With the approval of the crossing:markings=* proposal there is now a satisfactory way of tagging whether a crossing is marked or not regardless of the crossing being uncontrolled or having traffic signals. For signals, there is crossing:signals=* which fulfills the same role but has not been formally approved yet.
As such, I propose to approve crossing:signals=* and additionally deprecate crossing=* (except crossing=no).
Please sound off your feedback and comments here, the corresponding mailing list or on the wiki talk page.
I am aware and my intention was to propose both together. I have discussed the similar proposal you linked and will support approving that one should this one fail. The latter one doesnât include the deprecation of crossing=*.
Have you already had contact with data consumers about this? When deprecating such a common Key (7 million uses) I think your proposal should have a more detailed migration plan.
There should also be a clear plan for updating editors (iD, StreetComplete, etc).
iD was recently updated to include support for crossing:markings=* but in doing so changed crossing=marked to crossing=uncontrolled for its âMarked Crosswalkâ preset and will likely need to be updated again pending another change to crossing. Current discussion
it is probably better to wait for reply of @riiga - but you can copy existing abandoned proposal and continue proposal process (or take over existing one if fully abandoned and you like it as is and author agreed or is not responding for looooong time)
This proposal is more specifically about formalizing crossing:signals=* along with the addition of two optional values that are useful in some regions. I would prefer tackling this issue separately from the idea of deprecating crossing=*. The main thing holding up the crossing:signals=* proposal is what to call separate and shared. But we should probably discuss that in a separate thread to avoid confusion.
Whatâs missing on getting it through, you think? Although I see the value of deprecating crossing, I fear that part could add some friction. In that sense @Minh_Nguyenâs proposal could be the way to go. But, as he mentions, he has naming issues to figure out (which amount to solving the hardest problem in computer science). Just getting crossing:signals=yes/no though would get us far enough for my purposes.
Bump!
The Dutch are thinking about cleaning up their crossings. Itâs the same mess as everywhere, due to different and conflicting historical tagging, conflicting tooling and different opinions about categories and about which aspect is more important. Deprecation of crossing=* values (except =no) has little to no support here, but using crossing:markings=zebra|dots|dashes|yes|no is accepted and usual tagging.
The key crossing:signals is also established but a part of the Dutch mappers feel that this should not be necessary because crossing=traffic_signals and crossing=uncontrolled are the main types with crossing:markings=* as a secondary tag.
Another part of Dutch mappers feel that crossing=zebra should remain the duck tag for quick entry of zebra crossings.
Having seen some of the international discussions I think this pretty much is the general situation.
My personal conclusion
I think any proposal which includes deprecation of crossing=* will meet lots of opposition. I think that the max that can be achieved is approvement of crossing:markings=zebra|dots|dashes|no|yes and crossing_signals=yes|no in addition to any of the existing crossing=* tag.
Thinking about cleanup:
crossing:markings=yes only has temporary value as a âtranslationâ of crossing=marked, to free up the crossing key. It should be followed up by a specification project of MR mission, to add the actual markings.
Same for crossing:markings=no as a âtranslationâ of crossing=unmarked.
PS
I just had the pleasure of handling an uncontrolled turbo roundabout junction with 20 pedestrian crossings (zebraâs) and 12 bicycle crossings (dot markings).
