How should a two-way stop intersection be tagged if it isn’t known which approaching streets have to stop, just that not all of them have to stop?
I’ve proposed a new quest for StreetComplete that would encourage mapping traffic lights, stop signs, and yield signs at intersections. It would be limited to the U.S., where there’s no such thing as a “priority road” and stop signs are very common. It would be further limited to intersections where no traffic control has been mapped yet:
This information would be useful to both routers and renderers, especially in the U.S., where stop signs are very common but difficult to often discern in street-level imagery. (Recently I identified about 900 stop signs lacking stop bars, without really trying.)
StreetComplete is in some respects the perfect application for collecting information about traffic control, but it comes with some constraints. Unlike MapRoulette, StreetComplete needs to be able to put down something on the map in response to each task, or it’ll just ask the next user the very same question. This creates a tricky edge case at stop- or yield-controlled intersections, which need to change or create features away from the feature in question.
Normally, highway=stop is only tagged on the intersection node if it’s an all-way stop (stop=all):
This is a problem for StreetComplete, because it currently lacks the ability to create a new node in response to a quest. Without the ability to map something in every scenario, StreetComplete would be unable to ask the user about intersection traffic control at all.
There’s actually a relatively obscure tag, highway=priority, that’s designed to go on the intersection node in a situation like this. You’d still map the highway=stopstop=minor or highway=give_way at the stop bars, but the intersection itself would end up with highway=priority to let routers know that drivers on the main road have the right of way:
Until StreetComplete is able to support node creation, would it be acceptable for the application to tag just the highway=priority node but not the nearby highway=stop or highway=give_way node manually? Would it be acceptable to tag highway=priority like this all over, in a neighborhood that happens to have a lot of this kind of intersection? Effectively, it would say that one approaching street must stop or yield while the other can go right on through, but we don’t know which one yet. It would be somewhat awkward but still useful for helping mappers locate intersections to map more thoroughly.
highway=priority currently occurs 1,679 times globally. Of those occurrences, only 117 are by themselves without a highway=stop or highway=give_way node nearby. (I’m assuming the stop/give_way node would be within 20 meters, or about 66 feet, or about six lane-widths, from the intersection node.) But some occurrences are cruft probably left over by mappers unfamiliar with this tag.
I’m posting this in the U.S. category because the proposed quest would be limited to the U.S. However, international perspectives about highway=priority would be welcome as well.
Hm. I’m a big fan in principle of mapping stop signs and traffic control devices, as I think they’re quite useful data, not just to American drivers but also to pedestrians and bikers looking to cross a street without getting run over. But this scheme gives me some pause. I’m not sure I feel comfortable with the promotion of two tags, highway=priority and junction=uncontrolled (though I guess this post is only about the former), that have almost no natural US usage.
Maybe more to the point, this feels a bit like ‘mistagging for the tool’ to me: there’s a consensus way to map two-way stops in the US, it’s StreetComplete that’s limited to tagging it esoterically. In other words, it’s not really true that a mapper adding this means that “one approaching street must stop or yield while the other can go right on through, but we don’t know which one yet”, as it’s quite obvious on the ground. If this were implemented, it would introduce unnecessary ambiguity IMO: should all two-way stops be tagged with highway=priority on the intersection node (a pretty major change to existing practice)? Or should it be seen as a fixme for someone using an editor that allows node creation to go back in and correct all of these StreetComplete entries later?
I included highway=priority in the proposal because it can draw attention to intersections needing attention, similar to a fixme. However, I’m not proposing that we drop everything and add highway=priority to all two-way stops. If an intersection already has stop or yield signs on some but not all of the approaches to an intersection, then highway=priority is already assumed in practice.
The reason I’m aware of highway=priority is that Palo Alto is dotted with it after Lyft added it when mapping stop signs a few years back. At one point, a mapper went through deleting all of them one by one without giving a reason, but they’ve been restored.
Part of the reason the tag is so obscure is that its wiki page, until recently, was very brief and unhelpful. The actual documentation about it was on the page for highway=stop, below the fold, nestled between passages that have confused mappers for ages. (Did you know highway=stop sometimes goes on the intersection and sometimes doesn’t, depending on whether it’s an all-way stop? Go figure.)
Until now, I never cared much about this tag because of its unintuitive name, which suggests the Vienna Convention’s concept of a priority road; we don’t have priority roads in the U.S. But in fact, priority roads are tagged differently, with priority_road=yes. highway=priority expresses a concept that exists both in Vienna Convention countries and in the U.S., of an intersection where some vehicles can speed right on through. I also used to be a lone holdout on mapping two-way stops on the intersection node, which would’ve avoided the need for highway=priority, but I’ve moved on.
I don’t like highway=priority , because it doesn’t distinguish “this is a priority junction” (give-way or stop controlled) relative to junction=uncontrolled, and the “this road has priority unless it has a =stop or =give_way” recommended. For the latter, there’s is no great improvement by doing this at the point of intersection indirectly, compared to the benefit brought by priority_road= being added to the road itself. (maybe eg priority_road=de_facto should be suggested for unsigned unofficial uses)
Using both highway= and junction= for opposites of the same attribute is inconsistent. It should not be promoted. Furthermore, highway=priority won’t work on divided roads. (which is where better solutions eg junction=intersection comes in) Fundamentally, most of the junction= are mainly physical, so the use of it for rules in junction=uncontrolled and junction=filter don’t fit well either. I can’t find how this quest deals with any existing all-way stops having highway=stop added at the stopping position in the discussion yet. Duplicating highway=stop at the intersection should be avoided. If stop= or give_way= is suggested to be added, highway=priority is unnecessary at this stage.
Unfortunately, the U.S. does not benefit from priority_road, because there’s no such thing as a priority road in this country, signed or unsigned. Yet there are plenty of intersections at which one street has an automatic right of way (priority) over another, and it doesn’t necessarily have anything to do with whether one street is more important than the other.
To illustrate this point, I live near a neighborhood laid out in a grid, where the north–south streets are numbered. Pick an east–west street and drive down it, and you will stop at every intersection with an even-numbered road. But pick the next street over, and you will stop at every intersection with an odd-numbered road. In this lattice pattern, every intersection is a priority intersection but no road is a priority road.
If you have the right of way at one of these intersections, you go through at full speed while traffic on the cross street either stops or yields. In fact, at any intersection with a yield sign (highway=give_way) on at least one approach, the other approaches all have the right of way and go through at full speed.
This is currently documented as priority_road=yes_unsigned, which is quite an awkward name, but it isn’t relevant to this discussion.
“2×1” intersections (between a divided road and an undivided road) vary in their traffic control rules. If the divided road has a high speed limit or a wide enough median, traffic on the undivided road may have to stop at a stop sign in the divided road’s median. Otherwise, it has to cross the whole intersection at once. Similarly, a 2×2 intersection may have just four stop bars or a full set of eight, or the whole thing may operate as a single signalized intersection.
Can you elaborate on how junction=intersection could more elegantly describe a two-way stop intersection?
It seems to me that the values of junction=* that describe an intersection’s geometric design are always tagged on ways and/or a relation, whereas the values that describe traffic control are always tagged on an intersection node. And then there’s junction=yes, which is something to hang a name off of in guidance instructions.
I agree that duplicate highway=stop nodes should be avoided. This quest would go out of its way to avoid touching any intersection that has any form of traffic control already mapped, whether at the intersection node or at the stopping position.
But I think this is orthogonal to whether the quest would add stop=*. After all, by the rules documented on the wiki, a 2×1 intersection with only four stop bars (no stopping in the median) would have a total of four highway=stop nodes, all at the stop bars, but I don’t know that stop=minor would be appropriate on these nodes.
priority_road=yes_unsigned is said to be used when there is a yellow diamond sign upstream, but none at the upcoming junction. What I was thinking is creating something for these warning signs File:Vienna Convention road sign Aa-19a-V1.svg - OpenStreetMap Wiki , or even when there are no special others other than the give-way or stop sign. It would be a more direct indication of priority to the major road. The scope of hazard= itself should only warn of the presence of the minor road, and the syntax will be complicated if priority is introduced there.
I’ve enjoyed reading your GitHub request! I am not clear on the priority tag though.
As an alternate to this entire conversion about priority, could SC instead ask if there is an R1-3P All Way plaque and then handle tagging based on that? Per the MUTCD:
06 Supplemental plaques with legends such as 2-WAY, 3-WAY, 4-WAY, or other numbers of ways shall not be used with STOP signs.
In practice there are still some of those out there, but they are being phased out. If it were to ask if there is an All Way plaque, you can put the stop=all tag. Otherwise, it could drop a fixme for someone to check out street level imagery and add some more details.
Asking about specific signs might be helpful as a hint for understanding the different options. But the issue is not about how to identify an all-way stop intersection; rather, it’s about how to tag a non-all-way stop on existing features (in other words, on the intersection node). highway=stopstop=all does apply to the intersection node, but highway=stopstop=minor does not, so StreetComplete won’t tag it. I’m proposing highway=priority so that StreetComplete can at least leave some trace for other mappers to complete.
Wouldn’t it be the typical approach to map the highway=stop at the actual stop position (not at the junction point) and indicate it’s direction. Additional you can add traffic_sign as well based on their ID to indicate which sign is signposted exactly.
Usually for routing purpose it doesn’t matter, whether others need to stop, but rather whether you have to stop.
Yes, highway=priority is specifically intended to be mapped at the intersection node when highway=stop is at the stop position (what I’ve been calling the “stop bar”). This tag is of interest to the StreetComplete developers because of an inability to map the highway=stop node; at least something would be mapped. (That said, the developers are working on the ability to add nodes to ways.)
