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 <james2...@gmail.com> a écrit : _______________________________________________ Talk-ca mailing list Talk-ca@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, <hannesro...@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.mar...@gmail.com> An: "Hannes Röst" <hannesro...@gmx.ch> Cc: "Talk-CA OpenStreetMap" <talk-ca@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 <hannesro...@gmx.ch[mailto:hannesro...@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@openstreetmap.org[mailto:Talk-ca@openstreetmap.org] https://lists.openstreetmap.org/listinfo/talk-ca _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
