[Talk-ca] Import of large features in Canvec

Tue Jan 26 02:14:23 GMT 2010

Hi,

On Mon, Jan 25, 2010 at 4:08 PM, Frank Steggink <steggink at steggink.org>wrote:

> Hi Sam,
>
> Thanks for your feedback. I agree with your suggestion to remove the ID. It
> is simply unmaintainable by us. I also saw that many of them were the same.
> This was already before my script started splitting large areas up.
>
> The addition of canvec:sourceDate (valdate in the DB) is a good idea as
> well. Since it is an 8 char string, I'll leave it untouched. (Shp2osm.jar
> should strip any spaces though.) Note that the validation date of the wooded
> areas in the area I uploaded is "1982".
>
> By the way, should the source reflect the current year (2010)? I don't
> think this is necessary, since the import was started in 2009, although not
> much progress has been made so far.
> ai
>

Well, the 2010 import is going to be different, as it uses the python script
and will contain less bugs.   By changing it to this year, we can note in
the wiki that the 2009 imported data has 'known potential errors' and we can
list those.   So when people come across data that was imported in 2009,
these errors will be expected, and its known that it can be directly
replaced with the 2010 data.

Similar to the way the TIGER data in the US is treated.  A simple search in
the area for "CanVec_Import_2009" then it can be directly compared, using
open jump to new data.

Perhaps we can go even further, and somehow indicate which canvec data
version was used, as right now the latest version is 5.0
http://geogratis.cgdi.gc.ca/geogratis/en/collection/28954.html where it is
only certain datasets that have that version #, the rest have version 4.0
etc or earlier.   As when an update happens (it might only be a few features
changed) the entire NTS tile is upgraded to the next version.)
This information is ALSO in the dataset.   So perhaps "source:version=5.0"?

And on that note, in order to keep up with the changes in the canvec
datasets, we will need to introduce (appropriatly named) "CanBots".  These
will be programed to automatically download & convert & replace in touched
areas.
Fortunately this might not be needed, since OpenStreetMap has the advantage,
because we can work directly with the communities on the ground who can
donate their data directly to the database (as well as back to NRCan & the
provincial data compilers).

So in sum, i answered my own question.  Having the latest canvec dataset
version isn't needed. Just  "CanVec_Import_2010" would be fine :-)

Cheers,
Sam

Cheers,
>
> Frank
>
> Sam Vekemans wrote:
>
>> http://www.openstreetmap.org/browse/relation/393821
>>
>> attribution = Natural Resources Canada
>> canvec:CODE = 1240022
>> canvec:UUID = cad1acc2f7794480a0c17cadeef4d3b7
>> natural = wood
>> source = CanVec_Import_2009
>> type = multipolygon
>>
>>
>> That looks fine.  I would remove that canvec:UUID tag as since now it is
>> in the database it is free to edit, and to what we wish to.   But that's
>> just me.   BTW, in the USA Tiger data, the UUID was removed as it has a
>> 'power fit' where it was treated as more valuable than regular users edits.
>>   That part (power fit) is not acceptable with OpenStreetMap.
>>
>> The canvec:sourceDate=* should be added (it available in the datasource)
>> since that tells the users how old the data is and gives them a way to
>> compare the data with their own datasets (ie. from municipalities directly)
>> or from physical observations.  Change on the ground happens so fast that
>> it's important to have it on all features.
>>
>> Its worth no note that this 'wooded_area' is simply just that, it has no
>> boundaries, it just states "at the time of surveying, this area has trees,
>> and the wholes (inner polygons) dont have trees".  This 'wooded area' is not
>> a designated area, so it's neithor a park/private land/protected area. When
>> you look at the yahoo imagery (and future imagery) you can easily see what
>> the currently status of the 'wooded_area' actually is.  But on the ground,
>> you'll see what it's like today.
>>
>> So in sum, when your out mapping, feel free to adjust the edges of these
>> polygons to accurately show where in fact the 'wooded_area' is today.   And
>> if you know what the designation of the area is. ie. signs that say park
>> area, you can add that in as an unfilled polygon border.
>>
>> Great to see no edges, nice fix.
>>
>> Cheers,
>> Sam
>>
>>
>> On Sun, Jan 24, 2010 at 7:59 PM, Frank Steggink <steggink at steggink.org<mailto:
>> steggink at steggink.org>> wrote:
>>
>>    Hi all,
>>
>>    Today I have (finally) worked on large features in Canvec data
>>    (forests,
>>    water, etc.), and I have come up with a method how to deal with them.
>>    This currently involves PostGIS, but maybe I'll use GEOS or another
>>    method, so that it isn't necessary to load data in a DB. More details
>>    will follow soon, since I need to clean up code / sort out things
>>    a bit,
>>    and eventually integrate it into the canvec_to_osm.py script.
>>
>>    Right now I've uploaded (only) wooded areas in the Charlevoix
>>    region in
>>    Quebec. This already makes the map look entirely different! The result
>>    can be found here [1]. Changesets: [2] and [3].
>>
>>    You'll see faint horizontal and vertical lines crisscrossing the area.
>>    This is an artifact of making the features smaller (0.1 x 0.05
>>    degrees).
>>    This will be dealt with with the "gamma" option which is part of
>>    the new
>>    Mapnik 0.7.0 release. This will probably be used in a couple of
>>    weeks on
>>    osm.org <http://osm.org>. See [4] for more info.
>>
>>
>>    Cheers,
>>
>>    Frank
>>
>>    [1]
>>
>> http://www.openstreetmap.org/?lat=47.625&lon=-70.25&zoom=11&layers=B000FTFT
>>    <
>> http://www.openstreetmap.org/?lat=47.625&lon=-70.25&zoom=11&layers=B000FTFT
>> >
>>    [2] http://www.openstreetmap.org/browse/changeset/3707953
>>    [3] http://www.openstreetmap.org/browse/changeset/3708062
>>    [4] http://trac.mapnik.org/wiki/PolygonSymbolizer
>>
>>
>>    _______________________________________________
>>    Talk-ca mailing list
>>    Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>>
>>    http://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20100125/da8c5382/attachment.html>