[Tagging] part_of:wikidata key

Kevin Kenny kevin.b.kenny+osm at gmail.com
Tue Nov 28 20:29:03 UTC 2017

On Tue, Nov 28, 2017 at 2:47 PM, Andy Mabbett <andy at pigsonthewing.org.uk> wrote:
> On 28 November 2017 at 16:40, Christoph Hormann <osm at imagico.de> wrote:
>> The problem is OSM is a map of the physical world, not a map of the
>> world's databases.  If Wikidata wants to create links between OSM and
>> other databases that is great but so far i think no one has made a good
>> case why this linking information should be stored in OSM rather than
>> Wikidata.
> Then you are not paying attention. OSM IDs are volatile - far more
> volatile than Wikipedia IDs, let alone Wikidata IDs.
>> Again my suggestion: Working on better ways to address features in OSM
>> in a stable way from the outside would be much more productive
> Great! Let us know when you have a working solution, consensus to
> implement it, and tools that work with it.

Having nonvolatile ID's for ways really is technically infeasible. Ways get
split and recombined all the time, and their ID's will never be stable.

Having nonvolatile ID's for relations - we nearly do have these. If Wikidata
links addressed relations only, this discussion would be less urgent.
JOSM already scolds the user who tries to delete a relation. It's mostly
harmless to create a multipolygon with a single member, if necessary,
to generate a stable external ID.

Nevertheless, I agree with Andy that an external tool is a better approach.

Here is a relation object whose ID may or may not be volatile:
Here is an Overpass query that will return the OSM data for the
same Wikidata ID, irrespective of what happened to volatile
(click on the link to see the query)

Here is a slightly more complicated case, where the historic site is
both a boundary (that includes the grounds) and a building. I see that
there were multiple edits trying to get the wikidata right, and there
may have been the need of a site relation. I am guessing that at least
one of the way ID's for the site is likely to be volatile.
With Overpass, it appears that the multiple edits might not
have been necessary. A one-to-many relation between Wikidata
tag and geographic object may have been tolerable.
(again, click on the link to see the query, but it's pretty much got the
same structure as above.)

Given that the Overpass API exists, do we have a worked example
here to demonstrate that external tools have a ready way of accessing
'wikidata' tagged items within OSM?

More information about the Tagging mailing list