[OSM-talk] Fwd: Re: Roadmap for deprecation of name tags in OSM

pangoSE pangose at riseup.net
Sun Aug 9 10:52:47 UTC 2020

This was meant for the list.

-------- Originalmeddelande --------
Från: pangoSE <pangose at riseup.net>
Skickat: 9 augusti 2020 11:09:08 CEST
Till: Mateusz Konieczny <matkoniecz at tutanota.com>
Ämne: Re: [OSM-talk] Roadmap for deprecation of name tags in OSM


Thanks for the response. 

Mateusz Konieczny via talk <talk at openstreetmap.org> skrev: (9 augusti 2020 10:42:21 CEST)
>Aug 9, 2020, 10:25 by pangose at riseup.net:
>> I suggest we create a roadmap for deprecating of storing and updating
>names in OSM for objects with a Wikidata tag.
>Absolutely no.
>tagging name tag is a fundamental  part of OSM tag,
>offloading it to a third party service is a mistake that will not

I disagree. Redundancy is a problem waiting to be solved.

>https://josm.openstreetmap.de/ticket/19655 contains several misleading,
>wrong, mistaken
>and problematic claims, statements and implications but I have no time
>to process in detail
>as the entire idea is fundamentally bad, mistaken, problematic, broken,
>not workable,
>not acceptable, not going to happen and wrong.

I disagree. The current handling of names in osm is redundant in many cases and badly broken when it comes to references.

>Some samples:
>"there is no such thing as an international name. Names are part of a
>language whih is part of a culture. They are not GIS objects and the 
>osm datamodel does not handle this complexity well at all."
>Are you aware that we have other tags beyond name tag?


>loc_name, name:pl and many others?

Yes. This is not a blocker. For loc_name and others a new wikidata property can be created.

>"No more name vandalism in osm. We export the name handling to
>wikidata which has a much better system for handling vandalism."
>Because vandalism in third-party service is superior?
>Are you seriously claiming that Wikidata has less trouble with
>and deals with it better?

Yes. The new york defacement could most probably have been avoided wih this approach. I have no statistics to back up this claim though.

If anyone have statistics I would love to read them.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20200809/d8067b78/attachment-0001.htm>

More information about the talk mailing list