[Talk-ca] NRCan lakes

Tue Jul 7 16:18:09 UTC 2020

 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.
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.

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.
Ici- le lac https://www.openstreetmap.org/way/60852636
- la zone à exclure du multipolygone (role=inner) https://www.openstreetmap.org/way/60854569
- le multipolygone https://www.openstreetmap.org/way/946291

De plus, on retrouve un polygone couvrant une partie du lac pour le marécage adjacent au lac (natural=wetland).
https://www.openstreetmap.org/way/60852071

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.

Pierre 

    Le mardi 7 juillet 2020 11 h 34 min 08 s UTC−4, James <james2432 at gmail.com> a écrit :  

 _______________________________________________
Talk-ca mailing list
Talk-ca at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  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
On Tue., Jul. 7, 2020, 11:27 a.m. Hannes Röst, <hannesroest at gmx.ch> wrote:

Dear Adam and Daniel

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

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?

Best

Hannes

[1] 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
[2] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dstrait#How_to_map

Gesendet: Dienstag, 07. Juli 2020 um 09:56 Uhr
Von: "Adam Martin" <s.adam.martin at gmail.com>
An: "Hannes Röst" <hannesroest at gmx.ch>
Cc: "Talk-CA OpenStreetMap" <talk-ca at openstreetmap.org>
Betreff: Re: [Talk-ca] NRCan lakes

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.

Adam 

On Tue, Jul 7, 2020 at 2:33 AM Hannes Röst <hannesroest at gmx.ch[mailto:hannesroest at gmx.ch]> wrote:Hello

I am a contributor from Toronto and I have a question regarding how to
treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
I came across this lake here:

https://www.openstreetmap.org/way/69275451[https://www.openstreetmap.org/way/69275451]
https://www.openstreetmap.org/way/69277932
https://www.openstreetmap.org/way/69745752

Which is strangely split up into 3 parts and I wonder how to proceed:
should we fix this and create a single way out of these 3 parts or is
it beneficial (for comparison to future NRCan database entries) to
keep them that way and create a relation out of the three? Also, does
somebody know why the NRCan dataset does this, is this an import
artefact (splitting into tiles?) and should be corrected when encountered
or is it part of the original dataset?

Best

Hannes Rost

_______________________________________________
Talk-ca mailing list
Talk-ca at openstreetmap.org[mailto:Talk-ca at openstreetmap.org]
https://lists.openstreetmap.org/listinfo/talk-ca

_______________________________________________
Talk-ca mailing list
Talk-ca at openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20200707/b910d3af/attachment-0001.htm>