[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