<div dir="ltr">You didn't read my complete mail then. I wrote that it would be better to use something like access:destination:traffic_sign=...<div>because I realised that traffic_sign on a road would be a bad idea.</div><div><br></div><div>Did you read <span style="color:rgb(80,0,80);font-size:12.8px">Lauri Kytömaa's long mail ? There was an even better proposal with extra tags that could also be used to explain the access rules in case of private or other ad-hoc signs.</span></div><div><span style="color:rgb(80,0,80);font-size:12.8px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:12.8px">If you introduce a new value for access that will only be used in 1 or 2 countries[1],  it's unlikely that it will be adapted soon in global routers and renderers. Since it is almost the same as destination, the benefit of destination + extra key-values is that it will work for most uses.</span></div><div><font color="#500050"><span style="font-size:12.8px">A new value, unknown to the router/renderer, can be interpreted by default as yes, no, etc, which doesn't have to be the best fit.</span></font></div><div><font color="#500050"><span style="font-size:12.8px">And as long as the router doesn't ask the user the reason for the visit, it should substitute a value for your new value (no, yes, private, destination,... ?). Isn't destination then the best fit. So why not use it in tagging then ?</span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px">So for me, tagging it as a subcase of destination (with extra tags, not values) will provide the best backwards compatibility.<br><br></span></font></div><div>But feel free to introduce a new value.</div><div><br></div><div>regards</div><div><br></div><div>m</div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div><font color="#500050"><span style="font-size:12.8px"><br></span></font></div><div>[1] The "Aangelanden" in Belgium is not official, so perhaps when the sign is there, it is even access=yes for the law, instead of access=destination.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 9, 2015 at 7:46 AM, Friedrich Volkmann <span dir="ltr"><<a href="mailto:bsd@volki.at" target="_blank">bsd@volki.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 08.10.2015 16:05, Marc Gemis wrote:<br>
> Just as your new value. That is not documented neither. A new value or a new<br>
> key, both have to be documented and implemented.<br>
<br>
A new tag value fits more into an existing tagging scheme than a new key.<br>
<br>
Some applications (such as even the standard renderer, as I was told) run<br>
with a separate database where only a small list of keys is imported.<br>
<br>
And with a new key, you have to handle more conflicts.<br>
Say, vehicle=yes + traffic_sign=no_vehicles.<br>
This causes headache to other mappers as well as application developers.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Friedrich K. Volkmann       <a href="http://www.volki.at/" rel="noreferrer" target="_blank">http://www.volki.at/</a><br>
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria<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" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</font></span></blockquote></div><br></div>