[Tagging] traffic lights

sergio sevillano sergiosevillano.mail at gmail.com
Tue Sep 6 19:38:06 BST 2011

El 06/09/2011, a las 01:43, Stephen Hope escribió:

> I have no problem with some people just mapping "it has traffic
> lights" and others adding more detail, if they feel a need for it.
> Most people are never going to need (or have the time/knowledge to
> enter) more than "there are lights here", but that doesn't mean we
> shouldn't have the option for more. But if the only knowledge I have
> is "there are lights here", I'd rather be able to mark that than have
> to fake up some light pole positions or leave it without.

i agree

> Having said that, I do have some questions about marking in detail
> Should we use different tags for "this whole intersections has lights"
> and "there are lights in this exact spot". My first instinct is to say
> yes, so that data users can easily search for one or the other.  You
> could say that any lights not on a way are one, and lights on a way
> are the other, but what about overhead signals that hang over the
> centre of the way/intersection?

the present tagging schema means "this crossing is regulated by traffic lights"
(highway=traffic_lights in the intersection node)

the relation proposal connects all traffic lights of an intersection meaning the same thing
"this crossing is regulated by traffic lights" and they are placed here.

what  i was talking about is placing the tags at 
the nodes of ways that are affected by a traffic lights 
in more detail
(no need for relations here)

the approach is important 
if we map the physical traffic light signs
then it will be chaos as this is solved differently by country.
in this case the nodes should be alone (not in the way)
at the side maybe...
but i would not recommend to do this approach at all.

> Is there a problem with marking an intersection both ways?

right now there is.
the relation is good to say "this crossing is regulated by traffic lights"
and therefore the router can give direction in the "turn left at next traffic light" manner
the same way as the actual low resolution schema works.

the detailed schema now uses use exactly the same tagging, 
so the solution could be:

- single node meaning "this crossing is regulated by traffic lights"
"highway=traffic_lights" at the intersection node

- relation grouping several single traffic lights meaning "this crossing is regulated by traffic lights"
"highway=traffic_lights" at the relation

- single traffic light (part of a relation, or not), when mapping in detail, could be changed to
"highway=single_traffic_light" at the waiting point node of the way
meaning "this spot of the way is regulated by traffic lights (wait here)"

> Should we mark where the pole is, or where the lights are?  Many of
> our traffic lights hang over the road, with the pole base off to one
> side.

i think none, 
we should map the node of the way affected by the traffic light (wait here).

> Another aspect that should be taken into account when inventing the
> model for actual traffic light positions:
> There is sometimes indipendent traffic lights for different directions
> on the same lane. E.g. a lane where you can turn left or go straight
> might have 2 traffic lights, where you could have states like: green
> for left turn, red for straight on.
> Cheers,
> Martin

straight or left are regulated by the same traffic_lights
you can find them open or closed alternatively
so even you have different results on different lanes
they are all regulated. one tagged node serves for all. 

i cant think of any example in which there is not traffic lights to go straight 
but there are to turn left, but maybe in that case the traffic lights node 
should be placed at the way turning left

an example of this but with stop sign:

you have to open it with an editor (eg JOSM), 
and it could be checked with sat image:


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20110906/a48395e9/attachment.html>

More information about the Tagging mailing list