[OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy

[Matt Amos]

On Sat, Jun 27, 2009 at 11:35 AM, Dave Stubbs<osm.list at randomjunk.co.uk> wrote:
> 2009/6/26 Sam Vekemans <acrosscanadatrails at gmail.com>:
>> Hi all,
>> Im sending it out to everyone, as its of international significance when
>> dealing with bulk data.
>>
>> The 4 general tags
>> attribution=Natural Resources Canada
>> - tells the users what agency it came from (public/private)
>>
>> created_by=canvec2osm
>> - tell the user what program was used to create it. ... ie. blame me if the
>> script doesnt work or is wrong.
>>
>> source=CanVec_Import_2009
>> -tells the user what import project session it is ... ie. next year we might
>> do an import again for the updates.
>>
>> canvec:UUID=11CF43756692E5F4E0409C8467120387
>> - is the 'lot number / series and actual product identifier, more detailed
>> than the bar code (' which tells the user the identity of each node/way/area
>> they are looking at.
>>
>> The 5th, which is currently being debated
>> canvec:CODE=1200020
>> - This is the feature identifier, the SKU (Stock keeping unit) or the BIB
>> (Library catelogue number).  This tells the user which
>> Library/floor/section/shelf/book/page number that they are looking at.  When
>> the UUID identifies each character on the page.
>> Not having this CODE, would be like going to the library and asking if they
>> have a word in a book of 11CF43756692E5F4E0409C8467120387, when the CODE is
>> human-readable.  The 0 at the end means its a NODE a 1 - means a way and a 2
>> means an area. The 120 at the begining means it's part of the 1200009 series
>> of features.  and the '2' means it's the 2nd feature type in the set.
>> Like identifing 2 identical books, 'Times Atlas' where they has different
>> UUID's, but the same Catelogue code.
>>
>> So does anyone have objections to the logic and usefullness behind me
>> keeping canvec:CODE?  Or any arguments for/against what i wrote above?..
>> And at the same time im recommending for all imports that this gets added
>> (it its available).
>>
>
> Where are these tags going?
> Some definitely belong on changesets (there's no way
> source=CanVec_Import_2009 needs to be on every object when it's the
> same for everything you upload), whereas the UUID looks like it should
> be on the objects themselves.

+1

the attribution, source and created_by tags should definitely go on
the changeset, if possible.

the UUID might even be going too far. what happens when someone edits
a node with a UUID on it? is it still, for any useful purpose, the
same node?

> Also I'm a bit confused about what this CODE is. Is it about finding
> the feature, or about telling you what the feature is? If it's just
> what the feature is then it's possibly redundant. If it's about
> finding it, then is it likely to be the same for all elements of an
> upload? -- in which case it can also go on the changset.

+1

if CODE is common for each upload (or at least the non-feature-type
part of it) then it would save a lot of time, bandwidth and space to
put it on the changeset.

cheers,

matt