Andy, I suspect it will not help with every single geometry, but I think there will be plenty of untouched ones though.
Unfortunately I do not have a specific example of a situation where this has worked, but it seems better than the alternative of not using any UUIDs. For example importing all of the streets/parcels in Washington D.C. I think it makes sense to have a UUID so we can more quickly mark data as it changes. Could we potentially accomplish this in other ways? Sure. I think the UUID deserves exploration, if at a later time we discover it hasn't worked at all they could potentially be removed. -Kate On Wed, Oct 14, 2009 at 12:03 PM, Andy Allan <gravityst...@gmail.com> wrote: > 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. > > Any counter examples that I'm not aware of? > > Cheers, > Andy > >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
