<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Am 21.03.2021 um 17:57 schrieb Bert -Araali- Van Opstal:<br>
</p>
<blockquote type="cite"
cite="mid:14d872a0-0ae6-3bf2-946a-3d6df222bc4c@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font size="-1" face="Verdana">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.<br>
</font></p>
<font size="-1"> </font>
<p><font size="-1" face="Verdana">A description can be given with
a link to the deprecation wiki page in the "When to use" or
"Usage" section.<br>
</font></p>
</blockquote>
<p>I think the warning message can't be flashy enough - otherwise it
wouldn't be a warning message. <span class="VIiyi" lang="en"><span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="1"><span>A
mention anywhere in the text is forcibly overlooked.</span></span>
<span class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="2"><span>You
should make it clear that one day after the consensus of the
community is no longer up to date. </span></span></span><span
class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>Especially
for the "casual mapper" who doesn't follow a thousand
mailing lists or forums.</span></span></span> </p>
<blockquote type="cite"
cite="mid:14d872a0-0ae6-3bf2-946a-3d6df222bc4c@gmail.com">
<p><font face="Verdana">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. <br>
</font></p>
</blockquote>
<p><span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>But
now I disagree with you.</span></span> <span class="JLqJ4b
ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="1"><span>Yes,
you can freely map everything here.</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="2"><span>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.</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="3"><span>To
exclude this would clearly lead the proposal in some places
extremely ad absurdum.</span></span> <span class="JLqJ4b
ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="4"><span>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.</span></span>
<span class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="5"><span>Data
users and renderers simply need good documentation and,
above all, a uniform database.</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="6"><span>And
unfortunately both things are often produced very sparsely
here.</span></span> <span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="7"><span>And
OSM is a database, and it is also a task of a database to
save and output data consistently.<br>
</span></span></span><span class="VIiyi" lang="en"><span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="9"><span>You
would do away with the database itself if you take away its
structure and "uniformity".</span></span></span> <br>
<span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="7"><span></span></span></span></p>
<blockquote type="cite"
cite="mid:14d872a0-0ae6-3bf2-946a-3d6df222bc4c@gmail.com">
<p><font face="Verdana"> 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. <br>
</font></p>
</blockquote>
<p><span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>Referring
to my previous paragraph: How should the data user decide if
there is no uniform basis for decision-making?</span></span><span
class="JLqJ4b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="1"><span>
</span></span><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="2"><span>If
it were up to you, in the future I could mark all my streets
with the key "road" instead of "highway".</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="3"><span>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.</span></span> <span class="JLqJ4b
ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="4"><span>(Yeah
that's an exaggeration, but effectively it would come down
to something like that)<br>
<br>
</span></span></span><span class="VIiyi" lang="en"><span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"><span>All
in all, a database must always have the right to map the
data correctly, but still free of contradictions.</span></span>
<span class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="1"><span>And
that includes not having five different tags for phone
numbers, and someone uses a sixth variant.</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="2"><span>But
that you create uniformity for all sides.</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="3"><span>And
some then just have to jump over their shadow and are then
urged, but please to use something else.</span></span> <span
class="JLqJ4b ChMk0b" data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="4"><span>(You
can anyway, but then the community has every right to adapt
this to the consensus)</span></span></span> <br>
<span class="VIiyi" lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="4"><span></span></span></span></p>
</body>
</html>