Proposal talk:Relation:type=stop

See also

• Tag:highway=stop

Just one way?

Why *exactly one* way? The relation should be able to include multiple stops with multiple ways. There's no need for a separate relation. Alexrudd 04:38, 3 December 2008 (UTC)

Hmm... good point. I'm no longer certain why I suggested exactly one way per relation. If a particular junction has multiple ways that share a single node, I can't think of any reason why they can't all share the same relation. As long as each way is labelled with an appropriate role (as required), I don't think there would be any ambiguities for renderers or routers. Perhaps someone more familiar with relations in general, and with the way they are used in renderers and routers in particular could comment on this? It would certainly simplify things a bit to have a single relation per junction. -- Icycle 08:09, 4 December 2008 (UTC)

If just one way have stop sign, why not use a from node as alternative to way? i.e. the last node you would pass before arriving at the junction with the stop sign. --Skippern 12:49, 8 December 2008 (UTC)

Using a from node makes me a little uncomfortable for a few reasons. One reason is that the way is a natural component of the interesection, but a from node is separated from the intersection, and including it in a relation that applies to the intersection feels artificial to me. Also, if the road is straight, the from node could be quite some distance away from the intersection. Finally, unless the from node is a critical node, it would be far too easy to accidentally delete the from node and damage the relation. -- Icycle 02:41, 9 December 2008 (UTC)

There should be a warning when deleting components belonging to a relation, as there are no clear indications of relation properties of ways and nodes. This will reduce the risk of accidentally deleting of nodes. If the from node seems too far away from the intersection, than a node should be put closer. If node is not allowed than the will have to be cut on the intersection, for renderers that render the name of the street only by tagging of the way and not by relation, that might spam the map with street names, or some streets might not have names tagged because of too short sections. I know that this might be the extreme case, but keeping the option open will increase the usability of the relation. Ways should generally be the default IMO on this relation. --Skippern 05:14, 9 December 2008 (UTC)

Note that with this proposal, it is not necessary to split a way at an intersection to represent a situation where there is only a stop sign in one direction on the way at this junction. That is precisely the reason I propose for using the "forward" and "backward" roles with this relation. For example, if this is a one-way road with an intersection somewhere in the middle of the way, you would create a new relation, with the way and junction node as members. You would apply the "forward" role to the way. Routers and renderers should interpret this to mean that there is only a stop sign in the forward direction on this way at that node.

Nodes vs. Ways

I guess I'm OK with allowing the use of two nodes as an optional alternative representation. But it doesn't add any additional expressive power to the original proposal. There is nothing that can be represented with two nodes that can't be specified with a node, a way, and an optional role on the way. In OSM, is it preferable to have a single canonical method to represent something, or multiple equivalent alternatives? -- Icycle 19:48, 9 December 2008 (UTC)

forward and backward is a dirty way of doing it, it is the same with left and right, and should be avoided. Only exception I can think off is for routes where you can define 1 - 2 - 3 as forward and 3 - 2 - 1 as backward. I have seen quite a few errors in the use of forward/backward/left/right, and this kind of tags should be avoided IMO. --Skippern 03:12, 10 December 2008 (UTC)

I don't see why using forward and backward roles would be considered dirty. It is simple to understand, is well established role for a way in a relation and is well supported by editors. Up side is that using roles for ways removes need to split ways in smaller pieces. --Blaz 09:14, 29 August 2009 (UTC)

I'm fairly new to OSM, so I think I may have to defer to your knowledge and experience. Using roles seemed like it was an elegant solution, but if this really is considered dirty and error-prone, then so be it. The should be a fairly uncommon corner case anyway, since most intersections will have stop signs in both directions or the way will have oneway=yes. In either of those cases, the placement of the stop sign is sufficiently specified with just the way and the junction node. -- Icycle 05:17, 10 December 2008 (UTC)

Suggestion to clean up the proposal: remove the direction role of the way and make the way optional. Also allow for multiple ways if there are several roads leading to the junction. This way you can specify which ways have a stop sign, and omitting the way member you indicate stop sign in all directions. --Skippern 05:44, 10 December 2008 (UTC)

