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).
I donât see a point in doing that, especially since a deprecation doesnât mean that a tag cannot be used or must disappear immediately. It just means that the wiki wonât recommend using the tag, validators will point out uses of the outdated tag, editors will recommend to replace tagging, etc. There are no downsides to this and the other tags are already being used and supported by e.g. StreetComplete.
This should just be a totally separate proposal which is not conflicted by this one. It just introduces new values which will be more specific than just a simple yes. I see no issue in taking care of this proposal afterwards.
Most data consumers already support the proposed tags so this shouldnât be a problem. In case some of them donât, Iâd appreciate if someone went and suggested this to them.
This is the main thing that will heavily decrease the number of uses of the crossing=* tag. And deprecated status on the wiki is what will be a great reason for the devs to do so.
Deprecation despite active usage does not change the actual usage. It just diminishes the trust in the voting process. AFAIAC the crossing key is unneeded, but forced depreciation is contraproductive. Oh well, weâll see what happens over the coming decade.
Deprecating a tag doesnât fix the crossings. First (most of) the crossings need to be tagged with the new tags. For instance: 40.02% is tagged with crossing:markings and only 4.11% is tagged with crossing:signals. What is the plan if the crossing key is deprecated? Are all crossing key instances just removed from the database and thereby remove a lot of information? We canât retag them with the new tagging according to the changeover.
I would say itâs more important to make sure the ânewâ signal key is approved. The editors are updated to make sure every crossing gets these tags (markings, signals, crossing_ref (for UK)) and otherwise display a message the tags are missing. When a bigger part of crossings has these tags itâs time to think about deprecation, but for now they hold information otherwise missing.
As I previously described, the goal is to have editors like iD, JOSM, Vespucci to stop recommending the crossing=* tags, mark them as deprecated tags and make validators point out the usage of deprecated tags.
But yes, everybody can use what they want. I, for instance, like to still use cycleway:*=opposite_lane. The deprecation and change of templates will help those who only map based on templates and basically just go along with whatâs recommended, without any attachment to particular tagging.
But the editors (mainly iD) will still use e.g. both crossing=unmarked + crossing:markings=no. I donât like this approach. And it doesnât hurt to deprecate a tag that everybody agrees isnât needed.
