[Tagging] Feature Proposal - RFC - Discouraging the use of deprecated schemes

Robin Burek robin.burek at gmx.de
Mon Mar 22 00:33:06 UTC 2021


Am 21.03.2021 um 17:57 schrieb Bert -Araali- Van Opstal:

> The warning message which we show at the top of "deprecated" tags is
> to dominant.  It should be removed.  In essence, deprecation,
> banning is all contra-productive when it comes to improving tagging
> and achieving consensus, let us work together instead of against each
> other.  Not emphasize that practices and tactics exist that go
> against core OSM values as free and open and community engagement,
> incite activities and give people ideas how to undermine them.
>
> A description can be given with a link to the deprecation wiki page in
> the "When to use" or "Usage" section.
>
I think the warning message can't be flashy enough - otherwise it
wouldn't be a warning message. A mention anywhere in the text is
forcibly overlooked. You should make it clear that one day after the
consensus of the community is no longer up to date. Especially for the
"casual mapper" who doesn't follow a thousand mailing lists or forums.Â

> We should also remove it from the proposal process.  Deprecation, and
> the process of how to determine if the community supports the
> deprecation of a certain tag, should not be promoted by advocating it
> through Organised Mass or (semi)Automated edits.  But it comes to
> those extremes in many proposals we see today. So we should ban it
> from the proposal process.
>
But now I disagree with you. Yes, you can freely map everything here.
But at the same time it is part of consensus-building processes that not
only new, uniform keys or values are found, but that these also replace
others. To exclude this would clearly lead the proposal in some places
extremely ad absurdum. You would disperse the database more and more and
in the end destroy the data for data users to such an extent that one is
more fixed than further development can take place. Data users and
renderers simply need good documentation and, above all, a uniform
database. And unfortunately both things are often produced very sparsely
here. And OSM is a database, and it is also a task of a database to save
and output data consistently.
You would do away with the database itself if you take away its
structure and "uniformity".

> This might mean that you will see during prolonged periods duplicate
> and competing tagging schemes, but I personally see no problem in
> that.  Neither for data consumers or renderers, they decide
> independently what they render, what and how they process our data.Â
>
Referring to my previous paragraph: How should the data user decide if
there is no uniform basis for decision-making?If it were up to you, in
the future I could mark all my streets with the key "road" instead of
"highway". That would be okay, because the mapping is free and the data
users and renderers have to be able to handle it if they want to use it
sensibly. (Yeah that's an exaggeration, but effectively it would come
down to something like that)

All in all, a database must always have the right to map the data
correctly, but still free of contradictions. And that includes not
having five different tags for phone numbers, and someone uses a sixth
variant. But that you create uniformity for all sides. And some then
just have to jump over their shadow and are then urged, but please to
use something else. (You can anyway, but then the community has every
right to adapt this to the consensus)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210322/ffe0d1ae/attachment.htm>


More information about the Tagging mailing list