Proposal:Crossing signalization
| 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. |
| Statistics: | |
| Draft started: | 2022-11-16 |
Proposal
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.
Definitions
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.
- interval
- 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.
Background
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. However, this vehicular signal head does not protect pedestrians from road traffic making an opposing turn through the crossing. For example, at this crosswalk in Ohio, a pedestrian must watch for northbound traffic making an unprotected left turn across the crosswalk, even if the southbound vehicular signal head is green.
Tagging
| Value | Definition | Standard sign | ||
|---|---|---|---|---|
| 🇦🇺 Australia | 🇨🇦 Canada | 🇺🇸 United States | ||
| no | Crossing users do not wait for a traffic signal. | |||
| yes | Crossing users wait for a traffic signal, but which signal head is unspecified. | |||
| shared | Crossing users waits for the vehicular signal head that is shared with road traffic going in the same direction. | |||
| separate | Crossing users wait for a separate pedestrian signal head. | |||
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.
Rationale
Currently, the most popular method of indicating crossing signalization is crossing=traffic_signals. Unfortunately, this tag has multiple shortcomings:
- 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.
- 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.
- 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=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.
The proposed crossing:signals=* tag addresses these shortcomings:
- crossing:signals=* aligns with crossing:markings=*, crossing:barrier=*, etc.
- 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=*.
- If desired, a future proposal will be able to deprecate crossing=marked and unmarked in favor of crossing:markings=* and crossing=traffic_signals in favor of crossing:signals=yes without dataloss.
- You can explicitly state whether pedestrian traffic is controlled by the vehicular signal head or a pedestrian signal head.
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.
Examples
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
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
- Key:crossing:signals: indicate approved status, add shared and separate values, remove the link to Proposed features/crossing:signals
- Tag:crossing=traffic_signals: mention crossing:signals=* and crossing:markings=* as an alternative
- Crossings#Traffic control
- MUTCD/R#R10: Traffic Signal
References
- 1 2 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
- Nguyen, Minh (December 23, 2018). “Add Pedestrian Signals field to crossing presets”. openstreetmap/iD.
- Talk:Proposed features/crossing:signals
- Bolten, Nick (May 7, 2019). “Feature Proposal - RFC (etc) for crossing:signals”. tagging mailing list.
- Proposed features/traffic_signals=crossing_on_demand
- Proposed features/traffic_signals=crossing_only
- Slootweg, Sven (February 21, 2022). “Should iD be tagging
crossing=uncontrolledinstead ofcrossing=marked?”. openstreetmap/iD. - bgo_eiu (June 2, 2022). “Pedestrian signals thread”. OpenStreetMap Community.
- Nguyen, Minh (June 21, 2022). “Allow tagging signalized but unmarked pedestrian crossing”. openstreetmap/id-tagging-schema.
- Talk:Proposed features/Highway crossing cleanup
Comments
Please comment on the discussion page.