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

James james2432 at gmail.com
Sun Aug 9 12:49:36 UTC 2020


Network calls incur a performance hit. I didn't say it was complicated.

On Sun., Aug. 9, 2020, 8:46 a.m. pangoSE, <pangose at riseup.net> wrote:

>
> I disagree. With (permanent) unique ids is trivial and the overhead is IMO
> neglible.
>
> Its not rocket science to query an API endpoint from any programming
> language. All our data consumers are already doing this.
>
> I made a simple map in a few hours that query both overpass and wikidata
> based on the osmid to find links to images of shelters. See
> https://github.com/pangoSE/sheltermap
>
> James <james2432 at gmail.com> skrev: (9 augusti 2020 13:59:40 CEST)
>>
>> Not to mention the additional overhead of conflating two databases to get
>> something essential like a name
>>
>> On Sun., Aug. 9, 2020, 7:57 a.m. Alan Mackie, <aamackie at gmail.com> wrote:
>>
>>> This seems like a bad idea.
>>>
>>> Name tags are generally very easy to verify on the ground. It is not
>>> always as easy to tell if a shop with a certain name belongs to a specific
>>> wikidata entry, especially in jurisdictions that are less litigious when it
>>> comes to trademarks.
>>>
>>> We also should not be doing bulk name changes until we have verified
>>> that the signage on the individual locations has actually changed.
>>> Depending on the brand these could take years to ripple through to the
>>> individual stores, and particularly 'historic' stores may retain old
>>> branding as part of a conscious effort not to irk locals. Branding changes
>>> in the Wikidata would likely be over-applied.
>>>
>>> Abandoning the name tags for chains would essentially be carte-blanche
>>> permission for automated edits. As it stands now, a disagreement between
>>> OSM name and Wikidata name may be a useful indicator that resurvey is
>>> needed. If we abandon name tags we open the door to the introduction of
>>> dodgy data that isn't caught by any of our QA tools because it doesn't even
>>> have a changeset.
>>>
>>> If "duplication"  is really an issue, I would prefer to remove all
>>> Wikidata tags than to depreciate names where they exist. Forcing
>>> contributors to check an independant database before uploading survey
>>> results seems like a lot of extra effort for a volunteer driven project.
>>>
>>> On Sun, 9 Aug 2020 at 12:11, pangoSE <pangose at riseup.net> wrote:
>>>
>>>> These are valid concerns. See my response to James.
>>>> If Wikimedia should become uncooperative we could easily set up our own
>>>> wikibase installation. See https://www.wbstack.com/
>>>>
>>>> It takes a few minutes plus some configuration time.
>>>>
>>>> It would also be a new and currently unnecessary drain on OSMF's
>>> resources.
>>>
>>> In fact this might be much better than forcing our data into wikidata
>>>> which is very tied to education and does not accept all our objects that
>>>> have names currently.
>>>>
>>>> In case we take this route I would recommend having another prefix than
>>>> Q for our unique ids.
>>>>
>>>> Cheers
>>>>
>>>> Mateusz Konieczny via talk <talk at openstreetmap.org> skrev: (9 augusti
>>>> 2020 12:16:33 CEST)
>>>>>
>>>>> or has downtime? or deletes data/items used by OSM? or bans OSM
>>>>> mappers?
>>>>> or refuses to ban vandal/troll/harasser? or fails to ban them quickly?
>>>>>
>>>>> Aug 9, 2020, 11:45 by james2432 at gmail.com:
>>>>>
>>>>> is there a contingency plan if wikipedia/wikimedia ceases to exist?
>>>>>
>>>>> On Sun., Aug. 9, 2020, 4:29 a.m. pangoSE, <pangose at riseup.net> wrote:
>>>>>
>>>>> I suggest we create a roadmap for deprecating of storing and updating
>>>>> names in OSM for objects with a Wikidata tag.
>>>>>
>>>>> The rationale is explained here:
>>>>> https://josm.openstreetmap.de/ticket/19655
>>>>>
>>>>> This of course affects the whole project and data consumers as well.
>>>>> Every OSM user will have to become a Wikidata user as well to edit the
>>>>> names or add name references (through the editors)
>>>>>
>>>>> Substantial changes will have to be made:
>>>>> * nominatim will need to support fetching names from wikidata somehow.
>>>>> It could probably be done on the fly.
>>>>> * openstreetmap.org will need to fetch from wikidata when displaying
>>>>> any object.
>>>>> * rendering the standard map will have to support fetching from
>>>>> wikidata.
>>>>> * all editors would have to fetch and enable editing of Wikidata
>>>>> objects.
>>>>>
>>>>> These seems like large burdens to dump on open source developers.
>>>
>>>> * maybe it no longer makes sense to have 2 separate logins? We should
>>>>> unify the logging in as much as possible. Ideas are welcome on how to do
>>>>> that. Perhaps retire signing up as OSM user on osm.org and ask users
>>>>> to create a Wikimedia account instead and log in with that?
>>>>>
>>>>> I'm not sure if I have a Wikidata account so this is a non-issue for
>>> me.
>>>
>>>>
>>>>> I personally don't see any problems connecting Wikimedia and OSM
>>>>> closer than the islands they are today.
>>>>>
>>>>> As mentioned in the ticket above data consumers like Mapbox already
>>>>> prefer Wikidata names. I'm guessing thats because they are simply better
>>>>> quality, better modeled, better referenced and better protected against
>>>>> vandalism.
>>>>>
>>>>> WDYT?
>>>>>
>>>>> Cheers
>>>>> pangoSE
>>>>> Ps I choose this list because this not only relates to tagging, but to
>>>>> the wider ecosystem._______________________________________________
>>>>> talk mailing list
>>>>> talk at openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/talk
>>>>>
>>>>>
>>>>> _______________________________________________
>>>> talk mailing list
>>>> talk at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk
>>>>
>>> _______________________________________________
>>> talk mailing list
>>> talk at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20200809/8aeea1bb/attachment.htm>


More information about the talk mailing list