Re: [Talk-ca] Multipolygon problems

[Andrew]

Hello:
Does anybody see any more problem areas?

Pretty much no more polygon problems I think. Or maybe I hope

Andrew / CancevImports



On Tue, 2017-07-18 at 08:05 -0400, Andrew wrote:
> On Mon, 2017-07-17 at 11:27 -0400, Stewart C. Russell wrote:
> > 
> > On 2017-07-17 10:27 AM, Jochen Topf wrote:
> > > 
> > > 
> > > 
> > > There is a new layer with this data now in the OSMI:
> > > http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.7
> > > 22
> > > 07=8=same_tags_on_outer_ring
> > 
> > Thanks, Jochen! That's very helpful.
> > 
> >  
> This is very nice. Overpass was very helpful also.
> 
> Ah, just when I thought I was almost done :-(
> 
> 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

Re: [Talk-ca] Multipolygon problems

[Andrew]

On Mon, 2017-07-17 at 11:27 -0400, Stewart C. Russell wrote:
> On 2017-07-17 10:27 AM, Jochen Topf wrote:
> > 
> > 
> > There is a new layer with this data now in the OSMI:
> > http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.722
> > 07=8=same_tags_on_outer_ring
> 
> Thanks, Jochen! That's very helpful.
> 
> 
This is very nice. Overpass was very helpful also.

Ah, just when I thought I was almost done :-(

Andrew

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

Re: [Talk-ca] Multipolygon problems

[Begin Daniel]

That is helpful!
Thank Jochen

Daniel

-Original Message-
From: Jochen Topf [mailto:joc...@remote.org] 
Sent: Monday, 17 July, 2017 10:27
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

On Sat, Jul 01, 2017 at 09:52:48AM +0200, Jochen Topf wrote:
> > How difficult would it be to add this to OSM inspector? Not 
> > everybody has Postgres running, and is able to use osm2pgsql. Yes, 
> > there is documentation, but it requires some technical skills. Also, 
> > it would be very convenient to have this updated daily.
> 
> It is not that difficult to add to the OSM Inspector and if I have the 
> time I'll work on that together with the Geofabrik people.

There is a new layer with this data now in the OSMI:
http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.72207=8=same_tags_on_outer_ring

You have to zoom in to at least zoom level 8 to see something.

Jochen
--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

___
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] Multipolygon problems

[Stewart C. Russell]

On 2017-07-17 10:27 AM, Jochen Topf wrote:
> 
> There is a new layer with this data now in the OSMI:
> http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.72207=8=same_tags_on_outer_ring

Thanks, Jochen! That's very helpful.

Looks like CanvecImports cleaned up many of the thousands of giant
forestry and lake relations that were a problem the other week. Welcome
back!

 Stewart

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

Re: [Talk-ca] Multipolygon problems

[Jochen Topf]

On Sat, Jul 01, 2017 at 09:52:48AM +0200, Jochen Topf wrote:
> > How difficult would it be to add this to OSM inspector? Not everybody has
> > Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
> > but it requires some technical skills. Also, it would be very convenient to
> > have this updated daily.
> 
> It is not that difficult to add to the OSM Inspector and if I have the
> time I'll work on that together with the Geofabrik people.

There is a new layer with this data now in the OSMI:
http://tools.geofabrik.de/osmi/?view=areas=-64.28033=53.72207=8=same_tags_on_outer_ring

You have to zoom in to at least zoom level 8 to see something.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-ca] Multipolygon problems

[Begin Daniel]

Bonjour all

Concerning Canvec data and multipolygon relations,

The problem of multipolygon relations having the feature tag also associated 
with the outer ring may appear over all multipolygon relations (water, wood, 
whatever…) and on all currently available version of the Canvec product (6-10).

However, using the example provided by Stewart, I have not been able to 
reproduce the problem with the latest version of FME so the writer must have 
been corrected since. According to FME’s documentation “the multipolygon 
relation that is written out follows the rules and examples described in 
http://wiki.openstreetmap.org/wiki/Relation:multipolygon.”

Consequently, if a new version of Canvec is ever made available, I expect it 
should respect the OSM schema, at least on this aspect. In any case, one must 
conform to the general imports rules and to what has been said about Canvec 
data on this list.

Cheers,
Daniel
From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Monday, 3 July, 2017 16:00
To: Alan Richards; Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

Thanks everyone,
Stewart sent me an example I can use ☺
Daniel

From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Monday, 3 July, 2017 09:53
To: Alan Richards; Stewart C. Russell
Cc: talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] Multipolygon problems

If someone could provide me with an example of a relatively small, untouched 
multipolygon imported directly from Canvec having the problem, I could make 
some tests and sent it to FME to have their translator corrected if I can 
reproduce the problem.

Daniel

From: Alan Richards [mailto:alarob...@gmail.com]
Sent: Monday, 3 July, 2017 00:51
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] Multipolygon problems

Thanks for a good workflow - I cleared up 8 so far pretty quickly around Hope, 
BC. There's a bunch in a cluster around Merritt too. I'm guessing it's certain 
imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell 
<scr...@gmail.com<mailto:scr...@gmail.com>> wrote:
On 2017-07-02 04:41 PM, Begin Daniel wrote:
>
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
<https://www.openstreetmap.org/relation/576317> and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
>
> Daniel
>
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

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

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

Re: [Talk-ca] Multipolygon problems

[Begin Daniel]

Thanks everyone,
Stewart sent me an example I can use ☺
Daniel

From: Begin Daniel [mailto:jfd...@hotmail.com]
Sent: Monday, 3 July, 2017 09:53
To: Alan Richards; Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

If someone could provide me with an example of a relatively small, untouched 
multipolygon imported directly from Canvec having the problem, I could make 
some tests and sent it to FME to have their translator corrected if I can 
reproduce the problem.

Daniel

From: Alan Richards [mailto:alarob...@gmail.com]
Sent: Monday, 3 July, 2017 00:51
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org<mailto:talk-ca@openstreetmap.org>
Subject: Re: [Talk-ca] Multipolygon problems

Thanks for a good workflow - I cleared up 8 so far pretty quickly around Hope, 
BC. There's a bunch in a cluster around Merritt too. I'm guessing it's certain 
imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell 
<scr...@gmail.com<mailto:scr...@gmail.com>> wrote:
On 2017-07-02 04:41 PM, Begin Daniel wrote:
>
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
<https://www.openstreetmap.org/relation/576317> and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
>
> Daniel
>
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

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

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

Re: [Talk-ca] Multipolygon problems

[Begin Daniel]

If someone could provide me with an example of a relatively small, untouched 
multipolygon imported directly from Canvec having the problem, I could make 
some tests and sent it to FME to have their translator corrected if I can 
reproduce the problem.

Daniel

From: Alan Richards [mailto:alarob...@gmail.com]
Sent: Monday, 3 July, 2017 00:51
To: Stewart C. Russell
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

Thanks for a good workflow - I cleared up 8 so far pretty quickly around Hope, 
BC. There's a bunch in a cluster around Merritt too. I'm guessing it's certain 
imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell 
<scr...@gmail.com<mailto:scr...@gmail.com>> wrote:
On 2017-07-02 04:41 PM, Begin Daniel wrote:
>
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
<https://www.openstreetmap.org/relation/576317> and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
>
> Daniel
>
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

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

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

Re: [Talk-ca] Multipolygon problems

[Alan Richards]

Thanks for a good workflow - I cleared up 8 so far pretty quickly around
Hope, BC. There's a bunch in a cluster around Merritt too. I'm guessing
it's certain imports or import authors vs others that makes the difference.

alarobric

On Sun, Jul 2, 2017 at 3:40 PM, Stewart C. Russell  wrote:

> On 2017-07-02 04:41 PM, Begin Daniel wrote:
> >
> > However, since the same translator was used for all the polygons, the
> > problem should also appear on water bodies, etc. The problem may have
> > been related to the complexity of the polygons to convert.
>
> Hi Daniel - yes, I'm seeing a bunch of water relations with the same
> problem, such as on the Grand River
>  and also parts of the
> Speed near Guelph. Some of these data were imported from Canvec 10.
>
> > I also found that JOSM had similar problems with tag transfers a few
> > years ago (1). Maybe some of the problems found result from merging
> > nearby wooded areas?
> >
> > Daniel
> >
> > (1) https://josm.openstreetmap.de/ticket/9832.
>
> Interesting, but I'm seeing a lot of the problem water relations
> worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
> while the JOSM issue might have contributed a little, there were other
> factors in play. Indeed, I've even seen changesets (such as 5735148 from
> Sep 2010) where the editor had to duplicate the relation tag in the
> outer way to get the inner features to render!
>
> cheers,
>  Stewart
>
> ___
> 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] Multipolygon problems

[Stewart C. Russell]

On 2017-07-02 04:41 PM, Begin Daniel wrote:
> 
> However, since the same translator was used for all the polygons, the
> problem should also appear on water bodies, etc. The problem may have
> been related to the complexity of the polygons to convert.

Hi Daniel - yes, I'm seeing a bunch of water relations with the same
problem, such as on the Grand River
 and also parts of the
Speed near Guelph. Some of these data were imported from Canvec 10.

> I also found that JOSM had similar problems with tag transfers a few
> years ago (1). Maybe some of the problems found result from merging
> nearby wooded areas?
> 
> Daniel
> 
> (1) https://josm.openstreetmap.de/ticket/9832.

Interesting, but I'm seeing a lot of the problem water relations
worldwide (well, Scotland and Germany) where JOSM wasn't involved. So
while the JOSM issue might have contributed a little, there were other
factors in play. Indeed, I've even seen changesets (such as 5735148 from
Sep 2010) where the editor had to duplicate the relation tag in the
outer way to get the inner features to render!

cheers,
 Stewart

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

Re: [Talk-ca] Multipolygon problems

[Begin Daniel]

I have checked for the origin of the problem with old documentation about the 
Canvec2osm process. It seems the proprietary translator (FME) used to convert 
the data to OSM may have generated the problem. 

However, since the same translator was used for all the polygons, the problem 
should also appear on water bodies, etc. The problem may have been related to 
the complexity of the polygons to convert. 

I also found that JOSM had similar problems with tag transfers a few years ago 
(1). Maybe some of the problems found result from merging nearby wooded areas?

Daniel

(1) https://josm.openstreetmap.de/ticket/9832. 

-Original Message-
From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: Saturday, 1 July, 2017 17:43
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Multipolygon problems

Hi James,

> Canvec 10.0 doesnt have the issues of double tagging, just overlapping

I've found a whole bunch of Canvec 10 data with this problem west of Sudbury. I 
think it may still be an issue with later versions.

 Stewart

___
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] Multipolygon problems

[Stewart C. Russell]

On 2017-07-01 05:22 PM, Jochen Topf wrote:
> 
> There is nothing specific about woods here.

It seems, though, that the root problem in Canada is *mostly* related to
woods imported from Canvec. And we have some very large forestry
relations indeed. I was finding that the JOSM process was using 13 GB of
RAM just to load one.

> Of course you should still check all cases against sat images.

Outside cities, sat images are extremely poor in Canada. You might get
10 year old 7½-metre greyscale images. Which if you're looking at a
logging/bark beetle area could be way off current reality.

 Stewart

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

Re: [Talk-ca] Multipolygon problems

[James]

Depends where you get the data I think, canvec from ftp is different from
canvec from toporama/atlas

On Jul 1, 2017 5:44 PM, "Stewart C. Russell"  wrote:

> Hi James,
>
> > Canvec 10.0 doesnt have the issues of double tagging, just overlapping
>
> I've found a whole bunch of Canvec 10 data with this problem west of
> Sudbury. I think it may still be an issue with later versions.
>
>  Stewart
>
> ___
> 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] Multipolygon problems

[Stewart C. Russell]

Hi James,

> Canvec 10.0 doesnt have the issues of double tagging, just overlapping

I've found a whole bunch of Canvec 10 data with this problem west of
Sudbury. I think it may still be an issue with later versions.

 Stewart

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

Re: [Talk-ca] Multipolygon problems

[Jochen Topf]

On Sat, Jul 01, 2017 at 04:04:25PM -0400, Stewart C. Russell wrote:
> On 2017-07-01 04:30 AM, Frank Steggink wrote:
> > 
> > To all, this is the procedure I used yesterday, and probably something
> > similar also by Pierre.
> > * Not sure if it is a requirement, but it's better to use 64 bit Java.
> > …
> 
> Thanks for this, Frank. I think I've found a way to make this a bit
> quicker by loading a relation URL, then using your search query:
> 
> > * Eventually JOSM starts looking cluttered, because of all the extra
> > data. You can use the search query "type:way natural=wood role:outer" to
> > see if there are still rings needing work.
> 
> … then just deleting the ‘natural=wood’ from the selected ways.
> 
> I hope I'm understanding the problem correctly*: outer ways in a forest
> polygon relationship shouldn't have the ‘natural=wood’ tag? If that's
> the issue, then this should just be an auto-edit, no JOSM and
> pointy-clicky required.

There is nothing specific about woods here. An outer way in a
multipolygon relations should only have tags which apply to *that way*
specifically, not tags which apply to the whole relation. The tags on
the relation are for the polygon as a whole, the tags on the ways are
for those ways.

So if you have, say a wall surrounding a forest, you might have tags for
that wall on the ways, but the forest tags belong on the multipolygon
relation only. In most cases this simply means that there should be no
tags on the ways at all.

Of course you should still check all cases against sat images. For
instance, sometimes the whole relation can be removed and just a simple
closed way be used if there are no inner ways.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-ca] Multipolygon problems

[Stewart C. Russell]

On 2017-07-01 04:30 AM, Frank Steggink wrote:
> 
> To all, this is the procedure I used yesterday, and probably something
> similar also by Pierre.
> * Not sure if it is a requirement, but it's better to use 64 bit Java.
> …

Thanks for this, Frank. I think I've found a way to make this a bit
quicker by loading a relation URL, then using your search query:

> * Eventually JOSM starts looking cluttered, because of all the extra
> data. You can use the search query "type:way natural=wood role:outer" to
> see if there are still rings needing work.

… then just deleting the ‘natural=wood’ from the selected ways.

I hope I'm understanding the problem correctly*: outer ways in a forest
polygon relationship shouldn't have the ‘natural=wood’ tag? If that's
the issue, then this should just be an auto-edit, no JOSM and
pointy-clicky required.

cheers,
 Stewart

*: here's one of my edits, just in case I'm doing it wrong:
https://www.openstreetmap.org/changeset/49971662

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

Re: [Talk-ca] Multipolygon problems

[Pierre Béland]

Merci à vous deux. Pour ce qui est de Jochen, je l'invite à descendre au niveau 
des paqueretes et apprendre le respect, la communication plus positive ;)
La requête Overpass peut être utilisée directement dans JOSMFichier / 
Téléchargement depuis Overpass-API
 
Pierre 


  De : James <james2...@gmail.com>
 À : Frank Steggink <stegg...@steggink.org> 
Cc : Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
 Envoyé le : samedi 1 juillet 2017 8h25
 Objet : Re: [Talk-ca] Multipolygon problems
   
Error free Québec, just in time for Canada day! Good job Pierre :-)
On Jul 1, 2017 4:34 AM, "Frank Steggink" <stegg...@steggink.org> wrote:

Hi Jochen,

Maybe a MapRoulette challenge might even not be necessary. Yesterday I started 
to clean up a bit in Québec, but since it was already past midnight for me, I 
wanted to continue this morning. To my surprise Pierre has done a lot of work 
and now the entire province of Québec looks to be free from these errors. I 
just could find three errors, and fixed them. Bon travail, Pierre!

The OSM inspector will still be a good idea, in order to spot future errors.

To all, this is the procedure I used yesterday, and probably something similar 
also by Pierre.
* Not sure if it is a requirement, but it's better to use 64 bit Java.
* You'll need JOSM with the remote control plugin. You'll also need to start 
JOSM.
* Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5 K), and zoom/pan 
to the area of interest.
* Press Run and let Overpass do its work. Don't be afraid when Overpass 
mentions that the result is huge if you have a modern computer. Last night I 
wasn't experiencing any problems with 30MB data.
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks you to 
decide.
* JOSM starts downloading the data. Note that you're only getting the outer 
rings.
* Go to these rings one by one, and load data (at least you'll need the 
relationship itself).
* Remove the natural=wood tag from the outer ring.
* Eventually JOSM starts looking cluttered, because of all the extra data. You 
can use the search query "type:way natural=wood role:outer" to see if there are 
still rings needing work.
* Upload your changes. Be prepared to handle conflicts if someone else is 
working near you on this issue as well.
* After a while, check Overpass Turbo again.

I'm not sure what the update frequency is, but Pierre's changes from 4 hours 
ago were already processed.

Good luck!

Frank


On 01-07-2017 09:52, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

Ah, ok, now I understand. Since there was a lot of discussion about old
style multipolygon tagging, and since this type of problem hasn't been added
to OSM inspector,  this wasn't immediately obvious.


In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954 226a3acab882d28d8500ddef8203d/ same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/r elation/541821

How difficult would it be to add this to OSM inspector? Not everybody has
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
but it requires some technical skills. Also, it would be very convenient to
have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.




When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec dat

Re: [Talk-ca] Multipolygon problems

[James]

Error free Québec, just in time for Canada day! Good job Pierre :-)

On Jul 1, 2017 4:34 AM, "Frank Steggink"  wrote:

> Hi Jochen,
>
> Maybe a MapRoulette challenge might even not be necessary. Yesterday I
> started to clean up a bit in Québec, but since it was already past midnight
> for me, I wanted to continue this morning. To my surprise Pierre has done a
> lot of work and now the entire province of Québec looks to be free from
> these errors. I just could find three errors, and fixed them. Bon travail,
> Pierre!
>
> The OSM inspector will still be a good idea, in order to spot future
> errors.
>
> To all, this is the procedure I used yesterday, and probably something
> similar also by Pierre.
> * Not sure if it is a requirement, but it's better to use 64 bit Java.
> * You'll need JOSM with the remote control plugin. You'll also need to
> start JOSM.
> * Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5K), and
> zoom/pan to the area of interest.
> * Press Run and let Overpass do its work. Don't be afraid when Overpass
> mentions that the result is huge if you have a modern computer. Last night
> I wasn't experiencing any problems with 30MB data.
> * Press Export, and choose JOSM. Press "Repair query" when Overpass asks
> you to decide.
> * JOSM starts downloading the data. Note that you're only getting the
> outer rings.
> * Go to these rings one by one, and load data (at least you'll need the
> relationship itself).
> * Remove the natural=wood tag from the outer ring.
> * Eventually JOSM starts looking cluttered, because of all the extra data.
> You can use the search query "type:way natural=wood role:outer" to see if
> there are still rings needing work.
> * Upload your changes. Be prepared to handle conflicts if someone else is
> working near you on this issue as well.
> * After a while, check Overpass Turbo again.
>
> I'm not sure what the update frequency is, but Pierre's changes from 4
> hours ago were already processed.
>
> Good luck!
>
> Frank
>
>
> On 01-07-2017 09:52, Jochen Topf wrote:
>
>> On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:
>>
>>> On 30-06-2017 21:21, Jochen Topf wrote:
>>>
 On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

> Maybe I'm not understanding it, but in the OSM inspector [1] I just
> see one
> case of old style multipolygon, in Manitoba. Last week, when you
> posted your
> original message, I just saw one case in New Brunswick. IIRC, it was a
> park,
> not even from the Canvec import.
>
 The types of problems I am talking about don't show up in the OSM
 inspector. This is not old-style multipolygons (where tags are on the
 outer ways and not on the relation), but multipolygons where the tags
 are on the relation AND on the ways.

>>> Ah, ok, now I understand. Since there was a lot of discussion about old
>>> style multipolygon tagging, and since this type of problem hasn't been
>>> added
>>> to OSM inspector,  this wasn't immediately obvious.
>>>
 In the OSM inspector other errors can be seen, but the most prevalent
> one is
> "Touching rings". Maybe indeed a case of suboptimal mapping, but
> nothing
> which seems urgent to me.
>
> Here is an example of a forest multipolygon, imported by me
> (canvec_fsteggink). It is still version 1, but it has tags on the
> relation,
> not on the rings (except for the quarries): [2]
> This is from Canvec v7.0. IIRC, we started at v6.0, and the last
> version I
> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any
> such
> cases in the OSM inspector.
>
> So, I'd like to ask you to give a couple of examples where data
> imported
> from Canvec is clearly wrong with regard to old style multipolygon
> tagging.
>
 Here are all cases in Canada (not only those from the imports):
 https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/
 same-tags-ca.pbf

 Here is one example where you can clearly see the problem:
 http://www.openstreetmap.org/relation/541821

>>> How difficult would it be to add this to OSM inspector? Not everybody has
>>> Postgres running, and is able to use osm2pgsql. Yes, there is
>>> documentation,
>>> but it requires some technical skills. Also, it would be very convenient
>>> to
>>> have this updated daily.
>>>
>> It is not that difficult to add to the OSM Inspector and if I have the
>> time I'll work on that together with the Geofabrik people.
>>
>> When we have clear examples, then it might be easier to come up with a
> plan
> how to fix it. But so far, I see absolutely no reason why Canada
> stands out
> in a negative way. Yes, we all acknowledge that Canvec data is
> suboptimal,
> but as others already have pointed out, mapping everything by hand in
> especially remote areas is nearly impossible.
>
 Canada stands out in a 

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe a MapRoulette challenge might even not be necessary. Yesterday I 
started to clean up a bit in Québec, but since it was already past 
midnight for me, I wanted to continue this morning. To my surprise 
Pierre has done a lot of work and now the entire province of Québec 
looks to be free from these errors. I just could find three errors, and 
fixed them. Bon travail, Pierre!


The OSM inspector will still be a good idea, in order to spot future errors.

To all, this is the procedure I used yesterday, and probably something 
similar also by Pierre.

* Not sure if it is a requirement, but it's better to use 64 bit Java.
* You'll need JOSM with the remote control plugin. You'll also need to 
start JOSM.
* Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5K), and 
zoom/pan to the area of interest.
* Press Run and let Overpass do its work. Don't be afraid when Overpass 
mentions that the result is huge if you have a modern computer. Last 
night I wasn't experiencing any problems with 30MB data.
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks 
you to decide.
* JOSM starts downloading the data. Note that you're only getting the 
outer rings.
* Go to these rings one by one, and load data (at least you'll need the 
relationship itself).

* Remove the natural=wood tag from the outer ring.
* Eventually JOSM starts looking cluttered, because of all the extra 
data. You can use the search query "type:way natural=wood role:outer" to 
see if there are still rings needing work.
* Upload your changes. Be prepared to handle conflicts if someone else 
is working near you on this issue as well.

* After a while, check Overpass Turbo again.

I'm not sure what the update frequency is, but Pierre's changes from 4 
hours ago were already processed.


Good luck!

Frank


On 01-07-2017 09:52, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

Ah, ok, now I understand. Since there was a lot of discussion about old
style multipolygon tagging, and since this type of problem hasn't been added
to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821

How difficult would it be to add this to OSM inspector? Not everybody has
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
but it requires some technical skills. Also, it would be very convenient to
have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.


When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
 Canada and
b) most of these problems are probably caused by one little program, the
 program used to convert/import the CanVec data.

As you might have noticed, later imports, like the example I provided, don't
have that issue anymore. I'm mentioning this to express that not _all_
Canvec data is at fault! Only the first couple of versions. However, for
some reason this was never noticed up until a point that collaborative
action was done to have 

Re: [Talk-ca] Multipolygon problems

[Jochen Topf]

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:
> On 30-06-2017 21:21, Jochen Topf wrote:
> > On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> > > Maybe I'm not understanding it, but in the OSM inspector [1] I just see 
> > > one
> > > case of old style multipolygon, in Manitoba. Last week, when you posted 
> > > your
> > > original message, I just saw one case in New Brunswick. IIRC, it was a 
> > > park,
> > > not even from the Canvec import.
> > The types of problems I am talking about don't show up in the OSM
> > inspector. This is not old-style multipolygons (where tags are on the
> > outer ways and not on the relation), but multipolygons where the tags
> > are on the relation AND on the ways.
> Ah, ok, now I understand. Since there was a lot of discussion about old
> style multipolygon tagging, and since this type of problem hasn't been added
> to OSM inspector,  this wasn't immediately obvious.
> > > In the OSM inspector other errors can be seen, but the most prevalent one 
> > > is
> > > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
> > > which seems urgent to me.
> > > 
> > > Here is an example of a forest multipolygon, imported by me
> > > (canvec_fsteggink). It is still version 1, but it has tags on the 
> > > relation,
> > > not on the rings (except for the quarries): [2]
> > > This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
> > > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any 
> > > such
> > > cases in the OSM inspector.
> > > 
> > > So, I'd like to ask you to give a couple of examples where data imported
> > > from Canvec is clearly wrong with regard to old style multipolygon 
> > > tagging.
> > Here are all cases in Canada (not only those from the imports):
> > https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf
> > 
> > Here is one example where you can clearly see the problem:
> > http://www.openstreetmap.org/relation/541821
> How difficult would it be to add this to OSM inspector? Not everybody has
> Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
> but it requires some technical skills. Also, it would be very convenient to
> have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.

> > > When we have clear examples, then it might be easier to come up with a 
> > > plan
> > > how to fix it. But so far, I see absolutely no reason why Canada stands 
> > > out
> > > in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
> > > but as others already have pointed out, mapping everything by hand in
> > > especially remote areas is nearly impossible.
> > Canada stands out in a negative way, because
> > a) there are so many problems. Nearly a third of the cases worldwide are in
> > Canada and
> > b) most of these problems are probably caused by one little program, the
> > program used to convert/import the CanVec data.
> As you might have noticed, later imports, like the example I provided, don't
> have that issue anymore. I'm mentioning this to express that not _all_
> Canvec data is at fault! Only the first couple of versions. However, for
> some reason this was never noticed up until a point that collaborative
> action was done to have it fixed. Probably because the rendering pipeline of
> the slippy map was accepting this kind of tagging up until recently.

Okay, that is a big relief already. At least we are not making this
problem worse by new imports that might happen in the future.

> > Mapping Canada "by hand" might be difficult because it is such a huge
> > country and there aren't that many mappers. But the same arguments goes
> > for why you have to be extra careful importing data. If you break
> > something, there are not enough people to fix it manually. And, yes,
> > errors do happen. And if we find them, we fix them and move on. But
> > errors from imports can be so huge there aren't enough people there to
> > fix them manually.
> The world is so huge that there aren't enough people to create and maintain
> a global world map. However, OSM exists. Fixing errors can also be
> crowdsourced. Martijn van Exel is really doing a great job with MapRoulette,
> for instance. Although fixing errors (cleaning up the mess left behind by
> others) is not nearly as rewarding as mapping, it might be easier to do,
> especially since there is no need for a lot of creativity when fixing the
> same kind of errors.

You might have seen that I spent a lot of time in the last months to
create more than 60 Maproulette challenges for all sorts of different
multipolygon problems in different communities. And the community worked
tirelessly on all these problems. (http://area.jochentopf.com/fixed.html)

If the Canadian community steps up and is willing to do this work
manually, I'd he happy to provide such Maproulette 

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Cette requête dans JOSM peut aider à cherches des chemins avec 
natural=wood et role outer dans une relation: type:way natural=wood 
role:outer

S.v.p. utiliser avec prudence ;)

This query in JOSM can help finding ways with natural=wood and role 
outer in a relation: type:way natural=wood role:outer

Please use with caution ;)

Frank

On 30-06-2017 23:25, Pierre Béland wrote:

translation follows ...

James
la requête overpass ci-dessous extrait pour un bbox les chemins avec 
role externe dans une relation et avec la même clé natural=wood que 
sur la relation. De là, il est facile d'effacer la clé en doublon.

http://overpass-turbo.eu/s/q5K

Jochen, pour cette première extraction à l'aide de la requête 
overpass, je constate que la clé en doublon a été ajoutée à plusieurs 
reprises par un contributeur européen. Merci à lui de nous aider. Puis 
oui, il faut trouver des façons de progresser comme communauté, cela 
dans le respect de tous.


Vous n'êtes pas le premier à venir dire que la carte est mal foutue au 
Canada. Cela est très démobilisant. Sur la liste talk-ca, nous 
discutons aussi en anglais et français. Si vous ne faites pas d'effort 
pour communiquer avec les francophones, vous diminuez encore davantage 
vos chances de mobiliser la communauté OSM. Il vaut mieux motiver les 
contributeurs et tenter de comprendre la réalité de grands espaces 
plus ou moins désertiques tels le nord du Canada, l'Amazonie et 
certains territoires d'Afrique et d'Asie (moins importants ??).


Je me rappelle la réponse humanitaire du Mali en janvier 2013 où 
j'expliquais aux contributeurs des pays du nord qu'une route 
principale est toujours une route principale, même si elle est 
ensablée, en mauvaise état, non pavée. La carte, les classifications 
et les styles sont souvent pensés pour une réalité européenne. Ce 
n'est pas partout que l'on voit un réseau dense d'autoroutes. Regardez 
au zoom=5, la carte blanche au nord du Canada ou dans d'autres régions 
du monde peu denses. Essayez d'y repérer des villages, des routes (non 
pas des autoroutes), des mines, des barrages.  Bien sûr, il y en a 
moins de facilités, commerces, fast-food :)  Il y a au nord des 
villages à des centaines de kilomètres les uns des autres et sans 
route. Doit-on les ignorer?

http://www.openstreetmap.org/#map=5/56.969/-83.979

cordialement
-

James

The following overpass query extracts the ways with external role in a 
relation and  with the same key natural = wood as on the relation. 
From there it is easy to erase the duplicate key.
Http://overpass-turbo.eu/s/q5K 
<https://ssl.microsofttranslator.com/bv.aspx?from==en=Http%3A%2F%2Foverpass-turbo.eu%2Fs%2Fq5K>


Jochen,

on this first area that I extract data, I find that the duplicate key 
has been added several times by an European contributor. Thanks to him 
for helping us. And yes, we have to find ways to make progress as a 
community, with respect for all.


You are not the first to come and say that the map is screwed up in 
Canada. This is very demobilizing. On the talk-CA list, we also 
discuss in English and French. If you do not make an effort to 
communicate with the Francophones, you will further reduce your 
chances of mobilizing the OSM community. It would be good also for the 
global community to try to understand the reality of large, more or 
less deserted spaces such as northern Canada, the Amazon and some 
territories of Africa and Asia. These areas look deserted ( less 
important ??), but believe me, they are not.


I remember the Mali OSM humanitarian response in January 2013 where I 
explained to the contributors from northern countries that a major 
road is always a major road, even if it is sanded, in poor condition, 
unpaved. The map, classifications and styles are often thought for a 
European reality. It is not everywhere that we see a dense network of 
highways. Look at zoom = 5. We see almost nothing in northern Canada 
or in other areas of the world that are not very dense. Try to locate 
villages, roads (there are no motorways), mines, dams. Of course, 
there are less facilities, commerce, fast foods :) Some nordic 
villages are hundred of km apart. Should we ignore them?

http://www.openstreetmap.org/#map=5/56.969/-83.979

regard

Pierre



*De :* James <james2...@gmail.com>
*À :* Jochen Topf <joc...@remote.org>
*Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
*Envoyé le :* vendredi 30 juin 2017 16h04
*Objet :* Re: [Talk-ca] Multipolygon problems

If it's just removing tags, on inner polygons of a multipolygon, that 
should be manageable in itself... is there a way you are querying for 
said items without setting up a postgresql database?


On Jun 30, 2017 3:57 PM, "James" <james2...@gmail.com 
<mailto:james2...@gmail.com>> wrote:


To be fairyour example is from Canvec 4.0.that's
reaaa

Re: [Talk-ca] Multipolygon problems

[James]

If we have a overpass query that Pierre provided, we can create a
maproulette task...then everyone can contribute! I can read up on how to
create a task or ask Martjin

---
Si nous avons un query overpass que Pierre nous ont fournit, on pourrais
créer une tache maproulette...pour que tout le monde puisse y contribuer!
Je peux lire sur comment créer une tache maproulette ou demander a Martjin

On Jun 30, 2017 5:49 PM, "Frank Steggink"  wrote:

> On 30-06-2017 21:21, Jochen Topf wrote:
>
>> On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
>>
>>> Maybe I'm not understanding it, but in the OSM inspector [1] I just see
>>> one
>>> case of old style multipolygon, in Manitoba. Last week, when you posted
>>> your
>>> original message, I just saw one case in New Brunswick. IIRC, it was a
>>> park,
>>> not even from the Canvec import.
>>>
>> The types of problems I am talking about don't show up in the OSM
>> inspector. This is not old-style multipolygons (where tags are on the
>> outer ways and not on the relation), but multipolygons where the tags
>> are on the relation AND on the ways.
>>
> Ah, ok, now I understand. Since there was a lot of discussion about old
> style multipolygon tagging, and since this type of problem hasn't been
> added to OSM inspector,  this wasn't immediately obvious.
>
>> In the OSM inspector other errors can be seen, but the most prevalent one
>>> is
>>> "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
>>> which seems urgent to me.
>>>
>>> Here is an example of a forest multipolygon, imported by me
>>> (canvec_fsteggink). It is still version 1, but it has tags on the
>>> relation,
>>> not on the rings (except for the quarries): [2]
>>> This is from Canvec v7.0. IIRC, we started at v6.0, and the last version
>>> I
>>> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any
>>> such
>>> cases in the OSM inspector.
>>>
>>> So, I'd like to ask you to give a couple of examples where data imported
>>> from Canvec is clearly wrong with regard to old style multipolygon
>>> tagging.
>>>
>> Here are all cases in Canada (not only those from the imports):
>> https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/
>> same-tags-ca.pbf
>>
>> Here is one example where you can clearly see the problem:
>> http://www.openstreetmap.org/relation/541821
>>
> How difficult would it be to add this to OSM inspector? Not everybody has
> Postgres running, and is able to use osm2pgsql. Yes, there is
> documentation, but it requires some technical skills. Also, it would be
> very convenient to have this updated daily.
>
>> When we have clear examples, then it might be easier to come up with a
>>> plan
>>> how to fix it. But so far, I see absolutely no reason why Canada stands
>>> out
>>> in a negative way. Yes, we all acknowledge that Canvec data is
>>> suboptimal,
>>> but as others already have pointed out, mapping everything by hand in
>>> especially remote areas is nearly impossible.
>>>
>> Canada stands out in a negative way, because
>> a) there are so many problems. Nearly a third of the cases worldwide are
>> in
>> Canada and
>> b) most of these problems are probably caused by one little program, the
>> program used to convert/import the CanVec data.
>>
> As you might have noticed, later imports, like the example I provided,
> don't have that issue anymore. I'm mentioning this to express that not
> _all_ Canvec data is at fault! Only the first couple of versions. However,
> for some reason this was never noticed up until a point that collaborative
> action was done to have it fixed. Probably because the rendering pipeline
> of the slippy map was accepting this kind of tagging up until recently.
>
>> Mapping Canada "by hand" might be difficult because it is such a huge
>> country and there aren't that many mappers. But the same arguments goes
>> for why you have to be extra careful importing data. If you break
>> something, there are not enough people to fix it manually. And, yes,
>> errors do happen. And if we find them, we fix them and move on. But
>> errors from imports can be so huge there aren't enough people there to
>> fix them manually.
>>
> The world is so huge that there aren't enough people to create and
> maintain a global world map. However, OSM exists. Fixing errors can also be
> crowdsourced. Martijn van Exel is really doing a great job with
> MapRoulette, for instance. Although fixing errors (cleaning up the mess
> left behind by others) is not nearly as rewarding as mapping, it might be
> easier to do, especially since there is no need for a lot of creativity
> when fixing the same kind of errors.
>
>> So I think it is the job of those who did the import
>> in the first place, to fix their work. If you add data to OSM you take
>> on a certain responsibility. If you add more data, you have a larger
>> responsibility.
>>
> The person who did most work initially on the Canvec import has already
> left OSM 

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.
Ah, ok, now I understand. Since there was a lot of discussion about old 
style multipolygon tagging, and since this type of problem hasn't been 
added to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821
How difficult would it be to add this to OSM inspector? Not everybody 
has Postgres running, and is able to use osm2pgsql. Yes, there is 
documentation, but it requires some technical skills. Also, it would be 
very convenient to have this updated daily.

When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
Canada and
b) most of these problems are probably caused by one little program, the
program used to convert/import the CanVec data.
As you might have noticed, later imports, like the example I provided, 
don't have that issue anymore. I'm mentioning this to express that not 
_all_ Canvec data is at fault! Only the first couple of versions. 
However, for some reason this was never noticed up until a point that 
collaborative action was done to have it fixed. Probably because the 
rendering pipeline of the slippy map was accepting this kind of tagging 
up until recently.

Mapping Canada "by hand" might be difficult because it is such a huge
country and there aren't that many mappers. But the same arguments goes
for why you have to be extra careful importing data. If you break
something, there are not enough people to fix it manually. And, yes,
errors do happen. And if we find them, we fix them and move on. But
errors from imports can be so huge there aren't enough people there to
fix them manually.
The world is so huge that there aren't enough people to create and 
maintain a global world map. However, OSM exists. Fixing errors can also 
be crowdsourced. Martijn van Exel is really doing a great job with 
MapRoulette, for instance. Although fixing errors (cleaning up the mess 
left behind by others) is not nearly as rewarding as mapping, it might 
be easier to do, especially since there is no need for a lot of 
creativity when fixing the same kind of errors.

So I think it is the job of those who did the import
in the first place, to fix their work. If you add data to OSM you take
on a certain responsibility. If you add more data, you have a larger
responsibility.
The person who did most work initially on the Canvec import has already 
left OSM about five years ago. This was during the license change. He 
joined one of the forks, from which we hear nothing nowadays. So, don't 
count on him, and possibly not on others who were working on the Canvec 
import at that time. I'm sure he and others who were involved at that 
time regret certain decisions being made and actions being done.


However, the import was supported by the majority of the community at 
that time, and although there are people who have criticized the import 
(and also of the Geobase roads) they still exist in OSM and are 
gradually being improved by others.

But saying: We don't have the manpower, so we are taking
a shortcut and then, when it turns out the shortcut wasn't so short
after all, whining that 

Re: [Talk-ca] Multipolygon problems

[Pierre Béland]

translation follows ...
Jamesla requête overpass ci-dessous extrait pour un bbox les chemins avec role 
externe dans une relation et avec la même clé natural=wood que sur la relation. 
De là, il est facile d'effacer la clé en doublon.http://overpass-turbo.eu/s/q5K

Jochen, pour cette première extraction à l'aide de la requête overpass, je 
constate que la clé en doublon a été ajoutée à plusieurs reprises par un 
contributeur européen. Merci à lui de nous aider. Puis oui, il faut trouver des 
façons de progresser comme communauté, cela dans le respect de tous.

Vous n'êtes pas le premier à venir dire que la carte est mal foutue au Canada. 
Cela est très démobilisant. Sur la liste talk-ca, nous discutons aussi en 
anglais et français. Si vous ne faites pas d'effort pour communiquer avec les 
francophones, vous diminuez encore davantage vos chances de mobiliser la 
communauté OSM. Il vaut mieux motiver les contributeurs et tenter de comprendre 
la réalité de grands espaces plus ou moins désertiques tels le nord du Canada, 
l'Amazonie et certains territoires d'Afrique et d'Asie (moins importants ??).  

Je me rappelle la réponse humanitaire du Mali en janvier 2013 où j'expliquais 
aux contributeurs des pays du nord qu'une route principale est toujours une 
route principale, même si elle est ensablée, en mauvaise état, non pavée. La 
carte, les classifications et les styles sont souvent pensés pour une réalité 
européenne. Ce n'est pas partout que l'on voit un réseau dense d'autoroutes. 
Regardez au zoom=5, la carte blanche au nord du Canada ou dans d'autres régions 
du monde peu denses. Essayez d'y repérer des villages, des routes (non pas des 
autoroutes), des mines, des barrages.  Bien sûr, il y en a moins de facilités, 
commerces, fast-food :)  Il y a au nord des villages à des centaines de 
kilomètres les uns des autres et sans route. Doit-on les 
ignorer?http://www.openstreetmap.org/#map=5/56.969/-83.979

cordialement
-
James
The following overpass query extracts the ways with external role in a relation 
and  with the same key natural = wood as on the relation. From there it is easy 
to erase the duplicate key.Http://overpass-turbo.eu/s/q5K
Jochen, 

on this first area that I extract data, I find that the duplicate key has been 
added several times by an European contributor. Thanks to him for helping us. 
And yes, we have to find ways to make progress as a community, with respect for 
all.
You are not the first to come and say that the map is screwed up in Canada. 
This is very demobilizing. On the talk-CA list, we also discuss in English and 
French. If you do not make an effort to communicate with the Francophones, you 
will further reduce your chances of mobilizing the OSM community. It would be 
good also for the global community to try to understand the reality of large, 
more or less deserted spaces such as northern Canada, the Amazon and some 
territories of Africa and Asia. These areas look deserted ( less important ??), 
but believe me, they are not.

I remember the Mali OSM humanitarian response in January 2013 where I explained 
to the contributors from northern countries that a major road is always a major 
road, even if it is sanded, in poor condition, unpaved. The map, 
classifications and styles are often thought for a European reality. It is not 
everywhere that we see a dense network of highways. Look at zoom = 5. We see 
almost nothing in northern Canada or in other areas of the world that are not 
very dense. Try to locate villages, roads (there are no motorways), mines, 
dams. Of course, there are less facilities, commerce, fast foods :) Some nordic 
villages are hundred of km apart. Should we ignore them?
http://www.openstreetmap.org/#map=5/56.969/-83.979

regard  
Pierre 


  De : James <james2...@gmail.com>
 À : Jochen Topf <joc...@remote.org> 
Cc : Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
 Envoyé le : vendredi 30 juin 2017 16h04
 Objet : Re: [Talk-ca] Multipolygon problems
   
If it's just removing tags, on inner polygons of a multipolygon, that should be 
manageable in itself... is there a way you are querying for said items without 
setting up a postgresql database?
On Jun 30, 2017 3:57 PM, "James" <james2...@gmail.com> wrote:

To be fairyour example is from Canvec 4.0.that's reaaallly 
oldwas it possible that was a way of tagging back in the days? Or was it 
created initially as a polygon and was later converted to a relation?
Canvec 10.0 doesnt have the issues of double tagging, just overlapping
On Jun 30, 2017 3:22 PM, "Jochen Topf" <joc...@remote.org> wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
> case of old style multipolygon, in Manitoba. Last week, when you posted your
> original message, I just saw one case in New Brunswick. IIRC, it was a park,
>

Re: [Talk-ca] Multipolygon problems

[James]

If it's just removing tags, on inner polygons of a multipolygon, that
should be manageable in itself... is there a way you are querying for said
items without setting up a postgresql database?

On Jun 30, 2017 3:57 PM, "James"  wrote:

> To be fairyour example is from Canvec 4.0.that's reaaallly
> oldwas it possible that was a way of tagging back in the days? Or was
> it created initially as a polygon and was later converted to a relation?
>
> Canvec 10.0 doesnt have the issues of double tagging, just overlapping
>
> On Jun 30, 2017 3:22 PM, "Jochen Topf"  wrote:
>
>> On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
>> > Maybe I'm not understanding it, but in the OSM inspector [1] I just see
>> one
>> > case of old style multipolygon, in Manitoba. Last week, when you posted
>> your
>> > original message, I just saw one case in New Brunswick. IIRC, it was a
>> park,
>> > not even from the Canvec import.
>>
>> The types of problems I am talking about don't show up in the OSM
>> inspector. This is not old-style multipolygons (where tags are on the
>> outer ways and not on the relation), but multipolygons where the tags
>> are on the relation AND on the ways.
>>
>> > In the OSM inspector other errors can be seen, but the most prevalent
>> one is
>> > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
>> > which seems urgent to me.
>> >
>> > Here is an example of a forest multipolygon, imported by me
>> > (canvec_fsteggink). It is still version 1, but it has tags on the
>> relation,
>> > not on the rings (except for the quarries): [2]
>> > This is from Canvec v7.0. IIRC, we started at v6.0, and the last
>> version I
>> > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any
>> such
>> > cases in the OSM inspector.
>> >
>> > So, I'd like to ask you to give a couple of examples where data imported
>> > from Canvec is clearly wrong with regard to old style multipolygon
>> tagging.
>>
>> Here are all cases in Canada (not only those from the imports):
>> https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/
>> same-tags-ca.pbf
>>
>> Here is one example where you can clearly see the problem:
>> http://www.openstreetmap.org/relation/541821
>>
>> > When we have clear examples, then it might be easier to come up with a
>> plan
>> > how to fix it. But so far, I see absolutely no reason why Canada stands
>> out
>> > in a negative way. Yes, we all acknowledge that Canvec data is
>> suboptimal,
>> > but as others already have pointed out, mapping everything by hand in
>> > especially remote areas is nearly impossible.
>>
>> Canada stands out in a negative way, because
>> a) there are so many problems. Nearly a third of the cases worldwide are
>> in
>>Canada and
>> b) most of these problems are probably caused by one little program, the
>>program used to convert/import the CanVec data.
>>
>> Mapping Canada "by hand" might be difficult because it is such a huge
>> country and there aren't that many mappers. But the same arguments goes
>> for why you have to be extra careful importing data. If you break
>> something, there are not enough people to fix it manually. And, yes,
>> errors do happen. And if we find them, we fix them and move on. But
>> errors from imports can be so huge there aren't enough people there to
>> fix them manually. So I think it is the job of those who did the import
>> in the first place, to fix their work. If you add data to OSM you take
>> on a certain responsibility. If you add more data, you have a larger
>> responsibility. But saying: We don't have the manpower, so we are taking
>> a shortcut and then, when it turns out the shortcut wasn't so short
>> after all, whining that you don't have the manpower to fix it. That
>> can't be the excuse.
>>
>> Jochen
>> --
>> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
>> +49-351-31778688
>>
>> ___
>> 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] Multipolygon problems

