Graphhopper takes extra turn

In the example linked, GH takes an extra turn for no reason. It could continue straight and then turn.

Link: https://graphhopper.com/maps/?point=35.840731%2C-98.189962&point=35.95743%2C-98.303611&locale=en-US&vehicle=car&weighting=fastest&elevation=true&turn_costs&ch.disable=true&use_miles=false&layer=Omniscale

Does the same with ch.disable=false

I checked OSM for data reasons and found nothing: https://www.openstreetmap.org/edit#map=16/35.9282/-98.3148

It will take that route if I set a waypoint: https://graphhopper.com/maps/?point=35.840731%2C-98.189962&point=35.922681%2C-98.263307&point=35.95743%2C-98.303611&locale=en-US&vehicle=car&weighting=fastest&elevation=true&turn_costs=true&ch.disable=false&use_miles=false&layer=Omniscale

Currently GH is not explicitly trying to avoid turns. I understand you think the second route (including the way point) should be preferred because it involves less turns?

easbar, thanks for the reply. Yes I thought turn costs set to true would then use less turns.

I actually provided the wrong link on the last one with a waypoint. It should be:

Good: https://graphhopper.com/maps/?point=35.840731%2C-98.189962&point=35.936483%2C-98.281122&point=35.95743%2C-98.303611&locale=en-US&vehicle=car&weighting=fastest&elevation=true&turn_costs=true&ch.disable=true&use_miles=false&layer=Omniscale
Bad: https://graphhopper.com/maps/?point=35.840731%2C-98.189962&point=35.95743%2C-98.303611&locale=en-US&vehicle=car&weighting=fastest&elevation=true&turn_costs=true&ch.disable=true&use_miles=false&layer=Omniscale

I suspect the reason is because the good route is .01km longer. I would have thought that a turn would add more time than .01km though. That’s only 33 feet or about 1/2 a second going the posted speed limit.

Is there a way to deal with this?

The turn_costs parameter currently only takes into account OSM’s turn restrictions (like ‘no right turn’ or ‘only_straight_on’). I agree that a route that is only slightly longer but includes less turns should be preferred and its certainly something GH should support in the future.

For now your only option is running your own GH instance and modifying the Java code. You would have to implement your own TurnCostProvider or modify DefaultTurnCostProvider.

Ahh ok. I’m currently running my own GH instance.

Curious if you have any idea how hard it would be to implement this? Is it something that could actually be programmed into the TurnCostProvider or is it a monumental change to how GH works?

I think its not so hard (anymore) since we introduced the TurnCostProvider interface. And yes you should be able to do all the logic in your implementation of this interface. The shortest path algorithms (including CH) are already able to handle turn costs (not just restrictions). The hardest part might be detecting what is and what isn’t a turn. That should be easy for the turns in your example, but more complicated when the junctions are not just crossings of perpendicular straight roads. But maybe you can take a look at the code for ‘instructions’ which solves a similar problem. The other question of course is how you model the turn costs (i.e. how large the turning penalty should be, depending on the vehicle, the road type and all this).

Powered by Discourse