Re: [Talk-ca] NRCan lakes

[Kevin Farrugia]

I wouldn't worry about hoping the NRCan stuff is up to date. They're based
on data may/may not have been updated since the paper maps were printed in
the 70s/80s/90s and all aerial imagery that's in OSM would be newer than
that.

The National Hydro Network and National Road Network (based on provincial
data, which is based on municipal data) are both much more up to date and
actively maintained if you want some assistance when using imagery. I
believe both are automatically available in JOSM when editing in Canada.

---
Kevin F

On Wed., Jul. 8, 2020, 5:24 p.m. Hannes Röst,  wrote:

> Dear Daniel
>
> Thanks for your answers, I have tried to piece together this (apparently
> 10 year old) history of the import from the mailing list threads and the
> wiki and it has been somewhat difficult, especially as discussions seem to
> have been at multiple places. So, so many discussion about
> forests!...Overall there seem to be some questions about the quality and
> desirability of parts of the import of CanVec with the (Canadian) consus
> being that it is desireable to do the imports.
>
> The wiki still indicates to use the canvec.osm product even though the
> timestamps on the files are from 2013 [1] and it is not clear whether there
> is a newer / updated version of the data. When I compare the OSM files of
> tiles from the FTP site to the Toporama product doing some spot-checks I
> find them to be identical for hydrological data (wetlands, rivers etc) and
> almost identical for forests (with Toporama having some additional "inner"
> ways where no forest is, but not always more accurate). If my understanding
> is correct that the WMS endpoints of CanVec and Toporama are up-to-date,
> then this allows us to compare changes in the products since 2013 when the
> OSM FTP dump was made. On the other hand in the release notes from 2019 [2]
> they point to an FTP site but that one does not contain OSM files and the
> release notes seem to indicate 2016-01-14 as "original release" of the
> current CanVec data [3]. So it seems our version from 2013 is a bit behind
> but probably the best we have unless somebody is willing to create another
> export. However, it may make sense to load the *current* Toporama WSM layer
> into JOSM during an import and check for any updates since the 2013 dump.
> On the other hand, the data is not very up to date in cities, I found a
> large industrial complex in the Toporama map in downtown Toronto where "Marian
> Engel Park" is since at least 12 years [4], so we have to keep that in
> mind.
>
> The wiki also suggest to use a Google Sheet to track imports, but it does
> not seem to be used a lot - I assume from the wikipage that you have
> written most of it and initiated the import, correct?
>
> Best regards
>
> Hannes
>
> 1. https://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Datasets
> 2.
> https://www.nrcan.gc.ca/science-and-data/science-and-research/earth-sciences/geography/topographic-information/whats-new/canvec-update-available-now/22543
> 3.
> https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_en_Release_Note.pdf
> 4. https://www.openstreetmap.org/way/15804193
>
> *Gesendet:* Mittwoch, 08. Juli 2020 um 13:09 Uhr
> *Von:* "Daniel @jfd553" 
> *An:* "pierz...@yahoo.fr" , "Hannes Röst" <
> hannesro...@gmx.ch>
> *Cc:* "Talk-CA OpenStreetMap" 
> *Betreff:* Re: [Talk-ca] NRCan lakes
> OMG, a lot of pertinent questions!
> 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!
> Because of that, you cannot assume any coast-to-coast consistency with the
> problems you have identified, although you can find them almost everywhere.
> 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.
> Good mapping!
> Daniel
>
> Sent from Galaxy S7
> --
> *From:* Hannes Röst 
> *Sent:* Wednesday, July 8, 2020 11:41:50 AM
> *To:* pierz...@yahoo.fr 
> *Cc:* Talk-CA OpenStreetMap 
> *Subject:* Re: [Talk-ca] NRCan lakes
>
>
> Dear Pierre
>
> 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.
>
> In your example it seems that the import produced duplicated ways
> sometimes where the lake 

Re: [Talk-ca] NRCan lakes

[Pierre Béland via Talk-ca]

Hannes,
Ton exemple de doublons, on le retrouve beaucoup.  Et effectivement, le 
validateur JOSM permet de repérer ces doublons.  Et comme Daniel l'a clairement 
expliqué, il faut bien connaitre les données et effectuer les correction 
nécessaires.
Voici un script Overpass pour identifier les doublons  de polygones 
[natural=water] vs [roles inner - natural=wood]. Cette requête Overpass peut 
être lancée à partir de JOSM. 
http://overpass-turbo.eu/s/VW1
Il faut éviter de sélectionner une zone trop grande. Le script va extraire la 
relation natural=wood pour la zone et les chemins en doublon./ relations où 
doublons avec les éléments de cette relation natural=water. 

Le panneau Validation permet ensuite de repérer les doublons. Pour chacun il 
faut ensuite corriger tout en assurant l'intégrité de la relation natural=wood. 
Pierre 
 

Le mercredi 8 juillet 2020 17 h 23 min 04 s UTC−4, Hannes Röst 
 a écrit :  
 
 Dear Daniel Thanks for your answers, I have tried to piece together this 
(apparently 10 year old) history of the import from the mailing list threads 
and the wiki and it has been somewhat difficult, especially as discussions seem 
to have been at multiple places. So, so many discussion about 
forests!...Overall there seem to be some questions about the quality and 
desirability of parts of the import of CanVec with the (Canadian) consus being 
that it is desireable to do the imports. The wiki still indicates to use the 
canvec.osm product even though the timestamps on the files are from 2013 [1] 
and it is not clear whether there is a newer / updated version of the data. 
When I compare the OSM files of tiles from the FTP site to the Toporama product 
doing some spot-checks I find them to be identical for hydrological data 
(wetlands, rivers etc) and almost identical for forests (with Toporama having 
some additional "inner" ways where no forest is, but not always more accurate). 
If my understanding is correct that the WMS endpoints of CanVec and Toporama 
are up-to-date, then this allows us to compare changes in the products since 
2013 when the OSM FTP dump was made. On the other hand in the release notes 
from 2019 [2] they point to an FTP site but that one does not contain OSM files 
and the release notes seem to indicate 2016-01-14 as "original release" of the 
current CanVec data [3]. So it seems our version from 2013 is a bit behind but 
probably the best we have unless somebody is willing to create another export. 
However, it may make sense to load the *current* Toporama WSM layer into JOSM 
during an import and check for any updates since the 2013 dump. On the other 
hand, the data is not very up to date in cities, I found a large industrial 
complex in the Toporama map in downtown Toronto where "Marian Engel Park" is 
since at least 12 years [4], so we have to keep that in mind.  The wiki also 
suggest to use a Google Sheet to track imports, but it does not seem to be used 
a lot - I assume from the wikipage that you have written most of it and 
initiated the import, correct? Best regards Hannes 1. 
https://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Datasets2. 
https://www.nrcan.gc.ca/science-and-data/science-and-research/earth-sciences/geography/topographic-information/whats-new/canvec-update-available-now/225433.
 
https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_en_Release_Note.pdf4.
 https://www.openstreetmap.org/way/15804193 Gesendet: Mittwoch, 08. Juli 2020 
um 13:09 Uhr
Von: "Daniel @jfd553" 
An: "pierz...@yahoo.fr" , "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
Betreff: Re: [Talk-ca] NRCan lakesOMG, a lot of pertinent questions!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!Because of that, you cannot assume any coast-to-coast consistency with 
the problems you have identified, although you can find them almost 
everywhere.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.Good mapping!Daniel
 Sent from Galaxy S7From: Hannes Röst 
Sent: Wednesday, July 8, 2020 11:41:50 AM
To: pierz...@yahoo.fr 
Cc: Talk-CA OpenStreetMap 
Subject: Re: [Talk-ca] NRCan lakes 
Dear Pierre
 
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 

Re: [Talk-ca] NRCan lakes

[Hannes Röst]

Dear Daniel

 

Thanks for your answers, I have tried to piece together this (apparently 10 year old) history of the import from the mailing list threads and the wiki and it has been somewhat difficult, especially as discussions seem to have been at multiple places. So, so many discussion about forests!...Overall there seem to be some questions about the quality and desirability of parts of the import of CanVec with the (Canadian) consus being that it is desireable to do the imports.

 

The wiki still indicates to use the canvec.osm product even though the timestamps on the files are from 2013 [1] and it is not clear whether there is a newer / updated version of the data. When I compare the OSM files of tiles from the FTP site to the Toporama product doing some spot-checks I find them to be identical for hydrological data (wetlands, rivers etc) and almost identical for forests (with Toporama having some additional "inner" ways where no forest is, but not always more accurate). If my understanding is correct that the WMS endpoints of CanVec and Toporama are up-to-date, then this allows us to compare changes in the products since 2013 when the OSM FTP dump was made. On the other hand in the release notes from 2019 [2] they point to an FTP site but that one does not contain OSM files and the release notes seem to indicate 2016-01-14 as "original release" of the current CanVec data [3]. So it seems our version from 2013 is a bit behind but probably the best we have unless somebody is willing to create another export. However, it may make sense to load the *current* Toporama WSM layer into JOSM during an import and check for any updates since the 2013 dump. On the other hand, the data is not very up to date in cities, I found a large industrial complex in the Toporama map in downtown Toronto where "Marian Engel Park" is since at least 12 years [4], so we have to keep that in mind. 

 

The wiki also suggest to use a Google Sheet to track imports, but it does not seem to be used a lot - I assume from the wikipage that you have written most of it and initiated the import, correct?

 

Best regards

 

Hannes

 

1. https://wiki.openstreetmap.org/wiki/CanVec#Canvec_Product_-_Datasets


2. https://www.nrcan.gc.ca/science-and-data/science-and-research/earth-sciences/geography/topographic-information/whats-new/canvec-update-available-now/22543

3. https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_en_Release_Note.pdf

4. https://www.openstreetmap.org/way/15804193

 


Gesendet: Mittwoch, 08. Juli 2020 um 13:09 Uhr
Von: "Daniel @jfd553" 
An: "pierz...@yahoo.fr" , "Hannes Röst" 
Cc: "Talk-CA OpenStreetMap" 
Betreff: Re: [Talk-ca] NRCan lakes


OMG, a lot of pertinent questions!

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!

Because of that, you cannot assume any coast-to-coast consistency with the problems you have identified, although you can find them almost everywhere.

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.

Good mapping!

Daniel
 


Sent from Galaxy S7



From: Hannes Röst 
Sent: Wednesday, July 8, 2020 11:41:50 AM
To: pierz...@yahoo.fr 
Cc: Talk-CA OpenStreetMap 
Subject: Re: [Talk-ca] NRCan lakes

 




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

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 https://www.openstreetmap.org/way/129592036 and https://www.openstreetmap.org/way/129592039 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  

Re: [Talk-ca] NRCan lakes

[Daniel @jfd553]

OMG, a lot of pertinent questions!
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!
Because of that, you cannot assume any coast-to-coast consistency with the 
problems you have identified, although you can find them almost everywhere.
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.
Good mapping!
Daniel

Sent from Galaxy S7


From: Hannes Röst 
Sent: Wednesday, July 8, 2020 11:41:50 AM
To: pierz...@yahoo.fr 
Cc: Talk-CA OpenStreetMap 
Subject: Re: [Talk-ca] NRCan lakes


Dear Pierre

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.

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.


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 
https://www.openstreetmap.org/way/129592036 and 
https://www.openstreetmap.org/way/129592039 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 https://www.openstreetmap.org/way/129592307 and 
https://www.openstreetmap.org/way/129592315 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.

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

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

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: 
http://osmose.openstreetmap.fr/en/map/#zoom=12=46.0489=-77.5019==1==

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 
https://www.openstreetmap.org/way/129591734 (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 ?

Best

Hannes

1. https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007225.html
2. https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/osm/


Gesendet: Dienstag, 07. Juli 2020 um 12:18 Uhr
Von: "Pierre Béland" 
An: "Talk-CA OpenStreetMap" 
Cc: "Hannes Röst" 
Betreff: Re: [Talk-ca] NRCan lakes

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 

Re: [Talk-ca] NRCan lakes

[Hannes Röst]

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

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 
https://www.openstreetmap.org/way/129592036 and 
https://www.openstreetmap.org/way/129592039 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 https://www.openstreetmap.org/way/129592307 and 
https://www.openstreetmap.org/way/129592315 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.
 
> 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.
 
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]).
 
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: 
http://osmose.openstreetmap.fr/en/map/#zoom=12=46.0489=-77.5019==1==
 
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 
https://www.openstreetmap.org/way/129591734 (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 ?
 
Best
 
Hannes
 
1. https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007225.html
2. https://ftp.maps.canada.ca/pub/nrcan_rncan/vector/osm/
 

Gesendet: Dienstag, 07. Juli 2020 um 12:18 Uhr
Von: "Pierre Béland" 
An: "Talk-CA OpenStreetMap" 
Cc: "Hannes Röst" 
Betreff: Re: [Talk-ca] NRCan lakes

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[https://www.openstreetmap.org/way/60854569]
- le multipolygone 
https://www.openstreetmap.org/way/946291[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[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 

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

[Jason Carlson]

Thanks James. That's a good idea to create web documentation like that,
obviously learning from the past. With it there is no guessing later down
the road as to what is what if something needs to be modified, where it
came from, etc.

I have a couple of time consuming projects on the go now so will look to do
this later this fall.

*Jason*

On Tue, Jul 7, 2020 at 3:41 PM James  wrote:

> 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