OpenStreetMap BlogsOpenStreetMap User's Diaries
Automatic Pedestrian Detection at Signalized Crossings
Proposal for Tagging Detector‑Operated Pedestrian Signals in OSM
Author: Derlamaer
Date: 18 February 2026
Introduction
I’m new to OSM and to cartography in general, so please excuse any imperfections in this post. As I’ve been mapping my surroundings, I noticed a gap in how we describe certain modern pedestrian crossings, and I would like to propose a way to fill it.
More an
Proposal for Tagging Detector‑Operated Pedestrian Signals in OSM
Author: Derlamaer
Date: 18 February 2026
Introduction
I’m new to OSM and to cartography in general, so please excuse any imperfections in this post. As I’ve been mapping my surroundings, I noticed a gap in how we describe certain modern pedestrian crossings, and I would like to propose a way to fill it.
More and more signal‑controlled pedestrian crossings are equipped with automatic presence detectors. These sensors detect a pedestrian (or sometimes a vehicle) and trigger the traffic signal phase without requiring a push button. This behaviour is common in newer installations, but OSM’s tagging does not yet have a clear, standard way to capture it.
This diary entry describes the situation, proposes a tag, and invites feedback.
Current OSM Tagging for Signalised Crossings
Today, a typical signalised pedestrian crossing in OSM is tagged as:
highway=crossing
crossing=traffic_signals
To refine this, the OSM Wiki documents a couple of useful additional keys:
button_operated=yes/no
Indicates whether a pedestrian must press a button to request the green signal.
traffic_signals:sound=yes/no
Indicates the presence of an acoustic signal for visually impaired users.
(See the wiki page for crossing=traffic_signals for details .)
However, there is no widely documented, standard key that says:
“This traffic signal is triggered automatically by a detector, with no need for a push‑button.”
That is the missing piece I am trying to address.
Real‑World Example (Toulouse, France)
One concrete example can be found in Toulouse, France, where several pedestrian crossings use overhead or roadside sensors (camera, infrared, radar or similar) to detect pedestrians as they approach the kerb.
A representative location is shown on Google Street View (link as used in the forum post). In such setups:
There is no button (or the button is optional).
*A presence detector starts the pedestrian phase automatically.
*This strongly affects how the crossing behaves for pedestrians and vehicles, and is therefore relevant for routing, accessibility, and safety analysis.
What I Initially Wanted: A New Key
My first thought was to introduce a simple, descriptive key:
detector_operated
Suggested values
*yes – the crossing’s traffic signals are activated by an automatic presence detector.
*no – there is no detector; the crossing is not automatically triggered this way (typically a button is required).
Example usage:
highway=crossing
crossing=traffic_signals
button_operated=no
detector_operated=yes
This combination would explicitly describe a crossing where:
*The pedestrian does not have to press a button.
*The signal phase is triggered automatically by a detector.
Why This Distinction Matters
Explicitly capturing detector‑operated signals in OSM would bring several benefits:
Accessibility and convenience
People with reduced mobility, small children, or those pushing strollers or wheelchairs may not find it easy to reach or operate a button.
Automatically triggered crossings are easier and safer to use, and routers or accessibility tools could prioritise such crossings.
Better routing and user expectations
Pedestrian and multimodal routers could distinguish between:
crossings that require waiting for a button press, and
crossings that react automatically to presence.
This can influence estimated waiting times and route attractiveness.
Traffic modelling and safety analysis
Transport planners and researchers using OSM data could more accurately model:
where “smart” crossings exist,
how traffic phases are activated, and
the potential safety benefits of detector‑based systems.
Consistency with existing tags
detector_operated would sit naturally beside:
button_operated=
traffic_signals:sound=
Together, these describe how a crossing is activated and perceived, without conflicting with current conventions.
Community Feedback: The Existing traffic_signals:detector Key
After publishing the idea, I learned (via the Community Forum discussion) that OSM already has a key in use that represents essentially the same concept:
traffic_signals:detector
A fellow mapper pointed out that:
traffic_signals:detector is already in active use.
According to Taginfo, it has values such as:
yes (used >100 times)
remote_sensing (dozens of uses)
The key is not yet well documented on the wiki, but is clearly in real‑world use across multiple users [1].
The conclusion from that discussion was that introducing a completely new key is unnecessary. Instead, the best path forward is:
Use the existing traffic_signals:detector key.
Document it properly on the wiki.
Encourage consistent values to cover detector‑operated signals.
Recommended Tagging Based on the Outcome
Rather than detector_operated=*, the community feedback suggests we should do this:
Basic case: generic detector
highway=crossing
crossing=traffic_signals
button_operated=no
traffic_signals:detector=yes
This tells data consumers:
There is a traffic‑signalised crossing.
No button is needed (button_operated=no).
A detector triggers the signals (traffic_signals:detector=yes).
More specific case: remote or automatic sensing
Based on current Taginfo usage, a refined value could be:
highway=crossing
crossing=traffic_signals
button_operated=no
traffic_signals:detector=remote_sensing
This expresses that:
The detector operates at a distance (camera, IR, radar, etc.), not just a simple loop or push button.
Over time, the community could standardise a small, clear set of values under traffic_signals:detector=* for common detector types, such as:
yes – some form of detector is present (generic).
remote_sensing – non‑contact sensor like video, infrared, or radar.
induction_loop – vehicle loop detector (if needed for some installations).
The key point is that the existing key can already represent “detector‑operated” behaviour without creating new, parallel tagging.
Author: Derlamaer
Date: 18 February 2026
I’m new to OSM and to cartography in general, so please excuse any imperfections in this post. As I’ve been mapping my surroundings, I noticed a gap in how we describe certain modern pedestrian crossings, and I would like to propose a way to fill it.
More an
Proposal for Tagging Detector‑Operated Pedestrian Signals in OSM
Author: Derlamaer
Date: 18 February 2026
Introduction
I’m new to OSM and to cartography in general, so please excuse any imperfections in this post. As I’ve been mapping my surroundings, I noticed a gap in how we describe certain modern pedestrian crossings, and I would like to propose a way to fill it.
More and more signal‑controlled pedestrian crossings are equipped with automatic presence detectors. These sensors detect a pedestrian (or sometimes a vehicle) and trigger the traffic signal phase without requiring a push button. This behaviour is common in newer installations, but OSM’s tagging does not yet have a clear, standard way to capture it.
This diary entry describes the situation, proposes a tag, and invites feedback.
Current OSM Tagging for Signalised Crossings
Today, a typical signalised pedestrian crossing in OSM is tagged as:
highway=crossing
crossing=traffic_signals
To refine this, the OSM Wiki documents a couple of useful additional keys:
button_operated=yes/no Indicates whether a pedestrian must press a button to request the green signal.
traffic_signals:sound=yes/no Indicates the presence of an acoustic signal for visually impaired users. (See the wiki page for crossing=traffic_signals for details .)
However, there is no widely documented, standard key that says:
“This traffic signal is triggered automatically by a detector, with no need for a push‑button.”
That is the missing piece I am trying to address.
Real‑World Example (Toulouse, France)
One concrete example can be found in Toulouse, France, where several pedestrian crossings use overhead or roadside sensors (camera, infrared, radar or similar) to detect pedestrians as they approach the kerb.
A representative location is shown on Google Street View (link as used in the forum post). In such setups:
There is no button (or the button is optional). *A presence detector starts the pedestrian phase automatically. *This strongly affects how the crossing behaves for pedestrians and vehicles, and is therefore relevant for routing, accessibility, and safety analysis.
What I Initially Wanted: A New Key
My first thought was to introduce a simple, descriptive key:
detector_operated
Suggested values *yes – the crossing’s traffic signals are activated by an automatic presence detector. *no – there is no detector; the crossing is not automatically triggered this way (typically a button is required). Example usage:
highway=crossing
crossing=traffic_signals
button_operated=no
detector_operated=yes
This combination would explicitly describe a crossing where:
*The pedestrian does not have to press a button. *The signal phase is triggered automatically by a detector.
Why This Distinction Matters
Explicitly capturing detector‑operated signals in OSM would bring several benefits:
Accessibility and convenience
People with reduced mobility, small children, or those pushing strollers or wheelchairs may not find it easy to reach or operate a button. Automatically triggered crossings are easier and safer to use, and routers or accessibility tools could prioritise such crossings. Better routing and user expectations
Pedestrian and multimodal routers could distinguish between: crossings that require waiting for a button press, and crossings that react automatically to presence. This can influence estimated waiting times and route attractiveness. Traffic modelling and safety analysis
Transport planners and researchers using OSM data could more accurately model: where “smart” crossings exist, how traffic phases are activated, and the potential safety benefits of detector‑based systems. Consistency with existing tags
detector_operated would sit naturally beside: button_operated= traffic_signals:sound= Together, these describe how a crossing is activated and perceived, without conflicting with current conventions.
Community Feedback: The Existing traffic_signals:detector Key
After publishing the idea, I learned (via the Community Forum discussion) that OSM already has a key in use that represents essentially the same concept:
traffic_signals:detector
A fellow mapper pointed out that:
traffic_signals:detector is already in active use. According to Taginfo, it has values such as: yes (used >100 times) remote_sensing (dozens of uses) The key is not yet well documented on the wiki, but is clearly in real‑world use across multiple users [1]. The conclusion from that discussion was that introducing a completely new key is unnecessary. Instead, the best path forward is:
Use the existing traffic_signals:detector key. Document it properly on the wiki. Encourage consistent values to cover detector‑operated signals.
Recommended Tagging Based on the Outcome
Rather than detector_operated=*, the community feedback suggests we should do this:
Basic case: generic detector
highway=crossing
crossing=traffic_signals
button_operated=no
traffic_signals:detector=yes
This tells data consumers:
There is a traffic‑signalised crossing. No button is needed (button_operated=no). A detector triggers the signals (traffic_signals:detector=yes). More specific case: remote or automatic sensing Based on current Taginfo usage, a refined value could be:
highway=crossing
crossing=traffic_signals
button_operated=no
traffic_signals:detector=remote_sensing
This expresses that:
The detector operates at a distance (camera, IR, radar, etc.), not just a simple loop or push button. Over time, the community could standardise a small, clear set of values under traffic_signals:detector=* for common detector types, such as:
yes – some form of detector is present (generic). remote_sensing – non‑contact sensor like video, infrared, or radar. induction_loop – vehicle loop detector (if needed for some installations). The key point is that the existing key can already represent “detector‑operated” behaviour without creating new, parallel tagging.
Identificação em campo de Handroanthus impetiginosus (Ipê-roxo-de-bola)
DOI: 
DOI: 
Exemplo de etiquetas usadas no mapeamento de um indivíduo da espécie Tabebuia rosea. 
After consultations and careful observation, we selected Duaripara Slum as our core study area. Over the following days, we collected data from more than 400 households, representing over 8,200 people. But beyond the numbers were conversations, stories of survival, adaptation, and hope. Community leaders shared their concerns about flooding, health risks, and extreme heat. Residents spoke about their struggles but also about their determination.
Mapping was no longer just about coordinates. It became about understanding lived realities.
