Turn restriction support for /route and /matrix is now officially supported and the documentation mentions a new flag: turn_costs=true will enable turn restrictions based on OpenStreetMap data.
See this blog post for more details: https://www.graphhopper.com/blog/2020/07/08/turn-restriction-support-for-graphhoppers-directions-api/
Nice stuff Easbar.
When you talk about more computational time are you talking to generate the graph or generate individual routes?
Besides the driving we often spend a significant amount of travel time on turning between roads, waiting at traffic signals or even taking u-turns in case we need to change the direction after reaching some intermediate stop.
Does this mean enabling turning costs will add extra time to paths for turns? Where route.getBest(); may return a more direct path (more distance) instead of a windy zigzag path with more intersections (less distance but more time at intersections)?
Both. Enabling turn restrictions slows down the graph preparation and query time. But obviously for API users only the latter is relevant.
In general this is how turn costs work, yes. You can imagine time penalties for sharp turns etc. which would be added to route.getBest().getTime(). But for now the Directions API only supports turn restrictions, i.e a turn is either possible (no time penalty) or impossible (infinite time penalty/another route will be chosen). Using finite turn costs requires adjusting the (edge) costing model because edge- and turn-costs need to be geared to each other. I just mentioned this at the beginning of the blog post to give some context. The open source routing engine already can deal with finite turn costs on the algorithm level by the way.