Re: [Talk-ca] Canvec Import

[Viajero Perdido]

From: James 

not sure why Canvec always gets shat uppon, their water features are great
and pretty accurate


Bovine excrement.  Do I need to make an exhaustive list of the 
water-feature nonsense I keep finding?  Lakes dry up, and rivers change 
course (especially around Calgary in 2013).  Somebody imported a whole 
swath of ponds and lakes in NE Alberta, where a glance at imagery shows 
few if any still exist; it's all farmland now.


CanVec gets shat upon because the data quality is shite.  You can put 
water features in the BAD column along with landcover, POIs (schools are 
not prisons), trails (approximate is not good enough), and so on.


I am part of the CanVec immune system, because I want to see us create a 
*quality* map.


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

Re: [Talk-ca] canvec imports

[Matthew Darwin]

Andrew,

Keep up the great work making OSM great for Canada.


On 2018-11-27 1:36 p.m., Andrew Lester wrote:
I agree. A selective import from CANVEC is fine and generally gives 
good results. As long as you don't import things like forests and 
buildings (which are both woefully out-of-date, broken, or outright 
wrong), there usually isn't a problem. However, if someone just 
imports an entire block of data without inspecting it, that's when 
we run into the visible issues that the peanut gallery picks apart.


Andrew
Victoria, BC

--
*From: *"James" 
*To: *"Andrew" 
*Cc: *"talk-ca" 
*Sent: *Tuesday, November 27, 2018 9:58:19 AM
*Subject: *Re: [Talk-ca] canvec imports

not sure why Canvec always gets shat uppon, their water features are 
great and pretty accurate, the forest/landcover on the other hand 
needs fixing before import. I think it's clear enough on the canvec 
wiki page that only experienced mappers/importers should attempt a 
canvec import.


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

Re: [Talk-ca] canvec imports

[Andrew Lester]

I agree. A selective import from CANVEC is fine and generally gives good 
results. As long as you don't import things like forests and buildings (which 
are both woefully out-of-date, broken, or outright wrong), there usually isn't 
a problem. However, if someone just imports an entire block of data without 
inspecting it, that's when we run into the visible issues that the peanut 
gallery picks apart. 

Andrew 
Victoria, BC 


From: "James"  
To: "Andrew"  
Cc: "talk-ca"  
Sent: Tuesday, November 27, 2018 9:58:19 AM 
Subject: Re: [Talk-ca] canvec imports 

not sure why Canvec always gets shat uppon, their water features are great and 
pretty accurate, the forest/landcover on the other hand needs fixing before 
import. I think it's clear enough on the canvec wiki page that only experienced 
mappers/importers should attempt a canvec import. 

On Tue., Nov. 27, 2018, 12:54 p.m. Andrew < andrew.alli...@teksavvy.com wrote: 


FYI Canada 

I made a few imports to canada a while ago and apparently 
raised the ire of someone. 

Here we go again :-( 

--- 
This was the first message 

>>Please, fix issues caused by this changeset for example in region of 

Yup, that was it, I was like ok, whats wrong with the changeset? Found 
an overlapping way. Figured that was it :-) 

And now 

Where is documentation page of this import? Can you link to discussion 
done before this import started? 

And So On. 

--- 
Hi PurpleMustang, 

XXX X has sent you a message through OpenStreetMap with the 
subject Re: Canvec Import: 

XXX X 
On 2018-11-27 17:21:34 UTC PurpleMustang wrote: 

Hello: This import has been a work in progress for about 10 years now 
:-) 

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

https://wiki.openstreetmap.org/wiki/Geobase/Announcement 

Andrew 

Note that currently active import should have a wiki page describing 
what exactly is imported and how data is processed - see 
https://wiki.openstreetmap.org/wiki/Automated_ 

 

Oh Well Here we go again 

Andrew 
aka CanvecImports 


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

Re: [Talk-ca] canvec imports

[James]

not sure why Canvec always gets shat uppon, their water features are great
and pretty accurate, the forest/landcover on the other hand needs fixing
before import. I think it's clear enough on the canvec wiki page that only
experienced mappers/importers should attempt a canvec import.

On Tue., Nov. 27, 2018, 12:54 p.m. Andrew  FYI Canada
>
> I made a few imports to canada a while ago and apparently
> raised the ire of someone.
>
> Here we go again :-(
>
> ---
> This was the first message
>
> >>Please, fix issues caused by this changeset for example in region of
>
> Yup, that was it, I was like ok, whats wrong with the changeset? Found
> an overlapping way. Figured that was it :-)
>
> And now
>
> Where is documentation page of this import? Can you link to discussion
> done before this import started?
>
> And So On.
>
> ---
> Hi PurpleMustang,
>
> XXX X has sent you a message through OpenStreetMap with the
> subject Re: Canvec Import:
>
> XXX X
> On 2018-11-27 17:21:34 UTC PurpleMustang wrote:
>
> Hello: This import has been a work in progress for about 10 years now
> :-)
>
> https://wiki.openstreetmap.org/wiki/Import/Catalogue
>
> https://wiki.openstreetmap.org/wiki/Geobase/Announcement
>
> Andrew
>
> Note that currently active import should have a wiki page describing
> what exactly is imported and how data is processed - see
> https://wiki.openstreetmap.org/wiki/Automated_
>
> 
>
> Oh Well Here we go again
>
> Andrew
> aka CanvecImports
>
>
> ___
> 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] Canvec forest redux

[Paul Ramsey]

On Thu, Sep 29, 2016 at 5:58 PM, Adam Martin 
wrote:
>
> You know, it suddenly strikes me that part of the reason that there is so
> much trouble with the forest polygons from the Canvec data is less the
> accuracy of the data and more the fact that it is brutally difficult to
> work with.
>

This is my complaint about the forests. It's not just the fact they are
loaded as complex features, it's that even the simple polygons are just
packed full of vertices. So modifying them requires 5x the work of
modifying other things. They're only partially loaded into OSM and unlikely
to be updated. If there was ever a feature that a human-mediated map like
OSM should skip, it's this kind of landcover stuff: if one needs a
landcover in ones map, get a computer to do a classification of landsat 8,
and load that into your map, it'll be better in a global sense than the
handballed thing, and far more up to date than hand-massaged forest
polygons that were captured in the mid-80s.

P.




> These enormous multipolygon relations, linking the forests to open areas,
> wet lands, and water polygons, creating inner and outer relationships all
> within the confines of the Natural Resources map divisions. I wonder would
> these be nearly as hard to work with if the multpolygon relation itself
> didn't exist? I understand the reasoning for relations themselves - they
> are core mapping elements meant to describe logical arrangements between
> items. Bus routes are one of the prime examples of such a thing. Has anyone
> leaned back and just considered that, in the case of this forest data, we
> might be going a bit far to have inner and outer boundaries to describe
> breaks in the tree line? Think of it this way, what is the use of a
> multipolygon relation? In the Wiki, it is used to create an area for which
> the boundary is defined by multiple ways and / or an area possessing holes.
> When we import a forest multipolygon, what are we trying to describe
> exactly? An area of forest  with holes ... which are not holes, but are
> simply areas when the tree line breaks and another feature is present (open
> grassy area, a lake, a marsh, etc. Looking over some of these polygons, it
> is notable that houses or owned are often not provided a gap if they are
> not in a city centre. Even more unnerving is the fact that roads, major or
> minor, are also not provided gaps nor are they part of the relation.
> Essentially, the most important human feature of an area - the
> transportation network, is not important enough to be part of the relation.
>
> Perhaps it would be better to eliminate the multipolygon itself? Simply
> map the forest areas and open areas and lakes and so forth and add them to
> logical relations afterwards. Take my home province of Newfoundland. If one
> were to build a forest polygon, it could be logically broken down into
> regional multipolygons (such as one for the Avalon Penninsula). Or it could
> even be further divided based on localized geometry.
>
> Just some thoughts on the matter.
>
> Adam
>
> On Thu, Sep 29, 2016 at 6:26 PM, Sam Dyck  wrote:
>
>> Hi everyone
>>
>> Sorry for bringing this up, but I need to some Canvec importing. Given
>> the controversy about Canvec earlier this month, I'm trying to decide how
>> to do this. I could:
>>
>> - Leave the forests out entirely.
>> - Or use it as an opportunity to experiment with the Manitoba Lands
>> Initiative forest data. We've discussed MLI before and done some limited
>> importing. And I'm curious to take a look at the data.
>>
>> Thoughts?
>>
>> Sam
>>
>> ___
>> 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
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Canvec forest redux

[Sam Dyck]

Hi everyone

Sorry for bringing this up, but I need to some Canvec importing. Given the
controversy about Canvec earlier this month, I'm trying to decide how to do
this. I could:

- Leave the forests out entirely.
- Or use it as an opportunity to experiment with the Manitoba Lands
Initiative forest data. We've discussed MLI before and done some limited
importing. And I'm curious to take a look at the data.

Thoughts?

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

Re: [Talk-ca] Canvec attributes (roads)

[Begin Daniel]

Martjin, 
You can get current information about how old/accurate the data are using the 
above link.

http://geogratis.gc.ca/api/en/nrcan-rncan/ess-sst/-/(urn:iso:series)geobase-national-road-network-nrn?sort-field=relevance

To get the answer you need to look at the metadata: 
You select the area you are interested in (click)
You need to view the full metadata (formatted NAP) (click)
Look for the above tags under "dataQualityInfo" 
"DQ_AbsoluteExternalPositionalAccuracy"
You will find 1:N Distance values that describe how accurate the data are. 
"EX_TemporalExtent"
You will find 1:N timePosition values that describe how old the data are.

The same should apply for the other layers (NHN, NRWN...), even if the 
distribution units may differ (whole country, watershed ...)

Daniel

-Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Tuesday, 13 September, 2016 07:53
To: Martijn van Exel; Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec attributes (roads)

Bonjour Martijn
AFAIK, here is a summary about how old and accurate is Canvec/GeoBase. 

Transport Layers? 
The roads are updated every 1-2 years for most of the provinces, 5-10 for 
others. 
Railways were updated 4-5 years ago over all the Canadian landmass.

Other layers
Water features are 5-40+ years old depending on the 
province/territory/latitude; Forest areas are 5-40+ years old depending on the 
province/territory/latitude [1]. 
The rest is 25-40+ years old.

About the accuracy, the road network is about 10m (90%). The rest is usually 
better than 30m (90%) but you may find offsets between layers.

Daniel

[1] About forest areas, the latest GeoBase data results from images 
classification made about 5 years ago that gave the clumsy result Paul Ramsay 
recently shown on this list. The latest Canvec OSM tiles (2012?) had a mixture 
of old map data/new GeoBase data.

-Original Message-
From: Martijn van Exel [mailto:m...@rtijn.org]
Sent: Monday, 12 September, 2016 23:06
To: Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec attributes (roads)

On 09/12/2016 06:50 PM, Stewart C. Russell wrote:
> On 2016-09-12 04:08 PM, Martijn van Exel wrote:
>> Aren't these files grouped by feature type? So if we look at roads we 
>> wouldn't also necessarily need to look at land use boundaries etc.?
>
> Canvec - the product supplied by NRCan to the general public - always 
> was split by feature type. It's the OSM tiles, of structure decided 
> long ago, that lump everything together.
>
> It's also available as effectively seamless FGDBs if you want to avoid 
> the cleanup required after using tiled data. The FGDBs retain the 
> critically important survey dates and accuracies - so you can easily 
> see how much data's 40 years old and has ±75 m positional accuracy.
>

Good to know.
Are any of the transport related datasets that old or that inaccurate?

I created an initial Canvec road network translation file for ogr2osm, so you 
can convert the Canvec shapefiles to OSM format easily (if you know how to work 
ogr2osm - let me know if you need help, but Paul Norman is the expert here!)

It is located at
https://github.com/mvexel/canvec-ogr2osm-translation/blob/master/canvec2016.py
and I hope for many forks and improvements. Right now it does a basic job of 
translating the road classes to OSM types, and the most obvious attributes to 
the corresponding OSM tags.

Let me know what you all think.

Martijn

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

Re: [Talk-ca] Canvec attributes (roads)

[Begin Daniel]

Bonjour Martijn
AFAIK, here is a summary about how old and accurate is Canvec/GeoBase. 

Transport Layers? 
The roads are updated every 1-2 years for most of the provinces, 5-10 for 
others. 
Railways were updated 4-5 years ago over all the Canadian landmass.

Other layers
Water features are 5-40+ years old depending on the province/territory/latitude;
Forest areas are 5-40+ years old depending on the province/territory/latitude 
[1]. 
The rest is 25-40+ years old.

About the accuracy, the road network is about 10m (90%). The rest is usually 
better than 30m (90%) but you may find offsets between layers.

Daniel

[1] About forest areas, the latest GeoBase data results from images 
classification made about 5 years ago that gave the clumsy result Paul Ramsay 
recently shown on this list. The latest Canvec OSM tiles (2012?) had a mixture 
of old map data/new GeoBase data.

-Original Message-
From: Martijn van Exel [mailto:m...@rtijn.org] 
Sent: Monday, 12 September, 2016 23:06
To: Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec attributes (roads)

On 09/12/2016 06:50 PM, Stewart C. Russell wrote:
> On 2016-09-12 04:08 PM, Martijn van Exel wrote:
>> Aren't these files grouped by feature type? So if we look at roads we 
>> wouldn't also necessarily need to look at land use boundaries etc.?
>
> Canvec - the product supplied by NRCan to the general public - always 
> was split by feature type. It's the OSM tiles, of structure decided 
> long ago, that lump everything together.
>
> It's also available as effectively seamless FGDBs if you want to avoid 
> the cleanup required after using tiled data. The FGDBs retain the 
> critically important survey dates and accuracies - so you can easily 
> see how much data's 40 years old and has ±75 m positional accuracy.
>

Good to know.
Are any of the transport related datasets that old or that inaccurate?

I created an initial Canvec road network translation file for ogr2osm, so you 
can convert the Canvec shapefiles to OSM format easily (if you know how to work 
ogr2osm - let me know if you need help, but Paul Norman is the expert here!)

It is located at
https://github.com/mvexel/canvec-ogr2osm-translation/blob/master/canvec2016.py
and I hope for many forks and improvements. Right now it does a basic job of 
translating the road classes to OSM types, and the most obvious attributes to 
the corresponding OSM tags.

Let me know what you all think.

Martijn

___
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] Canvec attributes (roads)

[Martijn van Exel]

On 09/12/2016 06:50 PM, Stewart C. Russell wrote:

On 2016-09-12 04:08 PM, Martijn van Exel wrote:

Aren't these files grouped by feature type? So if we look at roads we
wouldn't also necessarily need to look at land use boundaries etc.?


Canvec - the product supplied by NRCan to the general public - always
was split by feature type. It's the OSM tiles, of structure decided long
ago, that lump everything together.

It's also available as effectively seamless FGDBs if you want to avoid
the cleanup required after using tiled data. The FGDBs retain the
critically important survey dates and accuracies - so you can easily see
how much data's 40 years old and has ±75 m positional accuracy.



Good to know.
Are any of the transport related datasets that old or that inaccurate?

I created an initial Canvec road network translation file for ogr2osm, 
so you can convert the Canvec shapefiles to OSM format easily (if you 
know how to work ogr2osm - let me know if you need help, but Paul Norman 
is the expert here!)


It is located at 
https://github.com/mvexel/canvec-ogr2osm-translation/blob/master/canvec2016.py 
and I hope for many forks and improvements. Right now it does a basic 
job of translating the road classes to OSM types, and the most obvious 
attributes to the corresponding OSM tags.


Let me know what you all think.

Martijn

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

Re: [Talk-ca] Canvec attributes (roads)

[James]

Yes the new canvec are split into different types of data: hydro data(lakes
rivers etc), forest(loads of fun),  transportation(this is what you want),
etc

On Sep 12, 2016 4:08 PM, "Martijn van Exel"  wrote:

> Aren't these files grouped by feature type? So if we look at roads we
> wouldn't also necessarily need to look at land use boundaries etc.? At
> least that's what I am getting looking at http://geogratis.gc.ca/api/
> en/nrcan-rncan/ess-sst/23387971-b6d3-4ded-a40b-c8e832b4ea08.html
>
> --
>   Martijn van Exel
>   m...@rtijn.org
>
>
>
> On Sun, Sep 11, 2016, at 12:59, James wrote:
>
> Plus it would help identify which parts and canvec are actually needed vs
> importing a bunch of forests and hoping for some roads
>
> On Sep 11, 2016 2:48 PM, "John Marshall"  wrote:
>
> Great idea Martijn,
>
> One of the big problems of OSM in Canada is there are many missing road
> where there are no local mappers. Canada is very big. Any tools to help map
> unmapped area of Canada gets a big +1 from me.
>
> John
>
> John Marshall
>
> On Sep 9, 2016 17:36, "Martijn van Exel"  wrote:
>
> Hi all,
>
> A few colleagues at Telenav and myself are looking at Canvec 2016. Roads
> specifically. I am sure some of you already have done that. Something we
> are looking into a workflow that is something like this (simplified):
>
> Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) --> Tasking
> manager
>
> The output of the conflation would be an OSM XML change file that could
> be (selectively) applied in JOSM. It would contain new / changed ways as
> well as some new or changed tags. All proposed updates would be verified
> manually (through tasking manager.)
>
> What do you think about this idea?
>
> The conflation engine takes OSM PBF as input, so the Canvec shapefiles
> would need to be translated (using ogr2osm). That would require an
> ogr2osm translation file. I wonder if someone already did this? (I am
> using this [2] attribute list as reference.)
>
> [1]https://www.openstreetmap.org/user/mvexel/diary/37808
> [2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/
> doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_Trans
> port-sd-en.html#div-1330009
> --
> Martijn van Exel
> m...@rtijn.org
>
> ___
> 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
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec attributes (roads)

[Martijn van Exel]

Aren't these files grouped by feature type? So if we look at roads we
wouldn't also necessarily need to look at land use boundaries etc.? At
least that's what I am getting looking at
http://geogratis.gc.ca/api/en/nrcan-rncan/ess-sst/23387971-b6d3-4ded-a40b-c8e832b4ea08.html

--
  Martijn van Exel
  m...@rtijn.org



On Sun, Sep 11, 2016, at 12:59, James wrote:
> Plus it would help identify which parts and canvec are actually needed
> vs importing a bunch of forests and hoping for some roads
>
> On Sep 11, 2016 2:48 PM, "John Marshall"  wrote:
>> Great idea Martijn,
>> One of the big problems of OSM in Canada is there are many missing
>> road where there are no local mappers. Canada is very big. Any tools
>> to help map unmapped area of Canada gets a big +1 from me.
>> John
>> John Marshall
>>
>> On Sep 9, 2016 17:36, "Martijn van Exel"  wrote:
>>> Hi all,
>>>
>>>  A few colleagues at Telenav and myself are looking at Canvec 2016.
>>>  Roads
>>>  specifically. I am sure some of you already have done that.
>>>  Something we
>>>  are looking into a workflow that is something like this
>>>  (simplified):
>>>
>>>  Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) -->
>>>  Tasking
>>>  manager
>>>
>>>  The output of the conflation would be an OSM XML change file that
>>>  could
>>>  be (selectively) applied in JOSM. It would contain new / changed
>>>  ways as
>>>  well as some new or changed tags. All proposed updates would be
>>>  verified
>>>  manually (through tasking manager.)
>>>
>>>  What do you think about this idea?
>>>
>>>  The conflation engine takes OSM PBF as input, so the Canvec
>>>  shapefiles
>>>  would need to be translated (using ogr2osm). That would require an
>>>  ogr2osm translation file. I wonder if someone already did this?
>>>  (I am
>>>  using this [2] attribute list as reference.)
>>>
>>>  [1]https://www.openstreetmap.org/user/mvexel/diary/37808
>>>  
>>> [2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_Transport-sd-en.html#div-1330009
>>>  --
>>>  Martijn van Exel
>>> m...@rtijn.org
>>>
>>>  ___
>>>  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
>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec attributes (roads)

[Martijn van Exel]

Paul, 
thanks, so perhaps we can start a new one for this data.
Perhaps we can crowdsource it? Has that been done before?

(Wouldn't it be interesting to have a github repo with the translation
file, and each time a commit is made an ogr2osm run is fired and the
resulting OSM file made available somewhere?)
-- 
  Martijn van Exel
  m...@rtijn.org

On Fri, Sep 9, 2016, at 15:54, Paul Norman wrote:
> On 9/9/2016 2:34 PM, Martijn van Exel wrote:
> > The conflation engine takes OSM PBF as input, so the Canvec shapefiles
> > would need to be translated (using ogr2osm).
> 
> The CanVec we've used in the past has been supplied in OSM XML format. 
> No one has proposed a new import with a different format, so I doubt 
> there are any ogr2osm translations available.
> 
> ___
> 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] Canvec attributes (roads)

[Pierre Béland]

A faire attention
Dans les zones forestières au nord, au Québec à tout le moins, il y a beaucoup 
de chemins forestiers temporaires pour la coupe de bois. Ces chemins et ponts 
ne sont pas entretenus par la suite. 

J'ai beaucoup cartographié des chemins au nord du Québec. A mon avis, seul les 
chemins principaux doivent être tracés.  Pour les autres, on ne peut se fier 
aux images satellites pour déterminer le statut des chemins.  Sur les chemins 
principaux, des camions hors norme font le transport de bois et ont la 
priorité.  Les routes ne sont en général pas carrossables pour les voitures. Il 
faut au minimum un pickup + CB pour annoncer sa présence aux camions.
  
Pierre 


  De : James <james2...@gmail.com>
 À : John Marshall <rps...@gmail.com> 
