More realistic road speed

[Esmolante]

Like all other navigators, the algorithm for calculating the fastest route assumes that the driver will travel at the maximum speed of the road. This assumption can be misleading, and provide a sub-optimal route calculation.
An example: There are two ways to reach the destination, one on a national road (maxspeed=100 km/h), and a slightly shorter way through a mountain pass (maxspeed=90 km/h). But in reality, the average speed on the latter road is 50 km/h. No one who knows the area would choose the latter option, as it is slower, although the calculation using the maximum legal speed on the road indicates otherwise. And even if it were slightly faster, most drivers would still prefer the better road, as it is the more comfortable, safer and more fuel efficient alternative.
So what do I propose to improve the route calculation? Use in the algorithm, not maxspeed, but a more realistic average speed, defined on the basis of road geometry and gradient. Of course, this would be a parameter specific to each road section that would have to be calculated in advance, when importing the OSM maps. And it would be sufficient for the algorithm to work with this speed value, instead of maxspeed.
Similarly, one could think about how to calculate a speed in a city, because it is not reasonable to think that we can cross a big city at 50 km/h maintained. There is dense traffic, traffic lights, crossings, pedestrian crossings... Here it is not very clear to me how to do it. It could be modulated by time of day (at night closer to maxspeed), and add delay for each traffic light, junction, etc. All the navigators, with the exception of Google Maps (it plays in another league, as it has access to real position data), suggest me to go through Madrid instead of going around it by the ring roads, which is crazy.
The proposed changes could be the differentiating factor to make OM the best offline browser. Or, at least, the best at calculating routes, which for me is almost a synonym.

[biodranik]

You're mixing it all together :)

1. Access to traffic data can improve any city/important highway navigation. It is impossible to do without the live traffic collection or at least statistical models in the past.
2. Introducing turns and traffic lights penalties should improve the algo.
3. Alternate routes should help in your 100/90km examples.

[Esmolante]

But alternative routes are of no use when the driver does not know the route (which is what the navigator is for). The driver chooses the most direct route through the mountain pass, unaware of the trouble he is getting into until he is already there, cursing the navigator for taking him that way.
Therefore, my proposal would be, when building the map for OM from OSM data, to analyse all roads from the points that define their axis and associate them with an average speed predicted by their geometry and gradient.
One way of doing this would be to take a point and calculate the distance to the straight line formed by the two previous points. And relate this value to the distance to the previous point. In this way we can discriminate whether it is an open or closed curve. By running this function over the whole layout of each section of road, we can get a faithful idea of its geometry (if it has many straight lines, open curves, closed curves...). With these values we would define a parameter which we could call "curvicity", which would limit the maxspeed of the road. It would be much simpler to do the same, but for the accumulated gradient, as steep gradients also slow down the pace.
The important thing is to approximate each stretch of road to the real speed at which an average driver would drive along it. This would allow the route calculation algorithm to work with much more realistic values than using the maxspeed value, offering more refined routes and more realistic estimated arrival times.

[biodranik]

CC @vng

[Esmolante]

By the way. This would also satisfy #3000: it would be trivial to implement an option for most twisty route possible for bikers and other asphaltic fauna. :)

[muralito]

There are/was some efforts to generate real speed data https://github.com/OpenStreetMapSpeeds

[Esmolante]

E.g. some set of users using experimental calculations, while the control set uses the traditional stable ones, and the collected results data could be used for evaluation. --> Great idea. I offer myself for data collection.
Another more convenient way would be to take advantage of the results provided by Google Maps routes (based on real data, let's remember) to establish patterns.
If the developers agree, I think I could be of help here.

[biodranik]

There are two independent tasks to improve OM ETA:

1. Take into account traffic lights, bumps, turns, road curves, and elevation.
2. Create, join or buy/get an online service that collects traffic-related data and road accidents/road works.

There are already some issues here for both points. Any help is appreciated.

[Esmolante]

Real-time traffic is undoubtedly the best solution, but it poses three problems:
a) Privacy
b) OM would no longer be offline-oriented
c) If provided by OM, it implies a critical mass of users, as well as a lot of resources to handle all that information.

The technical part I think would not be so difficult: OM collects and sends the average speed on each section of the road on which each user is traveling. If this deviates from the maxspeed (or, in the future, from the reference speed on each road, obtained with historical data), i.e. congestion, it sends an alert to the app of the users who have that road on their route to force a recalculation introducing that delay. Also for alerts of accidents, speedcams...
The problem would be the economic model to support it.

