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
