[Tagging] part_of:wikidata key
osm at imagico.de
Tue Nov 28 14:56:42 UTC 2017
On Tuesday 28 November 2017, Jo wrote:
> Smaller rivers don't have river relations, but they are still usually
> composed of several ways. (They are often split for tunnel=culvert).
You are free to create a relation for a river/stream of any size. Of
course if the waterways have no names there is no verifiable way to
structure the river network into distinct linear subset.
> I don't know what the big deal is with external identifiers. I agree
> too many of them are cruft in the DB.
This is one of the most important aspects of the discussion i linked to:
> * What is the qualification of Wikidata for having its IDs in OSM
> (both for wikidata=* and X:wikidata=*)? Is there a particular
> objective criterion that qualifies it? Would there be other external
> IDs that would also qualify under these criteria? Is there a limit
> in the number of different external IDs OSM is going to accept?
> But wikidata tags are the way to link to Wikipedia. It's not possible
> to link from Wikidata to OSM, due to the unstable nature of our ids
> and the 3 "namespaces" for nodes/ways/relations.
Again quoting from my previous analysis:
> * stability of Wikidata IDs seems limited. There seems to be a
> concept of redirects so an ID can point to a Wikidata object with a
> different ID and the object formerly under that ID is not necessarily
> identical to the one it redirects to. To what extent re-structuring
> of information on Wikidata (that would primarily mean merging and
> splitting of Wikidata objects) leading to the creation of redirects
> happens and how much more or less common it is to OSM IDs changing i
> don't know (and given Wikidata is still very young such information
> would also be quite unreliable for the future).
Note the three types of objects in OSM can simply be addressed with a
prefix as Osmium uses it: n12345/w12345/r12345.
Changing IDs in OSM happen mostly through either
* mappers not being aware of the importance of object histories and
doing a 'delete and newly create with the same tags' out of
* the geometry representation changing, in particular from a closed way
to a multipolygon relation.
A possible way to mitigate this problem would be to create a 'legacy_id'
tag that retains the id of the object first representing the real world
feature in question. Editors could have functions added to
automatically manage this as well as warning users if they make edits
that do not retain the id (like creating a feature with the same name
as one deleted in the same changeset but without a legacy_id tag).
More information about the Tagging