<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
To make it less ambiguous and easier I would deprecate forward/backward
completely for nodes and advice to use cardinal coordinates for all nodes.</blockquote><div>I think that would be ok for traffic_sign:direction=*, <br>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.<br>

<br></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
IMHO we should use relations for cases like this (see turn restrictions, via nodes, for reference)</blockquote><div>+1<br> <br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-14 8:44 GMT-03:00 fly <span dir="ltr"><<a href="mailto:lowflight66@googlemail.com" target="_blank">lowflight66@googlemail.com</a>></span>:<br>

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