Proposal talk:Traffic Signals

Discussion after major update at February 2nd 2015

Please discuss here:

Position of the physical traffic signal

In the past, there have often been discussions about the location of the traffic signal node: Should it be on the junction, on the way leading to the junction, or the actual position of the traffic sign pole? Depending on the use case, all three have merit, and so I've always hoped that a future traffic signal proposal would reconcile them with a solution that optionally allows all three to be mapped. At the moment, your proposal doesn't offer a possibility to map the physical position of the traffic signal, but perhaps you are interested to add a solution for this long-standing problem? --Tordanik 15:11, 10 February 2015 (UTC)

This proposal merely doesn't require that the traffic light is positioned at the correct physical position, but it doesn't conflict with the possibility to do so. Even with this proposal you can place the traffic light node at the correct position before the actual intersection. Lane turn definitions should be placed before the traffic light either way and in conjunction with placing an intersection area to group all traffic lights there is no algorithmic problem to correctly calculate routing information etc.. It should be noted, that this proposal doesn't replace how intersections are tagged in general, but extends existing regulations with more specific information for traffic light switching. --Gsnerf (talk) 15:43, 10 February 2015 (UTC)

The requirement that the incoming way is connected to the signal essentially excludes the option of mapping the actual position of the sign pole. - Hlaw (talk) 19:58, 10 February 2015 (UTC)

I was under the impression, that the 'actual position' would refer to the traffic lights position relative to the way where the cars would need to stop because of the traffic light. In the case of representing the pole itself I fail to see the connection to the relation proposed here. I would think thats a completely different matter which would require a proposal of it's own. --Gsnerf (talk) 21:21, 10 February 2015 (UTC)

I am not a fan of mapping the pole with a standalone highway=traffic_signal either, but this seems what was meant above as one of the styles. Mapping the vehicle stop position should already be subsumed under 'on the way leading to the junction'.

I don't think the present proposal intends to concern itself with the styles of mapping traffic signals, but it is taking the "name space" of "traffic_signals" relation (which might be expected to do so), and also putting a constrain that the traffic signal node is on the way. I think the issue could be addressed if this proposal is made a little bit flexible by relaxing the current constrain that the way is connected to the signal node (see my comments below). -Hlaw (talk) 06:54, 11 February 2015 (UTC)

I was indeed thinking of mapping the pole. This would include clarifying e.g. that the same traffic lights apply to the pedestrian crossing as to the junction nearby, and that it is on the same pole as the traffic signal for pedestrians crossing the road. To represent this, relations will likely also be necessary. As this proposal already introduces a large number of relations to junctions, I would have hoped to use the same relations for all information related to a traffic sign (e.g. by adding more members in the relation).

Of course, this can be added later to some degree, but I'm not sure if rules like "one relation per incoming way" or the way pedestrian crossings are handled are the best fit for what I have in mind. --Tordanik 12:05, 11 February 2015 (UTC)

I did not know that people were tagging the pole. I was only aware of the traffic_signal-node being at the crossing or at the stop-line. That is why I used the restriction - The traffic-signal node has to be at the from way. I could simply not see the need for the node being away from the from-way. Now I see the need to remove this rule and can't find any downside to do so. This way the relation could handle all tree methods of mapping the signals.

The rule one relation per incoming way seems reasonable to me. I can not think of a case where it should be done in a different way. Maybe you can show me an example.--Lukas.schaus (talk) 10:25, 12 February 2015 (UTC)

I don't think allowing the signal to not be on the from way is that easy as in the current form the relation relies on it to determine the direction the traffic light faces. There could be a separate node that can be tagged separately and even referenced in the relation, though I don't see any benefit from it for the desired effect? --Gsnerf (talk) 15:29, 12 February 2015 (UTC)

Use of a via node (eg the intersection node) as in turn restriction will do. It can be the same as or different from the signal node. Another model is the enforcement relation, which also places no restriction on the mapping of the camera. -Hlaw (talk) 04:23, 13 February 2015 (UTC)

