[RFC] Feature Proposal - Deprecate crossing=zebra in favor of crossing:markings

Minh_Nguyen · 2024-07-01T14:38:22.265Z

Nadjita:

An example, why the “let’s tag it explicitly” approach can be problematic, is shared bike/pedestrian ways in Germany. We tag them with highway=path + foot=designated + bicycle=designated + segregates=yes/no. But that would also allow horse riding on these paths, yet no one adds horse=no, or cared about small_electric_vehicle=*. So in order to “know” that horses are forbidden on these roads, and small electric vehicles are allowed, the router would have to start guessing which situation is tagged, instead of blindly following these tags.

Just to be clear, I’m not suggesting that these two approaches are mutually exclusive. crossing_ref=zebra seems to be the most informative tag for a zebra crossing in the UK, but other secondary keys can serve as a backstop for less sophisticated data consumers. To me, there’s little harm in allowing these other keys to be used in combination on a best-effort basis.

Maybe it seems obvious to us that a zebra crossing in the UK would be marked with zebra stripes, but inevitably there will be a long tail of obscure designations as well. For example, in Utah, a zebra crosswalk consists solely of zebra stripes – no Belisha beacon. But the stripes alone denote whether the motorist must wait for the pedestrian to clear the street.

We don’t have an established tag for these rules, and we can’t expect any armchair mapper to know them. Compare this to markings or signalization, which a mapper can easily observe and which data consumers already consume – this is what I mean by a basic characteristic. A (still hypothetical) data consumer that needs to know the specific traffic rules at each crossing may have to implement some heuristics based on crossing:markings=zebra or, if they’re lucky, crossing_ref=US:UT:zebra. You may be shocked at this “guessing”, but such informed guesses are the bread and butter of any OSM data consumer.

Nadjita:

Another problem would be if the legislation for zebra crossing changed. Let’s consider a country that explicitly forbade riding your bike on a zebra crossing to get to the other side, now starting to allow bicycles. If they were tagged with crossing_ref=zebra, the only thing that needed to change was the documented “template” value of bicycle=no to bicycle=yes, and not millions of crossings.

This is an argument against tagging nitty-gritty details that we’ve inferred. I agree that we probably shouldn’t tag crossing:restriction=no_jaywalking_nearby on a UK zebra crossing, as suggested tongue in cheek in the UK thread. That detail is merely an inference on our part. The rule is written on paper and can change on paper. But even if the authors of the TSRGD or Highway Code decide tomorrow that zebra crossings shall be rainbow-colored, they cannot magically cause rainbow paint to be splattered upon all the country’s zebras overnight.

Access restrictions in some countries are more like rules on paper, depending on things like zebra stripes rather than explicit signs. Unfortunately, the concept of default access restrictions for routing has been mostly in the realm of wishful thinking for the better part of this project’s history. But I don’t think the UK has completely avoided tagging access restrictions just because they can technically be inferred from other tags.

Nadjita · 2024-07-01T15:25:27.338Z

Minh_Nguyen:

Just to be clear, I’m not suggesting that these two approaches are mutually exclusive. crossing_ref=zebra seems to be the most informative tag for a zebra crossing in the UK, but other secondary keys can serve as a backstop for less sophisticated data consumers. To me, there’s little harm in allowing these other keys to be used in combination on a best-effort basis.

I complete agree, especially considering that in the US, it varies from state to state. Sometimes it’s easier to map “a zebra crossing”, and sometimes it’s easier to map “zebra stripes on the ground”. The same goes for “A shared bicycle and pedestrian lane” in contrast to “red painting on the left side of the way”. Person A might know what it stands for, person B might only know what it looks like. Someone might then, later on combine all this into the common tagging of that situation.

Minh_Nguyen:

even if the authors of the TSRGD or Highway Code decide tomorrow that zebra crossings shall be rainbow-colored, they cannot magically cause rainbow paint to be splattered upon all the country’s zebras overnight

This is a good example why it’s so complicated to come up with templates in OSM: you never know which part of the template changes: the visible, or the invisible part.

