Proposal talk:Wait

Except when turning right

MUTCD R1-10P

Thanks for this proposal – there is a real need for something like it. In the U.S., which drives on the right, a standard sign can appear beneath a stop or yield sign to indicate that it only applies when turning left or going straight through the intersection but not when turning right. However, the sign is almost always used on two-lane roads (one lane in each direction). I don't think wait:lanes:forward=none;stop would be clear enough to data consumers, because normally the indications separated by semicolons in a *:lanes tag are unordered. As far as I can tell, "stop except right turn" would be best expressed as a relation of some sort. For the time being, I've been piggybacking on maneuver relations to represent these exceptions, since stop relations never caught on but at least one router (OSRM) uses maneuver relations. I've also seen node-based approaches, but it seems less elegant to model a maneuver by reference like that. Perhaps if this proposal gets approved, wait=* could be used on existing relation types as well. – Minh Nguyễn ^💬 13:40, 21 November 2020 (UTC)

If the "stop except when turning right" sign is on a two lane way, this proposal would address that, and wait:lanes=stop|none would solve that situation nicely. Note that the separator here would not be a semicolon but a bar "|" which creates an ordered list, from left to right.--AntMadeira (talk) 19:52, 21 November 2020 (UTC)

@AntMadeira: If there's only one lane in each direction, the way would be tagged lanes=2 and turn:lanes:forward=left;through;right. Setting wait:lanes:forward=stop|none would be inconsistent with the overall lanes tagging scheme, because it would imply two lanes in the forward direction. wait:lanes=stop|none would be incorrect because it would indicate two lanes in either direction. – Minh Nguyễn ^💬 22:11, 21 November 2020 (UTC)

That's why I wrote "if (...) sign is on a two lane way", but I was referring to a one-way, of course. This proposal doesn't apply to ways with only one lane. What you bring here is another parallel problem, which has to do with "two traffic signs" that apply to the same lane. Similarly this doesn't solve the problem where you have two physical traffic signs in the same way direction, like you can see in the third example of the proposal.--AntMadeira (talk) 22:21, 21 November 2020 (UTC)

@Minh Nguyen: Although I had never seen a sign like the one you show here, this proposal has some limitations which are difficult to tackle. Your example is one of them, but there's also the problem about mapping the traffic signs as nodes when using the wait key. In a two lane way, if you use the wait key, how do you map a stop sign and a give_way sign, for example? A possible solution would be creating the nodes in their real positions, as nodes, and add direction, but how do you assign them to their respective lane? Me and L___I talked about a possible solution, which was something like this: give_way:lanes=through|none;stop:lanes:backward=left|none; traffic_signals:lanes:forward=left|none. In your example, we would have stop:forward=left;through. But this would create three tags, instead of one and wouldn't solve the traffic_signs positioning problem. --AntMadeira (talk) 21:17, 22 November 2020 (UTC)

@Minh Nguyen: I should mention there's traffic_signals:turn=right_on_red and traffic_signals:turn=not_right_on_red in Proposed_features/turn_signals#<turn-modifier-value>. stop=* is currently used for stop=minor and stop=all. ---- Kovposch (talk) 11:36, 31 January 2021 (UTC)