[James]

To be fairyour example is from Canvec 4.0.that's reaaallly
oldwas it possible that was a way of tagging back in the days? Or was
it created initially as a polygon and was later converted to a relation?

Canvec 10.0 doesnt have the issues of double tagging, just overlapping

On Jun 30, 2017 3:22 PM, "Jochen Topf"  wrote:

> On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> > Maybe I'm not understanding it, but in the OSM inspector [1] I just see
> one
> > case of old style multipolygon, in Manitoba. Last week, when you posted
> your
> > original message, I just saw one case in New Brunswick. IIRC, it was a
> park,
> > not even from the Canvec import.
>
> The types of problems I am talking about don't show up in the OSM
> inspector. This is not old-style multipolygons (where tags are on the
> outer ways and not on the relation), but multipolygons where the tags
> are on the relation AND on the ways.
>
> > In the OSM inspector other errors can be seen, but the most prevalent
> one is
> > "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
> > which seems urgent to me.
> >
> > Here is an example of a forest multipolygon, imported by me
> > (canvec_fsteggink). It is still version 1, but it has tags on the
> relation,
> > not on the rings (except for the quarries): [2]
> > This is from Canvec v7.0. IIRC, we started at v6.0, and the last version
> I
> > know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any
> such
> > cases in the OSM inspector.
> >
> > So, I'd like to ask you to give a couple of examples where data imported
> > from Canvec is clearly wrong with regard to old style multipolygon
> tagging.
>
> Here are all cases in Canada (not only those from the imports):
> https://tmp.jochentopf.com/954226a3acab882d28d8500ddef820
> 3d/same-tags-ca.pbf
>
> Here is one example where you can clearly see the problem:
> http://www.openstreetmap.org/relation/541821
>
> > When we have clear examples, then it might be easier to come up with a
> plan
> > how to fix it. But so far, I see absolutely no reason why Canada stands
> out
> > in a negative way. Yes, we all acknowledge that Canvec data is
> suboptimal,
> > but as others already have pointed out, mapping everything by hand in
> > especially remote areas is nearly impossible.
>
> Canada stands out in a negative way, because
> a) there are so many problems. Nearly a third of the cases worldwide are in
>Canada and
> b) most of these problems are probably caused by one little program, the
>program used to convert/import the CanVec data.
>
> Mapping Canada "by hand" might be difficult because it is such a huge
> country and there aren't that many mappers. But the same arguments goes
> for why you have to be extra careful importing data. If you break
> something, there are not enough people to fix it manually. And, yes,
> errors do happen. And if we find them, we fix them and move on. But
> errors from imports can be so huge there aren't enough people there to
> fix them manually. So I think it is the job of those who did the import
> in the first place, to fix their work. If you add data to OSM you take
> on a certain responsibility. If you add more data, you have a larger
> responsibility. But saying: We don't have the manpower, so we are taking
> a shortcut and then, when it turns out the shortcut wasn't so short
> after all, whining that you don't have the manpower to fix it. That
> can't be the excuse.
>
> Jochen
> --
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
> +49-351-31778688
>
> ___
> 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] Multipolygon problems

[Jochen Topf]

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
> case of old style multipolygon, in Manitoba. Last week, when you posted your
> original message, I just saw one case in New Brunswick. IIRC, it was a park,
> not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

> In the OSM inspector other errors can be seen, but the most prevalent one is
> "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
> which seems urgent to me.
> 
> Here is an example of a forest multipolygon, imported by me
> (canvec_fsteggink). It is still version 1, but it has tags on the relation,
> not on the rings (except for the quarries): [2]
> This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
> cases in the OSM inspector.
> 
> So, I'd like to ask you to give a couple of examples where data imported
> from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821

> When we have clear examples, then it might be easier to come up with a plan
> how to fix it. But so far, I see absolutely no reason why Canada stands out
> in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
> but as others already have pointed out, mapping everything by hand in
> especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
   Canada and
b) most of these problems are probably caused by one little program, the
   program used to convert/import the CanVec data.

Mapping Canada "by hand" might be difficult because it is such a huge
country and there aren't that many mappers. But the same arguments goes
for why you have to be extra careful importing data. If you break
something, there are not enough people to fix it manually. And, yes,
errors do happen. And if we find them, we fix them and move on. But
errors from imports can be so huge there aren't enough people there to
fix them manually. So I think it is the job of those who did the import
in the first place, to fix their work. If you add data to OSM you take
on a certain responsibility. If you add more data, you have a larger
responsibility. But saying: We don't have the manpower, so we are taking
a shortcut and then, when it turns out the shortcut wasn't so short
after all, whining that you don't have the manpower to fix it. That
can't be the excuse.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [Talk-ca] Multipolygon problems

[john whelan]

>>Especially when the only imagery available is Landsat

I remember the days when it was trudge out in the rain with the Garmin then
upload the GPS traces only to find a straight road was no longer straight
because of the wet leaves in the trees above.

Cheerio John

On 30 June 2017 at 15:03, James  wrote:

> Especially when the only imagery available is Landsat
>
> On Jun 30, 2017 2:18 PM, "Frank Steggink"  wrote:
>
>> Hi Jochen,
>>
>> Maybe I'm not understanding it, but in the OSM inspector [1] I just see
>> one case of old style multipolygon, in Manitoba. Last week, when you posted
>> your original message, I just saw one case in New Brunswick. IIRC, it was a
>> park, not even from the Canvec import.
>>
>> In the OSM inspector other errors can be seen, but the most prevalent one
>> is "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
>> which seems urgent to me.
>>
>> Here is an example of a forest multipolygon, imported by me
>> (canvec_fsteggink). It is still version 1, but it has tags on the relation,
>> not on the rings (except for the quarries): [2]
>> This is from Canvec v7.0. IIRC, we started at v6.0, and the last version
>> I know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any
>> such cases in the OSM inspector.
>>
>> So, I'd like to ask you to give a couple of examples where data imported
>> from Canvec is clearly wrong with regard to old style multipolygon tagging.
>> When we have clear examples, then it might be easier to come up with a plan
>> how to fix it. But so far, I see absolutely no reason why Canada stands out
>> in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
>> but as others already have pointed out, mapping everything by hand in
>> especially remote areas is nearly impossible.
>>
>> Regards,
>>
>> Frank
>>
>> [1] http://tools.geofabrik.de/osmi/?view=areas
>> [2] https://www.openstreetmap.org/relation/1481163/history
>>
>> On 30-06-2017 09:52, Jochen Topf wrote:
>>
>>> Hi!
>>>
>>> A week ago I wrote this email and nobody answered it yet. Does that
>>> mean that nobody feels responsible for the import that created this data
>>> and nobody here cares for this data?
>>>
>>> I see three ways forward:
>>> * We do nothing. The broken data stays in OSM. Not a good solution,
>>>because every user of the data has to work around this or handle the
>>>complaints.
>>> * The Canadian community steps up and fixes the data, automatically or
>>>manually.
>>> * We ask the Data Working Group to remove the broken import.
>>>
>>> Jochen
>>>
>>> On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
>>>
 Date: Thu, 22 Jun 2017 11:38:15 +0200
 From: Jochen Topf 
 To: talk-ca@openstreetmap.org
 Subject: [Talk-ca] Multipolygon problems

 Hi!

 In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
 the OSMF tile servers. This new version of the style doesn't take
 old-style multipolygons (where the tags are on the outer ways instead of
 on the relation) into account any more. In a huge effort in the last
 months we have converted all old-style multipolygons to the modern
 tagging, so this is a good step!

 Unfortunately, as a side-effect of this change, many multipolygon
 relations now appear wrong on the map. This is the case for multipolygon
 relations that have the same tags on the relation as well as on (some of
 the) outer or inner ways. This is *wrong* tagging, and needs to be
 fixed. (Note that this always was wrong tagging, even before we
 deprecated old-style multipolygons, but the way the software worked with
 old-style multipolygons, this problem was not visible on the map. But
 now it is.)

 Here is an example: http://www.openstreetmap.org/relation/1330741 . As
 you can see (unless somebody fixes this :-) the clearing in the forest
 that should just have grass, also has tree symbols on it. In many other
 cases it is not this obvious, there are just islands in a river missing
 or so.

 There are about 50,000 cases like this worldwide, forests, waterways,
 all sorts of areas. But the worst problem is in Canada. There are about
 15,000 affected relations, most from the CanVec imports.

 First, we have to make sure that there are no further imports of broken
 data. I hope the people who have done those imports (and might still
 continue) are here on this mailing list. If not please make them aware
 of this issue and/or put me in touch with them. Second, somebody needs
 to clean up the broken data, either automatically or manually. 99% of
 the data has not been changed since the import, so it might be feasible
 to do an automatic cleanup, but somebody has to do this. Otherwise we'll
 have to do a manual cleanup, through tools such as Maproulette and the
 OSM 

Re: [Talk-ca] Multipolygon problems

[James]

Especially when the only imagery available is Landsat

On Jun 30, 2017 2:18 PM, "Frank Steggink"  wrote:

> Hi Jochen,
>
> Maybe I'm not understanding it, but in the OSM inspector [1] I just see
> one case of old style multipolygon, in Manitoba. Last week, when you posted
> your original message, I just saw one case in New Brunswick. IIRC, it was a
> park, not even from the Canvec import.
>
> In the OSM inspector other errors can be seen, but the most prevalent one
> is "Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
> which seems urgent to me.
>
> Here is an example of a forest multipolygon, imported by me
> (canvec_fsteggink). It is still version 1, but it has tags on the relation,
> not on the rings (except for the quarries): [2]
> This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
> cases in the OSM inspector.
>
> So, I'd like to ask you to give a couple of examples where data imported
> from Canvec is clearly wrong with regard to old style multipolygon tagging.
> When we have clear examples, then it might be easier to come up with a plan
> how to fix it. But so far, I see absolutely no reason why Canada stands out
> in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
> but as others already have pointed out, mapping everything by hand in
> especially remote areas is nearly impossible.
>
> Regards,
>
> Frank
>
> [1] http://tools.geofabrik.de/osmi/?view=areas
> [2] https://www.openstreetmap.org/relation/1481163/history
>
> On 30-06-2017 09:52, Jochen Topf wrote:
>
>> Hi!
>>
>> A week ago I wrote this email and nobody answered it yet. Does that
>> mean that nobody feels responsible for the import that created this data
>> and nobody here cares for this data?
>>
>> I see three ways forward:
>> * We do nothing. The broken data stays in OSM. Not a good solution,
>>because every user of the data has to work around this or handle the
>>complaints.
>> * The Canadian community steps up and fixes the data, automatically or
>>manually.
>> * We ask the Data Working Group to remove the broken import.
>>
>> Jochen
>>
>> On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
>>
>>> Date: Thu, 22 Jun 2017 11:38:15 +0200
>>> From: Jochen Topf 
>>> To: talk-ca@openstreetmap.org
>>> Subject: [Talk-ca] Multipolygon problems
>>>
>>> Hi!
>>>
>>> In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
>>> the OSMF tile servers. This new version of the style doesn't take
>>> old-style multipolygons (where the tags are on the outer ways instead of
>>> on the relation) into account any more. In a huge effort in the last
>>> months we have converted all old-style multipolygons to the modern
>>> tagging, so this is a good step!
>>>
>>> Unfortunately, as a side-effect of this change, many multipolygon
>>> relations now appear wrong on the map. This is the case for multipolygon
>>> relations that have the same tags on the relation as well as on (some of
>>> the) outer or inner ways. This is *wrong* tagging, and needs to be
>>> fixed. (Note that this always was wrong tagging, even before we
>>> deprecated old-style multipolygons, but the way the software worked with
>>> old-style multipolygons, this problem was not visible on the map. But
>>> now it is.)
>>>
>>> Here is an example: http://www.openstreetmap.org/relation/1330741 . As
>>> you can see (unless somebody fixes this :-) the clearing in the forest
>>> that should just have grass, also has tree symbols on it. In many other
>>> cases it is not this obvious, there are just islands in a river missing
>>> or so.
>>>
>>> There are about 50,000 cases like this worldwide, forests, waterways,
>>> all sorts of areas. But the worst problem is in Canada. There are about
>>> 15,000 affected relations, most from the CanVec imports.
>>>
>>> First, we have to make sure that there are no further imports of broken
>>> data. I hope the people who have done those imports (and might still
>>> continue) are here on this mailing list. If not please make them aware
>>> of this issue and/or put me in touch with them. Second, somebody needs
>>> to clean up the broken data, either automatically or manually. 99% of
>>> the data has not been changed since the import, so it might be feasible
>>> to do an automatic cleanup, but somebody has to do this. Otherwise we'll
>>> have to do a manual cleanup, through tools such as Maproulette and the
>>> OSM Inspector. I am currently in the process of creating Maproulette
>>> challenges for other areas of the planet, but will not do this for
>>> Canada at this time. Lets discuss this here first.
>>>
>>> I can provide OSM data extracts, statistics, etc. if somebody wants to
>>> look at the data.
>>>
>>> All of this is part of a larger effort to fix areas in OSM. See
>>> http://area.jochentopf.com/ for more information. There is also a 

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe I'm not understanding it, but in the OSM inspector [1] I just see 
one case of old style multipolygon, in Manitoba. Last week, when you 
posted your original message, I just saw one case in New Brunswick. 
IIRC, it was a park, not even from the Canvec import.


In the OSM inspector other errors can be seen, but the most prevalent 
one is "Touching rings". Maybe indeed a case of suboptimal mapping, but 
nothing which seems urgent to me.


Here is an example of a forest multipolygon, imported by me 
(canvec_fsteggink). It is still version 1, but it has tags on the 
relation, not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version 
I know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any 
such cases in the OSM inspector.


So, I'd like to ask you to give a couple of examples where data imported 
from Canvec is clearly wrong with regard to old style multipolygon 
tagging. When we have clear examples, then it might be easier to come up 
with a plan how to fix it. But so far, I see absolutely no reason why 
Canada stands out in a negative way. Yes, we all acknowledge that Canvec 
data is suboptimal, but as others already have pointed out, mapping 
everything by hand in especially remote areas is nearly impossible.


Regards,

Frank

[1] http://tools.geofabrik.de/osmi/?view=areas
[2] https://www.openstreetmap.org/relation/1481163/history

On 30-06-2017 09:52, Jochen Topf wrote:

Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
   because every user of the data has to work around this or handle the
   complaints.
* The Canadian community steps up and fixes the data, automatically or
   manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:

Date: Thu, 22 Jun 2017 11:38:15 +0200
From: Jochen Topf 
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Multipolygon problems

Hi!

In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
the OSMF tile servers. This new version of the style doesn't take
old-style multipolygons (where the tags are on the outer ways instead of
on the relation) into account any more. In a huge effort in the last
months we have converted all old-style multipolygons to the modern
tagging, so this is a good step!

Unfortunately, as a side-effect of this change, many multipolygon
relations now appear wrong on the map. This is the case for multipolygon
relations that have the same tags on the relation as well as on (some of
the) outer or inner ways. This is *wrong* tagging, and needs to be
fixed. (Note that this always was wrong tagging, even before we
deprecated old-style multipolygons, but the way the software worked with
old-style multipolygons, this problem was not visible on the map. But
now it is.)

Here is an example: http://www.openstreetmap.org/relation/1330741 . As
you can see (unless somebody fixes this :-) the clearing in the forest
that should just have grass, also has tree symbols on it. In many other
cases it is not this obvious, there are just islands in a river missing
or so.

There are about 50,000 cases like this worldwide, forests, waterways,
all sorts of areas. But the worst problem is in Canada. There are about
15,000 affected relations, most from the CanVec imports.

First, we have to make sure that there are no further imports of broken
data. I hope the people who have done those imports (and might still
continue) are here on this mailing list. If not please make them aware
of this issue and/or put me in touch with them. Second, somebody needs
to clean up the broken data, either automatically or manually. 99% of
the data has not been changed since the import, so it might be feasible
to do an automatic cleanup, but somebody has to do this. Otherwise we'll
have to do a manual cleanup, through tools such as Maproulette and the
OSM Inspector. I am currently in the process of creating Maproulette
challenges for other areas of the planet, but will not do this for
Canada at this time. Lets discuss this here first.

I can provide OSM data extracts, statistics, etc. if somebody wants to
look at the data.

All of this is part of a larger effort to fix areas in OSM. See
http://area.jochentopf.com/ for more information. There is also a thread
on the talk mailinglist at
https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
and this issue
https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
News of the effort are posted regularly to
https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .

Jochen
--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

Re: [Talk-ca] Multipolygon problems

[Andrew]

User canvec_imports here :-) 

     What would you like me to say? Someone took the approach of
introducing my head to a  2x4 a few years back. Pretty much stopped me
dead in my tracks. 

1: - I saw the original 
On Fri, 2017-06-30 at 10:40 -0400, Stewart Russell wrote:
> Hi Jochen,
> > I was waiting for user canvec_imports to say something, but there's
been no activity from the account for more than two years. 
> 
> > > > The import was started a long time ago, before there were import
guidelines and very likely before the licence change too. It was done
with the best available data at the time, and done with good intent.
It was a major coup to get government data at the time. 
> 
> > > > > > Since we have the most of these offending polygons in Canada, and
since we're the second largest country in the world, a more bombastic
version of me might be tempted to say, "No, *you're* doing it wrong
...". But that's not particularly Canadian, and even less
constructive. We simply don't have the community available to fix
this. 
> 
> > > > > One thing that we must do is ensure that the sources of Canvec import
data are either fixed or removed from the web. The infrastructure and
documentation for continuing this import and thus propagating these
alleged errors is still out there. Unless it is removed, we could
potentially have a mapper restart the import again.
> 
>  Stewart
> 
> 
> > On Jun 30, 2017 3:54 AM, "Jochen Topf"  wrote:
> Hi!
> 
> 
> 
> A week ago I wrote this email and nobody answered it yet. Does that
> 
> > mean that nobody feels responsible for the import that created this
data
> 
> and nobody here cares for this data?
> 
> 
> 
> I see three ways forward:
> 
> * We do nothing. The broken data stays in OSM. Not a good solution,
> 
> >   because every user of the data has to work around this or handle
the
> 
>   complaints.
> 
> > * The Canadian community steps up and fixes the data, automatically
or
> 
>   manually.
> 
> * We ask the Data Working Group to remove the broken import.
> 
> 
> 
> Jochen
> 
> 
> 
> On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> 
> > Date: Thu, 22 Jun 2017 11:38:15 +0200
> 
> > > From: Jochen Topf 
> 
> > To: talk-ca@openstreetmap.org
> 
> > Subject: [Talk-ca] Multipolygon problems
> 
> >
> 
> > Hi!
> 
> >
> 
> > > In the last days the OpenStreetMap Carto Style 4.0 is being
deployed on
> 
> > the OSMF tile servers. This new version of the style doesn't take
> 
> > > old-style multipolygons (where the tags are on the outer ways
instead of
> 
> > > on the relation) into account any more. In a huge effort in the
last
> 
> > months we have converted all old-style multipolygons to the modern
> 
> > tagging, so this is a good step!
> 
> >
> 
> > Unfortunately, as a side-effect of this change, many multipolygon
> 
> > > relations now appear wrong on the map. This is the case for
multipolygon
> 
> > > relations that have the same tags on the relation as well as on
(some of
> 
> > the) outer or inner ways. This is *wrong* tagging, and needs to be
> 
> > fixed. (Note that this always was wrong tagging, even before we
> 
> > > deprecated old-style multipolygons, but the way the software worked
with
> 
> > > old-style multipolygons, this problem was not visible on the map.
But
> 
> > now it is.)
> 
> >
> 
> > > > Here is an example: http://www.openstreetmap.org/relation/1330741 .
As
> 
> > > you can see (unless somebody fixes this :-) the clearing in the
forest
> 
> > > that should just have grass, also has tree symbols on it. In many
other
> 
> > > cases it is not this obvious, there are just islands in a river
missing
> 
> > or so.
> 
> >
> 
> > > There are about 50,000 cases like this worldwide, forests,
waterways,
> 
> > > all sorts of areas. But the worst problem is in Canada. There are
about
> 
> > 15,000 affected relations, most from the CanVec imports.
> 
> >
> 
> > > First, we have to make sure that there are no further imports of
broken
> 
> > > data. I hope the people who have done those imports (and might
still
> 
> > > continue) are here on this mailing list. If not please make them
aware
> 
> > > of this issue and/or put me in touch with them. Second, somebody
needs
> 
> > > to clean up the broken data, either automatically or manually. 99%
of
> 
> > > the data has not been changed since the import, so it might be
feasible
> 
> > > to do an automatic cleanup, but somebody has to do this. Otherwise
we'll
> 
> > > have to do a manual cleanup, through tools such as Maproulette and
the
> 
> > > OSM Inspector. I am currently in the process of creating
Maproulette
> 
> > challenges for other areas of the planet, but will not do this for
> 
> > Canada at this time. Lets discuss this here first.
> 
> >
> 
> > > I can provide OSM data extracts, statistics, etc. if somebody wants
to
> 
> > look at the data.
> 
> >
> 
> > All of this is part of a larger effort to fix areas in OSM. See
> 
> > > > 

Re: [Talk-ca] Multipolygon problems

[James]

As john has said, we only have a couple hundred mappers for 9.985 million
square kilometers...or 27.93 germanies or 41.17 United kindoms or 15.5
Frances. Europe has hundreds of thousands of mappers, Canada does not. If
you wish to help out you are more than welcome as a NTS Grid tile section
usually takes about 2-3 hours to correct everything(knowing what you are
doing of course). It involves mind numbing clicking of buttons to keep all
relations when merging( I really wish there was an option to automatically
keep everything when merging instead of asking me for each of the 800+
polygons which would cut down the job to maybe 10-15 minutes)