Usage for routing / navigation

The revised proposal now addresses the more generic issue of mapping the relation of turn lane values (slight right, right etc) between an incoming way to destination way(s). Together with the turn lane tagging, this would largely address the issue of lane connectivity, not just the problem signal phase per lane. The part of the scheme would potentially be useful for navigation, beyond the original intention of signal phases.

For the purpose of specifying the turn lane destinations, I would prefer the style of the present proposal than the lane connectivity, as it needs much fewer relations (one relation per incoming way, instead of for each possible connection from each incoming way at most).

I think the proposal deserves further discussions as a result of its wider application. From the perspective of routing my view is-

• the mapping would be useful even in the absence of traffic signals. Instead of using a different type of relation for junctions with / without traffic signals, a signal relation should apply. (In other words, "hijacking" this proposal and making traffic signals optional)

• it would be useful to include the tags "applies_to" and "preferred" as in the lane connectivity proposal above (suffixed with :<turn>). This may also be relevant to traffic signal phases, for example, there could be different traffic signals for trams and other vehicles for the same direction (an example).

• to:<turn> roles with the same <turn> value should be able to occur more than once. e.g. 0, 1 or more ways could be specified with the role "to:right", where in reality different ways are permissible destinations for lane(s) marked with "right turn". Recurrence of to:<turn> need not be limited to 10.

• I am not sure of exactly what "crossing" refers to. In the intersection of 2 dual carriage ways there can be 8 crossings, with only 4 incoming ways.

• I think the criteria of whether ":forward" ":backward" is necessary should not be relevant to whether the way ends at a particular node, but instead whether the incoming way is oneway (for all lanes). Anyway, I think a better scheme would be to specify the incoming way using "from" way and "via" node (where the from way terminates at the via node in the incoming direction), as with turn restrictions. This would require breaking up the way but at this level of micro mapping this is probably already done. This would make it immune from edits which reverse the way concerned (besides being more familiar to most mappers).

- Hlaw (talk) 19:58, 10 February 2015 (UTC)

the mapping would be useful even in the absence of traffic signals. Instead of using a different type of relation for junctions with / without traffic signals, a signal relation should apply. (In other words, "hijacking" this proposal and making traffic signals optional)

I did not think of this being needed since junctions without signals are usually simpler but as you say it there will probably be some junctions where it is needed. I guess the proposal could be changed to fit this requirement. Probably the name should change then. Alternatively there could be a second type of relations introduced in the future which does the same but without traffic signals.

it would be useful to include the tags "applies_to" and "preferred" as in the lane connectivity proposal above (suffixed with :<turn>). This may also be relevant to traffic signal phases, for example, there could be different traffic signals for trams and other vehicles for the same direction

I agree. This would be a cool feature. But maybe it is not that important and can be added later since there is not much benefit of knowing the Tram signal phases since nobody will route using them. Also to ways are obvious by the tracks.

to:<turn> roles with the same <turn> value should be able to occur more than once. e.g. 0, 1 or more ways could be specified with the role "to:right", where in reality different ways are permissible destinations for lane(s) marked with "right turn". Recurrence of to:<turn> need not be limited to 10.

Why should there be a turn lane without a destination? You could use multiple to:<turn> members but you could also change the turn:lanes value on the way in order to clarify. For example turn:lanes=left;slight-left;reverse|through;slight-left|through;slight-right|right. The to-ways are still unique. This way a to-way is referenced in the same way humans would do. Since two different to_ways would not both be describes as left but one as slight left and the other as left or sharp left. I don't know an example where more than 10 possible destinations could occur. The only drawback i see is that the turn:lanes specification does not fit 100% with the arrows painted on the lanes.

I am not sure of exactly what "crossing" refers to. In the intersection of 2 dual carriage ways there can be 8 crossings, with only 4 incoming ways.

