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

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

[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
> https://lists.openstreetmap.org/listinfo/talk-ca

--
Jochen Topf  joc...@remo

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 .
> > News of the effort are posted regularly to
> > https://github.com/osmlab/fixing-po

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 
 À : 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 
> 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

[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
Talk-ca@openstreetmap.org
https://lists.openstre

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
> > https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
> > News of the effort are posted regula

Re: [Talk-ca] Multipolygon problems

[Stewart Russell]

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

Re: [Talk-ca] Multipolygon problems

[john whelan]

But we could put a note in the OSM wiki where we point to the CANVEC files
saying don't bring in the polys.

Note to Stewart since you can be far more tactful than I and know the
proper technical terms could you drop something in and the French will need
covering as well.

Cheerio John

On 30 June 2017 at 10:40, 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
> > 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

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
> 
> > > > http://area.jochentopf.com/ for more information. There is also

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

___
Talk-ca mailing l

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 thread
>>> on the talk mailinglist at
>>> http

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 Inspector. I am currently in the process of creating Maproulette
>

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

[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

[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

[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 
 À : Jochen Topf  
Cc : Talk-CA OpenStreetMap 
 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"  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

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 yo

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 about five years ago. This

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 



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 
*À :* Jochen Topf 
*Cc :* Talk-CA OpenStreetMap 
*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" > 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