On Jun 30, 2017 9:46 AM, "john whelan"  wrote:

Doing nothing for the moment looks extremely good to me.

Compared to many other areas of the world such as Germany and the UK we
have many fewer mappers per square kilometer.  As James has stated this
sort of clean up requires fairly specialised resources that realistically
we don't have in sufficient quantity to meet your priorities and I think
the Canadian mappers have indicated this is not a high priority for them
and they are happy with the status quo.

The more important areas to the map as far as end users go are being
cleaned up but probably not as fast as you would like to see.

If you are willing to make the corrections then I feel sure that the
Canadian community would be happy to see them made.

Cheerio John

On 30 June 2017 at 03:52, Jochen Topf  wrote:

> Hi!
>
> A week ago I wrote this email and nobody answered it yet. Does that
> mean that nobody feels responsible for the import that created this data
> and nobody here cares for this data?
>
> I see three ways forward:
> * We do nothing. The broken data stays in OSM. Not a good solution,
>   because every user of the data has to work around this or handle the
>   complaints.
> * The Canadian community steps up and fixes the data, automatically or
>   manually.
> * We ask the Data Working Group to remove the broken import.
>
> Jochen
>
> On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> > Date: Thu, 22 Jun 2017 11:38:15 +0200
> > From: Jochen Topf 
> > To: talk-ca@openstreetmap.org
> > Subject: [Talk-ca] Multipolygon problems
> >
> > Hi!
> >
> > In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> > the OSMF tile servers. This new version of the style doesn't take
> > old-style multipolygons (where the tags are on the outer ways instead of
> > on the relation) into account any more. In a huge effort in the last
> > months we have converted all old-style multipolygons to the modern
> > tagging, so this is a good step!
> >
> > Unfortunately, as a side-effect of this change, many multipolygon
> > relations now appear wrong on the map. This is the case for multipolygon
> > relations that have the same tags on the relation as well as on (some of
> > the) outer or inner ways. This is *wrong* tagging, and needs to be
> > fixed. (Note that this always was wrong tagging, even before we
> > deprecated old-style multipolygons, but the way the software worked with
> > old-style multipolygons, this problem was not visible on the map. But
> > now it is.)
> >
> > Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> > you can see (unless somebody fixes this :-) the clearing in the forest
> > that should just have grass, also has tree symbols on it. In many other
> > cases it is not this obvious, there are just islands in a river missing
> > or so.
> >
> > There are about 50,000 cases like this worldwide, forests, waterways,
> > all sorts of areas. But the worst problem is in Canada. There are about
> > 15,000 affected relations, most from the CanVec imports.
> >
> > First, we have to make sure that there are no further imports of broken
> > data. I hope the people who have done those imports (and might still
> > continue) are here on this mailing list. If not please make them aware
> > of this issue and/or put me in touch with them. Second, somebody needs
> > to clean up the broken data, either automatically or manually. 99% of
> > the data has not been changed since the import, so it might be feasible
> > to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> > have to do a manual cleanup, through tools such as Maproulette and the
> > OSM Inspector. I am currently in the process of creating Maproulette
> > challenges for other areas of the planet, but will not do this for
> > Canada at this time. Lets discuss this here first.
> >
> > I can provide OSM data extracts, statistics, etc. if somebody wants to
> > look at the data.
> >
> > All of this is part of a larger effort to fix areas in OSM. See
> > http://area.jochentopf.com/ for more information. There is also a thread
> > on the talk mailinglist at
> > https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
> > and this issue
> > 

Re: [Talk-ca] Multipolygon problems

[john whelan]

Doing nothing for the moment looks extremely good to me.

Compared to many other areas of the world such as Germany and the UK we
have many fewer mappers per square kilometer.  As James has stated this
sort of clean up requires fairly specialised resources that realistically
we don't have in sufficient quantity to meet your priorities and I think
the Canadian mappers have indicated this is not a high priority for them
and they are happy with the status quo.

The more important areas to the map as far as end users go are being
cleaned up but probably not as fast as you would like to see.

If you are willing to make the corrections then I feel sure that the
Canadian community would be happy to see them made.

Cheerio John

On 30 June 2017 at 03:52, Jochen Topf  wrote:

> Hi!
>
> A week ago I wrote this email and nobody answered it yet. Does that
> mean that nobody feels responsible for the import that created this data
> and nobody here cares for this data?
>
> I see three ways forward:
> * We do nothing. The broken data stays in OSM. Not a good solution,
>   because every user of the data has to work around this or handle the
>   complaints.
> * The Canadian community steps up and fixes the data, automatically or
>   manually.
> * We ask the Data Working Group to remove the broken import.
>
> Jochen
>
> On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> > Date: Thu, 22 Jun 2017 11:38:15 +0200
> > From: Jochen Topf 
> > To: talk-ca@openstreetmap.org
> > Subject: [Talk-ca] Multipolygon problems
> >
> > Hi!
> >
> > In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> > the OSMF tile servers. This new version of the style doesn't take
> > old-style multipolygons (where the tags are on the outer ways instead of
> > on the relation) into account any more. In a huge effort in the last
> > months we have converted all old-style multipolygons to the modern
> > tagging, so this is a good step!
> >
> > Unfortunately, as a side-effect of this change, many multipolygon
> > relations now appear wrong on the map. This is the case for multipolygon
> > relations that have the same tags on the relation as well as on (some of
> > the) outer or inner ways. This is *wrong* tagging, and needs to be
> > fixed. (Note that this always was wrong tagging, even before we
> > deprecated old-style multipolygons, but the way the software worked with
> > old-style multipolygons, this problem was not visible on the map. But
> > now it is.)
> >
> > Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> > you can see (unless somebody fixes this :-) the clearing in the forest
> > that should just have grass, also has tree symbols on it. In many other
> > cases it is not this obvious, there are just islands in a river missing
> > or so.
> >
> > There are about 50,000 cases like this worldwide, forests, waterways,
> > all sorts of areas. But the worst problem is in Canada. There are about
> > 15,000 affected relations, most from the CanVec imports.
> >
> > First, we have to make sure that there are no further imports of broken
> > data. I hope the people who have done those imports (and might still
> > continue) are here on this mailing list. If not please make them aware
> > of this issue and/or put me in touch with them. Second, somebody needs
> > to clean up the broken data, either automatically or manually. 99% of
> > the data has not been changed since the import, so it might be feasible
> > to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> > have to do a manual cleanup, through tools such as Maproulette and the
> > OSM Inspector. I am currently in the process of creating Maproulette
> > challenges for other areas of the planet, but will not do this for
> > Canada at this time. Lets discuss this here first.
> >
> > I can provide OSM data extracts, statistics, etc. if somebody wants to
> > look at the data.
> >
> > All of this is part of a larger effort to fix areas in OSM. See
> > http://area.jochentopf.com/ for more information. There is also a thread
> > on the talk mailinglist at
> > https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
> > and this issue
> > https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> > News of the effort are posted regularly to
> > https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .
> >
> > Jochen
> > --
> > Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
> +49-351-31778688
> >
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
>
> --
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
> +49-351-31778688
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list

Re: [Talk-ca] Multipolygon problems

[Pierre Béland]

Jochen 

cela ressemble a des menaces. Bon, il y a de meilleures façons de motiver les 
communautés locales.
Bonne journée
  
Pierre 


  De : Jochen Topf <joc...@remote.org>
 À : talk-ca@openstreetmap.org 
 Envoyé le : vendredi 30 juin 2017 3h53
 Objet : Re: [Talk-ca] Multipolygon problems
   
Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
  because every user of the data has to work around this or handle the
  complaints.
* The Canadian community steps up and fixes the data, automatically or
  manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> Date: Thu, 22 Jun 2017 11:38:15 +0200
> From: Jochen Topf <joc...@remote.org>
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Multipolygon problems
> 
> Hi!
> 
> In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> the OSMF tile servers. This new version of the style doesn't take
> old-style multipolygons (where the tags are on the outer ways instead of
> on the relation) into account any more. In a huge effort in the last
> months we have converted all old-style multipolygons to the modern
> tagging, so this is a good step!
> 
> Unfortunately, as a side-effect of this change, many multipolygon
> relations now appear wrong on the map. This is the case for multipolygon
> relations that have the same tags on the relation as well as on (some of
> the) outer or inner ways. This is *wrong* tagging, and needs to be
> fixed. (Note that this always was wrong tagging, even before we
> deprecated old-style multipolygons, but the way the software worked with
> old-style multipolygons, this problem was not visible on the map. But
> now it is.)
> 
> Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> you can see (unless somebody fixes this :-) the clearing in the forest
> that should just have grass, also has tree symbols on it. In many other
> cases it is not this obvious, there are just islands in a river missing
> or so.
> 
> There are about 50,000 cases like this worldwide, forests, waterways,
> all sorts of areas. But the worst problem is in Canada. There are about
> 15,000 affected relations, most from the CanVec imports.
> 
> First, we have to make sure that there are no further imports of broken
> data. I hope the people who have done those imports (and might still
> continue) are here on this mailing list. If not please make them aware
> of this issue and/or put me in touch with them. Second, somebody needs
> to clean up the broken data, either automatically or manually. 99% of
> the data has not been changed since the import, so it might be feasible
> to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> have to do a manual cleanup, through tools such as Maproulette and the
> OSM Inspector. I am currently in the process of creating Maproulette
> challenges for other areas of the planet, but will not do this for
> Canada at this time. Lets discuss this here first.
> 
> I can provide OSM data extracts, statistics, etc. if somebody wants to
> look at the data.
> 
> All of this is part of a larger effort to fix areas in OSM. See
> http://area.jochentopf.com/ for more information. There is also a thread
> on the talk mailinglist at
> https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html 
> and this issue
> https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> News of the effort are posted regularly to
> https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .
> 
> Jochen
> -- 
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

___
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] Multipolygon problems

[James]

https://i.imgur.com/8xKttYm.jpg

Image was ridiculously small

On Fri, Jun 30, 2017 at 6:28 AM, James  wrote:

