[Talk-ca] Canvec import issues

Wed Aug 22 17:29:33 BST 2012

* Select child selected, add to selection
Forgot to add type:way. So, in JOSM type in "child selected type:way", 
and check the radio button Add to selection.

Frank

On 22-8-2012 17:59, Frank Steggink wrote:
> Hi Daniel, Pierre,
>
> It is possible to reuse ways in the OSM datamodel, as you know. It is 
> also possible to do this, while having to make extracts later. For 
> example, when you only want to select lakes, you should do the 
> following in JOSM:
> * Select natural=water, replace selection
> * Select child selected, add to selection
> This way you have all lakes, including multipolygon ones with islands. 
> Note that the islands could have tags applied on them as well. You can 
> deal with them after you've copied the data to another layer.
>
> Anyways, unfortunately it is not possible to have ways being reused 
> easily with JOSM. At least not with standard JOSM or the Validator 
> tool. Perhaps there is a plug-in. I haven't looked into that. However, 
> if this functionality were to be implemented, it could easily open a 
> new can of worms. Sometimes it also happens that functionality is 
> revised (wholly or partially). For example, that is the case with 
> "unclosed ways". Now it isn't possible to merge duplicate nodes with 
> the Validator tool. With all the crossing address interpolation ways 
> and streams, I need to merge them manually tens of times per sheet, 
> sometimes even up to a hundred times. (Probably not much more, because 
> sheets are being split up farther in crowded, residential areas.)
>
> History also shows that everyone has his own standards, even amongst 
> all the people who have imported Canvec data. However, that is an 
> entirely different discussion...
>
> Frank
>
> On 21-8-2012 22:49, Daniel Begin wrote:
>>
>> 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 <mailto: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
>