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?
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.
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.
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).