Cc : Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
 Envoyé le : Dimanche 11 Septembre 2016 14h59
 Objet : Re: [Talk-ca] Canvec attributes (roads)
   
Plus it would help identify which parts and canvec are actually needed vs 
importing a bunch of forests and hoping for some roads
On Sep 11, 2016 2:48 PM, "John Marshall" <rps...@gmail.com> wrote:

Great idea Martijn,One of the big problems of OSM in Canada is there are many 
missing road where there are no local mappers. Canada is very big. Any tools to 
help map unmapped area of Canada gets a big +1 from me.JohnJohn Marshall
On Sep 9, 2016 17:36, "Martijn van Exel" <m...@rtijn.org> wrote:

Hi all,

A few colleagues at Telenav and myself are looking at Canvec 2016. Roads
specifically. I am sure some of you already have done that. Something we
are looking into a workflow that is something like this (simplified):

Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) --> Tasking
manager

The output of the conflation would be an OSM XML change file that could
be (selectively) applied in JOSM. It would contain new / changed ways as
well as some new or changed tags. All proposed updates would be verified
manually (through tasking manager.)

What do you think about this idea?

The conflation engine takes OSM PBF as input, so the Canvec shapefiles
would need to be translated (using ogr2osm). That would require an
ogr2osm translation file. I wonder if someone already did this? (I am
using this [2] attribute list as reference.)

[1]https://www.openstreetmap.o rg/user/mvexel/diary/37808
[2]http://ftp.geogratis.gc.ca/ pub/nrcan_rncan/vector/canvec/ 
doc/CanVec_Catalogue_50K_Trans port/SRDB_EXPL_ESSIM_50K_Trans 
port-sd-en.html#div-1330009
--
  Martijn van Exel
  m...@rtijn.org

__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.or g/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


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

Re: [Talk-ca] Canvec attributes (roads)

[James]

Plus it would help identify which parts and canvec are actually needed vs
importing a bunch of forests and hoping for some roads

On Sep 11, 2016 2:48 PM, "John Marshall"  wrote:

> Great idea Martijn,
>
> One of the big problems of OSM in Canada is there are many missing road
> where there are no local mappers. Canada is very big. Any tools to help map
> unmapped area of Canada gets a big +1 from me.
>
> John
>
> John Marshall
>
> On Sep 9, 2016 17:36, "Martijn van Exel"  wrote:
>
>> Hi all,
>>
>> A few colleagues at Telenav and myself are looking at Canvec 2016. Roads
>> specifically. I am sure some of you already have done that. Something we
>> are looking into a workflow that is something like this (simplified):
>>
>> Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) --> Tasking
>> manager
>>
>> The output of the conflation would be an OSM XML change file that could
>> be (selectively) applied in JOSM. It would contain new / changed ways as
>> well as some new or changed tags. All proposed updates would be verified
>> manually (through tasking manager.)
>>
>> What do you think about this idea?
>>
>> The conflation engine takes OSM PBF as input, so the Canvec shapefiles
>> would need to be translated (using ogr2osm). That would require an
>> ogr2osm translation file. I wonder if someone already did this? (I am
>> using this [2] attribute list as reference.)
>>
>> [1]https://www.openstreetmap.org/user/mvexel/diary/37808
>> [2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/
>> doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_Trans
>> port-sd-en.html#div-1330009
>> --
>>   Martijn van Exel
>>   m...@rtijn.org
>>
>> ___
>> 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
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec attributes (roads)

[John Marshall]

Great idea Martijn,

One of the big problems of OSM in Canada is there are many missing road
where there are no local mappers. Canada is very big. Any tools to help map
unmapped area of Canada gets a big +1 from me.

John

John Marshall

On Sep 9, 2016 17:36, "Martijn van Exel"  wrote:

> Hi all,
>
> A few colleagues at Telenav and myself are looking at Canvec 2016. Roads
> specifically. I am sure some of you already have done that. Something we
> are looking into a workflow that is something like this (simplified):
>
> Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) --> Tasking
> manager
>
> The output of the conflation would be an OSM XML change file that could
> be (selectively) applied in JOSM. It would contain new / changed ways as
> well as some new or changed tags. All proposed updates would be verified
> manually (through tasking manager.)
>
> What do you think about this idea?
>
> The conflation engine takes OSM PBF as input, so the Canvec shapefiles
> would need to be translated (using ogr2osm). That would require an
> ogr2osm translation file. I wonder if someone already did this? (I am
> using this [2] attribute list as reference.)
>
> [1]https://www.openstreetmap.org/user/mvexel/diary/37808
> [2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/
> doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_
> Transport-sd-en.html#div-1330009
> --
>   Martijn van Exel
>   m...@rtijn.org
>
> ___
> 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] Canvec attributes (roads)

[Paul Norman]

On 9/9/2016 2:34 PM, Martijn van Exel wrote:

The conflation engine takes OSM PBF as input, so the Canvec shapefiles
would need to be translated (using ogr2osm).


The CanVec we've used in the past has been supplied in OSM XML format. 
No one has proposed a new import with a different format, so I doubt 
there are any ogr2osm translations available.


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

[Talk-ca] Canvec attributes (roads)

[Martijn van Exel]

Hi all, 

A few colleagues at Telenav and myself are looking at Canvec 2016. Roads
specifically. I am sure some of you already have done that. Something we
are looking into a workflow that is something like this (simplified):

Canvec 2016 Shapefiles --> Conflation engine (Cygnus [1]) --> Tasking
manager

The output of the conflation would be an OSM XML change file that could
be (selectively) applied in JOSM. It would contain new / changed ways as
well as some new or changed tags. All proposed updates would be verified
manually (through tasking manager.)

What do you think about this idea?

The conflation engine takes OSM PBF as input, so the Canvec shapefiles
would need to be translated (using ogr2osm). That would require an
ogr2osm translation file. I wonder if someone already did this? (I am
using this [2] attribute list as reference.)

[1]https://www.openstreetmap.org/user/mvexel/diary/37808
[2]http://ftp.geogratis.gc.ca/pub/nrcan_rncan/vector/canvec/doc/CanVec_Catalogue_50K_Transport/SRDB_EXPL_ESSIM_50K_Transport-sd-en.html#div-1330009
-- 
  Martijn van Exel
  m...@rtijn.org

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

Re: [Talk-ca] Canvec Reverts

[James]

I agree that forest that are way too costly in time should be removed, but
they should also be replaced with something(better) not just mass removed,
oh well we'll get to it later kind of thing

On Sep 1, 2016 8:05 PM, "Sam Dyck"  wrote:

>  I took a break to make supper, so I'm going to have to respond
> collectively.
>
> - Sammuell and sammuell_imports are my accounts. Both the forest and the
> lake are from Canvec data imported together as in the same tile. I Imported
> the whole thing (I would never import over existing data that carelessly),
> and take responsibility for that.
>
> - As my subsequent email showed, I missed the part about water/forest
> overlaps in Paul's email. Both and other people on this list have explained
> our feelings about this, but I will accept DWGs decision.
>
> - Per Michael's suggestion: This is constructive, but I do not feel that
> it is feasible because of the tiled structure of Canvec. To try and shift
> the forest layer over would make the problem worse.
>
> - Removal of the forest layer may be the best solution here. However there
> are many places in where the data matches up perfectly. Speaking only of
> areas where I am the primary importer, most of the forests in Ontario west
> of Thunder Bay would have to go, which is unfortunate because some have
> been manually corrected, though not enough to save them. Much (but
> certainly not all) of the forests in Manitoba could be saved with minimal
> effort.
>
> - If/when this is done we could look at ways to restore these forests. In
> areas that are mostly forest it shouldn't be too difficult to fill them
> using large multipolygons.
>
> Sam
>
> ___
> 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] Canvec Reverts

[Sam Dyck]

 I took a break to make supper, so I'm going to have to respond
collectively.

- Sammuell and sammuell_imports are my accounts. Both the forest and the
lake are from Canvec data imported together as in the same tile. I Imported
the whole thing (I would never import over existing data that carelessly),
and take responsibility for that.

- As my subsequent email showed, I missed the part about water/forest
overlaps in Paul's email. Both and other people on this list have explained
our feelings about this, but I will accept DWGs decision.

- Per Michael's suggestion: This is constructive, but I do not feel that it
is feasible because of the tiled structure of Canvec. To try and shift the
forest layer over would make the problem worse.

- Removal of the forest layer may be the best solution here. However there
are many places in where the data matches up perfectly. Speaking only of
areas where I am the primary importer, most of the forests in Ontario west
of Thunder Bay would have to go, which is unfortunate because some have
been manually corrected, though not enough to save them. Much (but
certainly not all) of the forests in Manitoba could be saved with minimal
effort.

- If/when this is done we could look at ways to restore these forests. In
areas that are mostly forest it shouldn't be too difficult to fill them
using large multipolygons.

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

Re: [Talk-ca] CanVec Reverts

[Alan Richards]

I agree with Frederik here. New imports need to make sure they follow the
import guidelines, including using a dedicated import account.

The wiki information could all be cleaned up, consolidated, and then new
users would know the current status and process for importing new
information.

For cleaning up the existing information, I like the idea of getting some
MapRoulette tasks going, or maybe writing some new validations in osmlint,
osmose, etc.
Certainly in the BC and Ontario data I've seen, it's not just the forest
that is problematic, but also the water layer. Creeks occasionally flow the
wrong way (a bad very old import I suspect), lakes and wetlands are
mixed/overlaid.

Alan (alarobric)

On Thu, Sep 1, 2016 at 4:30 PM, john whelan  wrote:

> >I think a super good first step would be try and ensure that future
> imports are done diligently and don't introduce new issues.
>
> I think that is a reasonable way forward, and I concur with the rest of
> your post.
>
> I think we need to identify which parts of CANVEC are giving concern, each
> province is a different mixture of data sources, I suspect it is the forest
> and land use that are the most problematic.
>
> The older tiles had a problem in that a highway would reach the edge of
> the tile and there would be a matching highway on the next tile but there
> was no connection.  I spent many a happy hour, too many of them, merging
> nodes so routing would work.  I think the cities have been cleaned up but
> more rural areas still have the odd one or two to do.
>
> Probably what would make a lot of sense as a next step is to grab the
> provincial OSM dumps, chop them up into manageable portions then load them
> up into JOSM and run a modern validation on them.
>
> Cheerio John
>
> On 1 September 2016 at 19:13, Frederik Ramm  wrote:
>
>> Andrew,
>>
>> On 09/02/2016 12:47 AM, Andrew Lester wrote:
>> > If people from outside of Canada have decided that our data is so bad
>> > that it needs to be completely wiped out in its entirety, then I guess
>> > we're going to have to do something drastic to try to prevent this.
>>
>> I think a super good first step would be try and ensure that future
>> imports are done diligently and don't introduce new issues. (This might
>> be the "better documentation" step that Paul mentioned.) It really
>> shouldn't be too hard to detect whether your planned import causes
>> overlapping lakes and forests, but there needs to be an agreement that
>> these things matter and that you cannot simply upload "because if CanVec
>> says that forest and water overlap then this must be true".
>>
>> Then one could take stock of existing issues and make a plan on how to
>> fix them.
>>
>> Whether fixing existing issues will necessitate the wholesale removal of
>> some imports is something that should be decided down the line; I know
>> too little about CanVec imports to say whether some problems are
>> systemic in the data source, or certain regions, or just introduced by
>> clumsy importers. Any large-scale removal of imported data (perhaps to
>> replace it with new, better-imported data) would also have to take into
>> account potential manual work that has been performed on the imported by
>> mappers with local knowledge and it would be sad to lose that.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> 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
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec Reverts

[john whelan]

>I think a super good first step would be try and ensure that future
imports are done diligently and don't introduce new issues.

I think that is a reasonable way forward, and I concur with the rest of
your post.

I think we need to identify which parts of CANVEC are giving concern, each
province is a different mixture of data sources, I suspect it is the forest
and land use that are the most problematic.

The older tiles had a problem in that a highway would reach the edge of the
tile and there would be a matching highway on the next tile but there was
no connection.  I spent many a happy hour, too many of them, merging nodes
so routing would work.  I think the cities have been cleaned up but more
rural areas still have the odd one or two to do.

Probably what would make a lot of sense as a next step is to grab the
provincial OSM dumps, chop them up into manageable portions then load them
up into JOSM and run a modern validation on them.

Cheerio John

On 1 September 2016 at 19:13, Frederik Ramm  wrote:

> Andrew,
>
> On 09/02/2016 12:47 AM, Andrew Lester wrote:
> > If people from outside of Canada have decided that our data is so bad
> > that it needs to be completely wiped out in its entirety, then I guess
> > we're going to have to do something drastic to try to prevent this.
>
> I think a super good first step would be try and ensure that future
> imports are done diligently and don't introduce new issues. (This might
> be the "better documentation" step that Paul mentioned.) It really
> shouldn't be too hard to detect whether your planned import causes
> overlapping lakes and forests, but there needs to be an agreement that
> these things matter and that you cannot simply upload "because if CanVec
> says that forest and water overlap then this must be true".
>
> Then one could take stock of existing issues and make a plan on how to
> fix them.
>
> Whether fixing existing issues will necessitate the wholesale removal of
> some imports is something that should be decided down the line; I know
> too little about CanVec imports to say whether some problems are
> systemic in the data source, or certain regions, or just introduced by
> clumsy importers. Any large-scale removal of imported data (perhaps to
> replace it with new, better-imported data) would also have to take into
> account potential manual work that has been performed on the imported by
> mappers with local knowledge and it would be sad to lose that.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] CanVec Reverts

[Frederik Ramm]

Andrew,

On 09/02/2016 12:47 AM, Andrew Lester wrote:
> If people from outside of Canada have decided that our data is so bad
> that it needs to be completely wiped out in its entirety, then I guess
> we're going to have to do something drastic to try to prevent this.

I think a super good first step would be try and ensure that future
imports are done diligently and don't introduce new issues. (This might
be the "better documentation" step that Paul mentioned.) It really
shouldn't be too hard to detect whether your planned import causes
overlapping lakes and forests, but there needs to be an agreement that
these things matter and that you cannot simply upload "because if CanVec
says that forest and water overlap then this must be true".

Then one could take stock of existing issues and make a plan on how to
fix them.

Whether fixing existing issues will necessitate the wholesale removal of
some imports is something that should be decided down the line; I know
too little about CanVec imports to say whether some problems are
systemic in the data source, or certain regions, or just introduced by
clumsy importers. Any large-scale removal of imported data (perhaps to
replace it with new, better-imported data) would also have to take into
account potential manual work that has been performed on the imported by
mappers with local knowledge and it would be sad to lose that.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-ca] CanVec Reverts

[Andrew Lester]

If people from outside of Canada have decided that our data is so bad that it 
needs to be completely wiped out in its entirety, then I guess we're going to 
have to do something drastic to try to prevent this. 

@Michael, Frederik, Paul: would it be good enough for us to wipe out any and 
all CanVec forest data (or even ALL forest data because some could have been 
derived from CanVec)? This seems to be the biggest cause for concern. If not, 
what do you think we need to do to prevent all CanVec data from being wiped 
out? Wiping out all CanVec data would effectively clear out the majority of the 
Canadian map and really isn't an option in our minds. Do we need to get rid of 
all forest data and then go on a cooperative fixing blitz (maybe using 
MapRoulette or Tasking Manager) to fix every single JOSM validator error across 
the country? In short, if we're doing things so wrong, what can we do to make 
things right other than have a German revert all of our changesets so we can 
start from scratch? 

Andrew 
Victoria, BC, Canada 

- Original Message -

From: "Sam Dyck" <samueld...@gmail.com> 
To: "Talk-CA OpenStreetMap" <talk-ca@openstreetmap.org> 
Sent: Thursday, September 1, 2016 2:38:38 PM 
Subject: Re: [Talk-ca] CanVec Reverts 


After reading Paul's email again, its possible that what Nakaner is doing is in 
line with Paul's suggestion, if unnecessarily confrontational. I tried to play 
around in JOSM to see if I could get the forest polygons to a point where 
Nakaner would leave us alone by mercilessly deleting all of the inner ways in 
the forest multipolygons, but because of the way things are structured around 
rivers that would be several hours worth of work for one tile. Given this 
perhaps the only solution is to bulk delete all Canvec forest data. As someone 
who actually finds the forest data useful this would be extremely unfortunate, 
but if it allows us to continue imports without excessive external scrutiny 
then I am willing to except it. (apologies for the English only emails, my 
French writing skills are sadly lacking) 



On Thu, Sep 1, 2016 at 4:20 PM, Pierre Béland < pierz...@yahoo.fr > wrote: 




L'idéal préparer Une réponse standard indiquant que l'Import Canvec par la 
communauté OSM Canada est itératif et nous nous assurons collectivement 
d'améliorer les données. Voir page Wiki Import Canvec et venir discuter sur 
Talk-Ca si vous avez d'autres questions. 




Pierre 








De : Sam Dyck < samueld...@gmail.com > 
À : Talk-CA OpenStreetMap < talk-ca@openstreetmap.org > 
Envoyé le : jeudi 1 Septembre 2016 17h06 
Objet : Re: [Talk-ca] CanVec Reverts 






I received the following changeset comment from Nakaner for a Canvec import 
(changeset 
38158126) at 15:55 Central Time (20:55 UTC): 

"This changeset has uploaded data which does not fit to each other. There is an 
offset between the water areas and the forest areas. Example: 
https://www.openstreetmap.org/ way/406539219 
Could you please fix this?" 
I believe the given what we have just spent the last 24 hours discussing this 
request is unreasonable and the issue is not significant. Thoughts? 
Sam 

___ 
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 

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

Re: [Talk-ca] CanVec Reverts

[Frederik Ramm]

Sam,

On 09/01/2016 11:26 PM, Frederik Ramm wrote:
>> I believe the given what we have just spent the last 24 hours discussing
>> this request is unreasonable and the issue is not significant. Thoughts?
> 
> An importer who imports data into OSM that doesn't match up with already
> existing data and doesn't notice it is careless and should do a better job.
> 
> An importer who is asked to fix non-matching data he has accidentally
> imported and responds that the request is "unreasonable" should have his
> account taken away.

It appears I have mistakenly thought that you, Sam, and the import user
"sammuell" were one and the same. Apologies. I still think that if the
importer cannot be bothered to fix it, the data should be removed until
someone has the time to do it right (rather than keeping bad data in OSM
until someone can fix it).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-ca] CanVec Reverts

[Sam Dyck]

After reading Paul's email again, its possible that what Nakaner is doing
is in line with Paul's suggestion, if unnecessarily confrontational. I
tried to play around in JOSM to see if I could get the forest polygons to a
point where Nakaner would leave us alone by mercilessly deleting all of the
inner ways in the forest multipolygons, but because of the way things are
structured around rivers that would be several hours worth of work for one
tile. Given this perhaps the only solution is to bulk delete all Canvec
forest data. As someone who actually finds the forest data useful this
would be extremely unfortunate, but if it allows us to continue imports
without excessive external scrutiny then I am willing to except it.
(apologies for the English only emails, my French writing skills are sadly
lacking)

On Thu, Sep 1, 2016 at 4:20 PM, Pierre Béland <pierz...@yahoo.fr> wrote:

> L'idéal préparer Une réponse standard indiquant que l'Import Canvec par la
> communauté OSM Canada est itératif et nous nous assurons collectivement
> d'améliorer les données. Voir page Wiki Import Canvec et venir discuter sur
> Talk-Ca si vous avez d'autres questions.
>
>
> Pierre
>
>
> --
> *De :* Sam Dyck <samueld...@gmail.com>
> *À :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
> *Envoyé le :* jeudi 1 Septembre 2016 17h06
> *Objet :* Re: [Talk-ca] CanVec Reverts
>
> I received the following changeset comment from Nakaner for a Canvec
> import (changeset
> 38158126) at 15:55 Central Time (20:55 UTC):
> "This changeset has uploaded data which does not fit to each other. There
> is an offset between the water areas and the forest areas. Example: 
> https://www.openstreetmap.org/
> way/406539219 <https://www.openstreetmap.org/way/406539219>
> Could you please fix this?"
> I believe the given what we have just spent the last 24 hours discussing
> this request is unreasonable and the issue is not significant. Thoughts?
> Sam
>
> ___
> 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] CanVec Reverts

[Michael Reichert]

Hi Sam,

Am 01.09.2016 um 23:06 schrieb Sam Dyck:
> I received the following changeset comment from Nakaner for a Canvec import
> (changeset
> 38158126) at 15:55 Central Time (20:55 UTC):
> 
> "This changeset has uploaded data which does not fit to each other. There
> is an offset between the water areas and the forest areas. Example:
> https://www.openstreetmap.org/way/406539219
> 
> Could you please fix this?"
> 
> I believe the given what we have just spent the last 24 hours discussing
> this request is unreasonable and the issue is not significant. Thoughts?

If you have a proper look at the whole area around, you will see that
there is a systematic offset between the water "layer" and the forest
layer. The forest layer should be moved about 10 to 30 metres to
northwest. I wonder how such an error can be overseen during the
preparation of this tile.

Other examples:
https://www.openstreetmap.org/way/402043390
https://www.openstreetmap.org/#map=16/49.3997/-87.4329

Maybe the original data was traced from different aerial imagery and
that's why there is an offset which is not constant.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec Reverts

[Frederik Ramm]

Hi,

On 2016-09-01 21:06:57, Sam Dyck wrote:
> I believe the given what we have just spent the last 24 hours discussing
> this request is unreasonable and the issue is not significant. Thoughts?

An importer who imports data into OSM that doesn't match up with already
existing data and doesn't notice it is careless and should do a better job.