@Kovposch: Thanks, I didn’t know about that proposal – I had been tagging restriction=no_right_turn_on_red relations instead. (OSRM and probably other routers know to avoid treating this value as a hard restriction.) But I don’t think that proposal really addresses the situation I was referring to above, which is for unsignalized intersections with just a stop sign and only one lane in each direction. Besides, in the U.S., there is almost always a physical barrier between continuous through lanes and signalized turn lanes, which means there would be separate ways. (Proposed_features/turn_signals#<turn-modifier-value> was inspired by one notable exception in California.) – Minh Nguyễn ^💬 18:36, 7 February 2021 (UTC)

Only a suggestion for your formatting. Was thinking whether eg stop:turn=no_stop_on_right or 'stop:turn=left|through would be a good idea. ---- Kovposch (talk) 19:37, 7 February 2021 (UTC)

That's interesting and could be a solution to this wait proposal, but it would imply that stop sign (and yeld and traffic signs) would be stop:turn=all by default. Besides, it wouldn't solve the problem of the first and second examples of this proposal, where there is no priority intersection. --AntMadeira (talk) 23:55, 7 February 2021 (UTC)

Difference to traffic_sign

What exactly does this new tag add that can't be expressed using the established traffic_sign=*? "traffic_sign:lanes=give_way|none" seems perfectly suited for this purpose. --Mueschel (talk) 19:49, 22 November 2020 (UTC)

You can consult the previous discussions in tagging list, where you'll see this was already discussed. The rationale is that traffic_signs don't have lanes, so the logic of the lanes scheme is broken. --AntMadeira (talk) 20:25, 22 November 2020 (UTC)

":lanes" is a generic concept that can be applied to any lane-related tag including traffic signs. I'm a regular reader of the tagging mailing list but can't find the thread. --Mueschel (talk) 20:39, 22 November 2020 (UTC)

You have the link here: Proposed_features/wait#External_discussions --AntMadeira (talk) 21:21, 22 November 2020 (UTC)

After reading the thread, I still see no reason not to use traffic_sign=*. Naturally, it needs to be suffixed by :forward|:backward on a two-way street, but this is a common technique already. --Mueschel (talk) 09:17, 29 November 2020 (UTC)

There are two problems when using traffic_sign=* as you suggest. First one is using it in points. Not only points don't have lanes (the lanes scheme apply only to ways), they can not solve the examples this proposal have in its main page (like where the affected way starts and ends). Second problem is using traffic_sign=* in ways. As you can see here, here and here there is not a consensus about using traffic_sign=* as ways, which is also my opinion, so why create a proposal based on something that it’s not consensual and probably will never be? --AntMadeira (talk) 03:56, 4 December 2020 (UTC)

I don't agree with traffic_sign:lanes=* being sufficient (it's a sign, not functional), but I fail to understand your insistence that a point can't use *:lanes=*. Does it mean Forward & backward, left & right is inapplicable as well? Both are given meaning when points are on lines. (technically it may also be ill-defined when a point connects 2 crossing lines) ---- Kovposch (talk) 11:21, 4 December 2020 (UTC)

The *:lanes=* key doesn't apply to points, only to ways, as stated on it's wiki page. Unless you make a proposal to change that, I don't see why this proposal has to force something just because. I don't understand your comparison with the forward, backward, left & right values, since they mean the direction of travel affected by traffic signs on a way, so they can be used on points and have different semantics. --AntMadeira (talk) 19:46, 4 December 2020 (UTC)

This is about usage. It will be challenging to discuss anything if the assumptions and scope aren't clear. Consider the case of people "wrongly" applying your proposed wait:lanes=* on points as this seem natural to them. To what extent lines are split to apply this tag will be another issue in practice. So what's wrong with the meaning which lanes that affected by the sign or whatever feature? In terms of the formal process, Proposed_features/right_left is "supposed" to only apply on lines. The 1st line of Forward & backward, left & right#Tagging even tries to point the problem of using this concept on points. Proposed_features/direction mentioned it was ignoring direction=forward and direction=backward. If you look at for example Proposed_features/Conditional_restrictions for proposals related to *:forward=* and *:forward=*, this aspect also seem to be restricted to lines. ---- Kovposch (talk) 22:30, 4 December 2020 (UTC)

People can make "wrong" decisions all over OSM, but if the wiki page is well written, it will help to reduce the mistakes. Lines don't need to be split, like they don't with turn:lanes=*. The examples on the proposal page are very clear and don't involve splitting lines. "So what's wrong with the meaning which lanes that affected by the sign or whatever feature?" Well, if we agreed to open an exception to the rule (and logic), using lanes on points would miss the extension (beginning and end) of the affected lane, which is an important information conveyed by this proposal. Like in turn:lanes=*, we don't create traffic_sign points (and we could, by your reasoning), we apply that tag to ways only, because is important to have the extension of the affected lane. Also, a traffic_sign is supposed to have one sign assigned, not two or three. In the second example of this proposal (which is very common), you don't have a physical sign present. With a point, you would be creating a visible point over the line (and map) which would "affect" all lanes, instead of using a more conspicuous way of affecting only the lane we need. About the 1st line of Forward & backward, left & right#Tagging, is important to notice that it's a fringe problem that only affects points over crossing ways, which is easily solved and wouldn't be a problem here. --AntMadeira (talk) 23:45, 4 December 2020 (UTC)

Actually, after thinking a bit more about it, it seems that highway:lanes=* (still on nodes) would be the better tag - we already use highway=stop and highway=give_way. So that would be the logical way to extend to lane-dependend give-way signs. --Mueschel (talk) 17:59, 4 December 2020 (UTC)

Application to long turn lane sections

The distance from the 'form' point as described in the proposal can be huge:

from the first indication via road markings, signposts or similar indications which clearly divide the lanes in a particular direction

In many cases these highways need to be split into several different ways (e.g. due to other features of the road changing or bridges). How are data consumers able to figure out the actual position of a stop sign in this case? --Mueschel (talk) 09:22, 13 December 2020 (UTC)

