[Talk-ca] Canvec import issues

Thu Aug 23 08:44:37 BST 2012

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 <belasmp at yahoo.fr>:
>
>> David and Paul, do you think this was the problem with these imports???
>>  
>> Pierre
>>
>>
>>
>>> ________________________________
>>> De : David E. Nelson <denelson83 at yahoo.ca>
>>> À : Paul Norman <penorman at mac.com>; "talk-ca at openstreetmap.org"  
>>> <talk-ca at 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 <penorman at mac.com>
>>> To: 'Daniel Begin' <jfd553 at hotmail.com>; 'Pierre Béland'  
>>> <infosbelas-gps at yahoo.fr>; talk-ca at 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: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&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 at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-ca
>>> _______________________________________________
>>> Talk-ca mailing list
>>> Talk-ca at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>>
>>> _______________________________________________
>>> Talk-ca mailing list
>>> Talk-ca at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>>
>
>