An importer who is asked to fix non-matching data he has accidentally
imported and responds that the request is "unreasonable" should have his
account taken away.

(This is my personal opinion. DWG is more nuanced but Paul Norman's
message which you have read says clearly that the importer has the
responsibility to see that the data matches up with existing stuff.)

Either https://www.openstreetmap.org/way/406539219 is wrong, or the
forest around it is wrong. And to quote someone else from this thread,
the result is certainly not aesthetically pleasing either. You should
find out which, and take appropriate steps. I am speechless to hear that
not only are you importing broken data, but you also consider it
unreasonable to fix it.

If you can't be bothered to care for quality when importing, then don't,
and wait for someone more responsible to come along.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-ca] CanVec Reverts

[Sam Dyck]

I received the following changeset comment from Nakaner for a Canvec import
(changeset
38158126) at 15:55 Central Time (20:55 UTC):

"This changeset has uploaded data which does not fit to each other. There
is an offset between the water areas and the forest areas. Example:
https://www.openstreetmap.org/way/406539219

Could you please fix this?"

I believe the given what we have just spent the last 24 hours discussing
this request is unreasonable and the issue is not significant. Thoughts?

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

Re: [Talk-ca] CanVec Reverts

[James]

>From what Rps333 told me in person he had worked many hours on that
changeset and was frustrated when someone reverted before fixes could be
applied. Could you revert the revert?

On Sep 1, 2016 4:09 PM, "Paul Norman"  wrote:

> Hello,
>
> Multiple people have referred this issue and changeset 39517002 to the
> OpenStreetMap Foundation Data Working Group about this issue. The Data
> Working Group has responsibility for the resolution of disputes beyond
> the normal means of the community, as well as some responsibilities
> concerning imports. I am replying here rather than the changeset as it
> should reach everyone involved.
>
> CanVec Quality
> ==
>
> The CanVec import is one that was started long ago so parts of the
> documentation are lacking and some aspects are unclear.[1] CanVec, like
> any other import, has certain hard requirements, including the use of a
> dedicated user account.
>
> In particular it is expected that imported CanVec data is
>
> - Integrated with existing data, particularly at NTS/CanVec tile edges
>
> - Valid
>
> - Internally consistent with both the newly imported CanVec and existing
>   OSM data, particularly to avoid overlapping landuse like forest and
>   water, forest and residential, or wetlands in what is obviously a
>   residential subdivision.
>
> - Uploaded in small enough parts that the changesets make sense. This
>   means never uploading more than 50k objects at once, and typically
>   fewer than 10k.
>
> - Not duplicating existing OSM data. Evaluating what data is better
>   generally requires experience with both CanVec and OSM data in the
>   *region being mapped*
>
> It is not required that CanVec data is compared an external source like
> Bing imagery, but this is helpful, particularly when resolving problems.
>
> We encourage the Canadian community to develop better documentation for
> people importing CanVec to achieve this and to remove outdated
> documentation.[2]
>
> Reverting
> =
>
> Advance permission is not required for reverts, nor for normal mapping
> activities. At the same time, users are expected to be responsible,
> particularly when using tools for reverting which allow large-scale
> changes where other users may disagree with them.
>
> Where there are problems with an import reverting is an option, but
> just one of many, and often not the appropriate first action. Unless
> there are legal problems[3] or fatal problems with the import it is
> preferable if the original importer can fix the problems in a timely
> manner. There was every indication this was going to happen in this case.
>
> The revert of 39517002 was inappropriate and counter-productive. New
> actions like this revert may lead to further Data Working Group
> involvement and potentially blocks. If the Canadian community needs help
> reverting 41749133 and 41756737, the Data Working Group can revert those
> changesets.
>
> While not going into depth on the changeset discussion at this time, I
> want to remind everyone involved that OpenStreetMap is a crowd-sourcing
> project, which inherently involves working with other people. This
> requires good communication, which was absent here.
>
> Paul Norman
>
> For the OpenStreetMap Foundation Data Working Group
>
> [1]: Except for the CanVec license, which is ODbL and possibly CC BY-SA
>
> [2]: Much of the CanVec documentation is outdated, which makes it
>  difficult to know what is relevant. A good start would be removing
>  outdated documentation.
>
> [3]: Please refer cases of large-scale infringement to
> d...@osmfoundation.org
>  so we can "redact" the content to remove it from publicly viewable
>  history.
>
>
> ___
> 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] CanVec Reverts

[john whelan]

Canvec data has been imported for many years so why the sudden challenge
and change?  Are you willing to reimport the CANVEC data or are you intent
on leaving a blank area in the map?

Cheerio John

On 1 September 2016 at 15:41, Michael Reichert  wrote:

> Hi James,
>
> Am 2016-09-01 um 15:04 schrieb James:
> > To blatantly toss discussions of the
> > past whether to import CanVec or not into OSM and *that was approved*, …
>
> Could you point me to the discussion at the Imports mailing list? (link
> to the archive of the mailing list)
>
> I am not against importing CanVec data, I am just against importing
> CanVec data in a bad way.
>
> Best regards
>
> Michael
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
>
> ___
> 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] CanVec Reverts

[Paul Norman]

Hello,

Multiple people have referred this issue and changeset 39517002 to the
OpenStreetMap Foundation Data Working Group about this issue. The Data
Working Group has responsibility for the resolution of disputes beyond
the normal means of the community, as well as some responsibilities
concerning imports. I am replying here rather than the changeset as it
should reach everyone involved.

CanVec Quality
==

The CanVec import is one that was started long ago so parts of the
documentation are lacking and some aspects are unclear.[1] CanVec, like
any other import, has certain hard requirements, including the use of a
dedicated user account.

In particular it is expected that imported CanVec data is

- Integrated with existing data, particularly at NTS/CanVec tile edges

- Valid

- Internally consistent with both the newly imported CanVec and existing
  OSM data, particularly to avoid overlapping landuse like forest and
  water, forest and residential, or wetlands in what is obviously a
  residential subdivision.

- Uploaded in small enough parts that the changesets make sense. This
  means never uploading more than 50k objects at once, and typically
  fewer than 10k.

- Not duplicating existing OSM data. Evaluating what data is better
  generally requires experience with both CanVec and OSM data in the
  *region being mapped*

It is not required that CanVec data is compared an external source like
Bing imagery, but this is helpful, particularly when resolving problems.

We encourage the Canadian community to develop better documentation for
people importing CanVec to achieve this and to remove outdated
documentation.[2]

Reverting
=

Advance permission is not required for reverts, nor for normal mapping
activities. At the same time, users are expected to be responsible,
particularly when using tools for reverting which allow large-scale
changes where other users may disagree with them.

Where there are problems with an import reverting is an option, but
just one of many, and often not the appropriate first action. Unless
there are legal problems[3] or fatal problems with the import it is
preferable if the original importer can fix the problems in a timely
manner. There was every indication this was going to happen in this case.

The revert of 39517002 was inappropriate and counter-productive. New
actions like this revert may lead to further Data Working Group
involvement and potentially blocks. If the Canadian community needs help
reverting 41749133 and 41756737, the Data Working Group can revert those
changesets.

While not going into depth on the changeset discussion at this time, I
want to remind everyone involved that OpenStreetMap is a crowd-sourcing
project, which inherently involves working with other people. This
requires good communication, which was absent here.

Paul Norman

For the OpenStreetMap Foundation Data Working Group

[1]: Except for the CanVec license, which is ODbL and possibly CC BY-SA

[2]: Much of the CanVec documentation is outdated, which makes it
 difficult to know what is relevant. A good start would be removing
 outdated documentation.

[3]: Please refer cases of large-scale infringement to 
d...@osmfoundation.org

 so we can "redact" the content to remove it from publicly viewable
 history.


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

Re: [Talk-ca] CanVec Reverts

[Begin Daniel]

Hum 
First discussions about importing NRCan data can be find here...
https://lists.openstreetmap.org/pipermail/talk-ca/2008-November/000228.html

They are talking about importing GeoBase - which is exactly the same content 
that is found in Canvec since Canvec is the merging of GeoBase layers.

If you look at the date (November 2008), the import mailing list even did not 
exist.

We can go that way but I do not think it the point here. We must talk about 
deleting data that was imported in good faith, without leaving the community 
enough time to correct them. 

Daniel

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 15:41
To: James
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] CanVec Reverts

Hi James,

Am 2016-09-01 um 15:04 schrieb James:
> To blatantly toss discussions of the
> past whether to import CanVec or not into OSM and *that was approved*, 
> …

Could you point me to the discussion at the Imports mailing list? (link to the 
archive of the mailing list)

I am not against importing CanVec data, I am just against importing CanVec data 
in a bad way.

Best regards

Michael

--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)


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

Re: [Talk-ca] CanVec Reverts

[Darren Wiebe]

I'm usually just a lurker on these lists but this has dragged me out of my
cave.

Michael,

I'm glad you care about the quality of the map, I do too.  I welcome you to
take an constructive approach to working with these problems.  Canada has
an area of 9,984,670 square kilometers with a population density of only
8.8.  That presents us with challenges that wouldn't apply to a country
with an area of 357,022 square kilometers and a population density of
593.  Rather
than handing out an ultimatum to the Canadian mapping community how about
you work with us?  We share your concerns in regards to data quality but
your unilateral reversion of commits without communication or cooperation
is damaging to the map.

I find your comment "if it has not been touched for a few weeks" comment to
be insulting and it shows a complete lack of understanding of the realities
on the ground.  I'm personally working at improving the map in my area
(County of Vermilion River, Alberta, Canada) and you are more than welcome
to constructively help. However, just because I haven't touched something
for a couple of weeks doesn't mean I've forgotten about it.  It means I was
on holidays or got busy with other things in the office.

Have you ever tried importing data using JOSM?  I've spent hours poring
over a few square miles of countryside and trying to get everything cleaned
up and merged.  Then, when I actually import, the data gets split into much
smaller sizes.  Or maybe I get some of it imported and then have to fix a
bug I missed in something else.  To somebody like you it looks like I just
dumped a bunch of data in when in reality I've been picking away at it for
a few days.

Darren Wiebe



On Thu, Sep 1, 2016 at 8:49 AM, Sam Dyck <samueld...@gmail.com> wrote:

> Micheal
>
> Thanks for contacting us. I must object strongly to your use of the Worst
> of OSM example and generally assumption that the data is broken if it
> doesn't line up. I checked multiple commercial imagery providers before I
> found a digitalglobe image that covered the area during the summer. There
> is a large patch of sand between the vegetation-filled area and the coast.
> As for the boundary, that comes from another official source, I think it is
> supposed to be spaced off of the coastline, though I don't remember exactly
> how they calculated it, we would likely need a constitutional change to
> make it line up with the coast. Just because things don't match up does not
> mean that the data is wrong. Nature doesn't always translate into nice,
> clean maps.
>
> Sam
>
> -Original Message-
> From: Michael Reichert [mailto:naka...@gmx.net]
> Sent: Thursday, 1 September, 2016 01:39
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] CanVec Reverts
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> unfortunately posting via Gmane does not seem to work (the website is down
> but NNTP still works), that's why I have to start a new thread. :-(
>
> Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> > After reading through the changeset discussion, I discovered that one
> > of my imports in Northern Manitoba made Worst of OSM.
> > (http://worstofosm.tumblr.com/post/22180046353/dear-
> > openstreetmap-isnt-it-strange-how-the). As someone who spends a some
> > time amount of time in some of relatively unpopulated areas of Canada
> > and makes an effort to check the quality of Canvec data (which is
> > usually pretty good), I do agree that it is impossible to do
> > everything to the same level of quality that we would provide in
> > Toronto or Timmins or even small prairie towns.
>
> First of all, it is ok that an import takes a few years and therefore
> creates ugly green rectancles on the map. If an import is "unavoidable"
> :-), a manual import is the best thing that can be happen. But if someone
> uploads a changeset without a manual review beforehand, he counteracts the
> aim of a manual import: addind good data to OpenStreetMap. That's what I am
> mainly fighting against. If a users uploads much more than 100 objects per
> minute [1], you can be sure that he has not done any manual review. A
> manual review by myself confirmed this these. I am fighting against such
> changesets/users.
>
> A good imports must be reviewed *before* it is being uploaded. The review
> contains:
> - - Run JOSM validator, fix all warnings and errors. This includes all
> warnings regarding validity of areas. (you can argue if all warnings about
> "deprecated" tagging have to be fixed)
> - - Compare the data with available imagery. Is the forest really a forest
> or is another tag more appropiate? Right-click on a Bing tile at JOSM and
> have a look how old/recent the imagery is.
> - - Check if CanVec data fits to its

Re: [Talk-ca] CanVec Reverts

[Sam Dyck]

Micheal

Thanks for contacting us. I must object strongly to your use of the Worst
of OSM example and generally assumption that the data is broken if it
doesn't line up. I checked multiple commercial imagery providers before I
found a digitalglobe image that covered the area during the summer. There
is a large patch of sand between the vegetation-filled area and the coast.
As for the boundary, that comes from another official source, I think it is
supposed to be spaced off of the coastline, though I don't remember exactly
how they calculated it, we would likely need a constitutional change to
make it line up with the coast. Just because things don't match up does not
mean that the data is wrong. Nature doesn't always translate into nice,
clean maps.

Sam

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net]
Sent: Thursday, 1 September, 2016 01:39
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] CanVec Reverts

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

unfortunately posting via Gmane does not seem to work (the website is down
but NNTP still works), that's why I have to start a new thread. :-(

Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> After reading through the changeset discussion, I discovered that one
> of my imports in Northern Manitoba made Worst of OSM.
> (http://worstofosm.tumblr.com/post/22180046353/dear-
> openstreetmap-isnt-it-strange-how-the). As someone who spends a some
> time amount of time in some of relatively unpopulated areas of Canada
> and makes an effort to check the quality of Canvec data (which is
> usually pretty good), I do agree that it is impossible to do
> everything to the same level of quality that we would provide in
> Toronto or Timmins or even small prairie towns.

First of all, it is ok that an import takes a few years and therefore
creates ugly green rectancles on the map. If an import is "unavoidable"
:-), a manual import is the best thing that can be happen. But if someone
uploads a changeset without a manual review beforehand, he counteracts the
aim of a manual import: addind good data to OpenStreetMap. That's what I am
mainly fighting against. If a users uploads much more than 100 objects per
minute [1], you can be sure that he has not done any manual review. A
manual review by myself confirmed this these. I am fighting against such
changesets/users.

A good imports must be reviewed *before* it is being uploaded. The review
contains:
- - Run JOSM validator, fix all warnings and errors. This includes all
warnings regarding validity of areas. (you can argue if all warnings about
"deprecated" tagging have to be fixed)
- - Compare the data with available imagery. Is the forest really a forest
or is another tag more appropiate? Right-click on a Bing tile at JOSM and
have a look how old/recent the imagery is.
- - Check if CanVec data fits to itself.
http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
it-strange-how-the
<http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-it-strange-how-the>
- - Check if there has been any other data before. If yes, adapt the either
the CanVec data or the old data.
https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
ide-Cutting.png
<https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Inside-Cutting.png>
https://www.openstreetmap.org/way/439631732
- - Ways should not overlap with other ways if it is not necessary. The
outer ring of a lake should also be inner member of the forest
multipolygon. Maybe the program which created the OSM files should be
imprved?
- - Keep the history.
https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history

If a tile has been imported without being checked manually and no
post-upload fixes have been done (i.e. upload without any checks), I will
not shrink from reverting it. If a tile has been uploaded to OSM without a
review and if it has not been fixed within a month, it is worthless and can
easily be reimported at a later time if someone has the time to check and
fix it.

For the future, I will abstain from reverting changesets which have been
imported before September 1, 2016 and whose users are currently doing the
fixes that should already have been done. But if I come across an imported
tile of low quality which has not been touched for a few weeks and is full
of errors, it is just a question of time until it is reverte d.

Best regards

Michael

[1] I had a look on a few of my changesets which added a large number of
buildings to OSM. The fastest changeset contained about 60 objects per
minute and was full of missing buildings as I later detected while
collecting the housenumbers and usage of the buildings.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec reverts

[Loïc Haméon]

ne wrong, how to edit and
>>> how to fix them. :-/
>>>
>>> > 2) A addr:interp way may be split in 2 parts. 2 consequences:
>>> > - the interpolation way become useless because it's now 2 different
>>> objects.
>>> > - the mid-point becomes 2 superposed nodes. Useless duplication.
>>> >
>>> > 3) A grid tile has a fixed size. It may be appropriate for unpopulated
>>> areas
>>> > but it is too large for urban areas where editors work at a high zoom
>>> level
>>> > (17 and up). It's easy to damage a relation without knowing it.
>>> >
>>> > But there are other problems (not related to the grid):
>>> > 4) the relations seem to be designed to be stand-alone. Thus the
>>> relation
>>> > borders don't share a way. They use 2 superposed ways. Useless
>>> duplication.
>>> > It's very confusing and we frequently alter the wrong way.
>>> >
>>> > 5) lakes are represented by 2 superposed identical objects, one for
>>> the hole
>>> > and one for the lake. If the hole happen to be on top, the name will
>>> not be
>>> > displayed. It's an unjustifiable complexity for the casual user.
>>> > I've also seen triplicated contour (one for the lake, on for the inner
>>> role
>>> > and one for the outer role)
>>> >
>>> > Yes, all these quirks can be fixed manually but it's time-consuming
>>> and error-
>>> > prone.
>>>
>>> What about reverting the tiles which have all these issues and seem to
>>> be uploaded with too few checks beforehand, run a better version of the
>>> preprocessor on the CanVec raw data and reimport them again? (That
>>> causes a loss of OSM history but an import changeset is not as much
>>> valueable than a manual changeset)
>>>
>>> > Ideally, the contour of a forest must not split any object and it's not
>>> > possible with a grid.
>>> > The sole advantage of a grid IMHO is to simplify the CanVec exports.
>>>
>>> What about replacing the grid by less artificial borders, e.g. roads,
>>> rivers, powerlines etc. If an area has too few of theses objects,
>>> artifical borders could be automatically drawn which are optimized to
>>> cut as few objects as possible into two parts.
>>>
>>> > Some years ago I would have proposed that someone write a guide "How
>>> to fix a
>>> > CanVec import". But now I would rather propose that someone write a
>>> "How to
>>> > pre-process a CanVec export before importing it into OSM".
>>>
>>> +1
>>>
>>> All ongoing changesets which import CanVec data should either use an
>>> improved version of the preprocessor or should undergo the manual
>>> quality checks I described in my other emails and the changeset comments.
>>>
>>> Best regards
>>>
>>> Michael
>>>
>>>
>>> --
>>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
>>> ausgenommen)
>>> I prefer GPG encryption of emails. (does not apply on mailing lists)
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> -- Forwarded message --
> From: Begin Daniel <jfd...@hotmail.com>
> To: Michael Reichert <naka...@gmx.net>, Begin Daniel <jfd...@hotmail.com>,
> "talk-ca@openstreetmap.org" <talk-ca@openstreetmap.org>
> Cc:
> Date: Thu, 1 Sep 2016 13:04:30 +
> Subject: Re: [Talk-ca] CanVec Reverts
> I understand your point. You might be right about the time between
> changesets (even though it may depends on if the users is working with
> layers), but I maintain my points about the time it may take within a
> changeset.
> Daniel
>
> -Original Message-
> From: Michael Reichert [mailto:naka...@gmx.net]
> Sent: Thursday, 1 September, 2016 08:37
> To: Begin Daniel; talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] CanVec Reverts
>
> Hi Daniel,
>
> Am 2016-09-01 um 12:26 schrieb Begin Daniel:
> > Furthermore, I hope you will not use you 100 objects per minute to
> >

Re: [Talk-ca] CanVec Reverts

[Begin Daniel]

I understand your point. You might be right about the time between changesets 
(even though it may depends on if the users is working with layers), but I 
maintain my points about the time it may take within a changeset.
Daniel

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 08:37
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] CanVec Reverts

Hi Daniel,

Am 2016-09-01 um 12:26 schrieb Begin Daniel:
> Furthermore, I hope you will not use you 100 objects per minute to 
> decide whether or not you will delete a changeset. I think this 
> threshold is value doesn't' apply (see below)
> 
> Daniel
> 
> About the100 objects threshold.
> From my experience, if I load a Canvec tile in JOSM, make all the necessary 
> corrections and then import the result to OSM, I throw up to 25K objects to 
> the database within five minutes.  As far as I know, the timestamps attached 
> to the changeset and to the objects is generated by the OSM database when 
> receiving the data. The five minutes it takes to upload the data to the 
> database (5K objects per minute) do not reflect the time I spent editing the 
> data prior to the upload.

That's the base of my calculation I did with Rps333's changesets:

changeset   start   end object count

3951757119:30:5319:32:564311
3951768619:35:3019:41:1211724
3951794419:45:1519:47:274963
3951814719:53:2520:04:5519286

As you see, he took less than three minutes minutes after uploading
39517571 to prepare 39517686. You cannot check such an amount of data very well 
within that time.

Best regards

Michael


--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

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

Re: [Talk-ca] CanVec Reverts

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Am 2016-09-01 um 13:22 schrieb john whelan:
> In many parts of the country there are no local mappers for many 
> miles or kilometers if you prefer.  We do have some very 
> experienced GIS people around and I'm under the impression that we 
> really do know what we are doing.

This is no carte blanche to import any dataset you can get. The import
discussion exists to ensure that an import is done the right way, i.e.
importing good data in a good way. If the users who import a dataset
base on an import disussion/proposal do not care about the quality,
they violate the proposal and therefore the policy because the import
becomes an import which has not been approved.

Best regards

Michael


- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
(Mailinglisten ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJXyCKEAAoJEB87G9rMCMyIqvgQAK58kt5ULsvv0nf0MnCm6ahM
Iq8Kub3bLS2ZE93kVlgUl43cEJ6pzr3/XS0fd4hbRPuybektD0N9kNumm/KVZ2Pn
2/fZvOpai3YcVRAiSMZ2HUHaZnz9CYI56xsFYJcE8+RXcmTBXbp1WBmbqd4j7ceu
+IRdkrxweAQEDymlYtfI1rd1gA+CJBWnfcRr7Fq1CUNi2yI4M4U697qxtK1TdQuW
4Y+SmiDlUvGJLos0qjzucXs3zatY5SELY3/sTZ4iS0Emla8m5Eq1Wqo09FCGngrT
Yov1gQQBuMlUl80BsILM6beAKfhYq0hYgje77VzONmZYN79mMzkXHD3IJS2/lVfZ
r4pU2BL6bDTYues0diPefNbCvTi0SkLAOJccsy4+6OLWQ5B9WJgW8yT3KTbv6N0T
25yuaEGBdbLcs4dacZj1PdMKy2W4EgTy2UQKadlc4l4DAVJYyuaLifx0ij8n5pgs
hepMWWTh0B5WyIckDGVMBUk9awQFu1IN7gm5zJWgTap6Kz3m0O0TbvOGtaXjod7C
teFq+MmZ7wf/ocGc0AMCweZgJUBKiTu+tcKYrFUQq4f6XSCblzYiSJA95NlRNGJh
BiLVgu/K7nJ1fYgPhN9wSVGgP21HRs80X2ZVtGLbTL/hZTjSDKNLd8sS6tT+86Ie
ek7VLR9LDoAeihcRu3zU
=Ea1G
-END PGP SIGNATURE-

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

Re: [Talk-ca] CanVec Reverts

[James]

What tells you he didnt prepare batches outside the upload time(offline)?
Your logic is skewed

On Sep 1, 2016 8:39 AM, "Michael Reichert"  wrote:

> Hi Daniel,
>
> Am 2016-09-01 um 12:26 schrieb Begin Daniel:
> > Furthermore, I hope you will not use you 100 objects per minute to
> decide whether or not you will delete a changeset. I think this threshold
> is value doesn't' apply (see below)
> >
> > Daniel
> >
> > About the100 objects threshold.
> > From my experience, if I load a Canvec tile in JOSM, make all the
> necessary corrections and then import the result to OSM, I throw up to 25K
> objects to the database within five minutes.  As far as I know, the
> timestamps attached to the changeset and to the objects is generated by the
> OSM database when receiving the data. The five minutes it takes to upload
> the data to the database (5K objects per minute) do not reflect the time I
> spent editing the data prior to the upload.
>
> That's the base of my calculation I did with Rps333's changesets:
>
> changeset   start   end object count
> 
> 3951757119:30:5319:32:564311
> 3951768619:35:3019:41:1211724
> 3951794419:45:1519:47:274963
> 3951814719:53:2520:04:5519286
>
> As you see, he took less than three minutes minutes after uploading
> 39517571 to prepare 39517686. You cannot check such an amount of data
> very well within that time.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
> ___
> 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] CanVec Reverts

[Michael Reichert]

Hi Daniel,

Am 2016-09-01 um 12:26 schrieb Begin Daniel:
> Furthermore, I hope you will not use you 100 objects per minute to decide 
> whether or not you will delete a changeset. I think this threshold is value 
> doesn't' apply (see below)
> 
> Daniel
> 
> About the100 objects threshold.
> From my experience, if I load a Canvec tile in JOSM, make all the necessary 
> corrections and then import the result to OSM, I throw up to 25K objects to 
> the database within five minutes.  As far as I know, the timestamps attached 
> to the changeset and to the objects is generated by the OSM database when 
> receiving the data. The five minutes it takes to upload the data to the 
> database (5K objects per minute) do not reflect the time I spent editing the 
> data prior to the upload.

That's the base of my calculation I did with Rps333's changesets:

changeset   start   end object count

3951757119:30:5319:32:564311
3951768619:35:3019:41:1211724
3951794419:45:1519:47:274963
3951814719:53:2520:04:5519286

As you see, he took less than three minutes minutes after uploading
39517571 to prepare 39517686. You cannot check such an amount of data
very well within that time.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec Reverts

[john whelan]

Note to Michael Reichert

I think you should respect the views of the local community.

We know the data isn't perfect but for the most part its good data and as
Daniel has said when I've imported the work is done in JOSM off line over a
period of time so the time apparently taken doesn't really indicate this.

In many parts of the country there are no local mappers for many miles or
kilometers if you prefer.  We do have some very experienced GIS people
around and I'm under the impression that we really do know what we are
doing.

Cheerio John

On 1 September 2016 at 06:26, Begin Daniel <jfd...@hotmail.com> wrote:

> Thank for contacting the Canadian community Michael,
> You provided us with a short but useful reminder of current rules we
> should apply when importing data (or even just making standard edits).
>
> However, I understand from your last paragraph that you will keep deleting
> changesets. I was hoping your email started a discussion on best practices
> that we could be put in place in our context since adjusting Canvec data to
> the latest rules is a daunting task. I rather feel it is an ultimatum.
>
> Do your future actions will apply to the imports made a few months, a few
> years ago, which are 'full of errors' and for which nobody seems to care?
> Are you going to check with concerned contributors (old/future imports) if
> they bother or not to see their work deleted before you do it?
>
> Furthermore, I hope you will not use you 100 objects per minute to decide
> whether or not you will delete a changeset. I think this threshold is value
> doesn't' apply (see below)
>
> Daniel
>
> About the100 objects threshold.
> From my experience, if I load a Canvec tile in JOSM, make all the
> necessary corrections and then import the result to OSM, I throw up to 25K
> objects to the database within five minutes.  As far as I know, the
> timestamps attached to the changeset and to the objects is generated by the
> OSM database when receiving the data. The five minutes it takes to upload
> the data to the database (5K objects per minute) do not reflect the time I
> spent editing the data prior to the upload.
>
> -Original Message-
> From: Michael Reichert [mailto:naka...@gmx.net]
> Sent: Thursday, 1 September, 2016 01:39
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] CanVec Reverts
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> unfortunately posting via Gmane does not seem to work (the website is down
> but NNTP still works), that's why I have to start a new thread. :-(
>
> Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> > After reading through the changeset discussion, I discovered that one
> > of my imports in Northern Manitoba made Worst of OSM.
> > (http://worstofosm.tumblr.com/post/22180046353/dear-
> > openstreetmap-isnt-it-strange-how-the). As someone who spends a some
> > time amount of time in some of relatively unpopulated areas of Canada
> > and makes an effort to check the quality of Canvec data (which is
> > usually pretty good), I do agree that it is impossible to do
> > everything to the same level of quality that we would provide in
> > Toronto or Timmins or even small prairie towns.
>
> First of all, it is ok that an import takes a few years and therefore
> creates ugly green rectancles on the map. If an import is "unavoidable"
> :-), a manual import is the best thing that can be happen. But if someone
> uploads a changeset without a manual review beforehand, he counteracts the
> aim of a manual import: addind good data to OpenStreetMap. That's what I am
> mainly fighting against. If a users uploads much more than 100 objects per
> minute [1], you can be sure that he has not done any manual review. A
> manual review by myself confirmed this these. I am fighting against such
> changesets/users.
>
> A good imports must be reviewed *before* it is being uploaded. The review
> contains:
> - - Run JOSM validator, fix all warnings and errors. This includes all
> warnings regarding validity of areas. (you can argue if all warnings about
> "deprecated" tagging have to be fixed)
> - - Compare the data with available imagery. Is the forest really a forest
> or is another tag more appropiate? Right-click on a Bing tile at JOSM and
> have a look how old/recent the imagery is.
> - - Check if CanVec data fits to itself.
> http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
> it-strange-how-the
> - - Check if there has been any other data before. If yes, adapt the
> either the CanVec data or the old data.
> https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
> ide-Cutting.png
> https://www.openstreetmap.org/way/439631732
>

Re: [Talk-ca] CanVec Reverts

[Begin Daniel]

Thank for contacting the Canadian community Michael, 
You provided us with a short but useful reminder of current rules we should 
apply when importing data (or even just making standard edits).

However, I understand from your last paragraph that you will keep deleting 
changesets. I was hoping your email started a discussion on best practices that 
we could be put in place in our context since adjusting Canvec data to the 
latest rules is a daunting task. I rather feel it is an ultimatum.  

Do your future actions will apply to the imports made a few months, a few years 
ago, which are 'full of errors' and for which nobody seems to care? Are you 
going to check with concerned contributors (old/future imports) if they bother 
or not to see their work deleted before you do it? 

Furthermore, I hope you will not use you 100 objects per minute to decide 
whether or not you will delete a changeset. I think this threshold is value 
doesn't' apply (see below)

Daniel

About the100 objects threshold.
From my experience, if I load a Canvec tile in JOSM, make all the necessary 
corrections and then import the result to OSM, I throw up to 25K objects to the 
database within five minutes.  As far as I know, the timestamps attached to the 
changeset and to the objects is generated by the OSM database when receiving 
the data. The five minutes it takes to upload the data to the database (5K 
objects per minute) do not reflect the time I spent editing the data prior to 
the upload.

-Original Message-
From: Michael Reichert [mailto:naka...@gmx.net] 
Sent: Thursday, 1 September, 2016 01:39
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] CanVec Reverts

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

unfortunately posting via Gmane does not seem to work (the website is down but 
NNTP still works), that's why I have to start a new thread. :-(

Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> After reading through the changeset discussion, I discovered that one 
> of my imports in Northern Manitoba made Worst of OSM.
> (http://worstofosm.tumblr.com/post/22180046353/dear-
> openstreetmap-isnt-it-strange-how-the). As someone who spends a some 
> time amount of time in some of relatively unpopulated areas of Canada 
> and makes an effort to check the quality of Canvec data (which is 
> usually pretty good), I do agree that it is impossible to do 
> everything to the same level of quality that we would provide in 
> Toronto or Timmins or even small prairie towns.

First of all, it is ok that an import takes a few years and therefore creates 
ugly green rectancles on the map. If an import is "unavoidable"
:-), a manual import is the best thing that can be happen. But if someone 
uploads a changeset without a manual review beforehand, he counteracts the aim 
of a manual import: addind good data to OpenStreetMap. That's what I am mainly 
fighting against. If a users uploads much more than 100 objects per minute [1], 
you can be sure that he has not done any manual review. A manual review by 
myself confirmed this these. I am fighting against such changesets/users.

A good imports must be reviewed *before* it is being uploaded. The review 
contains:
- - Run JOSM validator, fix all warnings and errors. This includes all warnings 
regarding validity of areas. (you can argue if all warnings about "deprecated" 
tagging have to be fixed)
- - Compare the data with available imagery. Is the forest really a forest or 
is another tag more appropiate? Right-click on a Bing tile at JOSM and have a 
look how old/recent the imagery is.
- - Check if CanVec data fits to itself.
http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
it-strange-how-the
- - Check if there has been any other data before. If yes, adapt the either the 
CanVec data or the old data.
https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
ide-Cutting.png
https://www.openstreetmap.org/way/439631732
- - Ways should not overlap with other ways if it is not necessary. The outer 
ring of a lake should also be inner member of the forest multipolygon. Maybe 
the program which created the OSM files should be imprved?
- - Keep the history.
https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history

If a tile has been imported without being checked manually and no post-upload 
fixes have been done (i.e. upload without any checks), I will not shrink from 
reverting it. If a tile has been uploaded to OSM without a review and if it has 
not been fixed within a month, it is worthless and can easily be reimported at 
a later time if someone has the time to check and fix it.

For the future, I will abstain from reverting changesets which have been 
imported before September 1, 2016 and whose users are currently doing the fixes 
that should already have been done. But if I come across an imported tile of 
low quality which has not been touched for a few weeks and is full 

Re: [Talk-ca] CanVec Reverts

[James]

See that's where I have an issue with your revert logic, if errors are
mostly corrected and say theres only 1 or 2 warnings, you want to revert
the whole thing which is very bad for: 1. The community and 2. The
database. Let me explain: there are many hours that go into merging down
CanVec ways and you want to undo all that work. Why is it bad for the
database? It makes it bigger everytine you do stuff like that, an ID has to
be allocated to every node, way and relation and by you "deleting"
everything, they remain in the database as history which is bad as the full
history planet file is already retardedly big(200+GB) and then when someone
redoes the work you undid, new IDs are allocated which doubles the data
size just for you being anal about perfection. Instead of reverting it for
1-2 warnings FIX IT! You dont have nice bing satelite imagery to
reference(which is the case with most of northern Canada)? Too bad you want
to be anal. Also this is a reminder that bing imagery can be 1. Really
really really stale(10-15 years old as taking high res photos of trees
doesnt return on investment) and 2. 1-20m offset. Instead of reverting the
data that isnt perfect, why not spend your time correcting it instead of
work being done: Canada isn't Germany.

Ich wünsche einen guten Tag!

On Sep 1, 2016 1:40 AM, "Michael Reichert"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi,
>
> unfortunately posting via Gmane does not seem to work (the website is
> down but NNTP still works), that's why I have to start a new thread. :-(
>
> Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> > After reading through the changeset discussion, I discovered that
> > one of my imports in Northern Manitoba made Worst of OSM.
> > (http://worstofosm.tumblr.com/post/22180046353/dear-
> > openstreetmap-isnt-it-strange-how-the). As someone who spends a
> > some time amount of time in some of relatively unpopulated areas of
> > Canada and makes an effort to check the quality of Canvec data
> > (which is usually pretty good), I do agree that it is impossible to
> > do everything to the same level of quality that we would provide in
> > Toronto or Timmins or even small prairie towns.
>
> First of all, it is ok that an import takes a few years and therefore
> creates ugly green rectancles on the map. If an import is "unavoidable"
> :-), a manual import is the best thing that can be happen. But if
> someone uploads a changeset without a manual review beforehand, he
> counteracts the aim of a manual import: addind good data to
> OpenStreetMap. That's what I am mainly fighting against. If a users
> uploads much more than 100 objects per minute [1], you can be sure that
> he has not done any manual review. A manual review by myself confirmed
> this these. I am fighting against such changesets/users.
>
> A good imports must be reviewed *before* it is being uploaded. The
> review contains:
> - - Run JOSM validator, fix all warnings and errors. This includes all
> warnings regarding validity of areas. (you can argue if all warnings
> about "deprecated" tagging have to be fixed)
> - - Compare the data with available imagery. Is the forest really a forest
> or is another tag more appropiate? Right-click on a Bing tile at JOSM
> and have a look how old/recent the imagery is.
> - - Check if CanVec data fits to itself.
> http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
> it-strange-how-the
> - - Check if there has been any other data before. If yes, adapt the
> either the CanVec data or the old data.
> https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
> ide-Cutting.png
> https://www.openstreetmap.org/way/439631732
> - - Ways should not overlap with other ways if it is not necessary. The
> outer ring of a lake should also be inner member of the forest
> multipolygon. Maybe the program which created the OSM files should be
> imprved?
> - - Keep the history.
> https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history
>
> If a tile has been imported without being checked manually and no
> post-upload fixes have been done (i.e. upload without any checks), I
> will not shrink from reverting it. If a tile has been uploaded to OSM
> without a review and if it has not been fixed within a month, it is
> worthless and can easily be reimported at a later time if someone has
> the time to check and fix it.
>
> For the future, I will abstain from reverting changesets which have been
> imported before September 1, 2016 and whose users are currently doing
> the fixes that should already have been done. But if I come across an
> imported tile of low quality which has not been touched for a few weeks
> and is full of errors, it is just a question of time until it is reverte
> d.
>
> Best regards
>
> Michael
>
>
>
> [1] I had a look on a few of my changesets which added a large number of
> buildings to OSM. The fastest changeset contained about 60 objects per
> minute and was full 

[Talk-ca] CanVec Reverts

[Michael Reichert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

unfortunately posting via Gmane does not seem to work (the website is
down but NNTP still works), that's why I have to start a new thread. :-(

Am Tue, 30 Aug 2016 21:41:21 -0500 schrieb Sam Dyck:
> After reading through the changeset discussion, I discovered that
> one of my imports in Northern Manitoba made Worst of OSM. 
> (http://worstofosm.tumblr.com/post/22180046353/dear- 
> openstreetmap-isnt-it-strange-how-the). As someone who spends a
> some time amount of time in some of relatively unpopulated areas of
> Canada and makes an effort to check the quality of Canvec data
> (which is usually pretty good), I do agree that it is impossible to
> do everything to the same level of quality that we would provide in
> Toronto or Timmins or even small prairie towns.

First of all, it is ok that an import takes a few years and therefore
creates ugly green rectancles on the map. If an import is "unavoidable"
:-), a manual import is the best thing that can be happen. But if
someone uploads a changeset without a manual review beforehand, he
counteracts the aim of a manual import: addind good data to
OpenStreetMap. That's what I am mainly fighting against. If a users
uploads much more than 100 objects per minute [1], you can be sure that
he has not done any manual review. A manual review by myself confirmed
this these. I am fighting against such changesets/users.

A good imports must be reviewed *before* it is being uploaded. The
review contains:
- - Run JOSM validator, fix all warnings and errors. This includes all
warnings regarding validity of areas. (you can argue if all warnings
about "deprecated" tagging have to be fixed)
- - Compare the data with available imagery. Is the forest really a forest
or is another tag more appropiate? Right-click on a Bing tile at JOSM
and have a look how old/recent the imagery is.
- - Check if CanVec data fits to itself.
http://worstofosm.tumblr.com/post/22180046353/dear-openstreetmap-isnt-
it-strange-how-the
- - Check if there has been any other data before. If yes, adapt the
either the CanVec data or the old data.
https://wiki.openstreetmap.org/wiki/File:Import-Fails-Powerlines-Not-Ins
ide-Cutting.png
https://www.openstreetmap.org/way/439631732
- - Ways should not overlap with other ways if it is not necessary. The
outer ring of a lake should also be inner member of the forest
multipolygon. Maybe the program which created the OSM files should be
imprved?
- - Keep the history.
https://wiki.openstreetmap.org/wiki/Good_practice#Keep_the_history

If a tile has been imported without being checked manually and no
post-upload fixes have been done (i.e. upload without any checks), I
will not shrink from reverting it. If a tile has been uploaded to OSM
without a review and if it has not been fixed within a month, it is
worthless and can easily be reimported at a later time if someone has
the time to check and fix it.

For the future, I will abstain from reverting changesets which have been
imported before September 1, 2016 and whose users are currently doing
the fixes that should already have been done. But if I come across an
imported tile of low quality which has not been touched for a few weeks
and is full of errors, it is just a question of time until it is reverte
d.

Best regards

Michael



[1] I had a look on a few of my changesets which added a large number of
buildings to OSM. The fastest changeset contained about 60 objects per
minute and was full of missing buildings as I later detected while
collecting the housenumbers and usage of the buildings.

- -- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXx77+AAoJEB87G9rMCMyI95YQAJyCMY/Qtnqu4C3MpLPrrwTH
vN2aVBNoKHL+i6r5VBTPFy4JhcacjbAZSseMCbmQHo6CSdPgVk9Jvnk/Keh3ihH6
r//EqwqRnSPPE+JIBktW0DG50jzcogWun3UQmOyA/blRfYEZaIDhjRDjMcivBWvs
x8EGZsuX/mraX74ucTbfhy13Xoy4M4Yjf4ibNS7ZmJKlT4Zj8HDwlPKRzFxZ6iWG
JGfibU4wxxvJlQDWqjrVRN6zacbt8SKh9sHU3M88kNRhM+eido/rYY9LiKBFdO21
TBGM/XkvxcqM7F9u9uC03caDFi0cTb7PLZgv90QhXTi2DuFobfHf3sc1czq8lGeB
Wa8ZZqRI6Y9/SV06P/wydA48caKeeO3OiiuH8UXzEZJPauUhLjpEVxY1OixkgNkC
GR79KbVcx0AyFK66Jnrdn2pqa2HotJ2rM6RLSi68mMOYPbHcUvujcb7XQW5dvubF
L3TamnVs8u1qiifpfTCAp/AJFxd/9UDnGi2VsjSHrIPdZgJaCAcHmhiUSXkcZa55
hjfL+4b+itj48PRcfJRzXTRE3I9Q7oAyMkbwMKVFvSOe9GwgUNw5nvspWvPUriUo
pDoDHFJt3k4RE6hHVhsb0+L/OyVr6NFpjex2aoEbX0990Gvi+G6uabkNAOn4o0Ub
nAQhtQWnI5dlwMWhcYOH
=vPJv
-END PGP SIGNATURE-

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

[Talk-ca] CanVec+

[James]

I was just wondering if anyone knew that CanVec data is being phased out
and replaced by CanVec+. I spoke with Marc LeMaire from NRCan and he said
that they will not be offering .osm conversions of CanVec+ data, which
means that we will have to convert the shapefiles ourselves. My question is
has anyone begun coding/documenting CanVec+ data for conversion yet? Marc
said that they are ending CanVec by the end of the year.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec+

[Adam Martin]

Hi all!



