[Talk-ca] Canvec import issues

Pierre Béland infosbelas-gps at yahoo.fr
Wed Aug 22 18:22:29 BST 2012 

Frank, 

I dont think we can considere these as Open Data compatible with ODbl.


We dont know the license for Surete du Québec map. And no licensing information is given on the toponyms site.  You would have to contact them before using this information.


The government of Québec has just started is Open Data site and as discussed before on the list their license is not considered compatible with ODbl.

But they are open to discussion. After I wrote a request on the Open Data site, I was contacted last week by a government of Québec person. This person wants to clarify licensing problems. I will write a specific memo about that.

 
Pierre 



>________________________________
> De : Frank Steggink <steggink at steggink.org>
>À : talk-ca at openstreetmap.org 
>Envoyé le : Mercredi 22 août 2012 11h52
>Objet : Re: [Talk-ca] Canvec import issues
> 
>Hi Pierre,
>
>Regarding the duplicated ways, I'll get to that by replying Daniel's mail.
>Regarding the toponyms, the user I'm having contact with is refering to Sûreté de Québec, for example this page: http://www.sq.gouv.qc.ca/poste-mrc-des-pays-d-en-haut/organisation/carte-detaillee-pays-haut.pdf
>
>I don't know if both data sources can be considered public domain.  As far as I know, the guidelines for the federal government don't apply to provincial and local governments. See also the discussion about importing data from the Ville de Québec.
>
>Frank
>
>On 21-8-2012 20:59, Pierre Béland wrote:
>> Frank
>> 
>> The NEtiquette is always important in these circumstances. Lets hope this mapper will learn how to deal with the community.
>> 
>> I Looked rapidly at the data.I see a multipolygon natural=wood Relation : 2362646 that contains 72 members. I see that you imported a wooded area way=176778952 that is part of this relation. It also overlaps for the 2/3 with a lake way=57988179. I see similar situation with way 176778559.  Unless I missed something, my understanding is that you should simply remove ways 176778952 and 176778559 and any others that duplicate what is already defined  by relation 2362646.
>> 
>> The Quebec toponyms may sometime be more complete then Canvec. But not all the lakes have names and it is not easy to find infos for a specific area. You can  search for a specific name at http://www.toponymie.gouv.qc.ca/.
>> See http://www.toponymie.gouv.qc.ca/ct/ToposWeb/recherche.aspx?s=lac-ouimet&x=0&y=0 for lac Ouimet results
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20120822/2658186a/attachment-0001.html>

More information about the Talk-ca mailing list