I’m new here and just starting out in cartography. Please excuse me if my post is useless.
I would like to propose a new tag for signal-controlled crossings to indicate that a traffic signal is automatically activated by a presence detector, rather than requiring a push button.
Currently, OSM tagging for traffic-signalised pedestrian crossings uses:
highway=crossing
crossing=traffic_signals
to indicate a signalised crossing. The wiki also documents:
button_operated=yes/no – for crossings that are activated manually with a button
traffic_signals:sound=yes/no – for auditory signals (OSM Wiki)
However, there is no standard way to indicate that a crossing is triggered automatically by a detector (pedestrian or vehicle sensor).
thanks for your suggestion to include detector operated traffic signals. You have to know that not every existing tag is documented in the wiki or integrated as preset in the standard editor.
There is a key traffic_signals:detector already in use, and among the used values are 139 yes and 66 remote sensing according to taginfo.
Thank you very much, @Map_HeRo for your help and this quick response!
The TagInfo link is going straight to my favorites it will surely be even more helpful in the future.
@Map_HeRo I also thought about this tag, but there is one issue: Too often we have only one node for traffic signals - and then we need to distinguish between a sensor for road traffic and a sensor for crossing pedestrians. We might want to reserve traffic_signals:detector for the sensor monitoring the road.
Ideally we’d use a tag in the crossing: namespace like crossing:sensor.
I am not an expert in traffic signals tagging because there are not many of them around here, but if there is one I map the traffic signal node separate from the crossing. By doing so I did not see a problem to go for the crossing like
*:detector= / *:sensor= is better than *_operated= , but this doesn’t fully answer the question yet. Detectors can have other functionalities only, not actuating the crossing at all. UK Puffin crossings have them to extend the pedestrian green / vehicular red until all have crossed, and cancel the crossing call if all pedestrian walked away. They need to be distinguished next.
Therefore this should first have its verifiability asked, with the bad button_operated= naming and experience in mind. However, it should be clarified that we can start anew on both here, as if it’s separated into crossing:button=yes + “Something for effect”.
Cf previous Button operated traffic signals
Another problem/opportunity to beware of is railway=*crossing already have 2 similar crossing:activation= and crossing:on_demand=
Though this doesn’t necessarily clearly imply the function of the detector (activation, extension, both?) as @Kovoschiz mentioned above and I’m not sure we want to be three namespaces deep (as in crossing:signals:detector:activation=(yes|no) or similar) or end up with more multi-function keys (crossing:signals:detector=(activation|extension) or similar)…
This reminds me of flashing_lights=* which can be =sensor / =button / =button;sensor / other values.
Side note: crossing=traffic_signals (and crossing=* in general, though there are some exceptions) is strictly inferior to crossing:signals=*.
How about crossing:pedestrian_detector=activation|extension and crossing:signals:vehicle_detector=yes|no or just crossing:signals:detector=* for vehicles since detector seems to be in use already for vehicles, which would then need to be clearly documented.
That would require another tag for cycleway crossings (I know a few, both with buttons or sensors). And yet a distinction between the crossing cycleway and the cycleway on the main road.
I think the only way is a clear distinction between traffic_lights:X referring to the main road and crossing:X for the “minor” crossing path.
We really need two tags: One for the type of sensor, and one for its purpose.
Wasn’t there even somewhere a project with bluetooth-based sensors that tried to have the lights green as soon as the pedestrian reached the crossing?