Thanks for the heads up, James. I was not personally aware of this change
until now. Reading the news release for the CanVec+ from the Geogratis site
(http://geogratis.gc.ca/site/eng/whats-new/intro-canvec). I think one of
the key statements on the website is that the Department of Natural
Resources is *transitioning* to an improved data model with the goal of
providing seamless information. New vector products will be available under
this model *eventually*. That’s all good.



However, CanVec+ *is not* that new product. It is, instead, “an interim
product for the transition”. CanVec+ is just a new way for the Department
to publish the same data. They mention that it is a model that is supposed
to allow them to frequently update the data at the best resolution. This is
good, but is not likely to be of great benefit to OSM since the areas that
would get frequent update would, most likely speaking and from a logical
standpoint, be areas of high human concentration - AKA areas that OSM user
mapping efforts are concentrated. For other areas, in James’ words, the
shapefiles would need to be manually converted.



Personally, I see little point in adopting this information in any
widespread or meaningful way. CanVec+ is essentially the same data that we
currently have. The possibility of updates to the dataset would be
relatively meaningless. Until the new data format is released, I would
recommend sitting on this matter, if my reading of that news release is
correct (I could be wrong). If a new data format is coming, that might be
useful, though caution would need to be taken to ensure that user changes
were not overridden with it.



Adam

On Wed, Oct 7, 2015 at 3:09 PM, James  wrote:

> I was just wondering if anyone knew that CanVec data is being phased out
> and replaced by CanVec+. I spoke with Marc LeMaire from NRCan and he said
> that they will not be offering .osm conversions of CanVec+ data, which
> means that we will have to convert the shapefiles ourselves. My question is
> has anyone begun coding/documenting CanVec+ data for conversion yet? Marc
> said that they are ending CanVec by the end of the year.
>
> ___
> 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] canvec release schedule

[Daniel Begin]

Well, as far as I know, NRCan have no more projects around OSM community since 
fall 2012 - no more Canvec in .osm format, no more participation to the talk-ca 
list.  Governmental priorities change and they could eventually get back to the 
community but, for the moment, I am even surprised the ftp site is running!

Hoping for the best 
Daniel 

-Original Message-
From: Andrew [mailto:andrew.alli...@teksavvy.com] 
Sent: November-08-14 15:28
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] canvec release schedule

Hello List:

I seem to remember that Canvec had a 6 month release schedule for OSM, 
but the data on the ftp site seams to be about a year and half old.

http://ftp2.cits.rncan.gc.ca/OSM/pub/042/F/

Now I do see some newer data in:

http://ftp2.cits.rncan.gc.ca/pub/canvec+/

Is the Canvec data no longer being converted / made available for OSM?
Any tidbit of wisdom? 

Andrew




___
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

[Talk-ca] canvec release schedule

[Andrew]

Hello List:

I seem to remember that Canvec had a 6 month release schedule for OSM,
but the data on the ftp site seams to be about a year and half old.

http://ftp2.cits.rncan.gc.ca/OSM/pub/042/F/

Now I do see some newer data in:

http://ftp2.cits.rncan.gc.ca/pub/canvec+/

Is the Canvec data no longer being converted / made available for OSM?
Any tidbit of wisdom? 

Andrew




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

[Talk-ca] CanVec updates without a version bump

[Paul Norman]

I was having a look at New Westminster in tile 092G02.1.1, and 
I noticed that there are differences between CanVec 10.0 which 
I downloaded when it came out and what I just downloaded from 
the CanVec webpage, which is also labeled CanVec 10.0

Addresses have been added, and with them, errors introduced.
Although I'm not opposed to adding addresses, adding a new feature
like this obviously needs discussion and review, and I checked imports@
and it doesn't look like this happened.

Who's our contact at NRCan these days? We need to make sure that the scope
of what's getting imported is clear and that additions get properly
discussed.




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

[Talk-ca] Canvec 12

[Sam Dyck]

Is there a timeline for converting Canvec 12 to OSM XML? If not, could I
get a copy of canvec2osm so I can convert the files I need?

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

Re: [Talk-ca] CanVec 10 Data

[Harald Kliems]

I think Daniel's email got cut off at the end :-)

On Mon, Nov 4, 2013 at 6:26 AM, Daniel Begin jfd...@hotmail.com wrote:

 I'm not familiar with imports using Potlatch but importing it using JOSM is
 quite easy - open the file, select the features, copy then in a new layer
 and then upload the layer in OSM...

...after you've carefully checked if everything is plausible and you don't
mess up the work of other contributors who may already have added
housenumber data of better quality.

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

Re: [Talk-ca] CanVec 10 Data

[Paul Norman]

I don't believe CanVec has any addressing info in metro Vancouver, so no
conflict there. 

I'd also hope that if people regard addresses as important they've been
collecting them in surveys when out mapping, so there are address already
there that should *not* generally be replaced by CanVec data.

 From: Steve Roy [mailto:st...@ssni.ca]
 Subject: Re: [Talk-ca] CanVec 10 Data
 
 Agreed.  I see that Paul Norman imported some of the City of Surrey GIS
 data a couple of years ago and that included house numbers.
 
 Cheers
 Steve
 
 On 04/11/2013 6:16 AM, Harald Kliems wrote:
  I think Daniel's email got cut off at the end :-)
 
  On Mon, Nov 4, 2013 at 6:26 AM, Daniel Begin jfd...@hotmail.com
  mailto:jfd...@hotmail.com wrote:
 
  I'm not familiar with imports using Potlatch but importing it
 using
  JOSM is
  quite easy - open the file, select the features, copy then in a
 new
  layer
  and then upload the layer in OSM...
 
  ...after you've carefully checked if everything is plausible and you
  don't mess up the work of other contributors who may already have
  added housenumber data of better quality.



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

Re: [Talk-ca] CanVec 10 Data

[Steve Roy]

I see it in Burnaby and New Westminster under 092G02

and example of the Key/Value are:

addr:interpolation  odd
source  NRCan-CanVec-10.0

Cheers
Steve

On 04/11/2013 1:28 PM, Paul Norman wrote:
 I don't believe CanVec has any addressing info in metro Vancouver, so no
 conflict there. 
 
 I'd also hope that if people regard addresses as important they've been
 collecting them in surveys when out mapping, so there are address already
 there that should *not* generally be replaced by CanVec data.
 
 From: Steve Roy [mailto:st...@ssni.ca]
 Subject: Re: [Talk-ca] CanVec 10 Data

 Agreed.  I see that Paul Norman imported some of the City of Surrey GIS
 data a couple of years ago and that included house numbers.

 Cheers
 Steve


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

Re: [Talk-ca] CanVec 10 Data

[Daniel Begin]

Thanks for having found the missing part Harald!-)

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: November-04-13 09:17
To: Daniel Begin
Cc: Steve Roy; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] CanVec 10 Data

 

I think Daniel's email got cut off at the end :-)

 

On Mon, Nov 4, 2013 at 6:26 AM, Daniel Begin jfd...@hotmail.com wrote:

I'm not familiar with imports using Potlatch but importing it using JOSM is
quite easy - open the file, select the features, copy then in a new layer
and then upload the layer in OSM...

...after you've carefully checked if everything is plausible and you don't
mess up the work of other contributors who may already have added
housenumber data of better quality.

 Harald. 

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

[Talk-ca] CanVec 10 Data

[Steve Roy]

I have been doing some CanVec 10 imports and noticed in the latest files
that it includes semi street numbering - like odd/even block numbers.
An example here:
http://www.openstreetmap.org/#map=18/49.74784/-123.11109

Is this worth importing?  If so is there an easy way to import just this
via JOSM?  I only use Potlatch currently.

Thanks
Steve

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

[Talk-ca] Canvec v12

[Sam Dyck]

What are the details regarding the conversion to OSM format of Canvec v12?

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

Re: [Talk-ca] Canvec-OSM FTP Down?

[Daniel Begin]

The links in the wiki (Canvec) is now corrected…

Daniel

 

From: François Paquette [mailto:fpaque...@cooptel.qc.ca] 
Sent: July-20-13 18:18
To: 'Daniel Begin'; 'Adam Dunn'; 'talk-ca'
Subject: RE: [Talk-ca] Canvec-OSM FTP Down?

 

Try with

 

 http://ftp2.cits.rncan.gc.ca/OSM/pub http://ftp2.cits.rncan.gc.ca/OSM/pub

 

The FTP site is case sensitive

 

François

 

De : Daniel Begin [mailto:jfd...@hotmail.com] 
Envoyé : 20 juillet 2013 18:12
À : 'Adam Dunn'; 'talk-ca'
Objet : Re: [Talk-ca] Canvec-OSM FTP Down?

 

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried…

 

Daniel

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

 

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

 

Adam

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Canvec-OSM FTP Down?

[Adam Dunn]

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a
temporary thing, but does anybody know what's going on?

Adam
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec-OSM FTP Down?

[Daniel Begin]

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried.

 

Daniel

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

 

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

 

Adam

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec-OSM FTP Down?

[François Paquette]

Bonjour Daniel and Adam 

 

I ‘ve sent an email to the person in charge. If the problem is not solved
this weekend, it will be Monday

 

François

 

De : Daniel Begin [mailto:jfd...@hotmail.com] 
Envoyé : 20 juillet 2013 18:12
À : 'Adam Dunn'; 'talk-ca'
Objet : Re: [Talk-ca] Canvec-OSM FTP Down?

 

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried…

 

Daniel

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

 

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

 

Adam

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec-OSM FTP Down?

[François Paquette]

Try with

 

 http://ftp2.cits.rncan.gc.ca/OSM/pub http://ftp2.cits.rncan.gc.ca/OSM/pub

 

The FTP site is case sensitive

 

François

 

De : Daniel Begin [mailto:jfd...@hotmail.com] 
Envoyé : 20 juillet 2013 18:12
À : 'Adam Dunn'; 'talk-ca'
Objet : Re: [Talk-ca] Canvec-OSM FTP Down?

 

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried…

 

Daniel

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

 

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

 

Adam

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec misalignment? Ottawa end of Portage Bridge

[Richard Weait]

On Tue, Dec 18, 2012 at 11:30 AM, William Rieck bi...@thinkers.org wrote:

 There is no gospel, although surveys and GPS traces may be close, but
 certainly not Bing and CanVec imports.

 The map should represent what you see on the ground, so make whatever
 adjustments are needed, using deduction from your primary source (a
 survey), that aligns with traces (absolute position) and any other sources
 (Bing, Canvec) if they are helpful.


Indeed.  Consider all of your available sources.  Part of the fun of
mapping is learning 1) that all of your sources are lying to you, and 2) in
what ways they usually lie.  :-)

So when none of your sources agree perfectly, mappers have to make the best
informed guess that they can make.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] CanVec misalignment? Ottawa end of Portage Bridge

[Tom Taylor]

I've been continuing to work on validation errors in the Ottawa area. 
One complaint was of buildings projecting into the Ottawa River on the 
west side of the Portage Bridge, by the dam between the Ottawa side of 
the river and Victoria Island. When I look, the buildings (source CanVec 
6.0) are way out of line (up to 7 m) with the Bing imagery, but lots of 
GPS traces show that Bing has put the Portage Bridge in the right place.


Do we take CanVec as gospel in this case and shift the river boundary, 
or should I just tiptoe away and leave it alone?


Tom Taylor

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec misalignment? Ottawa end of Portage Bridge

[William Rieck]

There is no gospel, although surveys and GPS traces may be close, but
certainly not Bing and CanVec imports.

The map should represent what you see on the ground, so make whatever
adjustments are needed, using deduction from your primary source (a
survey), that aligns with traces (absolute position) and any other sources
(Bing, Canvec) if they are helpful.


On Tue, Dec 18, 2012 at 11:04 AM, Tom Taylor tom.taylor.s...@gmail.comwrote:

 I've been continuing to work on validation errors in the Ottawa area. One
 complaint was of buildings projecting into the Ottawa River on the west
 side of the Portage Bridge, by the dam between the Ottawa side of the river
 and Victoria Island. When I look, the buildings (source CanVec 6.0) are way
 out of line (up to 7 m) with the Bing imagery, but lots of GPS traces show
 that Bing has put the Portage Bridge in the right place.

 Do we take CanVec as gospel in this case and shift the river boundary, or
 should I just tiptoe away and leave it alone?

 Tom Taylor

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec bug - splitting of long riverbank ways?

[Brian Gamberg]

Canvec data appears to be produced with a maximum of 2K nodes per way. I assume 
that this was an attempt by the Canvec people to meet the max 2K node criteria 
of the OSM database.  When the split occurs in a way that is a member of a 
multipolygon, there's not a problem.  Otherwise, as Paul has pointed out, 
broken data may be uploaded inadvertently.  In JOSM, a quick check for this is 
to use the search function with the string nodes: 2000-.
  
On Monday, November 12, 2012 11:27 PM, Paul Norman penor...@mac.com wrote: 
 I appear to of found a CanVec 10 bug in 094P13.0.osm 
  
 There is a waterway=riverbank way (Dilly Creek) that is split in two at 
 59.7728641, 11219806992One way is 2k nodes, the other is 457 nodes. 
  
 Ideally this would be split in two to form two separate areas. An alternate 
 solution would be to not split them and have one way over 2k nodes. This 
 will force the importer to fix it before uploading as opposed to right now 
 where if someone doesn't notice they will upload broken data. 
  
  
 ___ 
 Talk-ca mailing list 
 Talk-ca@openstreetmap.org 
 http://lists.openstreetmap.org/listinfo/talk-ca 
 


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] CanVec bug - splitting of long riverbank ways?

[Paul Norman]

I appear to of found a CanVec 10 bug in 094P13.0.osm

There is a waterway=riverbank way (Dilly Creek) that is split in two at
59.7728641, -121.9806992. One way is 2k nodes, the other is 457 nodes.

Ideally this would be split in two to form two separate areas. An alternate
solution would be to not split them and have one way over 2k nodes. This
will force the importer to fix it before uploading as opposed to right now
where if someone doesn't notice they will upload broken data.


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec Imports in areas with existing data

[Andrew MacKinnon]

On Sun, Nov 4, 2012 at 8:21 PM, Duncan Hill dun...@soncan.ca wrote:
 I've recently imported some CanVec 10 data into the North Bay, Ontario area.
 It's been hard to figure out the best way to do this because of the assorted
 versions of existing data in the area. After chatting with some folks in the
 #osm-ca channel, I left the existing major highways to preserve routing.
 Since this is the first time I've imported any CanVec data, I am wondering
 if this is the best way to do it when there is existing data in the area. I
 would really appreciate it if someone could take a look at my import in case
 I have broken something.

Your import looks fine to me.

In areas with existing data, you need to merge the existing data with
the new data, by cutting and pasting new CanVec data into OSM and then
merging it with old data (by joining roads that you copy from CanVec
with existing roads, and cleaning up any old imported data that is
inaccurate e.g. roads with the wrong name). This is time consuming but
necessary.

When you import street address data, please join the imported street
address data with address data from adjacent CanVec tiles. This is
very time consuming but needs to be done properly. Also the
FixAddresses plugin in JOSM might be helpful to compare road names
of imported street address data with road names in the database,
although you should only use it on a small area, as it is really slow
if you try to use it on a large area.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] CanVec Imports in areas with existing data

[Duncan Hill]

I've recently imported some CanVec 10 data into the North Bay, Ontario
area. It's been hard to figure out the best way to do this because of the
assorted versions of existing data in the area. After chatting with some
folks in the #osm-ca channel, I left the existing major highways to
preserve routing. Since this is the first time I've imported any CanVec
data, I am wondering if this is the best way to do it when there is
existing data in the area. I would really appreciate it if someone could
take a look at my import in case I have broken something.

The NTS tile that I imported was: 031L06.0.11
The changeset for my import is here:
http://www.openstreetmap.org/browse/changeset/13755583

Duncan
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Canvec 10 and landcover issues

[Harald Kliems]

Hi everyone,
I've done some OSMInspector debugging of areas around Montreal and
I've come across a number of newly imported natural=wetland areas,
sourced from Canvec 10. that are clearly wrong. This, for example,
http://www.openstreetmap.org/?lat=45.69514lon=-73.90455zoom=17layers=M
is a subdivision, not wetland or wood. If you're importing Canvec data
could you please make sure to do some plausibility checks, based on
aerial imagery or road layout, especially in populated areas? I'm not
sure how old the imported data is, but some areas supposedly covered
by woods or wetlands look like they've been developed for quite some
time.

Cheers,
 Harald.

-- 
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec 10 and landcover issues

[Pierre Béland]

Harald, 

I dont know how you conclude that there is no wetlands around this area in 
Laval.  It is not sufficient to see houses around to conclude that there is no 
wetland. These are often wooded areas with water all over.  Google physical 
also shows a stream starting from this area.


The link below shows a comparison of this area with Google imagery.  Are you 
sure that there is no wetland in this area.

http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.91012lat=45.69989zoom=17


The link below shows an aera in Saint-Jean-sur-Richelieu were houses have been 
built for over 30 years. Look how many houses were flooded last year. Zoom in 
to see areas that were flooded.

http://pierzen.dev.openstreetmap.org/hot/openlayers/inondation-richelieu-2011.htm?zoom=16lat=45.28568lon=-73.24907layers=B000T


My experience, as a volunteer for SOS-Richelieu, last year, showed me how that 
too often the municipalities have accepted that contractors build houses over 
wetlands. And this was often the case with Laval.

These imports are part of the process of building the OSM map. This import is a 
first step and local mappers will eventually validate and correct if necessary.

The same situation arises with imagery such as Bing when some buildings are 
built or others demolished.
What we need is to build a strong  community of mappers that will improve the 
map from the state it is presently.
 
Pierre 




 De : Harald Kliems kli...@gmail.com
À : Talk-CA OpenStreetMap Talk-ca@openstreetmap.org 
Envoyé le : Vendredi 19 octobre 2012 14h04
Objet : [Talk-ca] Canvec 10 and landcover issues
 
Hi everyone,
I've done some OSMInspector debugging of areas around Montreal and
I've come across a number of newly imported natural=wetland areas,
sourced from Canvec 10. that are clearly wrong. This, for example,
http://www.openstreetmap.org/?lat=45.69514lon=-73.90455zoom=17layers=M
is a subdivision, not wetland or wood. If you're importing Canvec data
could you please make sure to do some plausibility checks, based on
aerial imagery or road layout, especially in populated areas? I'm not
sure how old the imported data is, but some areas supposedly covered
by woods or wetlands look like they've been developed for quite some
time.

Cheers,
Harald.

-- 
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec 10 and landcover issues

[Paul Norman]

 From: Harald Kliems [mailto:kli...@gmail.com]
 Sent: Friday, October 19, 2012 11:04 AM
 To: Talk-CA OpenStreetMap
 Subject: [Talk-ca] Canvec 10 and landcover issues
 
 Hi everyone,
 I've done some OSMInspector debugging of areas around Montreal and I've
 come across a number of newly imported natural=wetland areas, sourced
 from Canvec 10. that are clearly wrong. This, for example,
 http://www.openstreetmap.org/?lat=45.69514lon=-
 73.90455zoom=17layers=M
 is a subdivision, not wetland or wood. If you're importing Canvec data
 could you please make sure to do some plausibility checks, based on
 aerial imagery or road layout, especially in populated areas? I'm not
 sure how old the imported data is, but some areas supposedly covered by
 woods or wetlands look like they've been developed for quite some time.

Yes - one of the frequent issues is that the different thematic layers
(e.g. landcovers, addresses, roads, buildings, etc) are different ages and
some are very old. In BC the buildings information is horrendously old while
frequently the water and forest information doesn't agree - leading to
CanVec saying there are trees in the ocean. The recent releases are better
in this regards and I believe some zipfiles include information on the age
of the different feature data included, but the problem of areas being
described both as built up by the roads data and as forest by the other data
is still frequently an issue. It's like your mixing pictures of what the
area was like at different times, so you get confusing results.


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec 10 and landcover issues

[Harald Kliems]

Hi Pierre,
thanks for the response.

On Fri, Oct 19, 2012 at 3:25 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:
 I dont know how you conclude that there is no wetlands around this area in
 Laval.  It is not sufficient to see houses around to conclude that there is
 no wetland. These are often wooded areas with water all over.  Google
 physical also shows a stream starting from this area.

 The link below shows a comparison of this area with Google imagery.  Are you
 sure that there is no wetland in this area.
 http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.91012lat=45.69989zoom=17
This is a misunderstanding. I did not mean that there is _no_ wetland
in the area. But I'm pretty certain that the boundaries of the wetland
are wrong:

http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.90457lat=45.69533zoom=17

Aside from the wetland issue (see below), we can probably agree that
the area is not natural = wood, even if some people might have planted
trees in their yards.

 The link below shows an aera in Saint-Jean-sur-Richelieu were houses have
 been built for over 30 years. Look how many houses were flooded last year.
 Zoom in to see areas that were flooded.
 http://pierzen.dev.openstreetmap.org/hot/openlayers/inondation-richelieu-2011.htm?zoom=16lat=45.28568lon=-73.24907layers=B000T

 My experience, as a volunteer for SOS-Richelieu, last year, showed me how
 that too often the municipalities have accepted that contractors build
 houses over wetlands. And this was often the case with Laval.
Okay, this is a different issue, coming down to the definition of what
wetland is. I'm by no means an expert, but in my understanding you
can't have a residential area in wetlands. In order to build houses
you must first use drainage channels etc. to turn wetland into
developed land. The fact that there can be flooding in a given area
doesn't make it into wetland to me. The wiki isn't very explicit about
this (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland) but
the specific subtypes seem to hint at a definition stricter than
yours. Maybe someone can tell us what definition is used for Canvec.

Cheers,
 Harald.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec 10 and landcover issues

[Frank Steggink]

On 19-10-2012 21:46, Harald Kliems wrote:

Hi Pierre,
thanks for the response.

On Fri, Oct 19, 2012 at 3:25 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:

I dont know how you conclude that there is no wetlands around this area in
Laval.  It is not sufficient to see houses around to conclude that there is
no wetland. These are often wooded areas with water all over.  Google
physical also shows a stream starting from this area.

