How to tag traffic signals turned off at night

Discostu36 · 2022-12-16T12:43:28.647Z

In Germany, it is not uncommon that traffic signals are turned off at night due to low traffic. I haven’t found any information in the wiki about how to add that information to OSM.

See this for example:

mapillary.com

Mapillary

Mapillary is the street-level imagery platform that scales and automates mapping using collaboration, cameras, and computer vision.

Would it make sense to add something like

highway=traffic_signals
highway:conditional=give_way @ 21:00-06:00

?

Nadjita · 2022-12-16T16:10:16.430Z

It’s actually two problems that need solving:

How to tag the times when a traffic light is operational
How to tag which rules apply if the traffic light is out of service

Personally, I think service_times=* would fit for tagging when it’s operational, but I’ve rarely seen it tagged on anything but churches.

I think the downside to your suggested approach is that separately mapped traffic lights use traffic_signals:direction=*, whereas yield signs use the generic direction=*, which means that you’d end with some odd tags like

direction=forward
highway=traffic_signals
highway:conditional=give_way @ 21:00-06:00
traffic_signals:direction=forward

If the traffic lights aren’t mapped separately, I think a simple service_times=06:00-21:00 should be enough. It would be nice to formalize a proper approach, because the whole traffic signal mapping is kind of a mess the way it is right now, and adding things on top of it won’t make it more readable.

Whether highway:conditional=* is a good idea, is a different concern. I tend to think that it’s strictly speaking not okay to put :conditional=* on something that is not a restriction, because the traffic lights don’t turn into traffic signs, it’s just that they are turned off. What I’m trying to say is: we need a way to tag the signs that apply when the traffic lights are turned off and :conditional seems the wrong choice to me.

Maybe we can agree on some simple solution like traffic_signals:off=give_way / priority / stop instead of using conditional restrictions. So my currently favorite tagging would be

highway=traffic_signals
traffic_signals:direction=forward
traffic_signals:off=give_way
service_times=06:00-21:00

This would have the benefit of not having to use a separate direction=*, because the direction of the traffic lights would also apply to the :off=*. Well … this is non-standard, but it’s a proposal that could be added iteratively and also mapped regardless of knowing the service times of the traffic lights. I always wondered why there wasn’t already a proposal how to tag the fallback-signs on traffic lights.

Just my 2¢

JeroenvanderGun · 2022-12-16T21:34:53.940Z

highway=traffic_signals and highway=give_way are typically separate nodes because they typically have different stopping positions (if the signals are off you stop closer to the intersection). In this case you can simply add service_times=* to the node with highway=traffic_signals and you’re done.

Nadjita · 2022-12-16T21:43:41.172Z

Are we expecting routers to magically know that these give way signs can usually be ignored, because they are close to traffic lights?
Also, the traffic lights stop position and the stop position for giving way / stopping are usually identical over here. The problem is that they are all using the highway-key, otherwise we could just tag them on the same node. I guess we’re caught between a rock and a hard place until someone invents proper and easy crossing-tagging. Until then … pray and hope for the routers to just work.

JeroenvanderGun · 2022-12-16T23:35:23.985Z

Nadjita:

Are we expecting routers to magically know that these give way signs can usually be ignored, because they are close to traffic lights?

Yes, I’d expect applications can figure this out if they need to, considering their close proximity. It should be a lot easier than properly estimating the waiting time for the signal itself (which e.g. requires spatial analysis of all arms of the intersection). But even if not, we can always consider adding a tag to the highway=give_way node to indicate it gets overridden by traffic signals.

Nadjita:

Also, the traffic lights stop position and the stop position for giving way / stopping are usually identical over here.

If you imagine the traffic signals and its associated stopping line were not there, would you really place the highway=give_way node in the same position? In the Netherlands we always have haaientanden separately from the traffic signal stopping line.

Kovoschiz · 2022-12-17T06:01:55.896Z

I find highway:conditional= for time worse than highway:lanes= to solve per-lane priority or signals, as the traffic control device always exist there. As a comparison, parking:*:access:conditional=no @ (*) is used, not parking:*:conditional=no @ (*). So far, I tend towards suggesting give_way:*= and traffic_signals:*=, to keep highway= a top-level feature to collect them.
traffic_signals:off= is inflexible. It can’t accommodate the case when the =signal becomes =blink_mode at night. service_times= or opening_hours= isn’t clear that it doesn’t apply to the =give_way.
Also, I believe these priority signs can exist without the traffic light being turned off regularly? As a fallback for failure or outage?

Kovoschiz · 2022-12-17T06:07:47.788Z

Modifying =give_way seems more misleading. It can be common on slip lanes, eg merging after a signalized crosswalk. Not to mention signalized crosswalk on roundabouts. Collapsing =traffic_signals is possible because they are usually coordinated or synchronous, and OSM has always needed to deal with =traffic_signals at dual carriageway intersections. This can’t be done reliably for =give_way at complicated junctions as they most likely each represents a priority rule, eg staggered intersections, or double (mini) roundabouts.

Nadjita · 2022-12-17T07:07:09.728Z

In Germany, there’s no difference between blinking traffic lights and them being turned off. In both cases, they are out of service and the traffic signs apply.

What’s the difference in your country between blinking and being turned off?

Also, over here, there is only a limited variety of signs allowed together with traffic signals:

Give way
Priority on next intersection
Priority road
Priority road not going straight
Stop

Only 1 and 5 could currently be handled by nodes. 3 and 4 are attributes on the way itself so there’s no way that I’d know of to somehow tag this on the traffic lights. 2 is not mapped at all as far as I can see, instead we map the corresponding give way sign.
So looking at this, we probably (also?) need a way to tag on a junction that priority is usually handled by traffic lights, since there could be cases where it’s unclear for a router if the tagged priority road applies or not.

Maybe we can start by agreeing on service_times being the proper tag for traffic lights service times? The question is: do they blink outside of these or go black and what’s the difference?

Kovoschiz · 2022-12-17T12:53:05.254Z

Of course there is. In Japan and Taiwan, flashing red is stop; flashing yellow caution (ie de facto priority). There are basically no signs.
The meaning of off being the same as blinking (in one jurisdiction) doesn’t equate to the off state being the same as blinking. Furthermore in Japan, they will be signposted as “night blinking” signals. It doesn’t make sense to say they are turned off.
relation has been discussed for turn-based priority and signals. The semantics of type=restriction may not be totally applicable here, as found in restriction=no_right_turn_on_red.

Nadjita · 2022-12-17T13:33:35.059Z

Kovoschiz:

The meaning of off being the same as blinking (in one jurisdiction) doesn’t equate to the off state being the same as blinking.

I think there’s a little misunderstanding. We also have blinking traffic signals, they just happen to mean the same as completely black ones, they are just trying to announce “be careful, intersection ahead”. If the meaning was rather “give way”, I would not consider them being turned off, but rather switching into a different mode (maybe traffic_signals:conditional=blinker @ (22:00-06:00) or similar?). So in case of Germany, considering the traffic lights to be off outside service hours would be perfectly fine, but of course not in countries where the traffic lights will switch into such a different mode instead of shutting down. I don’t want to suggest that.

How is traffic regulated without signs in case they are broken / in maintenance or during an outage? In Germany, there can be signs under the traffic lights (there usually are), but it’s not a must. In case of absence, it’s typically the general priority to the right. Is that the same in Japan? And how do you currently map traffic lights that switch between traffic_signals=blinker and traffic_signals=signal?

Minh_Nguyen · 2022-12-17T21:52:00.443Z

At the risk of further complicating this discussion, here are some suggestions for tagging similar situations in the United States. The particulars may not be relevant in your country because of the Vienna Convention/MUTCD divide, but the reasoning may help you arrive at a workable solution in your country.

Intersection control beacons

At any dangerous stop-controlled intersection, a blinking light called an intersection control beacon can be mounted above the intersection. Each approach that must stop sees a stop sign and a blinking red light, while each approach that does not stop sees a blinking yellow light but no stop sign. The rules would be exactly the same without a beacon.

commons.wikimedia.org

File:Intersection OH-506 and OH-124 Marshall, Ohio.jpg

commons.wikimedia.org

File:Markle Indiana.jpg

The beacons can also be mounted directly atop each of the stop signs:

commons.wikimedia.org

File:Estacate Emenkvnv Nene (37693405835).jpg

I used to tag intersection control beacons as highway=traffic_signals traffic_signals=blinker, because I was more interested in mapping traffic signals than stop signs and a typical renderer’s icon looked more accurate than a icon. But this is misleading because the rule is to stop and go in order of arrival, not to wait for a light to change colors.

Nowadays, I find it more accurate to add traffic_signals=blinker to the highway=stop node or traffic_sign=stop node for these beacons that only reinforce an existing rule. However, I’d be open to tagging flashing_lights=yes instead, for consistency with other sign-mounted warning beacons that don’t control traffic on their own.

Flashing traffic signals

