Hi Pierre,
In 2009 we had a meeting in Sherbrooke. This was in the day the Canvec
landuse was starting to run. Discussions were already going on on
talk-ca and the wiki pages for several months. Emilie Laffray joined the
meeting with Skype, and explained how the Corine Land Cover was handled.
While it seemed to be a nice way, it somehow disappeared from the radar.
Perhaps the Canadian community is too small, or everyone is too busy
with other things, like work, etc.
Regarding the duplicate ways, caused by lakes punched out of forests,
I'm considering to write a small tool. It would be a good opportunity to
learn about the frameworks for handling OSM data which have been
developed in the last couple of years. I won't distribute in public, but
people could ask for it once it is "ready". I will certainly make it
single purpose only, i.e. handling only data which has been tagged with
one of the Canvec source tags.
Regarding the WMS layer, I'll check out the URL. I guess you're
referring to the one listed here?
http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers
Here is my first and only attempt to replace Geobase NRN roads, which
haven't been touched by others, by Canvec roads:
http://www.openstreetmap.org/browse/changeset/11848571
Although copying names involves manual labor, checking and replacing
roads individually is also manual labor. Note that the sheet area is
only to the south and east of St. Zacharie. The bounding box is much
larger, since I split up Geobase roads at the boundary of the sheet.
Re. Route 117: it is called "Route 117" in Canvec. Probably it's best
known as "Route Transcanadienne" in this area. Near Quebec City the
highway is called Route Jean-Lesage, although it's also part of the
Trans Canada Highway.
Frank
On 23-8-2012 15:17, Pierre Béland wrote:
Frank,
The France OSM association has many developpers participating and uses
various tools including Osmosis to validate / correct data. If there
were some canadian developpers that want to develop something for
Canada ....
Personnally, I check names manually using Geobase Roads layer. This
layer contains the same road names has in the Canvec files. There are
surely better ways to systematically verify names. But it is a simple
way to do it.
I added this layer to JOSM Imagery sources and it is available from
WMS/TMS Preferences in the CA section of the available imageries.
Having Geobase roads layer as background layer, you can find rapidly
the road names. We have to zoom in to see the layer. We switch the
Data layer on and off to see easily the road names from the Geobase layer.
Looking at this area, I see that mappers have given name="Route
canadienne" to road 117 with NHS="yes" tag. Route canadienne goes from
Québec to Montréal and Toronto.
Pierre
------------------------------------------------------------------------
*De :* Frank Steggink <stegg...@steggink.org>
*À :* Béland Pierre <bela...@yahoo.fr>
*Envoyé le :* Jeudi 23 août 2012 2h06
*Objet :* Re: [Talk-ca] Canvec import issues
To be clear, I haven't done full imports. I haven't imported roads
or water, in order not to duplicate features. Water was previously
imported by Yan Morin in 2009 (Geobase NHN data), and roads were
either drawn by users, or a result of the Geobase NRN import. In
case of water, I only have added a few streams which were missing.
One of the issues is that certain ways are duplicated, because of
multipolygon holes. That's why I'm gauging your thoughts about it,
because I don't see that as an issue myself. Perhaps we could come
up with a proper way how to deal with it.
Another issue which is bothering myself for a long time is the
fact that Geobase NRN roads don't have road names in Quebec. Road
names are present in Canvec now. Replacing them manually is a
tedious task. I have thought about it for quite some time, but I
can't come up with a better procedure, offering the same quality.
I also have considered writing tools for them. Any
(semi-)automated tools have an inherent risk, particularly because
it's hard to guarantee they will still do a proper job, given the
diversity in OSM data.
Frank
Quoting Béland Pierre <bela...@yahoo.fr <mailto:bela...@yahoo.fr>>:
> David and Paul, do you think this was the problem with these
imports???
>
> Pierre
>
>
>
>> ________________________________
>> De : David E. Nelson <denelso...@yahoo.ca
<mailto:denelso...@yahoo.ca>>
>> À : Paul Norman <penor...@mac.com <mailto:penor...@mac.com>>;
"talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>"
<talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>>
>> Envoyé le : Mercredi 22 août 2012 21h59
>> Objet : Re: [Talk-ca] Canvec import issues
>>
>>
>> Yeah, don't just do blanket imports. Just import whatever data
OSM *does not* have.
>>
>>
>>
>> - David E. Nelson
>>
>> ________________________________
>> From: Paul Norman <penor...@mac.com <mailto:penor...@mac.com>>
>> To: 'Daniel Begin' <jfd...@hotmail.com
<mailto:jfd...@hotmail.com>>; 'Pierre Béland'
<infosbelas-...@yahoo.fr <mailto:infosbelas-...@yahoo.fr>>;
talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>
>> Sent: Wednesday, August 22, 2012 6:52:12 PM
>> Subject: Re: [Talk-ca] Canvec import issues
>>
>>
>> I see the problem as being the importing of everything as being
the problem, not the geometric model :)
>>
>> From:Daniel Begin [mailto:jfd...@hotmail.com
<mailto:jfd...@hotmail.com>]
>> Sent: Tuesday, August 21, 2012 1:49 PM
>> To: 'Pierre Béland'; talk-ca@openstreetmap.org
<mailto:talk-ca@openstreetmap.org>
>> Subject: Re: [Talk-ca] Canvec import issues
>>
>> Bonjour Pierre,
>>
>> The Canvec Geometric Model is explained in the following OSM
wiki page ...
>> http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model
>>
>> The model was adopted after discussions with the community. The
model was designed to simplify the import of a selection of
features by the contributors, instead of imposing import the
entire contents by them.
>>
>> However, history now shows that the community usually imports
the entire content.
>> Compromises always bring pros and cons.!-)
>>
>> Best regards,
>> Daniel
>>
>>
>> ________________________________
>>
>> From:Pierre Béland [mailto:infosbelas-...@yahoo.fr
<mailto:infosbelas-...@yahoo.fr>]
>> Sent: August-21-12 16:04
>> To: talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>
>> Subject: Re: [Talk-ca] Canvec import issues
>>
>>
>> I didn't do Canvec imports too much. Looking at various lakes
in wooded areas, I now realize that Canvec imports are often
(always?) duplicating lakes. I do'nt know what was the reason to
create these duplicate ways in the Canvec import file. Should we
duplicate the lakes to apply a inner role in the relation? Is this
a reason for that? Or could we instead simply use the existing
lake with a inner role in the wooded area polygon relation?
>>
>> Pierre
>>
>> ________________________________
>>
>> De :Frank Steggink <stegg...@steggink.org
<mailto:stegg...@steggink.org>>
>> À : talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>
>> Envoyé le : Mardi 21 août 2012 13h32
>> Objet : [Talk-ca] Canvec import issues
>>
>> Hi,
>>
>> Today I was contacted by someone inquiring (with a somewhat
hostile tone) after the Canvec import I've done over the weekend
northwest of Montréal. He was not really happy with the way how
the import has handled. The way the Canvec data is currently
provided, leaves some room for improvement. I'm not sure if all
his issues have been discussed in the past (since I haven't
followed all Canvec discussions, especially in the beginning), but
I could see some merit in some of the point.
>>
>> Some examples he provided come from the Mt. Tremblant area [1].
Note that the lakes (and most of the streams) were imported
previously by someone else, based on NHN data, but the same issue
plays with the Canvec data itself. (This left me to the task to
leave the Canvec lakes out of the upload, as well as most streams.)
>>
>> On the left you see Lac Ouimet. He
> mentioned that a large part of the ways are duplicated. The
outer boundary of the wooded area is a separate polygon from the
lake itself. However, Lac Gauthier on the right is a different
case. This lake has been "cut out" from the woods, and I left the
inner boundary intact. JOSM is not complaining about this. Since
dealing with multipolygons remains a sticky issue, I have not done
that. I think it would be better to take care of these issues with
some tool. Although using a tool is considered "dangerously" (and
rightfully so!), dealing with multipolygons is prone to errors as
well.
>>
>> Another issue is that some lakes do not have names, but contain
a separate node (not part of any of the ways) with natural=water
and name=* tags. I can only assume that this comes from the source
data. In many cases it is hard to determine the extent of the
lake, since it can gradually taper into a river. This was not
mentioned directly by the user, but I
> thought he was referring to this.
>>
>> His issue turned out to be somewhat different. There is a place
node near Lac Gauthier, with the same name. I explained to this
that this must be the name of a hamlet. The non-official tag
"place=locality" is probably due to this confusion. This name is
also visible on the original topo map [2].
>>
>> Furthermore he noticed that I have duplicated his address nodes
and ways. This was an omission, so I have corrected this. I scan
the existing data in order not to duplicate existing features. Of
course this is prone to errors as well, especially in a large area
which is void of address nodes and ways, except for two ways
around a lake...
>>
>> I'm not asking anyone for "solutions". I can easily think about
them as well, but that doesn't make the problem go away. Thinking
about the solution is the easiest part, but working it out and
implementing it is much more difficult. It is more than simply
typing in some code
> and then run it over the data. Instead of doing that, I have
tried to explain him something about the hybrid data model OSM is
using (not purely geographical, but also not purely topological).
And of course there is also the gap between idealists and
realists. I see the current state of OSM as the status quo, so I
take it for granted. I think that Canvec falls within that status
quo situation as well, otherwise the OSM data offered by NRCan
would have looked differently, after all those years of
discussions and reviews.
>>
>> I have invited this user to discuss the issues he found on
talk-ca. I think that would be much more constructive than having
him directing all those issues to me, since they occur far beyond
his own backyard as well...
>>
>> Regards,
>>
>> Frank
>>
>>
>> [1]
http://www.openstreetmap.org/?lat=46.1749&lon=-74.5535&zoom=14&layers=M
>> [2]
ftp://ftp2.cits.rncan.gc.ca/pub/canmatrix2/50k_tif/031/j/canmatrix2_031j02_tif.zip
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> http://lists.openstreetmap.org/listinfo/talk-ca
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> http://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
>> http://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
