[talk-ch] OSM + Wikidata: No stable OSM IDs, meaning of source=survey in OSM

Estermann Beat beat.estermann at bfh.ch
Wed Jul 11 11:21:19 CEST 2018


Dear Stefan, Raphael,



Thank you for your clarifications!



I've added a comment to the property proposal:

https://www.wikidata.org/wiki/Wikidata:Property_proposal/OSM_node_ID

I'm not withdrawing it for now, as I think it is important to have this discussion.



I'm not familiar with OSM, but at first sight, it does not seem reasonable to renounce to having "permanent" IDs on the OSM side.

With "permanent" I mean that they must not be reassigned to a completely different entity after being deprecated. – This principle should not be very hard to implement on the OSM side, but again, I'm totally unaware of past discussions in this regard within the OSM community.



Regarding the proposal of using Wikidata Q numbers as identifiers for matching between OSM and Wikidata:

  *   Wikidata Q numbers are not absolutely "permanent": the scope of items may change (e.g. Qx "building and organization" is disentangled into Qx "building" and Qy "organization" - or vice versa).
  *   Wikidata items may be merged (in this case, the deprecated Q-number gets a re-direct to the valid Q-number).
  *   In some rare cases, Wikidata items may get deleted altogether (but the Q-numbers won’t get re-used for another item).
  *   I don’t think that under these conditions, we should just rely on Wikidata Q-numbers for the matching of items. – When disentangling or merging items on Wikidata, we should be able to explicitly deal with the related OSM IDs inside Wikidata.



Regarding the proposal of constructing some make-shift OSM IDs from tags and coordinates:

  *   If you create unique identifiers for the entries in OSM, they should be exportable to external databases. In my understanding, this is presently not the case due to licensing restrictions.
  *   And again, we should have a way of explicitly addressing OSM entries from within Wikidata.



See also: https://www.wikidata.org/wiki/Wikidata:OpenStreetMap

Maybe we should have this discussion over there.



Cheers,

Beat







-----Original Message-----
From: Stefan Keller [mailto:sfkeller at gmail.com]
Sent: Mittwoch, 11. Juli 2018 01:54
To: Openstreetmap Schweiz/Suisse/Svizzera/Svizra <talk-ch at openstreetmap.ch>
Subject: Re: [talk-ch] OSM + Wikidata: No stable OSM IDs, meaning of source=survey in OSM



Thanks Raphael for bringing this up. I want to backup your doubts.



Dear Beat



Although many (third party) apps are using OSM ID's, it is strongly recommended to abstain using such an "ID", especially in projects like Wikidata. Even the OSM relation ID should never have passed it's proposal to become a Wikidata property.



Use coordinate property in the first place. This is also what this extension https://www.mediawiki.org/wiki/Help:Extension:Kartographer

does.



Discussion about OSM IDs are repeatedly coming up in OSM mailing lists, and let to the "Permanent ID" proposal which is still in experimental stage. The idea is to use properties of an object to identify it: see https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID .



I hope you understand these reasonings and withdraw your Wikidata property proposal:

https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#OSM_node_ID



:Stefan



2018-07-10 19:05 GMT+02:00 Raphael Das Gupta

<lists.openstreetmap.ch at raphael.dasgupta.ch<mailto:lists.openstreetmap.ch at raphael.dasgupta.ch>>:

> Hi Beat

>

> On 10.07.2018 10:13, Estermann Beat wrote:

>

> What we are missing right now in Wikidata is a property to refer to

> the OSM node ID. I have therefore submitted a property proposal:

> https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_con

> trol#OSM_node_ID Feel free to add more examples and endorse the

> proposal. Creation of the property should take about 2 weeks.

>

> I doubt that it's a good idea to create a property for OSM IDs on

> Wikidata, as OSM IDs aren't "stable". Editors may (and sometimes do)

> assign new IDs even though the real-world object may still be the

> same, and previously used IDs might be re-assigned if not currently in

> use. (See e.g. the vivid history of Node Nr. 1:

> https://www.openstreetmap.org/node/1)

>

> Instead, OpenStreetMap entities (nodes, ways or relations) with a

> corresponding Wikidata object should refer to the Q-number (which

> AFAIK is stable). Determining the corresponding OpenStreetMap

> object(s) for a Wikidata entry would then require something like an

> Overpass query, but I can't think of any alternative way to make this

> linking sound and future-proof.

>

> And feel free to submit a property proposal for OSM ways if you see a

> need for it.

>

> Dito.

>

> What I don't like in the OSM data is the fact that the source

> ("survey") does not have proper references (which survey? publication date?).

>

> This is probably a misunderstanding. The source declaration "survey"

> in OpenStreetMap is understood to mean that the editor observed the

> represented facts themselves on-the-ground, not that the data stems

> from some published survey document or dataset. If the information

> stems from an pre-existing dataset, that specific dataset should be

> mentioned in the "source" changeset tag.

>

> See the value's explanation at

> https://wiki.openstreetmap.org/wiki/Key:source#General_sources_commonl

> y_used_by_human_mappers

> :

>

> The OSM user was there and saw it himself/herself. The OSM user may or

> may not have done any precision measurement of the location etc. using

> a device such as a GPS receiver or a theodolite.

>

>

> Note that use of the "source" tag on OpenStreetMap entities (nodes,

> ways or

> relations) is considered historic and (according to the Wiki not

> officially, but de-facto) deprecated. The tag should be used on changesets instead.

> Occurrences on nodes, ways or relations should not be taken at face

> value (they are likely to be outdated or incomplete if the object has

> been edited

> since) and should probably be ignored by OSM data consumers and/or

> augmented with the source information of the complete history of the object.

>

> Regards,

> Raphael

>

> _______________________________________________

> talk-ch mailing list

> talk-ch at openstreetmap.ch<mailto:talk-ch at openstreetmap.ch>

> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20180711/43d10af3/attachment-0001.html>


More information about the talk-ch mailing list