Sometimes conventional traffic lights become flashing signals due to a power outage or low traffic volume. By law, drivers have to treat a flashing red light the same as a stop sign. We don’t map temporary events like power outages, so I don’t think this is particularly relevant. However, whenever a traffic signal is configured to flash at night or on the weekends, I’d map a highway=traffic_signals node at each stopline, tagging it differently depending on the off-hours priority rules:

traffic_signals:conditional=stop @ (00:00-05:00, 22:00-24:00) in the direction that has to stop (flashing red)
traffic_signals:conditional=blink_mode @ (00:00-05:00, 22:00-24:00) in the direction that does not have to stop (flashing yellow)

The blink_mode value isn’t the most intuitive, but it’s consistent with the documented value for cases where a traffic signal normally flashes except during special events.

4004 · 2023-11-08T10:57:28.477Z

Resurrecting this, as also came across this issue when mapping roundabouts.
Normally, the roundabout is managed with traffic signals at each entry, which stay on for most of the time, but will turn off ocassionaly. Give way signs are in place, next to the traffic signs, as a fall back.

I do like the conditional scheme suggested by the OP, as there is a non-zero chance of it being supported at some point, whereas I’ve not heard of any router supporting service times for route calculation. Has there been any change in view points since then?

Discostu36 · 2023-11-08T21:58:12.172Z

4004:

I’ve not heard of any router supporting service times for route calculation.

Osmand does support many conditional: tags, I don’t know about others.

Minh_Nguyen · 2023-11-09T03:37:35.008Z

GraphHopper, OSRM, and Valhalla each support a small subset of the conditional restrictions syntax for the most common cases, such as a road that’s only passable on weekday afternoons. They consider conditions for secondary attributes like access and maxspeed. I think routers could quite feasibly add support for time-based traffic_signals:conditional tags. However, I don’t think any renderer or router would support conditionalizing primary feature keys like highway:conditional anytime soon – it breaks too many assumptions.

Incidentally, OSRM penalizes all highway=traffic_signals, without regard for traffic_signals=*, so there’s no harm in conditionalizing it as traffic_signals:conditional=*, but no practical benefit yet either.

github.com/Project-OSRM/osrm-backend

Ignore intermittent or stop-and-go traffic signals

opened 09:20PM - 28 Jun 17 UTC

1ec5

Bug Report Profile

The car profile [treats](https://github.com/Project-OSRM/osrm-backend/blob/09df8…d47a532ffba7b4b53fe5a61eb4971e2f906/profiles/car.lua#L298-L301) any node tagged with `highway=traffic_signals` as a traffic light, presumably eligible for a penalty. However, not every `highway=traffic_signals` node would cause a car to stop for a significant amount of time. The auxiliary [`traffic_signals=*` key](https://wiki.openstreetmap.org/wiki/Key:traffic_signals) provides a bit more nuance: * `traffic_signals=blinker` has the same effect as a stop sign. I’m unsure whether that means it would take as long to traverse as an ordinary stoplight. * `traffic_signals=continuous_green` by definition requires no waiting. * `traffic_signals=blink_mode` and `traffic_signals=emergency` normally require no waiting. * Even when `traffic_signals=ramp_meter` is activated, it has the same effect as a stop sign. * [`traffic_signals=crossing`](https://taginfo.openstreetmap.org/tags/traffic_signals=crossing) is likely for footpaths, operated on demand either by button or sensor. It should have the same effect as any other crosswalk. * I’m unsure what [`traffic_signals=tram_priority`](https://taginfo.openstreetmap.org/tags/traffic_signals=tram_priority) and [`traffic_signals=bus_priority`](https://taginfo.openstreetmap.org/tags/traffic_signals=bus_priority) indicate, but they might be intermittent as well. taginfo [says](https://taginfo.openstreetmap.org/keys/?key=traffic_signals#projects) Valhalla supports this tag. Additionally, iD’s [traffic light preset](https://github.com/openstreetmap/iD/blob/9ce06549e19a07d648ec6bd3c20c816132e9c776/data/presets/presets/highway/traffic_signals.json) offers a [combo box](https://github.com/openstreetmap/iD/blob/c8e4f76c230512dc82dc060bf337e3ba489b113e/data/presets/fields/traffic_signals.json) based on the most common values for the `traffic_signals` key. /ref #3747 /cc @danpat

SekeRob · 2023-11-09T05:30:56.505Z

Odd, seen many times all signals switched to blinking orange (yellow} when there’s a problem or at night hours, which promotes paying attention.

edit:typos