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

Mateusz Konieczny matkoniecz at tutanota.com
Tue Mar 30 19:31:32 UTC 2021


Maybe you missed it but 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/ban_deprecated_tags
has some questions/feedback that remain unanswered/ignored.

Mar 30, 2021, 20:42 by talk at openstreetmap.org:

> To get onto the topic I want to just the silly question "What do you loose when this proposal gets approved?"
>
> On 15 Mar 2021 2:58 pm, Sören Reinecke via talk <talk at openstreetmap.org> 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 <https://wiki.openstreetmap.org/wiki/Key: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 <https://wiki.openstreetmap.org/wiki/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 thinking.
>>
>> 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.
>>
>> Cheers
>>
>> Sören Reinecke alias Valor Naram
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210330/625f00ca/attachment.htm>


More information about the talk mailing list