Thanks, (also cc'd to main talk list, as discussion is relevent to everyone) :)
I have the sample area with more features listed. http://www.openstreetmap.org/?lat=48.9518&lon=-125.5153&zoom=12&layers=B000FTF I notice that the label for the island 'Kvarno Island' looks a little out of place (on the Osmarender), but once other name tags gets shown, it might look better. .. or the admin_level tag needs to be added. On Tue, May 12, 2009 at 4:56 AM, Richard Weait <[email protected]> wrote: > On Tue, 2009-05-12 at 01:02 -0700, Sam Vekemans wrote: > > Hi all, > > a quick question. (kind of) > > > > I think that having the tags that clearly define what the entity is; > > and how the entity is used in the source data, is something that needs > > to be kept. > > > > Here's why, it tells the user exactly what the feature is, and gives > > the user a better 'measuring stick' to decide for themselves which > > data to use; their own or this stuff. > > These definitions belong in the wiki and do not belong in the > database. > Humm, it belongs in a Clearly defined Wiki page. Something that also needs to be worked on. :) I think as a general rule. All features that are imported 300, are all listed on the appropriate wiki page. http://wiki.openstreetmap.org/wiki/CanVec:_Buildings_and_structures A second look at it, i think it looks fine (so far) The OSM tags are the only ones that can(should) (and actually probably will need to) change. If anyone wants to change the CanVec tags, well, they would need to re-import and compare the data. (which is only maybe needed 2x a year) > > Just as we do not, and should not, put instructions on how to use > Potlatch or josm inside the highway tag, we should not put these data > definitions in the CanVec tags. > I can remove the 'canvec:entity_definition=v" tag easily, however, i do think that "too much" really needs to be defined. As THESE definitions, define the source definition, and not actually the tag. ... OSM Tag definitons belong on the wiki, where CanVec tags belong on the NRCan website in the catelogue. (and can also be easily found). ... with a link on the wiki. > > Including the CanVec uuid is appropriate. Including the definition is > too much. Because the CanVec catalogue can change (but not so often), the wiki doesnt (cant) get updated at the same time. So can you expand further? Is it only the 'canvec:entity_definition' that should be removed? Or should more? The UUID tag could ALSO be found by looking at the origional data, then comparing with OSM data (in a postGIS database), pretending that the OSM data was made by users. Only the source=CanVec_Import_2009 tag needs to be visable, so people know where it came from. and the users contributions with the ID prefexed with 'geobase:' are identified, and isolated. Anyway, i have now loaded a sample of each feature available for this area :) and can EASILY delete the unnecessary tags :) I think there are a few more features available in the other 092c areas :) ... I'll load those once we got a clear definition of what 'enough is'. Technically, only 1 more set of canvec tags are available and havent been used. That is.. of "Minimum sizes:" with the following. -Specification code 1350042 -Area (Square meter) 500 -Lateral distance (Meter) 1.5 -Length (Meter) --- -Longitudinal distance (Meter) 3 -Right angle tolerance (Degree) --- -Spike angle tolerance (Degree) --- But i didn't add those, although i could have, and still might, if there is no reason not to. > > > Best regards, > Richard > > > > > Cheers, Sam
_______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
