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 frede...@remote.org ## N49°00'09" E008°23'33"
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
