Proposal:Crossing signalization

From OpenStreetMap Wiki
Jump to navigation Jump to search
For the 2019 proposal, see Proposal:crossing:signals.
Crossing signalization
Proposal status: Draft (under way)
Proposed by: Minh Nguyen
Tagging: crossing:signals=*
Applies to: node, way
Definition: Indicates which traffic signal head, if any, controls traffic using the crossing.

Draft started: 2022-11-16


Ratify the crossing:signals=* key, which is already in use, for indicating whether a user of a crossing (pedestrian, cyclist, equestrian) must wait for a traffic signal. Add more specific values to indicate which signal head the crossing user must obey.


This proposal uses the following technical terminology. Mappers would not necessarily need to know each of these terms, but they are defined here to remove any ambiguity for those commenting on this proposal.

The period during which a signal head remains a particular color, such as red.[1]
signal head
A single physical device housing multiple signals.[1]
signalized crossing
A crossing that uses traffic signals to control the flow of pedestrian traffic across the intersection. Not to be confused with a flashing beacon (flashing_lights=yes).
signalized intersection
A road intersection that uses conventional traffic signals (highway=traffic_signals) to control the flow of road traffic.


A pedestrian signal head (right) next to a vehicular signal head (left) in Uruguay.

At a signalized intersection, pedestrians generally must wait to cross until they get a green light or walk signal. This waiting interval lengthens the time it takes to cross the intersection, but it can also confer safety benefits on pedestrians. In some jurisdictions, failing to wait for a walk signal or failing to completely cross in the allotted interval is considered jaywalking, a civil offense.

The crossing can be controlled by a dedicated pedestrian signal head that operates independently of the vehicular signal head facing parallel road traffic. During the walk signal interval, the pedestrian's movements are protected from cross traffic by red traffic signals facing other directions. The pedestrian signal head's walk interval may begin or end at a different time than the vehicular signal head's green interval.

In some regions, all signalized crossings have pedestrian signal heads. Meanwhile, in other regions, pedestrian signal heads are only found at intersections with high traffic volume or a history of traffic accidents. In the absence of a pedestrian signal head, pedestrians are expected to obey the vehicular signal head instead, even at a very large intersection.


crossing:signals=* is solely concerned with users of the crossing. If a flashing beacon warns drivers of the crossing, tag the crossing with flashing_lights=yes. To indicate control of road traffic, map separate nodes at the stop line along the roadway and tag them with highway=traffic_signals, highway=stop, and highway=give_way for conventional traffic signals, stop signs, and yield signs, respectively.

This tagging scheme also applies to railway=crossing (and railway=tram_crossing), in cases where traffic crossing the railway is controlled by traffic signals instead of a level crossing signal.


Currently, the most popular method of indicating crossing signalization is crossing=traffic_signals. This tag has multiple shortcomings that would be addressed by introducing crossing:signals=*:

Problem Solution
Now that crossing:markings=* has been approved, signalization is the only characteristic of a crossing that lacks an established key or subkey; instead, the only approved tagging is a different crossing=* value. This anomaly is even starker when considering pedestrian level crossings and tram crossings, where crossing:light=* and crossing:barrier=* have been standard for years. crossing:signals=* aligns with crossing:markings=*, crossing:barrier=*, etc.
There is no way to indicate unknown signalization, only that signals are definitely present (crossing=traffic_signals) or definitely absent (crossing=uncontrolled). StreetComplete is unable to ask mappers questions for which there is no distinct tagging for the unknown state. For the same reason, it would also be impractical to deprecate crossing=marked and crossing=unmarked in favor of crossing=uncontrolled. If you cannot determine a crossing's signalization, you can omit crossing:signals=*. Similarly, if you cannot determine whether a crossing is marked, you can omit crossing:markings=*. StreetComplete can ask about signalization of crossings that lack crossing:signals=* and about markings on crossings that lack crossing:markings=*.
crossing=traffic_signals is a skunked tag. For historical reasons, if a crossing has crossing=traffic_signals but lacks crossing:markings=*, it is unclear whether it is definitely marked (the original meaning of crossing=traffic_signals) or whether the presence or absence of road markings is still undetermined. Perhaps the mapper is unable to see the crossing in aerial imagery because of a tree or building covering it. crossing:signals=* does not imply anything about markings. crossing:markings=* can explicitly indicate whether there are markings. The absence of crossing:markings=* means the markings are undetermined.
crossing=traffic_signals does not distinguish the presence or absence of a pedestrian signal head, although sometimes other tags like traffic_signals:countdown=yes and traffic_signals:sound=walk can imply that it is present. If there is no pedestrian signal head, a mapper would be unsure whether to apply crossing=traffic_signals or another crossing=* value. If they choose another value, a router would not be able to penalize the crossing based on the time spent waiting for a green light. You can explicitly state whether pedestrian traffic is controlled by the vehicular signal head (crossing:signals=shared) or a pedestrian signal head (crossing:signals=separate).

The crossing:signals=* values are chosen to be self-explanatory. shared is analogous to cycleway=shared in that both road traffic and crossing users share the same signal head. separate represents a separate signal head.


The following examples show how to translate typical real-world configurations to crossing:markings=* and crossing:signals=*. Sometimes crosswalks also have regulatory or warning signs that clarify the situation; see this appendix for guidance on translating the signs to tags.

Migration paths

Wherever crossing=traffic_signals is present, we can reliably set crossing:signals=yes or a more specific value. In some countries, we can reliably set crossing:markings=yes or a more specific value. (However, this is not the case everywhere. For example, in the United States outside of large cities, the combination crossing:signals=yes crossing:markings=no may be just as common.)

Suggestions for software developers

A conventional editor could add a field that offers four options bound to crossing:signals=*, as well as an option to clear the selection. A task-based editor like StreetComplete could ask whether a crossing is signalized, offering a "Don't know" option. A followup question could ask which signal head pedestrians must obey at the crossing.

A 3D renderer that focuses on street-level details at high zoom levels could depict crossing:signals=separate as a pedestrian signal head. Its appearance, orientation, and location relative to the crossing would all depend on the region.

Pedestrian routing profiles can continue to penalize signalized crossings with crossing:signals=yes/shared/separate, just as they currently penalize crossing=traffic_signals. Navigation applications can continue to warn drivers as they approach a crossing:signals=no, just as they currently warn about crossing=unmarked/marked/uncontrolled.

Alternatives considered

Countdown timer on the pedestrian signal head
Countdown on the vehicular signal head

Proposed features/Crosswalk clean-up proposes a crossing:traffic_signals=* that would indicate whether both crosswalk users and road traffic are controlled by traffic signals. Unfortunately, this approach conflates two distinct kinds of signals that have different taggable qualities. For instance, crossing:traffic_signals=all traffic_signals:countdown=yes is ambiguous as to whether there is a countdown timer for crosswalk users, for road traffic, or both. Moreover, at mid-block crossings controlled by conventional traffic signals, a highway=traffic_signals node on the roadway would become crossing:traffic_signals=all, forcing car-oriented renderers and routers to alias the new tag – but only for mid-block crossings, not crossings at signalized intersections. This heuristic would be difficult to implement, especially considering dog-leg intersections.

Some mappers might misinterpret crossing:signals=separate to mean that the signal head has been mapped as a separate feature. crossing:signals=walk would be consistent with traffic_signals:sound=walk. However, not all crosswalk users are pedestrians, and modern pedestrian signals no longer bear the inscription "WALK".

Features/Pages affected


  1. 1.0 1.1 Harkey, David L.; Carter; Barlow, Janet M.; Bentzen, Billie Louise (June 2007). “Intersection Signalization and Timing Plans”. Accessible Pedestrian Signals: A Guide to Best Practices. Washington, D.C.: National Cooperative Highway Research Program. Retrieved November 15, 2022. 

External discussions


Please comment on the discussion page.