The tag crossing is only applies to phases. There is not supposed to be a to:crossing Member. It seemed a good place to specify the phase. I did not see much need for this to be too accurate but wanted to have the option to specify. You are right at the outgoing edge it is not possible to specify crossing in a satisfying way.

I think the criteria of whether ":forward" ":backward" is necessary should not be relevant to whether the way ends at a particular node, but instead whether the incoming way is oneway (for all lanes). Anyway, I think a better scheme would be to specify the incoming way using "from" way and "via" node (where the from way terminates at the via node in the incoming direction), as with turn restrictions. This would require breaking up the way but at this level of micro mapping this is probably already done. This would make it immune from edits which reverse the way concerned (besides being more familiar to most mappers).

If the way ends at the node it is simply obvious which direction is meant. Otherwise clarification is only needed with bi-directional ways. I dont see that the way has to be splittet. If the from-way and a node is specified and the direction is given. It is obvious that the intersection starts behind the node. --Lukas.schaus (talk) 11:18, 12 February 2015 (UTC)

There could be a second type of relations introduced in the future which does the same but without traffic signals.

I think this is not very desirable, which is why perhaps a new type of relation with traffic signal as optional feature would be better.

Why should there be a turn lane without a destination? You could use multiple to:<turn> members but you could also change the turn:lanes value on the way in order to clarify. For example turn:lanes=left;slight-left;reverse|through;slight-left|through;slight-right|right. The to-ways are still unique. This way a to-way is referenced in the same way humans would do. Since two different to_ways would not both be describes as left but one as slight left and the other as left or sharp left. I don't know an example where more than 10 possible destinations could occur. The only drawback i see is that the turn:lanes specification does not fit 100% with the arrows painted on the lanes.

Yes in theory the turn:lanes could be changed artifically to make each destination unique but then this does not correspond to reality on the road, and user of navigation software would be confused (and also imagine the mess if say slight-right;right;U-turn is rendered). I agree that more than 10 possible destinations are unlikely at a junction, but without one-to-one correspondence between destination ways and turn values, 10 is just an arbitrary limit.

If the way ends at the node it is simply obvious which direction is meant.

A counterexample - in the following, 'A' is a single osm way looping onto itself, oneway=no, and the arrows indicate the direction of the osm way. '*' denotes the traffic signal.

                |
                C
                |
 ------ A ----->*---B--
 ^              |
 |              A
 A              |
 |              v
 <------A--------

(In this case A needs to be split to avoid ambiguity for turn restrictions.)

Anyway tagging with a dependency of whether a way ends at a node is also fragile to operations such as splitting and joining ways. Also :forward or :backward is easily broken when the way is reversed. All these require specific additional checks and splitting / reversing rules to be implemented in editors. On the other hand, using a "from" "via" scheme consistent with turn restrictions has the advantage of familiarity to (at least advanced) mappers. This does not depend on the direction of the way, and the logic to split / join ways has already been implemented in editors (for turn restrictions) and most get it right. (This is not a trivial thing, Potlatch still has bugs on this which are not yet fixed). In other words, the relation would enjoy more support and less likely be broken. This is more a practicality and consistency issue rather than a strictly technical one.

-Hlaw (talk) 14:02, 12 February 2015 (UTC)

I'm not sure (re-)adding lane connectivity to the proposal is a good way to go. Earlier discussions when this feature was already a part here indicate, that the result would be to complex to be ever tagged in a meaningfull manner. Not adding that complexity results in the following conclusions to your questions:

the mapping would be useful even in the absence of traffic signals

I don't think this would add much value over the already tagged lane information on the way itself.

it would be useful to include the tags "applies_to" and "preferred" as in the lane connectivity proposal above

I agree that "applies_to" is nice, "preferred" would be rather useless in a traffic light scenario.

I am not sure of exactly what "crossing" refers to.

I think crossing here just refers to the traffic lights for pedestrians at this specific traffic light. One would have to think a bit further here though, as there would still be crossings with traffic light phases where no separate traffic light for road traffic is specified (outgoing one ways).

