What form of traffic control is present at this intersection?

[1ec5]

General

Affected tag(s) to be modified/added: highway=traffic_signals, highway=stop, highway=give_way, junction=uncontrolled
Question asked: What form of traffic control is present at this intersection?
Or maybe more naturally: How does traffic wait at this intersection?

This quest should be limited to the United States and probably Canada. In these countries, there is no concept of a priority road and virtually every intersection has traffic lights, stop signs, yield signs, or the equivalent markings (“intersection control devices”). It should be limited to intersections where these tags are absent (and not on a nearby node representing a stopping point).

Checklist

Checklist for quest suggestions (see guidelines):

• 🚧 To be added tag is established and has a useful purpose
  • Three of these tags are de facto established and uncontroversial. junction=uncontrolled is rarer because it’s rarer in the real world.
  • Many renderers, including those used in turn-by-turn navigation, mark the locations of traffic lights, and some also mark the locations of stop signs and yield signs: Add intersection signals along current route. mapbox/mapbox-navigation-ios#4185 ZeLonewolf/openstreetmap-americana#796.
  • Many routers apply a penalty to each traffic light or stop sign. Though small, this penalty adds up over successive blocks to contribute significantly to a short route. It also allows car routers to favor through streets more than stop-and-go neighborhood streets, where through traffic poses a safety hazard to cyclists and a nuisance to residents.
  • Ideally, a navigation application would use these tags to tell the user how many more blocks to go before the next turn, because many users don’t find distances very intuitive on surface streets: Count the blocks until the next turn mapbox/mapbox-navigation-ios#426. “Blocks” are normally defined as controlled intersections, such as signalized intersections in urban areas. This is a major part of “natural-language guidance” in navigation systems, but OSM-based routers are currently unable to rely on these counts because of sparse coverage.
  • These tags will make it easier for mappers to classify pedestrian crossings as crossing=traffic_signals versus something else.
• 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
  • Any intersection would have one of these four configurations. If there is no intersection control, then it’s junction=uncontrolled.
• 🐿️ Easily answerable by any pedestrian from the outside but a survey is necessary
  • A pedestrian can easily spot an intersection control device, whether in the form of a signal, sign, or marking. It would be convenient or a pedestrian to survey the intersection while waiting to cross the street.
  • While it is often possible to identify intersection control using aerial imagery, there are many factors preventing intersection control from being mapped. For example, even in high-resolution orthoimagery, a stop sign is sometimes indiscernible because the imagery was captured at a time of day when the stop sign’s shadow is too short. Many intersections are covered by trees, and a stop bar marking may be covered by a traveling vehicle. In some places, stop bar markings are rarely painted on the roadway.
  • Although an observer on the ground can easily distinguish a stop sign from a diamond-shaped warning sign, it is much more difficult to distinguish the two shapes from aerial imagery. Similarly, it can be difficult to distinguish a conventional traffic light from an intersection control beacon, which has a similar shape but is merely a warning about a stop sign. I have personally mistagged many intersections as having traffic signals or stop signs before catching my mistake using street-level imagery.
• 💤 Not an overwhelming percentage of quests have the same answer (No spam)
  • Overall, I think there will be a healthy mix of traffic lights and stop signs/markings, with relatively fewer yield signs/markings. Traffic lights are installed at a minority of intersections in the U.S., but they correlate to populated areas and roads with high traffic volume. In some cities, mappers have historically focused on mapping traffic lights without mapping stop signs, so stop signs will dominate the quests there. In very rural areas, stop signs will also dominate,¹ but uncontrolled intersections are more likely and noteworthy from a safety perspective.
  • Even when all the intersections in a neighborhood are stop-controlled, they aren’t necessarily all-way stops, so there will be variety in determining which directions are affected.
• 🕓 Applies to a reasonable number of map data (Worth the effort)
  • Intersections are very common everywhere, but in many places, intersection control is rarely tagged. There are an estimated 15.8 million intersections in the U.S., including 272,000 signalized intersections. However, OSM has mapped only 576,171 highway=stop nodes and 451,187 highway=traffic_signals nodes – a figure that undoubtedly includes many redundant stop bar nodes at three- and four-way intersections.

