Maybe a bit of a can of worms, but why not informal=yes?

Maybe a bit of a can of worms, but why not informal=yes?
I think that could give the impression that the crossing is entirely informal, particularly as the wiki says of informal=yes “this attribute indicates that a feature has not been established on purpose or is not formally established”. They’re definitely there on purpose, but it’s the use of the zebra markings which is informal. It’s also a bit too close to crossing=informal, which again isn’t the case for these.
I’m not particularly wedded to crossing_ref=informal_zebra for these, but wanted some value in crossing_ref to discourage later mis-tagging with crossing_ref=zebra.
Getting back on topic, I’d be really happy if the crossing_ref key were deprecated, as long as there’s a crossing:$something=$iso3166:$legal_crossing_type replacement for it. I don’t have any strong opinion on what $something should be, as long as this information (1) isn’t lost entirely, (2) the replacement tag value is namespaced to make it clear about the jurisdiction to which it applies and (3) frees countries from crossing_ref=zebra where it really is nothing more than a duplication of crossing:markings=zebra.
There would be 5 meanings of “informal”
=path + informal=yes desire paths crosses a road=sidewalk (street corners) , and =footway terminals (where it’s legal to cross) as natural and often legally enshrined extensionscrossing:markings= =no or =surface , extending to “courtesy crossings”It’s about the dedicated phase. A scramble phase is interesting to both crossing users and road users, but we tag it on the crossing because it’s much more relevant to crossing users. For road users, all it means is a slightly longer wait and most likely a no turn on red restriction. As evidence of this, several countries have standard signs and markings to encourage pedestrians to cross diagonally, but no corresponding sign or marking to warn road users that a strange sight is about to unfold before their eyes.

Same for the other two. You mentioned crossing:signals are mainly about pedestrian traffic. Then I would think we need respective values for traffic lights, like you mentioned. If you map that traffic light information on the crossing node the pedestrian router would know.
We tag crossings with the presence of crossing signals because these signals are more relevant to pedestrians than road users. After all, a walk signal isn’t necessarily exclusive of a go signal on the road (for turning traffic).
The presence of a HAWK beacon is of secondary importance to a crossing user: the beacon doesn’t face them and they aren’t expected to know about it. It’s potentially interesting to a pedestrian router in terms of preferring that safety enhancement. But to a road user, it matters more: it has an unusual set of phases that most people have never learned. To a car router, a traffic_signals=hawk should probably nearly cancel out the usual penalty for highway=traffic_signals.

