Proposal:Traffic Signals
This Proposal replaces the old proposal that you can find at Proposed features/Traffic Signals (inactive)
| Traffic Signals | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | lukas.schaus |
| Applies to: | node/way |
| Definition: | This proposal covers the modelling of complex traffic light circuits with the introduction of a new relation and a small extension on the lane-tagging-features. |
| RFC start: | 2015-02-02 |
| Vote start: | 2015-02-09 |
| Vote end: | 2015-02-23 |
Proposal
This proposal introduces an easy way to model traffic signals at any kind of intersections in a more detailed way. Two factors are missing in the current modelling:
- Putting all traffic signals in complex multi node intersections into relation to their corresponding destination- (to-)way
- Modelling the phases of each traffic signal
Current discussions on this topic are often resulting in increasing the geometric complexity of intersections by mapping each lane individually. We suggest to use relations similar to the turn restriction relation but for every incoming way to an Intersection. The relation specifies the duration of red and green light phases for every turn possibility and specifies the outgoing- (to-)way
Rationale
Routing algorithms will be considering traffic signal phases in the not too distant future. OSM should provide a best practice to model those in order to help routing application developers. Also for traffic simulation it would be a huge benefit and cities could become more efficient. Intersections are built in many different ways and the modelling in OSM at the moment does not always reflect the real world. For flexibility the concept of using relations is a very helpful and a powerful tool.
Tagging
An Intersection with traffic_signals shall be represented through one relation per incoming way. Please note that one intersection can comprise more than one node. This relation includes the traffic-signal node, one incoming way (from-way), one to-way, and optional via-ways which connect the from- and the to-way in complex intersections.
Members
| Way or node | Role | Recurrence | Description |
|---|---|---|---|
|
signal | 1 | A node with the tag highway="traffic_signal" which represents the signal regulating this turn relation. |
|
from, from:forward, from:backward | 1 | The incomming way arriving at the signal. It must be connected to the signal |
|
|
to:<turn> | 1 to 10 (number of turn possibilities) | The way where the turning ends specified for every turn |
One node with the key highway=traffic_signal. It represents the geographic location of the traffic signals.
One from-way has to be included in the relation. If the node is tagged at the crossing and the way ends at the node, the driving direction the traffic signal applies to is obvious. If the same way continues after the node (the node is not at the end of the way) clarification can be achieved by from:forward=* or from:backward=*. Example:
<member type="way" role="from"/>
or
<member type="way" role="from:backward"/>
For every turn possibility there should be a to-way specified. The vales of the turn key introduced in Key:turn are used as identifiers
turn: {reverse, none, sharp_left,
slight_left, merge_to_left, merge_to_right,
through, slight_right, right, sharp_right, crossing(see below)}
Additionally the value crossing instead of the mentioned turn values can be used to define the timing and the occurrence of a pedestrian crossing traffic signal.
To-Way Example <member type="way" ref="" role="to:left"/>
This clarifies the destination of a specific turn since that is not always obvious for complex intersections. If turn:lanes are available in the from way, the traffic_signal can be assigned to a specific lane because the same keywords are used.
Tags
| Key | Description | Example value |
|---|---|---|
| phases, phases:<turn> | Describes the duration of each phase of the traffic signals. Using the phases key without a <turn> specification will set the default configuration for all traffic_signals in this relation. The default configuration can be overwritten by a specific definition e.g. phases:right. The value is a combination of the specifier for a phase (g: green, r: red, y: yellow, ry: red-yellow, yblink: blinking yellow, ... further specification possible) followed by the time in s for which the phase is active in one circuit. | g80|r40|ry3 |
Examples
Traffic signals are used all around the world. Their number should be in the high millions even though only 670000 are modelled in OSM. There are different scenarios where traffic signals are used:
- footway/cycleway crossing
- triangle intersections
- standard intersections
- complex intersections
- roundabouts
- train crossings
- and many more
Here is an example for a complex intersection:
|
<relation id='FROM_4'> |
The relation for incoming way 4. The key from:forward is not needed since the node is at the end of the way. In this Example the traffic signals have the same phases for all the turn possibilities. The signal is roughly 40 seconds red and ca. 80 seconds green. The time for yellow and red-yellow is not specified. An application builder can guess these or use the standard timing. The conditional option can be used to model different programs at different times of the day. The conditional rule overrules the general rule in the given time and can be used like described in Conditional restrictions |
|
<relation id='FROM_10'> |
This is the relation for the incoming way 10 with the traffic signal at the Southeast node. Also the key forward is not necessary since the way ends at the node (and is a one-way). The general phase declaration applies to the right and the through turn lanes. For the leftmost lane which is specified as turn:lanes=through;reverse The specific declarations apply to this lane. The conditional declaration also only effects the right and through lanes. A conditional declaration for the leftmost lane could be achieved by phases:left:conditional=* @ * |
|
<relation id='FROM_SOUTH_WEST'> |
The relation for the way arriving from the bottom left edge to the traffic signal. The role from:forward is necessary since the red way is no Oneway and the way does not end at the node. |
|
|
Applies to
Nodes, Ways, turn restriction, lanes
Rendering
This relation must not be rendered since it is more important for algorithms than human viewers
Features/Pages affected
turn_restriction turn restrictions could differ from the possible turns in this relation. In that case users should consider which is the valid restriction for this case.
Comments
Voting
Vote with {{vote|yes/no}} --~~~~
Vote is open:
I approve this proposal. briegel (talk) good way for a standard scenario, nevertheless,dynamically phases should be handled in a different approach. 20:52, 9 February 2015 (UTC)- I approve this proposal. This is a viable feature for simulation and routing and keeps the complexity to a minimum. --Lukas.schaus (talk) 14:30, 9 February 2015 (UTC)
- I approve this proposal. This second version is a lot better than the first version. --Nakaner (talk) 18:31, 9 February 2015 (UTC)
- I approve this proposal. Javbw (talk) 20:52, 9 February 2015 (UTC)
- I approve this proposal. --Khuebner (talk) 11:11, 10 February 2015 (UTC)
- I approve this proposal. --Gsnerf (talk) 13:31, 10 February 2015 (UTC)
- I approve this proposal. --Fanfouer (talk) 12:32, 10 February 2015 (UTC)
I oppose this proposal. Topics such as mapping the physical location of traffic signals should have be taken into account before voting, as these things are hard to add later. Unfortunately, there have not been a full two weeks since the RFC for the new version of the proposal, which would have allowed for such discussion to occur. --Tordanik 15:21, 10 February 2015 (UTC)- I oppose this proposal. Encourages mapping unmappable - typical traffic signal sequence depends on number of variables Mateusz Konieczny (talk) 16:48, 10 February 2015 (UTC)
- I oppose this proposal. Way too complicated and probably pretty useless as there are too many parameters involved. The timings are usually not fixed but depend on time of day, dynamically on road sensors or they are remotely controlled. Furthermore traffic signals are often interconnected in order to create green waves etc making it difficult to calculate an estimated delay based on the phases tag alone (even if it could be trusted). And finally, the relations are unnecessary as the tags could be added directly to the traffic_signal node as long as it is mapped at the stop line. --opani (talk) 18:29, 10 February 2015 (UTC)
- I oppose this proposal, for the time being. The proposal covers routing features which deserve more thought. -Hlaw (talk) 20:47, 10 February 2015 (UTC)
- I oppose this proposal, for the time being. Switching phases (tag phases:*) are dynamic processes of traffic lights. My opinion is that not correctly capture and do not belong to OSM. -streckenkundler (talk) 20:17, 11 February 2015 (UTC)
- I oppose this proposal, for the time being. Although such a proposal is quite important I'm still missing some key aspects. I'd like to see the voting be deferred until further discussions (1 week discussion is not enough until voting) --Peda (talk) 21:03, 11 February 2015 (UTC)
- I oppose this proposal. Phases of traffic signals are controlled more and more dynamically. Even the occurence of a red resp. green phase is often dependend on vehicles activating sensors. Special vehicles like buses, fire engines or police, local events like exhibitions or street festivals, wheather dependend traffic light programs, season dependend traffic light programs and many more effects make this data useless. --Osmonav 09:55, 12 February 2015 (UTC)
- I oppose this proposal. This proposal comes too early. A junction with signal times mapped also can have traffic signals mapped in a manner that relations are not needed. We need to move forward junctions detail mapping and see how traffic signaling fits in afterwards. --Jojo4u (talk) 10:02, 12 February 2015 (UTC)
- I oppose this proposal. Too early, too raw. There are a lot of things to be improved. --Zverik (talk) 19:07, 12 February 2015 (UTC)
- I oppose this proposal. Complex mapping of fragile data better collected elsewhere. Brycenesbitt (talk) 13:38, 13 February 2015 (UTC)
- I oppose this proposal. Too complex for the benefit of things which might not even belong into OSM or are at least not properly measureable, such as the timing. Also little mapping efforts for traffic lights won't become better with such a complex scheme. KISS and only tag which lanes are affected, just as is right now. --HybridOL (talk) 16:09, 13 February 2015 (UTC)
- I oppose this proposal. Too complex.--Pieren (talk) 14:59, 16 February 2015 (UTC)
- I oppose this proposal. I think this is a bit too complicated in my opinion because the reality is far too flexible and variable to figure out. Grouping traffic lights into a simple relation type=highway/highway=traffic_lights with the roles "forward/backward" for each member might be a possible alternative, but at the end of the day I map traffic lights as a simple node, with crossings shown separately. I am not saying that this proposal is valueless, because it reminds me of what I have just thought of. --Amaroussi (talk) 11:02, 17 February 2015 (UTC)
- I oppose this proposal. Complex proposal even in the simplified form. Major effort in mapping with little or even misleading impact on routing. Both direction-based lights as well as phase timing can change dynamically which is not mappable, not observable and not verifiable. Clusters of synchronised light have much more impact on driving time than individual phases. --Polarbear w (talk) 11:55, 17 February 2015 (UTC)
- I oppose this proposal. Oversimplified proposal is not usable for data consumers. There need for relations because they are intrinsic to traffic signal switching. Arguments "this proposal too complex" should be ignored IMO. You need to enter information about three signals somehow, either you use 3 tags or 3 values. You cannot avoid this. Proposal was way more usable for data consumers in its previous form with relations per direction. Complexity of tagging should be handled by smart tools to enter and edit data. Data model should be as precise as possible for consumers. Xxzme (talk) 12:27, 17 February 2015 (UTC)
- I oppose this proposal. Too complex, and I don't think that this kind of data belongs into OSM. --Zimba (talk) 20:52, 17 February 2015 (UTC)
- I oppose this proposal. although I agree that traffic lights are a topic where we lack concepts for micromapping I think that this is not mature enough and should be improved. --Dieterdreist (talk) 16:44, 19 February 2015 (UTC)
