Yeah, don't just do blanket imports. Just import whatever data OSM *does not*
have.
- David E. Nelson
________________________________
From: Paul Norman <[email protected]>
To: 'Daniel Begin' <[email protected]>; 'Pierre Béland'
<[email protected]>; [email protected]
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:[email protected]]
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; [email protected]
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:[email protected]]
Sent: August-21-12 16:04
To: [email protected]
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 <[email protected]>
À : [email protected]
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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