Ideas for implementation

Element selection:

The wiki has an example query for road intersections. It’s a slow join over a large area with lots of roads, but over a smaller area, it should be possible to query for intersections in a more reasonable time.

The query should exclude any intersection node tagged highway=traffic_signals/stop/give_way or junction=uncontrolled. Due to the stop bar mapping style, it should also look for these tags on the adjacent nodes of inbound ways. Intersection control also applies to ramps and roundabout approaches, so there’s no need to exclude highway=*_link ways.

Intersections between dual carriageways could make it more difficult to distinguish between fully-tagged and undertagged intersection nodes. I’m also uncertain how to tag an all-way stop between dual carriageways, because of the preference for tagging the intersection nodes instead of the stop bars. Perhaps as a first iteration, the quest could conservatively omit any intersection involving two or more one-ways, or any closely-spaced pair of intersection nodes.

Metadata needed:

Proposed UI:

The quest’s icon could be a composition including a traffic light, stop sign, and yield sign.

The quest unfortunately requires multiple questions, because of how the global community prefers to model intersection control that doesn’t affect all inbound ways. The quest’s flow could look like this:

1. Show the intersection and ask if there are: a) traffic lights (highway=traffic_signals), b) stop signs or markings (highway=stop), c) yield signs or markings (highway=give_way), or d) none of the above (junction=uncontrolled).
   1. If (a) or (d), tag the intersection node.²
   2. If (b) or (c), ask if it is an all-way stop / all-way yield.
      1. If it is, show a map or diagram of the intersection and ask which inbound ways need to stop or yield. Tag or create a nearby node along each affected way, behind any highway=crossing node.³ Add stop=minor or give_way=minor and the appropriate direction.
      2. If it isn’t, tag the intersection node and add stop=all or give_way=all.

Footnotes

1. According to OSM, most counties in Nebraska lack any traffic lights. Or do they? (See comments.) ↩

2. Or create a highway=traffic_signals node on each inbound way? Both styles are valid and supported to some extent by data consumers, but different mappers have different preferences. ↩

3. How far back should it be? Would it be possible to ask the user where the stop bar or unmarked stopping point is? Or maybe that’s for an armchair mapper to deal with? ↩

[matkoniecz]

Tag or create a nearby node along each affected way

That is a major obstacle, would require implementing completely new type of quest modifying geometry and editing multiple objects - not only queried one.

EDIT:

StreetComplete cannot really create new nodes which are part of existing geometry (node creation is possible for example in shop overlay but it creates standalone nodes for POIs, which are not part of any way or relation).

StreeComplete can handle way splitting but it is a special case and significant work would be needed to extend it if such edit would be coupled with placing tags.

Also, technically, nodes are created where POI deletion is reverted or when node splitting is reverted.

[Helium314]

That is a major obstacle, would require implementing completely new type of quest modifying geometry and editing multiple objects - not only queried one.

See #4481 for difficulties with this. I hope at some point it should be done, but it's a lot of work...

[nickrsan]

I agree that this would be very useful.

I might be way off base here, so just let me know, but thinking of some other quests that have answers like "it varies along the way", would it be possible to avoid some of the nearby queries and object creation by adding responses for this quest like "it varies between travel directions" or "it's already mapped" (to cover the case where someone mapped two stop lines already, but nothing on the intersection node). That could then mitigate the need to do queries or tag nearby objects initially and just handle simple cases of all-way stops and all-way traffic signals.

[1ec5]

Thanks, I was unaware that StreetComplete is unable to make multi-feature edits. That does seem like useful functionality, especially for attributes that can vary along the length of a road or path (requiring splitting).

Limiting the quest to all-way stops etc. would be better than nothing, but there would need to be a tag for affirming that an intersection was reviewed without being tagged. Otherwise, the user would be asked again and again about something they’ve already looked at.

In the old days, I used to tag two-way stops on the intersection node, using stop=minor to clarify that it only applies to the road with the lower classification. However, this approach doesn’t appear to be standard, and it frustrates routers when processing OSM data into a graph. It often failed because classification doesn’t necessarily correspond to intersection control – and this was actually the reason I stopped mapping stop signs in my city even as I continued to map traffic lights. (I live in a neighborhood where every street alternates between stopping for one cross street and not stopping for the next cross street in a lattice pattern. 🥧)