The invisble part is “pedestrians have the right of way, bicyclists have to unmount and push their bike. Cars have to approach carefully. Pedestrians are not allowed to cross the road on any other place if they are within 40m of a zebra crossing. You are also not allowed to park 10m before or after a zebra crossing”

The visible part is: “there are white zebra stripes on the carriageway, plus sign X, plus criss-cross zig-zags, glitter an whatnot”.

So, ideally, people would never have to “map” the invisble template, but leave these rules in the wiki or whereever, whereas the visible part(s) can definitely be mapped if people want to, and should maybe be part of an editor template. The invisble bits, could simply change overnight, and a lot of people either don’t know, or don’t care about these.

All in all, it seems that there is a need for templates, both in OSM and the editors, and maybe for country-specific prefixes for some of them. In general, being a geo database, these prefixes should be inferable from the surrounding administrative borders, but again, it might be preferable to tag crossing_ref=UK:zebra for a zebra crossing based on the UK template just to be 100% specific. Maybe it’s even time to abandon crosing_ref and switch to a :template suffix to store these, so we could later on apply the same MO to other things than mere crossings. crossing:template=UK:zebra doesn’t even look half as bad as I feared. I’m just spitballing some ideas, I’m in no position to enforce any of this. But I’m happy someone finally brought the whole discussion to live, even though the proposal, as it stands, it very likely goinf to be rejected.

Minh_Nguyen · 2024-07-01T17:05:10.896Z

rskedgell:

We also have a lot of not-zebra crossings on private land like car parks and industrial estates in the UK. They have the zebra stripes, but no legal enforceable rules, give way markings, Belisha beacons, restricted area with zigzags, etc. I usually tag these with crossing=uncontrolled + crossing:markings=zebra + not:crossing_ref=zebra, which is a very unsatisfactory way of doing it.

Good point, I take it that neither laypeople nor specialists would refer to these as “zebra crossings” per se, correct? That would seem to translate directly into the tagging combination you’re using. I appreciate the use of the not:* namespace to ward off overzealous QA. Is it unsatisfactory because you’re searching for a better word for these crossings, or because you’d rather not manually apply all three tags each time you encounter such a crossing?

rskedgell · 2024-07-01T17:19:44.361Z

I’m pretty sure that lay people would still refer to them as zebra crossings, as I don’t think most people would realise the significance of the give way markings at real zebra crossings. It’s probably not in the Highway Code or Driving Theory Test.

I’m using the not: namespace because I can’t think of anything better

Minh_Nguyen · 2024-07-01T18:09:46.962Z

mimics=* strikes again!

Minh_Nguyen · 2024-07-02T01:51:23.497Z

Thanks for helping me make sense of the current tagging situation locally. For a broader perspective, a Ohsome query for all crossing=* values in a wider area around Cincinnati illustrates the rise of various crossing tagging ideas over time. It’s a pastiche rather than a palimpsest: mappers like me haven’t made much of a dent in retagging existing crossings, because we have so many more still to tag and classify.

A stacked area chart of the crossings in the Cincinnati combined statistical area from January 2012 to present, color-coded by crossing=* value. A spurt of crossings in 2013 was entirely unclassified. crossing=zebra slowly began to appear around 2015, followed by a spurt in 2018, at the same time that crossing=traffic_signals made a big entrance on scene. crossing=marked, crossing=unmarked, and a tiny minority of crossing=uncontrolled followed in 2018. The newer tags mostly have not eaten into the older ones, but the share of unclassified crossings went down significantly with each new tag introduction.2258×1920 337 KB

These days, I replace crossing=zebra with the tag du jour whenever I come across one, but I haven’t been actively seeking them out. At some point, I’ll probably make a more concerted push to add crossing:markings=* and crossing:signals=*, but I probably won’t bother perfecting the crossing=* values. At the current rate, crossing=unmarked and traffic_signals will get replaced with shinier crossing=* values in a couple years anyways.

