Talk:Tag:highway=stop

From OpenStreetMap Wiki
Jump to: navigation, search

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
Way 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.
Node 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
Node from one a node on the way to which the stop sign applies, in front of the stop sign.
Node 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

Stop sign problem.PNG

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)

Stop-forward-backward-both-proposal copy.png

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)

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)

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
Way (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.
Node (none) or via one the junction at which the stop sign applies, or the stopping location if not at a junction
Way 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)