<div dir="auto">Error free Québec, just in time for Canada day! Good job Pierre :-)</div><div class="gmail_extra"><br><div class="gmail_quote">On Jul 1, 2017 4:34 AM, "Frank Steggink" <<a href="mailto:steggink@steggink.org">steggink@steggink.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jochen,<br>
<br>
Maybe a MapRoulette challenge might even not be necessary. Yesterday I started to clean up a bit in Québec, but since it was already past midnight for me, I wanted to continue this morning. To my surprise Pierre has done a lot of work and now the entire province of Québec looks to be free from these errors. I just could find three errors, and fixed them. Bon travail, Pierre!<br>
<br>
The OSM inspector will still be a good idea, in order to spot future errors.<br>
<br>
To all, this is the procedure I used yesterday, and probably something similar also by Pierre.<br>
* Not sure if it is a requirement, but it's better to use 64 bit Java.<br>
* You'll need JOSM with the remote control plugin. You'll also need to start JOSM.<br>
* Use Pierre's Overpass query (<a href="http://overpass-turbo.eu/s/q5K" rel="noreferrer" target="_blank">http://overpass-turbo.eu/s/q5<wbr>K</a>), and zoom/pan to the area of interest.<br>
* Press Run and let Overpass do its work. Don't be afraid when Overpass mentions that the result is huge if you have a modern computer. Last night I wasn't experiencing any problems with 30MB data.<br>
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks you to decide.<br>
* JOSM starts downloading the data. Note that you're only getting the outer rings.<br>
* Go to these rings one by one, and load data (at least you'll need the relationship itself).<br>
* Remove the natural=wood tag from the outer ring.<br>
* Eventually JOSM starts looking cluttered, because of all the extra data. You can use the search query "type:way natural=wood role:outer" to see if there are still rings needing work.<br>
* Upload your changes. Be prepared to handle conflicts if someone else is working near you on this issue as well.<br>
* After a while, check Overpass Turbo again.<br>
<br>
I'm not sure what the update frequency is, but Pierre's changes from 4 hours ago were already processed.<br>
<br>
Good luck!<br>
<br>
Frank<br>
<br>
<br>
On 01-07-2017 09:52, Jochen Topf wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 30-06-2017 21:21, Jochen Topf wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe I'm not understanding it, but in the OSM inspector [1] I just see one<br>
case of old style multipolygon, in Manitoba. Last week, when you posted your<br>
original message, I just saw one case in New Brunswick. IIRC, it was a park,<br>
not even from the Canvec import.<br>
</blockquote>
The types of problems I am talking about don't show up in the OSM<br>
inspector. This is not old-style multipolygons (where tags are on the<br>
outer ways and not on the relation), but multipolygons where the tags<br>
are on the relation AND on the ways.<br>
</blockquote>
Ah, ok, now I understand. Since there was a lot of discussion about old<br>
style multipolygon tagging, and since this type of problem hasn't been added<br>
to OSM inspector,  this wasn't immediately obvious.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the OSM inspector other errors can be seen, but the most prevalent one is<br>
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing<br>
which seems urgent to me.<br>
<br>
Here is an example of a forest multipolygon, imported by me<br>
(canvec_fsteggink). It is still version 1, but it has tags on the relation,<br>
not on the rings (except for the quarries): [2]<br>
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I<br>
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such<br>
cases in the OSM inspector.<br>
<br>
So, I'd like to ask you to give a couple of examples where data imported<br>
from Canvec is clearly wrong with regard to old style multipolygon tagging.<br>
</blockquote>
Here are all cases in Canada (not only those from the imports):<br>
<a href="https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf" rel="noreferrer" target="_blank">https://tmp.jochentopf.com/954<wbr>226a3acab882d28d8500ddef8203d/<wbr>same-tags-ca.pbf</a><br>
<br>
Here is one example where you can clearly see the problem:<br>
<a href="http://www.openstreetmap.org/relation/541821" rel="noreferrer" target="_blank">http://www.openstreetmap.org/r<wbr>elation/541821</a><br>
</blockquote>
How difficult would it be to add this to OSM inspector? Not everybody has<br>
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,<br>
but it requires some technical skills. Also, it would be very convenient to<br>
have this updated daily.<br>
</blockquote>
It is not that difficult to add to the OSM Inspector and if I have the<br>
time I'll work on that together with the Geofabrik people.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When we have clear examples, then it might be easier to come up with a plan<br>
how to fix it. But so far, I see absolutely no reason why Canada stands out<br>
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,<br>
but as others already have pointed out, mapping everything by hand in<br>
especially remote areas is nearly impossible.<br>
</blockquote>
Canada stands out in a negative way, because<br>
a) there are so many problems. Nearly a third of the cases worldwide are in<br>
     Canada and<br>
