[Talk-ca] [Imports] The great UUID debate (Was Re: 092G area)

[andrzej zaborowski]

2009/10/14 Andy Allan <gravitystorm at gmail.com>:
> Will it? I keep hearing that but don't really believe it. It would be
> hard enough merging changes if the data was not converted, has a 1:1
> correspondence in geometries and hadn't been editing in the meantime.
> But given that people will split ways, make multipolygons, and a
> certain %age of uuids will either disappear or end up on the wrong
> features (combine, split, combine) then I don't see them as useful
> *enough* to try to preserve them for years on end.
>
> It always seems like a nice idea, but I've yet to see it work in
> practice in OSM. I expect updates to require matching based on
> position and attributes (name etc) as opposed to the exceptionally
> fragile preservation of uuids.

The UUIDs can be even automatically removed by a bot after a
non-importer user touches an object, however the amounts of data
imported in the US show that most data will remain untouched for a
long time.  But... even when a way is edited, say, split, it's
probably useful to have the information about what particular object
in CanVec it came from -- otherwise you can only tell a piece of it
came from somewhere in CanVec, based on the first changeset comment in
that way's history, but cannot tell where in CanVec.

It's definitely more useful than the CODE.

Re keeping or dropping the CODE, I don't know exactly how the import
scripts work, but if there's "one-to-many" mapping between the CODE
and OSM tagging then I'd drop it.  If the mapping is more the
"many-to-one" type (like I believe it was the case in CorineLandCover
import), then I'd keep it.

Cheers