openrouteservice
openrouteservice copied to clipboard
GIScience
only_straight_on restriction is not supported
Hello,
only_straight_on restriction is not supported. Please check following route:
https://maps.openrouteservice.org/directions?n1=50.157696&n2=25.30745&n3=17&a=50.157645,25.305556,50.157398,25.308088&b=0&c=0&k1=en-US&k2=km
Thanks Dima
It seems this is an issue in graphhopper as on there it does the same - https://graphhopper.com/maps/?point=50.157683%2C25.304807&point=50.157346%2C25.308176&locale=en-GB&vehicle=car&weighting=fastest&elevation=true&use_miles=false&layer=OpenStreetMap.
Within ORS, the "continue_straight" parameter only affects continuing straight when there are multiple segments created by adding via points to the route. I believe the reason for the detour down the connecting way is because in OSM the main road has a speed restriction whereas the connecting road that is used does not, and so the routing "prefers" that small segment as it believes it is faster. Indeed, if you tell the service to use the shortest route, it continues along the main road.
If you build route on OSM.org, GraphHopper does it correctly...
https://www.openstreetmap.org/directions?engine=graphhopper_car&route=50.15762%2C25.30571%3B50.15733%2C25.30850#map=18/50.15747/25.30710
I believe there may be some differences between the graphhopper used on the graphhopper site and the one used by the osm site... The api calls appear to be the same but each gives a different response in terms of the diversion.
Hi, I can confirm the problem. In the case below there is a turn restriction only_straight_on on road SS16 from South to North, but ORS does a right turn. I tried OsmAnd (Android app) which indeed obey the restriction. https://maps.openrouteservice.org/directions?n1=43.61513&n2=13.384566&n3=17&a=43.61471,13.385403,43.614827,13.384266&b=0&c=0&k1=en-US&k2=km
@RigacciOrg @ujos - I have looked into this and it appears to be due to the system defaulting to contraction hierarchies when no additional parameters are set (i.e. maximum speed). When these contraction hierarchies are used (primarily this is a method which massively increases speeds of long distance routing, turn restrictions are not taken into account. If you turn on a parameter such as avoid tracks, then the route generated is correct:
https://maps.openrouteservice.org/directions?n1=43.615242&n2=13.38484&n3=17&a=43.614734,13.38535,43.614827,13.384266&b=0&l8=1&c=0&k1=en-US&k2=km
We are currently working on a bunch of new things relating to the algorithms used. @aoles - is this something that would be resolved when these things are complete?
@rabidllama not sure yet, as it depends on various factors and performance constrains.
In the latest version of GH (0.12) contraction hierarchies will support turn restrictions, so when we do the upgrade for that this should be fixed. I will put it on hold until we have the update complete in the upcoming months and then we can check if it fixed the issue
It's been over a year since the last post, and nearly as long since Graphhopper 0.12. Can we get an update?
We won't use GH's edge-based CH, it's very expensive for what it delivers. Actually for now, it might even be worse, as disabling CH (by setting an arbitrary dummy restriction) will enable C-ALT, which is also not ready for turn restrictions. We're working on fixing the latter though.
In the meantime, you can try integrating a dummy avoid_polygon which should trigger A* routing and respect turn restrictions.
Correct me if I'm wrong @HendrikLeuschner @aoles.
I think you are right @nilsnolde . We are working on integrating our own solution that has no performance penalty to support turn restrictions with high performance calculations. Will check back with my colleague to see whether only_straight_on is supported.
The original example doesn't seem to be relevant anymore. However, the issue is evident from the following example which has been fixed by now in GHv7 via https://github.com/graphhopper/graphhopper/pull/2689.
@aoles Let's close this issue then as fixed and open a new one for the proper integration of that feature?
