[Tagging] new access value

Marc Gemis marc.gemis at gmail.com
Fri Oct 9 06:30:37 UTC 2015


You didn't read my complete mail then. I wrote that it would be better to
use something like access:destination:traffic_sign=...
because I realised that traffic_sign on a road would be a bad idea.

Did you read 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.

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.
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.
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 ?

So for me, tagging it as a subcase of destination (with extra tags, not
values) will provide the best backwards compatibility.

But feel free to introduce a new value.

regards

m


[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.

On Fri, Oct 9, 2015 at 7:46 AM, Friedrich Volkmann <bsd at volki.at> wrote:

> On 08.10.2015 16:05, Marc Gemis wrote:
> > Just as your new value. That is not documented neither. A new value or a
> new
> > key, both have to be documented and implemented.
>
> A new tag value fits more into an existing tagging scheme than a new key.
>
> Some applications (such as even the standard renderer, as I was told) run
> with a separate database where only a small list of keys is imported.
>
> And with a new key, you have to handle more conflicts.
> Say, vehicle=yes + traffic_sign=no_vehicles.
> This causes headache to other mappers as well as application developers.
>
> --
> Friedrich K. Volkmann       http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20151009/6814ad90/attachment.html>


More information about the Tagging mailing list