It changed the key description in the infobox of crossing_ref from “Used to reference a specific type of crossing” to “Used to reference a specific type of crossing markings”. The changeset comment was “this is only about the markings”.
To me this is incorrect: crossing:markings is only about the markings. crossing_ref is about a lot more, though what exactly is country-specific.
For me what matters is the value of it. Therefore I urge you to keep it simple. KISS as somebody mentioned. I personally wish the key was called pedestrian_crossing and alternatively crosswalk (for the US).
The value is not in the details but in the fact that we know there is a pedestrian crossing.
Imagine you are a third-party software developer making satnav applications. How easy is it to add a feature to warn drivers that there is a crosswalk/pedestrian crossing ahead, based on OSM? (be careful, slow down,…)
So, we need to get it ‘right’ into the data so navigators can use it for driving and pedestrian safety ideally with a pro-active function, tell driver even when no route is programmed and followed.
An Italian website
talks about ‘strisce pedonale’ (literally striped footway, but pedestrian crossing in proper translation). A Q2-2023 report notes global 270,000 pedestrian crossing incidents of which 22% have fatal consequences, shocking. I’m hoping that in base highway=crossing as node and highway=footway+footway=crossing is enough to put the navigators on notice, the rest just being informational with crossing=zebra being the most general accepted uncontrolled type and crossing=traffic_signals for the controlled. Certainly several 3D renderers seem to understand crossing=zebra… the below freshly mapped block with said tag, but it’s all well possible that just highway=crossing was enough of a single node tag to active this render.
It’s directly below, wrongly named “Crossing type name (UK)”.
But as for the “what’s up with crossing_ref”, the question has been answered multiple times: it’s a collection of markings, priority and things like signs/beacons. It’s unclear, whether crossing=uncontrolled implies priority to crossing pedestrians and/or bicycles, so each and every country and community interpretates the meaning of marked and uncontrolled differently and the folks from the UK were being smart and put a whole zoo into crossing_ref. Everyone was rubbing their eye at penguins, puffins and pegasus, instead of defining their own set, or coming up with a proper solution (me included of course).
My guess: Sudden drops are caused by automated edits in France, changing crossing=zebra to crossing_ref=zebra. Some discussed and documented, some apparently not.
So the Wiki page for crossing_ref has a warning that the page contains “questionable, contentious or controversial information” and this is leading you to conclude that crossing=zebra is the preferred tag?
That is understandable, but I don’t think it’s intended. It’s actually ironic, if crossing_ref was invented in 2007 specifically to avoid the issues with crossing=zebra.
Maybe the page for crossing=zebra needs a similar warning, or simply a note that crossing_ref=zebra is a more popular way of saying the same thing?
The twice screenshotted standard JOSM preset is curious in that if you’re in the UK you could end up with crossing:markings and crossing type (crossing_ref) carrying the zebra value.
In Austria, the crossing=uncontrolled implies pedestrian priority. Otherwise it would be a crossing=unmarked. No need to add a crossing_ref to record, that there are zebra stripes on the ground, crossing:markings can do that and does not come with the additional ballast.
I’d prefer that crossing=zebra would be deprecated, because signalled crossing also always have zebra stripes. Same goes for crossing=marked There are no unmarked signalled crossings here.
As far as I know, you have Radfahrerüberfahrt in Austria, which are marked crossings where cyclists have priority, but necessarily pedestrians. I mean these:
compared to these:
Or do pedestrians always have priority on crossings where the markings are only for the bicyclists?
There is a bit of debate, if pedestrians are even allowed to use cycleways. In my opinion, they can use them just as any other road/street, i.e. keep to the (preferably left) side of the surface. Comments on the law are split, a decision by some higher judicial board wished for, yet these boards up to now declined to take the chance or burden. I fear, there is no answer to your question.
Well, all I can say is that in Germany, when you have a combined or segregated foot/cycleway that crosses the street, it’s perfectly legal and common that only one type of transport gets priority at the crossing. I was simply assuming things are the same “down there” ;o)
I understand the allure of this approach, but it is not without tradeoffs. For one thing, it assumes a system of implied defaults, hopefully documented in machine-readable format. (Please let it not be wikitext.)
Any system of implied defaults is presumptuous when its authors lack the necessary perspective to come up with fair and intuitive global defaults. After all, we have just discussed an innocently misapplied use of “uncontrolled” from one mailing list post that our standards and presets doubled down on, despite pleas by well-informed mappers who had been tagging it according to its real-world meaning for years. This experience shows that tagging discussions need to be more representative of the wider world before we can begin shoehorning the world into an elegant system.
It may seem like we can simply handwave about regional differences by letting each region define their own tags. This comes with a tradeoff too: data consumers are less able to do anything useful with a geographically fragmented tagging scheme. That’s OK for something like school classification, for which we probably care more about enabling personal queries and regional renderers than global geocoders. But when it comes to routing pedestrians via crossings, there are relatively universal concepts like “there are markings” and “pedestrians wait for a signal”. It would just be unfair to make renderer developers become familiar with a variety of legal systems just to respond to those basic attributes. Whereas something that takes a lot of explanation, like the six required phases of a HAWK crossing, should definitely be a regional tag.
There are days when I tire of the many crossing:* subkeys for railway level crossings. Too much clicking. Because checkboxes are inconvenient, we could scrap the elaborate OpenRailwayMap tagging scheme and replace it with a simpler crossing_ref key. In my neck of the woods, there would be seven alphanumeric values corresponding to presets with self-evident names like “Flashing Light Signal Assembly with Automatic Gate Arm” (crossing_ref=9). Router and renderer developers would ensure compliance with the implied defaults in this wiki table. We’d deprecate crossing:saltire and crossing:bell as redundant and reduce our usage of crossing:barrier to less than 20% of what it is now.
Maybe if we were around in the early days of OSM, we could build up the social structures and processes necessary to make an approach like this work well. But as things stand, we have to make do with a more loosely coupled system. It’s actually not that bad thanks to presets – just don’t confuse presets with JOSM presets.
Maybe it has something to do with advocacy for crossing=zebra, but as a holistic classification rather than solely an indication of markings? It isn’t clear to me if that has ever been a prevailing viewpoint.
A couple months ago, I added a section to each of the crossing=* pages indicating which tags are supported by which data consumers, as opposed to the JOSM presets that flood taginfo’s Projects tab. Overall, the crossing=unmarked/zebra/traffic_signals, crossing=unmarked/uncontrolled/traffic_signals, and crossing=unmarked/marked/traffic_signals schemes all enjoy roughly the same amount of support among renderers and routers, which is not to say very much. crossing:markings=* and crossing:signals=* also have nearly as much support among routers as either of those schemes, despite being much more recent introductions. crossing_ref=zebra is supported by a few renderers as an alias of crossing=zebra, but no router understands it as far as I can tell.
