[OSM-talk] You are still free to continue to use or interpret this tag as you see fit since OpenStreetMap does not have “banned features”
tilmanreinecke at yahoo.de
Wed Mar 17 13:01:30 UTC 2021
I created the Proposal page
_This proposal wants to discourage the use of schemes in case they have
been labeled as deprecated and replacements have been found for them. _
And nothing else this proposal will do. It strikes to "prohibit new
entries being made with the old key" (Cited from Anonymous but said in
another context). It mustn't be done by a strict ban but it can be done
by discouraging "new entries [from] being made with the old key" (Cited
from Anonymous but said in another context).
On 15.03.21 14:58, S??ren Reinecke via talk wrote:
> Hello all,
> I see on the wiki sometimes the following message above wiki pages
> describing deprecated tags/keys:
> /This feature has been labeled as *deprecated*. The recommended
> replacement is: changing_table
> The reason is documented in Deprecated features
> <https://wiki.openstreetmap.org/wiki/Deprecated_features>. You are
> still free to continue to use or interpret this tag as you see fit
> since OpenStreetMap does not have ???banned features???. /
> /*Under no circumstances should you (semi-)automatically change
> ???deprecated??? tags to something else in the database on a large
> scale without conforming to the Automated Edits code of conduct
> Any such change will be reverted.*/
> I have objections on the part that OSM does not have a banned feature.
> OSM is a database and when it comes to that, there are rules.
> One of these rules is preventing data reluctance. In the example of
> deprecation of Key:diaper in order to push the much much better
> Key:changing_table forward we recommend mappers not to use the first
> key but the last key. In the same box we also see that the mapper can
> also use the old Key:diaper tag. Well, did you thought about the
> nonsense? Because developers will only support Key:changing_table and
> not the Key:diaper because we stick to standards and all others who do
> not will fail. It would be complete nonsense to map Key:diaper because
> no data customer will process that key, nor will convert it to
> something usable. So that entry ends up in the database for nothing
> and no other mapper will understand what the key is all about.
> Refering to "Deprecated features" wiki page (to cover
> Key:contact:phone vs Key:phone example):
> "Often expressed opinion is that in case of two tags with exactly the
> same meaning deprecating one and retagging objects is waste of time
> and energy and disturbs mapping for no benefit."
> - This opinion wrong and probably come from those not understanding
> databases. Deprecation in case two tags have exactly the same meaning
> is good and is an improvement to the database. And it is also clearer
> for newbies to decide whether to use tag A or B. For data customers it
> is also easier because they don't need to support two schemes meaning
> exactly the same. An example: Key:contact:phone and Key:phone where I
> had discussions with people not understanding databases and ignoring
> my expertise. I study these things btw.
> "Often expressed opinion is that in such case of tags with the same
> meaning one should be quickly deprecated"
> - The word "quickly" shouldn't be used here. Also deprecation of a
> duplicate tag should be done with care. Quick might be your wrong
> partner there. So people saying that, please reconsider your way of
> A "banned feature" would be useful here (in case of the phone thing)
> since two keys in use at the same time meaning exactly the same. We
> then could ban the use of Key:phone or Key:contact:phone and doing a
> duty to our database.
> So yes, we should ban certain features in favor of newer and better
> schemes and where possible automatically/manually convert these to the
> newer ones to keep the database clean and the information conveyed in
> these deprecated keys being useful still.
> S??ren Reinecke alias Valor Naram
> talk mailing list
> talk at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk