<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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 <a href="http://wiki.openstreetmap.org/wiki/CanVec_OSM_Map_Features#Attributes_common_to_all_entities" target="_blank">http://wiki.openstreetmap.org/wiki/CanVec_OSM_Map_Features#Attributes_common_to_all_entities</a> page.</blockquote>

<div><br></div><div>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</div>

<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

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.</blockquote><div> </div><div>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. </div>

<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

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...</blockquote>

<div><br></div><div>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). </div>

<div><br></div><div>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. </div><div><ol><li>Make appropriate OSM tags and include it </li>

<li>Fork OSM to a project that does want to include as much data as possible</li></ol>And no one likes forks.</div><div><br></div><div>-Tyler</div></div>