[OSM-talk] Voting CanVec OSM Map Features: Attributes common to all entities

Sam Vekemans acrosscanadatrails at gmail.com
Sun Jun 21 05:53:42 BST 2009


Hi all,
I'm trying to get a definative answer for all the tags.
So far so good. :-)
it looks like its unanaimous that the 'canvec:description' tags get removed.
So thats cool, its not that hard to remove those tags. :)

Any comments about the other tags, why they should be removed or kept?

Im sure many tags CAN be removed, we just need to clearly post on the wiki why.

Im now adjusting the script so that all the tags get stored gzipped in
a folder, so it can be used if needed as a backup.

Thanks,
Sam

On 6/19/09, Tyler <tyler.ritchie at gmail.com> wrote:
>>
>> Out of the "Buildings and structures" page, yes, there is however
>> more useful information in CanVec that I think has a place in OSM
>> too, beside the obvious (name, name:fr, etc) on the
>> http://wiki.openstreetmap.org/wiki/CanVec_OSM_Map_Features#Attributes_common_to_all_entities
>>  page.
>
>
> Yes, what Andrzej (how is that pronounced?) said. Though I would also
> include the Attribute code on the buildings and structures page (and
> equivalent codes elsewhere). With just a canvec:attribcode= that could then
> be referenced to a database of features
>
> So the original CODE would be good for reference and does not introduce
>> redundancy in the data.  However, converting it to 4 different tags in
>> osm
>> does add redundancy.
>
>
> Agreed, same essential reasoning as above. It's not really that difficult
> to
> pull together multiple data sources if you can easily cross reference
> datasets. There aren't tags in the database like 'building_desc="a man-made
> structure used for housing people and objects"' for good reason: they
> aren't
> necessary and it can be cross-referenced.
>
> Information such as the year and technique of acquisition (VALDATE, AQTECH)
>> is what the "source=" tag is sometimes used for in OSM.  I'd even include
>> the CanVec code (CODE) because the mapping from one tagset to another...
>
>
> Agreed, with reservations. There's no reason to lose information, but is
> that information encoded in anything else already like the object code or
> source?. To me canvec:Theme seems especially redundant (with the exception
> of water saturated soils) if there were a translation rule that was
> followed
> to go from canvec:Theme to standard OSM key:value pairs then it's
> unnecessary and redundant and no data is lost in the transition (you could
> always go back and re-create the canvec theme).
>
> Finally, if we don't want the extra information that is clearly in canvec
> (and other data sources) with no OSM analogues I feel there are two ways to
> resolve it.
>
>    1. Make appropriate OSM tags and include it
>    2. Fork OSM to a project that does want to include as much data as
>    possible
>
> And no one likes forks.
>
> -Tyler
>


-- 
Twitter: @Acrosscanada
Facebook: http://www.facebook.com/sam.vekemans




More information about the talk mailing list