If the way ends at the node it is simply obvious which direction is meant. -> A counterexample

A tagging like the one in the example seems only likely for very small ways with no traffic light involving and only one lane in each direction. More complex scenarios are likely to have dedicated turn lanes which would need to be modelled either way and would cause a split of the way before the intersection. Apart from that I kind of like the requirement to end the way at the traffic light node (wether it's called "via" or "signal" doesn't really matter, does it?).

--Gsnerf (talk) 15:24, 12 February 2015 (UTC)

I'm not sure (re-)adding lane connectivity to the proposal is a good way to go.

I did not mean reverting to the previous version, just saying that the specification of to:<turn> members per incoming way, in the current version of the proposal, is already useful, and is so beyond the context of traffic signals. In this context,

I don't think this would add much value over the already tagged lane information on the way itself.

Turn lane values tagged on the incoming way (right, left, slight-left etc) are ambiguous as there could be no strict definitions on the angles involved. In a complex intersection (e.g. intersection of dual carriage ways with slip roads) the outgoing way and thus direction of the destination is also not immediately obvious (to the software). Currently, there is a need to rely on a number of heuristics to guess the mapping from road geometries, such as counting lanes, skipping short ways between dual-carriageways, inferring from turn angles, etc to give a sane result. Using to:<turn> to specify the destination way would be more precise and accurate, especially in complex intersections (where accurate lane advice may be most needed).

Take the words from the developer of OsmAnd (at the bottom) for it. (Osmand seems to be the first open source application to support turn lanes in OSM.) It is the (unintended?) usefulness / importance of this feature for navigation software that I think more discussion would be beneficial to avoid going wrong or missing something.

"preferred" would be rather useless in a traffic light scenario.

I was thinking of this as a more generic scheme to specify the turn lane mapping whether there is a traffic light or not.

Apart from that I kind of like the requirement to end the way at the traffic light node (whether it's called "via" or "signal" doesn't really matter, does it?).

An implementation would have to cater for edge cases as above. With the requirement to split, another benefit of not requiring the signal node = the node where the way ends is that you need not split the road at the traffic light node. It is enough to just split it at the intersection (via) node.

-Hlaw (talk) 04:23, 13 February 2015 (UTC)

Pedestrian crossings

How would pedestrian crossings (highway=crossing + crossing=traffic_signals) be handled in the context of your proposal? This is relevant both in the context of junctions (where they are usually at a node some distance away from the junction nodes) and stand-alone crossings. Should they be members of the relation? And, in the junction case, should they be before or after the traffic sign node? --Tordanik 12:13, 11 February 2015 (UTC)

Pedestrian Crossing should not be a part of the relation since there is no benefit for routing or simulation tasks, what is the main purpose of the relation. The optional tag phases:crossing can be used to specify the duration of the signal but there should be no to:crossing member in the current version of the proposal. The proposal does not effect highway=crossing + crossing=traffic_signals)--Lukas.schaus (talk) 11:23, 12 February 2015 (UTC)

Scope of this Proposal

There are quite some questions and remarks on the voting panel which I would consider out of the scope of this proposal. I have the impression that quite a few people interpret this proposal as replacement for current intersection and traffic light mapping regulations where I'd think this is a simple (optional) extension to existing ones. Would the down-voters please elaborate how they think this could/should affect other aspects of intersection tagging that are already accepted? --Gsnerf (talk) 15:41, 12 February 2015 (UTC)

Not necessarily adverse impact on other accepted tagging schemes, but exactly as this might be the first relation concerning turn lanes at intersections to be approved, that this might deserve more discussions. As a comparison the present turn lane tagging gone through some serious deliberations on alternatives. -Hlaw (talk) 04:23, 13 February 2015 (UTC)

Discussion before major update at February 2nd 2015

How is this proposal related to this (Tagging_for_complex_junctions) and this proposal (highway-junction)? I would split this proposal into two smaller proposals (traffic signals and lanes) to make it more likely that they pass acceptance? --Karussell (talk) 21:59, 19 January 2015 (UTC)

