[Talk-ca] Canvec import issues

Thu Aug 23 02:52:12 BST 2012

I see the problem as being the importing of everything as being the problem,
not the geometric model :)

From: Daniel Begin [mailto:jfd553 at hotmail.com] 
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; talk-ca at 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-gps at yahoo.fr] 
Sent: August-21-12 16:04
To: talk-ca at 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 <steggink at steggink.org>
À : talk-ca at 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
<http://www.openstreetmap.org/?lat=46.1749&lon=-74.5535&zoom=14&layers=M>
&lon=-74.5535&zoom=14&layers=M
[2]
ftp://ftp2.cits.rncan.gc.ca/pub/canmatrix2/50k_tif/031/j/canmatrix2_031j02_t
if.zip

_______________________________________________
Talk-ca mailing list
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/20120822/e8b376b1/attachment.html>