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

Andy Allan gravitystorm at gmail.com
Wed Oct 14 17:03:27 BST 2009


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
>




More information about the Imports mailing list