[OSM-talk] OSM relation ID property in Wikidata
Mike
mike.cuttlers at gmail.com
Tue May 7 14:14:34 UTC 2013
I guess you are all both right and wrong on this matter and thus because
you are loking from single angle only.
I recognize several different needs:
External link to coordinates
This is simply link to specific geographic coordinates. As it is not
necessarily that there is an object on this coordinates that means there
is no sense for such links to exist at all.
External link to location
Lets define location as specific place on map where object is located.
It may not necessarily fixed to specific coordinates for the sole reason
that coordinates may be changed for reasons like better measurements or
fixed error or something like this. But, this is still just an location
which may be linked externally regardless what type of object is located
there.
External link to an property
Property is object on map that is fixed (if we disregard possibility
that it may be destroyed or relocated in very exceptional conditions).
Any kind of building is fine example. In some manner we may look at
property and location as the same but with significant difference:
location is related to geographic location and has eternal existence,
and property is related on real object which is logically placed on a
location but may be destroyed or (exceptionally) moved.
Back to the point, external link to an object is meant to target
specific object that is not moveable.
External link to an property purpose
Property purpose is function object has. If we see building as an
property, shop located in that building would be object purpose. Object
purpose is not constant. It may change. Building may have number of
purposes in time, or several purposes at the same time. But if some
external database contains data about number of shops it needs to link
to OSM data which related for specific shop. If shop moves few blocks
away, external link should still point to that very shop.
So, to have database support all this needs it should have separate
entities as location, property and property purpose in manner that one
first defines location (with it's own ID), then defines property (with
it's own ID) at that location and then attaches property purpose(s)
(with their own ID(s)) for that object.
Whole discussion is caused because OSM database does not support this
kind of objects. It is so loosely defined that object may serve all
three roles from case to case and may even change role in time.
What could be solution?
First, let simplify things by merging role of location and role of
property as they are very similar.
When new object is created in OSM database it should get it's unique ID.
That ID stays unchanged until object is deleted. This is actually how
thing are already done, and it will do the job for external linking to
location or property.
But it does not help when property purposes are needed. So, OSM database
may be expanded for another ID which is created when purpose is assigned
to object and if purpose of the object is changed. It also should stay
unique. This other property would allow linking to property purpose. If
property purpose is deleted, it's ID is also deleted, but if purpose is
moved to other object (on another location) then it's ID is moved to and
unchanged, so external links will still be valid.
What happens when object is changed from point to multipoint or area or
split?
It should done in such manner that object ID is preserved, or, in case
new object is created instead of an old one, some kind of relation
should be established so if database is queried for old object ID it
would return info about new object with new ID which is replacement.
If object is split, one part preserves existing ID and other parts are
considered as new objects with new ID's assigned.
More information about the talk
mailing list