The three most used tags
uncontrolled,unmarked,markedlost their (small) value whencrossing:markingswas introduced and got popular.
to reiterate the point: as crossing:markings is only about markings it is loosely related to uncontrolled, because uncontrolled implies a pedestrian crossing without traffic signals, while zebra crossings can occur at signal controlled crossings, so this is orthogonal information and deprecation (as implied in the thread title) should be out of discussion
For what itâs worth, this isnât a very meaningful comparison. In the U.S., pedestrians technically always have the right of way over vehicles: a vehicle always must yield to a pedestrian in the roadway to avoid running them over, even if theyâre jaywalking and dancing in the street.
In practice, vehicles have the right of way at signal-controlled crosswalks, but âzebra crosswalkâ means something totally different here than it does in Vienna Convention countries. It literally only means crossing:markings=ladder:skewed. A zebra crosswalk can be controlled by traffic signals, and this is usually the case in some states. Our zebras donât run wild, you see. 
Generally, the choice of one high-visibility marking pattern over another is purely an aesthetic consideration without a legal distinction. However, in Utah, crossing:markings=zebra â that is, not a zebra crosswalk â means that a vehicle must wait for the pedestrian to completely cross the street, not just halfway. So that would be âpriority plusâ, so to speak.
Anyways, I wouldnât read much into any crossing=zebra in the U.S. American mappers largely stopped using that tag in 2018. Back then, crossing tagging was chaos. No one knew why we were classifying crossings by zoo animal, and everyone had their own idiosyncratic approach to dealing with that uncertainty.
At this point, Iâd favor a mass deletion of crossing=zebra in the U.S. without replacement, but that can happen independently of this proposal.
Would a reference to crossing:signals=* address this concern? I assume it wasnât mentioned because of an assumption that crossing:signals=no by default, but if the goal is to rely more on subkeys going forward, then a migration path should explicitly set any reliable implications to avoid dataloss.
Voting on the proposal has begun.
Please vote on the proposal page: Proposal:Deprecate crossing=zebra in favor of crossing:markings - OpenStreetMap Wiki
Sorry for it taking longer then expected and announced by me.
It being orthogonal information is reason for the deprecation, to make clear if there are traffic lights with just the crossing tag you would need to tag crossing=uncontrolled;zebra and crossing=zebra;traffic_signals.
Orthogonal information belongs in a separate key
It isnât called out specifically in this proposal, but as a reminder to developers, id-tagging-schema will likely need to refrain from its usual response to tag deprecations. According to this proposal, crossing=zebra will not have exactly the same replacement tags in every region. For example, the replacement must include crossing_ref=zebra in some regions but most not in others, depending on legal expectations.
Furthermore, weâll need to be very careful about any automated application of crossing=uncontrolled. In English-speaking countries, this tag was historically used according to the legal/engineering/colloquial definition before its meaning became corrupted in the non-anglophone world. Ideally, weâd review all existing crossing=uncontrolled and retag as crossing=unmarked or crossing:markings=yes before replacing anything else with crossing=uncontrolled, to avoid generating countless false positives that risk going another step removed from reality.
To facilitate this review, id-tagging-schema could institute regional deprecation rules, but that kind of scoping is currently unsupported. This is not necessarily a problem for the proposal, since it currently states that iD and Go Map!! donât need to do anything differently if the proposal passes.
So this proposal instantly fails because it still features the crossing key but just with some other value. My question is why is being controlled by lights so important its what determines a crossing type(?) and doesnât use itâs own, proper crossing:signals? Also the affirmative value is very weird being traffic_signals instead of the probably more expected controlled to match the negative counterpart.
I suggest deprecating the crossing=* tag as a whole. All of the most typically used values already have their respective tags as a replacement.
crossing=no should always have been not:highway=crossing anyway but if someone has a good argument to keep that then itâll be fine with me since it doesnât describe a highway=crossing but a hazard=illegal_crossing.
I donât think I can stop the spread of the crossing_ref tag so at the very least please keep it out of Poland. But I will suggest a replacement regardless. If itâs a crossing for both pedestrians and cyclists, use footway:crossing:markings and cycleway:crossing:markings. All the existing values should be enough to cover all combinations. And if you like your pegasuses then use maybe traffic_signals:symbol=* or something along those lines.
I think thatâs all from me, donât forget to tag cycleway:surface:colour=red!
Erm - Iâm confused - what does the colour of cycleways (usually not red where Iâm from) have to do with zebra crossings? 
This thread is confusing enough already without trying to expand it beyond the original singular suggestion.
Indeed - there are enough combinations of previous tags and geography that itâd be virtually impossible to suggest a ânewly correctâ option except in the absolutely simplest of cases**.
** Actually thatâs true with iD in lots of other areas too (but not relevant to this thread).
For info, in case anyone wasnât aware, this discussion has a doppelgĂ€nger over on the tagging list**. One thing mentioned there thatâs not directly related to the proposal but would definitely add clarity is the following:
uncontrolledThe OSM wiki has at least two different answers:
This page says âA generic crossing with road markings, but no traffic-signals of any typeâ. This page says âwith markings, without traffic lightsâ. In the UK, a zebraâą crossing on a public road always has a flashing orange indicator that is part of the signal to traffic that âyou must give way to pedestriansâ, but doesnât tend have traffic lights (though other UK animal-named crossings do).
** for completeness the scrubbed HTML-only attachment here said âI think you might have a slight misunderstanding here, a crossing=uncontrolled is not an uncontrolled crossing but a marked crossing without traffic signalsâ in the original email.
Traffic signals is usually used as a synonym to traffic lights, they are both supposed to mean stuff here that stops traffic with a red light.
There have been proposals to deprecate the whole of crossing in the past, but they never went anywere as the scope was too big to reach a consensus. You will find complaints about using crossing:signals and crossing:markings at all in the discussions about this one and people who would like to go back to crossing=* only.
This proposal does not block a later deprecation of crossing in favor of crossing: signals in any way, if anything it makes it easier since there is one less info in the crossing value, the marking type.
One difference currently is that crossing:markings has a wide range of values as opposed to the yes/no of crossing:signals. With crossing=unmarked not being deprecated crossing=* would for now contain a simple yes/no information about both, markings and signals.
Feel free to try to deprecate crossing but I donât see the community accepting it. So I try to take a small step at the imo worst value instead.
Having people blocking the deprecation of crossing as it being too much and people blocking this as doing too little doesnât get us anywhere.
Case in point:
We are in a bit of a bind because zebra and uncontrolled were both skunked or redefined so long ago. If the replacement of crossing=zebra with crossing=uncontrolled is unattractive to the community, then I would suggest omitting crossing=* altogether. This doesnât require a formal deprecation of crossing=*, since a crossing node or way has never strictly required a crossing=* tag.
In my own city, where we had to map hundreds of kilometers of crosswalks to connect our imported sidewalks, we typically omitted crossing=* in a first pass. We didnât want to take a side in the intractable debates about this key. Now that the deconflicted subkeys are reasonably well established, weâre able to sidestep the drama. People do add crossing=uncontrolled or crossing=marked out of habit or through editor presets, but itâs merely tagging flotsam; the precise value no longer matters.
I appreciate your courage in bringing any crossing-related proposal to a vote. The proposal ended up being fairly complex due to all the intersecting interests, no pun intended. If it doesnât succeed, maybe you could try scoping down the effort by focusing on crossing_ref=* and crossing:*=* as a replacement without introducing any crossing=* tag as a replacement. Some will probably complain about redundancy or verbosity, but as long as the proposal is explicit about avoiding ambiguity while enabling the future regionalization of crossing=* that these mappers always wanted, then their concerns effectively become cosmetic and temporary.
A third interpretation is that an uncontrolled crossing has no traffic signals, signs, or road markings because these are all considered traffic control devices. Itâs for this reason that I try to always add both crossing:markings and crossing:signals. The combination of these two tags is much less prone to misinterpretation.
I do get the intention but I donât think itâs executed well by writing Tagging: crossing=uncontrolled + crossing:markings=zebra at the top. This is also quite silly since crossing=zebra doesnât even imply that itâs uncontrolled. And it just doesnât decrease the number of objects tagged with crossing=*.
But everybody just adds those tags. I guess the step is to discourage all editors from adding this tag or at least limit its values and IMO thatâs just equivalent to deprecation.
After reading some of the other votes and doing a bit of thinking Iâd say what should be done is to at least make the crossing tag be used for one purpose instead of two. Iâd recommend to deprecate the next most-used values being uncontrolled ans traffic signals and port them to crossing:signals=* since I see less attachment to those values. A crossing being controlled is referring only to traffic lights and if thereâs different flickering or something, that can be a different value. If someone wants to tag a different kind of controlling, then let them invent a new crossing:*=* tag.
I saw the description of crossing_ref on the wiki and this one vote saying that a zebra crossing is more than just a marking. In my opinion such a crossing then should have all the parts of the crossingâs kind be mapped still though perhaps in the UK it makes sense to still keep the crossing_ref tag (I do think itâs a ref in a way). Anyways, I think that every piece should be mapped because templates in OSM are generally a bad idea. I think they only exist here and in an alternate 3D building roof tagging scheme.
So in my opinion a re-run of the proposal should focus on uncontrolled and traffic_signals as well as maybe some other lesser-used values and another discussion can focus on determining whether crossing=* is still needed for mapping crossingâs marking and overall just the best tagging scheme for it.
Pedestrian crossings are the perpetual motion machine of mapping drama. Nothing we do can please everyone â especially doing nothing. Of all the putatively OSM-destroying things we could possibly do to pedestrian crossings, deprecating crossing=zebra is the idea that has the most widespread support. Weâve already discussed, voted on, and approved this deprecation on at least one occasion, depending on oneâs personal interpretation of crossing=zebra. More importantly, mappers and data consumers have effectively made synonyms of crossing=zebra, crossing=marked, and crossing=uncontrolled, at least to a first approximation. Itâs a messy Venn diagram but the sky hasnât fallen.
As I see it, the only serious disagreement with practical implications is how to execute this deprecation without losing a significant amount of detail by inaccurately conflating one thing with another. Probably everyone has a different level of tolerance for dataloss, depending on their past experience and future outlook. Pity those who want to map real zebra crossings. One might think the safest course of action is to simply stop the bleeding: convince editor developers to stop setting crossing=* as part of the presets that already set crossing:markings=* and crossing:signals=*. Unfortunately, acrimony about every previous change has made developers reluctant to take this step without getting something in writing from the community, hence this proposal and the other one about deprecating crossing=*.
This proposal recommends a specific migration path which, if executed today, would preclude any cleanup of the substantial number of existing crossing=uncontrolled that doesnât necessarily match the currently documented definition. Fortunately, it comes with the caveat that the migration path will differ by circumstances. In my view, this means we need to be more deliberate about our response to any deprecation â for example, by avoiding bulk edits or only doing them in smaller regions or based on editing history, so that we can make more confident generalizations. But this is how deprecation already works in OSM.
In other news, waterway=riverbank is still deprecated.
Not everywhere, not all mappers, not all data consumers. Most of the world lies outside the United States, (or should I say North-Mexico?)
In countries where this is a systematic error, mappers should clean this up, without deprecating a harmless value. They will have to evaluate and correct all these crossings, with or without the deprecation. Elsewhere, crossing=zebra just means itâs a crossing with zebra markings (=zebra crossing, except maybe in the UK).
I personally prefer crossing:markings=zebra, but thatâs no reason to disallow crossing=zebra as start-level tagging for a zebra crossing when other attributes are unknown.
Hey now, letâs not paint with too broad of a brush. My area of the United States is called South-Canada 
.
I said âto a first approximationâ in the part of the sentence that you omitted. What I meant is that, yes, if you consider only a particular region or a particular mapper or a particular time period, then you can more confidently distinguish the intent behind one of these tags. But in general? The tags are all synonyms from a data consumerâs standpoint. If weâre going to blame countries, then only the UK is blameless.
Sometimes we can salvage a skunked tag, but crossing=* is the canonical example of a tagging scheme so badly mangled by misunderstanding over the years that it would be more productive to start over. Starting over in this case means deprecating a tag and gently steering mappers to alternatives through natural processes. I donât see a proposal to disallow anything. In fact, if this proposal succeeds, we will be one step closer to reclaiming crossing=* so that you can once again tag crossing=zebra without misleading data consumers.
No, they are not! They describe different things.
crossing=zebra means itâs a crossing with zebra markings, crossing=marked means itâs got some kind of marking (not necessarily zebra), and crossing=uncontrolled means there are no lights and nothing is known about markings (zebra or other).
If somewhere, somehow, crossing=zebra is tagged on a crossing without zebra markings, that is a clear error. The correct way to solve this is to correct the tagging.
A systematic and thorough cleanup is what should be done in all cases. Deprecation of crossing=zebra does not automatically result in cleanup. Re-affirming that crossing=zebra only applies to crossings with actual zebra markings doesnât do automatic cleanup either, but it avoids deprecating a massively used value which is correctly applied in many cases.
I agree, with the addition that crossing=zebra implies no traffic signals. Otherwise it would be crossing=traffic_signals.
Around here it is frequent to have signal controlled crossings with zebra markings (it is not an issue, it is simply not a zebra crossing).
While you are describing what mappers (in your area) want to express with that tag his statement was about how data users treat it. And these do not make that destinction.
To give some examples the OpenSideWalksScheme converts all crossing=zebra to crossing:markings=yes and not crossing:markings=zebra or MOTIS equals crossing=zebra with crossing=uncontrolled.
Apart from OSM2World I donât know a single global data user that assumes that a crossing=zebra has zebra style markings. For the statement that there is a difference (for data users) there would need to be data users that actually make that difference.
.jpg){kind=link}