refactor crossing presets to use approved "crossing:markings" tag: add field for the new tag, change "Marked Crosswalk" presets to use "crossing=uncontrolled" tag and add preset for "Cycle Crossing With Pedestrian Signals"

[tyrasd]

The tag proposal crossing:markings was recently approved. This adds a field for this new tag to the corresponding crossing presets. (#589)

This also changes the tag used by the "marked crossing" preset from crossing=marked to OSM's accepted crossing=uncontrolled.

preset	before this PR	changed in this PR
Crossing With Pedestrian Signals (vertex)	highway=crossing + crossing=traffic_signals	added field for crossing:markings
Crossing With Pedestrian Signals (line)	highway=footway + footway=crossing + crossing=traffic_signals	added field for crossing:markings
Cycle Crossing With Pedestrian Signals	N/A (#568)	highway=cycleway + cycleway=crossing + crossing=traffic_signals + field for crossing:markings
Marked Crosswalk (vertex)	highway=crossing + crossing=marked	highway=crossing + crossing=uncontrolled (#408) + field for crossing:markings
Marked Crosswalk (line)	highway=footway + footway=crossing + crossing=marked	highway=footway + footway=crossing + crossing=uncontrolled (#408) + field for crossing:markings
Marked Cycle Crossing	highway=cycleway + cycleway=crossing + crossing=marked	highway=cycleway + cycleway=crossing + crossing=uncontrolled (#408) + field for crossing:markings
Unmarked Crossing (vertex)	highway=crossing + crossing=unmarked	(unchanged)
Unmarked Crossing (line)	highway=footway + footway=crossing + crossing=unmarked	(unchanged)
Unmarked Cycle Crossing	highway=cycleway + cycleway=crossing + crossing=unmarked	(unchanged)
Cycle & Foot Crossing	highway=cycleway + cycleway=crossing + field for crossing	added field for crossing:markings

It is now possible to tag an unmarked crossing with traffic lights by using the Crossing With Pedestrian Signals preset and using the no value in the new field for crossing:markings. (#507)

[tyrasd]

I hope there will be continued openness to evolving these presets as further proposals reorient the crosswalk tags away from a one-size-fits-all model

Definitely :+1:

As I see it, this is only the first small step towards a more logically, structured approach of mapping road crossings. Further steps would be the incorporation of crossing:signals (keeping the crossing tag as an optional field), finished by by dropping the crossing field after a reasonably long phase-out period. Unfortunately, the proposal for crossing:signals seems to be quite inactive at the moment. I've left a comment stating my general support to further go into this direction.

[zekefarwell]

Unfortunately, the proposal for crossing:signals seems to be quite inactive at the moment.

I'm not sure why this matters. Although "approved", crossing:markings is just months old with very little usage (~2000) so far. crossing:signals has been in use for several years and has four times the usage (~8000). In the grand scheme of things, the usage of both tags is absolutely tiny compared to crossing with over 6 million uses.

https://taghistory.raifer.tech/#/crossing:markings/&/crossing:signals/

If you're going to start populating crossing:markings it would make sense to start populating crossing:signals as well in order fully solve the problem. On the other hand if you think it's too early to start populating crossing:signals, then it's also too early to start populating crossing:markings and neither should be implemented yet. Personally, I'd say go ahead with both.

[mxxcon]

crossing:markings proposal was approved only 10 days ago so few people are aware of it and as of right now I don't think any editor has presets for it, so it's natural for its usage to be low for now.

[zekefarwell]

This also changes the tag used by the "marked crossing" preset from crossing=marked to OSM's accepted crossing=uncontrolled.

Changing from crossing=marked to crossing=uncontrolled seems out of scope, given the title of the PR doesn't mention this. I suggest either limiting the PR to only the crossing:markings tag, or changing the title of the PR to: Crossing presets: replace "crossing=marked" with "crossing=uncontrolled" and add new "crossing:markings" tag.

[tyrasd]

I'm not sure why this matters.

It matters in this case because not everyone agrees whether the crossing:signals tag should be used or not (see example). The proposal process exists “to document that a rough consensus exists within the community on how to model and tag a feature”. For the crossing:signals this is especially relevant because the tag might (or might not, depending on how the proposal will actually be formulated) render the existing—millions of times used and approved—crossing tag partially obsolete. This needs to be clarified before I as a maintainer can start working on adding the tag.

I hope this clarifies your question. Might I add that the proposal process is a well documented, reasonably easy and open process, which you should not be afraid of if you're confidently supporting a specific way to tag features. I guess the best way to further the drafted proposal would be for you or anyone who's interested to get in touch with the author (which I think is @Nbolten) to collaborate on finishing the proposal (which I think needs to at least be updated to incorporate the recently added crossing:markings tag) and eventually bringing it to the RFC phase and a vote.

[tyrasd]

Changing from crossing=marked to crossing=uncontrolled seems out of scope, given the title of the PR doesn't mention this

Sorry for missing this in the title. My intention was to keep the title short, but I guess it is only fair to include every important detail in the title for larger changes such as this one. I've changed the title now.

My intention behind switching out crossing=marked for crossing=uncontrolled was to bring the used crossing tags in line with the approved values of the crossing tag. I'd be open to omit this tag change if arguments can be made why this would be a bad choice. //edit: and as I said before, I hope that eventually this change would not even matter because if crossing:signals were approved, the presets can be refactored to not need the crossing tag anymore and the tag be phased out.

[zekefarwell]

The proposal process exists “to document that a rough consensus exists within the community on how to model and tag a feature”

I am familiar with the proposal process and am generally in favor of it, however it is not required for a new tag to become established. There isn't even a rough consensus in the community that the proposal process documents a rough consensus. Many prominent voices consider the proposal process largely irrelevant and claim it has no bearing on anything but the wiki itself. A recent example:

The proposal process determines how tags are documented on the wiki. Nothing else. You are free to use whatever tags you like in OSM no matter what the wiki says. https://community.openstreetmap.org/t/using-the-forum-as-the-main-discussion-platform-for-tagging/3030/26

WIth this being the case, I consider the 8000 uses of crossing:signals and its clear upward trajectory over the past few years to be a clearer indicator of mapper support than the 29 votes in favor of crossing:markings. I understand you want to be very careful as a maintainer, but it seems clear to me that mappers have demonstrated over the past few years that crossing:signals is a tag they want to use and it would be reasonable to add to the iD presets in some way. Perhaps if you don't want to take too strong a stance, it could just be added as an optional field that is not pre-populated by preset selection.

I guess the best way to further the drafted proposal would be for you or anyone who's interested to get in touch with the author (which I think is @nbolten) to collaborate on finishing the proposal

I may find the time and energy to help with this if it is truly the only way you'll consider adding support for the tag. However, it seems unnecessary to me at this point and it feels like wasted effort when many in the comminunity consider approved proposals essentially meaningless.

[tyrasd]

the proposal process […] is not required for a new tag to become established.

I don't disagree, but the proposal process does also have benefits: On the one hand, it makes sure that the tag in question is well defined (on the wiki) and that its relationship and interplay with other tags is documented. On the other hand, while it might not guarantee that a tag is complete consensus behind a tag, it at least makes it likely that problems/disagreements/dissensus/conflicts associated with the tag are surfaced.

In this particular case both of these aspects are relevant, as several aspects of the crossing:signals proposal are currently not clear in my opinion:

• It is not clear what consequences the new crossing:markings tag has to the (proposed) usage of the crossing:signals tag.
• Is the crossing:signals tag meant to completely replace the crossing tag (potentially in conjunction with the new crossing:markings tag), or just the crossing=traffic_signals value?
• Whether the community is fine with deprecate the crossing tag by the combination of crossing:markings + crossing:signals.

8000 uses of crossing:signals and its clear upward trajectory

It's not that easy, unfortunately. As you said above, the 8000 uses are almost negligible in the "grand scheme of things". There are hundreds of times more crossings added each day which don't use the crossing:signals tag, but instead rely on the "established" crossing=traffic_signals tag… Raw usage numbers are not a sufficient condition for or against adding a tag, I'm afraid.

feels like wasted effort when many in the community consider approved proposals essentially meaningless.

I feel you. The issue from my perspective is that I really want to avoid to just incorporate tags on a "gut feeling" basis, as this approach had led to many unnecessary controversies in the past. And I also really need tags to be properly documented somewhere[^1] before they can become useful as a preset/field/etc.. These two of my requirements are currently somewhat well covered by the wiki tag approval process, that's why I rely on it so strictly on the wiki tag approval process. If you have an idea for a better process, please let me know (but maybe open a new issue, such that it doesn't get too off-topic here).

[^1]: currently, the wiki is the only good place for this, and a good amount of iD's functionalities rely on it, e.g. the taginfo integration.

[1ec5]

A lot of the criticism of the wiki’s proposal process focuses on its limited participation, which has always been a struggle. However, I think what’s more relevant to crossing tagging is that the proposal process can only capture a snapshot in time.

In 2008, maybe it was OK that something as unimportant and pedantic as pedestrian crossing classification could be coined by British mappers based on local distinctions and approved (with reservations) by ten mappers, all but one from Europe. Maybe it was OK that the crossing=uncontrolled tag originally came from non-English-speaking countries where the word’s real meaning was mistaken for almost its opposite.

But times change, the project changed, and so did our collective understanding of the importance and complexity of crossings. A similar misnomer hopefully wouldn’t pass muster today, and hopefully people have learned their lesson to vote no when they have those reservations. The rest of the wiki evolved to document the controversy around this tag, gaps in the tagging scheme, and fitful attempts at addressing its shortcomings. However, the approved proposal remains fixed, confidently presenting the tagging scheme as one that works well, even though we know it doesn’t.

I appreciate that we have a formal process for requesting comments on a tagging idea, and that it can even be brought to a vote, incentivizing mappers to come to a decision instead of trailing off like most tagging list threads. But it’s an imperfect process: besides not being representative of OSM’s internal and external stakeholders, it requires too much effort. On the surface, it’s just a matter of writing a wiki page and posting a few mailing list posts. But as we saw with the original tagging list discussion about crossing=marked/unmarked, there are a lot of special interests to appease. As a result, the process is optimized for the most determined, politically savvy community members, not necessarily the best ideas.

You’re right to insist on broader discussion and decisionmaking, because these tagging issues affect more than just iD. At the same time, the iD maintainer is a position of leadership within the community. It would mean a lot if, beyond expressing a desire for tagging improvements here, you could lend your support to reworking and promoting a crossing:signals proposal. Meanwhile, I think it would be healthy if we stick to debating the merits of one tag or another, without putting undue emphasis on a tag status that would not have been achieved in today’s environment. After all, there remains plenty of grousing about dumping crossing=zebra in favor of crossing=marked, but crossing=zebra wasn’t approved either.

[tyrasd]

I think that eventually, it would probably be a better user interface if these options were presented using a pictorial form

I've implemented this suggestion in iD now:

//edit: and this is how it looks like with translatable strings:

[tyrasd]

I've merged this branch now, to not let it sit around any longer and get stale. I think it does improve the tagging schema (e.g. by adding a way to specify crossing markings, bring cycle crossing up to par with foot crossings, and removing some inconsistencies between presets).

I'd still love to see someone from the community to pick-up and finish the crossing:signals to fully simplify these presets. If nobody steps up, I might try to give it a shot when I find some spare free time.

[1ec5]

There are a couple ongoing proposals to refactor crossing tagging, including https://wiki.openstreetmap.org/wiki/Proposed_features/Highway_crossing_cleanup. From the sound of the discussion, they’re still fluid, so you have an opportunity to contribute to the potential subkey-ification of crossing tagging.

[1ec5]

I've merged this branch now, to not let it sit around any longer and get stale. I think it does improve the tagging schema (e.g. by adding a way to specify crossing markings, bring cycle crossing up to par with foot crossings, and removing some inconsistencies between presets).

Discussion on one of these changes is continuing in #658.

I'd still love to see someone from the community to pick-up and finish the crossing:signals to fully simplify these presets. If nobody steps up, I might try to give it a shot when I find some spare free time.

A new proposal for crossing:signal is in the works. I invite those interested in this topic to contribute their expertise and perspective to this draft ahead of a general RfC.