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
