My opinion:
With a button operated traffic signals, I would expect the main function to be controlled with the button.
Any other functions like sounds, vibrations can also be button controlled. This should then also be recorded together with the function. E.g. sound:button_operated, vibration:button_operated.
âOperatedâ indicates that there must be a recognizable function!
The values should allow to distinguish between:
has a recognizable function (yes)
has no discernible function (placebo)
has a recognizable function at times (temporary)
must always be pressed (only)
not button operated (no)
What is your opinion? button_operated (with no additional namespace) on crossing=traffic_signals should mean:
I would avoid any trouble and just tag button=yes if there is a button. Meaning: press the button and you will get a chance to cross. Because that is what people expect and do, no matter how it actually works.
At crossings, historically it is pretty clear that it (is supposed to) activate the traffic signals. Not pressing it may thus result it:
green light for pedestrians never turning on
green light for pedestrians turning on, but much later (and/or being of shorter duration when it does turn on)
no effect
As it is hard to verify what actually happens (esp. as it might change depending on the time of the day, underground induction sensors, traffic jam detectors etc), it is not really possible to make it more detailed. But on crossingsbutton_operated=* should mean be about indicating you want to cross there, and not thing else.
(Note that button_operated=* may be used at other tags listed, like elevators, doors etc. where it might have different function)
I dislike recent additions that try to make button_operated=* on crossings do other functions, like turning sound on or off. Those should be in that specific namespace (e.g. traffic_signals:sound=button_operated or traffic_signals:sound:button_operated=yes) and not trying to blur what has been common usage: requesting a crossing
I think there is a meaningful difference between not knowing whether it has a function or knowing for sure that it has no function (it could also be timebased for example, so pushing it and noticing nothing is not a proof there is no function). If you knew for sure that there isnât any function then you shouldnât tag it as button operated
I agree with idea generally, but in practice is hard to prove a negative.
Unless you work at company which installed or maintains those traffic signals, or you did some investigating (involving screwdriver, electronics knowledge, and illegal access), you usually canât really âknow for sure that is has no functionâ in vast majority of the cases. (and if you do, please leave a note=* with details to warn next mappers)
We may allow some uncertainty.
If no one ever observes a function, then it doesât matter that it is not captured.
But we can use values like unknown for this uncertainty.
It may be observed hundreds a times a day, it may just be that number of OSM mappers in general population is low enough that no OSM mapper ever observes a functionâŠ
But, yeah, Verifiability - OpenStreetMap Wiki is a thing. It is easy to verify something has a button. It is other thing altogether (and hugely harder to verify!) what that button actually does.
Even more, many mappers will not invest enough effort to investigate such using proper scientific method. E.g. someone using StreetComplete might come at the crossing, see 4 boxes with button on each, and confirm it is button_operated=yes before following along to next quest few seconds later.
Properly doing statistically significant number of measurements for each crossing, spreading along all imaginable influential factors (time of day, time of year, weather, traffic, different button presses patterns - at different times of traffic cycle, once or several times etc.) and tracking differences along those, and then trying to prove correlation versus causation, is worthy of an academic dissertation; and not for more precisely mapping low-utility OSM tag.
But yeah, if one is pretty certain that it does nothing even after prolonged observations, it might be mapped with button_operated=placebo and appropriate note=* (otherwise, if button_operated=* is just missing, very next mapper will add it, and thus endless cycle of useless adding/removing tag will begin )
The question remains, how youâd map the individual functions this button can have: turn on the traffic lights (no green phase otherwise), and speed up getting green phase for the pedestrians.
Would you tag those as different values of button_operated=* (button_operated=request_green sounds like itâs the wrong way around), or rather a separate tag?
problems correctly determining how it actually works (see above)
chances that is could be both at the same time (depending on the time of the day / traffic, for example)
low utility of the distinction (i.e. if you value your time over the effort/risk of pressing a button, youâd press it in both cases anyway)
fact that there are many other more important things to map (and my time is not infinite)
I personally wouldnât bother distinguishing them, i.e. Iâd mark both cases as simple button_operated=yes and move on.
(In fact, were it not for the fact that I use StreetComplete where act of mapping in takes less than a second and is streamlined with more important crossing-related quests, and I was waiting at the said crossing anyway, I probably wouldnât bother mapping button_operated=* at all)
If one however feels it is an important distinction (e.g. green light never turns on unless button is pressed, and buttons are placed so high so that individual in wheelchair cannot reach them and at such crossing there are very few if any pedestrians - so wheelchair users might be unable to cross it at all), one might for now add free-form description=* describing the issue as well as other possibly related tags (wheelchair=limited + wheelchair:description:en=* in example above).
That should help directly, as well as much more easily allow further updates when it is standardized (e.g. button_operated=required or whatever). Of course, since one cared about that specific issue, they would try to find out what routers such individuals use to find out acceptable crossings, and would work with that routers to determine what would be best way to map or invent new tags that would get support in them (as otherwise, no amount of tagging is useful unless such information makes a difference for the end user).
From a router perspective, it would make sense to penalize traffic lights that never turn red for cars, unless a pedestrian presses a button, far less than those that periodically turn red for cars anyway. For a pedestrian, the difference is negligible, as you usually always press the button if one is there.
Iâve never even thought about users in wheelchairs having problems reaching the button. Interesting idea, but at least over here, it doesnât happen.
Maybe it is exact opposite, it depends on exact model. E.g. such must-press buttons might be placed on some roads exactly because such roads were overcongested, in order to reduce that congestion at least somewhat. (And preferring such overcongested roads would of course be counterproductive).
And (as noted above) in more advanced cities, it depends on the traffic patterns (i.e. it might be must-push and then with wait-for-next-cycle-timer for pedestrian green in peak car traffic hours, but might be pedestrian-preferring [e.g. stop car traffic after several seconds] in off-peak hours), so you might prefer it in some times, but penalize it in others. Trying to tag for that seems too problematic for too little gain.
So, to me button_operated=required vs. button_operated=yes seems a poor proxy for determining routing weight for cars based on such pedestrian button policy only, even if it were correctly mapped.
If one wished to conveyed such information about road weight, it might be better to map road segments with average maxspeed:practical=* to allow routers to prefer one road over the other instead, but it is by no means foolproof (see part of different traffic patterns depending on time of day etc).
Neither does here, but Iâm trying to imagine use cases where distinguishing them would serve some useful purpose. Because, if we canât find real and useful purposes, we probably shouldnât bother wasting time trying to map it correctlyâŠ
Another preference might be routing of blind people (which might prefer automatic light to ones the ones where they must find a button and press it). But also probably not a real concern, as theyâd usually want to find and feel the box (with the button) anyway, to correctly orient themselves for crossing (and retrieve extra engraved information, e.g. on which side is cycleway, if there is a island in the middle of the street etc.)
To my understanding every detail mapping should not just add data to an object, but additional value.
For a pedestrian traffic light the valuable information are:
Here is a traffic light for pedestrians. You can safely cross the road there.
The traffic light is in working condition (otherwise you would not need to go there).
For disabled people: there is sound or vibration, maybe a traffic island, no raised kerb.
Thatâs it.
Does âbutton_operatedâ add any value? Not for pedestrians or cyclists because they know it may take some time to get a green light anyhow with or without button. Probably for routing? Well, it is easy verifyable OTG so no harm in tagging it if there might be some small additional value.
Even more details? Is the button working or not? If not, has it ever been working? Is the button activating the green light or just a sound? Will there be green light without pressing it? Who knows (who has the time and the will to check all this?) ⊠and who cares? Imho all these are just details without adding any additional value to the traffic light itself.
The point of a crossing indicator is to indicate that it is safe to cross. If someone canât see a light, the fact it changed is irrelevant. Thatâs why I use button_operated for any function. To cater it only to a crossing light is just catering toward a particular indicator for no real reason, other than it being the indicator you prefer.
(As for why detailing these buttons matters: it allows navigation apps to notify someone who canât easily see potential buttons whether they should be looking for one, and cyclists to know whether theyâll have to navigate their bike from the road to the sidewalk, since bikes often canât trigger lights on their own.)
This thread seems to talk about a specific push switch (also known as âpedestrian call buttonâ) that you need to press in order to indicate you want to cross the street (otherwise, you may wait a longer time, or even never get a chance to cross!)
That is mapped in OSM as button_operated=yes (on pedestrian crossings / crosswalks).
you seem to be talking here (if I understand it correctly) about vibrating / tactile indicator in form of a button (as used by blind persons as an alternative to red/green light signals). That is indicated by other tag in OSM, traffic_signals:vibration=yes. That is completely different âbuttonâ with different functionality, so it is also mapped differently.
Of course, the vibration button and sound signals (if present) always activate at the same time a green/walk light for sighted people, as they are alternatives for same functionality; that is taken for granted I hope?
Those are valid ideas. Iâve mentioned the use for blind persons before, but I did not one anticipate one for bicycles â at least here in Croatia, if youâre cyclist on the road youâll have to use regular car traffic semaphores (without any buttons of course); and if you are on the dedicated/shared cycleway youâll always be pushing the buttons the same as pedestrians would anyway. (as an avid bicycle user, Iâd be interested to know how such bike situation is implemented elsewhere, though!)
Relatedly, do you perchance know of any OSM navigation app that is actually currently able to do that suggestion (that is, notify the user that they should look for âpedestrian call buttonâ)?
Hm, it seems I wasnât clear: the point Iâm making is that, at least here in Canada, many buttons are for sound indicators only (the lights change on the same timer regardless); only mapping button_operated=yes in the case that it requests a light change is therefore to leave those who canât see buttons unable to know they should try to find one. Whether there are tactile or sound signals at all is independent of whether there exists a button to request an indicator that itâs safe to cross, which is what, IMO, button_operated=yes should represent on a crossing, particularly since those who canât easily see buttons are who would need this data the most.
at least here in Croatia, if youâre cyclist on the road youâll have to use regular car traffic semaphores (without any buttons of course); and if you are on the dedicated/shared cycleway youâll always be pushing the buttons the same as pedestrians would anyway. (as an avid bicycle user, Iâd be interested to know how such bike situation is implemented elsewhere, though!)
Yes, here in Canada, and in the US, biking can be a bit of an afterthought in street design, and many traffic lights (in particular, those that manage a smaller cross street intersecting with a larger road) only change when either a large metal vehicle is detected with an induction loop or a pedestrian button somewhere is pressed. I donât know of any apps that use this data for bike routing, but I donât actually use OSM while biking, itâs just a problem Iâve run into, getting stuck at a light that I need to dismount and hunt down a crossing button to trigger.
Most beg buttons Iâve seen are fairly low, but that doesnât necessarily mean theyâve placed in a reasonable location. Not only does this crosswalk go from nowhere to nowhere and lack a dedicated pedestrian signal, but its pedestrian call button is also on a post in the middle of nowhere, on the other side of a small ditch:
Iâd suggest mapping a call button as a separate utility=pedestrian_signal_button node whenever itâs less than accessible. No router would use it yet, but at least youâd be able to find the cruel joke the next time it comes up in a forum discussion.
A pedestrian call buttonâs function would be mapped for different reasons than its mere existence. There are plenty of things we map just because they exist, with no particular consumer use case. If a particular call button is just decoration, well, Iâve mapped plenty of art crosswalks. So I donât see a problem with tagging the buttonâs mere existence.
That said, the button_operated key is suggestive of a purpose and an effect, which I guess is why weâre debating feasible it is to observe that purpose. The âcallâ in âcall buttonâ refers to a request being made. An elevator has call buttons too, as does the receptionist desk on the other side of the lobby. I donât think itâs a big deal to map the ability to make a request, regardless if that request is ever heard or honored.
Here in the U.S., we have a derogatory nickname for these buttons, âbeg buttonsâ. I think it aptly captures the pedestrianâs sense of helplessness due to auto-centric signal configurations. It would seem kind of absurd to split hairs about a beg buttonâs efficacy before we even have an established way to tag whether a crossing has a dedicated walk phase you can wait for, versus braving traffic coming in from multiple directions. Where I grew up, most signalized intersections had beg buttons but no pedestrian signals. In some cities, pedestrians would never bother with such formalities, preferring to brave the traffic, but of course not everyone has that luxury.
Iâm definitely open to suggestions. So far Iâve only encountered these buttons on posts that you could kind of call utility poles, very short ones, but Iâd be stuck if I ever encountered one mounted on a wall.
)
