Button operated traffic signals

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.)

3 Likes