<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 10, 2018 at 4:57 PM, Martin Koppenhoefer <span dir="ltr"><<a href="mailto:dieterdreist@gmail.com" target="_blank">dieterdreist@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><br><div class="gmail_extra"><br><div class="gmail_quote">2018-05-10 21:03 GMT+02:00 Ruben Kelevra <span dir="ltr"><<a href="mailto:ruben@vfn-nrw.de" target="_blank">ruben@vfn-nrw.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> which is intrinsically flawed, as it gets added to a node but nodes<br>
> don’t have a direction.<br>
</span>Yep. It's a mess and really bad to parse and check for consistency. Also<br>
pretty hard to understand. I fixed many highway=stop nodes which are<br>
actually the intersection nodes, so even the primary_road was<br>
considered to stop there... which makes no sense.<br>
<br>
What do you think about the relation-approach designed by AMDmi3:<br>
<br>
<a href="https://wiki.openstreetmap.org/wiki/Relations/Proposed/Give_way" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/Relations/Proposed/Give_<wbr>way</a></blockquote></div><br><br><br></div></span><div class="gmail_extra">generally, a relation is capable of explicitly modelling the situation, at the cost of complicated/time consuming actions required from the mapper (and nowadays, with a lot of mapping on mobile phones going on, average editor relation support is even worse). Personally, I am mapping in a context with a lot of oneway streets, so it often is not an issue to just use a node close to the intersection, I believe if you can, you should avoid relations because it makes the map more complex for others to understand and modify (maybe with the exception of well supported multipolygon relations).<br></div></div></blockquote><div><br></div><div>Any editor that is capable of correctly building a turn restriction relation would be readily capable of accurately creating give_way and stop relations by the looks of the proposal (and it largely falls in line with my previous proposal for tagging stops).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">The particular proposal seems thought through, but might eventually be overengineered. In the simplest representation you would only need a via node (at the stop line) and a from way (ending at the stop line) and be done. <br></div></div></blockquote><div><br></div><div>I can see that, particularly for stop signs at, say, campground ranger stations in state parks, security shacks at practically honor-system gates at industrial sites, and similar mid-block one-direction stop signs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"></div><div class="gmail_extra">I am not sure how several via ways should work together with several from and to ways, and I guess even if it works, it will be complicated to evaluate (for other mappers) and several very simple relations (only from way and via node) would probably be much easier to understand (at the cost of having to split the ways at the stop/via).</div></div></blockquote><div><br></div><div> Well, think of a situation where you have a R1-1 STOP and a R3-11 RIGHT TURN PERMITTED WITHOUT STOPPING sign.  Your from way would be the way those signs are facing, and the TO ways would be all the ways you would have to stop at the sign before proceeding to enter (ie, all of them except the way for the right turn).</div></div></div></div>