> Example:
> https://i.imgur.com/8xKttYm_d.jpg
>
> Represents multiple thousand square kilometers of forest/objects. To
> actually be able to fix it correctly you NEED to launch JOSM in 64bit mode
> with min/max memory values set or else it will crap out/freeze at 2GB of
> memory. Now 1. JOSM doesnt document this ANYWHERE/IS VERY VERY HARD TO FIND
> for the common user. I doubt many people know about the 2gb limit(other
> than power mappers) .
> Personally I find it very arrogant of you to say well, it's been a week
> might as well contact the DWG and revert all of Canada, cause no one
> replied to my email... not everyone has the experiance needed to merge down
> polygons/relations on such a large object scale and very wide spread
> throughout Canada
>
>
> On Jun 30, 2017 6:12 AM, "James"  wrote:
>
> The problem that canvec has is multi polygons with different attributes
> were stacked on top of eachother(i.e. hole in the forest that is also a
> lake? That makes 2 polygons with same shape stacked one of top of
> eachother... marshland+water+hole in forest? 3 polygons etc etc. Not that I
> wouldnt live it fixed, but as someone that has "fixed" canvec data before
> dropping it in, It's a massive undertaking and really complexe/abstract
> thing to do.
>
> On Jun 30, 2017 3:54 AM, "Jochen Topf"  wrote:
>
> Hi!
>
> A week ago I wrote this email and nobody answered it yet. Does that
> mean that nobody feels responsible for the import that created this data
> and nobody here cares for this data?
>
> I see three ways forward:
> * We do nothing. The broken data stays in OSM. Not a good solution,
>   because every user of the data has to work around this or handle the
>   complaints.
> * The Canadian community steps up and fixes the data, automatically or
>   manually.
> * We ask the Data Working Group to remove the broken import.
>
> Jochen
>
> On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> > Date: Thu, 22 Jun 2017 11:38:15 +0200
> > From: Jochen Topf 
> > To: talk-ca@openstreetmap.org
> > Subject: [Talk-ca] Multipolygon problems
> >
> > Hi!
> >
> > In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> > the OSMF tile servers. This new version of the style doesn't take
> > old-style multipolygons (where the tags are on the outer ways instead of
> > on the relation) into account any more. In a huge effort in the last
> > months we have converted all old-style multipolygons to the modern
> > tagging, so this is a good step!
> >
> > Unfortunately, as a side-effect of this change, many multipolygon
> > relations now appear wrong on the map. This is the case for multipolygon
> > relations that have the same tags on the relation as well as on (some of
> > the) outer or inner ways. This is *wrong* tagging, and needs to be
> > fixed. (Note that this always was wrong tagging, even before we
> > deprecated old-style multipolygons, but the way the software worked with
> > old-style multipolygons, this problem was not visible on the map. But
> > now it is.)
> >
> > Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> > you can see (unless somebody fixes this :-) the clearing in the forest
> > that should just have grass, also has tree symbols on it. In many other
> > cases it is not this obvious, there are just islands in a river missing
> > or so.
> >
> > There are about 50,000 cases like this worldwide, forests, waterways,
> > all sorts of areas. But the worst problem is in Canada. There are about
> > 15,000 affected relations, most from the CanVec imports.
> >
> > First, we have to make sure that there are no further imports of broken
> > data. I hope the people who have done those imports (and might still
> > continue) are here on this mailing list. If not please make them aware
> > of this issue and/or put me in touch with them. Second, somebody needs
> > to clean up the broken data, either automatically or manually. 99% of
> > the data has not been changed since the import, so it might be feasible
> > to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> > have to do a manual cleanup, through tools such as Maproulette and the
> > OSM Inspector. I am currently in the process of creating Maproulette
> > challenges for other areas of the planet, but will not do this for
> > Canada at this time. Lets discuss this here first.
> >
> > I can provide OSM data extracts, statistics, etc. if somebody wants to
> > look at the data.
> >
> > All of this is part of a larger effort to fix areas in OSM. See
> > http://area.jochentopf.com/ for more information. There is also a thread
> > on the talk mailinglist at
> > https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
> > and this issue
> > https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> > 

Re: [Talk-ca] Multipolygon problems

[James]

Example:
https://i.imgur.com/8xKttYm_d.jpg

Represents multiple thousand square kilometers of forest/objects. To
actually be able to fix it correctly you NEED to launch JOSM in 64bit mode
with min/max memory values set or else it will crap out/freeze at 2GB of
memory. Now 1. JOSM doesnt document this ANYWHERE/IS VERY VERY HARD TO FIND
for the common user. I doubt many people know about the 2gb limit(other
than power mappers) .
Personally I find it very arrogant of you to say well, it's been a week
might as well contact the DWG and revert all of Canada, cause no one
replied to my email... not everyone has the experiance needed to merge down
polygons/relations on such a large object scale and very wide spread
throughout Canada


On Jun 30, 2017 6:12 AM, "James"  wrote:

The problem that canvec has is multi polygons with different attributes
were stacked on top of eachother(i.e. hole in the forest that is also a
lake? That makes 2 polygons with same shape stacked one of top of
eachother... marshland+water+hole in forest? 3 polygons etc etc. Not that I
wouldnt live it fixed, but as someone that has "fixed" canvec data before
dropping it in, It's a massive undertaking and really complexe/abstract
thing to do.

On Jun 30, 2017 3:54 AM, "Jochen Topf"  wrote:

Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
  because every user of the data has to work around this or handle the
  complaints.
* The Canadian community steps up and fixes the data, automatically or
  manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> Date: Thu, 22 Jun 2017 11:38:15 +0200
> From: Jochen Topf 
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Multipolygon problems
>
> Hi!
>
> In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> the OSMF tile servers. This new version of the style doesn't take
> old-style multipolygons (where the tags are on the outer ways instead of
> on the relation) into account any more. In a huge effort in the last
> months we have converted all old-style multipolygons to the modern
> tagging, so this is a good step!
>
> Unfortunately, as a side-effect of this change, many multipolygon
> relations now appear wrong on the map. This is the case for multipolygon
> relations that have the same tags on the relation as well as on (some of
> the) outer or inner ways. This is *wrong* tagging, and needs to be
> fixed. (Note that this always was wrong tagging, even before we
> deprecated old-style multipolygons, but the way the software worked with
> old-style multipolygons, this problem was not visible on the map. But
> now it is.)
>
> Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> you can see (unless somebody fixes this :-) the clearing in the forest
> that should just have grass, also has tree symbols on it. In many other
> cases it is not this obvious, there are just islands in a river missing
> or so.
>
> There are about 50,000 cases like this worldwide, forests, waterways,
> all sorts of areas. But the worst problem is in Canada. There are about
> 15,000 affected relations, most from the CanVec imports.
>
> First, we have to make sure that there are no further imports of broken
> data. I hope the people who have done those imports (and might still
> continue) are here on this mailing list. If not please make them aware
> of this issue and/or put me in touch with them. Second, somebody needs
> to clean up the broken data, either automatically or manually. 99% of
> the data has not been changed since the import, so it might be feasible
> to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> have to do a manual cleanup, through tools such as Maproulette and the
> OSM Inspector. I am currently in the process of creating Maproulette
> challenges for other areas of the planet, but will not do this for
> Canada at this time. Lets discuss this here first.
>
> I can provide OSM data extracts, statistics, etc. if somebody wants to
> look at the data.
>
> All of this is part of a larger effort to fix areas in OSM. See
> http://area.jochentopf.com/ for more information. There is also a thread
> on the talk mailinglist at
> https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
> and this issue
> https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> News of the effort are posted regularly to
> https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .
>
> Jochen
> --
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
+49-351-31778688
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> 

Re: [Talk-ca] Multipolygon problems

[James]

The problem that canvec has is multi polygons with different attributes
were stacked on top of eachother(i.e. hole in the forest that is also a
lake? That makes 2 polygons with same shape stacked one of top of
eachother... marshland+water+hole in forest? 3 polygons etc etc. Not that I
wouldnt live it fixed, but as someone that has "fixed" canvec data before
dropping it in, It's a massive undertaking and really complexe/abstract
thing to do.

On Jun 30, 2017 3:54 AM, "Jochen Topf"  wrote:

Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
  because every user of the data has to work around this or handle the
  complaints.
* The Canadian community steps up and fixes the data, automatically or
  manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> Date: Thu, 22 Jun 2017 11:38:15 +0200
> From: Jochen Topf 
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Multipolygon problems
>
> Hi!
>
> In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> the OSMF tile servers. This new version of the style doesn't take
> old-style multipolygons (where the tags are on the outer ways instead of
> on the relation) into account any more. In a huge effort in the last
> months we have converted all old-style multipolygons to the modern
> tagging, so this is a good step!
>
> Unfortunately, as a side-effect of this change, many multipolygon
> relations now appear wrong on the map. This is the case for multipolygon
> relations that have the same tags on the relation as well as on (some of
> the) outer or inner ways. This is *wrong* tagging, and needs to be
> fixed. (Note that this always was wrong tagging, even before we
> deprecated old-style multipolygons, but the way the software worked with
> old-style multipolygons, this problem was not visible on the map. But
> now it is.)
>
> Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> you can see (unless somebody fixes this :-) the clearing in the forest
> that should just have grass, also has tree symbols on it. In many other
> cases it is not this obvious, there are just islands in a river missing
> or so.
>
> There are about 50,000 cases like this worldwide, forests, waterways,
> all sorts of areas. But the worst problem is in Canada. There are about
> 15,000 affected relations, most from the CanVec imports.
>
> First, we have to make sure that there are no further imports of broken
> data. I hope the people who have done those imports (and might still
> continue) are here on this mailing list. If not please make them aware
> of this issue and/or put me in touch with them. Second, somebody needs
> to clean up the broken data, either automatically or manually. 99% of
> the data has not been changed since the import, so it might be feasible
> to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> have to do a manual cleanup, through tools such as Maproulette and the
> OSM Inspector. I am currently in the process of creating Maproulette
> challenges for other areas of the planet, but will not do this for
> Canada at this time. Lets discuss this here first.
>
> I can provide OSM data extracts, statistics, etc. if somebody wants to
> look at the data.
>
> All of this is part of a larger effort to fix areas in OSM. See
> http://area.jochentopf.com/ for more information. There is also a thread
> on the talk mailinglist at
> https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
> and this issue
> https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> News of the effort are posted regularly to
> https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .
>
> Jochen
> --
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
+49-351-31778688
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/
+49-351-31778688

___
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] Multipolygon problems

[Jochen Topf]

Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
  because every user of the data has to work around this or handle the
  complaints.
* The Canadian community steps up and fixes the data, automatically or
  manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:
> Date: Thu, 22 Jun 2017 11:38:15 +0200
> From: Jochen Topf 
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] Multipolygon problems
> 
> Hi!
> 
> In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
> the OSMF tile servers. This new version of the style doesn't take
> old-style multipolygons (where the tags are on the outer ways instead of
> on the relation) into account any more. In a huge effort in the last
> months we have converted all old-style multipolygons to the modern
> tagging, so this is a good step!
> 
> Unfortunately, as a side-effect of this change, many multipolygon
> relations now appear wrong on the map. This is the case for multipolygon
> relations that have the same tags on the relation as well as on (some of
> the) outer or inner ways. This is *wrong* tagging, and needs to be
> fixed. (Note that this always was wrong tagging, even before we
> deprecated old-style multipolygons, but the way the software worked with
> old-style multipolygons, this problem was not visible on the map. But
> now it is.)
> 
> Here is an example: http://www.openstreetmap.org/relation/1330741 . As
> you can see (unless somebody fixes this :-) the clearing in the forest
> that should just have grass, also has tree symbols on it. In many other
> cases it is not this obvious, there are just islands in a river missing
> or so.
> 
> There are about 50,000 cases like this worldwide, forests, waterways,
> all sorts of areas. But the worst problem is in Canada. There are about
> 15,000 affected relations, most from the CanVec imports.
> 
> First, we have to make sure that there are no further imports of broken
> data. I hope the people who have done those imports (and might still
> continue) are here on this mailing list. If not please make them aware
> of this issue and/or put me in touch with them. Second, somebody needs
> to clean up the broken data, either automatically or manually. 99% of
> the data has not been changed since the import, so it might be feasible
> to do an automatic cleanup, but somebody has to do this. Otherwise we'll
> have to do a manual cleanup, through tools such as Maproulette and the
> OSM Inspector. I am currently in the process of creating Maproulette
> challenges for other areas of the planet, but will not do this for
> Canada at this time. Lets discuss this here first.
> 
> I can provide OSM data extracts, statistics, etc. if somebody wants to
> look at the data.
> 
> All of this is part of a larger effort to fix areas in OSM. See
> http://area.jochentopf.com/ for more information. There is also a thread
> on the talk mailinglist at
> https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html 
> and this issue
> https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> News of the effort are posted regularly to
> https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .
> 
> Jochen
> -- 
> Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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