[Talk-ca] canvec2osm v0.30 with more GeoBase/CanVec reference

[Steve Singer]

On Thu, 7 May 2009, Sam Vekemans wrote:

> and here is the latest rules.txt file
> http://docs.google.com/Doc?docid=d2d8mrd_179gnhs54cw&hl=en
>
> I made a few changes, for example.
>

> You can see that it looks closer to what the canvec catelogue has listed.
> So rather than weeding through the wiki, the definition of the tag is
> available in the data.
> With over 300 map features, having the original entity & value listed, it
> makes it easier for people to go down to the last 2 tags and change it where
> needed.

I don't like this including the category definitions as part of the data. 
In normal OSM land we would just tag an area as "landuse=residential", we 
wouldn't copy the wiki text landuse:description="For areas of land used 
by people. For natural areas, see....".

This is exactly what your doing with the canvec:entity_definition="....."

It fills your database with duplicate data this means that

A. Your database is a lot larger than it needs to be.  I like being able to 
store all the OSM data for canada on my cellphone.

B. Let's say want to edit or translate that definition.  You'd have to edit 
thousands of tags versus just 1 wiki entry.  There is a concept in database 
design called normalization.  Part of this is you try to eliminate 
duplicated data in favor of pointers to a common location.

C. The canvec:entity=Residential value is secondary to the OSM tag of 
landuse=residential. Once the data is in OSM the renderer (and other 
programs) will be driven by the OSM tagset.



If you want your editor to automatically fetch+display the definition then 
you should get your editor to do that not add the definition to thousands of 
data elements

>
> The process for this import (IMO) will be slowly and steadily. .. I'd like
> to make sample areas for many parts of the country (as i did before) so
> people can go through the data and check and see what tags i used, and if
> they need to be changed.
>
> Ideally, this CanVec data will ONLY  get imported to areas that have ALREADY
> been filled in with GeoBase Roads. .. So Im asking for feedback, is it a
> good idea to include the CanVec roads, so they can be used to trace where
> needed?

One of the problems I am have when you send out a .zip file with over 100 
layers and ask for feedback  is knowing where I should concentrate the 
limited time I have for review.   If you decide that a particular layer 
isn't going to be imported then its better to not include them in the .zip 
so people don't spend time reviewing them.

I wonder if you might get a better response working feature type by feature 
type.   I think you will find that some features are non-controversial, 
don't have regional variations and are unlikely to conflict with huge 
amounts of existing data.   These can be imported nationwide without a lot 
of pain.

Then you can move onto some of the more complicated features

Some of the features that I suspect will be easier to import include: Radar 
and radio antennas, historic crosses, power sub-stations.







>
> Anyway, Im still working on minor tweaks, and corrections.
>
> Let me know if you want a sample area for where you are.
>
> Thanks,
> Sam Vekemans
> Across Canada Trails
> P.S. I also sent this message to GeoBase, as im wondering if and when the
> next update of the GeoBase/CanVec data will be, and what kind of changes to
> expect.
>