Re: [Talk-ca] can I submit road data?

[James]

https://wiki.openstreetmap.org/wiki/Import/Guidelines

Usually involves creating a wiki page like

https://wiki.openstreetmap.org/wiki/Ottawa/Import/Plan

outlining that licensing isnt an issue and what tags would be
used(addr:housenumber and addr:street for address points) as well as
contigency for conflating against existing data

On Tue., Jul. 7, 2020, 5:11 p.m. Jason Carlson, 
wrote:

> Okay, I'll scrap the idea of importing roads - mostly because they are
> already there - just off skew but a dozen or more meters in many places. I
> wrote software to fix most of our issues in our area - maybe there is an
> API to do the same with OSM and I can volunteer some skills there.
>
> As a side note, what about point data. I have a bunch of rural addresses
> that I could upload as point data and it would be a lot easier to do the
> initial import at least if I can get a hold of those guidelines so I can
> set it up right the first time :) You know where I can find those?
>
>
> *Jason Carlson*
>
> IT/GIS Administrator
>
> *403.772.3793*
>
> *Starland County*
> *Morrin, AB  *
> *(403) 772-3793*
> *www.starlandcounty.com *
>
> *Our organization accepts no liability for the content of this email, or
> for the consequences of any actions taken on the basis of the information
> provided, unless that information is subsequently confirmed in writing. The
> content of this message is confidential. If you have received it by
> mistake, please inform us by an email reply and then delete the message. It
> is forbidden to copy, forward, or in any way reveal the contents of this
> message to anyone. *
>
>
> On Tue, Jul 7, 2020 at 2:16 PM stevea  wrote:
>
>> > Imports are quite the pain to try and do - there's a whole process in
>> place now to do them. It stems from the experience in the States of an
>> import more than a decade ago of the TIGER data (from the Census Bureau)
>> that is still being fixed after pretty large amounts of time working
>> through it.
>>
>> Major components of the USA's TIGER import included both road (highway=*)
>> and rail (railway=*).  This took place in 2007-8 with early-to-mid-2000s
>> data and resulted in OSM data which were (and still are in places) quite
>> problematic.  There have been many strategies and even renderers which aim
>> to address helping fix the massive amount of TIGER data that were imported,
>> yet it will likely take another decade (three?) to complete these
>> improvements — that's a lot of work.  This sort of "ongoing work to improve
>> an import" is common with earlier / older imports (especially when OSM had
>> little to no "official" guidelines to doing imports well).  Our Import
>> Guidelines go a long way towards remedying common problems associated with
>> imports from "lessons learned" in earlier ones, but imports are still both
>> controversial and often problematic.  However, there are excellent examples
>> of well done imports, usually with very carefully written Import
>> Guidelines, a good deal of community buy-in and consensus and often the
>> guidance of OSM volunteers who have experience with imports and can steer
>> the process in better directions if they begin to go awry.  I don't need to
>> say it, but Kevin is correct:  let TIGER be a lesson to OSM about imports,
>> especially those done at very wide (national) scales in large geographic
>> areas like Canada or USA.  They are challenging to do well, but shouldn't
>> be completely prohibited, but rather done quite carefully and slowly.
>>
>> SteveA
>> California
>
> ___
> 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

Re: [Talk-ca] can I submit road data?

[Jason Carlson]

Okay, I'll scrap the idea of importing roads - mostly because they are
already there - just off skew but a dozen or more meters in many places. I
wrote software to fix most of our issues in our area - maybe there is an
API to do the same with OSM and I can volunteer some skills there.

As a side note, what about point data. I have a bunch of rural addresses
that I could upload as point data and it would be a lot easier to do the
initial import at least if I can get a hold of those guidelines so I can
set it up right the first time :) You know where I can find those?


*Jason Carlson*

IT/GIS Administrator

*403.772.3793*

*Starland County*
*Morrin, AB  *
*(403) 772-3793*
*www.starlandcounty.com *

*Our organization accepts no liability for the content of this email, or
for the consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing. The
content of this message is confidential. If you have received it by
mistake, please inform us by an email reply and then delete the message. It
is forbidden to copy, forward, or in any way reveal the contents of this
message to anyone. *


On Tue, Jul 7, 2020 at 2:16 PM stevea  wrote:

