[Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

fly lowflight66 at googlemail.com
Thu Sep 18 19:29:37 UTC 2014


Am 18.09.2014 16:07, schrieb Lukas Sommer:
> 
> 
>     So far, highway=traffic_signal is only defined for nodes and there are
>     only few ways and fewer relations.
> 
> 
> Correct.
>  
> 
> 
>     Also in favour of separation I would prefer to use junction=* with
>     name=* and only highway=traffic_signal with name if it is only a single
>     light (e.g. the case with a named junction and different separate names
>     for the lights)
> 
>     This way we could add an additional junction=* to the nodes with named
>     traffic_signal and once all lights are tagged separately only use
>     junction=* for ways.
>     Additionally we have a better hint for the renderer what to render and
>     diversify between a named junction and single named traffic_signals.
> 
>     cu fly
> 

Sorry, was kind of confusing, try again:

1. simple solution with only one node
junction=yes/traffic_signal/*
highway=traffic_signal (if the junction has lights)
name=*

2. area
junction=yes/traffic_signal/*
name=*


Maybe also highway=junction [1] could be used.

Renderer could use junction=* to determine the needed icon and we stay
consistant with the use of traffic_signals.

This makes detailed tagging possible while adding the information for
renderers to

> Hm, I am not sure if I understand you correctly. You want to use
> junction=yes not on nodes anymore, but only on areas – and change the
> currently existing cases in OSM?

No, no problem with junction=* on nodes but in long term only needed for
rare situations and low detailed mapping

> If so, I would disagree here. We have a yet existing tagging that works
> well for both – named junctions and names traffic signals – as long as
> this are simple junctions like
> https://wiki.openstreetmap.org/wiki/File:Junction_yes_example_1.png My
> proposal keeps the existing tagging for simple junctions – and extends
> it also to complex junctions. I am not convinced in changing the current
> tagging practice for simple junctions and require changing a lot of yet
> existing data in OSM. Currently I do not know of any situation where we
> have at the same place on the ground a different junction name and a
> different traffic signal name. It seems to me a barely theoretical
> problem. Maybe that does not mean that such a situation is impossible to
> exist. However, we should create our tagging scheme starting from the
> situation on the ground, and this seems to be either junction names or
> traffic signal names, but not both things at the same time. Replace an
> existing simple practice with a new complicate practice just to solve a
> problem that does probably not exist on the ground?

Well, I just followed this thread:

>>> Am 16.09.2014 16:49, schrieb Satoshi IIDA:
>>>> 2014-09-16 23:38 GMT+09:00 fly <lowflight66 at googlemail.com>:
>>>>> The name belongs to the junction and not to the traffic_signal,
>>>>> am I wrong ?
>>>> In Japan, Hokkaido region, there is 4 traffic_signals on 1
>>>> junction.
>>>> Each traffic_signals and 1 junction has different name.
>>>>
>>>> Indeed it is rare case.
>>>> But I think we need Lukas's idea to support it.

> However, I think it is nevertheless a good idea to think about this
> case. I would propose to leave the existing tagging for simple
> intersections as it is (with tagging on a node). Moreover, for the rare
> case that we have a junction and a traffic signal with different names,
> one of them could be represented by an area around the other one (and
> same thing on complex junctions/traffic signal systems). Thus, we keep a
> door open to tag two different names, just for the case that sometime we
> really need it. Nevertheless, we do not break compatibility with the
> current practice, and we do not make things unnecessarily complicate for
> the real-world cases.

Ok, here we are common.

Hope my thoughts are better understandable this time.

Cheers fly



More information about the Tagging mailing list