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:
Would it make sense to add something like
highway=traffic_signals
highway:conditional=give_way @ 21:00-06:00
?
It’s actually two problems that need solving:
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¢
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.
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.
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.
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.
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?
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.
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:
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?
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.
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?
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.
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.
The beacons can also be mounted directly atop each of the stop signs:
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.
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.
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?
Osmand does support many conditional: tags, I don’t know about others.
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.
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