> > To make it less ambiguous and easier I would deprecate forward/backward > completely for nodes and advice to use cardinal coordinates for all nodes.
I think that would be ok for traffic_sign:direction=*, but not for traffic_signals:direction=* or direction=* when used with highway=stop/give_way, because it wouldn't be as easy to know to which highway's direction the highway=traffic_signals/stop/giveway applies to. IMHO we should use relations for cases like this (see turn restrictions, > via nodes, for reference) +1 2014-04-14 8:44 GMT-03:00 fly <lowfligh...@googlemail.com>: > Am 14.04.2014 08:28, schrieb Peter Wendorff: > > Hi, > > > > Am 13.04.2014 21:35, schrieb Steve Doerr: > >> I'm surprised that so many people are jumping to this conclusion. Let's > >> remember that a way is just a series of nodes in a particular order. So > >> a node is not necessarily an isolated object. > > Agree > >> In many cases, it exists solely as part of a way. Thus the concept of > direction is not > >> meaningless for a node which is part of a way. > > Agree partly. It's not meaningless, but it get's ambiguous very often. > > Exactly, it is not meaningless but ambiguous and can easily lead to > wrong results. > > > Take traffic signals as one example where the direction might be used: > > Besides an intersection someone could add the traffic lights on the four > > individual ways (instead on the intersecting node itself). > > This matches the installation of the individual lights and the stop > > positions, but it produces wrong results without a direction tag. > > > The drawback of that is, that someone crossing the intersection straight > > meets two traffic lights, which is wrong of course. The mapper therefore > > might decide to add direction-tags to them, as each traffic light node > > is relevant and applied only for one of the two directions. > > > > Looks perfect now - all four traffic lights are mapped separately where > > they are, routing for cars works great (provided that the direction tag > > is known and supported by routers). > > > > Enter of the next mapper: He want's to add the footways and cycleways > > that cross the streets using the pedestrian traffic lights integrated in > > the traffic lights mentioned above. > > As a result the nodes previously mapped with a direction are shared by > > two ways, and it's hard to determine what the direction tag refers to, > > as of course crossing for pedestrians is possible and meaningful for > > both directions. > > Thanks for another example where cardinal coordinates work but > forward/backward fails. > > >> I haven't examined any > >> uses of the tag on a node, but I can imagine, for instance, that a node > >> in a way with a direction attribute might be used to represent a > >> road-sign that applies only to traffic on the way passing that node in a > >> particular direction. > > For other traffic signs it's the same, and that's why we usually map the > > road signs meaning on the road that is affected by it. (The sign itself > > may be mapped as such, as an obstacle and a physical object next to the > > street), while maximum speed, maximum dimensions (width, height, > > weight), oneway access, access restrictions and so on are mapped on the > > where they hold. > > > > Here the direction is useful (look at the oneway=yes tag), meaningful > > and not ambiguous; on nodes it is or get's very lightly without tagging > > mistakes. > > Ok, we can take a split between unconnected nodes on the > left-/right-hand-side of the road and nodes being part of a way. The > first are less ambigious but you still need to know the driving > directions where as the latter ones just won't work properly with > forward/backward. > > To make it less ambigious and easier I would deprecate forward/backward > completely for nodes and advice to use cardinal coordinates for all nodes. > > fly > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
