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

Tyler tyler.ritchie at gmail.com
Sat Jun 20 00:37:27 BST 2009


>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090619/dfbde752/attachment.html>


More information about the talk mailing list