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