An RRFB is probably also more relevant to road users than pedestrians, especially if it’s only visible from the road.
In any case, crossing:signals=* is about crossing signals. That was already the case in the database before I started promoting it. If you want to indicate that the crossing is protected by a HAWK beacon, RRFB, standard traffic lights, shark’s teeth, or crossing guard holding a portable traffic light, there’s no reason for us to stuff that unrelated detail in crossing:signals=*.
As for crossing=zebra, again some find it valuable and valid, some think it should be removed, and I don’t care, because I checked all crossing=zebra in NL and if really zebra crossing, I added crossing:markings=zebra. So AFAIAC it’s redundant, but it doesn’t hurt.
I prefer this kind of redundancy over forced deprecation.
For the country table in the proposal, I would suggest to enter in the rightmost column:
“Community is undecided; keep for now”.
PS 2026-01-07: Added it myself, after announcing it in the Dutch forum topic about Zebras.
I think if it is on private land it can be inferred that it is not officially designated (according to the jurisdiction maybe). Being on private land (currently often not inferrable from the landuse which in some mapping happily extends to whatever area around) can often be seen from access tags on the streets.
Whelp, talk about a thread that derailled towards all directions…
I’ve used this thread to update the original page [crossing_ref page](Key:crossing_ref - OpenStreetMap Wiki) with meanings of the various types (and what they imply). I’d especially urge the USians to doublecheck my work on their crossing types. It also seems that having subtypes of [Key|flashing_light](Key:flashing_lights - OpenStreetMap Wiki) (as Jarek proposes) would remedy the need for some of the crossing_ref categories (esp. RRFB and HAWK). If you have corrections, please put them into the wiki directly
The British might use flashing_lights:ref=belisha to indicate that a crossing has Belisha beacons.
I’ve also discovered that crossing:signed exists (with 12K entries); this solves the tagging to indicate wether or not “traffic signs” are present.
I’ve also seen the proposal to have `crossing:priority`. I oppose this. The priority at a crossing is indicated through various physical objects (such as road markings, traffic signs, signals, …) The politicians might one day decide that such a physical object does not imply priority anymore (or that it might start implying priority). If we map the physical objects, we can simply (re)calculate where pedestrians have priority based on that and we don’t have to resurvey everything.
The British might use
flashing_lights:ref=belishato indicate that a crossing has Belisha beacons.
I’m fine withflashing_lights:$something=belisha, but please not another misuse of ref for something which clearly isn’t a reference number or code. Having it in crossing_ref is bad enough.
Sure, I just took :ref as it was proposed by Jarek above. Do you have a better proposal? flashing_lights:type?
I’ve also discovered that crossing:signed exists (with 12K entries); this solves the tagging to indicate wether or not “traffic signs” are present.
Yes, this key got a late start, but I’m glad it’s finally taking off. Unfortunately, the signed versus signals distinction is really confusing in some dialects of Spanish, which call both señales, but that’s a more general issue I guess.
I’d especially urge the USians to doublecheck my work on their crossing types. It also seems that having subtypes of [Key|flashing_light](Key:flashing_lights - OpenStreetMap Wiki) (as Jarek proposes) would remedy the need for some of the crossing_ref categories (esp. RRFB and HAWK). If you have corrections, please put them into the wiki directly
Thanks for summarizing the discussion there.
I avoided suggesting a specific replacement tag for RRFBs because this is just a special case. Flashing beacons can adorn other kinds of traffic signs, most commonly stop signs.
So it seems to me that we should document flashing_lights=* etc. as primarily something that you’d tag on a traffic_sign=stop or traffic_sign=US:W11-2,US:W16-7PL node, and only secondarily on something else that it reinforces, such as a highway=stop or highway=crossing node. Maybe we should only tag it on a footway=crossing way if flashing beacons are embedded in the pavement along the crosswalk markings.
Sure, I just took
:refas it was proposed by Jarek above. Do you have a better proposal?flashing_lights:type?
How about flashing_lights:design=*, by analogy with post_box:design=*?
I made some further edits in the US section here: Key:crossing ref: Difference between revisions - OpenStreetMap Wiki . Mostly just clarifying wordings, adding additional use numbers, and proposing some more synonyms. I did make one substantive change, which is that I removed the statement that a HAWK signal implies flashing_lights=yes: rather, the motorists get a solid red light when the pedestrian walk phase is on, although the lights blink at other phases. It does imply normal pedestrian signals and road markings though, so I switched those in.
This might suggest
highway=traffic_signalstraffic_signals=hawkfor the HAWK beacons, consistent with the very similar beacons that we tag astraffic_signals=emergency. Still, a pedestrian router would want to know that a crossing is protected by one of these separately mapped beacons.
The presence of a HAWK beacon is of secondary importance to a crossing user: the beacon doesn’t face them and they aren’t expected to know about it. It’s potentially interesting to a pedestrian router in terms of preferring that safety enhancement. But to a road user, it matters more: it has an unusual set of phases that most people have never learned. To a car router, a
traffic_signals=hawkshould probably nearly cancel out the usual penalty forhighway=traffic_signals.
Agree and agree, I think adding a special tag on the accompanying signals is a great idea, but they should still be tagged on the pedestrian crossing somehow as well. Maybe crossing=traffic_signals + traffic_signals=hawk would work for pedestrian crossings too?
Ah, thanks for improving this! I didn’t understand that the motorists did get a solid red phase and have to wait; I thought it was just a fancy, flashing light warning motorists for crossing pedestrians - but not forcing them to stop.
Agree and agree, I think adding a special tag on the accompanying signals is a great idea, but they should still be tagged on the pedestrian crossing somehow as well. Maybe
crossing=traffic_signals+traffic_signals=hawkwould work for pedestrian crossings too?
crossing=traffic_signals or crossing:signals=yes is going to be present anyways because of the crossing signals. Counterintuitively, traffic_signals=hawk would not be iterative refinement of crossing=traffic_signals. A crossing protected by conventional vehicular signals isn’t usually tagged traffic_signals=pedestrian_crossing on the crossing node or way, but I guess it would be a reasonable approach if we don’t expect routers to infer that from the presence of traffic signal nodes nearby.
In states that paint school crossings yellow, such as California [4] and Arizona [5], these crosswalks can be tagged
colour=yelloworcrossing:markings:colour=yellow.
By the way – I’ve noticed and tagged some crossing:markings=lines crossing:markings:colour=yellow that are not in school zones. Obviously, I tag it based on the physical reality of whether the lines or zebra markings are yellow or not.
More discussion about RRFBs:
[yes_2_square] [image] (Image Source: TDEI Tools | Wikimedia Commons) I’d like to start a discussion on mapping of Rectangular Rapid Flashing Beacons (RRFBs) at crossings in the US. 1. How should we map the beacons themselves? (Tags on nodes at the location of the beacon) 2. How should we map the beacons’ implications? (Tags on the footway=crossing way and/or highway=crossing node) The only existing documentation I’m finding on the OSM Wiki is on flashing_lights=* (link) which states: f…