I personally don’t mind either way. I am just alerting those that might. Please don’t shoot the messenger, but instead comment on the wiki talk page. Commenting here is just a comment.
The scope of the tag was expanded by one unhelpful iD-ism, but now iD is encouraging users to devalue crossing:markings by spamming the database with useless crossing:markings=yes tags.
But then we need a crossing:poles=stripy and crossing:light=belisha_beacon/blinking_yellow_orb and restriction=no_parking and crossing:markings:nearby=zigzag and crossing:restriction=no_jaywalking_nearby.
Or just crossing_ref=zebra, as crossing=* keeps changing between zebra ↔ uncontrolled ↔ marked at the whim of iD and individual editors.
Belisha beacons and zigzag lines are not required for zebra crossings on cycle tracks.
If it’s desirable to micromap the zigzag line restriction, that is parking:both=no + parking:both:restriction=no_stopping + overtaking:both=no for the extent of the zigzag makings on the highway=* way (usually 8-18 markings, but may be as low as 2), not the crosing node.
There’s no need to map crossing:restriction=no_jaywalking_nearby as it doesn’t exist. I don’t believe that the power to create regulations prohibiting jaywalking within 100yds of a crossing in s. 25(2)(a) RTRA 1984 has ever been used in the 40 years it’s existed and it’s certainly not in Schedule 14 TSRGD 2016. It’s not even a SHOULD in the Highway Code.
OK, it looks like I should have listed 6 tags for the new bloated tagging rather than five, that’s much better.
This whole proposal seems like an exercise of changing the world to satisfy the whim of iD rather than getting iD to actually reflect what the tags mean. One infamously capricious bit of editing software shouldn’t be wagging the dog.
So glad I have JOSM with the rapid adding and tweaking of custom presets, to include a field for raised table and why I don’t know but since it’s asked when on table, kerb is flush.
Mappers will continue to use the value of crossing=* they prefer. I mostly map in Greater London, where there is only one node tagged with crossing=zebra (and the useless iD-ism of crossing:markings=yes): n11695153050
Yes indeed, the go-to tag for me is usually crossing:marking=zebra and have found you can add a colour scheme when not standard black-white. Many on tables here have a green fringe. All in paint of dubious quality not made for our clime and traffic density. Dots becoming more popular where the crossing is also used by bikes.
Today there is, in on 2015-01-01 it was 547 (actually I think I queried elements rather than nodes). Is the change really contributor preference? I’m not really convinced it is. Back then only two users had double digit percentages for most recently edited, between them less than 30% of the elements were associated with them. Today within London over 30% of crossing_ref=zebra elements were most recently changed by a single user which feels less like a consensus and more like a personal preference (although they seem to leave it alone on ways).
What I find interesting is that Overpass turbo reports 1269 “lines” in London with crossing=zebra so it’s clearly liked by something.
On the iD-ism, the fact that searching for zebra and clicking on the first preset results in a generic crossing:markings=yes feels actively malicious. If iD doesn’t want to recognise the term then it shouldn’t return anything if you search for it.
In the UK, a crossing with crossing:markings=zebra;dots (usual road markings for a zebra crossing) or crossing:markings=zebra is not controlled by traffic signals.
A crossing=traffic_signals will have either crossing:markings=dots (usual road markings for pelican and puffin crossings), crossing:markings=dots;surface, crossing_markings=surface, or crossing:markings=no
For marked and signal controlled I use crossing:markings=yes + crossing:signals=yes. For marked without signals I use crossing:markings=yes + crossing:signals=no. I replace yes with more specific positive values as appropriate.
For marked and signal controlled I use crossing:markings=yes + crossing:signals=yes. For marked without signals I use crossing:markings=yes + crossing:signals=no. I replace yes with more specific positive values as appropriate.
In principle this will work well, I am supporting this tagging, particularly if the shortcut is not deprecated (e.g. one could tag crossing=zebra and have crossing:markings=zebra crossing:signals=no implied)
I guess we would also need a tag for policemen controlling a crossing, additionally or only (although those will likely not be there 24/7, but the same can be said for many traffic signals which might be turned off e.g. at night)
For pedestrian crossings controlled by traffic lights, I think it would be important to see whether vehicles can have green light at the same time as pedestrians (e.g. for safety reasons one might want to avoid these).
One feature, one OSM element. Or in this case, one tag, one purpose. Right now crossing=(un)controlled and crossing=(un)marked are in conflict with each other. Using one key per crossing feature, all under the same crossing:*=* tagging scheme would be a lot clearer.
One feature, one OSM element. Or in this case, one tag, one purpose. Right now crossing=(un)controlled and crossing=(un)marked are in conflict with each other.
crossing=marked is just a crazy step back, introduced by iD to replace crossing=zebra which was well defined. crossing=unmarked is fine, it means a place used for crossing but without markings or infrastructure.
one feature one element is not related to one tag one purpose, which is not a rule AFAIK. What do you say about „service“?