[OSM-talk] Id stability

[Frederik Ramm]

Hi,

Steve Bennett wrote:
> 3) Why people intentionally destroy ids, and whether there are better
> ways of achieving their goals?
> 
> (I seem to recall someone explaining that sometimes objects are
> deleted and recreated in order to discard the change history,
> particularly for large relations.)

That was me. There are a number of other reasons why IDs could "break". 
One is the expansion of POI nodes into buildings that Toby mentioned. 
Another is the splitting of ways (old ID would then point to only half) 
or merging (old ID would become invalid in 50% of cases). Same with the 
re-structuring of relations or the re-mapping of stuff in the course of 
the license change.

Relying on numeric IDs is never going to work, and there is no way how 
this could be made to work in the future. IDs are OSM internal 
identifiers and if you use them for anything external then you're lost. 
It is even conceivable that, for whatever reason, IDs are changed on a 
grand scale - for example I expect API 0.7 to introduce some kind of 
area data type which will likely lead to lots of existing areas being 
changed in some way and that might include a new ID.

The generally accepted wisdom - although not fully implemented or 
extensively used - is that you need to make fuzzy links like "a node 
with amenity=pub and name=The Old Dog in this area". Tim Alder's "query 
to map" interface tried to implement that. In the long run there might 
be proper, external servers where you can set up a stored query like the 
above "Old Dog" and record a permanent ID for that query, and then 
reference that.

I don't think it should/will be a core API feature though, or at least 
that would be phase 2 after a number of competing schemes have been 
tried out by third parties and the best has been found.

(Two or three people have also started tagging OSM objects with UUID 
tags but I don't think that that's anything more than database bloat. I 
think that about 99.9% of UUID tags in the database come from a building 
import where somebody automatically assigned an UUID to every last 
garden shed. Not useful.)

Bye
Frederik

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