Proposal:crossing:signals
- For the 2022 draft proposal, see Proposal:Crossing signalization.
| Pedestrian-relevant signalization of crossings | |
|---|---|
| Proposal status: | Inactive (inactive) |
| Proposed by: | Nbolten |
| Tagging: | traffic_signals, crossing:signals=yes;no |
| Applies to: |  
|
| Definition: | The signals available at a particular crossing: signals for pedestrians, bicycles, etc vs. signals for traffic. |
| Statistics: |
|
| Draft started: | 2019-03-21 |
Proposal
This proposal regards replacing and upgrading crossing=traffic_signals with separately namespaced keys: traffic_signals=*, crossing:signals=*.
Given current best practices, adoption of this proposal would imply that all crossing=traffic_signals tags be upgraded to crossing:signals=yes. This would leave the crossing=* key open to filling with appropriate values for markings and t. Adoption of this proposal would also imply a benefit of upgrading a number of traffic_signals:*=* subtags that are only for pedestrian use to crossing:signals:*=*.
Problems with crossing=traffic_signals
crossing=traffic_signals forces mappers to choose between markings and signalization
The crossing=* namespace has values that are not orthogonal, requiring a mapper to choose between the types of features they want to map. Namely, there is a competition between describing markings on the ground and signalization. There are four potential combinations of these two real-world features: unmarked/no signals, unmarked/signals, marked/no signals, marked/signals. However, there are only three tags attempting to describe these values: crossing=unmarked, crossing=uncontrolled, and crossing=traffic_signals, and therefore no way to describe all combinations.
While the wiki is not clear on the exact meaning of these tags, a common interpretation is a hierarchy: if there are pedestrian-facing signals, tag crossing=traffic_signals. Otherwise, tag for markings: crossing=unmarked or crossing=uncontrolled. Therefore, when crossing=traffic_signals is set, the markings on the ground are now unknown. Mappers are forced to choose between mapping signals and ground markings.
Some mappers claim (despite a lack of documentation) that crossing=traffic_signals implies markings. Even if this were this case, it fails to describe real-world crossings, such as those near Westlake Park in Seattle, WA, USA, where there are many pedestrian signals that lack markings.
This proposal suggests placing signalization (like traffic lights) on a separate tag so that mappers can fully describe a crossing's signals and markings.
It is easy to tag crossing=uncontrolled instead of crossing=traffic_signals using aerial imagery
Armchair mappers attempting to map pedestrian crossings can see ground markings from aerial/satellite imagery and can (and have) mapped them with crossing=uncontrolled, even when there are pedestrian signals available. Aside from being incorrect (according to some), this is a problem for QA and general accuracy: the crossing=* key has been tagged, so quest-based QA like MapRoulette or StreetComplete can't identify it as a crossing needing subtagging. Only an audit or bad experience in a downstream data consumer will reveal the error / lack of information about signals.
If pedestrian signals used a separate tag, this would never happen.
crossing=traffic_signals is ambiguous/misleading
"traffic_signals" is used twice as a tag value: for crossing=traffic_signals and highway=traffic_signals. Using the same value isn't inherently a problem, but in the case of crossings it is unclear to what extent the tag describes pedestrian-facing infrastructure (like walk/do not walk signs) versus traffic signals (stop/go/yield): the meaning of "traffic signals" is not obvious.
The wiki does not describe the precise meaning of crossing=traffic_signals, stating only
Position this tag where the crossing-traffic (pedestrian, bicycles) have their own traffic lights.
Having "their own traffic lights" does not clarify whether pedestrians are protected by lights that control street traffic or whether pedestrians have a light facing them controlling when to cross.
On the tagging mailing list, an astute expert user claimed that crossing=traffic_signals implies that pedestrians have a light that controls/synchronizes with a street traffic light. This degree of specificity exists in stark contrast to the existing documentation of crossing=traffic_signals and raises questions about right-of-way implications beyond mere signals. Under the current tagging schema, all of these issues must be grappled with by mappers and data consumers in order to create quality data.
Imagine writing an editor for the crossing=* tag. What questions would you ask to ensure that the meaning is consistent? How would you ensure that it matches how mappers have already used the tag?
crossing=traffic_signals limits expression of the types of signals at crossings
It is useful for pedestrians to know whether a crossing is "protected" by traffic signals directed at street traffic. it is also useful for pedestrians to know whether there are pedestrian-facing signals for "walk/do not walk". The crossing=traffic_signals tag has potential implications regarding both street traffic signals and pedestrian signals without adequate options for both. There are four theoretical combinations in the simplest scenario:
- No traffic signals, no pedestrian signals: use crossing=* (but not crossing=traffic_signals).
- Traffic signals, no pedestrian signals: no tag on the crossing itself, just highway=traffic_signals nearby. Data consumers do not know whether that particular crossing is protected.
- No traffic signals, pedestrian signals: this seems like an odd situation, but it all boils down to what we consider a "traffic signal". For example, if a warning light it not a "traffic signal", this could easily be a valid situation. If it is a traffic signal, this requires clarification and ideally a unique tag.
- Traffic signals, pedestrian signals: this is the oft-presumed meaning of crossing=traffic_signals, sans an unambiguous definition.
Only two of those scenarios are accounted for with the current tagging schema and one of them is crossing=traffic_signals - with all its other issues.
Pedestrians needs vs. crossing=traffic_signals
When crossings have pedestrian signals ("walk/do not walk"), they usually, but not always, have ground markings. While ground marking information is currently communicated by other tags (crossing=uncontrolled, crossing=unmarked), crossing=traffic_signals makes no clear statement about markings on the ground, resulting in their potential erasure: if a mapper chooses this tag versus the others, we no longer know about markings on the ground.
This leaves out substantial portions of the population. For example, people who self-describe as having low vision use crossing markings to navigate[1]. The exact format/type of markings even dictates how well a low vision pedestrian can identify and orient themselves at a street crossing.
Pedestrians benefit from ground markings that communicate right-of-way information, but crossing=traffic_signals erases information about markings
Many different countries/regions use ground markings to convey right-of-way information, such as the infamous zebra/pelican/toucan/pegasus crossings in the UK. While those particular crossings have a home in the crossing_ref=* tag, there are similar (but distinct) strategies used in other countries, states, regions, and municipalities to convey similar right-of-way information to both pedestrians and street traffic.
This information is either lost entirely (due to using crossing=traffic_signals alone) or unavailable outside of countries using the UK model of crossing_ref=* due to the aforementioned erasure of marking information.
Pedestrian safety benefits from marked crossings, but crossing=traffic_signals erases information about markings
Marked crossings impact pedestrian safety even at signaled crossings. Even the distance from traffic signals, orientation, and style of crosswalks at signaled crossings changes pedestrian safety[2].
Proposed Solution
Separate tag namespaces for automotive traffic signalization and cross traffic signalization
By using separate namespaces, mappers could quickly add basic signalization information without ambiguity:
- Set traffic_signals=yes/no for a crossing with/without signalization for automotive traffic.
- Set crossing:signals=yes/no for a crossing with/without signalization for "cross traffic" (pedestrians, cyclists, etc).
Deprecate crossing=traffic_signals
crossing:signals=yes/no would be used instead, removing ambiguity from the crossing=* namespace. Note that highway=traffic_signals would not be impacted whatsoever.
Describe traffic signalization relevant to pedestrians using traffic_signals=yes/no
Because traffic_signals=yes/no/* would unambiguously describe traffic signalization, it could be applied to crossings to describe whether automotive traffic has signalization. For example, indicating that traffic has signalization at a crossing could be done using:
Upgrade process / mechanical edits
This proposal does not require or propose any mechanical edits: voting for this proposal does not mean any tags will be updated en masse.
However, to avoid competing standards, it is good to have a strategy for updating deprecated tags, part of which might include mechanical edits. Most of the existing tags are highly amenable to automated edits, and those not amenable should be reviewed anyways due to historical problems with tagging.
No changes to highway=traffic_signals
traffic_signals=* would remain unchanged when applied to a highway=traffic_signals node.
Splitting crossing=traffic_signals for highway=crossing or footway=crossing
crossing=traffic_signals should be updated automatically only when the editor software in question has used an unambiguous question. In all other cases, a manual review is suggested, wherein mappers are asked separate yes/no questions regarding the presence of traffic signals vs. pedestrian signals. The questions should populate traffic_signals=yes/no and crossing:signals=yes/no, respectively. If a local OSM community believes the tags have been added with a clear intent that maps to the new schema, a mechanical edit could be performed for the associated region.
Subtags
The pedestrian-specific subtags of traffic_signals=* would become subtags of crossing:signals=*:
- traffic_signals:vibration=yes/no → crossing:signals:vibration=yes/no
- traffic_signals:arrow=yes/no → crossing:signals:arrow=yes/no
- traffic_signals:minimap=yes/no → crossing:signals:minimap=yes/no
- traffic_signals:floor_vibration=yes/no → crossing:signals:floor_vibration=yes/no