single preset or better extended preset for crossing=traffic_signals

[Elefant-aus-Wuppertal]

Where pedestrians are crossing the road with traffic lights, there can be added more information about the crossing than just tactile_paving= and kerb= . What do you think, wouldn't it be useful or would it somehow be possible for crossing=traffic_signals, to add button_operated=yes/no, traffic_signals:arrow=yes/no, traffic_signals:vibration=yes/no and traffic_signals:sound= ? I think this would encourage people to look at this and adding it in an easy way.

In most these are all facilities used by disabled people, but that's the same for e. g. tactile_paving.

[bhousel]

I'd like to add this but I can't think of a good way to do it.

For one, I don't want to add a whole lot more checkboxes and fields to the crossing presets.

I would be ok with adding a "Accessibility Features" multiselect field, but I can't really do this because the tags are all over the place - some have no prefix, some have a traffic_signals: prefix, and that prefix is sometimes used for other non-crosswalk things (traffic_signals:direction). Sometimes the values are yes/no but sometimes there is other information encoded (traffic_signals:sound=yes/no/locate/walk).

I hate to close this, but unfortunately these tags just aren't currently designed in a way that we can easily support them in iD.

[1ec5]

As someone who’s mapped wayyy too many signalized crosswalks, I would find it very convenient if the Marked Crosswalk and Unmarked Crossing presets could have a Pedestrian Signal checkbox. This is closely related to the request above but smaller in scope, so hopefully more feasible to implement cleanly.

Currently, one of the popular crossing=*values is traffic_signals, which indicates that pedestrians using the crossing must wait for a walk light, potentially after pressing a “beg button”. But even before 1ffca3ce85d630539c7ebb11454a91770bd76536, iD’s presets have been focused on crossing values that describe the appearance of a crossing rather than its signalization.

Signalization is important, sometimes moreso than pavement markings. For example, routers need to penalize signalized crossings when giving walking directions, regardless of whether the crossing is marked. (The marked-versus-unmarked distinction is generally more meaningful to renderers.)

According to taginfo, 3% of all instances of traffic_signals=* are on crossing=* features. @bhousel pointed out in https://github.com/openstreetmap/iD/issues/5205#issuecomment-410784580 that this tag is ambiguous, because mappers could intend it to represent either pedestrian or motorist signals at a crossing node.

There are a few ways to resolve the ambiguity:

• Add traffic_signals=yes or traffic_signals=crossing to a crossing way but not to a crossing node, which is sometimes reused for motorist signals. These tags are already in use. 1ffca3ce85d630539c7ebb11454a91770bd76536 is consistent with the draft crossing=marked proposal, so traffic_signals=yes would align with this part of the proposal.
• @nbolten also floated the idea of a pedestrian_signals=yes tag, by analogy with the in-use crossing=pedestrian_signals tag, to get around the pedestrian/motorist ambiguity. However, it hasn’t been used anywhere.
• traffic_signals:foot=yes is also in use. This could be an option for crossing nodes.

As things stand, a lot of crossings are being added that give data consumers no straightforward way to distinguish between signalized and unsignalized crossings. if a mapper does want to indicate signalization, it’s too tempting to change the Type field from marked to traffic_signals, which defeats the purpose of 1ffca3ce85d630539c7ebb11454a91770bd76536.

I realize the state of crossing tagging is still largely a mess, but hopefully somewhere in here is a way forward. If not, please consider this comment an FYI.

[1ec5]

a crossing node, which is sometimes reused for motorist signals

It occurs to me that iD doesn’t really support using the same node as a crosswalk and a vehicular traffic signal anyways, so there’s no risk of conflict.