[Tagging] direction=forward/backward on nodes ?

[fly]

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