I feel like the current way of tagging traffic lights is fairly limited to what we can map. It’s particularly notable because the equivalent for railway signals is quite extensive, particularly these of trams which also use (their own) traffic lights.
Denoting the states of traffic signals
Most traffic lights come in three states: Red, yellow and green but it also is common to have only red and yellow or even yellow and green (a more controlled version of right-on-red so to speak).
Some of it can be implied by some traffic_signals values but others aren’t so much, not to mention the same signal type can use different states.
Another important point is that normal traffic signals can also have special states which aren’t universal e.g. a user on the shared_green thread noted that some vehicle lights for pedestrian crossings in Spain blink amber after some time (with the intention that cars can proceed but still give way to pedestrians).
Multiple traffic signals laterally
There also is the issue that multiple traffic signals can be placed next to each other which can be either different signals for different lanes or for different vehicles.
Highways aren't the only ones which can benefit from this
Tramways traffic lights can also come up like this i.e. the same position has two separate signals with their own phases (e.g. a signal for turning left and another for moving straight right with a side effect that some states are duplicated). This image is one such example and there doesn’t seem to be a good way to denote these on ORM either.
No differentiation for lanes
This is a classic example: Each lane has its own signal.
My preferred idea is that to use the *:lanes suffix even if it’s unusual to use it for nodes but the justification here is that you can read the lanes on the connected highway but it also only works if each signal is mapped separately.
Signals for certain vehicles
Related to get into the detail, the current tagging is mostly focused on traffic lights for vehicles with support for pedestrian signals (mostly in the context of crossings). However, bicycles and buses can have their own signal too, sometimes on the same lane.
Buses are particularly notable because they share these with trams rams signals (which do have an aforementioned detailed way of tagging) in many countries and in case where they’re shared, it’s only possible to do so if the highway is drawn over the railway (like single-lane and oneway) but otherwise can’t share nodes.
Which the later is for pedestrian crossings. Its important to have this seperation as their routing penalty is very different. A pedstrian crossing has neglectable impact on travel times for the crossing motor_vehicle traffic.
And this should be kept in mind when adding more traffic_signals variants. Which signals have which penalty for the pedestrian/motor vehicle traffic?
What’s more unusual is using a subkey to qualify a primary tag. Does highway:lanes=traffic_signals override highway=traffic_signals, or does the feature have only highway:lanes=traffic_signals without highway=traffic_signals?
Incidentally, a separate scheme was proposed a few years ago for lane-based intersection control, but it was rejected.
I decided to go back to the idea and decided to formalise my first ideas:
Depending on the setup, the traffic signals can either apply to the road as a whole or on different lanes. For this reason, I use a scheme similar to the destination (particularly destination:symbol) i.e. there are three different separators, one for each level:
| is the group separator (a group being part of a single lane): Used to denote the individual signals on a per-lane basis (think of *:lanes)
; is the set separator (with a set being a single signal): Differentiates the individual signals for a single lane or for all lanes.
, is the unit separator: Further classifies a single signal such as which states it has or which lights are installed.
I also thought of introducing the following tags:
traffic_signal is kept unchanged except maybe properly formalising the key itself.
traffic_signal:<traffic_mode> denotes which signals are designed to which traffic mode. For example, if a bicycle signal exists, you use traffic_signal:bicycle and if one for buses exist, you use traffic_signal:bus instead. traffic_signal:vehicle also is valid and is used in specific cases to tell that certain lanes lack general vehicle lights (e.g. bus-only lanes).[1] Valid values are no (lack of signal) and yes (signal dedicated to a mode) — there is no designated nor only and any instance thereof should be replaced by yes if not replaced altogether.
traffic_signal[:<traffic_mode>]:states which contains the different states a signal can be in (when active). Keep in mind that deactivated also is a state since not all signals are active all the time (e.g. an emergency signal which is off by default). Accepts generic values such as go, stop and off but country-specific values with their codes also are valid and may be preferred.[2] The individual states are comma separated.
traffic_signal[:<traffic_mode>]:arrow to denote the turn arrows for the individual signals with values similar to turn. If a single signal has multiple arrows, separate them by commas.[3]
traffic_signal:fallback is used to denote a fallback in case it has been disabled or is faulty . Possible values include none (the default and generally not mapped), give_way and stop
In general, the need to specify a certain direction depends on the connected highway: It can be dropped if the signals are unidirectional (e.g. installed on a one-way or traffic_signal:direction isn’t both) or if the signals are the same for both directions. In a very unlikely situation where there are different set of lights in both directions, one can suffix the differences with :forward and :backward, only happening if there are two independent.
On that aside, a similar scheme can also be adopted for tramway signals where you sometimes have two one-by-one with their own signal phases (e.g. one which denotes left turns and one which denotes going straight) but that’s outside the definition of any proposal (but feel free to take inspiration of it, ORM team).
Conversely, certain ORM schemes can also be adopted to the traffic signal expansion such as bus priority signals.
Naturally, there is the limitation that it doesn’t work on highway=traffic_signal in the middle of a junction so this sort of tagging only works in the grand scheme on micromapped traffic signals. However, it is entirely valid when used in the middle of a linear way.
All the ideas will be collected for a proper proposal. Feel also free to suggest some example images.
Pedestrians are assumed to be unaffected by these and the corresponding is crossing=traffic_signals, not to mention traffic_signal is already used for something else, though please do mention relevant exceptions. ↩︎
This is relevant when the signals in questions are entirely different for each traffic mode — e.g. buses and trams in many highway codes use the same set of signals. ↩︎
For example, if there is only one lane but separate lights for through and right turns, you use traffic_signal:arrow=through;right but if there is only one for through and right turns, you use traffic_signal:arrow=through,right instead. Naturally, if through and right turns are on separate lanes with their own lights with arrows, you tag it with through|right instead ↩︎
Although I think the historical concerns about mapping highway=traffic_signals on intersection nodes have been overblown, micromapping them at stoplines is clearly where we’re headed. It means both routers and renderers will need to do some postprocessing to reassociate the traffic signals with the intersections. Good thing OSRM recently released proper support for traffic_signals:direction=*! But some cases will always be harder without something to explicitly associate the traffic signal node with the intersection node:
The main pain point I have with traffic signals at the stopline is that there can be a many-to-many relationship between roadway centerlines and stoplines, a many-to-many relationship between stoplines and signal heads, and even a many-to-many relationship between lanes and stoplines.
For lack of an established approach for tagging the roadways, I’ve experimented with micromapping traffic signal gantries and individual signal heads, especially at an unconventional interchange like a SPUI or superstreet. My first attempts at this attracted some skepticism. It’s good to know that I’m not alone in wanting to micromap signalized intersections, and railway signaling might give us a reasonable model to follow. That said, I think it’s worth reassuring the community that this degree of micromapping won’t be a baseline requirement, at least not for a long time.
