Allow tagging signalized but unmarked pedestrian crossing

[1ec5]

For completeness, there should be a preset or field that allows the user to indicate that a pedestrian crosswalk is signalized but unmarked.

Rationale

As of #192 #368, this repository has a set of presets to express each of these pedestrian crossing configurations:

• Crossing with no road markings and no traffic signals (crossing=unmarked)
• Crossing with road markings but no traffic signals (crossing=marked)
• Crossing with road markings and traffic signals (crossing=traffic_signals)

However, there’s no affordance for tagging crossings with traffic signals but no road markings.

This configuration is standard and commonplace in some regions: #408 (comment). Where it occurs, it is important to distinguish from a crossing with traffic signals and road markings, because the lack of road markings creates a higher risk profile for pedestrians, especially where there are unprotected left turns. One can imagine a pedestrian router applying the same penalty as for marked, signalized crossings, while a car router issues the same alert as for unmarked, unsignalized crossings.

Tagging

The most common tag combination for this configuration is crossing=unmarked crossing:signals=yes, with 78 occurrences globally. This is likely an undercount, because the crossing:signals key description page was created only a few weeks ago despite being proposed several years ago. It’s quite likely that a lot of unmarked, signalized crossings are being tagged as just crossing=unmarked or just crossing=traffic_signals, losing valuable information.

Even if we assume that this configuration is limited to the United States (which is false), it is still common enough to merit support in this repository. crossing=unmarked crossing:signals=yes represents 1% of all crossing:signals usage in the U.S. At this rate, over 2,000 of the crossing=traffic_signals that have been tagged so far in the U.S. could conceivably be candidates for crossing:signals=no. Of course, that can only be a rough estimate, because so much data has already been lost through the adoption of crossing=traffic_signals.

Design

One approach would be yet another set of presets, i.e., “Unmarked Crossing With Pedestrian Signals”. The existing “Crossing With Pedestrian Signals” preset would be renamed to “Marked Crossing With Pedestrian Signals” to avoid confusion. This unwieldy name would accurately reflect the approved antipattern of cramming multiple orthogonal aspects into a single tag.

A cleaner approach would be to add a “Pedestrian Signals” checkbox field to the “Marked Crosswalk” and “Unmarked Crossing” presets. The existing “Crossing With Pedestrian Signals” preset might need to become unsearchable, to avoid a situation where the editor forces the user to choose between two functionally equivalent but very different-looking tagging combinations.

[tyrasd]

Tagging

The problem here is that there doesn't yet exist an approved tagging schema for such crossings. Since the proposal for crossing:signals would deprecate the existing tag crossing=traffic_signals, I'm very hesitant to include this in the tagging schema before the community has reached a decision on the proposal as a whole.

Please discuss this on the dedicated community channels for tagging discussions, and try to bring the tagging proposal to a conclusion. When that is done, we can continue the implementation details here.

[1ec5]

That’s fair, but in the meantime, we do have a bit of a problem with crossing=traffic_signals now being promoted so prominently. It may be a (kind of) approved tag from eons ago (with lots of asterisks), but including it without the antonym means iD is promoting dataloss in some regions. I think this means the migration path in the proposal will need to be more aggressive than it would be if the crossing:signals key were adopted piecemeal for only the crossings that aren’t adequately served by the approved tags.

[1ec5]

As a starting point, can we consider renaming “Crossing With Pedestrian Signals” to “Marked Crosswalk With Pedestrian Signals”, to reflect the actual documented meaning of crossing=traffic_signals? I don’t think that requires a new proposal, because it’s consistent with the original approved one.

[tyrasd]

Unfortunately, the tag crossing=traffic_signals is documented to be used on any crossing with traffic signals which may or may not feature road markings. Renaming the preset would contradict the wiki. 😒

[1ec5]

Oof, yep, you’re right. So for now, there’s nothing to be done about the potential for crossing=unmarked crossing:signals=yes to be changed to crossing=traffic_signals by mappers unaware of the hidden crossing:signals=yes tag but aware of the prominent “Crossing With Pedestrian Signals” preset?

[tyrasd]

Not really, except for bringing the new tagging proposal further along.

Maybe a very slight positive take on this topic: Since the preset for crossing=unmarked is simply called "Unmarked Crossing" (and not "Unmarked Crossing Without Traffic Signals"), it leaves the opportunity open for mappers to choose it over the "Crossing With Pedestrian Signals" preset if they experience that the lack of markings is the more important / most distinctive property of a particular crossing for them.

[bhousel]

Unfortunately, the tag crossing=traffic_signals is documented to be used on any crossing with traffic signals which may or may not feature road markings. Renaming the preset would contradict the wiki. 😒

This language was only added in 2019 by a single wiki editor.
https://wiki.openstreetmap.org/w/index.php?title=Key%3Acrossing&type=revision&diff=1920351&oldid=1920333

Before that, the wiki said the tag meant that "(pedestrian, bicycles) have their own traffic lights." I interpret this as something like a HAWK signal, but in practice mappers were just adding this tag wherever there were traffic lights for vehicles, assuming that to be a save place to cross.

Back around 2018 @nbolten did an audit of actual use of this tag around Seattle and found that the tag was too inconsistent to use. Actual use of crossing=traffic_signals doesn't reflect any version of what people have written on the wiki, and it doesn't correlate well with the on-the-ground safety or suitability of the crossing.