I do not understand the timing and phase tag. Why g|y|r|r? Why not assume g|y|r for every timing entry. IMO this is too fine-grained tagging maybe only red and green timings are necessary? --Karussell (talk) 21:59, 19 January 2015 (UTC)

>Why not assume g|y|r for every timing entry

It is possible that there is an intersection where one traffic signal is switching g|y|r|g|y|r before the pattern for all traffic signals repeats. (This is also related to the question why the total number of seconds in each relation should be the same)--Lukas.schaus (talk) 09:04, 19 January 2015 (UTC)

>Why g|y|r|r?

-It is easier to tag the whole intersection if you make a new field every time one traffic signal changes. Therefor it is possible to have multiple times the same state in a row. If the tagging is done in such a way the timing tag should be the same for all relations.--Lukas.schaus (talk) 09:04, 19 January 2015 (UTC)

>IMO this is too fine-grained tagging maybe only red and green timings are necessary? -It is not necessary and is not obligatory to use the yellow. But it models the world in a more specific way and is imo a valid optional feature.--Lukas.schaus (talk) 09:04, 19 January 2015 (UTC)

> The total number of seconds specified in phases should be the same for all relations at the intersection?

Why that restriction?

-If it is not done in that way the traffic lights are not in sync and will produce logical failures. In simulation that would result in a crash.--Lukas.schaus (talk) 09:04, 19 January 2015 (UTC)

> turn_restriction turn restrictions shall be overruled by traffic_signals relations.

What features of turn restrictions are effected and overwritten?

-If a turn restriction prohibits right turns and there is a traffic signal relation for this case, there is a conflict. Navigation and Simulation Applications shall be aware of this conflict. You are right that there is not much effect in terms of modelling but application builders have to consider which of the conflicting data they are using. I would suggest that the traffic signal relation shall overrule the turn restriction since lights are more powerful then signs.--Lukas.schaus (talk) 09:04, 19 January 2015 (UTC)

This tagging scheme is the total opposite of KISS

I doubt if this tagging scheme would get large acceptance among the mappers. Although I read it twice, I, a senior mapper and tag inventor in public transport and railway tagging, do not understand it. You do not need relations to map the duration of green periods of traffic lights. As suggested at German OSM forum, I would solve it this way:

• Use traffic_signals:direction=forward/backward to define which direction of traffic the traffic signals apply. This tag is not necessary if oneway=yes.

• Use traffic_signals:green:left=*, traffic_signals:green:slight_left=*, traffic_signals:green:through=*, … to map the duration of green periods if you are on a lane associated with the left/slight_left/through turn via turn:lanes=*. I do not know if it is better to use percentages (20 % if the traffic lights are 20 % green per period), fractions (40/120 if it is 40 seconds green per 120 second red period) or something like r30ry1g10y2 (30 seconds red followed by 1 second red+yellow followed by 10 seconds green followed by 2 seconds yellow).

I advise against using tags like traffic_signals:green=20|50|50|70 + turn:lanes=left|through|through|right because this easily breaks by changing lane layout. Referencing via turn direction is more robust.

If you want to map the green duration at different times or days (e.g. the left direction has longer green periods between 6.00 and 9.00 a.m.), you can use traffic_signals:green:left:conditional=*. --Nakaner (talk) 18:08, 17 January 2015 (UTC)

How do you want to simulate traffic switching without timing information?

Is there many traffic simulation experts at german forum? I will happily listen to their opinions here and how they can use information about traffic simulation without timing information. Xxzme (talk) 20:21, 18 January 2015 (UTC)

I am not against mapping red and green durations of traffic lights. My main point of critism is the complexity Lukas proposes. It has also been mentioned by Tom Pfeifer at Tagging list. The main contra-argument mentioned at German forum is that traffic lights often have no timed programm. The show green if their is car which waits there. They are traffic-dependent. That's why you cannot map times there. A lot of traffic lights also have a couple of different programms they use during a day. It will be hard to map all these. --Nakaner (talk) 23:36, 18 January 2015 (UTC)

