If you read the thread a bit more, you'll see that I'm exactly for including UUIDs during import:)
My message you've replied to was trying to address the concern of UUIDs being mangled during subsequent editing. Michael. On Wed, Oct 14, 2009 at 02:22:16PM -0400, Kevin Farrugia (kevinfarru...@gmail.com) wrote: > 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.baraba...@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 ( > > 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 > > > > > > On Wed, Oct 14, 2009 at 1:09 PM, Kate Chapman <k...@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 <rich...@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.baraba...@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 > > > >> <acrosscanadatra...@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@openstreetmap.org > > > >> http://lists.openstreetmap.org/listinfo/imports > > > > > > > > _______________________________________________ > > > > Imports mailing list > > > > Imports@openstreetmap.org > > > > http://lists.openstreetmap.org/listinfo/imports > > > > > > > > > > _______________________________________________ > > > Imports mailing list > > > Imports@openstreetmap.org > > > http://lists.openstreetmap.org/listinfo/imports > > > > _______________________________________________ > > Talk-ca mailing list > > talk...@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-ca > > _______________________________________________ Imports mailing list Imports@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports
