[Tagging] Micro mapping traffic signals

Paul Johnson baloo at ursamundi.org
Tue Aug 27 14:42:14 UTC 2013


Seems like this would be better done as a relation.  Also, still seems this
has yet to be resolved for anything other than a 4-way stop, and to a
lesser extent (due to the nature of being usually placed on ramps, or in
neighborhoods as an all-way control) give_way (though still unresolved for
two-way yields).


On Tue, Aug 27, 2013 at 9:02 AM, Pieren <pieren3 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20130827/d6f5ebf3/attachment-0001.html>


More information about the Tagging mailing list