<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>On 2017-05-21 13:36, Martin Koppenhoefer wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div dir="ltr">
<div class="gmail_extra"><br />
<div class="gmail_quote">2017-05-21 13:15 GMT+02:00 Colin Smale <span><<a href="mailto:colin.smale@xs4all.nl">colin.smale@xs4all.nl</a>></span>:<br />
<div>this can depend on legislation. Usually the end of the restriction should be signed (or the restriction will already have indications when it will end/to where it applies, e.g. a sharp bend), some jurisdictions also require that it will be repeated at every crossing, or it will end automatically.</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>Which is exactly why we need a way of making this explicit, because we are not able to discuss having documented "territorial defaults" without the discussion getting nasty. OSM has to work for everyone. Using words like "usually" serves to emphasise the need for a model that also caters for the "unusual." Other countries may do things very differently to what you are used to.</div>
<div> </div>
</div>
</div>
</div>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">
<div>European traffic law is full of cases where a sign applies until the next junction, but what counts as the "next junction" may not be unambiguously obvious from the OSM data. And a give-way sign must be unambiguously linked to the junction and road segment to which it applies.</div>
</blockquote>
<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left: 1px solid #cccccc; padding-left: 1ex;">
<div class="gmail_extra">I am convinced that geometry alone is not able to resolve this in all cases, so an explicit model is also required.</div>
</blockquote>
<div><br /><br /></div>
<div>feel free to come up with something, just because something can not resolve all cases does not mean that all cases have to be made complicated. I have so far never encountered a situation where I would have needed a relation to say what I think to where a sign applies (surely these will exist, but not in "masses", at least not around here). Many signs are also very redundant (IMHO) for mapping purposes, e.g. the turn restriction signs before entering into a oneway street are complemented by the oneway signs and the no-entry signs in the opposite direction. A lot of signs (and work) for what can usually be mapped unambigously with a simple oneway=yes tag in OSM.<br /><br /></div>
</div>
</div>
</div>
</blockquote>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>First we start with a data model, using node/way/relation/polygon primitives together with tagging, possibly leveraging the "namespace model" to allow some kind of grouping and hierarchy in the tags. We ensure it is as simple as possible while remaining fit-for-purpose. If it too verbose, we document defaults to reduce the tagging required or we agree to drop certain capabilities. But of course this will require a statement of purpose, otherwise you cannot judge if the proposal is a valid solution. So, in simple language, WHY do we put traffic signs into OSM? Let's have this frame of reference on the table. Only then can we make value judgments about this or that proposal as to HOW.</div>
<div> </div>
<div> </div>
<div>//colin</div>
<div> </div>
</div>
</div>
</div>
</body></html>