The most interesting thing for me here is that the share of unclassified crossings was always dropping until it started rising recently again.
Also interesting to run this for the UK:
I wholeheartedly agree with this point of view.
Something like a “German zebra crossing” is a standardized feature type that shouldn’t require more than a single tag. Presets which add half a dozen tags behind the scenes can only reliably solve (or rather, hide) the problem for the first mapper, the one who initially adds the feature.
As for the proposal, these considerations don’t really mean that crossing=zebra needs to be kept around. But crossing:markings=zebra isn’t a suitable replacement, at least not in those jurisdictions where a “zebra crossing” is a distinct legal concept rather than just a visual design choice. Instead, crossing_ref=zebra might be a suitable replacement in those cases. (Although I would prefer a hypothetical crossing:template key – that’s a good idea!)
I would prefer if tags which are implied for a standardized type of crossing were not added to the database. Doing so increases the risk for errors and the maintenance burden. Of course, that would require decent tooling to automatically “expand” these templates for the benefit of data consumers. I guess much of this problem is a symptom of the relatively low-level tooling landscape for consuming OSM data.
The presets in id-tagging-schema, as used by iD, Rapid, Go Map!!, and Every Door, are more capable than you’re giving them credit for. So are the presets in Potlatch (which is not dead yet). When you select an existing feature, the preset continues to hide any tagging complexity. Overpass turbo’s wizard integrates with id-tagging-schema too, certainly not just for the benefit of the initial mapper. The outlier at this point is JOSM, which prioritizes raw tags in its UI even if it recognizes that a feature matches a preset. As a result, mappers feel the burden of managing each of these raw tags individually.
As important as JOSM is to the health of our community, I don’t think we should place too much focus on optimizing its ergonomics through tagging policy. The other editors have shown that ergonomics can be improved in other ways, but people choose JOSM because they want a look at the bare metal without all the frills. The tradeoff sometimes comes in seeing extra complexity under the hood.
Anyways, I don’t think half a dozen tags are on the table; that was just hyperbole.
Some attributes are inherently implied solely by the legal classification and cannot be determined any other way. In general, it’s the data consumer’s responsibility to infer those attributes. However, a more literal attribute like a marking pattern is influenced by the legal classification but not implied by it. I think the cost-benefit analysis is different for tagging these attributes explicitly.
StreetComplete’s author likes to speak of the European who suddenly finds themselves in the middle of an American city, unaware of any of the local norms. It’s a useful thought exercise, if somewhat contrived. This hapless tourist is more likely to correctly identify the zebra stripes of a HAWK crossing than the name of that configuration. (It turns out we have some fauna on this side of the pond too.) If a local later comes in and positively identifies the HAWK crossing, do they have to remove crossing:markings=zebra at the same time that they add crossing_ref=hawk? I think that would be pointless at best.
Not only that, but also the openendedness of having to infer arbitrary attributes from arbitrary “template” values. This complexity won’t affect a bespoke local data consumer, but it will limit the reach and quality of any data consumer that aims to serve a more global audience.
I agree that it makes no sense to tag the local implications of a zebra crossing with all those tags that have been brought up satirically that would always show up paired together with a crossing_ref=zebra. But I don’t think it makes sense to have a global tag you can use almost everywhere to describe a thing, but can’t use it in certain areas to describe the same thing, just because they have an other tag there that implies the markings. So I’m advocating to use crossing:markings=* everywhere and additionally crossing_ref=* where appropriate. I don’t think that one additional tag creates huge issues, we even tag highway=crossing on nodes with crossing=* and no one complains. Most people don’t even see the highway tag itself despite handeling it constantly due to it being hidden by the editor.
With crossing_ref=* being great to handle local implications the proposal included it from day one for certain regions, I just named the proposal after the tag that would be applied global. I have rewritten that section a bit now to say something about possible presets as well.
That’s more of an issue with the incredibly vague semantics of the highway=path tag which is used anywhere from wide, smooth and well paved ways in cities to the narrowest, steepest and roughest hiking trail somewhere in the middle of nowhere on a mountain.
No sane router can safely infer anything from just the highway=path tag besides the most basic ‘you can probably walk on it if you’re steady on your feet’. Using e.g. a wheelchair? Anyone’s guess, who knows. Using a bike? ¯\_(ツ)_/¯ [1]
Many bike routers heavily penalize highway=path without an explicit bicycle=* tag for good reason, not (only) because of the unclear legal situation but mostly because of the physical conditions. The same is probably true for horse routers and if they don’t do that they are foolish (although legal concerns are more weighty there since horses are much less often allowed on ways than bicycles).
This is not a problem with the “lets tag it explicitly” approach, this is a problem with a rather ill defined tag that has no universally (or even regionally) applicable semantics. The explicit tags here do exactly what they are supposed to do, which is clarify the situation with well defined universally applicable information (albeit partially) [2]
Path controversy - OpenStreetMap Wiki
Richard's Diary | What does the path say? | OpenStreetMap ↩︎
Incidentally, tagging your shared bike/pedestrian ways as highway=cycleway + foot=designated+ segregated=yes/no would mostly solve the issues you mentioned, simply because the semantics of that tag are much more well defined and data consumers know what to expect from such a way. ↩︎
This is a great example, thank you. Because highway=path is so vague, you need a lot of explicit tags to make it work the way you want. highway=path + (access=no) + bicycle=designated is equivalent to highway=cycleway, and yet everyone would call this tagging inferior, because you should call it cycle way, if it’s a cycle way. The original proposal for highway=path even wanted to retire highway=footway, highway=bridleway, and highway=cycleway, but it was refused by 6:26 votes. And that’s pretty much the case I’m making for zebra crossings.
I dislike crossing_ref= mainly because it’s not a *_ref= . Prefer designation= legally, while *:template= or something better could be used for a set of physical layout.
Has anyone here argued for not tagging a zebra crossing as a “zebra crossing” somehow? I thought the point of contention was whether other secondary tags could be allowed or encouraged alongside crossing(_ref)=zebra despite some arguable redundancy.
The main similarity between the 2008 highway=path and crossing=* / crossing_ref=* proposals is that both proposals sought to consolidate the values of a primary key, relegating some finer distinctions to a secondary key. However, the highway=path proposal further assumed that, for example, a path is a “cycleway” if and only if it has bicycle=designated. In other words, a renderer should equate highway=path bicycle=designated with highway=cycleway, full stop. These days, with routing engines relying heavily on the same access keys, sometimes too much, that old assumption is difficult to reconcile with the widespread view that access tags correspond to legal restrictions, and who knows what access restrictions to infer. If the highway=path proposal had attempted to replace highway=cycleway with highway=path bicycle=yespath=cycleway, we might be in a different situation.
The tangent about carpark crossings earlier highlights another problem with the highway=path proposal. Sometimes a local authority might officially call a path a “shared use path”, carefully avoiding favoritism toward cyclists, but in practice, even the pedestrians and horseback riders customarily call it a cycleway or bike path, so naturally a novice mapper will reach for the Cycle Path preset. This is exceedingly common in some countries, to the point that some routers have decided to assume that all highway=cycleways are walkable unless otherwise noted.[1]
Similarly, if a zebra-striped crossing in a UK carpark lacks the legal authority of a zebra crossing, but it walks and quacks like a zebra, some mappers may be inclined to classify it as a crossing(_ref)=zebra anyways. So when the main argument for preserving crossing=zebra rests on common sense,[2] it’s worth reflecting on whether there’s really a common understanding. What is really the essence of a zebra crossing – the legal ramifications, or the physical appearance?
For what it’s worth, I think crossing_ref=* never took off in the U.S. mainly because people here generally don’t name crossing configurations as if they’re entrées on a menu. The one obvious value would be crossing_ref=hawk, because a HAWK crossing has many distinctive features, including a specialized vehicular signal accompanied by a wordy sign (necessary for educating even experienced motorists), which we couldn’t begin to describe with other tags. Other than that, the official distinction between crossing and crosswalk is already relatively obscure, let alone Utah’s zebra crosswalk. In defiance of national regulations, California uses crossing:markings:colour=yellow to warn of a nearby school and sometimes requires crossing:markings=lines for accessibility reasons, but a typical layperson wouldn’t know to tag crossing_ref=school, and crossing_ref=clarification_for_sight-impaired_pedestrians doesn’t exactly roll off the tongue.
designation=* is underappreciated in general. I’ve been considering that key for places too, since border_type=* seems to rankle some folks. For better or worse, there’s a lot of momentum and history behind crossing_ref=*, so I’m wary of introducing yet another standard when we haven’t even sunsetted crossing=zebra yet. But I appreciate that it communicates a degree of formality that we don’t get from either crossing=* or crossing_ref=*.
Maybe someone with skill and inside the subject of highway=crossing (as node) and highway=footway/cycleway + footway/cycleway=crossing (as way) ** can visualize in a tree(s) structure graph what all the tagging combo’s look like at present. Than we might be able to see patterns. Right now I’ve concocted my own Custom Preset and crossing_ref is certainly not in it ***.
** Taginfo says there’s 150K cycleway=crossing, over here 9 out of 10 a combo with foot too and thus the tag segragate=yes/no needed, crossing that have both strisce pedonali (zebra) and dot marking which signify the crossing is also used by cyclists, but that is newish here.
*** Think I started a crossing_ref topic WTH when someone came to town and started swapping many zebra tags to the crossing_ref version. (A long time ID user on checking). Questioned it with mapper, zero response.
Fully agree with that part.
I don’t think it makes sense to split the physical layout and the legal designation in two tags, since these will always appear together.
But even if we agree on one tag I’m not sure if deprecating a tag and introducing a new one with exact the same meaning just because the key sounds better is the way to go.
I consider replacing crossing_ref=* out of scope for this proposal anyway, since that decision would be completely unaffected by the decision about crossing=zebra and vice versa.
Everybody here wants to have zebra crossings tagged, the question is just about the how.
Combined with the problem that only certain countries have zebra crossings (with zebra markings), while others just have zebra markings.
They can be different. In UK, a Zebra Crossing on =cycleway doesn’t have Belisha beacons, nor zig-zag lines.
Perhaps in your jurisdiction. In mine, we are still waiting for the judges in charge to weigh in on this. Until to date, they declined to to that.
So you have judges considering the legal consequences of OSM tagging? That’s when you know the project has really gone mainstream 
Something has been lost in translation – an English idiom for that is “the jury is still out there”. Which, taken literally, also has legal consequences. 
Something like this just for everything?
Is there any progress on this proposal?
I am currently mapping/tagging/retagging thousands of zebra’s in Nederland, based on a data source of zebra’s spotted from the air. An outcome of this proposal would be welcome and could very well lead to a fast retagging project.
The zebra project in Nederland: my contribution (skip this if you don’t like long boring stories peppered with personal opinions!)
Overall mapping picture: the full historic mess of tagging schemes and improvs. Presets and actual tagging reflect this mess.
Data users can ignore zebra’s, or apply this rule: if the value for crossing, crossing_ref and/or crossing:markings is zebra, it’s a zebra, so rendering could show a zebra, routing could apply a time penalty, and navigation could show/announce the crossing as a zebra.
I am just adding information, not implementing a certain tagging scheme, so for already mapped crossings I leave the tagging as it is, except for adding the value “zebra” in the simplest way possible. E.g. if it’s highway=crossing+crossing=marked, I change “marked” to “zebra” which simply adds the information that its zebra marking. In Nederland, pedestrian priority is implied.
If crossing=uncontrolled, I don’t change that information. If there is a crossing:markings=yes (or =no) tag I change yes to zebra, just adding information without altering the tagging style.
(BTW I think just crossing=marked does not add any information to highway=crossing; if you know it’s marked then please enter the type of marking or don’t bother to tag it! And it does not help to add crossing:markings=yes to crossing=marked;
I I have a complex junction with zebras all around, usually with different taggng styles, I simply select all the nodes and add crossing_ref=zebra, leaving all other tags untouched.
In short, I am not solving the mess, and not shifting the tagging style in any direction, because I want to keep everybody happy and not mess with any mapper’s preferences. I confess I like crossing=zebra because of its simplicity for mappers and data users.
Of all the possible ways forward on this issue, crossing=zebra is the largest step backwards. Granted, it does harken back to a simpler time…
I agree, but my current mission is not to enhance the tagging scheme. It is to add information. crossing=zebra is a step up from crossing=marked, and it is alive in the database.
In Nederland, it’s no problem to add crossing:markings=zebra to all crossing=zebra and crossing_ref=zebra nodes. It’s another thing to get rid of crossing=zebra and crossing_ref=zebra: both have usage and support among mappers. We could end up with triple redundancy (might be good for ISP links, less so for the database).
It is currently in hibernation. I need to rewrite some parts about crossing_ref, particulary so that misconceptions like
don’t arise anymore.
I should get some free time for that soonish to bring it to a vote in Q1 2025.
