Congestion observations

[Mariculous]

It is known that the current congestion calculation, whilst still an improvement, is a huge compromise as the relation in between congestion and travel times is quite guessed.

Currently, congestion is defined as the proportion of #vehicles/#stopping_vehicles on a tile.
A congestion of 100% expects the journey time to be doubled.

I had some observations of how well that guess matches the actual travel times and came to the conclusion that it's slightly overestimating the affect for not-really congested roads used by mixed speed vehicles e.g. 75 km/h busses and 88 km/h busses, but in any real congestion situation underestimates the affect on journey times by-far!

I had observed a 6km long congested stretch of road in betweeen in between swainsgrave and chorborough.
The congestion of each tile was around 30%, roads and vehicles maximum speed being 96 km/h
Thus, the congestion calculation would expect an uncongested journey time of 3.75 minutes, added 30% journey time due to congestion, we end up at ~5 minutes.

So let's get to the actual journey time of multiple observed vehicles:
The measured journey time for that stretch of road was for 9 out of 10 observed vehicles in between 35 and 40 minutes, thus roughly 10 times the guessed travel time!

However, that road is quite a hard one, so I also had further such observations around the intersection where the Burnerminster bypass joins the Burnerminster road.
I have observed 4km of road for both of these.

Burnerminster bypass is a 64 km/h TarMc, congested by ~40%, Burnerminster road is partly TarMc congested by ~60% and hot rolled asphalt congested by ~50%
Calculated journey times:
Burnerminster bypass: 3.75 minutes uncongested, 5.25 minutes congested
Burnerminster road: 1.4+1.5625 minutes uncongested, 2.24+2.34 =~4.6 minutes congested

Observed:
Burnerminster bypass: 9 minutes
Burnerminster road: 13 minutes

So, what does this mean?
As expected, the current congestion system does not at all relate to the actual travel times.
A fairly small congestion value can cause very huge delays in travel time, as can be seen at swainsgrave-chorborough.
Further, road ane vehicle max speeds do not well relate to congestion speeds.
Our current expactation that a congestion of 100% would double the journey time by-far underestimates the effect.

Suggestion:
In the long term we should think about the average tile speed based congestion calculation.
In the short term, we should increase the effect of congestion to the guessed jorney. "A congestion of 100% will multiply tiles expected jorney time by 5". Even that will underestimate the effect in most cases, but I think it's a good interims solution.

[jamespetts]

Thank you for your thoughts and detailed empirical observations. Would you suggest simply multiplying all percentages by 5 (as the percentage is intended to be precisely the measure of the additional journey time, or else it is meaningless as it is not a percentage of anything), or would you suggest some other specific algorithm which has the effect of tapering this at the lower end (and, if so, what algorithm would this be)?

[Mariculous]

As mentioned, there is no real relation in between congestion% and average speeds at the moment. This is true for all observed levels of congestion.
Thus, for simplicity, I would suggest to simply multiply the percentage by a fixed factor, e.g. 5 until we have a better measure for congestion implemented.

The issue why we cannot get any simple relation in between these is that the characteristics for the cause of the congestion is significiant for how much the #vehicles/#stops ratio affects travel and that characteristics cannot be simply determined:
E.g. a long closed level crossing will let quite a lot vehicles pass without a high congestion number whilst the journey time slowdown is significant.
Two merging roads will cause a lot of stops, that will be quite short if the merged road itself is not congested.

I had also considered taking the number of passed vehicles in the last month into account but that won't work either as one direction may suffer high congestion whilst there is a quite high traffic flow in the opposite direction.

Thus, I don't think we can properly addres this issue without an actual (directionally) per tile average journey time based approach.

Also see https://forum.simutrans.com/index.php/topic,19468.msg184463.html#msg184463 for a suggested implementation.

[Phystam]

Probably, it depends on meters per tile. In the British theme, it is 125m per tile. Do you think a private car occupies 125m on road? No, it occupies only 5~10m in reality when it stops due to congestion.
in our pak256 theme, which has 25m per tile scale, the condition changes. We need to consider that.

[Mariculous]

It does not depend on meters_per_tile.
congestion is currently defined as congestion:=vehicles_passed/vehicles_stopped.
The travel time expectation will scale linearly with the congestion value.

The suggested solution also won't depend on meters_per_tile by design, as we will use the ratio in between the expected and actual travel time to calculate a congestion factor.
No units as time, speed or distance involved (as the time gets eliminated)

[Qayyum]

Journey time is calculable only in specific vehivle in a specific route

[Phystam]

In principle, Qayyum is right, a car has a proper journey time.
However, it requires much cost for calculation. And we want to obtain the congestion ratio on the way. Journey time mesurement and journey time estimation are different issues.

By the way, I did a simple calculation. The situation is: "when the congestion happens due to a railroad crossing, how long time does it take to pass the crossing?"


