[Tagging] direction=forward/backward on nodes ?

fly lowflight66 at googlemail.com
Mon Apr 14 11:44:05 UTC 2014

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

To make it less ambigious and easier I would deprecate forward/backward
completely for nodes and advice to use cardinal coordinates for all nodes.


More information about the Tagging mailing list