[westnordost]

This is unfortunately not possible to do and it is not feasible to make it possible. @matkoniecz and @Helium314 already wrote about it. In my own words and additional reasons:

1. (as explained by @matkoniecz ): Only one element can be modified by StreetComplete and any answer the user can give must result in an edit being made. In this case, the edited element would be the intersection node. However, for the situation of a priority road / stop signs, not the intersection node but some other nodes would need to be tagged. As far as I know, there is no tag in OSM that one could set on an intersection node that would just denote "this is an intersection without traffic lights" (i.e. regardless of whether there are stop/yield signs or not).

2. It is somewhat complex and probably ultimately fuzzy to find whether an intersection does not already have some kind of traffic lights mapping, as it is both valid tagging to put the traffic lights on the intersection node or separately at the actual position at which the cars must stop before the red light. I can imagine that the complexity involved here somewhat explodes for bigger (and/or micromapped) intersections

3. (as explained by @Helium314 ): It may be possible in the future to have the ability to make modifications on several elements in one edit (I am still contemplating). A UI as you propose would then theoretically be possible. However, I do not think this is feasible because without a full view of the data (as you have in normal editors such as iD, JOSM,...) , the user will be prone to put the stop / yield signs at a wrong position - there is too much potentially going on on a (micromapped) intersection.

So, I'll close this as will not fix. The easiest solution here would be if all the situations of a road could be tagged on the intersection node itself where it would be valid to both tag it on the intersection node and separately. This does not seem to be the case.

[1ec5]

However, for the situation of a priority road / stop signs, not the intersection node but some other nodes would need to be tagged. As far as I know, there is no tag in OSM that one could set on an intersection node that would just denote "this is an intersection without traffic lights" (i.e. regardless of whether there are stop/yield signs or not).

Since junction=uncontrolled indicates that there’s no form of control, I believe the full set of tags in this proposal cover all the possible scenarios, other than the fact that some of them are mapped away from the intersection. But if you really need a tag for saying that there are no traffic lights specifically, that would be not:highway=traffic_signals. This tag isn’t in use per se, but it’s a natural use of the not: prefix.

Note that this proposal is scoped to countries that do not have a concept of priority roads. I agree that it would be more difficult to implement in countries that do have priority roads.

It is somewhat complex and probably ultimately fuzzy to find whether an intersection does not already have some kind of traffic lights mapping, as it is both valid tagging to put the traffic lights on the intersection node or separately at the actual position at which the cars must stop before the red light. I can imagine that the complexity involved here somewhat explodes for bigger (and/or micromapped) intersections

Does this project require every quest to map a feature comprehensively? If not, I think this quest would still have a significant benefit even if the query is very conservative, filtering out any intersection within, say, 30 meters¹ of a highway=traffic_signals/stop/give_way node. Or perhaps any intersection between ways that don’t already have highway=traffic_signals/stop/give_way nodes along them. Or just any intersection between two minor roads (highway=residential or similar).

Footnotes

1. I based this number on the size of a very large conventional intersection in San José, California, but it could be as large as you want. ↩

[1ec5]

I hesitate to mention this because I’m not sure I like the tag, but highway=priority is also somewhat well-used for indicating a partially stop-controlled intersection (such as a two-way stop at a four-way intersection), where the highway=stop nodes are offset from the intersection.

[westnordost]

Sorry, are you saying that there was a misunderstanding? Let's say we will have the quest look like this:

Are there traffic lights for this intersection?
[Yes] [No]

then it would be correct to tag

• highway=traffic_signals on the intersection node if yes and
• junction=uncontrolled on the intersection node if no regardless of whether it is an intersection with a priority road (give_way) or not

if the traffic signals (if any) haven't been mapped separately?

---

If this is the case, what exactly do you propose to find and thus exclude intersections that have the traffic signals mapped separately?

[1ec5]

junction=uncontrolled on the intersection node if no regardless of whether it is an intersection with a priority road (give_way) or not

