2009/6/20 Ian Dees <ian.d...@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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk