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

Minh_Nguyen · 2024-07-01T06:34:08.036Z

Yes, like designation=* and border_type=*, crossing_ref=* is intentionally regional. In another era, we might’ve come up with a more explicit syntax such as crossing:UK=zebra (compare place:CN=*, school:FR=*).

If mappers in one country are using crossing_ref=* counterintuitively, the problem is confined to that country. For example, over the years, some U.S. mappers have used crossing_ref=* to indicate marking patterns, such as zebra a.k.a. continental. When we approved crossing:markings=*, we also deprecated this usage of crossing_ref=* in the U.S. This made room for crossing_ref=hawk, which refers to an entire configuration.

Just as place=village place:CN=village and admin_level=8 border_type=village are common and valid combinations, crossing_ref=zebra isn’t exclusive of other crossing tags. crossing_ref=* reduces the pressure to micromap every minute detail about the crossing that’s already specified in uniform national regulation. But if a detail is so basic that every data consumer should get it right, even if it doesn’t know anything about the UK, then nothing stops us from tagging those more basic details explicitly. This is where presets come in, keeping each feature’s tags consistent and hiding the implementation details from users who don’t want to fuss too much about the crossings they’re mapping.

rskedgell · 2024-07-01T07:52:51.858Z

Minh_Nguyen:

Maybe also designation=zebra or zebra=designated for additional British tagging flair?

If we were to use something like designation=GB:zebra (or a country code prefix in some other tag) that would make it absolutely clear that we’re only referring to one where UK rules about pedestrian precedence and road markings apply.

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.

Nadjita · 2024-07-01T08:02:27.018Z

Minh_Nguyen:

nothing stops us from tagging those more basic details explicitly

There’s currently no way to tag who has priority/right of way on a crossing, which is probably the most interesting tag. Depending on the country you’re in, the right of way comes from a traffic sign, the zebra stripes on the ground, flashing lights, a combination of all, or sometimes from the designation of a crossing. I’m sure we’d all be surprised how this works in the different countries.

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. It feels like advertising to map every wall of a house separately, instead of “a house”, even though that’s probably not what you had in mind.

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.

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.

stevea · 2024-07-01T08:11:03.131Z

@Nadjita, that was a particularly helpful, highly informative post and I thank you for it.

dieterdreist · 2024-07-01T09:33:13.000Z

There’s currently no way to tag who has priority/right of way on a crossing, which is probably the most interesting tag.

agreed, I think mappers and people are typically assuming this is implicit. On top of the legal situation, there are also cultural habits. E.g. in Italy, pedestrians have the right of way on zebra crossings, but in the south of the country, motorists are typically expecting pedestrians to let them through nonetheless, and while you might have the legal right to walk first, it may be better advice to wait a second rather than going to the hospital for some weeks because you insisted on your right.
I think the situation is similar in other countries as well.
For practical usefulness, we would have to record what is the actual situation and not just the theoretical legal situation.

Bauer33333 · 2024-07-01T10:00:02.902Z

We don’t even have something describing the theoretical legal situation. All the way back from 2008 when crossing_ref first showed up everybody just assumed mappers and data consumers just know what the crossing names mean and imply and what areas they are valid in without ever taking a closer look at it and writing it down.
Same about crossing:markings now, the people saying it is just gimmick micromapping right now are somewhat right since no one knows what the markings mean in what country/region.
Looking back it is not really surprising everyone interpreted stuff differently. There is a need for someone looking into every countries legal books and writing that stuff down, like this global maxspeed list Default speed limits - OpenStreetMap Wiki but it is a lot of work.

SekeRob · 2024-07-01T10:35:49.553Z

There was a rule somewhere which said that if within 20-30 meter of a ‘zebra’, a pedestrian was obliged to use them. There is/was a rule also if a driver sees a pedestrian approaching a marked crossing, the driver is obliged to stop preemptively… both seriously ignored by both parties. You’re lucky if you put a foot on, drivers stop at the other half you’ve not reached yet continuing to fly past swiping your glasses and before you’ve crossed the half the gas pedal is hit and the creases leave your pants at your backside. Anyway now we see something new

image388×594 85.7 KB

image905×145 50.5 KB

Statements of obliged use of zebra and explicit full size signs at foot crossings for vehicle operators also seen in small on the yellow rim at left for the dyslectic.

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.