[Tagging] Feature Proposal - RFC - traffic signals set

[Lukas Sommer]

Hello.

In the discussion about the proposal about type=traffic_signals_group
it was suggested to use the term “set” instead of “group”. So I’ve
adapted the wiki page of the proposal and I’ve moved it to
http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_set

-- 
Lukas Sommer

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (traffic signals group)

[Lukas Sommer]

Okay. I’ve made some clarifications to the proposal (avoid confusion
with coordination of traffic signals along a length of road …).

The remaining problem is the tag value “type=traffic_signals_group”. I
agree that “group” is not the best choise. We could maybe switch to
“type=traffic_signals_set”. (I would avoid “intersection_set” because
the relation isn’t restricted to intersections, but could theretically
also be used for pedestrian crossings on straight road; probably there
is not so much need, but I don’t wont to exclude this use case.)

So our choise could be “type=traffic_signals_set”?

2015-02-26 6:28 GMT, Warin <61sundow...@gmail.com>:
> Looks like this has already been discussed .. in 2008 to 2011.
> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Set_of_Traffic_Signals
> No outcome for that ..
> Past discussion looks to have pointed to a relation ... the relation
> contains each node of traffic_light and can have a name= tag.
>
> I use 'set' because that is how they are called here in Australasia ..
> and it looks to be used in the UK too  ...
>
> http://www.tfgm.com/Corporate/Pages/UTC-fault-reporting-form.aspx
>
>
>
> On 26/02/2015 4:55 PM, John Willis wrote:
>> If group is not a good word, then "set" is a good alternative.
>>
>> Javbw
>>
>>
>> On Feb 26, 2015, at 8:33 AM, Warin <61sundow...@gmail.com
>> > wrote:
>>
>>> Hi,
>>>
>>> This could be confused with the coordination of traffic signals along
>>> a length of road or even a district wide coordination of traffic
>>> light signals.
>>> I think it needs some words that restrict it to a single intersection?
>>>
>>> And possibly some thought to where a length of road (many
>>> intersections) or a district wide coordination of traffic signals
>>> occurs? If the name 'traffic signals group' is taken what name would
>>> you give this? May be a different name for this 'group'? Such as ?
>>> traffic signals set?
>>>
>>>  On 26/02/2015 8:59 AM, Lukas Sommer wrote:
 Hello.

 This is a request for comments for the proposal
 http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group

 The original author is Sanderd17. With the consent of him, I did some
 supplementing. Thanks to Sanerd17!

 Unlike the proposal “Proposed features/Traffic Signals” of Lukas
 Schaus, this is _not_ about traffic light circuits, but just about
 grouping together all nodes with highway=traffic_signals that belong
 to a traffic signal system at one place. This could be useful in
 Japan, where traffic signal systems have namen. (Thanks to nyampire
 and javbw for suggestions and comments.) This could be useful for
 routing/turn-to-turn navigation engines to calculate better the time
 penalty for the traffic signal system.

 Best regards

 sommerluk

 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Lukas Sommer

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (traffic signals group)

[Warin]

Looks like this has already been discussed .. in 2008 to 2011.
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Set_of_Traffic_Signals
No outcome for that ..
Past discussion looks to have pointed to a relation ... the relation 
contains each node of traffic_light and can have a name= tag.


I use 'set' because that is how they are called here in Australasia .. 
and it looks to be used in the UK too  ...


http://www.tfgm.com/Corporate/Pages/UTC-fault-reporting-form.aspx



On 26/02/2015 4:55 PM, John Willis wrote:

If group is not a good word, then "set" is a good alternative.

Javbw


On Feb 26, 2015, at 8:33 AM, Warin <61sundow...@gmail.com 
> wrote:



Hi,

This could be confused with the coordination of traffic signals along 
a length of road or even a district wide coordination of traffic 
light signals.

I think it needs some words that restrict it to a single intersection?

And possibly some thought to where a length of road (many 
intersections) or a district wide coordination of traffic signals 
occurs? If the name 'traffic signals group' is taken what name would 
you give this? May be a different name for this 'group'? Such as ? 
traffic signals set?


 On 26/02/2015 8:59 AM, Lukas Sommer wrote:

