Pedestrian signals thread

To discuss - how do you survey them? How do you map them? What does and doesn’t work, what’s missing in the existing schemes?

I’ve mapped relatively few despite surveying a lot because of how ephemeral they are. One of the first ones I mapped a couple months ago is gone already and I had to go back and mark it as such. I still haven’t worked out how to approach these because they’re ostensibly important but they have a shorter lifespan than painted crosswalks where I live.

I don’t know if any existing routing routines have penalties for pedestrian signals, but that would be one use case for mapping more of these.

Fundamental issue is that crossing | Keys | OpenStreetMap Taginfo is badly designed

crossing:island | Keys | OpenStreetMap Taginfo is much better - we should have crossing:traffic_signals=yes/no (or with more values?)

That would handle much better cases where for example people map from aerial imagery and better express things than what we have now.

1 Like

crossing:signals=yes/no has been proposed for several years, and now it’s finally documented. In one of the cities where I map, it’s slowly being adopted in neighborhoods where there are crosswalks that are signal-controlled but not marked or vice versa, in combination with crossing=marked/unmarked. This way we can also find intersections where no one has yet determined whether it has a signal.

Heh, I have the opposite problem. In some cases, I’ve returned to crosswalks that I had thought were signalized but unmarked, only to find that they were marked: the paint had worn so badly that it was only barely visible in street-level imagery but undiscernible in high-resolution aerial imagery. From a safety perspective, it was basically nonexistent. This problem is especially prevalent in snowy places, where road salt wears down the paint.

(That said, there are plenty of crosswalks across the U.S. that are designed to be signalized but unmarked. It’s one of the configurations explicitly allowed in federal regulation.)

The established and proposed tags leave out some distinctions and details that I would like to be able to incorporate into the database somehow.

Signalization without pedestrian signals

At some crossings, pedestrians wait for a dedicated walk signal. At other crossings, they wait for the standard traffic signal for cars to turn green. I see this a lot in less built-up areas and at older urban intersections, even ones that have pedestrian signal call buttons:

West Loveland Avenue and Wall Street, Loveland, Ohio (© Minh Nguyen, CC BY-SA 4.0)

I currently tag them just like the intersections with pedestrian signals, because the timing for both cars and pedestrians remains unaffected. However, it’s less safe than an intersection with pedestrian signals. A green light isn’t as specific as a walk light at intersections with unprotected turns.

Crosswalk intersections

Some signalized crossings are part of a normal road intersection and are coordinated with the main traffic signals. Other signalized crossings have similar traffic signals, but there’s no cross traffic other than pedestrians:

Madison Road, Cincinnati, Ohio (© realadamp, CC BY-SA 4.0)

Sometimes these crossings are even combined with other traffic-calming features like speed humps or tables:

Airport Boulevard, San José, California (© lvl5, CC BY-SA 4.0)

Another mapper introduced me to crossing=pedestrian_signals on the crossing way and traffic_signals=pedestrian_crossing on the traffic signal nodes, but I’m unsure if others are using these tags for the same purpose. It probably makes sense to tag HAWK beacons similarly, since crossing_ref=hawk is country-specific.

Time limits

Most of the signalized crosswalks in my area now have countdown timers and even read the seconds aloud, so it’s pretty easy to survey the time limits. It could be useful for identifying crosswalks that don’t leave enough time to cross without running – not unheard of around here. I’ve thought about tagging them as durations, but some routers literally treat that key as the duration of the routing edge, which defeats the purpose. I’d rather not have to divide the length by the time limit to get a minspeed value. :grimacing:

3 Likes

OsmAnd’s cycling and walking profiles apply a penalty at crossings that varies depending on the crossing classification. However, it only supports the crossing=traffic_signals/uncontrolled/unmarked scheme, which is designed for countries that follow the Vienna Convention.

OpenTripPlanner apparently used to prefer signalized crosswalks over unsignalized crossings using the crossing=pedestrian_signals tag, but I can’t find any reference to it in the codebase anymore. GraphHopper has declined to estimate a penalty for signalized crosswalks.

Aside from routers, @SomeoneElse’s style renders crossing=traffic_signals as a :vertical_traffic_light:, just like highway=traffic_signals.

1 Like

It’s good to see crossing:signals documented, I hadn’t realized it wasn’t.


Most of these pending service requests are broken pedestrian signals. I haven’t kept up with it in a few months, but sometimes I’ll get annoyed enough walking to the bus stop that I’ll spend the ride reporting these. I got a call from someone at city DOT who told me what I need to do is break these down into as many individual steps as possible - if there is one intersection with four broken buttons and four broken lights, make 8 reports even if they’re all connected. Otherwise, the people they send out to fix these will just read what they see as the first “part” and mark it as closed without finishing the rest. According to this guy that’s what happens anyway, as far as I know most if not all of these haven’t even been touched. Another time a lady at DOT left a voicemail telling me to just stop reporting them because nobody reads them. It’s at least reassuring to know there’s a threshold you can reach with these where people decide you’re being annoying enough to talk to.

(Green and blue don’t mean anything here. One of two things happens: it gets closed without comment within a few hours of the report, or it stays open indefinitey.)

These reports all get published in a big GeoJSON file, so mapping these in OSM at any point would be pretty straightforward. Really I need a partner on the east side of town to cover more ground though, for all I know there could be more broken signals there.

I’ve tried out a couple ways of mapping signals at the curb side/corner - mapping them on the button location for button operated, or mapping them as nodes in the sidewalk. Maybe a combination of both where the sidewalk way meets wherever the button is somewhere; especially for weirdly configured corners it at least conveys that you’re expected to stand in or move to that spot before crossing. It’s not apparent which if any of these methods is the most useful though