Talk:Tag:highway=stop

Discussion

highway=* page says that this key is to be applied to nodes - so probably on the crossing nodes. but how is it supposed to be shown which road has it and in which direction ? --Richlv 13:59, 2 September 2008 (UTC)

I was wondering about the same question. Did you find a solution to this problem? Maybe it can be done with a relation?!? --Hampelratte 17:31, 11 September 2008 (CEST)

What about highway=stop:nsew? This would be an indication as to which direction(s) the stop sign is on. This example would indicate a four-way stop. Any combination of the directions could be applied. highway=stop:all would also indicate an all-way stop. — Val42 00:16, 4 October 2008 (UTC)

And for a five way intersection what would you enter as the value? Alv 12:29, 4 October 2008 (UTC)

Good question. However, without an indication as to which streets have stop (or yield) signs, then it wouldn't be as useful. At least around here, most intersections that don't have semaphores have stop signs. How would you propose tagging which streets have stop (or yield) signs? — Val42 07:30, 7 October 2008 (UTC)

I've been adding adding a node on each incoming road at the position of the stop sign (or, actually, traffic_lights). It's more work and more nodes but likely unnoticeable addition to data quantity. Some kind of relation could be used to bind them to the correct intersection, but almost always the nearest intersection node is the correct one. And once one starts to add cycleways as separate ways I think it becomes "necessary" to have the traffic lights on nodes on or before the crossings with the cycleways. Alv 08:12, 7 October 2008 (UTC)

What about marking the way instead of the node, e.g. highway=stop:at_end if there is a stop sign at the end of the way or highway=stop:at_start or highway=stop:at_both? This would give us a clear assignment of a stop sign to a highway without extra nodes. No matter, how many roads end at an intersection. The only disadvantage, that I see here, is extra attention needed, when splitting a way (otherwise duplicate stop sign in the middle of the way at the split position). --Wanderer 20:39, 29 October 2008 (UTC)

I think highway=stop is like Relation:restriction in this case. Also see Proposed_features/Set_of_Traffic_Signals for relations regarding junctions. -- MapFlea 13:47, 10 November 2008 (UTC)

I think the best way to flexibly model stop signs is with a relation. The relation should have two members, exactly one node, and exactly one way. If the node is at the endpoint of the way, then it unambiguously denotes that there is a stop sign where the selected way enters the junction containing the selected node. If the node is not a endpoint of the way, then the relation should be labeled as "forward", "backward", or "both" depending on whether there is a stop in one or both directions. This scheme can easily be applied to four-way stops, two-way stops, intersections with one-way streets, T-intersections, intersections between side streets and dual carriageways, and complicated intersections with more than four ways. This scheme also doesn't require the splitting of ways. -- Icycle 17:38, 2 December 2008 (UTC)

It looks like I've kicked off some discussion, hopefully on the path to a real solution. To me, it sounds like either proposal would be adequate to meet the need to documenting stop signs at a wide variety of intersection types. Personally, I find the way + node specification more intuitive than the 2 node specification, since to me at least, the natural components of a stop sign are the road the stop sign appears on, and the intersection it appears at, which maps pretty naturally to a way and a node. The two node specification specifies the road, but only implicitly, rather than directly. And it is entirely possible that the "from" node could be quite some distance away from the junction, whereas in way + node specification, both the way and the node will be quite naturally adjacent to the location of the stop sign.

Neither proposal requires splitting of ways, which is nice.

For the way + node specification, the directionality of the way can matter in the general case, but in the common case where the way traverses the junction and there is a stop sign on both sides of the junction, or where the way ends at the junction, then the directionality of the way does not matter.

One potential problem with the two nodes specification is that if the "from" node happens to be a "non-critical" node, and gets deleted, that could leave the stop sign in an undefined state. On the other hand, for the way + node specification, you can't delete either the way or the node without radically altering the intersection the stop sign appears at, which makes is less likely that the stop sign relation could be accidentally underspecified by deletion.

