[Talk-ca] Canvec import issues

Frank Steggink steggink at steggink.org
Tue Aug 21 18:32:27 BST 2012


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




More information about the Talk-ca mailing list