[Tagging] direction=forward/backward on nodes ?

John Packer john.packer7 at gmail.com
Mon Apr 14 11:52:48 UTC 2014


>
> 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 <lowflight66 at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140414/c6ac8c75/attachment-0001.html>


More information about the Tagging mailing list