Your suggestions make sense. I have updated the proposal accordingly. Thank you. -- Icycle 19:18, 10 December 2008 (UTC)

I'm wondering if the use of a 'from' node isn't likely to become ambiguous in case there is more than a way leading from the 'from' node to the junction node. We should find a way to unambiguously associate the 'from' node to the specific way connecting the 'from' node to the junction, to which the stop applies. The direction still plays a role, as we need to specify in which direction and along which way we move from the 'from' node to get to the junction node. IMO it's easier to unambiguously pair the way/direction information rather then the way/'from node' information. --Kaitu 03:57, 14 December 2008 (UTC)

For cases were you have one-ways streets or you have two-way streets where both directions have a stop at the junction, using just a way and a node is sufficient. It gets more complicated if you have a two-way road where there is only a stop in one direction at the junction. This should be a very rare case. I've racked my brain, and the best example hypothetical example I could come up with is where a relatively minor street intersects a dual carriageway. Depending on the particular circumstances, you might have a circumstance where the minor cross street has only a single stop sign in each direction to cross the two junctions of the dual carriageway, resulting in a two-way street with a stop sign in only one direction.

I thought using the forward / backward role on way to specify which direction has a stop sign would be clever, sufficient, and unambiguous, since each way is effectively a vector. But Skippern suggests that people editing the map won't understand this properly. The suggested alternative is to use a from node instead. As you point out, this is not a perfect solution either. Hopefully, people using a from node would specify the from node on a way that also contains the junction node. As long as there isn't another way that shares both nodes, this should be sufficiently unambiguous. One can always just add a new node on the way to use as the from node if necessary. -- Icycle 18:54, 15 December 2008 (UTC)

Lacking OSM experience myself, I trust Skippern wisdom, and I reckon we'd better avoid error prone specifications, even if they appear at first glance as the more obvious solution. But I think the use of a 'from' node is either too artificial (when the node is added for the sole purpose of creating a suitable 'from' node) or too ambiguous when the same node is prone to become shared with other ways, possibly leading to the junction via a multiple paths. As an simple (though a bit weird) example, think of a way which closes to itself in a loop, like a 'q' letter, and there is a Stop where the ring intersects the vertical segment. We can place the 'from' node anywhere in the ring, and still we have no way to infer if the way encounters a Stop when driving the ring in a clockwise direction, or anticlockwise, or both. The Stop is conceptually a relation between a point (the junction) and a way, not between two points. As you point out, an ambiguity arises only when the junction is an inner node of a two-way street, and we can't tell if there is a stop entering the junction from both directions, or only from one. I propose to modify the relation as consisting of only one node (the junction) and one or more ways. We assume that any way belonging to the relation, encounters a Stop while approaching the junction from any allowed direction. In the rare case that a two-way street crosses the junction, and there is only a stop in one direction, we just need to split the way in two parts, right at the junction node. We then add to the relation only the part which finds a Stop when it enters the junction. As now the junction is a terminal node for that way, the node can be reached only from on direction, and there is no ambiguity. Hopefully, we'll get a way to overcame the unwanted fragmentation effect which the artificial splitting produces on the street, as soon as the proposed Collected Way relation will be approved in some form. --Kaitu 21:05, 15 December 2008 (UTC)

Very good suggestion. The case where a two-way intersections a junction, but doesn't have a stop sign in both directions should be very rare in practice, so splitting the way seems like a reasonable compromise to make understanding and using this relation simpler. I have incorporated this suggestion into the proposal. -- Icycle 00:39, 17 December 2008 (UTC)