The link below shows a comparison of this area with Google imagery.  Are you
sure that there is no wetland in this area.
http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.91012lat=45.69989zoom=17

This is a misunderstanding. I did not mean that there is _no_ wetland
in the area. But I'm pretty certain that the boundaries of the wetland
are wrong:

http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.90457lat=45.69533zoom=17

Aside from the wetland issue (see below), we can probably agree that
the area is not natural = wood, even if some people might have planted
trees in their yards.


The link below shows an aera in Saint-Jean-sur-Richelieu were houses have
been built for over 30 years. Look how many houses were flooded last year.
Zoom in to see areas that were flooded.
http://pierzen.dev.openstreetmap.org/hot/openlayers/inondation-richelieu-2011.htm?zoom=16lat=45.28568lon=-73.24907layers=B000T

My experience, as a volunteer for SOS-Richelieu, last year, showed me how
that too often the municipalities have accepted that contractors build
houses over wetlands. And this was often the case with Laval.

Okay, this is a different issue, coming down to the definition of what
wetland is. I'm by no means an expert, but in my understanding you
can't have a residential area in wetlands. In order to build houses
you must first use drainage channels etc. to turn wetland into
developed land. The fact that there can be flooding in a given area
doesn't make it into wetland to me. The wiki isn't very explicit about
this (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland) but
the specific subtypes seem to hint at a definition stricter than
yours. Maybe someone can tell us what definition is used for Canvec.

Cheers,
  Harald.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


Hi Harald,

As Paul just explained, the Canvec data comes from different ages, so 
what this basically tells is that 20 or 30 years ago (or maybe just 10 
years ago) this area was a wooded marsh. Unfortunately, this landcover 
data is the best available. (The lower resolution Landsat data can be 
pretty old too, and its resolution makes it unusable.) It still needs to 
be reconciled with the roads, preferably with the help of Bing imagery. 
I'm not sure if a decent resolution is available in this area. Good 
coverage is pretty spotty in Canada.


Regarding the flooding: areas which used to be wetlands in the past are 
still prone to flooding, unless significant work has been undertaken 
from ever happening again (like drainage, diverting streams, putting 
extra soil on top). Especially when buildings are built within the 
channels which have been eroded by rivers, then you can basically wait 
for a disaster to happen.


Frank


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec 10 and landcover issues

[Pierre Béland]

Harald,

I am not an expert either and it would be interesting to have the opinion of an 
expert. But I can say that a wetland is an area were the groundwater is at the 
surface of the soil. It can be grass or covered by forest.  For years you see 
no problems and pretend the situation do not exist.

The government of Québec is producing very detailed maps of risk zones. It 
would be interesting to see. But it is not free.

There are different types of wetland. The tag natural=wetland is combined with 
wetland=type for more precision.
wiki http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland


 
Pierre 




 De : Harald Kliems kli...@gmail.com
À : Pierre Béland infosbelas-...@yahoo.fr 
Cc : Talk-CA OpenStreetMap Talk-ca@openstreetmap.org 
Envoyé le : Vendredi 19 octobre 2012 15h46
Objet : Re: [Talk-ca] Canvec 10 and landcover issues
 
Hi Pierre,
thanks for the response.

On Fri, Oct 19, 2012 at 3:25 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:
 I dont know how you conclude that there is no wetlands around this area in
 Laval.  It is not sufficient to see houses around to conclude that there is
 no wetland. These are often wooded areas with water all over.  Google
 physical also shows a stream starting from this area.

 The link below shows a comparison of this area with Google imagery.  Are you
 sure that there is no wetland in this area.
 http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.91012lat=45.69989zoom=17
This is a misunderstanding. I did not mean that there is _no_ wetland
in the area. But I'm pretty certain that the boundaries of the wetland
are wrong:

http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.90457lat=45.69533zoom=17

Aside from the wetland issue (see below), we can probably agree that
the area is not natural = wood, even if some people might have planted
trees in their yards.

 The link below shows an aera in Saint-Jean-sur-Richelieu were houses have
 been built for over 30 years. Look how many houses were flooded last year.
 Zoom in to see areas that were flooded.
 http://pierzen.dev.openstreetmap.org/hot/openlayers/inondation-richelieu-2011.htm?zoom=16lat=45.28568lon=-73.24907layers=B000T

 My experience, as a volunteer for SOS-Richelieu, last year, showed me how
 that too often the municipalities have accepted that contractors build
 houses over wetlands. And this was often the case with Laval.
Okay, this is a different issue, coming down to the definition of what
wetland is. I'm by no means an expert, but in my understanding you
can't have a residential area in wetlands. In order to build houses
you must first use drainage channels etc. to turn wetland into
developed land. The fact that there can be flooding in a given area
doesn't make it into wetland to me. The wiki isn't very explicit about
this (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland) but
the specific subtypes seem to hint at a definition stricter than
yours. Maybe someone can tell us what definition is used for Canvec.

Cheers,
Harald.


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] canvec fixme - Place type may not be valid

[Andrew Allison]

Hello:

   I'm currently importing canvec data in south western Ontario.

My question is, canvec data has fixmes for
place = locality  Place type may not be valid
track sport type unknown. 

Should I just go ahead and delete these fixme, as I don't think
they are really fixme's?

Andrew

aka PurpleMustang, CanvecImports.


signature.asc
Description: This is a digitally signed message part
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec fixme - Place type may not be valid

[Pierre Béland]

Andrew,

I cc to Nicolas Gariepy from NRCan. Nicolas should be able to indicate what 
NRCan want us to validate when they put these fixme on Canvec files. It is 
probably to validate if this locality exist or not.


For example, looking at one of the canvec edits you did recently, I see Fishers 
Glen locality (node=1873510264) at the end of Fishers Glen rd, near Fishers 
Creek. 
Pierre 




 De : Andrew Allison andrew.alli...@teksavvy.com
À : talk-ca talk-ca@openstreetmap.org 
Envoyé le : Mercredi 10 octobre 2012 12h58
Objet : [Talk-ca] canvec fixme - Place type may not be valid
 
Hello:

       I'm currently importing canvec data in south western Ontario.

        My question is, canvec data has fixmes for
        place = locality      Place type may not be valid
        track sport type unknown. 

        Should I just go ahead and delete these fixme, as I don't think
they are really fixme's?

        Andrew

        aka PurpleMustang, CanvecImports.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

To be clear, I haven't done full imports. I haven't imported roads or  
water, in order not to duplicate features. Water was previously  
imported by Yan Morin in 2009 (Geobase NHN data), and roads were  
either drawn by users, or a result of the Geobase NRN import. In case  
of water, I only have added a few streams which were missing.


One of the issues is that certain ways are duplicated, because of  
multipolygon holes. That's why I'm gauging your thoughts about it,  
because I don't see that as an issue myself. Perhaps we could come up  
with a proper way how to deal with it.


Another issue which is bothering myself for a long time is the fact  
that Geobase NRN roads don't have road names in Quebec. Road names are  
present in Canvec now. Replacing them manually is a tedious task. I  
have thought about it for quite some time, but I can't come up with a  
better procedure, offering the same quality. I also have considered  
writing tools for them. Any (semi-)automated tools have an inherent  
risk, particularly because it's hard to guarantee they will still do a  
proper job, given the diversity in OSM data.


Frank


Quoting Béland Pierre bela...@yahoo.fr:


David and Paul, do you think this was the problem with these imports???
 
Pierre





De : David E. Nelson denelso...@yahoo.ca
À : Paul Norman penor...@mac.com; talk-ca@openstreetmap.org  
talk-ca@openstreetmap.org

Envoyé le : Mercredi 22 août 2012 21h59
Objet : Re: [Talk-ca] Canvec import issues


Yeah, don't just do blanket imports.  Just import whatever data  
OSM *does not* have.




- David E. Nelson


From: Paul Norman penor...@mac.com
To: 'Daniel Begin' jfd...@hotmail.com; 'Pierre Béland'  
infosbelas-...@yahoo.fr; talk-ca@openstreetmap.org

Sent: Wednesday, August 22, 2012 6:52:12 PM
Subject: Re: [Talk-ca] Canvec import issues


I see the problem as being the importing of everything as being  
the problem, not the geometric model :)

 
From:Daniel Begin [mailto:jfd...@hotmail.com]
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
Bonjour Pierre,
 
The Canvec Geometric Model is explained in the following OSM wiki page ...
http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model
 
The model was adopted after discussions with the community. The  
model was designed to simplify the import of a selection of  
features by the  contributors, instead of imposing import the  
entire contents by them.

 
However, history now shows that the community usually imports the  
entire content.

Compromises always bring pros and cons.!-)
 
Best regards,
Daniel
 



From:Pierre Béland [mailto:infosbelas-...@yahoo.fr]
Sent: August-21-12 16:04
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
 
I didn't do Canvec imports too much. Looking at various lakes in  
wooded areas,  I now realize that Canvec imports are often  
(always?) duplicating lakes. I do'nt know what was the reason to  
create these duplicate ways in the Canvec import file.  Should we  
duplicate the lakes to apply a inner role in the relation? Is this  
a reason for that? Or could we instead simply use the existing  
lake with a inner role in the wooded area polygon relation?

 
Pierre



De :Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat  
hostile tone) after the Canvec import I've done over the weekend  
northwest of Montréal. He was not really happy with the way how  
the import has handled. The way the Canvec data is currently  
provided, leaves some room for improvement. I'm not sure if all  
his issues have been discussed in the past (since I haven't  
followed all Canvec discussions, especially in the beginning), but  
I could see some merit in some of the point.


Some examples he provided come from the Mt. Tremblant area [1].  
Note that the lakes (and most of the streams) were imported  
previously by someone else, based on NHN data, but the same issue  
plays with the Canvec data itself. (This left me to the task to  
leave the Canvec lakes out of the upload, as well as most streams.)


On the left you see Lac Ouimet. He
mentioned that a large part of the ways are duplicated. The outer  
boundary of the wooded area is a separate polygon from the lake  
itself.  However, Lac Gauthier on the right is a different case.  
This lake has been cut out from the woods, and I left the inner  
boundary intact. JOSM is not complaining about this. Since dealing  
with multipolygons remains a sticky issue, I have not done that. I  
think it would be better to take care of these issues with some  
tool. Although using a tool is considered dangerously (and  
rightfully so!), dealing

Re: [Talk-ca] Canvec import issues

[Pierre Béland]

Frank,

Regarding the WMS layers, I created entries into  
http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers. These entries are 
accessible in JOSM through WMS/TMS Preferences.

The objective is to facililate validation of content vs Canvec and Geobase. For 
example, it is possible to validate rapidly a portion of road without having to 
load Canvec.osm files. Since the Canvec toporama layer do not show the 
road names, I simply use Geobase roads for names. Geobase entries are 
derived from  http://www.geobase.ca/geobase/en/wms/index.html page.

Canvec
http://wms.sst-sw.rncan.gc.ca/wms/toporama_fr?REQUEST=GetMapSERVICE=wmsVERSION=1.1.1EXCEPTIONS=application/vnd.ogc.se_inimageSRS={proj(EPSG:4326)}FORMAT=image/pngtransparent=truelayers=SCW-ToporamaWIDTH={width}height={height}BBOX={bbox}
 Geobase Hydrography

http://ows.geobase.ca/wms/geobase_en?service=wmsrequest=GetMapversion=1.1.1SRS=EPSG:4326style=format=image/pngtransparent=truelayers=nhn:hydrography,nhn:networkWIDTH={width}height={height}BBOX={bbox}
 
Geobase Roads
http://ows.geobase.ca/wms/geobase_en?service=wmsrequest=GetMapversion=1.1.1SRS=EPSG:4326style=format=image/pngtransparent=truelayers=nrn:addressrange,nrn:streetnames,nrn:streetnames:streetnames_primary,nrn:streetnames:streetnames_secondary,nrn:streetnames:streetnames_other,nhn:hydrography,nrn:roadnetworkWIDTH={width}height={height}BBOX={bbox}
 
What other contributors are thinking about this? If people find it usefull,  It 
would be good that I describe this into 
http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers. 
Regarding route 117, I am sure this is not called Route 
transcanadienne. There is only one crossing Québec. The highways 20 and 
40 represent Route transcanadienne.  Governments give sometimes names to
 parts of roads like the Jean Lesage section. This is also the case for 
route 117 north of Saint-Jovite. There, it is call route du Curé-Labelle
 as showed on the Geobase layer. In fact, Geobase names are provided by 
Government of Québec.
 
Pierre 




 De : Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org 
Envoyé le : Jeudi 23 août 2012 14h19
Objet : Re: [Talk-ca] Canvec import issues
 
Hi Pierre,

In 2009 we had a meeting in Sherbrooke. This was in the day the Canvec landuse 
was starting to run. Discussions were already going on on talk-ca and the wiki 
pages for several months. Emilie Laffray joined the meeting with Skype, and 
explained how the Corine Land Cover was handled. While it seemed to be a nice 
way, it somehow disappeared from the radar. Perhaps the Canadian community is 
too small, or everyone is too busy with other things, like work, etc.

Regarding the duplicate ways, caused by lakes punched out of forests, I'm 
considering to write a small tool. It would be a good opportunity to learn 
about the frameworks for handling OSM data which have been developed in the 
last couple of years. I won't distribute in public, but people could ask for 
it once it is ready. I will certainly make it single purpose only, i.e. 
handling only data which has been tagged with one of the Canvec source tags.

Regarding the WMS layer, I'll check out the URL. I guess you're referring to 
the one listed here? http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers
Here is my first and only attempt to replace Geobase NRN roads, which haven't 
been touched by others, by Canvec roads: 
http://www.openstreetmap.org/browse/changeset/11848571
Although copying names involves manual labor, checking and replacing roads 
individually is also manual labor. Note that the sheet area is only to the 
south and east of St. Zacharie. The bounding box is much larger, since I split 
up Geobase roads at the boundary of the sheet.

Re. Route 117: it is called Route 117 in Canvec. Probably it's best known as 
Route Transcanadienne in this area. Near Quebec City the highway is called 
Route Jean-Lesage, although it's also part of the Trans Canada Highway.

Frank

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec import issues

[Pierre Béland]

Harald,

it would probably be possible to prepare a mapcss style sheet to highlight in 
JOSM those ways with tag name not present. But I dont know wich mapcss 
expression would do.


 
Pierre 




 De : Harald Kliems kli...@gmail.com
À : Pierre Béland infosbelas-...@yahoo.fr 
Cc : talk-ca@openstreetmap.org talk-ca@openstreetmap.org 
Envoyé le : Jeudi 23 août 2012 18h43
Objet : Re: [Talk-ca] Canvec import issues
 
Pierre,
I've been using the Geobase layer for adding street names, too, and
it's a great tool. Do you (or anyone else) know an easy way to make
JOSM display/highlight unnamed streets? That would make the process
much smoother.
Harald.

On Thu, Aug 23, 2012 at 4:21 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:
 Frank,

 Regarding the WMS layers, I created entries into
 http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers. These entries are
 accessible in JOSM through WMS/TMS Preferences.

 The objective is to facililate validation of content vs Canvec and Geobase.
 For example, it is possible to validate rapidly a portion of road without
 having to load Canvec.osm files. Since the Canvec toporama layer do not show
 the road names, I simply use Geobase roads for names. Geobase entries are
 derived from  http://www.geobase.ca/geobase/en/wms/index.html page.

 Canvec
 http://wms.sst-sw.rncan.gc.ca/wms/toporama_fr?REQUEST=GetMapSERVICE=wmsVERSION=1.1.1EXCEPTIONS=application/vnd.ogc.se_inimageSRS={proj(EPSG:4326)}FORMAT=image/pngtransparent=truelayers=SCW-ToporamaWIDTH={width}height={height}BBOX={bbox}

 Geobase Hydrography

 http://ows.geobase.ca/wms/geobase_en?service=wmsrequest=GetMapversion=1.1.1SRS=EPSG:4326style=format=image/pngtransparent=truelayers=nhn:hydrography,nhn:networkWIDTH={width}height={height}BBOX={bbox}

 Geobase Roads
 http://ows.geobase.ca/wms/geobase_en?service=wmsrequest=GetMapversion=1.1.1SRS=EPSG:4326style=format=image/pngtransparent=truelayers=nrn:addressrange,nrn:streetnames,nrn:streetnames:streetnames_primary,nrn:streetnames:streetnames_secondary,nrn:streetnames:streetnames_other,nhn:hydrography,nrn:roadnetworkWIDTH={width}height={height}BBOX={bbox}

 What other contributors are thinking about this? If people find it usefull,
 It would be good that I describe this into
 http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers.


 Regarding route 117, I am sure this is not called Route transcanadienne.
 There is only one crossing Québec. The highways 20 and 40 represent Route
 transcanadienne.  Governments give sometimes names to parts of roads like
 the Jean Lesage section. This is also the case for route 117 north of
 Saint-Jovite. There, it is call route du Curé-Labelle as showed on the
 Geobase layer. In fact, Geobase names are provided by Government of Québec.

 Pierre

 
 De : Frank Steggink stegg...@steggink.org
 À : talk-ca@openstreetmap.org
 Envoyé le : Jeudi 23 août 2012 14h19

 Objet : Re: [Talk-ca] Canvec import issues

 Hi Pierre,

 In 2009 we had a meeting in Sherbrooke. This was in the day the Canvec
 landuse was starting to run. Discussions were already going on on talk-ca
 and the wiki pages for several months. Emilie Laffray joined the meeting
 with Skype, and explained how the Corine Land Cover was handled. While it
 seemed to be a nice way, it somehow disappeared from the radar. Perhaps the
 Canadian community is too small, or everyone is too busy with other things,
 like work, etc.

 Regarding the duplicate ways, caused by lakes punched out of forests, I'm
 considering to write a small tool. It would be a good opportunity to learn
 about the frameworks for handling OSM data which have been developed in the
 last couple of years. I won't distribute in public, but people could ask for
 it once it is ready. I will certainly make it single purpose only, i.e.
 handling only data which has been tagged with one of the Canvec source tags.

 Regarding the WMS layer, I'll check out the URL. I guess you're referring to
 the one listed here? http://wiki.openstreetmap.org/wiki/Canada_WMS_Layers
 Here is my first and only attempt to replace Geobase NRN roads, which
 haven't been touched by others, by Canvec roads:
 http://www.openstreetmap.org/browse/changeset/11848571
 Although copying names involves manual labor, checking and replacing roads
 individually is also manual labor. Note that the sheet area is only to the
 south and east of St. Zacharie. The bounding box is much larger, since I
 split up Geobase roads at the boundary of the sheet.

 Re. Route 117: it is called Route 117 in Canvec. Probably it's best known
 as Route Transcanadienne in this area. Near Quebec City the highway is
 called Route Jean-Lesage, although it's also part of the Trans Canada
 Highway.

 Frank


 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca




-- 
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

Hi Pierre,

Regarding the duplicated ways, I'll get to that by replying Daniel's mail.
Regarding the toponyms, the user I'm having contact with is refering to 
Sûreté de Québec, for example this page: 
http://www.sq.gouv.qc.ca/poste-mrc-des-pays-d-en-haut/organisation/carte-detaillee-pays-haut.pdf


I don't know if both data sources can be considered public domain.  As 
far as I know, the guidelines for the federal government don't apply to 
provincial and local governments. See also the discussion about 
importing data from the Ville de Québec.


Frank

On 21-8-2012 20:59, Pierre Béland wrote:

Frank

The NEtiquette is always important in these circumstances. Lets hope 
this mapper will learn how to deal with the community.


I Looked rapidly at the data.I see a multipolygon natural=wood 
Relation : 2362646 that contains 72 members. I see that you imported a 
wooded area way=176778952 that is part of this relation. It also 
overlaps for the 2/3 with a lake way=57988179. I see similar situation 
with way 176778559.  Unless I missed something, my understanding is 
that you should simply remove ways 176778952 and 176778559 and any 
others that duplicate what is already defined  by relation 2362646.


The Quebec toponyms may sometime be more complete then Canvec. But not 
all the lakes have names and it is not easy to find infos for a 
specific area. You can  search for a specific name at 
http://www.toponymie.gouv.qc.ca/.
See 
http://www.toponymie.gouv.qc.ca/ct/ToposWeb/recherche.aspx?s=lac-ouimetx=0y=0 
for lac Ouimet results

Pierre


