2009/10/14 Andy Allan <[email protected]>: > 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 _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
