[Tagging] Micro mapping traffic signals

fly lowflight66 at googlemail.com
Tue Aug 27 14:31:11 UTC 2013

Thanks for this report, Pieren.

This should go into a proposal first.
Forward/Backward do not work on nodes !
You need a relation or use ways.

Stop using forward/backward on nodes but use an relation similar to
turn-restrictions for traffic_signals and enforcement.


On 27.08.2013 16:02, Pieren wrote:
> Hi all,
> If you did not notice, the OSM routing fans [1] are just pushing the
> sub-tag "traffic_signals:direction" in the wiki:
> http://wiki.openstreetmap.org/wiki/Traffic_signals
> http://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> This is trying to fix one old issue in OSM. The tag
> "highway=traffic_signals" has been created to say "this intersection
> is controlled by traffic lights" and was placed on the intersection
> node itself. It wasn't intended to tag each individual spotlight.
> But since we have hi-res images, some contributors started the
> micro-mapping of each individual traffic light and used the original
> tag to see them on mapnik.
> It looks nice on high mapnik zooms but this creates some issues for
> data consumers because the same tag and the same feature can have
> different amount of elements e.g, routine engine where routes with
> traffic signals are penalized. And on complex intersections, we cannot
> rely only on complex topological analysis. Note that we have a similar
> issue with the "stop" sign, for instance.
> The current solution with an additional tag
> "traffic_signals:direction", pushed without a public discussion, is
> solving most of the routing issues. But it is not sure to help other
> applications where it is hard to determin which spotlight controls
> which intersection and how it is synchronised , e.g. the rendering
> issue where one, two, four or eight icons could be drawn depending on
> the zoom level, icon size and distance between nodes; e.g. complex
> intersections where more than one traffic light can be synchronized
> (and should be counted only once for penalties); etc.
> At low zoom levels, it's interresting to see only one symbol for the
> whole intersection. At high zoom levels, each individual traffic light
> can be painted. The current tagging solution does not help in this
> regard. It's just working more or less by accident on mapnik when
> icons are overlapping (if not, the rendering will fail).
> My proposal:
> - when micro-mapping the traffic lights, use a different tag than
> "highway=traffic_signals" which should be reserved for the "simple,
> old" fashion way of mapping the intersection itself.
> - create a new tag for the micro-mapping of each individual traffic
> signal e.g.: "highway=traffic_light" (any other suggestion is welcome)
> - create a new relation type e.g. "type=traffic_lights" (or reuse the
> proposal "type=junction" [2]) with a role for each "traffic_light"
> node and one role on the "intersection" node(s)
> - advantages : for routers, they just collect the relations where the
> intersection node is member to calculate penalties. For renderers,
> either they draw an icon for each individual traffic light at high
> zoom levels or a centroid of the junction nodes member of the relation
> at lower zoom levels. In principle, the old fashion is compatible with
> the new one but once the relation is widely supported, the old
> "highway=traffic_signals" could be removed where the relation is
> present. Common traffic signals attributs like the "button_operated"
> could be generalized into the relation.
> - disadvantage : contributors going to micro-map the traffic signals
> will have to use relations. But I don't see this as a big issue since
> micromappers should be considered as advanced users. If they cannot
> handle relations, they can fall back on the previous simple old manner
> with a tag on the intersection node. It's also a good opportunity to
> learn relations which can be used later for many other things (e.g.
> turn restrictions ;-)
> Your comments ?
> Pieren
> [1] https://github.com/DennisOSRM/Project-OSRM/issues/31
> [2] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Junctions
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

More information about the Tagging mailing list