The situation nationally is a bit different. With many more mappers working independently on crossings, these statistics are less skewed by the preferences and priorities of individual mappers like me. It’s possible to identify some inflection points in this graph that correspond to changes in iD or later id-tagging-schema. However, I think the share of unclassified crossings is the real story here. Anyone sufficiently motivated could establish a real competitor to the legacy tagging schemes without even stepping on any toes. And this doesn’t even consider all the crossings that have yet to be mapped.

A stacked area chart of the crossings in the United States from January 2012 to present, color-coded by crossing=* value. Overall, crossing coverage has risen along a logistic (?) curve. crossing=marked ate into the share of crossing=zebra in 2020, but starting last year, crossing=uncontrolled has significantly eaten into the share of crossing=marked. Otherwise, the various values have grown independently of each other, and the remainder (mostly unclassified) remains significant at roughly a quarter of all crossings.2258×1918 370 KB

Bauer33333 · 2024-07-02T10:16:53.158Z

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:

grafik1387×674 43.4 KB

and Germany:

grafik1373×667 44 KB

crossing=uncontrolled vs. crossing=marked is a whole other story here than in the US. But crossing=zebra still stays the absolute minority, even in the UK the share isn’t really higher than in the US. It has even been a lot lower historically (around 2018).

Tordanik · 2024-07-02T12:55:53.185Z

Nadjita:

I also think that if a single tag, crossing_ref=zebra, can replace 8 other tags, reduces the risk of mis-tagging, doesn’t need editor support, and is widely understood, then it’s probably superior to tagging every single detail.

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!)

Minh_Nguyen:

To me, there’s little harm in allowing these other keys to be used in combination on a best-effort basis.

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.

Minh_Nguyen · 2024-07-02T14:38:47.803Z

Tordanik:

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.

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.

Tordanik:

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.

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.

Tordanik:

I guess much of this problem is a symptom of the relatively low-level tooling landscape for consuming OSM data.

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.

Bauer33333 · 2024-07-02T17:13:49.461Z

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.

Woazboat · 2024-07-03T01:17:56.701Z

Nadjita:

An example, why the “let’s tag it explicitly” approach can be problematic, is shared bike/pedestrian ways in Germany. We tag them with highway=path + foot=designated + bicycle=designated + segregates=yes/no. But that would also allow horse riding on these paths, yet no one adds horse=no, or cared about small_electric_vehicle=*. So in order to “know” that horses are forbidden on these roads, and small electric vehicles are allowed, the router would have to start guessing which situation is tagged, instead of blindly following these tags.

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. ↩︎

Nadjita · 2024-07-03T05:51:35.396Z

Woazboat:

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.

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.

Kovoschiz · 2024-07-03T07:03:40.699Z

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.

Minh_Nguyen · 2024-07-03T09:02:05.916Z

Nadjita:

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.

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=yes~~ path=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.

Kovoschiz:

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.

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=*.

iD tried to mitigate this tendency with a Cycle & Foot Path preset, which has been contentious in some countries. ↩︎
Vietnamese speakers would call this phenomenon thấy mặt đặt tên, literally, “see it, name it”. ↩︎

SekeRob · 2024-07-03T09:36:30.188Z

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 ***.

image329×510 21.6 KB

** 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.

Bauer33333 · 2024-07-03T11:53:56.764Z

Kovoschiz:

I dislike crossing_ref= mainly because it’s not a *_ref= .

Fully agree with that part.

Kovoschiz:

Prefer designation= legally, while *:template= or something better could be used for a set of physical layout.

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.

Bauer33333 · 2024-07-03T11:56:28.202Z

Nadjita:

And that’s pretty much the case I’m making for zebra crossings.

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.

Kovoschiz · 2024-07-03T13:07:00.036Z

They can be different. In UK, a Zebra Crossing on =cycleway doesn’t have Belisha beacons, nor zig-zag lines.

Hungerburg · 2024-07-03T22:46:39.280Z

Nadjita:

highway=path + (access=no) + bicycle=designated is equivalent to highway=cycleway,

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.

SomeoneElse · 2024-07-04T09:57:29.454Z

Hungerburg:

In mine, we are still waiting for the judges in charge to weigh in on this.

So you have judges considering the legal consequences of OSM tagging? That’s when you know the project has really gone mainstream