Using this approach, and (although this isn't a necessary condition) assuming a similar approach is used for Yield or Give Right of Way, how would I handle the following situation. Assume three ways, clockwise (or anticlockwise in some countries) A, B and C, connecting in a "Y", with B normally having right of way to C or A. The traffic control requirement when entering the junction from A is that you are required to stop if proceeding to B but only to yield if proceeding to C. This could be more generalized to any multiple way intersection (or roundabout) where you are required to stop if proceeding to any way other than the one to your immediate right (or left depending on country). The only way I can see to handle this is with "to" nodes (which then begs the question, once again, of why not "from" nodes). I can't recall a specific physical example of this, but I seem to remember running into it more than once sometime in the past. Hopefully I've overlooked a simple answer.(Pardon my earlier failure to sign)turbodog 13:00, 1 October 2009 (UTC)

Needed for routing?

What makes the stop sign so important for routing ? I think it's a lot of editing work for almost nothing. -- Pieren 08:40, 3 December 2008 (UTC)

It's most useful for bicycle routing, less so for automobiles. Cyclists must consume a lot of energy every time they start up from a complete stop. This makes routes with lots of stop signs a lot slower and a lot more tiring for cyclists. And thus it is highly desirable to know where the stop signs are, so that routing algorithms can give such routes a lower priority when calculating routes for cyclists. -- Icycle 06:29, 4 December 2008 (UTC)

Imagine a long residential road through neighborhoods that connect two major roads. Normally the roads intersecting the long road will have a stop sign for traffic entering the long road but not for the long road itself. Directions routing along this long road may be faster than circling the neighborhoods on major roads. If however, the residents of the neighborhoods through which the long roads have lobbied for four way stop signs to be placed at each intersection as a means of controlling speeding traffic the long road would be less desirable as a route between the two major roads. Stopping every few hundred yards for several miles could take significantly longer than maintaining a constant slow speed for the entire distance. --rharrison 10:38, 21 July 2009 (UTC)

Maybe routing isn't the best usage for this, but I can certainly see a lot of value if the gps in your car can warn you that you have to stop. You sometimes have to watch our for so many things that it can always help. --Eimai 14:01, 4 December 2008 (UTC)

Here is a concrete example of where documenting stop signs would be useful for bicycle routing:

http://www.openstreetmap.org/?lat=37.30729&lon=-121.94571&zoom=17&layers=B000FTF

Williams Road has a bike lane for most of its length, except for this short stretch to the east of S. Winchester Blvd, and is a major east-west bicycle corridor. A few hundred meters to the south-east is the Westfield-Downing Pedestrian Overcrossing, which is a bridge over the freeway and also a major feature of this east-west corridor.

The most obvious, naïve routing, without taking into account stop signs, would be to cross over the Wesfield-Downing POC, turn right on S. Daniel Way, and turn left on Williams Rd. As it turns out, each of the intersections on Williams Rd. between S. Daniel Way and S. Winchester Blvd. is a four-way stop, and they occur at 100m intervals. On a bicycle, this is exhausting and very slow.

The alternative and better route for cyclists either takes Clifton Ave. or Westfield Ave, since on these streets, the same series of 100m intersections are all two-way stops where Clifton Ave. and Westfield Ave. have the right-of-way.

Without documenting the stop signs, I don't see how a routing algorithm would pick the better route. And in fact, if you try this in Google Maps, you will see that it choose the obvious, but inferior route. -- Icycle 20:45, 4 December 2008 (UTC)

Best usage is probably for use of maps in 3D mode, the map can then render a stop sign far up on the road, maybe even before you are able to see it yourself, that way you can prepare yourself for the full stop, i.e slow the car down in time before the intersection. Routing software will only take use of this if it can avoid areas with many stop signs by choosing a different route, the same way it works with traffic signals and speed traps. --Skippern 13:14, 11 December 2008 (UTC)

Taking account of stop signs probably adds little value for automobile routing, since most auto routes are likely to spend most of their distance and time on motorways instead of local streets. The location of stop signs is of greatest use to bicycles, since bicycles generally may not use motorways, and stop signs have a more profound impact on cyclists. Here's a very good article on why bicyclists hate stop signs, from University of California at Berkeley Trasportation Center:

http://socrates.berkeley.edu/~fajans/pub/pdffiles/StopSignsAccess.pdf

-- Icycle 16:46, 11 December 2008 (UTC)

This is important for routing, because is affects the estimated time to arrival. --Lulu-Ann 15:02, 25 August 2009 (UTC)

Stopping just for certain vehicle types

In Belgium we can have signs like:

which means that the stop sign only applies to bicycles resp. bicycles and mopeds. How would this fit in this relation? --Eimai 13:04, 3 December 2008 (UTC)

Perhaps the relation should have an except attribute, for example, except=bicycle;moped. However, I'm not familiar with this type of traffic control. Does this mean that bicycles treat the stop as a yield or give way sign? Or does it mean that bicycles treat the stop sign as if it didn't exist? If there is a four-way stop that has these signs, and a bicycle and motorist are both approaching the intersection, does the bicyclist automatically have the legal right-of-way?

Also, in the state of Idaho in the United States, all stop signs are treated like yield signs. I'm not sure if this is the same as the Belgium example you cite or not. And should Idahoan who use this relation tag all stop signs to indicate that they are yield signs for bicyclists? Or should clients of OSM data just know that if the stop sign is in Idaho it is a yield for bicyclists? -- Icycle 08:17, 4 December 2008 (UTC)

I think you've misunderstood the meaning of the sign. It's not for car drivers that have to stop for cyclists only. It's for cyclists that have to stop and give way to all other traffic. So it's the cars here that can act like the signs don't exist.

So, an "except" tag wouldn't work here, but maybe a "vehicles" tag followed by a semicolon separated list of vehicle types could work. --Eimai 13:48, 4 December 2008 (UTC)

Btw, we also have:

and

where the cyclists (and mopeds) aren't required to stop, but they do have to give way to other traffic. --Eimai 13:54, 4 December 2008 (UTC)

Give way signs?

Should this proposal be extended to give way signs as well? The concept is similar (stop signs also require to give way), so it makes sense. --Eimai 13:07, 3 December 2008 (UTC)

Yes, I agree entirely. In fact, I wondered this myself from the moment I proposed it. It seems like there are two ways it could be accomodate. One option would be to generalize this relation to be something like type=traffic_control, with an attribute traffic_control that can take on the values stop or give_way. Another option would be to have two different kinds of relations, one of type=stop, the other of type=give_way. I don't feel like I yet have enough experience with OSM to make a good judgement as to which is preferred, but I would lean towards making this relation generic, and then specify whether it is a stop or yield with additional attributes.

And of course, this is further complicated by the fact that a single junction could contain a mix of both stop a yield signs, and as noted above, in some jurisdictions, a stop sign is treated as if it were a yield sign. -- Icycle 08:22, 4 December 2008 (UTC)

For now I think a type=stop and a type=give_way or type=yield is the easier option. But you can take them both in one go on this page, as everything else is similar. --Eimai 13:56, 4 December 2008 (UTC)

I'd like to figure out what the best long term option is, not just what easiest. Especially considering that in some cases (like stop signs in Idaho), some kinds of traffic consider the sign as a stop, and other kinds of traffic as a yield, both of these traffic control signs feel like just two subclass of an abstract type. -- Icycle 18:55, 5 December 2008 (UTC)

I've chucked up a quick variant of this at *Proposed_features/Relation:type=traffic_control, which is basically the same except it handles give way signs as well (and can be extended to others). The members have roles which say what kind of traffic control (stop, give_way) affects them - would that be useful? --Doctau 11:05, 25 September 2009 (UTC)

Right of Way signs

When having this for stop and give-way signs, why not implement the same concept for the road that has priority? To know that a road has priority is important for routing - such ways should be faster and therefore preferred. However, for ways that have priority at all junctions they cross, it should be possible to tag the way with priority=right_of_way or something like that, thereby avoiding a lot of relations. Consequently, there should also be priority=give_way and priority=stop if this is true for every junction of a given way. --Mink 20:40, 17 December 2008 (UTC)

type=restriction

Example

   1|
    |
====+=====
2   |    3
    |4

With "5" as the junction node.

<relation>
 <member type="way" ref="2" role="from"/>
 <member type="way" ref="1" role="to"/>
 <member type="way" ref="3" role="to"/>
 <member type="way" ref="4" role="to"/>
 <tag k="type" v="roadsign"/>
 <tag k="roadsign" v="stop"" />
 ... other sign values
</relation>

or

<relation>
 <member type="way" ref="2" role="from"/>
 <member type="node" ref="5" role="to"/>
 <tag k="type" v="roadsign"/>
 <tag k="roadsign" v="stop"" />
 ... other sign values
</relation>

Discussion

Why not use type=restriction?
See Talk:Relation:restriction#Proposed_changes
On my proposal you could simply set stop=yes.
If no "to"-ways are needed (no turning restriction) you could tag the junction-node as "to".
--Phobie 14:14, 8 December 2008 (UTC)

I think that's misusing the restriction relation. The concept aren't similar enough, so it's cleaner to do it differently. --Eimai 14:59, 8 December 2008 (UTC)

Besides some countries have laws that make this very different from a restriction, such as it might not be required to come to a full stop if you turn to right, or right of way is given to a vehicle that have come to a full stop in the junction. By abusing the restriction relation on this, than you would have to give different ways of the relation depending on the regulations in the given country. At least this way we just tell the renderer and the routing software about the stop signs, and let the routing software take care of any other special condition. --Skippern 03:35, 9 December 2008 (UTC)

What has your law-argument to do with my idea? With my Talk:Relation:restriction#Proposed_changes we have a distinct way to describe from where we approach a junction, which is needed for junction-signs. Road signs are restrictions so the name is good. We only need to think about if signs fit to the turning-restrictions of type=restriction. I already introduced sign=* for turning-restriction-signs. If it does not fix it should be named type=sign since type=stop does not really fit for all needs. --Phobie 20:27, 9 December 2008 (UTC)

What I meant by the law-argument is that you have to know what rights and restrictions the stop sign gives in the given country to apply the restriction correctly. I am traveling some around the world, and will not be able to apply the correct values to a stop-sign-restriction for most of those places, while I can always identify a stop sign. Besides, a stop sign isn't really a restriction, but can be put up together with or in parallel with a restriction. Keep stop and restriction separate, they are distinctively two different things. --Skippern 03:20, 10 December 2008 (UTC)

No, you just tag the position of the sign in relation to the road in a way which is parse-able by routing software. For me a stop-sign is a restriction. It restricts me from driving through the junctions without stopping... --Phobie 12:27, 10 December 2008 (UTC)

In that case I can call speed limits, yeld signs, no passing zones and such also for restrictions, as it prevents me from driving as fast as I want. --Skippern 12:45, 10 December 2008 (UTC)

Yes, thats what I meant. But this does not mean that all those restrictions have to be in one relation-type. --Phobie 14:00, 10 December 2008 (UTC)

I agree with Eimai. The concept of turn restrictions, like No Right Turn, or No U-Turn, feel like a very distinct concept from stop signs (and yield signs for that matter), and therefore, it feels more correct to me to have them represented by a distinct relation. In addition, restrictions are relatively rare, but stop signs are ubiquitous. It would seem a little odd for the most common use case for restriction to be something for which it isn't a particularly great fit anyway. Finally, I thought the restriction schema required splitting of ways, and if so, I would not want to add a very common use case that would cause additional unnecessary splitting of ways. -- Icycle 20:41, 9 December 2008 (UTC)

It does not need to have the same name, but it could share the syntax. What is bad about splitting ways? --Phobie 12:08, 10 December 2008 (UTC)

If it has a different name, why share the same syntax? Also splitting ways is bad for several reasons. One important reason is that it makes future editing of the way more difficult since you now need to make sure you edit each segment of the split way. Also, some renderers may not realize that the split ways are all part of the same entity, which may cause bad labeling. -- Icycle 17:06, 10 December 2008 (UTC)

Because the syntax is useful. If many ways share the same values, those values should be better saved into a relation! If a renderer does something wrong the renderer should be fixed. --Phobie 19:57, 10 December 2008 (UTC)

• I really don't understand all this complexity. What is wrong with placing a tag (roadsign=stop + direction=1|0 depending on the direction of the way) on a node just before the actual crossing? That is where the stop and give_way roadsigns are on the road anyway. --Skratz 12:30, 30 December 2008 (UTC)

Because it should not be necessary to have several nodes in a simple intersection, because one relation can give information about all the stop signs in a given junction, and also the same relation can give information about give_way and right_of_way. Besides, we are not tagging the actual sign as the sign post would be slightly to the right (left in some countries) of the road, and not on the actual road. --Skippern 12:49, 30 December 2008 (UTC)

Ok so you don't actually tag roadsigns, but that you have to stop or give way. But you always have to stop before the intersection, therefore it doesn't make sense to tag the intersection itself. Tagging a relation on a single node is also abusing the relation thing, because there is no relation with anything else, just a single node. So there is no way to tell for sure to what road that connects to the intersection the information applies without full knowledge of rules that have been made up here just to make that possible. Only the fanatics are going to do and understand that. --Skratz 03:23, 31 December 2008 (UTC)

Actually in this example I will end up with 3 members in the relation, the road I'm on, the road I'm about to cross, and where I will cross it. I do not see the point in making a node 2.5 meters from the center of the intersection, because a white line is painted on the road there. Do you tag a traffic signal with 10 nodes? No, because you know you have to stop a few meters from the center of the intersection, and that there might be more than one light mast. Tag the actual conditions, not photocopy the world. --Skippern 13:28, 1 January 2009 (UTC)

If you also put the roads in the relation, then I predict that things will get very messy. You'll be at least putting 3 peaces of road in the intersection, otherwise there is no intersection. The more roads intersect, the more roads in the relation. That is a lot of information you don't need to know, you only need the info that is on your route. And I still don't see how the information can be put in a relation without making it very confusing and thus error prone (see my very first remark). You only need 1 (not 10) node per signal/rule. Sometimes you can even use the same node for different things, so that's even less than one. Using nodes isn't even close to photocopying the world, but correctness is important, it avoids confusion. Also relations are for virtual things (like for example routes) not for fisical things (like for example where the road stops). --Skratz 15:15, 1 January 2009 (UTC)

How can you give any useful information about stop signs without getting messy when only using one node? A node marked as roadsign=stop or whatever it is tells you nothing more than there is a stop sign present. If this node is not in the intersection, but a few meters off as you suggest, than how can routing software on the crossing road see that it have the right of passage? If you put it in the middle of the intersection, does that mean there is a stop sign in every direction? What if one of the roads have right of passage? That is where the relation comes in. --Skippern 16:08, 1 January 2009 (UTC)

Because there is no stop tag on that road? or because there is a tag right_of_way on that road or on a node before the crossing? or because that road is a primary road and therefore has priority over a residential road? or they are both residential and there is no tag, than it should assume that traffic coming from the right (or left, depends where you live) has the right_of_way. The governments have already created rules that apply in most situations, in the other situations lines, signs and lights tell us what to do. --Skratz 18:33, 1 January 2009 (UTC)

You seem to think that roadsigns and whatnot on other roads matter, the way I see it they don't. When I'm driving on a road and I have no gps or anything else, I don't care about the other roads. All that matters is: what are the rules on the route I'm following. --Skratz 18:44, 1 January 2009 (UTC)

Easier method?

Just wondering if it wouldn't be much easier like this: split the way at the intersection with a stop sign, and add to the road with the stop sign a tag like "stop=at_end" or "stop="at_start" (depending on the direction of the way), or "stop=at_both_sides" (if both sides of the way has a stop sign). As far as I can see there's no real drawback by doing it this way, and no ambiguity. --Eimai 14:13, 30 December 2008 (UTC)

The problem with this approach is actually where the stop sign in one way gives right of passage for the crossing way in the intersection, a relation will take care of that. --Skippern 15:08, 30 December 2008 (UTC)

Wouldn't that be an easy check? Just see which ways on a crossing have a stop sign or a give way sign, and the other ones have right of way. --Eimai 19:09, 30 December 2008 (UTC)

The easiest check is only to load the road you're on, and if it is a member of a relation take that into account. If you need to load all crossing roads than the workload of the program is largely increased. So the easiest way for the programs is to have relations where the crossing roads are members. --Skippern 13:21, 1 January 2009 (UTC)

This is basically the proposal of Key:stop. Skippern: having a relation, the software would still need to (down)load the relation members, if I understood the implications correctly, plus the relation data. I'm in favour of using a simple tag for this. (See also discussion on talk@). --Hanska 15:08, 23 August 2009 (UTC)

Problem with "easy method" is that it is quite error prone. Without explicit support for such tag you would inadvertently introduce non existing stop signs when splitting a road, drop existing signs when joining ways and move sign to other end of a road when reversing a way. On the other hand, editors give generic warnings when splitting or joining ways in a relation. --Blaz 09:25, 29 August 2009 (UTC)

Why not more hierarchical?

Would it not make more sense to have a relation of "type=traffic_control", with "traffic_control=stop" or "traffic_control=yield" or "traffic_control=traffic_light" or even "traffic_control = no" for an explicitly uncontrolled intersection? I originally thought only "control" but felt that was too general, and likely to be used elsewhere for other purposes. -- turbodog 10:36 3 October 2009 (UTC)

I wasn't aware of the alternative proposal when I made the above comment. I would like to see this combined with this proposal Proposed_features/Relation:type=traffic_control. I think it provides a less fractured solution to intersection traffic control, although this one may be more completely stated.--turbodog 18:02, 6 November 2009 (UTC)

Stop "does not apply"

I've read through the proposals and I think that I've come up with an even easier way. The intersection (node) would be tagged with "highway=stop". With only this tag it would be an all-way stop. If it is not all-way, then a relationship is added between the node and each highway that doesn't stop. Here are two example intersections where road #1 doesn't stop:

  2 |          3 | / 4
    |            |/
====+===== 1 ====+====
    |           /|
    |          / |

Since road #1 doesn't stop, it's relationship value would be "does not apply", but something shorter. This same sort of thing could be applied to yield signs. — Val42 05:48, 31 October 2009 (UTC)

Details

In the USA, it is generally not easy to decipher which traffic must stop without looking at the stop signs, since sometimes, all directions must stop, and sometimes only some of them.

I think I would do it like so (similar to Relation:restriction):

1. All traffic stops ("All Way" stop in USA lingo): highway=stop (it is very simple to apply, and these are also the stops where the biggest percentage of traffic stops, so relation can complement tag instead of replacing)
2. When multiple roads intersect, only some stop, for traffic on road in both directions ("2 Way" stop): Relation:stop, nodes/ways/etc. of intersection have role "via", and road-way(s) have no role given.
3. When multiple roads intersect, like in 2., but traffic only stops from one direction ("opposing traffic does not stop"): Relation:stop, role "via" for intersection components, "from" and "to" roles for ways which the stopping traffic comes from, and goes to, when stopping (in other words, "from" role before the stop sign/intersection, "to" role after the stop sign/intersection). [In a similar fashion to restrictions, this would require that ways must be split in two by intersections if necessary.]
4. If necessary (when none of the above can specify this alone), use multiple relations, in above-mentioned format.

An advantage of doing it like this is that it presents the semantics in a clear way.

And taking another page from restriction relations, it seems it might be good to make the stop relation a subtype of the proposed Traffic Control relation, the same way that there are several subtypes of restriction. For example, instead of `Relation:type=stop`, we'd use `Relation:type=traffic_control` with `traffic_control=stop`.

Abbafei (talk) 08:16, 8 April 2014 (UTC)