b) most of these problems are probably caused by one little program, the<br>
     program used to convert/import the CanVec data.<br>
</blockquote>
As you might have noticed, later imports, like the example I provided, don't<br>
have that issue anymore. I'm mentioning this to express that not _all_<br>
Canvec data is at fault! Only the first couple of versions. However, for<br>
some reason this was never noticed up until a point that collaborative<br>
action was done to have it fixed. Probably because the rendering pipeline of<br>
the slippy map was accepting this kind of tagging up until recently.<br>
</blockquote>
Okay, that is a big relief already. At least we are not making this<br>
problem worse by new imports that might happen in the future.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Mapping Canada "by hand" might be difficult because it is such a huge<br>
country and there aren't that many mappers. But the same arguments goes<br>
for why you have to be extra careful importing data. If you break<br>
something, there are not enough people to fix it manually. And, yes,<br>
errors do happen. And if we find them, we fix them and move on. But<br>
errors from imports can be so huge there aren't enough people there to<br>
fix them manually.<br>
</blockquote>
The world is so huge that there aren't enough people to create and maintain<br>
a global world map. However, OSM exists. Fixing errors can also be<br>
crowdsourced. Martijn van Exel is really doing a great job with MapRoulette,<br>
for instance. Although fixing errors (cleaning up the mess left behind by<br>
others) is not nearly as rewarding as mapping, it might be easier to do,<br>
especially since there is no need for a lot of creativity when fixing the<br>
same kind of errors.<br>
</blockquote>
You might have seen that I spent a lot of time in the last months to<br>
create more than 60 Maproulette challenges for all sorts of different<br>
multipolygon problems in different communities. And the community worked<br>
tirelessly on all these problems. (<a href="http://area.jochentopf.com/fixed.html" rel="noreferrer" target="_blank">http://area.jochentopf.com/fi<wbr>xed.html</a>)<br>
<br>
If the Canadian community steps up and is willing to do this work<br>
manually, I'd he happy to provide such Maproulette challenges. I have<br>
challenges running at this moment for this exact problem for other parts<br>
of the world (<a href="http://area.jochentopf.com/fixing.html" rel="noreferrer" target="_blank">http://area.jochentopf.com/fi<wbr>xing.html</a>). But I wanted to<br>
give the Canadian community the chance for some input first, because of<br>
the unique situation here.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally, I think that, although things were far from perfect, they were<br>
done with the best intentions and with the support of the majority of the<br>
Canadian OSM community. We have to deal with this situation now. A much more<br>
cooperative tone would have been very welcome, especially since you would<br>
like to see us coming off our lazy butts and fix our mess.<br>
<br>
There is really nothing to gain by threatening to contact the DWG in order<br>
to have those imports removed. They already exist for about 7 years! And if<br>
the Canadian community at large wouldn't have welcomed it, this would have<br>
come to the surface way sooner.  So, why has this suddenly become such a<br>
huge problem because of the way how the slippy map is rendered?<br>
</blockquote>
Well, I tried writing a nice mail informing you all about the problem. A<br>
week later, when nobody had even acknowledged the problem, I wrote the<br>
next mail. And that did exactly what it was supposed to do: It got you<br>
all off your butts and discuss this problem. Now to the next step:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We can much better focus on getting the job done, than criticizing each<br>
other. If 150 people are fixing 100 multipolygons each, this is doable! We<br>
could do it with the help of OSM inspector, and eventually a MapRoulette<br>
task.<br>
</blockquote>
Thank you. That is the first time somebody from the Canadian community<br>
is actually addressing the issue at hand and proposing a way forward.<br>
Lets see whether other people in the community see it the same way and<br>
you can come to a solution together.<br>
<br>
I can help by providing Maproulette challenges and OSMI views and<br>
downloads with lists of affected relations etc. But I can't decide how<br>
you want to address this problem. The Canadian community has to do this.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
p.s. Are you still wearing your t-shirt with Lake Manicouagan on it, based<br>
on OSM data? I hope it doesn't contain wrong tagging or imported data. ;)<br>
</blockquote>
Unfortunately the lake has faded a lot on that t-shirt so I don't wear<br>
it much any more. I should make a new one! :-)<br>
<br>
Jochen<br>
</blockquote>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer" target="_blank">https://lists.openstreetmap.or<wbr>g/listinfo/talk-ca</a><br>
</blockquote></div></div>