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 <pier...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