> > Imports are quite the pain to try and do - there's a whole process in
> place now to do them. It stems from the experience in the States of an
> import more than a decade ago of the TIGER data (from the Census Bureau)
> that is still being fixed after pretty large amounts of time working
> through it.
>
> Major components of the USA's TIGER import included both road (highway=*)
> and rail (railway=*).  This took place in 2007-8 with early-to-mid-2000s
> data and resulted in OSM data which were (and still are in places) quite
> problematic.  There have been many strategies and even renderers which aim
> to address helping fix the massive amount of TIGER data that were imported,
> yet it will likely take another decade (three?) to complete these
> improvements — that's a lot of work.  This sort of "ongoing work to improve
> an import" is common with earlier / older imports (especially when OSM had
> little to no "official" guidelines to doing imports well).  Our Import
> Guidelines go a long way towards remedying common problems associated with
> imports from "lessons learned" in earlier ones, but imports are still both
> controversial and often problematic.  However, there are excellent examples
> of well done imports, usually with very carefully written Import
> Guidelines, a good deal of community buy-in and consensus and often the
> guidance of OSM volunteers who have experience with imports and can steer
> the process in better directions if they begin to go awry.  I don't need to
> say it, but Kevin is correct:  let TIGER be a lesson to OSM about imports,
> especially those done at very wide (national) scales in large geographic
> areas like Canada or USA.  They are challenging to do well, but shouldn't
> be completely prohibited, but rather done quite carefully and slowly.
>
> SteveA
> California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] can I submit road data?

[stevea]

> Imports are quite the pain to try and do - there's a whole process in place 
> now to do them. It stems from the experience in the States of an import more 
> than a decade ago of the TIGER data (from the Census Bureau) that is still 
> being fixed after pretty large amounts of time working through it.

Major components of the USA's TIGER import included both road (highway=*) and 
rail (railway=*).  This took place in 2007-8 with early-to-mid-2000s data and 
resulted in OSM data which were (and still are in places) quite problematic.  
There have been many strategies and even renderers which aim to address helping 
fix the massive amount of TIGER data that were imported, yet it will likely 
take another decade (three?) to complete these improvements — that's a lot of 
work.  This sort of "ongoing work to improve an import" is common with earlier 
/ older imports (especially when OSM had little to no "official" guidelines to 
doing imports well).  Our Import Guidelines go a long way towards remedying 
common problems associated with imports from "lessons learned" in earlier ones, 
but imports are still both controversial and often problematic.  However, there 
are excellent examples of well done imports, usually with very carefully 
written Import Guidelines, a good deal of community buy-in and consensus and 
often the guidance of OSM volunteers who have experience with imports and can 
steer the process in better directions if they begin to go awry.  I don't need 
to say it, but Kevin is correct:  let TIGER be a lesson to OSM about imports, 
especially those done at very wide (national) scales in large geographic areas 
like Canada or USA.  They are challenging to do well, but shouldn't be 
completely prohibited, but rather done quite carefully and slowly.

SteveA
California
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] can I submit road data?

[Jason Carlson]

Thanks Kevin, That would make sense if there were attribute changes but if
all the basics are the same they are still split. There is odd fields in
the data likely left over from an import years ago that just was never
cleaned up. With GIS databases, it would have been so easy to do a merge on
roads that connect and have the same attributes. Perhaps that query was not
so simple back when it was imported and anything was better than nothing at
that time.