Hello.

This is a request for comments for the proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group

The original author is Sanderd17. With the consent of him, I did some
supplementing. Thanks to Sanerd17!

Unlike the proposal “Proposed features/Traffic Signals” of Lukas
Schaus, this is _not_ about traffic light circuits, but just about
grouping together all nodes with highway=traffic_signals that belong
to a traffic signal system at one place. This could be useful in
Japan, where traffic signal systems have namen. (Thanks to nyampire
and javbw for suggestions and comments.) This could be useful for
routing/turn-to-turn navigation engines to calculate better the time
penalty for the traffic signal system.

Best regards

sommerluk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (traffic signals group)

[Bryce Nesbitt]

On Wed, Feb 25, 2015 at 9:55 PM, John Willis  wrote:

> If group is not a good word, then "set" is a good alternative.
>

intersection_group=
intersection_set=
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (traffic signals group)

[John Willis]

If group is not a good word, then "set" is a good alternative.

Javbw


> On Feb 26, 2015, at 8:33 AM, Warin <61sundow...@gmail.com> wrote:
> 
> Hi,
> 
> This could be confused with the coordination of traffic signals along a 
> length of road or even a district wide coordination of traffic light signals. 
> I think it needs some words that restrict it to a single intersection? 
> 
> And possibly some thought to where a length of road (many intersections) or a 
> district wide coordination of traffic signals occurs? If the name 'traffic 
> signals group' is taken what name would you give this? May be a different 
> name for this 'group'? Such as ? traffic signals set? 
> 
>>  On 26/02/2015 8:59 AM, Lukas Sommer wrote:
>> Hello.
>> 
>> This is a request for comments for the proposal
>> http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group
>> 
>> The original author is Sanderd17. With the consent of him, I did some
>> supplementing. Thanks to Sanerd17!
>> 
>> Unlike the proposal “Proposed features/Traffic Signals” of Lukas
>> Schaus, this is _not_ about traffic light circuits, but just about
>> grouping together all nodes with highway=traffic_signals that belong
>> to a traffic signal system at one place. This could be useful in
>> Japan, where traffic signal systems have namen. (Thanks to nyampire
>> and javbw for suggestions and comments.) This could be useful for
>> routing/turn-to-turn navigation engines to calculate better the time
>> penalty for the traffic signal system.
>> 
>> Best regards
>> 
>> sommerluk
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (traffic signals group)

[Warin]

Hi,

This could be confused with the coordination of traffic signals along a 
length of road or even a district wide coordination of traffic light 
signals.

I think it needs some words that restrict it to a single intersection?

And possibly some thought to where a length of road (many intersections) 
or a district wide coordination of traffic signals occurs? If the name 
'traffic signals group' is taken what name would you give this? May be a 
different name for this 'group'? Such as ? traffic signals set?


 On 26/02/2015 8:59 AM, Lukas Sommer wrote:

Hello.

This is a request for comments for the proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group

The original author is Sanderd17. With the consent of him, I did some
supplementing. Thanks to Sanerd17!

Unlike the proposal “Proposed features/Traffic Signals” of Lukas
Schaus, this is _not_ about traffic light circuits, but just about
grouping together all nodes with highway=traffic_signals that belong
to a traffic signal system at one place. This could be useful in
Japan, where traffic signal systems have namen. (Thanks to nyampire
and javbw for suggestions and comments.) This could be useful for
routing/turn-to-turn navigation engines to calculate better the time
penalty for the traffic signal system.

Best regards

sommerluk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (traffic signals group)

[Lukas Sommer]

Hello.

This is a request for comments for the proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals_group

The original author is Sanderd17. With the consent of him, I did some
supplementing. Thanks to Sanerd17!

Unlike the proposal “Proposed features/Traffic Signals” of Lukas
Schaus, this is _not_ about traffic light circuits, but just about
grouping together all nodes with highway=traffic_signals that belong
to a traffic signal system at one place. This could be useful in
Japan, where traffic signal systems have namen. (Thanks to nyampire
and javbw for suggestions and comments.) This could be useful for
routing/turn-to-turn navigation engines to calculate better the time
penalty for the traffic signal system.

