{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidvon4pwgw6dnlg7fmymweysfd2psjvrkeungmo2rkqv7323625ty",
    "uri": "at://did:plc:4tuge3k3comfj4nfvqnwkemn/app.bsky.feed.post/3mgjxmnwmlnp2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreign5bgxjehqqy6hucynbjbaqnhl2rt4cikddalh2d42hhzfurgwxu"
    },
    "mimeType": "image/png",
    "size": 71266
  },
  "path": "/user/Derlamaer/diary/408326",
  "publishedAt": "2026-03-07T14:06:21.000Z",
  "site": "https://www.openstreetmap.org",
  "tags": [
    "Derlamaer"
  ],
  "textContent": "# Proposal for Tagging Detector‑Operated Pedestrian Signals in OSM\n\n_Author:Derlamaer_\n_Date: 18 February 2026_\n\n## Introduction\n\nI’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.\n\nMore 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.\n\nThis diary entry describes the situation, proposes a tag, and invites feedback.\n\n## Current OSM Tagging for Signalised Crossings\n\nToday, a typical signalised pedestrian crossing in OSM is tagged as:\n\n\n    highway=crossing\n    crossing=traffic_signals\n\n\nTo refine this, the OSM Wiki documents a couple of useful additional keys:\n\nbutton_operated=yes/no Indicates whether a pedestrian must press a button to request the green signal.\n\ntraffic_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 .)\n\nHowever, there is no widely documented, standard key that says:\n\n“This traffic signal is triggered automatically by a detector, with no need for a push‑button.”\n\nThat is the missing piece I am trying to address.\n\n## Real‑World Example (Toulouse, France)\n\nOne 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.\n\nA representative location is shown on Google Street View (link as used in the forum post). In such setups:\n\nThere 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.\n\n## What I Initially Wanted: A New Key\n\nMy first thought was to introduce a simple, descriptive key:\n\n\n    detector_operated\n\n\nSuggested 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:\n\n\n    highway=crossing\n    crossing=traffic_signals\n    button_operated=no\n    detector_operated=yes\n\n\nThis combination would explicitly describe a crossing where:\n\n*The pedestrian does not have to press a button. *The signal phase is triggered automatically by a detector.\n\n## Why This Distinction Matters\n\nExplicitly capturing detector‑operated signals in OSM would bring several benefits:\n\nAccessibility and convenience\n\nPeople 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\n\nPedestrian 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\n\nTransport 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\n\ndetector_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.\n\n## Community Feedback: The Existing traffic_signals:detector Key\n\nAfter publishing the idea, I learned (via the Community Forum discussion) that OSM already has a key in use that represents essentially the same concept:\n\ntraffic_signals:detector\n\nA fellow mapper pointed out that:\n\ntraffic_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:\n\nUse the existing traffic_signals:detector key. Document it properly on the wiki. Encourage consistent values to cover detector‑operated signals.\n\n## Recommended Tagging Based on the Outcome\n\nRather than detector_operated=*, the community feedback suggests we should do this:\n\nBasic case: generic detector\n\n\n    highway=crossing\n    crossing=traffic_signals\n    button_operated=no\n    traffic_signals:detector=yes\n\n\nThis tells data consumers:\n\nThere 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:\n\n\n    highway=crossing\n    crossing=traffic_signals\n    button_operated=no\n    traffic_signals:detector=remote_sensing\n\n\nThis expresses that:\n\nThe 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:\n\nyes – 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.",
  "title": "Automatic Pedestrian Detection at Signalized Crossings"
}