Both proposals are potentially subject to "over-specification" where someone accidentally adds more than two nodes or one node and one way to a relation, rendering the proper interpretation of the stop sign ambiguous.

Another interesting difference is the two nodes schema requires one relation per stop sign, but the way + node schema can specify two stop signs with a single relation.

I have submitted my way+node stop relation as a formal proposal here Proposed_features/Relation:type=stop -- Icycle 02:31, 3 December 2008 (UTC)

Here is a more formal description of my suggestion for Relation:stop. Should this be generalized to encompass both yield signs and stop signs? -- Icycle 18:55, 2 December 2008 (UTC)

Tags

Key	Value	Discussion
type	stop

Members

Way or Node	Role	Recurrence?	Discussion
	forward / backward / both	one	the way to which the stop sign applies. The implied default role is "both", unless the way is oneway or the associated node is an endpoint of the way.
		one	the junction at which the stop sign applies.

Suggestion: Allow the way to occur several times, then only one relation is needed for one crossing. The editor (e.g. JOSM) should take care about splitting the way. --Tweller 10:34, 30 December 2008 (UTC)

Alternative proposal

Perhaps it would be easier to use two nodes (after all, roads shouldn't be overlapping, so there is no need to specify the way). Then the direction of the way does not matter and no way splitting is required. Make one of the nodes have the role "from" and the other "to". Andrewpmk 02:02, 3 December 2008 (UTC)

In case of a 4-way crossing I then need to have 3 relations for only one source direction: 1. stop for going left, 2. stop for going straight ahead, 3. stop for going right. With the original proposal I only have one relation: 1. stop when coming from this street. The original proposal seems more like it is in real world. --Tweller 10:25, 30 December 2008 (UTC)

Tags

Key	Value	Discussion
type	stop

Members

Way or Node	Role	Recurrence?	Discussion
	from	one	a node on the way to which the stop sign applies, in front of the stop sign.
	to	one	the junction at which the stop sign applies.

Simpler

Is there anything wrong with using cardinal directions? N, E, S, and W? highway=stop and stop=N;S indicates two stop signs on the road going north and south. If needed, use NE, SE, SW, NE, and if needed on a complicated intersection, NNE, ENE, ESE, etc...

This can be confusing for rendering software, routing software, and for users. --Skippern 21:01, 4 October 2009 (UTC)

And you're suggesting that the other alternatives are less confusing? Anything which looks at the node can see that it's a stop, can calculate the cardinal direction of the ways approaching it, and pick from the list. I don't think this scheme will stand the test of time, but until a better system is created, this is how *I* will be tagging stop signs, and I encourage other people to tag them this way as well. Once somebody comes up with a better scheme, instances of this one can be converted into that one. --RussNelson 21:13, 4 October 2009 (UTC)

I've used Key:stop since the beginning of the month and haven't found any cases for which it doesn't work. --RussNelson 02:26, 28 October 2009 (UTC)

Even more simpler

Add a node tagged highway=stop on the highway road itself at the level of the stop sign in the real world, usually very closed to the intersection point.

This is the simpliest method as it does not need to add relations or any complex tagging just to help software applications to resolve what a baby is able to determin: the stop sign applies to the nearest intersection point. And to define what is the nearest, we just use the lat/lon positions of the elements. -- Pieren 12:48, 28 October 2009 (UTC)

The reason I suggest tagging the intersection and using stop=N;E;S;W is because when you fetch the way, you also fetch the intersection. --RussNelson 16:08, 28 October 2009 (UTC)

Strange, actually, that it hasn't been described as such with the valuedescription template. Discussion would then be moved to the Talk:Tag:highway=stop page. I'll get to it someday unless someone is faster. Alv 13:06, 28 October 2009 (UTC)

Driving direction

For routing software, we can't assume that the intelligence of a baby is anywhere in reach. In the graphic here, the blue circles are stop signs and a 4-way stop is depicted. Each way is 2-way and undivided, which is typically composed by human editors as a single way rather than a way for each lane. If you are driving in any direction, you encounter a stop sign twice when traversing the intersection. There is no indication of which way the sign is facing or which direction of travel is impacted. One could use an interpretation rule like "ignore a stop sign if it comes in position three of a trio of nodes 'stop', 'intersection', 'stop' when the total distance between nodes is less than 50 yards", but that isn't really a practically generalizable thing unless the distance were scaled differently between highway=residential, highway=trunk and highway=footway. I have used the 'stop node on way' method before, but I don't think it is a general solution unless you are working with one-way routes (or mapping of lanes) ... then it works beautifully. --Ceyockey 04:06, 21 July 2011 (BST)

Why not use Relation:restriction?

It seems to me that mapping the physical location of stop signs is useless and ambiguous pre-relation trivia, just like we don't map the physical location of turn restriction signs we shouldn't waste effort on mapping where stop signs are.

Of course some people are mapping the location on the road at which you're supposed to stop and the proposal above suggests a new relation to model that.

But why not simply use the restriction relation? instead with a restriction=stop key? Or would that be more confusing than helpful? --Ævar Arnfjörð Bjarmason 14:32, 28 October 2009 (UTC)

Because the current support for relations in editors is difficult and confusing for people to use. I'm not proposing stop=N;E;S;W as a permanent standard, merely as one that doesn't get in the way of editing as relations do now, and which can be turned into a relation later. I'm tagging this way now and it's very easy to do. If you think your method is better, could you write a tutorial on how to use it? --RussNelson 16:08, 28 October 2009 (UTC)

For a four-way stop you would need 4 relations, one for each direction of travel, wouldn't you? --Ceyockey 04:08, 21 July 2011 (BST)

I don't think so - that could be done in one relation with the intersection and the ways approaching the intersection that have a stop sign as members. If it's not an all-way stop, leave out the ways that don't have stop signs. Martijn van Exel 20:31, 2 January 2012 (UTC)

(after not thinking about this for 6 months, let's take another stab) I think the trick with using a variant on the restriction relation isn't, as I at first thought, the need for multiple relations; there are plenty of junctions that require 6 or more restriction relations to model effectively. I think the issue might be the need to model a transient stop. For the restriction relations, they are all "for all time" except where time delimited to certain days or hours; but even when delimited, the restrictions are not transient during the period but rather continuously in force. I think we would need to be able to model the pause which a stop sign represents. By the same token, one could use restriction relations for traffic lights if one were able to model conditional restrictions. I'm not opposed to these things; I think it would be useful to increase the flexibility of the relations to cover the transient and conditional states. --Ceyockey 22:40, 2 January 2012 (UTC)

Take a look at my 3 ideas.

I think I came to something easy to understand and to do in the maps.

I don't know exactly how the relations work, but I thought of something like this:

Solution 1:

Think of the intersections. There are two ways (for example), and an intersection node. We could add a node before the intersection on each way (on both sides, so four nodes), then add something on the intersection node that would mean "stop_when_from_node:01;03". Automatically, the other nodes would create the opposite: "pass_when_from_node:02;04".

Solution 2:

We could add a relation between way and intersection node, like this: highway=pass_at_node:(# of the intersection node) highway=stop_at_node:(# of the intersection node)

Solution 3:

On the same place we choose turn restrictions, we could add the following, using street names/references: Restriction: First Street - Stops for - Second Street. This works for as many roads as you want, because you could add First, Second, Third and Fourth Streets to Stop For Fifth Street.

I think the intersection must be considered the own stop sign. --ClebersonPRT 23:50, 3 April 2012 (BST)

Would it be too complicated for software to determine which intersection is closest to a stop node, and then indicate a stop only when traveling from the stop node to the intersection node, and not vice versa? This may be the same as idea #1 above; I am not sure. --Eliyak 03:29, 4 April 2012 (BST)

stop=forward/backward/both/all proposal

Here is a proposal for a very simple model:

• use highway=stop on each node where there is a stop sign
• use stop=forward/backward to tell in which direction the sign applies on the way
• in case of 4-ways stops, a single node at the crossing could hold highway=stop + stop=all
• in case of oneway streets, the stop=* is not needed

This avoid using relations which are difficult to understand for many contributors, and hard to deal with in basic editors. It also make things quite simple for data consumers. Cquest (talk) 15:43, 15 August 2013 (UTC)

I like this approach that avoids the usage of relations. However, I would prefer to leave room for future extensions of highway=stop and would therefore recommend to re-use and extend the concept of traffic_signals:direction=*. The values "all" and "both" are optional, they contain redundant information. So, how about using stop:direction=forward/backward? --Biff (talk) 21:18, 3 January 2014 (UTC)

I second the use of stop:direction=forward/backward instead of just direction=forward/backward. I suggest also doing the same for give_way. --Fearsyth (talk) 18:34, 25 January 2019 (UTC)

Thinking about what the _indicator_ for stopping is

There are at least two common indicators of a stop restriction in the United States: most commonly a red sign, less commonly a pavement painting. In both cases, there is typically, but not always, a pavement line indicating the farthest point at which the stop should take place. In the case of the pavement painting stop, the word "stop" is painted on the pavement and a sign is not erected. Now, with tag:highway=crossing, the tag:crossing_ref=* is used to indicate the type of crossing marking available, the most common value (without actually looking to see if this is true) being "zebra". Should we use a similar construct like "tag:stop_ref=*" where the most common value would be "sign" and the (perhaps) second would be "pavement" or "pavement marking"? Thsnks for your thoughts. Regards --Ceyockey 01:26, 1 December 2012 (UTC)

Just to note: The last I checked, the current law here (Missouri, USA) is to stop before the painted crosswalk. If there is no crosswalk, then stop before the painted stop line. If there is both, stop before the first. If the first was a crosswalk, you can roll forward to the stop line and stop again (rare, usually the stop line is first). If there is neither, stop before entering the intersection. The position of the stop sign has no importance in where to stop. --Fearsyth (talk) 18:39, 25 January 2019 (UTC)

Tag priority road on the ways

Hi, the initial idea with the tag priority_road=* was to identify the very roads that do have the "this has priority" signs. In the countries I've driven in, that's only a small subset of roads even if others roads might be even completely "protected" from side road traffic by them having yield or stop signs. It would be a shame if mappers in these countries were to start using priority_road=yes_unposted on other roads that just happen to have priority over the side roads in the next intersection. (The priority road signs even imply a parking prohibition on the carriageway, where signposted outside urban areas - other roads that just happen to have priority in all or most intersections don't have that.) Where the priority road signs are never used, this is of course not an issue, but makes processing more dependent on cutting the data first for each and every country. IMO the unposted "this has priority at the next intersection" would best use some other key. How could this be said nicely on Tag:highway=stop? Alv (talk) 21:38, 23 January 2014 (UTC)

Suggestion based on the wheelchair-routing kerb tagging scheme

It's not _very_ documented but wheelchair routing tagging for kerb height have a pretty useful tagging which is easy to apply to stop and give_way.

Every road is a vector, so they always have a start and an end node. They tag kerb:start=* (height in meters, btw) as the kerb at the starting node and kerb:end=* on the ending node. This may be analogous with the signs at the ends of a road. (Similar tagging for implicite sidewalks is sidewalk:left:kerb:start=*.)

This could be used as stop:start=yes and give_way:end=yes. No need to create additional nodes, using compass or similar. Only thing is to take care when splitting and joining roads (this is a con, yes). --grin ✎ 06:34, 13 October 2014 (UTC)

collection of notes

Scenarios

Case	Description	Existing solution(s)	Suggested solution(s)	Reasoning
All-way stop	Junction where all traffic stops	highway=stop	use existing
Mid-road stop	A one- or two-way stop sign not by a junction	highway=stop, with direction=* if only one direction of traffic stops	use existing; for complex one-way, type=stop relation with incoming/stopping way as member with "from" or no role, and stopping-point node with no role (and stop-node tagged with highway=stop if programs which won't recognize this relation should interpret it as a two-way stop instead of no stop)
Minor-road stop	Only traffic arriving from the smaller roads stop	node off junction tagged with highway=stop; stop=minor with highway=stop (see Key:stop#Way_tagging_scheme); highway=priority; priority_road=*	type=stop relation, with stopping/minor way(s) with "from" or no role and junction with blank role; priority_road=* in localities where signed
3-way 1-stop	A three-way junction/intersection where only one traffic approaching from one direction/way stops	node off junction tagged with highway=stop and direction=*; highway=stop and stop=a cardinal direction (see Key:stop#Way_tagging_scheme)	type=stop with stopping way as member with "from" or no role, and junction as member with no role	highway=stop and direction=* does not make sense for localities where there is not an exact location to stop at by a junction; highway=stop and stop=a-cardinal-direction does not make sense for junctions with roads approaching from non-cardinal directions
3-way 2-stop	3-way junction; 2 ways have to stop. The roads here would not be minor/major, but all the same class (or a similar setup)	(see earlier existing solutions)	type=stop relation with both stopping ways members with "from" or no role, and junction node as a member
1-way except	A junction where incoming traffic from a way stops, but not when going to some of the way(s) (see [1])	?	type=stop relation with stopping way as member with "from" or no role, junction as member, and outgoing ways for which traffic does stop as members with "to" role	by default, in the type=stop relation, all outgoing traffic from that junction should stop; this should only be made into the opposite (no outgoing traffic stops besides to the way members with "to" role) if one or more members have the "to" role

type=stop - adapted from Proposed_features/Relation:type=stop

Way or Node	Role	Recurrence?	Discussion
	(none) or "from"	zero or more	the way(s) to which the stop sign applies (or to all ways at the node if none). This may be a multi-way stop when there is one "from" way and the node is in the middle of it. If the node is not on/part-of the way, then it is considered as if not a member.
	(none) or via	one	the junction at which the stop sign applies, or the stopping location if not at a junction
	to	zero or more	the destination way(s) to which the stop sign applies. If none, the sign applies to all the (road)ways of that junction node.

Complex intersections may need multiple stop relations/tags, for example when a way is a "from" for one stop-sign and a "to" for another.

tags

Key	Value	Discussion
type	stop
except, restriction:(vehicle-type), day_on, day_off, hour_on, hour_off	(vehicle-type)	see these tags at Relation:restriction
restriction:(vehicle-type)	see this tag at Relation:restriction

notes

• Directions of stoppers - The specified method of tagging a stop sign for a single direction is highway=stop together with direction=forward. This is good for a stop sign which is not at a junction; by a junction, however, it is likely more useful to tag the fact that there is a stop sign for the junction from a certain direction, than tagging exactly the point where the sign is (since not all that is not necessarily the point to stop at; the sign itself can be tagged on its own using traffic_sign=*). This may be solved, by tagging the junction node.
• Incoming stoppers - The incoming roads which stop at a junction have to be specified if not all of them have a stop-sign. There is a method of representing these using cardinal directions; however, as mentioned at the end of this section, this is not always practicable. This may be solved by tagging the incoming way(s).
• Outgoing stoppers - Occasionaly there is a stop at a junction where traffic going to a certain outgoing road from the junction does not need to stop. (see for example [2]). This may be solved, by tagging the outgoing ways.

Abbafei (talk) 09:32, 24 October 2014 (UTC)

Stop applying only in a particular lane / when making a specific turn?

How should you map a stop at an intersection which applies only when turning from A to B in lane 3? See https://www.mapillary.com/app/?lat=-33.80486691666667&lng=151.1806786944444&z=17&pKey=mKmjaGwEKe9us4dXlWz1rw&x=0.2981776834038572&y=0.6252122584238203&zoom=0&focus=photo Aharvey (talk) 00:03, 29 August 2017 (UTC)

I would split this 5-lanes bidirectional way, using a short one-way 1-lane central highway segments before the crossing (putting the stop near the end of this segment), and two short one-way 2-lanes highway segments in opposite direction on each side.

After all the vehicles that are stopping on the central lane are an abstacle between the two opposite lanes, and there's even a continuous line "protecting" the central line that prohibits changing from one lane to another, and even a physical obstacle in front of this turning lane, so other vehicules must drive on the external one-way lanes if they don't turn.

As this central lane will be one-way, there's also no need to specify a direction for the stop node you put on it, just before the point crossing with the parallel lane coming from the opposite direction.

 ——————————————————————————————————————————————————————————___  
 →   →   →   →   →   →   →   →   →   →   →   →   →   →   →    ————
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ˍ →   →
 →   →   →   →   →   →   →   →   →   →   →   →   →   →   →   ¯ - -
 - - - - - - - - - - - —————————————▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄    →   →
 →   →   →   →   →   ↴   ↴   ↴   ◥█░░░░░ISLAND░░░░▄▄▄██▀▀▀▀━━━———
 ——━━━▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄━━━—————STOP———▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    ←   ←   ←
 ←   ←   ← ▀▀▀▀▀     |             |  ←  ←   ←   ←   ←     ˍ - - - 
 - - - ˍ ˍ   ←   ←   |    KEEP     - - - - - - - - - - - ¯   ←   ←
 ←   ←   ← ¯ ¯ - - - -    CLEAR    |  ←  ←   ←   ←   ←   ←   _____  
 ———_____    ←   ←   |    AREA    /- - - - - ___—————————————     
         ——————_____ ˍ ˍ ˍ ˍ          ↙___———
                    \   \   \      ————
                     | ↰ | ↰ | ↓  /
                     |   ¦   |   |
                     | ↰ ¦ ↰ | ↓ |

— Verdy_p ^(talk) 13:48, 28 August 2017 (UTC)

Wow great diagram! Thanks for the suggestion, using a separate way would make it easy, but I'm uncertain about doing that as I thought it should only mapped as separate ways if there is a physical separation. There is that island but it would end at the intersection. Other downsides is routers start to think that you can do a uturn here if there is a way for the turn because it looks like two right turns rather than a u turn. Aharvey (talk) 00:03, 29 August 2017 (UTC)

If you want to apply u-turn restrictions, you can still do that... if it is effective. On the photos, there's NO clear indication that you are not allowed to do that using the central lane, passing the STOP and then continue turning right through the "Keep clear area": I think it is allowed.

However there's an effective separation of lanes with continuous lines and with a restricted zone between the two directions before the stop: this efefctively changes the profiles of lanes and goes in favor of their separation (which is typical here for what is marked as a "motorway" here in Australia, even if it has some crossings. Separating the one-way lanes will efffectively restrict all uturns, except at crossings like this one, will ease navigation without ambiguity (including with vocal indications about which lanes to take or merge into), and will also render better at high zoom levels (don't also forget to set the number of lanes for each direction). — Verdy_p ^(talk) 10:57, 29 August 2017 (UTC)

You can't use a no u-turn relation since as you say there is no signage restricting it so it's allowed. But mapped as a node, routers see it as a uturn and try to avoid it as much as possible but mapped as a separate way routers see it as just two right turns which is something they will route you over much easier, but doesn't reflect what it really is, uturn.

The other way I see this could be done without using dual carriage ways is simply add a stop sign on the south street just off the node and add a direction to it. Ideally it would before the intersection not after but I feel this is better than making this dual carriage way when there is no physical separation. Aharvey (talk) 21:53, 29 August 2017 (UTC)

But THERE IS a separation (more than just a straight line). An I don't see where you would put a stop on the branch going to the south: it would mean that vehicles coming from the East would also have to stop before taking that way to the south by turning left (and this is not the case: this is clear on the photo, or the diagram above: they can turn directly and this is even facilitated for them and observe there no transversal line asking them to even give way as they have priority, to those that would come from the west and that MUST stop to give the way to all vehicles coming in front of them to get to the same street to the south).

Yes there's no restriction for vehicles coming from the west where they turn right just at the stop, that forbids them to get back to the west (and it is easy for them by continuing turning right to use the most external lane on the south side): yes this will be a second turn to the right, but the "keep clear" area makes it relatively easy and safe for them.

For vehicles coming from the east however, they can't "uturn" at all as they have the physical separation of the island and the continuous line blocking them to get into the oneway central lane through its final stop, so they can't turn twice to the right. — Verdy_p ^(talk) 00:44, 30 August 2017 (UTC)

Oh shoot you're right, I can't just add the node on the south way.

Re uturns. What's legal/indicated is one thing, but without it being mapped with dual ways routers know that it's a uturn and people who choose to avoid uturns can avoid being routed that way. If mapped as dual ways, it looks like two right turns (which it's not) and hence routers don't know that it's actually a uturn not two right turns. Admitidly this is an issue for other roads mapped as dual ways, routers see uturns as two right turns when really they are uturns. So I'm confident the solution here is more tagging on the link way rather than just avoiding dual ways.

Although https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Divided_highways only says physically seperate lanes should be mapped as divided highways, and it never says the converse that divided ways should only ever be due to physical separation.

So I guess that's the solution here, I dare not ask what to do if there is no separation? Aharvey (talk) 07:54, 30 August 2017 (UTC)

What if there's only one lane in each direction, but the stop still only applies to only one maneuver and not the other? At this intersection, there's a stop sign with an "except right turn" plaque beneath it. This is a standard sign that often occurs on rural township roads in the U.S. – Minh Nguyễn ^💬 06:14, 11 July 2019 (UTC)

@Aharvey: I've started using maneuver relations in the case where stopping is dependent on the maneuver made, though a stop dependent on the lane used would probably be a better fit for a connectivity relation. – Minh Nguyễn ^💬 22:59, 16 July 2019 (UTC)

I've been thinking about this a lot, because there's a huge number of situations like this in Portugal. I've even opened a topic in OSM forum here but got no conclusive answer. There's also an alternative suggestion given in OSM Telegram channel that uses relations, but there's no consensus about which type of relation to use and I think it's unecessarily complex. What if we created a key like stop_lane and guiveway_lane? That way, we could always assign a stop or giveway sign to the correct lane. In this example it could be something like this
lanes=3;
lanes:forward=1;
lanes:backward=2;
turn:lanes:backward=left|through;
stop_lane:backward=yes|none

--AntMadeira (talk) 19:15, 8 July 2020 (UTC)

I don't see why you need a new key. stop:lanes=*, give_way:lanes=*, traffic_signals:lanes=* would work. (reason of not using a highway:lanes=* is these traffic control methods can co-exist at one point, and highway=* is an important feature) -- Kovposch (talk) 07:31, 9 July 2020 (UTC)

One of the answers I got from the mailing list is that this approach doesn't have a proper logic, because points don't have lanes, which I think makes sense. On the other hand, you already have maxspeed:lanes=* and minspeed:lanes=*, although you could argue you're not tagging a traffic_signal but a feature of the highway. I was just trying to following the same logic here. Instead of attributing lanes to a stop sign, I would attribute lanes to a feature of a highway, which is you have to stop on that lane (or giveway), much like you have a speed-limit on a stretch of a highway. --AntMadeira (talk) 19:29, 9 July 2020 (UTC)

They aren't limited to points. You can put these tags on lines as well (for instance I could imagine lane control signals being tagged with traffic_signals:lanes=*). The problem with not putting on the yield or stop line is it will make that tagged point pretty useless and misleading, with poor compatability and more complicated interpretation. The points are already defined as something on the lines of roads, so this appears to be correct iterative refining. -- Kovposch (talk) 10:06, 10 July 2020 (UTC)

Sorry, but you misread my previous text. I didn't say it's limited to points, but that point's don't have lanes. --AntMadeira (talk) 19:36, 10 July 2020 (UTC)

"The points are already defined as something on the lines of roads, so this appears to be correct iterative refining" And I mean you can use these tags on lines as well. -- Kovposch (talk) 11:56, 11 July 2020 (UTC)

Lanes are not used on points, so the lanes sufix can't and should not be used with points. That's based on this that I'm proposing a new key to indicate that a specific lane is a stop lane or a giveway lane. Other than that, the alternative is using a relation, which I would like to avoid for simplicity reasons.

Ok I assume you have no major issue with my suggestion on putting stop:lanes=*, give_way:lanes=*, traffic_signals:lanes=* on lines. So you have no other reason other than this? By your logic, should left/right and forward/bacward not be defined on points? -- Kovposch (talk) 10:38, 12 July 2020 (UTC)

It's not my logic, it's OSM logic. You can't apply lanes sufix to a point, no matter where you put it. Once again, only lines/ways have lanes. Unless you change the wiki with a new proposal for the lanes suffix, I don't see a reason to force something that can be done with other alternatives. Forward/backward and left/right are different, because you can argue that when applied to points it indicates the direction where the point faces to, the same way you apply right/left to a highway to indicate it has a sidewalk. It becomes a semantics issue, not practical. --AntMadeira (talk) 19:48, 12 July 2020 (UTC)

"when applied to points it indicates the direction where the point faces to" If a point can be shown to apply to one side, why can't the same be done over the cross-section of the road? It's still a feature spanning over each lane. -- Kovposch (talk) 07:55, 13 July 2020 (UTC)

A proposal has been created to address this Proposed features/wait. --Aharvey (talk) 01:26, 28 December 2020 (UTC)

All-way stop with flashing beacon

@CBRS: This change advocates highway=traffic_signals traffic_signals=stop instead of highway=stop when there is a flashing intersection control beacon above the stop signs at an all-way stop. I've temporarily removed the recommendation pending further discussion, because this is not the predominant usage in the database. Of the 520 nodes tagged traffic_signals=stop, only 71 are tagged highway=traffic_signals while 440 are tagged highway=stop.

Aside from current usage, I'm concerned that the proposed preference for highway=traffic_signals places too much emphasis on the intersection control beacon, which in reality merely reinforces the stop signs rather than replacing them. The beacon doesn't change the fact that a driver must stop at a stop sign and give right of way to anyone who came first before proceeding through the intersection. Therefore, a router shouldn't have to process the intersection any differently than one without a beacon. The risk is that a router that doesn't know about traffic_signals=stop (which would be all of them at this point) would treat the intersection as having a three-phase traffic light and penalize accordingly. I also think this use of highway=traffic_signals is misleading to renderers, which would naturally use a three-phase traffic light icon to represent highway=traffic_signals, whereas the beacon only has a passing resemblance to a traffic light.

I think the predominant usage with highway=stop is a better reflection of reality and more likely to be interpreted correctly by data consumers. I say this as someone who has routinely mapped all-way stops as highway=traffic_signals traffic_signals=blinker in the past but now am reconsidering. If you want to distinguish between two-way and all-way stops with beacons, highway=stop traffic_signals=stop already seems sufficient for that purpose, but highway=stop traffic_signals=blinker stop=all is also a possibility.

 – Minh Nguyễn ^💬 08:43, 8 September 2021 (UTC)

Crosswalk crosses a highway

A crosswalk crosses a rural highway. There are two stop signs for the highway. But no stop signs for pedestrians. Can I still just use highway=stop on the node that joins them? Jidanni (talk) 17:54, 23 September 2022 (UTC)

Changes affect a proposal

Latests changes of this page affect a proposal talking about traffic signs. Also this new version makes all the translations obsolete due to now the text in English is not the same it was. --Yopaseopor (talk) 17:35, 20 February 2024 (UTC)

There is no effect on how it's used. Quite the opposite, it's clarifying any possibility in misinterpreting it as you have. Proposal_talk:Extended_traffic_signs_tagging#Traffic_control https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508/104
—— Kovposch (talk) 07:09, 21 February 2024 (UTC)