1. crossing time
the crossing time depends on meters per tile, since the crossing size is proportional to the value. For example, it is 250 m for double track crossing in Pak128.Britain-Ex, while 50m in Pak256-Ex.
Therefore the passing time is also proportional to meters per tile.
t∝a,
where t is passing time, a is meters per tile.
2. repeating
Let's see the last private car, whose distance from the crossing is 1000 m. The array of car is inversely proportional to a. For example, there are 8 cars in front of the last car in Pak128.Britain-Ex, while 40 cars in Pak256-Ex.
Therefore
N∝1/a.
Naïvely the total passing time T will be
T=Nt∝1.
As Freahk says, the passing time does not depend on the meters per tile.

3. When the car number is same, what happens?
Probably you get the result immediately. Yes, the passing time will be T=Nt∝a. This is the problem. Is the generated car number in the game is inversely proportional to meters per tile?
The population in a certain tile area is proportional to a², naïvely. So the generated car number should have the same relationship. I don't know how many passengers are in a car, but if the capacity is not proportional to a² but constant, the larger the meters per tile become, the more congestion occurs.

[Mariculous]

This feature is currently already under developement.
Calculation of the expected journey time is another thing, where for sure the meters_per_tile is correctly considered..
It's as simple as t=v/d, distance d does not only depend on meters_per_tile but also on passing a tile diagonally or straight.
The assumption here is that a vehicle passing an entirely uncongested road will be able to travel at min(vehicle_speed, road_speed) speed. If they cannot, it is "congested", what should moreover be called a slowdown factor in this algorithm as sharp corners passed by playercars will also cause "congestion".

Calculating times to pass crosings does not matter to this algorithm. I don't think we should start identifying the cause of congestion and throwing some assumptions at the current pased/stopped algorithm, as that can quickly become an extremely complex, still inpreciese and much more inefficient task than simply measuring travel times on a tile.

Obviously, yes, the higher the meters_per_tile, the more inhabitants per tile. The more inhabitants per tile, the more cars will be spawned.
I don't think this is the point of measuring congestion ingame. We have different types of simutransians: Ones that don't have a private car at all, so they will always walk of use public transport, ones that hve a car but prefer the fastest way and ones that will always use their private car.
The whole thing about congestion is routing all the road traffic as good as possible along the fastest route and properly calculating private cars travel times, so the second type of passengers will properly decide if they want to use their car or public transport for the journey.

[Vladki]

A few things I have observed is: normally there can be only one vehicle (either player's or private car) on one tile in each direction. But on very congested places there are multiple private cars on the same tile - they probably spawned there when tile was occupied. That you could observe - buses waiting for clearance forever, with new and new private cars appearing in front of them. If you start deleting the private cars, or just using the inspection tool, you get a few private cars on the same tile, before deleting the road (or getting the info about the road). This should be avoided. Imho if a private citizen wants to use his car, and the road at his house is congested, he should either wait for clearance, or use public transport. Also allowing multiple vehicles on one tile (according to their visible length - i.e. at scale cca 20-30 m/tile) would be nice, but probably more complicated.

Another thing is how about this congestion measurement instead of cars stopped/passed: measure the average time cars need to traverse the tile (i.e. time between entering and leaving the tile) and compare it with top speed of the way on that tile. Zero congestion would be if all cars pass at top speed. So that some congestion would be indicated also in cases when cars that can't reach that speed use it. These average speed would then be useful to find fastest route for private and players cars to determine if using a bypass is useful or not.

[Mariculous]

The first is entirely true. Especially around monuments this can potentially lock down roads for an infinite amount of time. However, I would wait out for the new congestion measurement. That should already drastically congest such roads, thus sending more passengers by public transport to those attractions. Cars piling up is not pretty nice but not spawning them at all just because there is a car on the road at that exact moment, also is not a good option imho.
Maybe limiting this to two cars per tile, might be an option.

About the congestion measurement:
Keep in mind that there is already an alternative approach in developement.
I guess that exact approach you suggest was discussed on stephenson-siemens, but was discarded in favor of an additional travel time based approach.
The reason for this is that an average speed does not tell us much about congestion of a road especially on barely used roads with a few low speed vehicles.
These few vehicles would not affect most faster vehicles on that road as there are simply no such vehicles on that road at that time.
Not to mention unidirectional roads, where even if there are quite a lot of slow vehicles, these won't have a huge effect as overtaking works quite well.
Once a road is out of balance, which means mainly used by slow vehicles, it's quite unlikely to get in balance again.

For sure, the additional travel time measurement also has its disatvantages, but these missgueses won't throw the whole road out of balance.
Asuming there are quite a lot slow vehicles on a road, which don't affect each other, the road will be uncongested. As it is uncongested, faster vehicles might attempt to use it.
These will however cause congestion.

Another variant would be using both:
The more congestion there is on a road, the more we will consider the average speed of that road to decide if we should use the road or not.
The idea behind this is that a low average speed will likely not affect slow vehicles as much as it would affect faster ones.
This will however only work properly for player vehicles, as private cars all share the same routes, thus we cannot distinguish in between routes for faster vehicles and slower vehicles.
In any case, I would prefer emprirical observations of the suggested and by Freddyharwayd already implemented solution measuring congestion based on additional travel times before investigating further improvements.
If that works practically well, it's all right!