I am sorry if I am stating the obvious, I would like to be of more help.

[Misalf-git]

I'm not trying to talk you down, but you're killing your own arguments. With your approach, a, b and c still hold true.

[Esmolante]

I am just discussing the subject, pros and cons.

[muralito]

For the city where I live, there are open data with the average vehicle speed for each lane, measured every 5 minutes in the main streets.
One csv file per month since january 2021.
https://catalogodatos.gub.uy/dataset/intendencia-montevideo-velocidad-promedio-vehicular-en-las-principales-avenidas-de-montevideo

Let me know if such data is useful.

[Esmolante]

Not exactly the point but I don't want to risk unleashing the wrath of the programmers by opening new threads. :)
ETA is always calculated based on maxspeed, and does not even take into consideration the historical average speed on each type of road of each driver. For example, ETA is the same whether you drive a car or a motorhome or a lorry, even if the legal speed on the motorway is 120km/h with one and 90km/h with the other.
One option has already been discussed, which is that the user chooses the type of vehicle (or directly the maximum speeds for each type of road).
The other would be for the programme itself to record the average speed and react accordingly. For example, if I have been driving for 3 hours on a motorway at 90km/h, it does not assume that I will be driving at 120km/h for the rest of the journey.
Both options would increase the accuracy of the ETA, as well as the quality of the route (if you can't exceed 90km/h, you may not want to take a detour on the motorway, because you can't take advantage of its higher speed limit).

[Misalf-git]

The other would be for the programme itself to record the average speed and react accordingly.

That's a good one.

[biodranik]

Good one, but it can't predict right in advance, before collecting the data.

[Esmolante]

On another note, and without wishing to monopolise the debate.
I was thinking of a feasible intermediate step to reach real-time traffic speed.
To know this data we need a huge mass of connected users (Google again), so that there are several OM users on each (at least important) road/street at more or less the same time. This is still a long way off.
However, what would be more feasible is that, with the user's permission and properly anonymised, the programme could collect the average speed at which the driver is travelling on each road (it would be interesting to relate this to a vehicle class, car, motorbike, lorry, van / motorhome...).
These average speeds of each road are sent to the server from time to time and, based on them, OM could gradually build up a database of realistic average speeds for each day, discriminating by day of the week and time of day. For this, a much smaller mass of users is sufficient, so that at least once in a while a user passes each road (at least the main roads). For roads without data, until they are available, the average speed could be obtained by extrapolating from similar roads (same category in the vicinity). This alone would be a huge improvement in the quality of the optimal route calculation.

[coyoteecd]

I was thinking of putting a penalty on the maxspeed, e.g.

• highway == trunk road, use maxspeed * 1
• highway == primary road, use maxspeed * x
• highway == secondary road, use maxspeed * y
  ...
  and so on, where 0 < x/y/z <= 1 and would probably require some tweaking (they can be 1, for instance trunk vs primary might not require a penalty). For example use 0.9 for secondary roads and maybe a more aggressive value for residential ones.

This basically decreases the maxspeed based on the road class, as far as routing is concerned. It is not perfect, but as stated above I think it's simpler to try out and might get better results than purely using maxspeed (especially given that many villages/small towns have 50 km/h flat everywhere).

[biodranik]

We already have a not-perfect approach. Let's make it perfect ) Your idea doesn't work with speed bumps, traffic lights, and it will influence the otherwise valid ETA in some cases.

[muralito]

Maybe it could work, but not with the same penalties worldwide. What works for your city maybe is not the best for mine. The parameters in your approach may need to be tuned for each country/state/city.

[Esmolante]

We agree. The only thing is that these X and Y should be variable to add other parameters besides the category (road geometry, gradient, turns...).

[Esmolante]

We already have a not-perfect approach. Let's make it perfect

It is not possible to predict with total accuracy the speed on each road (and therefore the ETA), only to estimate it. It can be done in various ways (from more to less refined):
A) real-time data from other drivers on that road. We assume that the driver will go at the same speed as everyone else (which may be false, e.g. a lorry, and the speed would have to be corrected with the preceding speeds of that user).
B) historical data from other drivers on that road, discriminating day and time. We assume that the traffic pattern will repeat itself (quite likely, and is self-correcting with new data. Needs the same correction for driver/vehicle type as A)
C) maxpeed of the road. We assume that the driver will always drive at the maximum allowed speed of the road, which is a very poor approximation, and needs to be improved by taking into account, in addition to A) and B), other modifiers such as traffic lights, road geometry, detours...
The key is to establish assumptions that allow a more realistic calculation.