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 Traffic 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 Traffic 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)

//edit: this branch also adds a preset for highway=footway + footway=traffic_island (see #633).

[1ec5]

Though it may rest on approved tags, this PR demonstrates how messy the state of approved tagging remains. 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 and closer to what we have for railway=crossing.

[1ec5]

These three strings are inconsistent with each other. Both “traffic signals” and “traffic lights” are correct in American English, but we should stick to one. “Crossing” is redundant in this field.

[1ec5]

Should no get a string too? It would only make sense on a node. Maybe crossing=no should be a separate preset?

[tyrasd]

I've fixed the wording.

Maybe crossing=no should be a separate preset?

I haven't included https://wiki.openstreetmap.org/wiki/Tag:crossing%3Dno in this field, as it is intended to specify the type of a crossing, where the no option doesn't make sense.
crossing=no would indeed be useful as a standalone preset and as dedicated field to be added to presets like the highway=traffic_signals.

[1ec5]

Some strings would be helpful for this field. In particular, the zebra value was chosen as a concession to mappers used to the terminology in Europe (and some other countries), but unlike its official definition in some European countries, here it only refers to a marking pattern, without implying other aspects of the crossing.

[tyrasd]

Yes, strings would be definitely useful. I haven't included them in this PR already, because I didn't feel very confident choosing labels that are . Maybe you could help me out with these? This was one of my drafts, but several entries don't quite feel right to me (e.g. surface, zebra*, ladder:paired, …).

            "yes": "Unspecified Markings",
            "surface": "Distinct Surface",
            "zebra": "Zebra Stripes",
            "lines": "Solid Lines on Either Side",
            "ladder": "Ladder",
            "lines:paired": "Pairs of Lines on Either Side",
            "dashes": "Dashed Lines on Either Side",
            "dots": "Dotted Lines on Either Side",
            "zebra:double": "Zebra Stripes, Split in the Middle",
            "zebra:paired": "Zebra Stripes With Paired Bars",
            "zebra:bicolour": "Zebra Stripes With Alternating Colors",
            "ladder:skewed": "Skewed Ladder",
            "ladder:paired": "Ladder With Paired Bars",
            "no": "No Markings"

I think that eventually, it would probably be a better user interface if these options were presented using a pictorial form, like in this graphic on wikipedia:

[1ec5]

Paging @andrewharvey for his emoji skills. 😉 Until ideditor/schema-builder#56 is fixed, I tried a few things from the I Ching and box drawing symbols:

Value	“Icon”
yes
surface	▓
zebra	䷀ or ||||
lines	┃┃ or | |
ladder	▤ or ▥
lines:paired	║║
dashes	╏╏ or ===
dots	┋┋ or ⋮⋮ or ::::
zebra:double	䷁ or ☷ or ¦¦¦¦
zebra:paired	║║
zebra:bicolour	▮▯▮▯
ladder:skewed	⫻⃫͟͞
ladder:paired	╞╡
no

Some of these icons look OK in isolation, but I don’t think we’d be able to put together a coherent set for all the options.

[1ec5]

Similar to tracktype, we can probably get away with longer, more descriptive strings to avoid confusion. I don’t think even the traffic engineering profession has a set term for every one of these values, let alone any dialect of colloquial English. In case it helps, here are the technical terms for these patterns in the U.S., paired with my best guess at what non-U.S. markings would be called, but I think using them without a more descriptive tooltip would risk mistranslation and misuse by lay mappers:

Value	Description
yes	Marked Somehow
surface	Surface Treatment Only
zebra	Longitudinal Bars
lines	Transverse Lines
ladder	Ladder With Longitudinal Bars
lines:paired	Double Transverse Lines
dashes	Dashed Transverse Lines
dots	Dotted Transverse Lines
zebra:double	Triple-Four (!?!?)
zebra:paired	Paired Longitudinal Bars
zebra:bicolour	Longitudinal Bars With Alternating Colors
ladder:skewed	Ladder With Diagonal Bars
ladder:paired	Ladder With Paired Longitudinal Bars
no	Unmarked

[1ec5]

uncontrolled isn’t just “marked”, it’s “marked without traffic signals”.

[tyrasd]

Right, but we also need to keep a balance between keeping the preset names short and including every detail of a preset in its name. I thought that the presence of the dedicated preset for crossings with traffic signals makes it clear enough that the "marked crosswalk" preset is not meant for situations where there is a traffic light. There's also the ℹ️ icon which shows this additional detail for the preset. Last but not least, the name "Marked Crosswalk" worked well in the past for the tag crossing=marked which also implied the absence of traffic signals.

Maybe you have a better name for this preset (I'd rather avoid naming it Uncontrolled Crosswalk 😉 )?

[1ec5]

I think “Marked Crosswalk” is passable as long as there’s a field that can transform it into crossing=traffic_signals. It looks like you’ve left the Type field in place for this preset, which helps somewhat. Currently, the field isn’t as usable to non-English speakers, but providing localizable option strings is also fraught: several of the most common values mean the same thing – or don’t mean the same thing at all, depending on who you ask – and each has its ardent defenders.

[1ec5]

This makes it more difficult to clarify that an unmarked crosswalk is in fact signalized, so I disagree that this PR fixes #507.

[tyrasd]

Hmm…

The common design pattern for the presets in this repo is to not repeat the field for "main tag" of a preset, because the intended mechanism to switch between presets is to, well, use the preset switcher UI to choose the better fitting preset. But perhaps we could make an exception in this case, in order to better accommodate the necessities for situations like #507. I'm open to that. //edit: I've now implemented this in the PR

I guess an alternative would be to get rid of the "specialized" crossing presets altogether and only work with fields. One downside of that would be that we'd loose the dedicated icons which currently distinguish the different kinds of crossings on the map view.

[1ec5]

But perhaps we could make an exception in this case, in order to better accommodate the necessities for situations like #507.

Yes, I think of this as an exception because of these presets overlapping in meaning from a user standpoint. There’s some precedent for an exception like this, though usually it involves a multicombo field, such as Sports or Cuisine.

I guess an alternative would be to get rid of the "specialized" crossing presets altogether and only work with fields. One downside of that would be that we'd loose the dedicated icons which currently distinguish the different kinds of crossings on the map view.

I think this would be an obvious approach to take in the long run. Every time there’s a discussion around crossing classification, people clamor for regional presets for the only kinds of crossings that occur in their country. I’m sure UK mappers would appreciate an intuitive Toucan Crossing preset as much as U.S. mappers would appreciate a HAWK Crosswalk preset, not to mention other avian innovations around the world. But currently we don’t have room for regional crossing presets because of the sheer number of presets for each combination of mode-of-transportation and degree-of-traffic-control.

Another problem with the existing presets is that iD only remembers the last four presets, but it’s very common to need more than four presets when mapping a typical street due to all the separate crossing presets we have. For me, the MRU list is always thrashing between Marked Crosswalk, Unmarked Crossing, Crossing With Pedestrian Signals, Curb, Sidewalk, Traffic Signals, and Stop Sign. openstreetmap/iD#8895 would add a preference for remembering more presets at a time, but consolidating some of these closely related presets would minimize the thrashing without much inconvenience in my opinion.

[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 👍

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¹ 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).

Footnotes

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.