Re: [OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy
2009/6/26 Sam Vekemans acrosscanadatra...@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 129 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.
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.
Dave
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy
On Fri, 2009-06-26 at 15:40 -0700, Sam Vekemans wrote: [ ... a lot of stuff ... ] The 5th, which is currently being debated canvec:CODE=1200020 - This is the [CanVec] feature identifier, [analogy removed]. So does anyone have objections to the logic and usefulness of canvec:CODE? Or any arguments for/against what I wrote above?.. And at the same time I'm recommending for all imports that this gets added (if it is available). [edits for readability] Sure, I object, Sam. :-) canvec:CODE only helps by making it easier for somebody to go back to the CanVec data. Ideally we want the data to just work in OSM so that an external reference is rarely required. Object that you selected for your example is instructive and I see why you are tempted to explain it further. Let's have a look at a CanVec 1200020 object. According to the wiki page[1] that you wrote based on the CanVec docs, 1200020 is a cartographic spot height. Here's one from a sample area in southern Ontario node id=-25 lat=43.42109989905811 lon=-80.4427889 tag k=attribution v=Natural Resources Canada/ tag k=source v=CanVec_Import_2009/ tag k=created_by v=canvec2osm/ tag k=canvec:CODE v=1200020/ tag k=canvec:UUID v=7c362dc87f31468193377634d3cdc78c/ tag k=name v=325/ tag k=ele v=325/ /node A name tag here is inappropriate. The name of this survey point is not 325, 325 is the elevation. Use man_made=survey_point[2]. That will be in step with accepted OSM usage, _and_ adds the context that helps OSM'ers decide how to use the data. Best regards, Richard [1] http://wiki.openstreetmap.org/wiki/CanVec:_Relief_and_landforms_(FO) [2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurvey_point ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy
On Sat, Jun 27, 2009 at 11:35 AM, Dave Stubbsosm.l...@randomjunk.co.uk wrote:
2009/6/26 Sam Vekemans acrosscanadatra...@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 129 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
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] CanVec:CODE vs. CanVec:UUID -relevancy
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 129 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).
Thanks,
Sam Vekemans
Across Canada Trails
Twitter: @Acrosscanada
Facebook: http://www.facebook.com/sam.vekemans
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
