[OSM-talk] Id stability

[Frederik Ramm]

Hi,

Steve Bennett wrote:
> If your definition of "work" is "guaranteed to work under all
> circumstances no matter what", then sure. But if it's "continue to
> function subject to a slow rate of linkrot 

[...]


>> 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.
> 
> Let's avoid that if possible.

See, that's exactly my point. Once we allow people to use our internal 
IDs to link to (and more or less promise them only a "slow rate of 
linkrot"), then we drastically reduce our say over our own data. 
Suddenly certain operations that might totally make sense otherwise fall 
in the category of "aw, but let's not do that, all those people who have 
hard-coded relation IDs in their applications will fall over".

I could even see the discussion of how to model areas in the 
post-API-0.6 world be influenced by people who say "aw, but's let's 
avoid that if possible", and us choosing the second-best alternative 
just to placate people who use our internal IDs to link to.

OSM IDs are our internal thing and we must keep the freedom to do with 
them whatever we think makes sense to us, at any time in the future.

> Vapourware solutions are nice, but when people have a problem today,
> they need a solution that exists today.

Well then let them think of a solution. Using our internal IDs to link 
to is a vapourvare "solution" just the same. Anyone who uses them must 
be aware that they might change at any time, even wholesale.

But excuse me now, I'm writing a node renumber script that will keep us 
in the 32-bit range for half a year longer by re-using the gaps created 
by deleted nodes ;)

Bye
Frederik

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