[1ec5]

Maybe a very slight positive take on this topic: Since the preset for crossing=unmarked is simply called "Unmarked Crossing" (and not "Unmarked Crossing Without Traffic Signals"), it leaves the opportunity open for mappers to choose it over the "Crossing With Pedestrian Signals" preset if they experience that the lack of markings is the more important / most distinctive property of a particular crossing for them.

I’m not sure that that’s how a user would react to these options. If I weren’t a tagging insider, I would take the presence of “Crossing With Pedestrian Signals” as a signal that the OSM community prefers that aspect over markedness and so should I. But it would be overkill to conduct a user study to find out. 😛

Many occurrences of crossing=traffic_signals crossing:signals=yes began as crossing=marked/unmarked crossing:signals=yes, presumably because a mapper considered both details important, until another mapper came along and switched it to crossing=traffic_signals. This was months before this repository released a preset for crossing=traffic_signals, so I think there’s a higher risk now of back-and-forth or muddied distinctions.

I am interested in taking a revised version of @nbolten’s 2019 proposal to a vote. But there’s been so much skepticism from Europe about the unmarked/signalized configuration that I think it would be necessary to first demonstrate the prevalence ahead of any project-wide vote. As one of the top users of crossing=traffic_signals globally, and formerly one of its biggest proponents, I’m focused on replacing my usage of that tag in favor of crossing:signals, which didn’t exist back when I did most of my crosswalk classification tagging.

[tyrasd]

Many occurrences of crossing=traffic_signals crossing:signals=yes began as crossing=marked/unmarked crossing:signals=yes

For reference: Looking at the data, there have only ever been 12 occurrences of features having the tag combination crossing=traffic_signals + crossing:signals=yes in OSM. I wouldn't draw too many conclusions from such a small sample (especially when considering the relatively large number of 1.7k objects with crossing=marked + crossing:signals=yes).

[1ec5]

Sure, and some of those cases didn’t involve iD either. I was only trying to illustrate a scenario that I think would become more likely as of the latest releases of id-tagging-schema.

[nbolten]

I am interested in taking a revised version of @nbolten’s 2019 proposal to a vote. But there’s been so much skepticism from Europe about the unmarked/signalized configuration that I think it would be necessary to first demonstrate the prevalence ahead of any project-wide vote. As one of the top users of crossing=traffic_signals globally, and formerly one of its biggest proponents, I’m focused on replacing my usage of that tag in favor of crossing:signals, which didn’t exist back when I did most of my crosswalk classification tagging.

I'd be happy to help spruce up the proposal! The non-orthogonality of pedestrian signals vs. markings is a longstanding issue for getting these things reliably mapped - and for providing useful, or even understandable, instructions to mappers.

In my opinion, the proposal would benefit from having several examples where the current schema fails but the proposed schema would work. Also, examples where both schemas work, to show that it wouldn't break anything. Do any folks have some favorites off the top of their heads? I had one in New York, NY that I used to show people.

[bgo-eiu]

This is the favorite that comes to mind for crossing:signals=yes + crossing=unmarked - I was perplexed by it earlier this week. It's not immediately obvious until you try to cross, but the angles of the signal heads are perfectly aligned so that you can tell they are there walking up to it, but you can't actually see any of them when you're crossing. I was hopping back and forth a bit trying to work out if there was a way to cross that had something to do with what the signals were doing but I didn't figure it out, at least in the time I had. (Referring to the two facing each other, the one facing the camera here is visible at the crossing.)

[tyrasd]

But there’s been so much skepticism […] about the unmarked/signalized configuration

One suggestion from me as a preset maintainer which you might consider: I would be much happier to support a tagging schema which is backwards-compatible with the current schema. I'm wondering whether there was a reason why you stuck with the crossing tag for distinguishing between marked/unmarked, compared to introducing a new tag for that property as well. Wouldn't it be more natural to let both properties of a crossing to live in their own subtags (crossing:signals=yes/no and crossing:marked=yes/no), especially when one might consider both details equally important?

By that scheme, the old crossing=marked/unmarked/traffic_signals/… tag could be declared outdated, but wouldn't need to be redefined and/or mechanically edited. This helps with compatibility of legacy software consumers during the transition period (which likely will be long) and might also help with the adoption / reduce skepticism of the new tagging schema. The proposal could for example also come with some upgrade guide (i.e. stating that crossing=marked implies crossing:marked=yes + crossing:signals=no, crossing=traffic_signals implies crossing:signals=yes + crossing:marked=<undefined>, etc.). Such upgrading rules would be very easy to adopt in iD.

[1ec5]

To clarify, I was referring to skepticism about whether the unmarked/signalized configuration can even legitimately exist in the real world – it does – but this is a good idea worth consideration. The fewer cobbled-together classification systems in OSM, the better. It looks like the possibility of a crossing:marked or crossing:markings was analyzed in the proposal’s wiki discussion and discussed on the tagging list a few years ago.

[kaneap]

@tyrasd @1ec5 You may be interested in the proposal for crossing:markings=* to capture the markings on the ground (as well as their style).

[tyrasd]

The proposal for the crossing:markings tag was recently approved.