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

andrzej zaborowski balrogg at gmail.com
Fri Jun 19 23:38:20 BST 2009


2009/6/20 Ian Dees <ian.dees at gmail.com>:
> In my opinion, the only data that should be imported as tags on geographic
> features in the OSM database is the data in the "OSM Tags" column on the
> "Buildings and structures" page. The other columns of data should not be
> included as tags.

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.

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 (i.e. what the "Buildings and structures" chart
attempts to do) is never unambiguous, it's like a conversion from
fixed-point to floating-point representation (it introduces rounding
errors) or a translation from french to english ("lost in
translation"?).  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.

I also need to relate to Sam's argument that in the future people may
demand that the data in the database be more readable and
self-explanatory.  I think you wrongly think that the bus / train
route and schedule planners will be looking at the raw data from the
database, I think that's a flawed assumption.  If they even get near
OSM it will be only through a specialised editor that will convert
human readable (pretty icons, buttons etc) into machine readable and
back (OSM tags).  The user never gets to see the OSM tags, so there's
no point making them self-explanatory.

Cheers




More information about the talk mailing list