That's a good question. If you have a segment with a bridge in the middle (----===----), for example, I think that the logic is to consider the last segment in the direction of the way as the segment where the stop/give_way/traffic_signs is. If, for some reason, that becomes a problem, you can just tag the last segment. --AntMadeira (talk) 18:34, 13 December 2020 (UTC)

Point-like features should not be tagged on ways

The stop signs or traffic_signals are point-like features that affect only a certain point of a lane. These should be tagged on nodes but not on ways. Having them tagged on ways needs a whole new set of editor and validator features that take care that when splitting a way the tags are transferred to the correct portion of the way. Using nodes circumvents this issue completely. --Mueschel (talk) 09:22, 13 December 2020 (UTC)

What does this have to do with this proposal? --AntMadeira (talk) 18:36, 13 December 2020 (UTC)

You propose to add a tag to ways and this tag is used to describe a point-like feature. The proposal should be to add a tag for point-like features to nodes. --Mueschel (talk) 18:38, 13 December 2020 (UTC)

This key doesn't substitute the traffic signs on nodes. It just conveys information about the lanes. It doesn't tell you where to stop or give_way, it just informs you that you'll have to stop/give_way [wait] sooner or later in that particular lane (preferably at the end of the affected lane). It's a workaround for the impossibility of using more than one node with a traffic sign on the same way without redundancy. Maxspeed, to cite just one example, is also applied to the lanes scheme, and no one argues that we're applying a traffic sign to a way. --AntMadeira (talk) 19:19, 13 December 2020 (UTC)

'maxspeed' affects the whole length of the way, so it obviuously can be tagged on ways. Please elaborate on "It's a workaround for the impossibility of using more than one node with a traffic sign on the same way without redundancy." I don't understand what you mean. Any way can have as many nodes with traffic_signs as there are signs. If this new key doesn't substitute the traffic_sign or highway tags, it's redundant and unnecessary. --Mueschel (talk) 19:50, 13 December 2020 (UTC)

When you use turn:lanes, you're referring to a traffic sign or markings which have turn indications, and you don't say that you're applying a traffic sign to a way or a lane. Here, the logic it's the same, but with other kinds of traffic signs/markings. You're conveying information that lane X will encounter a traffic sign at the end of the that lane. "Please elaborate on (...)". What I mean is that in these cases where you have two traffic signs for two lanes on a way, you can't create two nodes with traffic signs, say a stop sign and a give way sign on the same way, because you don't have a way to tell which one affects which lane. That's precisely the information this proposal aims to give. It doesn't substitute traffic signs, it only conveys information where traffic signs can't be assigned to different lanes. --AntMadeira (talk) 18:53, 14 December 2020 (UTC)

We don't need yet another tag for the same thing. What we need is a well documented and planned extension of the ':lanes' syntax to nodes on ways. It's exactly the same as using forward/backward on nodes which was established long ago. --Mueschel (talk) 21:27, 14 December 2020 (UTC)

Your description "lane X will encounter a traffic sign at the end of the that lane" clearly indicates to me that this information should be on an element "at the end of that lane" (a node). Equating it to a turning lane isn't perfect. The whole turning lane exists for the purpose of turning. The node at the end is the place where you stop. Similar, I wouldn't tag a 10 mile road with "leads to a park", I'd just put a park at the end of it and a data consumer can interpret the physical geometry.

What about splitting ways?

Are you aware why Proposed features/transit failed? How this proposal will avoid it? There should be way to keep data valid, also in case where mapper unaware about this tag will split a way (without special support from editors) Mateusz Konieczny (talk) 07:17, 29 January 2021 (UTC)

Sorry, I'm not aware. I would appreciate you to explain it to me. I don't understand what's the problem with splitting ways. Doesn't that happen when you split any kind of way with information on it? What happens if you change a street name with 50 buildings around it? Are you not going to change the street name because you would need to change the address of those 50 buildings too? What about turn:lanes, maxspeed:lanes, width:lanes, etc.? What about relations? OSM is full of examples of things that can't keep data valid when mappers change them unwillingly. Are we in favour of adding data consistently or in favour of not adding it because people will change it in the future? AntMadeira (talk)

"turn:lanes, maxspeed:lanes, width:lanes" - this apply to entire length, right? While wait:lanes applies to the end of way? So if you split maxspeed:lanes it can and should end on both. Where wait:lanes should end? On both of them? 17:27, 29 January 2021 (UTC)

What do you mean with the entire length? It applies to the length that you decide, like with wait:lanes. It's exactly the same. It starts and ends where you decide it starts and ends. You cut the way where the wait:lanes starts and cut it again where it ends, exactly like you do with the entire lanes scheme. AntMadeira (talk)

