Germany has signs that indicate that a priority road makes a turn:
This shows that the priority road makes a left turn, but also that you have to signal left to show that you’re staying on the road. A router would definitely be expected to tell you to “make a left”, because of this sign. So far so good, but sometimes, all the signs on a crossing aren’t really cohesive, and it can happen that the signs on each street of the crossing differ in a way you wouldn’t expect. Example:
As you can see, if you come from the west, or north-west, and want to go east, (green arrows) you have to signal left, but if you come from the east and want to go west (red arrows), you must not signal at all.
I tried several times to solve this with geometry, but it always ends in a mess of oneway roads which don’t reflect the reality on ground.
Question: Are connectivity-relations made to solve these issues? I’m suspecting so, because this relation is listed in the proposal as an example to »mark what the “through” part of the oneway road actually means«. Since the relation doesn’t have “through” anywhere, I’m suspecting, that the general idea is that if you link from a lane on road A to a lane on road B and the lane on road A is a turn-lane with “left”, then this could be used by routers to create a “make a left turn” direction.
Is this assumption correct? If not: are there any other tags that I could use to give these turn-hints?
That would require some serious modification of the connectivity=*-key. So instead of connectivity=1:1|2:2,3, we would somehow have to modify it to be closer to connectivity=1:1;through|2:2,(3);left. Mening: Lane 1 from the from-way connects to lane 1 of the to-way by going through (straight), whereas lane 2 of the from way connects to lane 2 of the to way (but you can also turn into lane 3), by making a left turn. The proposal does explicitly mention, though, that it’s not meant to be used for this:
This relation type doesn’t specify what “turn” travelling from the from way to the to way is - that should be added in the turn:lanes=* tag of the from way, since that is where it is specified in the real world. Another option for this is to use a type=manoeuvre or type=maneuver relation, which are supported by OSRM, but aren’t very common.
That actually sounds like manoeuvre is only useful if the markings on the ground don’t match the reality. Or am I misreading this?
Meant adding maneuouvre= to type=connectivity only. connectivity= should be kept separate. But I realized it only works with the central section as via .
Can you explain what connectivity=1:1|2:2,3 refers to? I don’t understand how you arrived at 1:1 being through , and 2:2,(3) being left . You need to make 2 type=connectivity for each pair, with 1 for each direction. The from and to are swapped between them.
That was just a generic example, and not related to the crossing of my initial posting. Yes, you need 1 connection per direction, but manoeuvre needs 1 relation per manoeuvre, so this wouldn’t be compatible. Which is why I suggested adding the actual manoeuvre after each connection. Anyway, I’m not sure which one top use in my case. Both would work, bit manoeuvre seems a bit exotic here.
Really? You cross that many dashed lines and don’t signal for any of them? Round here you’d be expected to signal that you’re departing the main road and that you’re leaving the second road to join the third.
Officially, you would be required not to signal, but I suspect that most people would probably signal a left turn after they left the priority road. The important bit is: you’re expected not to signal that you’re leaving the priority road, whereas the reverse way requires you to signal left.
Maneuver relations are sort of a stopgap. Their only value is to keep routers from doing something too naïve that would cause real-world problems. But the router developers who implemented it would be quick to acknowledge that, ideally, OSM would come up with other ways to model these specific cases more descriptively so that a brute-force override wouldn’t be necessary. Since these relations are added as a last resort, there would probably need to be multiple approaches to replacing the relation type, depending on the situation.
As approved, a connectivity relation only pertains to lane connectivity. If we were to extend this scheme to also classify the associated maneuver, it would need both a maneuver classification like “turn” versus “fork” and a direction classification like “left” versus “slight left”. Since that would be pretty experimental and unproven, I’d still leave the maneuver relation in place, redundantly, for backwards compatibility until routers learn to respect connectivity relations in the first place.
Yes, I totally agree. We don’t want to end up having to put 2 relations (connectivity plus manoeuvre) for these types of crossings, but rather extend the approved one to be able to handle both situations. Not an easy thing to do.
