2009/6/17 Sam Vekemans <[email protected]>: > Answered below, > > Twitter: @Acrosscanada > Facebook: http://www.facebook.com/sam.vekemans > > > On Wed, Jun 17, 2009 at 4:57 AM, "Marc Schütz" <[email protected]> wrote: >> >> > I think the definitions really don't belong in the the data -- perhaps >> > if you want to see them, your browser should look them up in some >> > table rather than load from the data. >> >> +1 >> >> It should be sufficient to keep the canvec:UUID, source and attribution >> tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we >> would need most of the others. If someone is really interested in them, they >> can look them up in Canvec using the UUID. > > Actually, its not that easy to look up a source with the uuid from CanVec > data. > They would need to open up the shp files and sift through the data. > Unfortunately the canvec data isn't organized to that extreem on their > website.
You don't need to look it up in the shp files, you can have it in a huge xml file or somewhere else because it's a trivial 1:1 conversion. The point is that the definition of what is a school (not the particular school to which the tag is attached) belongs in an encyclopaedia, not in a database of geographic data. The school object on the map is already fully defined by "amenity=school", now, if you want to interpret this you need to look it up in the Map_Features page or an encyclopaedia or in 99% cases from your prior knowledge. > The purpose of keeping the uuid is that it might be used during > the conversion process to compare old/new canvec data. Other than that, the > "source" tag is really the only one that is technically needed. > > > Arguments to keep all original tags as available. > > When importing large amounts of data, not only are we importing the data, > but also opening the door to all of the users of that data, who now have a > 2nd choice of where to extract the data (cloudmade provides shp files of OSM > data) > So now, users of geogratis data, can turn to OSM, where they can now see the > value of working WITH the data. For example, a federal parks manager, who > would turn to geogratis to get a basemap, can now use OSM, as the map is > more accurate. > However, because government is a stickler for 'official source' we can > provide the source tags, that anyone can go to geogratis and varify the > detail. > > This is a fair trade off, as not only am i copying the data, i am providing > an accurate 'carbon' copy of the origional source. > > In order to be 'sync' with the import data, it all needs to be there. (All > or none?) > > I think this is a fare tradeoff, as it lets us have are cake, eat it, AND > also share it with more types of data users. (where a certain other map, > doesnt do this) ... (ie if BC Parks decides do donate their 'official' > property boundaries) they too could include their back-end cross referencing > system, and ALSO include osm standard tags) > > Arguments against: > -This is OpenSTREETMap where we only provide ways with names, and make > relations and add things that end users want. > > But, an end-user can also be a city planner who is thinking of sharing all > there origional survay data, and property boundary information. Provided > they can also include lot numbers, and official property easment. > > If there is an unlimited number of tags alloud, why not keep them? > > If i remove SOME and not ALL, where do we draw this line in the sand? > > I think we need to make it clear on a global level, exactly WHAT should be > included or omited with an import. (any builk import for that matter) It's quite clear, I think: - include things that carry some new information (e.g. amenity=school) - omit things that are redundant, because they can be inferred from other tags on the object or from an external, non-geographic database (the definition of a building, school, road) There's a 1:1 correspondence between the value of amenity= and the value of canvec:value_definition= so one of them should be removed. There's a 1:1 correspondence between the value of canvec:entity= and the value of canvec:entity_definition= so one of them should be removed. For example, let's say you're making a database of large prime numbers. For each entry you could store the prime number N, some kind of proof of why it's a prime or a method of deriving the number, the name of the discoverer, but not: - the definition of a prime number (redundant), - N+1 (redundant), - N^2 (redundant), > > If you dont like it because it looks like 'clutter', but infact its useful. > .. i dont know if thats a strong argument. > > Perhaps I think we need to find a former Geogratis user, who will now be > using OSM. And find out just how useful there tags are. (as im not one, my > voice is rather quite) > > Right now the evedence to keep all the tags is not that great. ... > > The process of removing these tags is not small. So a definate answer > should be found before i continue with more importing :) > > > >> >> created_by should be removed, too. This is better moved into the >> changeset. One could even argue that "source" belongs there, too. > > Well 'cause its not only me uploading, it can be anyone who wants to use the > canvec2osm script, you dont need to be logged in with geobase:username. ... > because your only importing a few features that you want. ... and there's > no way to control what gets typed into the changeset. Would be nice if > everyone followed what im doing. ... but not possable. > The created_by tag of 'canvec2osm' so people know it was my (crappy script) > that made the mess :), so they can turn to me, and go to the canvec2osm wiki > page to try to figure out how to fix problems. > >> >> Regards, Marc >> >> -- >> GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss >> für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 > > Cheers, > Sam Vekemans > Across Canada Trails > _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