I looked at the ESRI imagery and it is a lot more accurate (although more
dated so I guess new areas wouldn't be in it). I looked at a couple of
villages (which I have aerials for just because those tiles were partly
rural). I noticed the OSM road data matches perfectly with the Bing aerials
but not with my aerials or ESRI at all. ESRI is insanely close to lining up
with ours. The good news is the Bing tile skews are isolated and
variant only to each tile so theoretically a person could highlight all
points and move them all to correct. The bad news is because Bing is the
default viewer, some future editor is just going to think they need to fix
it to align with Bing not realizing it is inaccurate and all the work will
be undone. Too bad OSM does not have an option to flag flawed
background tiles for an area so users are at least alerted that the tile
they are using as a guide is not accurate.

*Jason Carlson*

IT/GIS Administrator

*403.772.3793*

*Starland County*
*Morrin, AB  *
*(403) 772-3793*
*www.starlandcounty.com *

*Our organization accepts no liability for the content of this email, or
for the consequences of any actions taken on the basis of the information
provided, unless that information is subsequently confirmed in writing. The
content of this message is confidential. If you have received it by
mistake, please inform us by an email reply and then delete the message. It
is forbidden to copy, forward, or in any way reveal the contents of this
message to anyone. *


On Tue, Jul 7, 2020 at 12:13 PM Kevin Farrugia 
wrote:

> Hey Jason,
>
> Imports are quite the pain to try and do - there's a whole process in
> place now to do them. It stems from the experience in the States of an
> import more than a decade ago of the TIGER data (from the Census Bureau)
> that is still being fixed after pretty large amounts of time working
> through it.
>
> There could be multiple reasons for all of the road splits you're seeing-
> one is that in most import data sources roads are split at traversable
> intersections (as you would find in most GIS datasets), another reason is
> that in OSM streets are split wherever there is a change in attributes, for
> example where speed limits change, turn lanes appear/disappear, surface
> types changes, or there's a bridge.
>
> It might be worth trying Esri imagery.  I've noticed in the municipality I
> work for, as well as others in the Toronto area, that they buy the aerial
> imagery that we commission them to fly every spring. It might not be the
> freshest available, but I've found the accuracy to be more accurate than
> other commercial imagery available.
>
> ---
> Kevin F
>
> On Tue., Jul. 7, 2020, 1:02 p.m. Jason Carlson, 
> wrote:
>
>> While waiting for a response I think if I import roads that already exist
>> (albeit incorrectly) it will possibly be just as much work to fix. I tried
>> editing changes but the aerial photos by Bing are horribly inaccurate in
>> some places. I think they must pay for accuracy based on the amount of
>> population in an area. For example, one rural road comes to the right edge
>> of a Bing aerial tile and stops as on the adjacent tile the road abruptly
>> starts 30 meters to the south. I just noticed however I can load other
>> aerial backgrounds including my own which is very accurate. The only thing
>> that sucks is I have a lot of data that is missing such as road width, lane
>> numbers, surface type, road name aliases (like historical or common local
>> names), speed limits, even signage locations (like yield or stops). With my
>> 3300+ roads (of which OpenStreetMap has split into a heck of lot more
>> unnecessarily probably from the initial import) this is going to take some
>> time to fix but hopefully after I do some mapping programs that use
>> OpenStreetMaps will help people navigate to rural addresses in our region
>> as right now GPS units are pretty much useless out here.
>>
>>
>> On Fri, Jun 26, 2020 at 11:53 AM Jason Carlson 
>> wrote:
>>
>>> I noticed a number of roads in our county are incorrect in our area (as
>>> are most rural areas with next to no population). I recently rebuilt all
>>> our GIS road data and submitted it to an organization that then
>>> redistributes it to emergency dispatch services and about 25
>>> organizations/companies. I did not see OpenStreetMap as one of the ones
>>> they send data too so I was wondering if I could submit that data myself to
>>> them?
>>>
>>> Jason
>>>
>> 

Re: [Talk-ca] can I submit road data?

[Kevin Farrugia]

Hey Jason,

Imports are quite the pain to try and do - there's a whole process in place
now to do them. It stems from the experience in the States of an import
more than a decade ago of the TIGER data (from the Census Bureau) that is
still being fixed after pretty large amounts of time working through it.

There could be multiple reasons for all of the road splits you're seeing-
one is that in most import data sources roads are split at traversable
intersections (as you would find in most GIS datasets), another reason is
that in OSM streets are split wherever there is a change in attributes, for
example where speed limits change, turn lanes appear/disappear, surface
types changes, or there's a bridge.

It might be worth trying Esri imagery.  I've noticed in the municipality I
work for, as well as others in the Toronto area, that they buy the aerial
imagery that we commission them to fly every spring. It might not be the
freshest available, but I've found the accuracy to be more accurate than
other commercial imagery available.

---
Kevin F

On Tue., Jul. 7, 2020, 1:02 p.m. Jason Carlson, 
wrote:

> While waiting for a response I think if I import roads that already exist
> (albeit incorrectly) it will possibly be just as much work to fix. I tried
> editing changes but the aerial photos by Bing are horribly inaccurate in
> some places. I think they must pay for accuracy based on the amount of
> population in an area. For example, one rural road comes to the right edge
> of a Bing aerial tile and stops as on the adjacent tile the road abruptly
> starts 30 meters to the south. I just noticed however I can load other
> aerial backgrounds including my own which is very accurate. The only thing
> that sucks is I have a lot of data that is missing such as road width, lane
> numbers, surface type, road name aliases (like historical or common local
> names), speed limits, even signage locations (like yield or stops). With my
> 3300+ roads (of which OpenStreetMap has split into a heck of lot more
> unnecessarily probably from the initial import) this is going to take some
> time to fix but hopefully after I do some mapping programs that use
> OpenStreetMaps will help people navigate to rural addresses in our region
> as right now GPS units are pretty much useless out here.
>
>
> On Fri, Jun 26, 2020 at 11:53 AM Jason Carlson 
> wrote:
>
>> I noticed a number of roads in our county are incorrect in our area (as
>> are most rural areas with next to no population). I recently rebuilt all
>> our GIS road data and submitted it to an organization that then
>> redistributes it to emergency dispatch services and about 25
>> organizations/companies. I did not see OpenStreetMap as one of the ones
>> they send data too so I was wondering if I could submit that data myself to
>> them?
>>
>> Jason
>>
> ___
> 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

Re: [Talk-ca] can I submit road data?

[John Marshall]

Hi Jason,

I am happy to help. Sounds like a fun project.

John

On Tue, Jul 7, 2020 at 1:02 PM Jason Carlson 
wrote:

> While waiting for a response I think if I import roads that already exist
> (albeit incorrectly) it will possibly be just as much work to fix. I tried
> editing changes but the aerial photos by Bing are horribly inaccurate in
> some places. I think they must pay for accuracy based on the amount of
> population in an area. For example, one rural road comes to the right edge
> of a Bing aerial tile and stops as on the adjacent tile the road abruptly
> starts 30 meters to the south. I just noticed however I can load other
> aerial backgrounds including my own which is very accurate. The only thing
> that sucks is I have a lot of data that is missing such as road width, lane
> numbers, surface type, road name aliases (like historical or common local
> names), speed limits, even signage locations (like yield or stops). With my
> 3300+ roads (of which OpenStreetMap has split into a heck of lot more
> unnecessarily probably from the initial import) this is going to take some
> time to fix but hopefully after I do some mapping programs that use
> OpenStreetMaps will help people navigate to rural addresses in our region
> as right now GPS units are pretty much useless out here.
>
>
> On Fri, Jun 26, 2020 at 11:53 AM Jason Carlson 
> wrote:
>
>> I noticed a number of roads in our county are incorrect in our area (as
>> are most rural areas with next to no population). I recently rebuilt all
>> our GIS road data and submitted it to an organization that then
>> redistributes it to emergency dispatch services and about 25
>> organizations/companies. I did not see OpenStreetMap as one of the ones
>> they send data too so I was wondering if I could submit that data myself to
>> them?
>>
>> Jason
>>
> ___
> 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

Re: [Talk-ca] can I submit road data?

[Jason Carlson]

While waiting for a response I think if I import roads that already exist
(albeit incorrectly) it will possibly be just as much work to fix. I tried
editing changes but the aerial photos by Bing are horribly inaccurate in
some places. I think they must pay for accuracy based on the amount of
population in an area. For example, one rural road comes to the right edge
of a Bing aerial tile and stops as on the adjacent tile the road abruptly
starts 30 meters to the south. I just noticed however I can load other
aerial backgrounds including my own which is very accurate. The only thing
that sucks is I have a lot of data that is missing such as road width, lane
numbers, surface type, road name aliases (like historical or common local
names), speed limits, even signage locations (like yield or stops). With my
3300+ roads (of which OpenStreetMap has split into a heck of lot more
unnecessarily probably from the initial import) this is going to take some
time to fix but hopefully after I do some mapping programs that use
OpenStreetMaps will help people navigate to rural addresses in our region
as right now GPS units are pretty much useless out here.


On Fri, Jun 26, 2020 at 11:53 AM Jason Carlson 
wrote:

> I noticed a number of roads in our county are incorrect in our area (as
> are most rural areas with next to no population). I recently rebuilt all
> our GIS road data and submitted it to an organization that then
> redistributes it to emergency dispatch services and about 25
> organizations/companies. I did not see OpenStreetMap as one of the ones
> they send data too so I was wondering if I could submit that data myself to
> them?
>
> Jason
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] NRCan lakes

