Andy,<div><br></div><div>I suspect it will not help with every single geometry, but I think there will be plenty of untouched ones though.  </div><div><br></div><div>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.</div>
<div><br></div><div>-Kate<br><br><div class="gmail_quote">On Wed, Oct 14, 2009 at 12:03 PM, Andy Allan <span dir="ltr"><<a href="mailto:gravitystorm@gmail.com">gravitystorm@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Will it? I keep hearing that but don't really believe it. It would be<br>
hard enough merging changes if the data was not converted, has a 1:1<br>
correspondence in geometries and hadn't been editing in the meantime.<br>
But given that people will split ways, make multipolygons, and a<br>
certain %age of uuids will either disappear or end up on the wrong<br>
features (combine, split, combine) then I don't see them as useful<br>
*enough* to try to preserve them for years on end.<br>
<br>
It always seems like a nice idea, but I've yet to see it work in<br>
practice in OSM. I expect updates to require matching based on<br>
position and attributes (name etc) as opposed to the exceptionally<br>
fragile preservation of uuids.<br>
<br>
Any counter examples that I'm not aware of?<br>
<br>
Cheers,<br>
<font color="#888888">Andy<br>
</font><div><div></div><div class="h5"><br></div></div></blockquote></div></div>