[OSM-talk] Tagging OSM objects with UUIDs

[John Smith]

On 7 June 2010 19:01, Frederik Ramm <frederik at remote.org> wrote:
> It doesn't exactly require a stroke of genius to see that potential, given
> that people are already using our internal IDs all over the place for lack
> of something better.

I'm open to suggestion on what would be better, I don't think either
system is perfect and both have work arounds for their flaws.

> It does, however, require a stroke of genius to find a non-invasive and
> permanent way to solve this problem. Tagging objects with UUIDs is neither.

Unless we start trying out different solutions we'll only be guessing.
You're assuming they'll simply disappear, but they can be applied to a
new object, unlike the existing IDs.

> If you investigate the use cases for permantent IDs further, you will find
> that "moving across town" is often a valid reason for actually discarding
> the ID. As in, someone writes a travel guide and wants to link to a
> restaurant ("Chez Fred, an excellent pizza joint in the heart of Hamburg
> with views on the Elbe river traffic..."). Now if "Chez Fred" moves across
> town and is replaced, at the same location, with "Chez John", is it useful
> for the travel guide to still be able to link to "Chez Fred"? - Of course,
> if the travel guide said: "Chez Fred, an excellent pizza joint in Hamburg
> where renowned chef Frederik Ramm entertains his guests to Pizza Margherita
> every Tuesday", then it would have made sense to keep the link despite the
> move (but perhaps not so if the owner=... tag had changed...)

You misunderstood, I wasn't talking about people tagging stuff moving
across town, I was talking about the thing they tagged moving across
town. Also the current proposal suggests using multiple UUID tags if
needed one for the occupant, one for the building in case they need to
be split, if you only have one UUID and Flickr refers to the building
and wikipedia refers to the occupant, who gets to keep the UUID if the
occupant shifts?

> For every kind of object and every context in which you link to it, the
> change of some properties might invalidate the link. That's why UUIDs are
> not only clumsy but also not solving the problem.

I fail to see your point here, why would changing properties cause
problems with UUIDs that are allocated independently of the existing
OSM ID information? I'm not suggesting here to replace the internal ID
numbers with something else, but use static tags so they can be
shifted between objects.