What is it that you don't understand in the proposal. Maybe I can clarify. Please let me know what KISS means.

I am aware of the problem of dynamic timings. Nevertheless it is important to have a rough idea how these traffic signals are timed. Your suggestion to tag the timings with fractions like traffic_signals:green = 40/120 seems like a good compromise between complexity and loss of information. To increase the information the use of conditional fraction timings also seems to be a reasonable optional tool.

To know the exact via ways is a crucial feature for routing and simulation tasks. Relations seem to be a good way to model them. Also it seems to be more easy to tag on all relations which include certain nodes than to tag the information in the single nodes. Why do you think that it is better not to use relations? --Lukas.schaus (talk) 09:48, 19 January 2015 (UTC)

KISS means "Keep it short and simple". KISS principle is used at a lot of places in OSM. For example, we only have three API objects, simple data scheme etc. (you will find very large PDF documentation if you compare it to surveying authorities).

But back to the topic. A router which supports green durations usually supports turn:lanes, too. The router knows which lanes the user has to use in order to turn into a specified direction at a large crossing. Because he knows which lane to use, he knows the "OSM description" (left/sligh_left/through/…) of this lanes and can find the duration by querying traffic_signals:green:lanes=*. --Nakaner (talk) 11:29, 19 January 2015 (UTC)

Here are two examples where I think that a specification without via-ways and more importantly without the to-way is not distinct. A router would know which lanes to use for a right turn but maybe it wouldn't know that the turn that it wants to perform is really the right turn. It could also be the through or the slight_left in complex intersections.

Also the scheme you proposed is breaking if the traffic_signal node is not on a single way but is part of two. Like in this example where the traffic signal is tagged on the crossing:

With this proposal it is possible to model more acurate and both scenarios are handled: The one where the node is on the way(before the intersection), and the one where the node is at the intersection. I will try to update the specified lanes in my proposal since your suggestion to use the left, rigth, slight_left ... tags is indeed more robust and understandable.--Lukas.schaus (talk) 14:44, 27 January 2015 (UTC)

rendering traffic_signals_area question

There was a previous proposal for Tagging_for_complex_junctions_or_traffic_signals_that_are_named - which would have put an area that encompassed the nodes used for the signal (car and ped alike) for the purpose of naming the whole intersection and having a single signal icon rendered, mostly for Japan, as named signals are the major navigational aid, as there are no "street addresses" in japan, so most directions are relative to landmarks, and signals are used extensively by people for navigation, as well as presented in navigational systems - with the signal icon.

As I understand it, these relation links are meant for navigation software, and the name of the signal is a *required* part of signal routing in Japan, so if we are going to link all the possible connections through an intersection, then the problem with rendering multiple icons and multiple names for the single named object (the "signal") could also be solved with this as well - as the individual relations will not be rendered - but be read and understood by the navi software.

Is it possible, if this major work has been done to map the intersection, that some kind of name be given to the intersection where the name and a single, area centered icon can be rendered by -carto?

Javbw (talk) 21:55, 17 January 2015 (UTC)

I guess that there could be a name tag in the relation. This would make it easy to group all the nodes that are in relations with the given name. An area could be circled around the nodes and the name could be rendered at the intersection. --Lukas.schaus (talk) 09:54, 19 January 2015 (UTC)

Overall proposal is good but single timing tag is not enough. Single relation is not enough.

You have red, yellow, green signals. Multiple timing tags in single relation is not enough. All of them have duration in seconds. In some countries/territories there more signals (blinking, arrows, "double red").

Please consult this page as starting page.

You need:

1. duration per each signal (red/yellow/green) and direction (from-via-to)
2. (read 1), you also need multiple relations to switch between tham.
3. After 1 and 2 are specified in OSM db you can think about how to export them to real traffic simulation software. Xxzme (talk) 20:17, 18 January 2015 (UTC)