*De :* Frank Steggink stegg...@steggink.org
*À :* talk-ca@openstreetmap.org
*Envoyé le :* Mardi 21 août 2012 13h32
*Objet :* [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat
hostile tone) after the Canvec import I've done over the weekend
northwest of Montréal. He was not really happy with the way how
the import has handled. The way the Canvec data is currently
provided, leaves some room for improvement. I'm not sure if all
his issues have been discussed in the past (since I haven't
followed all Canvec discussions, especially in the beginning), but
I could see some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1].
Note that the lakes (and most of the streams) were imported
previously by someone else, based on NHN data, but the same issue
plays with the Canvec data itself. (This left me to the task to
leave the Canvec lakes out of the upload, as well as most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of
the ways are duplicated. The outer boundary of the wooded area is
a separate polygon from the lake itself.  However, Lac Gauthier on
the right is a different case. This lake has been cut out from
the woods, and I left the inner boundary intact. JOSM is not
complaining about this. Since dealing with multipolygons remains a
sticky issue, I have not done that. I think it would be better to
take care of these issues with some tool. Although using a tool is
considered dangerously (and rightfully so!), dealing with
multipolygons is prone to errors as well.

Another issue is that some lakes do not have names, but contain a
separate node (not part of any of the ways) with natural=water and
name=* tags. I can only assume that this comes from the source
data. In many cases it is hard to determine the extent of the
lake, since it can gradually taper into a river. This was not
mentioned directly by the user, but I thought he was referring to
this.

His issue turned out to be somewhat different. There is a place
node near Lac Gauthier, with the same name. I explained to this
that this must be the name of a hamlet. The non-official tag
place=locality is probably due to this confusion. This name is
also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes
and ways. This was an omission, so I have corrected this. I scan
the existing data in order not to duplicate existing features. Of
course this is prone to errors as well, especially in a large area
which is void of address nodes and ways, except for two ways
around a lake...

I'm not asking anyone for solutions. I can easily think about
them as well, but that doesn't make the problem go away. Thinking
about the solution is the easiest part, but working it out and
implementing it is much more difficult. It is more than simply
typing in some code and then run it over the data. Instead of
doing that, I have tried to explain him something about the hybrid
data model OSM is using (not purely geographical, but also not
purely topological). And of course there is also the gap between

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

Hi Daniel, Pierre,

It is possible to reuse ways in the OSM datamodel, as you know. It is 
also possible to do this, while having to make extracts later. For 
example, when you only want to select lakes, you should do the following 
in JOSM:

* Select natural=water, replace selection
* Select child selected, add to selection
This way you have all lakes, including multipolygon ones with islands. 
Note that the islands could have tags applied on them as well. You can 
deal with them after you've copied the data to another layer.


Anyways, unfortunately it is not possible to have ways being reused 
easily with JOSM. At least not with standard JOSM or the Validator tool. 
Perhaps there is a plug-in. I haven't looked into that. However, if this 
functionality were to be implemented, it could easily open a new can of 
worms. Sometimes it also happens that functionality is revised (wholly 
or partially). For example, that is the case with unclosed ways. Now 
it isn't possible to merge duplicate nodes with the Validator tool. With 
all the crossing address interpolation ways and streams, I need to merge 
them manually tens of times per sheet, sometimes even up to a hundred 
times. (Probably not much more, because sheets are being split up 
farther in crowded, residential areas.)


History also shows that everyone has his own standards, even amongst all 
the people who have imported Canvec data. However, that is an entirely 
different discussion...


Frank

On 21-8-2012 22:49, Daniel Begin wrote:


Bonjour Pierre,

The Canvec Geometric Model is explained in the following OSM wiki page ...

http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model

The model was adopted after discussions with the community. The model 
was designed to simplify the import of a selection of features by the  
contributors, instead of imposing import the entire contents by them.


However, history now shows that the community usually imports the 
entire content.


Compromises always bring pros and cons.!-)

Best regards,

Daniel



*From:*Pierre Béland [mailto:infosbelas-...@yahoo.fr]
*Sent:* August-21-12 16:04
*To:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Canvec import issues

I didn't do Canvec imports too much. Looking at various lakes in 
wooded areas,  I now realize that Canvec imports are often (always?) 
duplicating lakes. I do'nt know what was the reason to create these 
duplicate ways in the Canvec import file.  Should we duplicate the 
lakes to apply a inner role in the relation? Is this a reason for 
that? Or could we instead simply use the existing lake with a inner 
role in the wooded area polygon relation?


*/Pierre/**//*



*De :*Frank Steggink stegg...@steggink.org
*À :* talk-ca@openstreetmap.org
*Envoyé le :* Mardi 21 août 2012 13h32
*Objet :* [Talk-ca] Canvec import issues


Hi,

Today I was contacted by someone inquiring (with a somewhat hostile 
tone) after the Canvec import I've done over the weekend northwest of 
Montréal. He was not really happy with the way how the import has 
handled. The way the Canvec data is currently provided, leaves some 
room for improvement. I'm not sure if all his issues have been 
discussed in the past (since I haven't followed all Canvec 
discussions, especially in the beginning), but I could see some merit 
in some of the point.


Some examples he provided come from the Mt. Tremblant area [1]. Note 
that the lakes (and most of the streams) were imported previously by 
someone else, based on NHN data, but the same issue plays with the 
Canvec data itself. (This left me to the task to leave the Canvec 
lakes out of the upload, as well as most streams.)


On the left you see Lac Ouimet. He mentioned that a large part of the 
ways are duplicated. The outer boundary of the wooded area is a 
separate polygon from the lake itself.  However, Lac Gauthier on the 
right is a different case. This lake has been cut out from the 
woods, and I left the inner boundary intact. JOSM is not complaining 
about this. Since dealing with multipolygons remains a sticky issue, I 
have not done that. I think it would be better to take care of these 
issues with some tool. Although using a tool is considered 
dangerously (and rightfully so!), dealing with multipolygons is 
prone to errors as well.


Another issue is that some lakes do not have names, but contain a 
separate node (not part of any of the ways) with natural=water and 
name=* tags. I can only assume that this comes from the source data. 
In many cases it is hard to determine the extent of the lake, since it 
can gradually taper into a river. This was not mentioned directly by 
the user, but I thought he was referring to this.


His issue turned out to be somewhat different. There is a place node 
near Lac Gauthier, with the same name. I explained to this that this 
must be the name

Re: [Talk-ca] Canvec import issues

[Pierre Béland]

Frank, 

I dont think we can considere these as Open Data compatible with ODbl.


We dont know the license for Surete du Québec map. And no licensing information 
is given on the toponyms site.  You would have to contact them before using 
this information.


The government of Québec has just started is Open Data site and as discussed 
before on the list their license is not considered compatible with ODbl.

But they are open to discussion. After I wrote a request on the Open Data site, 
I was contacted last week by a government of Québec person. This person wants 
to clarify licensing problems. I will write a specific memo about that.

 
Pierre 




 De : Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org 
Envoyé le : Mercredi 22 août 2012 11h52
Objet : Re: [Talk-ca] Canvec import issues
 
Hi Pierre,

Regarding the duplicated ways, I'll get to that by replying Daniel's mail.
Regarding the toponyms, the user I'm having contact with is refering to Sûreté 
de Québec, for example this page: 
http://www.sq.gouv.qc.ca/poste-mrc-des-pays-d-en-haut/organisation/carte-detaillee-pays-haut.pdf

I don't know if both data sources can be considered public domain.  As far as 
I know, the guidelines for the federal government don't apply to provincial 
and local governments. See also the discussion about importing data from the 
Ville de Québec.

Frank

On 21-8-2012 20:59, Pierre Béland wrote:
 Frank
 
 The NEtiquette is always important in these circumstances. Lets hope this 
 mapper will learn how to deal with the community.
 
 I Looked rapidly at the data.I see a multipolygon natural=wood Relation : 
 2362646 that contains 72 members. I see that you imported a wooded area 
 way=176778952 that is part of this relation. It also overlaps for the 2/3 
 with a lake way=57988179. I see similar situation with way 176778559.  
 Unless I missed something, my understanding is that you should simply remove 
 ways 176778952 and 176778559 and any others that duplicate what is already 
 defined  by relation 2362646.
 
 The Quebec toponyms may sometime be more complete then Canvec. But not all 
 the lakes have names and it is not easy to find infos for a specific area. 
 You can  search for a specific name at http://www.toponymie.gouv.qc.ca/.
 See 
 http://www.toponymie.gouv.qc.ca/ct/ToposWeb/recherche.aspx?s=lac-ouimetx=0y=0
  for lac Ouimet results
 Pierre
 
     
     *De :* Frank Steggink stegg...@steggink.org
     *À :* talk-ca@openstreetmap.org
     *Envoyé le :* Mardi 21 août 2012 13h32
     *Objet :* [Talk-ca] Canvec import issues
 
     Hi,
 
     Today I was contacted by someone inquiring (with a somewhat
     hostile tone) after the Canvec import I've done over the weekend
     northwest of Montréal. He was not really happy with the way how
     the import has handled. The way the Canvec data is currently
     provided, leaves some room for improvement. I'm not sure if all
     his issues have been discussed in the past (since I haven't
     followed all Canvec discussions, especially in the beginning), but
     I could see some merit in some of the point.
 
     Some examples he provided come from the Mt. Tremblant area [1].
     Note that the lakes (and most of the streams) were imported
     previously by someone else, based on NHN data, but the same issue
     plays with the Canvec data itself. (This left me to the task to
     leave the Canvec lakes out of the upload, as well as most streams.)
 
     On the left you see Lac Ouimet. He mentioned that a large part of
     the ways are duplicated. The outer boundary of the wooded area is
     a separate polygon from the lake itself.  However, Lac Gauthier on
     the right is a different case. This lake has been cut out from
     the woods, and I left the inner boundary intact. JOSM is not
     complaining about this. Since dealing with multipolygons remains a
     sticky issue, I have not done that. I think it would be better to
     take care of these issues with some tool. Although using a tool is
     considered dangerously (and rightfully so!), dealing with
     multipolygons is prone to errors as well.
 
     Another issue is that some lakes do not have names, but contain a
     separate node (not part of any of the ways) with natural=water and
     name=* tags. I can only assume that this comes from the source
     data. In many cases it is hard to determine the extent of the
     lake, since it can gradually taper into a river. This was not
     mentioned directly by the user, but I thought he was referring to
     this.
 
     His issue turned out to be somewhat different. There is a place
     node near Lac Gauthier, with the same name. I explained to this
     that this must be the name of a hamlet. The non-official tag
     place=locality is probably due to this confusion. This name is
     also visible on the original topo map [2

Re: [Talk-ca] Canvec import issues

[Paul Norman]

I see the problem as being the importing of everything as being the problem,
not the geometric model :)

 

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues

 

Bonjour Pierre,

 

The Canvec Geometric Model is explained in the following OSM wiki page ...

http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model

 

The model was adopted after discussions with the community. The model was
designed to simplify the import of a selection of features by the
contributors, instead of imposing import the entire contents by them.

 

However, history now shows that the community usually imports the entire
content.

Compromises always bring pros and cons.!-)

 

Best regards,

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: August-21-12 16:04
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues

 

 

I didn't do Canvec imports too much. Looking at various lakes in wooded
areas,  I now realize that Canvec imports are often (always?) duplicating
lakes. I do'nt know what was the reason to create these duplicate ways in
the Canvec import file.  Should we duplicate the lakes to apply a inner role
in the relation? Is this a reason for that? Or could we instead simply use
the existing lake with a inner role in the wooded area polygon relation?

 

Pierre 

  _  

De : Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org 
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues


Hi,

Today I was contacted by someone inquiring (with a somewhat hostile tone)
after the Canvec import I've done over the weekend northwest of Montréal. He
was not really happy with the way how the import has handled. The way the
Canvec data is currently provided, leaves some room for improvement. I'm not
sure if all his issues have been discussed in the past (since I haven't
followed all Canvec discussions, especially in the beginning), but I could
see some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1]. Note that
the lakes (and most of the streams) were imported previously by someone
else, based on NHN data, but the same issue plays with the Canvec data
itself. (This left me to the task to leave the Canvec lakes out of the
upload, as well as most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of the ways
are duplicated. The outer boundary of the wooded area is a separate polygon
from the lake itself.  However, Lac Gauthier on the right is a different
case. This lake has been cut out from the woods, and I left the inner
boundary intact. JOSM is not complaining about this. Since dealing with
multipolygons remains a sticky issue, I have not done that. I think it would
be better to take care of these issues with some tool. Although using a tool
is considered dangerously (and rightfully so!), dealing with multipolygons
is prone to errors as well.

Another issue is that some lakes do not have names, but contain a separate
node (not part of any of the ways) with natural=water and name=* tags. I can
only assume that this comes from the source data. In many cases it is hard
to determine the extent of the lake, since it can gradually taper into a
river. This was not mentioned directly by the user, but I thought he was
referring to this.

His issue turned out to be somewhat different. There is a place node near
Lac Gauthier, with the same name. I explained to this that this must be the
name of a hamlet. The non-official tag place=locality is probably due to
this confusion. This name is also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes and ways.
This was an omission, so I have corrected this. I scan the existing data in
order not to duplicate existing features. Of course this is prone to errors
as well, especially in a large area which is void of address nodes and ways,
except for two ways around a lake...

I'm not asking anyone for solutions. I can easily think about them as
well, but that doesn't make the problem go away. Thinking about the solution
is the easiest part, but working it out and implementing it is much more
difficult. It is more than simply typing in some code and then run it over
the data. Instead of doing that, I have tried to explain him something about
the hybrid data model OSM is using (not purely geographical, but also not
purely topological). And of course there is also the gap between idealists
and realists. I see the current state of OSM as the status quo, so I take it
for granted. I think that Canvec falls within that status quo situation as
well, otherwise the OSM data offered by NRCan would have looked differently,
after all those years of discussions and reviews.

I have invited this user to discuss the issues he found on talk-ca. I think
that would be much more constructive than

Re: [Talk-ca] Canvec import issues

[Béland Pierre]

David and Paul, do you think this was the problem with these imports???
 
Pierre 




 De : David E. Nelson denelso...@yahoo.ca
À : Paul Norman penor...@mac.com; talk-ca@openstreetmap.org 
talk-ca@openstreetmap.org 
Envoyé le : Mercredi 22 août 2012 21h59
Objet : Re: [Talk-ca] Canvec import issues
 

Yeah, don't just do blanket imports.  Just import whatever data OSM *does not* 
have.



- David E. Nelson


 From: Paul Norman penor...@mac.com
To: 'Daniel Begin' jfd...@hotmail.com; 'Pierre Béland' 
infosbelas-...@yahoo.fr; talk-ca@openstreetmap.org 
Sent: Wednesday, August 22, 2012 6:52:12 PM
Subject: Re: [Talk-ca] Canvec import issues
 

I see the problem as being the importing of everything as being the problem, 
not the geometric model :)
 
From:Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
Bonjour Pierre,
 
The Canvec Geometric Model is explained in the following OSM wiki page ...
http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model
 
The model was adopted after discussions with the community. The model was 
designed to simplify the import of a selection of features by the  
contributors, instead of imposing import the entire contents by them.
 
However, history now shows that the community usually imports the entire 
content.
Compromises always bring pros and cons.!-)
 
Best regards,
Daniel
 



From:Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: August-21-12 16:04
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
 
I didn't do Canvec imports too much. Looking at various lakes in wooded 
areas,  I now realize that Canvec imports are often (always?) duplicating 
lakes. I do'nt know what was the reason to create these duplicate ways in the 
Canvec import file.  Should we duplicate the lakes to apply a inner role in 
the relation? Is this a reason for that? Or could we instead simply use the 
existing lake with a inner role in the wooded area polygon relation?
 
Pierre 



De :Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org 
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat hostile tone) 
after the Canvec import I've done over the weekend northwest of Montréal. He 
was not really happy with the way how the import has handled. The way the 
Canvec data is currently provided, leaves some room for improvement. I'm not 
sure if all his issues have been discussed in the past (since I haven't 
followed all Canvec discussions, especially in the beginning), but I could see 
some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1]. Note that the 
lakes (and most of the streams) were imported previously by someone else, 
based on NHN data, but the same issue plays with the Canvec data itself. (This 
left me to the task to leave the Canvec lakes out of the upload, as well as 
most streams.)

On the left you see Lac Ouimet. He
 mentioned that a large part of the ways are duplicated. The outer boundary of 
the wooded area is a separate polygon from the lake itself.  However, Lac 
Gauthier on the right is a different case. This lake has been cut out from 
the woods, and I left the inner boundary intact. JOSM is not complaining about 
this. Since dealing with multipolygons remains a sticky issue, I have not done 
that. I think it would be better to take care of these issues with some tool. 
Although using a tool is considered dangerously (and rightfully so!), dealing 
with multipolygons is prone to errors as well.

Another issue is that some lakes do not have names, but contain a separate 
node (not part of any of the ways) with natural=water and name=* tags. I can 
only assume that this comes from the source data. In many cases it is hard to 
determine the extent of the lake, since it can gradually taper into a river. 
This was not mentioned directly by the user, but I
 thought he was referring to this.

His issue turned out to be somewhat different. There is a place node near Lac 
Gauthier, with the same name. I explained to this that this must be the name 
of a hamlet. The non-official tag place=locality is probably due to this 
confusion. This name is also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes and ways. This 
was an omission, so I have corrected this. I scan the existing data in order 
not to duplicate existing features. Of course this is prone to errors as well, 
especially in a large area which is void of address nodes and ways, except for 
two ways around a lake...

I'm not asking anyone for solutions. I can easily think about them as well, 
but that doesn't make the problem go away. Thinking about the solution

Re: [Talk-ca] Canvec import issues

[Pierre Béland]

Frank 


The NEtiquette is always important in these circumstances. Lets hope this 
mapper will learn how to deal with the community.
I Looked rapidly at the data.I see a multipolygon natural=wood Relation : 
2362646 that contains 72 
members. I see that you imported a wooded area way=176778952 that is 
part of this relation. It also overlaps for the 2/3 with a lake 
way=57988179. I see similar situation with way 176778559.  Unless I 
missed something, my understanding is that you should simply remove ways 
176778952 and 176778559 and any others that duplicate what is already defined  
by relation 2362646.
The Quebec toponyms may sometime be more complete then Canvec. But not all the 
lakes have names and it is not 
easy to find infos for a specific area. You can  search for a specific 
name at http://www.toponymie.gouv.qc.ca/.
See 
http://www.toponymie.gouv.qc.ca/ct/ToposWeb/recherche.aspx?s=lac-ouimetx=0y=0 
for lac Ouimet results 
 
Pierre 




 De : Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org 
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues
 
Hi,

Today I was contacted by someone inquiring (with a somewhat hostile tone) 
after the Canvec import I've done over the weekend northwest of Montréal. He 
was not really happy with the way how the import has handled. The way the 
Canvec data is currently provided, leaves some room for improvement. I'm not 
sure if all his issues have been discussed in the past (since I haven't 
followed all Canvec discussions, especially in the beginning), but I could see 
some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1]. Note that the 
lakes (and most of the streams) were imported previously by someone else, 
based on NHN data, but the same issue plays with the Canvec data itself. (This 
left me to the task to leave the Canvec lakes out of the upload, as well as 
most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of the ways are 
duplicated. The outer boundary of the wooded area is a separate polygon from 
the lake itself.  However, Lac Gauthier on the right is a different case. This 
lake has been cut out from the woods, and I left the inner boundary intact. 
JOSM is not complaining about this. Since dealing with multipolygons remains a 
sticky issue, I have not done that. I think it would be better to take care of 
these issues with some tool. Although using a tool is considered dangerously 
(and rightfully so!), dealing with multipolygons is prone to errors as well.

Another issue is that some lakes do not have names, but contain a separate 
node (not part of any of the ways) with natural=water and name=* tags. I can 
only assume that this comes from the source data. In many cases it is hard to 
determine the extent of the lake, since it can gradually taper into a river. 
This was not mentioned directly by the user, but I thought he was referring to 
this.

His issue turned out to be somewhat different. There is a place node near Lac 
Gauthier, with the same name. I explained to this that this must be the name 
of a hamlet. The non-official tag place=locality is probably due to this 
confusion. This name is also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes and ways. This 
was an omission, so I have corrected this. I scan the existing data in order 
not to duplicate existing features. Of course this is prone to errors as well, 
especially in a large area which is void of address nodes and ways, except for 
two ways around a lake...

I'm not asking anyone for solutions. I can easily think about them as well, 
but that doesn't make the problem go away. Thinking about the solution is the 
easiest part, but working it out and implementing it is much more difficult. 
It is more than simply typing in some code and then run it over the data. 
Instead of doing that, I have tried to explain him something about the hybrid 
data model OSM is using (not purely geographical, but also not purely 
topological). And of course there is also the gap between idealists and 
realists. I see the current state of OSM as the status quo, so I take it for 
granted. I think that Canvec falls within that status quo situation as well, 
otherwise the OSM data offered by NRCan would have looked differently, after 
all those years of discussions and reviews.

I have invited this user to discuss the issues he found on talk-ca. I think 
that would be much more constructive than having him directing all those 
issues to me, since they occur far beyond his own backyard as well...

Regards,

Frank


[1] http://www.openstreetmap.org/?lat=46.1749lon=-74.5535zoom=14layers=M
[2] 
ftp://ftp2.cits.rncan.gc.ca/pub/canmatrix2/50k_tif/031/j/canmatrix2_031j02_tif.zip


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] Canvec import issues

[Pierre Béland]

I didn't do Canvec imports too much. Looking at various lakes in wooded areas,  
I now realize that Canvec imports are often (always?) duplicating lakes. I 
do'nt know what was the reason to create these duplicate ways in the Canvec 
import file.  Should we duplicate the lakes to apply a inner role in the 
relation? Is this a reason for that? Or could we instead simply use the 
existing lake with a inner role in the wooded area polygon relation? 
Pierre 




 De : Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org 
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues
 
Hi,

Today I was contacted by someone inquiring (with a somewhat hostile tone) 
after the Canvec import I've done over the weekend northwest of Montréal. He 
was not really happy with the way how the import has handled. The way the 
Canvec data is currently provided, leaves some room for improvement. I'm not 
sure if all his issues have been discussed in the past (since I haven't 
followed all Canvec discussions, especially in the beginning), but I could see 
some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1]. Note that the 
lakes (and most of the streams) were imported previously by someone else, 
based on NHN data, but the same issue plays with the Canvec data itself. (This 
left me to the task to leave the Canvec lakes out of the upload, as well as 
most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of the ways are 
duplicated. The outer boundary of the wooded area is a separate polygon from 
the lake itself.  However, Lac Gauthier on the right is a different case. This 
lake has been cut out from the woods, and I left the inner boundary intact. 
JOSM is not complaining about this. Since dealing with multipolygons remains a 
sticky issue, I have not done that. I think it would be better to take care of 
these issues with some tool. Although using a tool is considered dangerously 
(and rightfully so!), dealing with multipolygons is prone to errors as well.

Another issue is that some lakes do not have names, but contain a separate 
node (not part of any of the ways) with natural=water and name=* tags. I can 
only assume that this comes from the source data. In many cases it is hard to 
determine the extent of the lake, since it can gradually taper into a river. 
This was not mentioned directly by the user, but I thought he was referring to 
this.

His issue turned out to be somewhat different. There is a place node near Lac 
Gauthier, with the same name. I explained to this that this must be the name 
of a hamlet. The non-official tag place=locality is probably due to this 
confusion. This name is also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes and ways. This 
was an omission, so I have corrected this. I scan the existing data in order 
not to duplicate existing features. Of course this is prone to errors as well, 
especially in a large area which is void of address nodes and ways, except for 
two ways around a lake...

I'm not asking anyone for solutions. I can easily think about them as well, 
but that doesn't make the problem go away. Thinking about the solution is the 
easiest part, but working it out and implementing it is much more difficult. 
It is more than simply typing in some code and then run it over the data. 
Instead of doing that, I have tried to explain him something about the hybrid 
data model OSM is using (not purely geographical, but also not purely 
topological). And of course there is also the gap between idealists and 
realists. I see the current state of OSM as the status quo, so I take it for 
granted. I think that Canvec falls within that status quo situation as well, 
otherwise the OSM data offered by NRCan would have looked differently, after 
all those years of discussions and reviews.

I have invited this user to discuss the issues he found on talk-ca. I think 
that would be much more constructive than having him directing all those 
issues to me, since they occur far beyond his own backyard as well...

Regards,

Frank


[1] http://www.openstreetmap.org/?lat=46.1749lon=-74.5535zoom=14layers=M
[2] 
ftp://ftp2.cits.rncan.gc.ca/pub/canmatrix2/50k_tif/031/j/canmatrix2_031j02_tif.zip


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec imports allowed again?

[James Ewen]

On Sat, Jul 21, 2012 at 1:09 AM, Paul Norman penor...@mac.com wrote:

  From: David E. Nelson [mailto:denelso...@yahoo.ca]
  Subject: [Talk-ca] CanVec imports allowed again?
 
  Now that the redaction bot has apparently finished its sweep of Canada,
  is it safe for CanVec imports to be resumed?  I want to try my hand at
  importing a few tiles around where I live.

 The bot is still running. It shouldn't impact mapping although uploading
 frequently is always a good idea. Imports are still not to be done.

Are we at the point where we can continue mapping in OSM yet?

There's a lot of damaged areas around here that need to be repaired,
but it's a waste of time doing so if the bot is still running.

--
James
VE6SRV

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] canvec import in ontario

[Jesse Davis]

Hello,

I'd like to import some canvec data for the area just north of Plevna,
Ontario, Canada (NTS 031F02), which has not been imported and for the
most part is completely blank. I have downloaded the most recent canvec
10 data and it looks like the import is easy enough to do using the 
provided osm files and the josm editor (I've done many edits in the past 
with josm). 

I imported a tile (NTS 031F02.0.0.0) before realizing that there were
import guidelines, and I shouldn't just go ahead without first
consulting the community. So, I'd just like to make sure it's ok to
proceed.

I will use a separate account for the imports as per the guideline.

Is there anything else I should know or do before proceeding?

Thanks,
Jesse Davis







___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec imports allowed again?

[David E. Nelson]

I've looked at a couple of videos on YouTube.

http://www.youtube.com/watch?v=uR0OrnACPHk
http://www.youtube.com/watch?v=OJr_gucFGMY

 
- David E. Nelson


- Original Message -

From: Iain Ingram i...@monkeyface.ca
To: David E. Nelson denelso...@yahoo.ca
Cc: 
Sent: Thursday, July 26, 2012 10:00:54 PM
Subject: Re: [Talk-ca] CanVec imports allowed again?

Hello David,

I was wondering if you had a quick tutorial about canvec imports? It seems that 
several areas in the Alberta Lake Louis area have been damaged and I thought I 
would start with some re-imports 

Thanks
Iain
On 2012-07-21, at 12:58 AM, David E. Nelson wrote:

 Now that the redaction bot has apparently finished its sweep of Canada, is it 
 safe for CanVec imports to be resumed?  I want to try my hand at importing a 
 few tiles around where I live.
 
  
 - David E. Nelson
 
 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] CanVec imports allowed again?

[David E. Nelson]

Now that the redaction bot has apparently finished its sweep of Canada, is it 
safe for CanVec imports to be resumed?  I want to try my hand at importing a 
few tiles around where I live.

 
- David E. Nelson

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] CanVec imports allowed again?

[Paul Norman]

 From: David E. Nelson [mailto:denelso...@yahoo.ca]
 Subject: [Talk-ca] CanVec imports allowed again?
 
 Now that the redaction bot has apparently finished its sweep of Canada,
 is it safe for CanVec imports to be resumed?  I want to try my hand at
 importing a few tiles around where I live.

The bot is still running. It shouldn't impact mapping although uploading
frequently is always a good idea. Imports are still not to be done. 


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Canvec in Potlatch 2

[Richard Fairhurst]

Hello talk-ca people,

I've made a little change to Potlatch 2 that will ease the process of 
loading Canvec data.


Potlatch's approach is very much here is some data that you can use to 
help your mapping, rather than here is some data you can upload in 
bulk, and the idea is that you load the data as a vector background 
then pull through the bits you want.


You can find out how to do this at:
http://wiki.openstreetmap.org/wiki/Canvec#Using_Potlatch

cheers
Richard


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Canvec in Potlatch 2

[James Ewen]

On Tue, Jul 3, 2012 at 7:38 AM, Richard Fairhurst rich...@systemed.net wrote:

 I've made a little change to Potlatch 2 that will ease the process of
 loading Canvec data.

 Potlatch's approach is very much here is some data that you can use to help
 your mapping, rather than here is some data you can upload in bulk, and
 the idea is that you load the data as a vector background then pull
 through the bits you want.

Sweet! I was tempted to go to the dark side to be able to import
CanVec data with Merkaartor or JOSM, but I missed the intuitive
interface that Potlatch provides.

Not only do I have my cake, but I get to eat it as well... I think
there's even icing on it these days!

Thanks for all the work you do making these tools so easy to use and
integrated so well!

-- 
James
VE6SRV

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec and other external sources

[Bégin , Daniel]

Bonjour Richard,

I've modified my scripts to produce .osm files having the appropriate xml tag...
osm version='0.6' upload='false'.

I'll introduce it in the Canvec.osm conversion process later today. Eventually, 
all of Canvec.osm files - Release 10 and later - will be processed that way.

Thanks to Paul

Best regards,
Daniel



-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: April 9, 2012 09:20
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] canvec and other external sources

Dear all,

Paul Norman pointed this out to me.

If canvec, or other external source data is created as an osm file, with

osm version='0.6' upload='false'
instead of the ordinary
osm version=0.6

that will protect a mapper who uses that data from a class of embarrassing 
accidents.  When using a canvec file for reference, a mapper might have several 
file layers open in JOSM.  Pressing upload with the wrong layer selected may 
upload data that was not intended or that duplicates existing data.  
upload=false gives the mapper another chance to catch their error.  A 
dialogue box is presented before uploading a layer based on a file with 
upload=false.

To be clear, the data can still be uploaded.  Another warning is offered before 
the upload so that the mapper can double-check the action.

Do we agree that this would be an improvement to the CanVec data?
Daniel, would you consider making this change for future CanVec product?

Best regards,
Richard

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[Bégin , Daniel]

Bonjour,

I'll have a look to see if I can do something for it in the next release. 

I suspect that might be caused by data resolution. Lat and Lon are stored in 
decimal degrees with 7 digits precision (48.1234567). The 7th digit will 
provide a precision around 0.001 meter. The 6th digit a precision around 0.027 
meter witch look like your 0.03 meter.

Cheers
Daniel

-Original Message-
From: michael bishop [mailto:cle...@nbnet.nb.ca] 
Sent: January 30, 2012 16:11
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] canvec data offset

ive been working with canvec for a few days now, and ive noticed some of the 
data is offset by 0.03 meters its not matching up with nearby tiles

for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to write them 
down


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[michael bishop]

the south east corner of 021O10.0 is at 47.534 by -66.7500013
the north east corner of 021O07.1 (should be exact same node), is at 
47.500 by -66.750
the exact offset differs from corner to corner, some are off more then 
others, some are off in a different direction



On 01/31/2012 08:11 AM, Bégin, Daniel wrote:

Bonjour,

I'll have a look to see if I can do something for it in the next release.

I suspect that might be caused by data resolution. Lat and Lon are stored in 
decimal degrees with 7 digits precision (48.1234567). The 7th digit will 
provide a precision around 0.001 meter. The 6th digit a precision around 0.027 
meter witch look like your 0.03 meter.

Cheers
Daniel

-Original Message-
From: michael bishop [mailto:cle...@nbnet.nb.ca]
Sent: January 30, 2012 16:11
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] canvec data offset

ive been working with canvec for a few days now, and ive noticed some of the 
data is offset by 0.03 meters its not matching up with nearby tiles

for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to write them 
down


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[Frank Steggink]

I've seen some of these deviations as well during Canvec import. Because 
they are so small ( 1 meter), I just decided to glue the polygons 
together, so any slivers are gone.


It is inconvenient though. Could it be related to that some sheets were 
originally still in NAD27, instead of NAD83 (which is approximately 
WGS84, as used by OSM)?


Frank

On 31-1-2012 15:06, michael bishop wrote:

the south east corner of 021O10.0 is at 47.534 by -66.7500013
the north east corner of 021O07.1 (should be exact same node), is at 
47.500 by -66.750
the exact offset differs from corner to corner, some are off more then 
others, some are off in a different direction



On 01/31/2012 08:11 AM, Bégin, Daniel wrote:

Bonjour,

I'll have a look to see if I can do something for it in the next 
release.


I suspect that might be caused by data resolution. Lat and Lon are 
stored in decimal degrees with 7 digits precision (48.1234567). The 
7th digit will provide a precision around 0.001 meter. The 6th digit 
a precision around 0.027 meter witch look like your 0.03 meter.


Cheers
Daniel

-Original Message-
From: michael bishop [mailto:cle...@nbnet.nb.ca]
Sent: January 30, 2012 16:11
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] canvec data offset

ive been working with canvec for a few days now, and ive noticed some 
of the data is offset by 0.03 meters its not matching up with nearby 
tiles


for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to 
write them down



___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[Bégin , Daniel]

Bonjour Frank,

The problem is not related to a NAD27-NAD83 conversion. With Michael's example, 
I am now sure that the problem is related to the quadtree clipper. I must find 
a way to round quadtree's tiles coordinates to a proper value.

Thanks to Michael

Best regard,
Daniel
 

-Original Message-
From: Frank Steggink [mailto:stegg...@steggink.org] 
Sent: January 31, 2012 11:56
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] canvec data offset

I've seen some of these deviations as well during Canvec import. Because they 
are so small ( 1 meter), I just decided to glue the polygons together, so any 
slivers are gone.

It is inconvenient though. Could it be related to that some sheets were 
originally still in NAD27, instead of NAD83 (which is approximately WGS84, as 
used by OSM)?

Frank

On 31-1-2012 15:06, michael bishop wrote:
 the south east corner of 021O10.0 is at 47.534 by -66.7500013 the 
 north east corner of 021O07.1 (should be exact same node), is at 
 47.500 by -66.750 the exact offset differs from corner to 
 corner, some are off more then others, some are off in a different 
 direction


 On 01/31/2012 08:11 AM, Bégin, Daniel wrote:
 Bonjour,

 I'll have a look to see if I can do something for it in the next 
 release.

 I suspect that might be caused by data resolution. Lat and Lon are 
 stored in decimal degrees with 7 digits precision (48.1234567). The 
 7th digit will provide a precision around 0.001 meter. The 6th digit 
 a precision around 0.027 meter witch look like your 0.03 meter.

 Cheers
 Daniel

 -Original Message-
 From: michael bishop [mailto:cle...@nbnet.nb.ca]
 Sent: January 30, 2012 16:11
 To: Talk-CA OpenStreetMap
 Subject: [Talk-ca] canvec data offset

 ive been working with canvec for a few days now, and ive noticed some 
 of the data is offset by 0.03 meters its not matching up with nearby 
 tiles

 for example 021O10 doesnt match up with 021O07

 ive noticed the problem on other tiles aswell, but didnt think to 
 write them down


 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca



 ___
 Talk-ca mailing list
 Talk-ca@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-ca



___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[michael bishop]

yeah, thats what i had to do for every node
but part is the issue there, is that when i merge 2 nodes, it doesnt 
always go to the 'right' position'
need to manualy select them in the right order to make it go in the 
right direction, it seems more like an error in the canvec data then an 
extra step i need to do on every tile
almost looks like floating point rounding errors, but not sure why some 
tiles are ok and others arent



On 01/30/2012 05:56 PM, Samuel Longiaru wrote:


Have you tried just zooming back a bit in JOSM and merging them?  It's 
part of my stitching process for each tile.  I've never had a merge 
refused because of a 3 cm difference (but, of course I've never looked 
that closely to see how far apart they were actually).  We're dealing 
with precision here... not accuracy at that level.


Sam

-Original Message-
*From*: michael bishop cle...@nbnet.nb.ca 
mailto:michael%20bishop%20%3ccle...@nbnet.nb.ca%3e
*To*: Samuel Longiaru longi...@shaw.ca 
mailto:samuel%20longiaru%20%3clongi...@shaw.ca%3e

*Subject*: Re: [Talk-ca] canvec data offset
*Date*: Mon, 30 Jan 2012 17:42:42 -0400

yeah, its not much, but its enough to screw up josm when trying to 
combine things between the 2 tiles
have to fix each node on the border one by one, no real patern to 
which direction they are shifted
even along a solid line (the edge of the tile), the nodes are going 
updown and zig-zagging across the edge



On 01/30/2012 05:31 PM, Samuel Longiaru wrote:


I can hardly put my finger to my nose to within .03 meters... and 
that's not even drunk.  :)


Sam L.
Kamloops



-Original Message-
*From*: michael bishop cle...@nbnet.nb.ca 
mailto:michael%20bishop%20%3ccle...@nbnet.nb.ca%3e
*To*: Talk-CA OpenStreetMap talk-ca@openstreetmap.org 
mailto:talk-ca%20openstreetmap%20%3ctalk...@openstreetmap.org%3e

*Subject*: [Talk-ca] canvec data offset
*Date*: Mon, 30 Jan 2012 17:11:27 -0400

ive been working with canvec for a few days now, and ive noticed some of
the data is offset by 0.03 meters
its not matching up with nearby tiles

for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to write
them down


___
Talk-ca mailing list
Talk-ca@openstreetmap.org  mailto:Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca






___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[Samuel Longiaru]

But which is the rightposition?  When one is given to be 3 cm's off
the other, neither is more accurate, given the data collection
technique.  I think you are beyond the accuracy of the data themselves
at that level.  While merging and then combining a stream or a road that
crosses a tile boundary, trying to decide which node is more accurate
is one of those questions best asked only during periods of intensive
navel contemplation.  Take either one.  The precision of the data exceed
their accuracy I would guess by several orders of magnitude.  Is the
next node along the way mapped to 3 cm accuracy?  Or the next, or the
next?  No.  Here is an example where good enough is TRULY good
enough.  It's all the science can bear. 

Sam

 

-Original Message-
From: michael bishop cle...@nbnet.nb.ca
To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] canvec data offset
Date: Mon, 30 Jan 2012 18:01:04 -0400

yeah, thats what i had to do for every node
but part is the issue there, is that when i merge 2 nodes, it doesnt
always go to the 'right' position'
need to manualy select them in the right order to make it go in the
right direction, it seems more like an error in the canvec data then an
extra step i need to do on every tile
almost looks like floating point rounding errors, but not sure why some
tiles are ok and others arent


On 01/30/2012 05:56 PM, Samuel Longiaru wrote: 

 
 Have you tried just zooming back a bit in JOSM and merging them?  It's
 part of my stitching process for each tile.  I've never had a merge
 refused because of a 3 cm difference (but, of course I've never looked
 that closely to see how far apart they were actually).  We're dealing
 with precision here... not accuracy at that level.
 
 Sam
 
 -Original Message-
 From: michael bishop cle...@nbnet.nb.ca
 To: Samuel Longiaru longi...@shaw.ca
 Subject: Re: [Talk-ca] canvec data offset
 Date: Mon, 30 Jan 2012 17:42:42 -0400
 
 yeah, its not much, but its enough to screw up josm when trying to
 combine things between the 2 tiles
 have to fix each node on the border one by one, no real patern to
 which direction they are shifted
 even along a solid line (the edge of the tile), the nodes are going
 updown and zig-zagging across the edge
 
 
 On 01/30/2012 05:31 PM, Samuel Longiaru wrote: 
 
  
  I can hardly put my finger to my nose to within .03 meters... and
  that's not even drunk.  :)
  
  Sam L.
  Kamloops
  
  
  
  -Original Message-
  From: michael bishop cle...@nbnet.nb.ca
  To: Talk-CA OpenStreetMap talk-ca@openstreetmap.org
  Subject: [Talk-ca] canvec data offset
  Date: Mon, 30 Jan 2012 17:11:27 -0400
  
  
  ive been working with canvec for a few days now, and ive noticed some of 
  the data is offset by 0.03 meters
  its not matching up with nearby tiles
  
  for example 021O10 doesnt match up with 021O07
  
  ive noticed the problem on other tiles aswell, but didnt think to write 
  them down
  
  
  ___
  Talk-ca mailing list
  Talk-ca@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-ca
  
  
 
 
 



___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] canvec data offset

[michael bishop]

i wrote a josm plugin that does all the math and marks the border of 
every canvec tile
some of the tiles match my grid perfectly, and match eachother with no 
overlap or gap

other tiles are offset slightly and dont fit the grid or eachother

by checking the grid in my plugin, i can tell which node is in the 
'correct' spot, because the canvec edges are always a certain fraction 
of a degree



On 01/30/2012 06:36 PM, Samuel Longiaru wrote:


But which is the rightposition?  When one is given to be 3 cm's off 
the other, neither is more accurate, given the data collection 
technique.  I think you are beyond the accuracy of the data themselves 
at that level.  While merging and then combining a stream or a road 
that crosses a tile boundary, trying to decide which node is more 
accurate is one of those questions best asked only during periods of 
intensive navel contemplation.  Take either one.  The precision of the 
data exceed  their accuracy I would guess by several orders of 
magnitude.  Is the next node along the way mapped to 3 cm accuracy?  
Or the next, or the next?  No.  Here is an example where good enough 
is TRULY good enough.  It's all the science can bear.


Sam



-Original Message-
*From*: michael bishop cle...@nbnet.nb.ca 
mailto:michael%20bishop%20%3ccle...@nbnet.nb.ca%3e
*To*: Talk-CA OpenStreetMap talk-ca@openstreetmap.org 
mailto:talk-ca%20openstreetmap%20%3ctalk...@openstreetmap.org%3e

*Subject*: Re: [Talk-ca] canvec data offset
*Date*: Mon, 30 Jan 2012 18:01:04 -0400

yeah, thats what i had to do for every node
but part is the issue there, is that when i merge 2 nodes, it doesnt 
always go to the 'right' position'
need to manualy select them in the right order to make it go in the 
right direction, it seems more like an error in the canvec data then 
an extra step i need to do on every tile
almost looks like floating point rounding errors, but not sure why 
some tiles are ok and others arent



On 01/30/2012 05:56 PM, Samuel Longiaru wrote:


Have you tried just zooming back a bit in JOSM and merging them?  
It's part of my stitching process for each tile.  I've never had a 
merge refused because of a 3 cm difference (but, of course I've never 
looked that closely to see how far apart they were actually).  We're 
dealing with precision here... not accuracy at that level.


Sam

-Original Message-
*From*: michael bishop cle...@nbnet.nb.ca 
mailto:michael%20bishop%20%3ccle...@nbnet.nb.ca%3e
*To*: Samuel Longiaru longi...@shaw.ca 
mailto:samuel%20longiaru%20%3clongi...@shaw.ca%3e

*Subject*: Re: [Talk-ca] canvec data offset
*Date*: Mon, 30 Jan 2012 17:42:42 -0400

yeah, its not much, but its enough to screw up josm when trying to 
combine things between the 2 tiles
have to fix each node on the border one by one, no real patern to 
which direction they are shifted
even along a solid line (the edge of the tile), the nodes are going 
updown and zig-zagging across the edge



On 01/30/2012 05:31 PM, Samuel Longiaru wrote:


I can hardly put my finger to my nose to within .03 meters... and 
that's not even drunk.  :)


Sam L.
Kamloops



-Original Message-
*From*: michael bishop cle...@nbnet.nb.ca 
mailto:michael%20bishop%20%3ccle...@nbnet.nb.ca%3e
*To*: Talk-CA OpenStreetMap talk-ca@openstreetmap.org 
mailto:talk-ca%20openstreetmap%20%3ctalk...@openstreetmap.org%3e

*Subject*: [Talk-ca] canvec data offset
*Date*: Mon, 30 Jan 2012 17:11:27 -0400

ive been working with canvec for a few days now, and ive noticed some of
the data is offset by 0.03 meters
its not matching up with nearby tiles

for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to write
them down


___
Talk-ca mailing list
Talk-ca@openstreetmap.org  mailto:Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca






___
Talk-ca mailing list
Talk-ca@openstreetmap.org  mailto:Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca



___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca