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

[Michael Barabanov]

While this can indeed happen in many cases, Canada is so huge that I
expect large areas to be left as is, and not have this problem.  Even for densely populated
areas like Vancouver, the rate of changes isn't all that high right now.

Michael.

On Wed, Oct 14, 2009 at 05:03:27PM +0100, Andy Allan (gravitystorm at 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
> 
> On Wed, Oct 14, 2009 at 1:09 PM, Kate Chapman <kate at maploser.com> wrote:
> > I also think UUID is important in the case of imported data. It will
> > ease the update of datasets that we bring in.
> >
> > Kate Chapman
> >
> >
> > On Oct 14, 2009, at 7:48 AM, Richard Weait <richard at weait.com> wrote:
> >
> >> Sam removed that context, then spun this new thread and widened
> >> distribution!  Here's some context, Sam thinks uuids are uninteresting
> >> and not useful in imported data.  Michael, below, thinks uuids are
> >> useful.  Now the rest of the conversation in context.
> >>
> >> On Wed, Oct 14, 2009 at 12:06 AM, Michael Barabanov
> >> <michael.barabanov at gmail.com> wrote:
> >>> Hi Sam,
> >>>
> >>> I'm not talking about keeping CODE=2270010. That's indeed not
> >>> terribly
> >>> useful. But UUIDs allow us to later
> >>> match the imported features to potentially more complete Canvec
> >>> datasets.
> >>> Example: imagine next Canvec data comes in that also has name= for
> >>> each
> >>> park. If we keep UUIDs in imported data, it's trivial to write a
> >>> script
> >>> to implement a join between the two feature set based on UUID and
> >>> update
> >>> the OSM with park names.
> >>>
> >>> We decided to keep UUID for NRN segments for similar reasons.
> >>
> >> On Wed, Oct 14, 2009 at 12:39 AM, Sam Vekemans
> >> <acrosscanadatrails at gmail.com> wrote:
> >>> Ok,
> >>> as long as by 'us' you mean 'not me' :-)
> >>> 'cause i dont know how to 'trivially' use UUID as a tool like that.
> >>>
> >>> Have you tested that?
> >>>
> >>> I can put a note on the readme.txt file, and on the wiki about it.
> >>>
> >>> Do we have a seconder for this change? (its a BIG change)
> >>
> >> A seconder, Sam? Here is a short list of those from talk-ca who
> >> believe that a uuid is a good idea in a Canadian import:
> >> You - http://lists.openstreetmap.org/pipermail/legal-talk/2009-March/002322.html
> >> Steve S - http://lists.openstreetmap.org/pipermail/talk-ca/2009-February/000705.html
> >> Michel - http://lists.openstreetmap.org/pipermail/talk-ca/2009-January/000612.html
> >> Austin - http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001223.html
> >> James - http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001138.html
> >> me - http://lists.openstreetmap.org/pipermail/talk-ca/2009-June/001293.html
> >>
> >> _______________________________________________
> >> Imports mailing list
> >> Imports at openstreetmap.org
> >> http://lists.openstreetmap.org/listinfo/imports
> >
> > _______________________________________________
> > Imports mailing list
> > Imports at openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/imports
> >
> 
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/imports