Proposed features/Traffic Signal Timings

From OpenStreetMap Wiki
Jump to: navigation, search
Traffic Signal Timing Groups
Status: Draft (under way)
Proposed by: gappleto97
Tagging: type=timing
Applies to: Relation
Definition: A way to indicate relative timing for traffic signals
Rendered as: hidden
Drafted on: 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 Reddit: https://www.reddit.com/r/openstreetmap/comments/7c404i/feature_proposal_draft_traffic_signal_timings/

On Tagging Mail List: https://lists.openstreetmap.org/pipermail/tagging/2017-November/034081.html

Comments

Please comment on the discussion page.