Best regards

sommerluk

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[Lukas Schaus]

The practical use is that routing algorithms can calculate the travel time more 
accurate if the durations are known. By specifying the via ways a routing 
algorithm knows which signals can be ignored. Simulations can be done more 
precisely. 

To reply to the other comments:
 I am aware of the problem of dynamic timings. Nevertheless it is important to 
have a rough idea how these traffic signals are timed. The suggestions of 
Nakaner to tag the timings with fractions like green=40/120, indicating that 
the signal is 40 of 120 seconds green seems like a good compromise between 
complexity and loss of information. To increase the information a use of 
conditional fraction timings for different times at a day also seems to be a 
reasonable optional tool. I think the connection between more intersection is 
to complex to model and can be guessed of the simulation and routing 
applications. 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?

I’d like you to use the discussion page for a better readability

http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Traffic_Signals 



> I'm going to have to agree with this.  What's the practical purpose of this
> schema?  I the only thing I can come up with would be to recreate the
> system for a driving game of some realistic fashion, however, that seems to
> be more of something the game designer would need to implement on their own
> rather than expecting some overly baroque tagging model in a third-party
> database (ie, OSM) to sort out for them.  The GPS navigation model doesn't
> really bring up a solid case for this, either (with the exception of turn
> lanes that prohibit turn on red and have their own signals, in which
> there's bound to be a simpler way to indicate the presence of left or right
> turn signals and whether or not they allow turn on red to give navigation
> systems finer grain control over cost assignment, ie, in the pacific
> northwest US model, a right turn would have the same penalty as a two-way
> stop, as would a left turn to a one-way street (since you can make a left
> on red arrow if it's to a one-way street in that part of the world, even
> from a two way), but all other left turns involving a left turn signal
> would "cost" more).
> 
> I guess we're going to need a better idea of what this is trying to solve
> beyond just mapping for the sake of detail overkill (which I have nothing
> against, but let's not make things overly complex just for the sake of
> this).

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[Paul Johnson]

On Sun, Jan 18, 2015 at 7:14 AM, Tom Pfeifer  wrote:

> Sorry but I'm sceptical about the scheme. It adds very little value
> compared
> to its own complexity. In particular the timing of the lights is highly
> volatile
> in modern cities, and it seems impossible to collect the ground truth as a
> mapper just by observing them.


I'm going to have to agree with this.  What's the practical purpose of this
schema?  I the only thing I can come up with would be to recreate the
system for a driving game of some realistic fashion, however, that seems to
be more of something the game designer would need to implement on their own
rather than expecting some overly baroque tagging model in a third-party
database (ie, OSM) to sort out for them.  The GPS navigation model doesn't
really bring up a solid case for this, either (with the exception of turn
lanes that prohibit turn on red and have their own signals, in which
there's bound to be a simpler way to indicate the presence of left or right
turn signals and whether or not they allow turn on red to give navigation
systems finer grain control over cost assignment, ie, in the pacific
northwest US model, a right turn would have the same penalty as a two-way
stop, as would a left turn to a one-way street (since you can make a left
on red arrow if it's to a one-way street in that part of the world, even
from a two way), but all other left turns involving a left turn signal
would "cost" more).

I guess we're going to need a better idea of what this is trying to solve
beyond just mapping for the sake of detail overkill (which I have nothing
against, but let's not make things overly complex just for the sake of
this).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[Michael Reichert]

Hi,

Am 2015-01-18 um 19:02 schrieb fly:
> Additional to below I want to mention that on a micromapping style a
> traffic_signal is placed one the pedistrian crossing or the stop_line. I
> even came across ones one the stop_line and an addition highway=crossing
> on the pedestrian crossing.
> 
> I am tagging direction=* for the direcion it faces.
> 
> Together with the :lanes tagging you do not need any relation at all but
> could simply add the information on the node with :lanes tagging

I agree you. I have described a way to map it without relations using
lane tagging which should exist if you want to have useful traffic
simulations.

https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Traffic_Signals#This_tagging_scheme_is_the_total_opposite_of_KISS

