<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 23, 2017 at 7:44 AM, 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=""><div class="gmail_extra"><br><div class="gmail_quote">2017-03-23 10:30 GMT+01:00 Jean-Marc Liotier <span dir="ltr"><<a href="mailto:jm@liotier.org" target="_blank">jm@liotier.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_3844640131153191003gmail-:1zz" class="m_3844640131153191003gmail-a3s m_3844640131153191003gmail-aXjCH m_3844640131153191003gmail-m15afa81a73457692">As the "complex intersections" section of the highway=traffic_signals<br>
page describes a gradation of model complexity<br>
(<a href="https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Complex_intersections" rel="noreferrer" target="_blank">https://wiki.openstreetmap.or<wbr>g/wiki/Tag:highway%3Dtraffic_<wbr>signals#Complex_intersections</a>)<wbr>,<br>
maybe coexistence is also possible between simple tagging of a<br>
highway=stop+direction=forward node on the way to an intersection and a<br>
complex relation-based model for more complex cases: having a simple<br>
model that covers most cases has such significant benefit that I would<br>
say it more than offsets the cost of having more than one way to do it.</div></blockquote></div><br><br></div></span><div class="gmail_extra">If we choose to trade off  stability / disambiguity / reliability for a little less complexity (no relation), the better solution is positioning the node for the sign not on the highway but in the driving direction close to it to the side (could be sold as "actual sign position" save some exceptions). This way you have the direction implicitly stored and don't depend on other ways, but there is the risk of someone dragging the node with the sign or the highway so far away that another (unrelated) highway comes closer.<br></div></div></blockquote><div><br></div><div>This assumption would generally mean that on tight-radius corners common in rural American towns, the implied face of the stop would be towards the major road on the downstream side of the intersection, when in reality it's facing the upstream side of the minor intersection, thanks to the stop sign being closer to the side of the major road than the minor road.</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"></div><div class="gmail_extra">Both variants require postprocessing anyway (either you have to look for a closeby highway or for the direction of the way(s) your node is part of).<br><br></div><div class="gmail_extra">Yet another option would be to use tiny way stubs for the signs, these would have a direction (and could even imply a default sign direction if defined like that).<br></div></div></blockquote></div><br></div><div class="gmail_extra">Not to sound like a broken record, but what exactly would be so complicated about adapting the existing and adopted enforcement style relations to stop and give way devices?  This completely removes ambiguity and guesswork and can already be done using existing tools.  Plus, like turn relations, further developments on the editor end would make this even more trivial.</div></div>