Frank,
The France OSM association has many developpers participating and uses various
tools including Osmosis to validate / correct data. If there were some canadian
developpers that want to develop something for Canada ....
Personnally, I check names manually using Geobase Roads layer. This layer
contains the same road names has in the Canvec files. There are surely better
ways to systematically verify names. But it is a simple way to do it.
I added this layer to JOSM Imagery sources and it is available from WMS/TMS
Preferences in the CA section of the available imageries. Having Geobase roads
layer as background layer, you can find rapidly the road names. We have to zoom
in to see the layer. We switch the Data layer on and off to see easily the
road names from the Geobase layer.
Looking at this area, I see that mappers have given name="Route canadienne" to
road 117 with NHS="yes" tag.Route canadienne goes from Québec to Montréal and
Toronto.
Pierre
>________________________________
> De : Frank Steggink <[email protected]>
>À : Béland Pierre <[email protected]>
>Envoyé le : Jeudi 23 août 2012 2h06
>Objet : Re: [Talk-ca] Canvec import issues
>
>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 <[email protected]>:
>
>> David and Paul, do you think this was the problem with these imports???
>>
>> Pierre
>>
>>
>>
>>> ________________________________
>>> De : David E. Nelson <[email protected]>
>>> À : Paul Norman <[email protected]>; "[email protected]"
>>> <[email protected]>
>>> 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 <[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
>>>
>>>
>>>
>
>
>
>
_______________________________________________
Talk-ca mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