I mentioned this proposal at German OSM forum.
http://forum.openstreetmap.org/viewtopic.php?id=29712

Main comments there:
A large number of traffic lights/crossings have no programm. The show
green to the branch streets if a waits there. Otherwise they show red to
the branch streets and green to the main street. There are also traffic
lights in cities which
- show green for a couple of minutes if fire brigades approach to
  "clean the way".
- can have extra-extra programms if a special event changes traffic flow
- have multiple programms (one on the morning rush hour, one for the
  low-traffic periode between 9 and 12 a.m., one afternoon programm,
  one evening rush hour programm, one late-evening programm and a
  Sunday programm)

Best regards

Michael


-- 
I prefer GPG-encrypted emails.



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[fly]

Additional to below I want to mention that on a micromapping style a
traffic_signal is placed one the pedistrian crossing or the stop_line. I
even came across ones one the stop_line and an addition highway=crossing
on the pedestrian crossing.

I am tagging direction=* for the direcion it faces.

Together with the :lanes tagging you do not need any relation at all but
could simply add the information on the node with :lanes tagging

cu fly

Am 18.01.2015 um 14:14 schrieb Tom Pfeifer:
> Sorry but I'm sceptical about the scheme. It adds very little value
> compared
> to its own complexity. In particular the timing of the lights is highly
> volatile
> in modern cities, and it seems impossible to collect the ground truth as a
> mapper just by observing them.
> 
> Take the 2050 traffic lights in Berlin for example [1], which are
> controlled in 3 tiers.
> Each junction works autonomously with predefined programmes for
> different times
> of the day and days of the week, even if disconnected. In the next tier,
> junctions are regionally clustered, so they can sync for better traffic
> flow.
> In the third tier, they are connected with two fibre rings to the traffic
> management centre in the former airport Tempelhof buildings, where their
> cycles can
> be completely changed and adapted: to the current traffic flow or
> accidents,
> in response to mass events, and e.g. to switch a 'green corridor' for a
> state visitor.
> 
> Thus as a mapper with a stop watch, you never know which of these
> programmes
> you are currently observing.
> 
> Tom

+1

> [1] Ref: VMZ Berlin, 2013
> 
> Lukas Schaus wrote on 2015-01-15 12:15:
>> Hello Everybody,
>>
>> please take some time to read my proposal concerning more detailed
>> modelling of traffic signals and tell me your thoughts.
>>
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals
>>
>> I will keep track of the discussion page and the Comments section of
>> the proposal.
>>
>> Greetings
>>
>> Lukas Schaus
>>
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

[Tom Pfeifer]

Sorry but I'm sceptical about the scheme. It adds very little value compared
to its own complexity. In particular the timing of the lights is highly volatile
in modern cities, and it seems impossible to collect the ground truth as a
mapper just by observing them.

Take the 2050 traffic lights in Berlin for example [1], which are controlled in 
3 tiers.
Each junction works autonomously with predefined programmes for different times
of the day and days of the week, even if disconnected. In the next tier,
junctions are regionally clustered, so they can sync for better traffic flow.
In the third tier, they are connected with two fibre rings to the traffic
management centre in the former airport Tempelhof buildings, where their cycles 
can
be completely changed and adapted: to the current traffic flow or accidents,
in response to mass events, and e.g. to switch a 'green corridor' for a state 
visitor.

Thus as a mapper with a stop watch, you never know which of these programmes
you are currently observing.

Tom

[1] Ref: VMZ Berlin, 2013

Lukas Schaus wrote on 2015-01-15 12:15:

Hello Everybody,

please take some time to read my proposal concerning more detailed modelling of 
traffic signals and tell me your thoughts.

http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals

I will keep track of the discussion page and the Comments section of the 
proposal.

Greetings

Lukas Schaus




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - (Traffic Signals)

[Lukas Schaus]

Hello Everybody,

please take some time to read my proposal concerning more detailed modelling of 
traffic signals and tell me your thoughts.

http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals 


I will keep track of the discussion page and the Comments section of the 
proposal. 

Greetings

Lukas Schaus___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging