openrouteservice
openrouteservice copied to clipboard
GIScience
ORS driving directions take wrong off-ramps when OSM has no turn restrictions
First off - thanks for this project!
Here's what I did
Requested directions from 46.433539,-81.035328 to 46.450351,-81.003549
https://maps.openrouteservice.org/directions?n1=46.430404&n2=-80.991662&n3=15&a=46.433539,-81.035328,46.450351,-81.003549&b=0&c=0&k1=en-US&k2=km
See also discussion in https://www.openstreetmap.org/note/1711523 and https://www.openstreetmap.org/changeset/68216922
Here's what I got
OpenRouteService recommends a very sharp left onto a roadway which is the off-ramp for traffic travelling in opposite direction.
(As of time of bug report, this is not entered as a turn restriction in OpenStreetMap. It is likely not signed. I will add it as an implicit restriction, but it seems worth it to handle cases like this.)
ors-export-linestring.json is:
{"elevation":true,"summary":{"distance":5312.4,"duration":301.8,"ascent":31.4,"descent":42.5},"geometry_format":"geojson","geometry":[[46.433554,-81.035314,278],[46.433503,-81.035202,277],[46.43329,-81.03446,275.8],[46.432856,-81.033016,276.6],[46.432468,-81.030673,280.9],[46.432238,-81.02846,280.7],[46.432166,-81.02672,275.5],[46.432223,-81.024967,271],[46.43241,-81.0234,271.5],[46.432597,-81.022034,273.7],[46.432779,-81.021145,275.5],[46.433104,-81.019496,277.3],[46.433374,-81.01824,277],[46.433674,-81.016111,275.9],[46.433725,-81.015076,277.1],[46.433716,-81.013908,278.7],[46.433632,-81.012968,279.4],[46.433503,-81.012131,279.5],[46.433308,-81.011206,281.1],[46.433027,-81.0103,283.9],[46.432548,-81.00886,284.4],[46.432364,-81.008306,282.7],[46.432247,-81.007954,281.8],[46.43156,-81.005836,277.5],[46.430032,-81.001198,277],[46.431424,-81.005051,276.3],[46.431727,-81.005802,276.5],[46.432045,-81.006456,277],[46.432459,-81.006982,277.4],[46.432881,-81.007282,277.8],[46.43331,-81.007443,278.1],[46.433864,-81.007486,278.7],[46.434372,-81.007425,279.8],[46.435193,-81.007179,279.4],[46.435993,-81.006907,275.4],[46.436727,-81.006761,271.1],[46.439577,-81.005731,268.7],[46.440949,-81.005532,270.2],[46.441497,-81.005421,271.1],[46.442075,-81.005468,271.7],[46.442157,-81.005474,271.8],[46.443278,-81.005747,271],[46.443744,-81.005833,270.3],[46.44414,-81.005906,270.1],[46.444787,-81.005934,271.5],[46.445405,-81.005848,273.7],[46.446154,-81.005481,275],[46.447183,-81.005053,272.9],[46.44866,-81.004439,270.2],[46.450361,-81.003591,266.9]],"segments":[{"distance":5312.4,"duration":301.8,"ascent":31.4,"descent":42.5,"detourfactor":1.73,"percentage":100,"steps":[{"distance":2746.2,"duration":123.6,"type":11,"instruction":"Head southeast on <b>Southwest By-Pass, 17</b>","name":"Southwest By-Pass, 17","way_points":[0,24],"distanceTurf":2746.9,"$$hashKey":"object:1055"},{"distance":2566.2,"duration":178.3,"type":2,"instruction":"Turn sharp left","name":"","way_points":[24,49],"distanceTurf":2567,"$$hashKey":"object:1056"},{"distance":0,"duration":0,"type":10,"instruction":"Arrive at your destination, on the right","name":"","way_points":[49,49],"$$hashKey":"object:1057"}],"$$hashKey":"object:1035"}],"way_points":[0,49],"bbox":[-81.035314,46.430032,-81.001198,46.450361]}
Here's what I was expecting
I would expect to take the right-hand turn onto looping offramp, even without a turn restriction in OSM.
Here's what I think could be improved
Give a scoring penalty for very sharp left turns, in particular onto one-way ways.
Similar case, in case it helps with testing, again a two-way highway with separate off-ramps and no turn restrictions:
https://maps.openrouteservice.org/directions?n1=42.94747&n2=-79.255596&n3=16&a=42.9519,-79.262238,42.947046,-79.259555&b=0&c=0&k1=en-US&k2=km
Test cases of unusual ramp usage in Germany:
Same problem of taking ramp intended for oncoming traffic: https://maps.openrouteservice.org/directions?n1=50.82665&n2=8.90134&n3=16&a=50.824983,8.900814,50.828073,8.891287&b=0&c=0&k1=en-US&k2=km
Here, strangely, ORS prefers a sharp left onto a slip ramp rather than a straight left: https://maps.openrouteservice.org/directions?n1=50.827667&n2=8.900417&n3=16&a=50.828277,8.891952,50.82501,8.900793&b=0&c=0&k1=en-US&k2=km
It seems it might be a similar issue as #339? That issue also involves unexpected use of slip/turn lanes and relatively sharp turns.
I'm not familiar with the algorithm at all, but to me it looks like it takes the as-the-bird-flies route and then finds roads nearest that route, but score penalties for sharp turns are not high enough.
It seems that this is related to that other issue yes as turning off the acceleration calculations on a local instance makes it so that it uses the slip road as intended (in the first example).
but the root problem seems to be how GH handles such instances, as for the same junction it also does the strange u-turn if you go closer to the junction
@rabidllama in your example you have moved the origin point past the turn-off point for the curved ramp.
Arguably a router should not suggest 170 degree left turns, especially off trunk routes, but the only other option from that starting point is taking the next exit 3 km up the road.
Yes I moved it past the turn off point to see if GH would take you to the next exit, which it does not and instead does the strange U-turn, which would imply that there needs to be something in the GH code which applies the sharp turn restriction. The reason it happens with the fastest option when used on the road before the junction is because we have some code that tries to take into account acceleration which isn't applied to roads that have a speed of higher than 80km/h. That means that the graph sees staying on the >80km/h road as being faster than turning off of it onto the link, which ends up having a speed half of that. So there are basically two factors that affect the choice of this U-turn:
- That the graph sees it as being faster to stay on the highway than to use the link road,
- There are no restrictions within GH that tries to stop such a turn being used
If you try shortest, the result is what you would expect; as mentioned above, my guess is that this is caused my contraction hierarchies which currently do not support turn restrictions @rabidllama
ah, well i too just noticed this: example what's worse, the B65 is at this point a Kraftfahrstraße, so it is illegal to do a u-turn
car defaulting to CH has long been a problem and should not be necessary anymore. Can we finally move to Core-ALT and ditch CH?
