[OSM-talk] Id stability

[Frederik Ramm]

Andrzej,

andrzej zaborowski wrote:
> Or create an OSM relation containing just the thing you want to link
> to and reference the relation's Id.... the editors already support
> warning when somethign bad happens to a relation member.  

Under no circumstances should we burden the mapper with keeping up 
external IDs that someone needs for their application. A relation being 
edited is not "something bad happening", it is something good. We don't 
want to discourage edits, or make them more complex, just so that 
someone's linked data store continues to function - that must be *their* 
  job, not the mapper's.

> Relations
> are unlikely to be reused for a compeltely new purpose and they can be
> undeleted and modified to match changes in reality.

Just because you cannot think of anything right now doesn't mean that 
(a) there isn't anything and (b) there won't be anything in the future. 
If you promise relation ID stability to anyone now, you reduce what *we* 
can do with *our* data in the future.

(One example off the top of my head: Relations for long-distance routes 
are often created in several places at the same time, then they grow 
until they "meet", and are merged, with one of them being deleted.)

>> Of course you would add a UUID tag only to objects that are actualy
>> referenced. And then you would need some way to enforce uniqueness.
> 
> Because of the above I'm not sure if you want to enforce uniqueness,
> you might even want >1 UUIDs per osm entity.

I'm not a big fan of UUIDs because, again, it burdens *our* data with 
stuff that other people want to do with it. We had a lot of discussion 
about this. Andrzej ist right - if five-star restaurant "Chez John" is 
in a listed building, then someone compiling a directory of listed 
buildings would have to use another UUID than someone compiling a list 
of good restaurants, because the restaurant could move elsewhere and it 
would then have to take its UUID with it. Consequently, people have 
started to use UUID:building and UUID:amenity keys but I really have a 
very bad feeling about this.

Coming back to what Maarten has said above, I would definitely be 
against adding UUIDs to every single house and garden shed "just in 
case" - like the 75.000 "uuid:building" tags we have. If we were to do 
UUIDs we would have to have a way of finding out whether something is 
actually linked, and if it isn't, then don't bother having an UUID.

Which brings me back to something I mentioned earlier - I would like to 
have some kind of "link server" where you can go and say "I want a 
permanent link to this OSM object", then the server says "ok, I have 
investigated the object you mentioned and I'd say I make the permanent 
link point to 'a restaurant named Chez John within 500 metres of this 
location', is that ok", and you go "yes", and the server then says "your 
permanent link ID is 1234567890, thank you". At any later time you can 
query the server for that permanent link ID and you get back either the 
OSM object, or the current OSM object ID, or nothing if the link is broken.

The great thing about such a server would be that the server could 
indeed *always* know which links are still working and which are broken, 
and broken links could even be automatically highlighted on something 
like OpenStreetBugs so anyone who is interested could hunt them down and 
fix them. The server could also track which links are actually used, and 
expire them if they aren't used for a year or so.

This would make one great project for a student thesis (Claus, are you 
still reading...?). I don't know if this is compatible with the linked 
data store idea, maybe explicitly having to register a link is a problem 
there, but if that's the case then I'd say linked data store is just not 
for us.

And to Steve Bennett ("people need a solution now, not vapourware") - 
sometimes settling for a half-baked solution too early has the risk of 
entrenching half-bakedness and never getting around to implement a good 
solution.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"