wait:lanes=stop|| means "at the end of this segment left lane must stop before continuing, right"? Mateusz Konieczny (talk) 09:31, 31 January 2021 (UTC)

Yes, like turn:lanes=left|| means you have to turn left at the end of segment's left lane before continuing. --AntMadeira (talk) 14:19, 31 January 2021 (UTC)

turn:lanes=left|| has a different meaning. It means "this is a lane for turning left". It may be split before crossing itself Mateusz Konieczny (talk) 20:37, 31 January 2021 (UTC)

That's not always correct. There are many examples like, for example, turn:lanes=through;right where that doesn't apply. Besides, we could apply the same reasoning to wait:lanes=stop||, like you can see in example two of the proposal page: "This is a lane where you have to stop before turning." --AntMadeira (talk) 21:24, 31 January 2021 (UTC)

"This is a lane where you have to stop before turning." - it is not so simple. It may apply before turning, before crossing with major road, before crossing with a minor road (sometimes even driveway in case of fire station driveway!), before level crossing, on start of single-lane section with reversible direction, before hazard, before entering ferry etc... How data consumer is supposed to detect point where stop/give way/etc applies? Mateusz Konieczny (talk) 07:48, 8 February 2021 (UTC)

Maybe the wording is not encompassing all the possibilities and that's something that can be changed in a possible future proposal, but isn't that what you're doing when splitting a way and tagging it with a wait tag? I mean, if you cut a way in the "beginning" (as in "the wait lane starts here") and cut it again in the "end" (as in "the wait lane ends here") what's the information that's missing for data consumers? --AntMadeira (talk) 16:08, 8 February 2021 (UTC)

Location where stop/give way would actually happen. Given OSM way may have "stop" modifier tagged on it and it may apply (1) once at the end, (2) not at all, (3) multiple times Mateusz Konieczny (talk) 16:18, 8 February 2021 (UTC)

Well, do you know any mechanism that doesn't involve relations to do that in OSM? Like many other features, I guess you would have to assume that the stop/give_way/traffic_signals would occur at the end of the wait lane. In that case, you would know that you should encounter a stop/give_way/traffic_signals at the end of the stretch of way tagged with wait:lanes. For me, that's the biggest virtue and also the biggest problem of this proposal. In examples 1 and 2, it's not possible to map a point there. This proposal tries to fix that using the lanes scheme to say "at the end of the wait lane, you'll have to stop or give way. --AntMadeira (talk) 01:50, 9 February 2021 (UTC)

"you should encounter a stop/give_way/traffic_signals at the end of the stretch of way tagged with wait:lane" - then you ran into problem with way splitting, see beginning of this section. "Well, do you know any mechanism that doesn't involve relations to do that in OSM?" - tagging on nodes with some direction indicator Mateusz Konieczny (talk) 03:15, 9 February 2021 (UTC)

Ok, I finally (!) understood what you mean with the problem with splitting a way (that's what happens when two people from different countries try to communicate with a third language...). Maybe we could make the assumption that in the cases where you have a series of segments of connecting wait:lanes, the "action point" would be on the end of the last segment. If you have something like

where the consecutive horizontal segments are wait:lanes, it would assume the "action point" before each junction. About the direction indicator on points, I don't see how that could work. How would you convey lanes info that way? --AntMadeira (talk) 05:27, 9 February 2021 (UTC)

The solution that you mention would mostly work - I expected something like that to be a part of proposal. The problem is that expressing "each of crossings has the same per-lane stop rules" would require splitting road and removing turn:lanes:forward from some section Mateusz Konieczny (talk) 12:46, 17 February 2021 (UTC)

"About the direction indicator on points, I don't see how that could work. How would you convey lanes info that way?" Using turn:lanes:forwardturn:lanes:backward with way direction mattering for forward/backward also would work, but that would also require extra support from editor software on reversing way :( Mateusz Konieczny (talk) 12:46, 17 February 2021 (UTC)

Traffic signals

"Driver must obey to traffic signals on the affected lane." -this is true in general. It seems to be about fact that traffic lights are present on the specific lane Mateusz Konieczny (talk) 07:49, 8 February 2021 (UTC)

What do you mean with this, Mateusz? --AntMadeira (talk) 01:56, 9 February 2021 (UTC)

After vote

Note "If the vote fails, do not despair. Many proposals were rejected, modified and succeeded. Sometimes proposal fail because some people noticed issues during vote." and "Rejected features may be resubmitted, modified, and new vote started. You can also move back to the RFC process." at Proposal process. Mateusz Konieczny (talk) 12:42, 17 February 2021 (UTC)