Intersections don’t quite work like this in the U.S. Just like highway=stop, we only map highway=give_way when there’s a triangular yield sign. If there’s no yield sign, vehicles go right on through without yielding, so we don’t map anything special along that street. Therefore, these are only the proposed outcomes after dealing with a previously untagged intersection:

• highway=traffic_signals on the intersection node
• highway=stop stop=all on the intersection node
• highway=stop stop=minor on some of the inbound ways, and highway=priority on the intersection node
• highway=give_way on some of the inbound ways, and highway=priority on the intersection node¹
• junction=uncontrolled on the intersection node

I tried to be helpful by distilling this into a multi-step, wizard-like flow, but perhaps I was mistaken for thinking that a quest could have multiple steps. Showing all these options simultaneously would be just as correct.

If this is the case, what exactly do you propose to find and thus exclude intersections that have the traffic signals mapped separately?

This is indeed a challenge. There’s no standard tag to indicate that all the highway=traffic_signals nodes are at the stop bars instead of the intersection, and highway=priority isn’t necessarily mapped when highway=stop stop=minor is mapped at the relevant stop bars. But I’m quite certain that’s manageable – as long as StreetComplete isn’t taking an all-or-nothing approach, requiring all untagged intersections to turn up in the query. The Overpass API is more than capable of filtering out results based on proximity to some node.

Actually, I’m running into a more basic challenge of just identifying intersections in general. The wiki’s Overpass examples perform a slight of hand by including some filters that we wouldn’t be able to use here. The closest I have so far is this query, which would be suitable for this quest, except that it also needs to filter out any node that joins two roadways of the same name. Otherwise, it takes a conservative approach, avoiding any intersection that could potentially already be tagged at the stop bars. I’m also ignoring link roads and service roads, which often do have stop and yield signs, but not frequently enough to avoid spamming the user. With the default bbox in that query, you can see for instance that it correctly includes this untagged intersection, but not this tagged all-way stop or this two-way stop with nearby stop bars.

Footnotes

1. Contrary to my original post, highway=give_way give_way=minor would probably be unnecessary, because an “all-way yield” would be equivalent to junction=uncontrolled. Roadgeeks have turned up one instance of a signposted all-way yield in Texas, but this is nonstandard, misleading, and not worth accounting for here. ↩

[1ec5]

The closest I have so far is this query, which would be suitable for this quest, except that it also needs to filter out any node that joins two roadways of the same name.

Here’s a query that only includes intersection nodes. I also updated the wiki with it as a better example for finding intersections. It takes about four times as long as the simpler query I posted earlier, but there’s probably room for optimization. I can get it to run within 25 seconds over a bounding box that covers a moderately dense city street grid about 2 km square.

[matkoniecz]

highway=stop stop=minor on some of the inbound ways, and highway=priority on the intersection node
highway=give_way on some of the inbound ways, and highway=priority on the intersection node1

in such case is it helpful to tag solely highway=priority on the intersection node? Without highway=stop stop=minor / highway=give_way on any inbound ways?

[matkoniecz]

Really nice magical query!

---

There will be some additional filtering needed...

I guess that oneway split intersections like https://www.openstreetmap.org/node/262193741 ideally would be filtered out (should be doable in SC even if overpass cannot do this)

Also, probably roundabouts can be skipped? See https://www.openstreetmap.org/node/262193741 https://www.openstreetmap.org/node/262116931 https://www.openstreetmap.org/node/262116932 https://www.openstreetmap.org/node/262116933 https://www.openstreetmap.org/node/262116935 https://www.openstreetmap.org/node/262116936 https://www.openstreetmap.org/node/262116930 https://www.openstreetmap.org/node/1080043218

And cases where exactly two ways meet https://www.openstreetmap.org/node/1080043173 - before I fixed issue with bad name it was found as crossing, name change of straight road is not a crossing, for crossing you need meeting of three incoming roads* (way to the left used to be a separate way without name, see https://www.openstreetmap.org/changeset/134925517 and https://www.openstreetmap.org/way/93167141/history )

*in OSM it could be 2 incoming ways