Create loop edges for nodes tagged as highway=turning_circle or turning_loop

[easbar]

The node (!) tags highway=turning_circle and highway=turning_loop are quite popular in OSM and can be used as an indicator for places where it is easy to turn around your vehicle. They are often used instead of an actual 'loop' of OSM ways at the end of dead-end streets and also rendered as such, like here at the end of Friedrich-Ebert-Straße:

So far we did not use these tags and simply applied the standard u-turn costs for every junction and dead-end. We also did not consider turning around at nodes tagged as turning_circle or turning_loop that were not junctions (somewhere in the middle of a road).

In this PR I modified the OSM import such that helper 'loop' edges (to be more precise: one extra node with two edges) are added to the graph that represent the turning_circle/loop. Without further changes this would mean that there is no turning penalty when we do a 'u-turn' at these nodes. This means that the routing algorithms will prefer turning around at these nodes compared to turning around at junctions and other dead-ends.

I'm not yet sure if this is an improvement, because there can be cases where suggesting to go into some residential area for example, just to turn around at the next turning_circle, makes little sense. Then again, it could easily be better than simply suggesting to turn around at the next 'junction', which could just as well be a crossing with some random footway etc.

todo:

• show the u-turns in turn instructions
• maybe still apply some kind of penalty for u-turns at turning_circle/loop nodes? currently the costs and even the distance of the helper loops is simply zero.

c.f. this and the following comments: #2139 (comment)

[otbutz]

Could we avoid the zero distance loops if we duplicate the incoming edges instead?

[easbar]

Could we avoid the zero distance loops if we duplicate the incoming edges instead?

Yes, maybe. This is an interesting idea!

Our requirements are:

• we need to be able to recognize turning_circle-turns for our instructions
• we need to be able to assign some kind of wight for turning_circle-turns

So far I haven't thought about or found a way how to this with neither approaches. And of course performance-wise it is better to add only one edge instead of two edges and an extra node.

[otbutz]

Increasing the cost for the virtual edge should work as it's only selected in case of a u-turn.

[easbar]

Increasing the cost for the virtual edge should work as it's only selected in case of a u-turn.

Yes, but we need to make sure we do not snap to it, but possibly this works by 'simply' (<-?) adding it before (or after) the normal edge. LocationIndex will then find the first edge before the other, we did something similar in #2689. To be able to add the turning cost we would need some marker bit for these edges, or (less flexible) somehow set fixed turn costs using TurnCostStorage. And of course the same applies for the other approach with the extra node.