Proposed features/Traffic Signal Timings
|Traffic Signal Timing Groups|
|Status:||Draft (under way)|
|Definition:||A way to indicate relative timing for traffic signals|
To create a relation specification for relative traffic light timings.
This proposal does not cover, and is not intended to cover, the following scenarios:
- Emergency vehicles overriding normal patterns
- Signals that dynamically interact with each other
This would assist navigation applications. If there are two traffic lights in a row, at two separate intersections, it is very useful to know whether or not they are synchronized. If so, then the longest delay is still the same as if it were only one traffic light.
The tagging scheme was chosen, as it was the simplest that I could think of that covered both synchronized traffic lights and diagonal crosswalks.
Basic tagging is as follows:
|timing=*||Possible values: sync, opposite, wave, cycle (required)|
|on=*||Needed only for timing=wave. Possible values: green, red, both|
|strict=no||Indicates that a signal can be overridden in some way, for instance skipping cycle elements by road sensors|
|night=*||Indicates that a light has different behaviour at night. If it's the same, do not tag. Otherwise night=yes indicates nighttime and night=no indicates daytime|
|interval:*=*||An optional tag which indicates the interval between two elements of a wave or cycle. interval:1=3 would indicate that the period between the start of part 1 and the start of part 2 is 3 seconds long.|
|interval=*||A variant on the above for if the cycle has a purely uniform interval|
Roles are always given in one of the following forms:
- A number
- A name
- A colon followed by a name
- A number and a name separated by a colon (
And members can be either:
A blank role refers to the entire intersection, or on a crossing refers to the associated pedestrian ways. A role with a number does the same, while also indicating its position in a cycle or wave.
A role with a colon followed by a name refers to only the part of the intersection defined by
name. To figure out which way this applies to, you can check the relation for the role
name. So to reiterate:
:name refers to the intersection as it relates to way
:name role can also be preceded by a number, which indicates its position in a cycle.
This indicates that each member is active or inactive at the same time. It either refers to the entire traffic light, or just the way referenced by the light's role.
This is restricted to two members. It indicates that each member is only active when the other is not. Note that it can be useful to have other timing relations as members to this.
A wave refers to a set of traffic lights which has a rolling activation window. In other words, the green light will appear to flood the road from 1 to n. Because waves sometimes do--and sometimes don't--turn red at the same time, a on=* tag is required. If it's on=green, that means that for red lights these can be considered as a timing=sync relation.
A cycle is distinguished from a wave in that the activations don't overlap. So when 1 activates, it must deactivate before 2 begins (unless that element is also in 2). Because of this, an
on=* is not necessary. Otherwise tagging is identical to a wave.
The simplest case is demonstrated by the intersection of US-41 and Grove in Marquette, Michigan. These two lights are part of a larger intersection, and are locked in sync with each other. (Note: this intersection has since been changed into a roundabout. I will find another simple example.)
This is most easily described as follows:
Integrating Pedestrian Crosswalks
For this case, we'll look at the intersection of Wright and Presque Isle, again in Marquette. This intersection consists of one light for road traffic, and four for pedestrian traffic. To mark the synchronization for this, we need three relations.
In addition, this example shows how you specify the direction an intersection is activated on. Note that for crossing=traffic_signals, it is assumed that a non-specified direction means only the pedestrian portions.
If Presque Aisle Avenue was a continuous road, it would only need one entry. Because it is split into two ways at this intersection, it requires two direction entries.
Alternatively, you can look at an in-place example at the intersections of 7th and College/Magnetic, again in Marquette.
In that case, the night=yes is because the light takes on a different behaviour at night. One side (the same for both) becomes blinking yellow, the other (again, same for both) becomes blinking red. Because the different groups still keep the same behaviour, they can still remain in a day/night sync group.
Since I don't have one locally, to make this example I will need to make some guesses about cycle order. If you happen to live in Tokyo, please feel free to correct me here.
This example will focus on Shibuya crossing, in Tokyo. To represent this, we will need three relations. It could be done in one relation, but would be uglier. It could be done with five relations, and the final relation would be significantly smaller. It comes down to stylistic preference more than anything else.
None on the main map. To do so would be overly complicated and not provide information to the user.
In a navigation application, one could show the intersection timing if the user is at a stop. This would allow them to estimate their remaining time at the intersection.
On Telegram: https://t.me/OpenStreetMapOrg
On Tagging Mail List: https://lists.openstreetmap.org/pipermail/tagging/2017-November/034081.html
Please comment on the discussion page.