Proposal:Traffic Signal Timings
| Traffic Signal Timing Groups | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | gappleto97 |
| Tagging: | type=timing |
| Applies to: | 
|
| Definition: | A way to indicate relative timing for traffic signals |
| Statistics: |
|
| Rendered as: | hidden |
| Draft started: | 2017-11-08 |
Proposal
To create a relation specification for relative traffic light timings.
Constraints
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
Rationale
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.
Tagging
Basic tagging is as follows:
| Tag | Notes |
|---|---|
| type=timing | (required) |
| 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:
- Blank
- A number
- A name
- A colon followed by a name
- A number and a name separated by a colon (
3:example)
And members can be either:
Role Parsing
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.
The :name role can also be preceded by a number, which indicates its position in a cycle.
Sync
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.
Opposite
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.
Wave
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.
Cycle
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.
Examples
Simple Case
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:
| Tag | Value |
|---|---|
| type | timing |
| timing | sync |
| strict | (assumed yes) |
| night | yes |
| Members | Role |
| Node 200224382 | (blank) |
| Node 200224378 | (blank) |
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.
Relation 1:
| Tag | Value |
|---|---|
| type | timing |
| timing | sync |
| strict | (assumed yes) |
| Members | Roles |
| Node 4959310776 | (blank) |
| Node 4959310775 | (blank) |
| Node 185384949 | :Presque1 |
| Node 185384949 | :Presque2 |
| Way 525495610 | Presque1 |
| Way 34269243 | Presque2 |
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.
Relation 2:
| Tag | Value |
|---|---|
| type | timing |
| timing | sync |
| strict | (assumed yes) |
| Members | Roles |
| Node 4959310777 | (blank) |
| Node 4959310774 | (blank) |
| Node 185384949 | :Wright1 |
| Node 185384949 | :Wright2 |
| Way 17901961 | Wright1 |
| Way 34269250 | Wright2 |
Relation 3:
| Tag | Value |
|---|---|
| type | timing |
| timing | opposite |
| strict | (assumed yes) |
| Members | Roles |
| Relation 1 | (blank) |
| Relation 2 | (blank) |
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.
Diagonal Crosswalks
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.
| Tag | Value |
|---|---|
| type | timing |
| timing | sync |
| strict | (assumed yes) |
| Members | Roles |
| Node 1499530624 | (blank) |
| Node 1676749591 | (blank) |
| Tag | Value |
|---|---|
| type | timing |
| timing | sync |
| strict | (assumed yes) |
| Members | Roles |
| Node 2021391989 | (blank) |
| Node 1499530621 | (blank) |
| Node 1499530620 | (blank) |
Relation 3:
| Tag | Value |
|---|---|
| type | timing |
| timing | cycle |
| strict | (assumed yes) |
| Members | Roles |
| Relation 1 | 1 |
| Node 291758776 | 1:tertiary1 |
| Node 291758776 | 1:tertiary2 |
| Relation 2 | 2 |
| Node 291758776 | 2:tertiary3 |
| Node 291758776 | 2:tertiary4 |
| Node 291758776 | 2:公園通り |
| Relation 1 | 3 |
| Relation 2 | 3 |
| Node 3608568719 | 3 |
| Node 3608568720 | 3 |
| Way 23334685 | tertiary1 |
| Way 213526440 | tertiary2 |
| Way 376162311 | tertiary3 |
| Way 31610468 | tertiary4 |
| Way 260252968 | 公園通り |
Applies To
Rendering
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.
Features/Pages Affected
External discussions
On Telegram: https://t.me/OpenStreetMapOrg
On Tagging Mail List: https://lists.openstreetmap.org/pipermail/tagging/2017-November/034081.html
Comments
Please comment on the discussion page.