On Sat, Jun 27, 2009 at 11:35 AM, Dave Stubbs<[email protected]> wrote: > 2009/6/26 Sam Vekemans <[email protected]>: >> 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 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
