Proposal:Wait
(Redirected from Proposed features/wait)
| Lanes with give_way/stop/traffic_signals | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | AntMadeira, L___I |
| Tagging: | wait=none/give_way/stop/traffic_signals
|
| Applies to: | 
|
| Definition: | Define the lane(s) where stop/give_way/traffic_signals apply |
| Statistics: |
|
| Draft started: | 2020-11-20 |
| Vote start: | 2021-01-27 |
| Vote end: | 2021-02-10 |
Proposal
This proposal introduces the key wait, which specifies the lanes where give_way/stop/traffic_signals apply. This key is only useful if used together with at least one of the suffixes :lanes, :forward or :backward or on one-ways.
Rationale
At the date of this proposal, there's no easy or straightforward procedure to tell routing apps when a driver has to stop or give way on a certain lane. Adding a stop or give way sign to a way doesn't solve this, because there could be several different signs affecting several lanes on the same road. Adding to the :lanes scheme, this proposal aims at introducing a key which identifies a specific lane where a give_way/stop/traffic_signals is applied, while the others on the same carriageway are not affected. This can be used by routing applications to inform drivers that they have to wait on a certain lane.
Tagging
Lane-specific information can be expressed in a way by suffixing the key with :lanes, as with other keys in the same scheme, like maxspeed=*, destination=*, turn=*, change=*, etc. The value of that key then contains the values for each lane separated by a | (vertical bar) in left-to-right order as viewed in the respective driving direction of those lanes (resp. in the osm-way direction in case of lanes running in both directions).
The selected portion of the affected way, must be cut in the following way:
- from the first indication via road markings, signposts or similar indications which clearly divide the lanes in a particular direction
- to the junction or the completion of merge.
This key would have four different possible values: none, give_way, stop or traffic_signals.
| Value | Action |
|---|---|
| none | The lane is not affected by this key. The driver doesn't need to wait on the affected lane. |
| give_way | Driver must give way on the affected lane. |
| stop | Driver must stop on the affected lane. |
| traffic_signals | Driver must obey to traffic signals on the affected lane. |
A simple example with wait key on a one-way street:
lanes=3 turn:lanes=left|through|right wait:lanes=stop|none|give_way
This would be a road with three lanes, with a stop applied only to the leftmost lane, none to the centre lane, and a give way sign on the rightmost lane. For a driver, this means he/she has to stop on the left lane to turn left or give way on the right lane to turn right, while the centre lane has no restrictions.
The direction of the lane change is usually viewed in the direction of the OSM way. If the key is used together with the suffix lanes:backward (i.e. as wait:lanes:backward=*) the direction is viewed in the opposite direction of the OSM way.
Examples
These are some examples of places where the wait key could be helpful.
| Images | Tags | In OSM |
|---|---|---|
 |
lanes=2 turn:lanes=merge_to_right|through;right wait:lanes=give_way|none |
776323611 776323611
|
 |
lanes=3 lanes:forward=1 lanes:backward=2 turn:lanes:forward=left;through turn:lanes:backward=left|through wait:lanes:backward=stop|none |
776617389 776617389
|
 |
lanes=3 lanes:forward=2 lanes:backward=1 turn:lanes:forward=left|right wait:lanes:forward=traffic_signals|give_way |
875250330 875250330
|
Applies to
This key applies to ways only, as in the lanes scheme.
Related keys
turn=*destination=*
External discussions
See also
Comments
Please comment on the discussion page.
Voting
Voting closed
Voting on this proposal has been closed.
It was rejected with 7 votes for and 9 votes against.
I approve this proposal. --AntMadeira (talk) 01:42, 27 January 2021 (UTC)- I approve this proposal. --HedgiePT (talk) 03:09, 27 January 2021 (UTC)
- I approve this proposal. --Aharvey (talk) 03:20, 27 January 2021 (UTC)
- I approve this proposal. --ForgottenHero (talk) 07:09, 27 January 2021 (UTC)
I oppose this proposal. changed to no - problem of handling way splitting remains unsolved. Original comment for abstain: thing seems missing - an explicit mention that it applies on the end of last way with the same tagging (so splitting way requires no special functionality - to avoid Proposed features/transit fiasco). Sorry for not noticing it earlier. Mateusz Konieczny (talk) 07:11, 27 January 2021 (UTC)
- That won't work in dense city environments - the next lane with wait tags might start right after the first one ended. --Mueschel (talk)
- It can be solved by one extra way split. Otherwise it is doomed to Proposed features/transit fiasco (requiring extra support from all editors) Mateusz Konieczny (talk) 10:57, 27 January 2021 (UTC)
- Sorry Mateusz, but I don't understand what you mean. Please, open a topic in the discussion page to explain it better. AntMadeira (talk)
- Done some time ago Mateusz Konieczny (talk) 12:39, 17 February 2021 (UTC)
- Sorry Mateusz, but I don't understand what you mean. Please, open a topic in the discussion page to explain it better. AntMadeira (talk)
- It can be solved by one extra way split. Otherwise it is doomed to Proposed features/transit fiasco (requiring extra support from all editors) Mateusz Konieczny (talk) 10:57, 27 January 2021 (UTC)
- That won't work in dense city environments - the next lane with wait tags might start right after the first one ended. --Mueschel (talk)
- I oppose this proposal. Critical issues as in Talk:Proposed_features/wait#Point-like_features_should_not_be_tagged_on_ways not addressed. This dissociates necessary information from the location-relevant
highway=*feature. -- Kovposch (talk) 07:20, 27 January 2021 (UTC)
- To be more specific, there was response but you and proposal author disagreed whatever such info should be mapped on nodes or on ways Mateusz Konieczny (talk) 07:47, 27 January 2021 (UTC)
- I oppose this proposal. I don't think the issues raised on the discussion page have been addressed. I still don't understand why there is a need for a new tag - we already have means to add give-way signs and traffic lights. All it needs is a proper definition how ":lanes" can work on nodes (which is possible, see backward/forward and direction used on nodes). In addition, as Kovposch wrote, what does it mean if a long way has a "wait=traffic_signals" tag? That's not important for most of this way as long as you don't pass through the actual traffic light node (or there is a traffic jam 24/7 which is not the type of information we have in OSM). --Mueschel (talk) 10:32, 27 January 2021 (UTC)
- As I had the chance to mention in the discussion page, unless you change the
lanes:scheme to accept that key on points, I don't understand why we should go against that. No proposal can propose what you're suggesting without going against what's approved in thelanes:wiki. Why would someone use the "wait=traffic_signals" tag on a way? AntMadeira (talk)
- As I had the chance to mention in the discussion page, unless you change the
- I oppose this proposal. This proposal doesn't specify how the new tagging scheme would interact with and use existing
highway=traffic_signals,highway=stopandhighway=give_waynodes. This is an absolute requirement. The discussed idea (which is not documented in the proposal) of having the wait tag apply to the last way in a series of ways with the same tagging is very error prone and may require splitting ways for no other reason than breaking the chain of ways with similar tags if two or more stop/wait/... lines are in close proximity to each other. Like others already mentioned, this is a property of points and not stretches of ways and should be tagged as such. --Woazboat (talk) 11:13, 27 January 2021 (UTC)
- The interaction issue is a limitation that can't be solved without a relation. This proposal had the intention of avoiding the use of relations in these kind of cases and keep it the simpliest possible. It doesn't substitute the existing
highway=traffic_signals,highway=stopandhighway=give_waynodes, it just tries to convey some kind of information to inform routers that a certain lane is going to encounter one of those nodes. Maybe we should propose different values from those well established tags, but I guess that wouldn't solve the interaction problem. AntMadeira (talk)
- The interaction issue is a limitation that can't be solved without a relation. This proposal had the intention of avoiding the use of relations in these kind of cases and keep it the simpliest possible. It doesn't substitute the existing
- I oppose this proposal. Same reasons as Woazboat. I am not convinced by the scheme’s documentation so far and don’t feel this kind of information would be super useful for routing purpose. --Lejun (talk) 15:16, 27 January 2021 (UTC)
- I approve this proposal. --Something B (talk) 13:49, 4 February 2021 (UTC)
- I oppose this proposal. Quite simply, I am terribly confused by this proposal, even after having read it several times. I'm sorry I can't give a more helpful reason here. I wouldn't know when to use this tagging in the real world based on the descriptions provided. --ZeLonewolf (talk) 13:37, 6 February 2021 (UTC)
- Imagine you have a one-way road with 3 lanes. You arrive at a junction and you have a stop sign for the left lane and a give_way sign for the centre and right lanes. How do you map that? --AntMadeira (talk) 17:27, 6 February 2021 (UTC)
- Okay, I think I understand what you're trying to do here. So you're not actually proposing the key
wait=*at all, you're introducing four keyswait:lanes:forward=*,wait:forward=*,wait:lanes:backward=*, andwait:backward=*? I think? Is there any occasion when you would usewait=*by itself? This whole writeup seems to assume a whole lot of prior knowledge about other schemes, and it would be really helpful to the wider audience to understand if things were spelled out very plainly for the next go-around and really dig into how it intersects with other aspects of traffic routing described in some of the no votes above. --ZeLonewolf (talk) 00:57, 7 February 2021 (UTC)- Please, re-read the proposal carefully. Everything is explained. The key wait is proposed for the lanes scheme, as it is stated in the proposal. You need to understand the lanes scheme and its prefixes (like turn, maxspeed, destination, etc.) to understand this proposal. Anyway, I don't know how someone can vote "no" for something that he/she doesn't understand. I think that's rude and disrespectful, but anyway, it won't change anything really. --AntMadeira (talk) 05:24, 8 February 2021 (UTC)
- Proposals turn into documentation, and I don't feel that what is documented here is adequate for an ordinary mapper to understand how to use the tagging. So yes, I am voting that this proposal is not understandable enough to make an informed decision on. I am willing to say "this is not understandable" while other OSMers who are not willing to put their words down are likely looking at the proposal and saying "this is too confusing so I won't vote". The objections raised by others only reinforce that we don't seems to be looking at a complete picture here of the proposed tagging. I'm sorry you find this rude, but that is my impression and feedback. --ZeLonewolf (talk) 06:01, 8 February 2021 (UTC)
- Maybe this is not the best of proposals. I acknowledge it makes the assumption that mappers know the other schemes, specially the
lanes:scheme. Because of that, it can be a bit confusing for those who are not familiar with it. I respect your opinion, I just don't think this is the place for it. The proposal had more than two months of discussions, plus the time on the tagging list and no one complained that it wasn't understandable. Anyway, this isn't the place to discuss this either. Feel free to leave your comments on the discussion page (or read it again). Your points can be useful if another proposal ever come to light. --AntMadeira (talk) 06:26, 8 February 2021 (UTC)
- Maybe this is not the best of proposals. I acknowledge it makes the assumption that mappers know the other schemes, specially the
- Proposals turn into documentation, and I don't feel that what is documented here is adequate for an ordinary mapper to understand how to use the tagging. So yes, I am voting that this proposal is not understandable enough to make an informed decision on. I am willing to say "this is not understandable" while other OSMers who are not willing to put their words down are likely looking at the proposal and saying "this is too confusing so I won't vote". The objections raised by others only reinforce that we don't seems to be looking at a complete picture here of the proposed tagging. I'm sorry you find this rude, but that is my impression and feedback. --ZeLonewolf (talk) 06:01, 8 February 2021 (UTC)
- Please, re-read the proposal carefully. Everything is explained. The key wait is proposed for the lanes scheme, as it is stated in the proposal. You need to understand the lanes scheme and its prefixes (like turn, maxspeed, destination, etc.) to understand this proposal. Anyway, I don't know how someone can vote "no" for something that he/she doesn't understand. I think that's rude and disrespectful, but anyway, it won't change anything really. --AntMadeira (talk) 05:24, 8 February 2021 (UTC)
- Okay, I think I understand what you're trying to do here. So you're not actually proposing the key
- Imagine you have a one-way road with 3 lanes. You arrive at a junction and you have a stop sign for the left lane and a give_way sign for the centre and right lanes. How do you map that? --AntMadeira (talk) 17:27, 6 February 2021 (UTC)
- I approve this proposal. --EneaSuper (talk) 11:55, 7 February 2021 (UTC)
- I oppose this proposal. I agree with other responses that this would be better suited on a node. Or adapting the highway:stop tags to work with lanes. --Blackboxlogic (talk) 13:15, 7 February 2021 (UTC)
- There's a logic behind the lanes scheme not being applied to nodes. Why does this proposal should distort that logic? A lane implies extension, a beginning and an end, something a node clearly doesn't have. This was discussed and explained in the discussion page. --AntMadeira (talk) 05:29, 8 February 2021 (UTC)
- I keep hearing references to "beginning" and "end", but I don't see how "wait" can possibly be meaningful regarding a range. It's something the router should know happens at a spot. Hearing "this is the beginning of where you're going to wait at the end" doesn't compute for me. It would be like tagging an entire road with the information "there is a stop sign at the end of this road" versus just putting a stop sign at the end of the road. When you say "There's a logic behind the lanes scheme not being applied to nodes", maybe that's what I'm missing? Could you point me to a discussion, or more info, or an example, or a contradiction this would cause, or an ambiguity? "This was discussed and explained in the discussion page" yeah, I saw that and I became more firm in my opinion. --Blackboxlogic (talk) 14:06, 9 February 2021 (UTC)
- How would you use points on the two first examples? In the middle of the road? And what about the third example? With two points over the way? --AntMadeira (talk) 15:34, 10 February 2021 (UTC)
- I approve this proposal. --Adiatmad (talk) 05:15, 8 February 2021 (UTC)
- I oppose this proposal. Sorry for coming in late, but I would prefer none to be replaced by "nothing" (like this : "||"), like in turn:lanes. And this information seems more suitable on nodes. --Gileri (talk) 09:45, 8 February 2021 (UTC)
- Please, read my answer to @Blackboxlogic:. And none is the value used in the lanes scheme, although you can also use the other alternative, which is "nothing". The first option is more understandable and preferable. Please, see turn values. --AntMadeira (talk) 16:01, 8 February 2021 (UTC)
- I oppose this proposal. I like the principal idea, but the application is clearly at nodes rather than on ways. Augmenting signage tagging to better handle lanes is preferable. The potential for confusing tagging is high here: for instance, when working at an intersection, one would tag the connecting way to indicate the function of each lane, but that tagging would "propagate" along the length of the way, making it confusing for someone utilizing/editing/navigating on that way (potentially) many [miles/kilometers] away. --JOlshefsky (talk) 12:35, 10 February 2021 (UTC)
- How would you use points on the two first examples? In the middle of the road? And what about the third example? With two points over the way? --AntMadeira (talk) 15:34, 10 February 2021 (UTC)