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

[Kevin Farrugia]

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.

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.

-Kevin (Kevo)


On Wed, Oct 14, 2009 at 12:16 PM, Michael Barabanov <
michael.barabanov at gmail.com> wrote:

> 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
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20091014/2814d2b7/attachment.html>