I'd have to disagree. While there are many areas of Canada that will change little, if at all, from current data, it would be incredibly short sighted and lazy to not implement UUIDs at the initial import phase. Considering the bulk of the work is done with a script, it only makes sense to include the extra bit of data. The road may not move, but if more detailed data comes out for a street (such as better block numbering, # of lanes for a road, cover type, last paved, etc.), it would be easier to add this data to existing data based on UUID. If there is no UUID, but the road exists, then we just have the script do what it already does - match the imported segment to the segment on the map based on its current location.<br>
<br>If I recall correctly from earlier mail in this list (from before the import), we discussed this and the US Tiger import was brought up because they didn't include UUIDs and therefore couldn't really update it as well or at all. My memory could be wrong about this though.<br>
<br clear="all">-Kevin (Kevo)<br>
<br><br><div class="gmail_quote">On Wed, Oct 14, 2009 at 12:16 PM, Michael Barabanov <span dir="ltr"><<a href="mailto:michael.barabanov@gmail.com">michael.barabanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
While this can indeed happen in many cases, Canada is so huge that I<br>
expect large areas to be left as is, and not have this problem. Even for densely populated<br>
areas like Vancouver, the rate of changes isn't all that high right now.<br>
<br>
Michael.<br>
<br>
On Wed, Oct 14, 2009 at 05:03:27PM +0100, Andy Allan (<a href="mailto:gravitystorm@gmail.com">gravitystorm@gmail.com</a>) wrote:<br>
> 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>
> Andy<br>
><br>
> On Wed, Oct 14, 2009 at 1:09 PM, Kate Chapman <<a href="mailto:kate@maploser.com">kate@maploser.com</a>> wrote:<br>
> > I also think UUID is important in the case of imported data. It will<br>
> > ease the update of datasets that we bring in.<br>
> ><br>
> > Kate Chapman<br>
<div><div></div><div class="h5">> ><br>
> ><br>
> > On Oct 14, 2009, at 7:48 AM, Richard Weait <<a href="mailto:richard@weait.com">richard@weait.com</a>> wrote:<br>
> ><br>
> >> Sam removed that context, then spun this new thread and widened<br>
> >> distribution! Here's some context, Sam thinks uuids are uninteresting<br>
> >> and not useful in imported data. Michael, below, thinks uuids are<br>
> >> useful. Now the rest of the conversation in context.<br>
> >><br>
> >> On Wed, Oct 14, 2009 at 12:06 AM, Michael Barabanov<br>
> >> <<a href="mailto:michael.barabanov@gmail.com">michael.barabanov@gmail.com</a>> wrote:<br>
> >>> Hi Sam,<br>
> >>><br>
> >>> I'm not talking about keeping CODE=2270010. That's indeed not<br>
> >>> terribly<br>
> >>> useful. But UUIDs allow us to later<br>
> >>> match the imported features to potentially more complete Canvec<br>
> >>> datasets.<br>
> >>> Example: imagine next Canvec data comes in that also has name= for<br>
> >>> each<br>
> >>> park. If we keep UUIDs in imported data, it's trivial to write a<br>
> >>> script<br>
> >>> to implement a join between the two feature set based on UUID and<br>
> >>> update<br>
> >>> the OSM with park names.<br>
> >>><br>
> >>> We decided to keep UUID for NRN segments for similar reasons.<br>
> >><br>
> >> On Wed, Oct 14, 2009 at 12:39 AM, Sam Vekemans<br>
> >> <<a href="mailto:acrosscanadatrails@gmail.com">acrosscanadatrails@gmail.com</a>> wrote:<br>
> >>> Ok,<br>
> >>> as long as by 'us' you mean 'not me' :-)<br>
> >>> 'cause i dont know how to 'trivially' use UUID as a tool like that.<br>
> >>><br>
> >>> Have you tested that?<br>
> >>><br>
> >>> I can put a note on the readme.txt file, and on the wiki about it.<br>
> >>><br>
> >>> Do we have a seconder for this change? (its a BIG change)<br>
> >><br>
> >> A seconder, Sam? Here is a short list of those from talk-ca who<br>
> >> believe that a uuid is a good idea in a Canadian import:<br>
> >> You - <a href="http://lists.openstreetmap.org/pipermail/legal-talk/2009-March/002322.html" target="_blank">http://lists.openstreetmap.org/pipermail/legal-talk/2009-March/002322.html</a><br>
> >> Steve S - <a href="http://lists.openstreetmap.org/pipermail/talk-ca/2009-February/000705.html" target="_blank">http://lists.openstreetmap.org/pipermail/talk-ca/2009-February/000705.html</a><br>
> >> Michel - <a href="http://lists.openstreetmap.org/pipermail/talk-ca/2009-January/000612.html" target="_blank">http://lists.openstreetmap.org/pipermail/talk-ca/2009-January/000612.html</a><br>
> >> Austin - <a href="http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001223.html" target="_blank">http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001223.html</a><br>
> >> James - <a href="http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001138.html" target="_blank">http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001138.html</a><br>
> >> me - <a href="http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001293.html" target="_blank">http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001293.html</a><br>
> >><br>
> >> _______________________________________________<br>
</div></div>> >> Imports mailing list<br>
> >> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
> >> <a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
> ><br>
> > _______________________________________________<br>
> > Imports mailing list<br>
> > <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
> > <a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
> ><br>
><br>
> _______________________________________________<br>
> Imports mailing list<br>
> <a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/imports" target="_blank">http://lists.openstreetmap.org/listinfo/imports</a><br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-ca" target="_blank">http://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</div></div></blockquote></div><br>