<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
OMG, a lot of pertinent questions! <br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
You are summarizing questions than were discussed on this list over the last decade. Discussions about canvec/osm data modeling, internal canvec data sources, import problems, edits problems, and artifacts from osm validation tools' history!
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Because of that, you cannot assume any coast-to-coast consistency with the problems you have identified, although you can find them almost everywhere.
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Here are some clues. Canvec model did not change much over years but the sources used to build the product changed (from federal to provincial/municipal). As far as I know, canvec.osm product is not maintained anymore, even if its last version is still available.
When you find inconsistencies, look at data history. It may help to identify if a problem comes from an initial import, from an adjustment with existing data, from a duplicated erroneous import, or from subsequent edits.<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Good mapping!<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Daniel <span id="ms-outlook-android-cursor"></span><br>
<br>
</div>
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
<span id="OutlookSignature">
<div dir="auto" style="direction: ltr; margin: 0; padding: 0; font-family: sans-serif; font-size: 11pt; color: black; ">
Sent from Galaxy S7</div>
</span><br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Hannes Röst <hannesroest@gmx.ch><br>
<b>Sent:</b> Wednesday, July 8, 2020 11:41:50 AM<br>
<b>To:</b> pierzenh@yahoo.fr <pierzenh@yahoo.fr><br>
<b>Cc:</b> Talk-CA OpenStreetMap <talk-ca@openstreetmap.org><br>
<b>Subject:</b> Re: [Talk-ca] NRCan lakes</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
Dear Pierre<br>
<br>
Thanks a lot, your explanation of the history is very helpful. I can also see on the wiki and the mailing list some threads and pages that explain the import but some of the wiki pages are quite old (10 years or so) and its not clear whether they still all
apply and contain current policy.<br>
<br>
In your example it seems that the import produced duplicated ways sometimes where the lake and the multipolygone (inner) were identical.In this case I see that they can be found with the JOSM validator (org.openstreetmap.josm.data.validation.tests.DuplicateWays
and can then be merged (Shift-J) but its 4 clicks for each merge so quite some work and a script could potentially fix that automatically.<br>
<br>
<br>
When I look more closely, however, I think this is partially an import artefact and partially a problem in the input data. Take for example the case of
<a href="https://www.openstreetmap.org/way/129592036">https://www.openstreetmap.org/way/129592036</a> and
<a href="https://www.openstreetmap.org/way/129592039">https://www.openstreetmap.org/way/129592039</a> which has the same issue (one tagged as "inner" and one as water) and I look in the current CanVec data 031L03 0.3.3 then I only see a single way with 14 nodes
at that position. In the same tile I find the ways <a href="https://www.openstreetmap.org/way/129592307">
https://www.openstreetmap.org/way/129592307</a> and <a href="https://www.openstreetmap.org/way/129592315">
https://www.openstreetmap.org/way/129592315</a> are duplicated both in OSM as well as in the input CanVec data tile 031L03 0.3.3 (one is inner of wetland, the other inner of wood). I am not sure where this error comes from but it clearly highlights the need
for manual fixup of the imported data.<br>
<br>
> Ici on peut par exemple ne conserver que le lac (way/60852636) et effacer le doublon pour le role inner (way/60854569) et réviser la relation multipolygone pour y indiquer way/60852636 avec role=inner.<br>
<br>
Yes I think that is possible with JOSM by selecting both and hitting Shift-J and then making sure to click "Keep" in the relation. But its a lot of work because it is currently done manually and it seems this could easily be done by a script (this was already
discussed several years back, especially doing this automatically but nothing seems to have happened [1]).<br>
<br>
Another issue that I found in the import is with highways: the "almost connected but not connected" ways, luckily they can be found by Osmose but create a ton of warnings:
<a href="http://osmose.openstreetmap.fr/en/map/#zoom=12&lat=46.0489&lon=-77.5019&item=xxxx&level=1&tags=&fixable=">
http://osmose.openstreetmap.fr/en/map/#zoom=12&lat=46.0489&lon=-77.5019&item=xxxx&level=1&tags=&fixable=</a><br>
<br>
What I also dont understand is differences between CanVec imports, for example looking at the same tile as above ( 031L03 0.3.3 ) there are several waterways that are missing in the CanVec data, for example
<a href="https://www.openstreetmap.org/way/129591734">https://www.openstreetmap.org/way/129591734</a> (tagged with NRCan-CanVec-8.0) is not present any more in the tiles that I downloaded from [2] - is there some error here, was the stream removed on purpose
in the newer CanVec data? In the ESRI and Bing satellite data I can clearly see a feature there in the woods that looks very much like a waterway, so it looks like some sort of stream is there, but not in other images from Maxar (maybe its only part of the
year?). So why is it missing in newer CanVec data? How should we deal with these cases in OSM ?<br>
<br>
Best<br>
<br>
Hannes<br>
<br>
1. <a href="https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007225.html">
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007225.html</a><br>
2. <a href="https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/osm/">https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/osm/</a><br>
<br>
<br>
Gesendet: Dienstag, 07. Juli 2020 um 12:18 Uhr<br>
Von: "Pierre Béland" <pierzenh@yahoo.fr><br>
An: "Talk-CA OpenStreetMap" <talk-ca@openstreetmap.org><br>
Cc: "Hannes Röst" <hannesroest@gmx.ch><br>
Betreff: Re: [Talk-ca] NRCan lakes<br>
<br>
Petit rappel pour ceux moins familiers avec les imports Canvec. Il est bon de bien connaître la structure des données et doublons éventuels à corriger. Aussi JOSM est très utile pour repérer les chemins en doublon et corriger.<br>
<br>
Les développeurs OSM mentionnent régulièrement des multipolygones bois (imports Canvec) très grands et complexes qui causent des problèmes de traitement de données dans la base de données OSM. Il faut donc éviter de jumeler les multipolygones bois, et plutôt
simplifier lorsque possible. <br>
Aussi, on rencontre souvent des chemins en doublon pour décrire et le lac et les zones à exclure d'un multipolygone. Tobermory Lake (60852636) est un exemple intéressant à ce sujet. Avec JOSM, on clique sur les bords du lac pour voir si des doublons existent.<br>
<br>
Ici- le lac <a href="https://www.openstreetmap.org/way/60852636">https://www.openstreetmap.org/way/60852636</a><br>
- la zone à exclure du multipolygone (role=inner) <a href="https://www.openstreetmap.org/way/60854569[https://www.openstreetmap.org/way/60854569">
https://www.openstreetmap.org/way/60854569[https://www.openstreetmap.org/way/60854569</a>]<br>
- le multipolygone <a href="https://www.openstreetmap.org/way/946291[https://www.openstreetmap.org/way/946291">
https://www.openstreetmap.org/way/946291[https://www.openstreetmap.org/way/946291</a>]<br>
<br>
De plus, on retrouve un polygone couvrant une partie du lac pour le marécage adjacent au lac (natural=wetland).<br>
<a href="https://www.openstreetmap.org/way/60852071[https://www.openstreetmap.org/way/60852071">https://www.openstreetmap.org/way/60852071[https://www.openstreetmap.org/way/60852071</a>]<br>
<br>
Ici on peut par exemple ne conserver que le lac (way/60852636) et effacer le doublon pour le role inner (way/60854569) et réviser la relation multipolygone pour y indiquer way/60852636 avec role=inner.<br>
<br>
<br>
Pierre<br>
<br>
<br>
<br>
Le mardi 7 juillet 2020 11 h 34 min 08 s UTC−4, James <james2432@gmail.com> a écrit :<br>
<br>
<br>
<br>
_______________________________________________<br>
Talk-ca mailing list<br>
Talk-ca@openstreetmap.org[mailto:Talk-ca@openstreetmap.org]<br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
<br>
I don't think canvec is updating these things on a regular basis, OSM after corrections are usually more accurate than canvec anyways and doubt would update data from Canvec to fix outdated data <br>
<br>
On Tue., Jul. 7, 2020, 11:27 a.m. Hannes Röst, <hannesroest@gmx.ch[mailto:hannesroest@gmx.ch]> wrote:Dear Adam and Daniel<br>
<br>
Thanks a lot, so this answers the question that these are import artefacts and not intended. One question still remains, namely whether we should clean them up and how (joining ways makes sense from the OSM data model but may make a future update based on CANVEC
files much harder while adding all ways into a relation would preserve the import but the resulting shape will look funny). My instinct is still to fix the ways unless there is a strong reason against this. One reason I ran into this was trying to match OSM
to Wikidata items and of course having 3 ways all called the same name makes this difficult. Let me know what you think<br>
<br>
Another issue I found was with nodes such as these: 1279897592, 1279898654 and 1279896951 which also seem to come from an import (see [1] for overpass query). I am not sure whether these are duplicate imports or whether they are supposed to indicate the extent
of a feature (most east and most western point) of the channel. The wiki indicates to either map this as "natural=strait" and use either a single node, a line or a multipolygon [2] but not as multiple nodes with the same name. Honestly, in this case its a
bit hard to see where the supposed "channel" should be, but connecting the nodes to a line would seem sensible here to me, any thoughts?<br>
<br>
Best<br>
<br>
Hannes<br>
<br>
[1] <a href="http://overpass-turbo.eu/map.html?Q=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A(%0A%20%20node%5Bname%3D%22Devil%20Island%20Channel%22%5D%3B%0A)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B[http://overpass-turbo.eu/map.html?Q=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A(%0A%20%20node%5Bname%3D%22Devil%20Island%20Channel%22%5D%3B%0A)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B">
http://overpass-turbo.eu/map.html?Q=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A(%0A%20%20node%5Bname%3D%22Devil%20Island%20Channel%22%5D%3B%0A)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B[http://overpass-turbo.eu/map.html?Q=%5Bout%3Ajson%5D%5Btimeout%3A25%5D%3B%0A(%0A%20%20node%5Bname%3D%22Devil%20Island%20Channel%22%5D%3B%0A)%3B%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B</a>]<br>
[2] <a href="https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map[https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map">
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map[https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map</a>]<br>
<br>
<br>
Gesendet: Dienstag, 07. Juli 2020 um 09:56 Uhr<br>
Von: "Adam Martin" <s.adam.martin@gmail.com[mailto:s.adam.martin@gmail.com]><br>
An: "Hannes Röst" <hannesroest@gmx.ch[mailto:hannesroest@gmx.ch]><br>
Cc: "Talk-CA OpenStreetMap" <talk-ca@openstreetmap.org[mailto:talk-ca@openstreetmap.org]><br>
Betreff: Re: [Talk-ca] NRCan lakes<br>
<br>
As mentioned by Daniel, this is due to the nature of the CANVEC data import. CANVEC shapefile data is based on tiles and these will chop practically anything into pieces - lakes are just ones of the more noticeable. I have corrected some of these myself as
I've come across them. Just be careful in cases where the lake pieces are part of different relations in the area - you will need to adjust those to make sure nothing breaks.<br>
<br>
Adam <br>
<br>
On Tue, Jul 7, 2020 at 2:33 AM Hannes Röst <hannesroest@gmx.ch[mailto:hannesroest@gmx.ch][mailto:hannesroest@gmx.ch[mailto:hannesroest@gmx.ch]]> wrote:Hello<br>
<br>
I am a contributor from Toronto and I have a question regarding how to<br>
treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.<br>
I came across this lake here:<br>
<br>
<a href="https://www.openstreetmap.org/way/69275451[https://www.openstreetmap.org/way/69275451][https://www.openstreetmap.org/way/69275451%5Bhttps://www.openstreetmap.org/way/69275451%5D">https://www.openstreetmap.org/way/69275451[https://www.openstreetmap.org/way/69275451][https://www.openstreetmap.org/way/69275451%5Bhttps://www.openstreetmap.org/way/69275451%5D</a>]<br>
<a href="https://www.openstreetmap.org/way/69277932">https://www.openstreetmap.org/way/69277932</a><br>
<a href="https://www.openstreetmap.org/way/69745752">https://www.openstreetmap.org/way/69745752</a><br>
<br>
Which is strangely split up into 3 parts and I wonder how to proceed:<br>
should we fix this and create a single way out of these 3 parts or is<br>
it beneficial (for comparison to future NRCan database entries) to<br>
keep them that way and create a relation out of the three? Also, does<br>
somebody know why the NRCan dataset does this, is this an import<br>
artefact (splitting into tiles?) and should be corrected when encountered<br>
or is it part of the original dataset?<br>
<br>
Best<br>
<br>
Hannes Rost<br>
<br>
_______________________________________________<br>
Talk-ca mailing list<br>
Talk-ca@openstreetmap.org[mailto:Talk-ca@openstreetmap.org][mailto:Talk-ca@openstreetmap.org[mailto:Talk-ca@openstreetmap.org]]<br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca[https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca[https://lists.openstreetmap.org/listinfo/talk-ca</a>]<br>
<br>
_______________________________________________<br>
Talk-ca mailing list<br>
Talk-ca@openstreetmap.org[mailto:Talk-ca@openstreetmap.org]<br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
<br>
_______________________________________________<br>
Talk-ca mailing list<br>
Talk-ca@openstreetmap.org<br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</div>
</span></font></div>
</body>
</html>