[Pierre Béland via Talk-ca]

 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  
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,  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" 
An: "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
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 
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

Re: [Talk-ca] NRCan lakes

[James]

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,  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" 
> An: "Hannes Röst" 
> Cc: "Talk-CA OpenStreetMap" 
> 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]> 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

Re: [Talk-ca] NRCan lakes

[Hannes Röst]

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" 
An: "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
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 
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

Re: [Talk-ca] NRCan lakes

[Adam Martin]

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  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/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
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] NRCan lakes

[Daniel @jfd553]

Have a look at the osm wiki page for canvec import, you will understand why.

Sent from Galaxy S7


From: Hannes Röst 
Sent: Tuesday, July 7, 2020 1:02:43 AM
To: talk-ca@openstreetmap.org 
Subject: [Talk-ca] NRCan lakes

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/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
https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] (no subject)

[James]

If it becomes over 2000 nodes in a single "way" or shape, it's recommended
to make it a multipolygon. The reason NRCan does this is probably because
it's on the edge of what they call "NTS Tiles" which is a grid that
organizes the data (see forests in Canada
https://wiki.openstreetmap.org/wiki/Canada#What.27s_with_the_forests_in_Canada.3F).
Importers just didnt join them back in the day, that's all

On Tue, Jul 7, 2020 at 5:02 AM Hannes Röst  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/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?) or is it part of the original
> dataset?
>
> Best
>
> Hannes Rost
> ___
> 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