[Talk-ca] Multipolygon problems

James james2432 at gmail.com
Fri Jun 30 22:05:52 UTC 2017


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" <steggink at steggink.org> 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 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 you don't have the manpower to fix it. That
>> can't be the excuse.
>>
> I'm not using it as an excuse, but as a fact. I don't know how "complete"
> the Canadian map is, but I'm sure that it will be way less complete when
> imports wouldn't have been done. I recall that one day I've driven about
> 800 kms, for about 12 hours in total, but the resulting GPX file doesn't
> look that "impressive". It barely made a dent, even at that time... Just a
> couple of main roads and some adjustments in the database. The same applies
> to digitizing, or as it is also called, "armchair mapping".
>
> Personally, I think that, although things were far from perfect, they were
> done with the best intentions and with the support of the majority of the
> Canadian OSM community. We have to deal with this situation now. A much
> more cooperative tone would have been very welcome, especially since you
> would like to see us coming off our lazy butts and fix our mess.
>
> There is really nothing to gain by threatening to contact the DWG in order
> to have those imports removed. They already exist for about 7 years! And if
> the Canadian community at large wouldn't have welcomed it, this would have
> come to the surface way sooner.  So, why has this suddenly become such a
> huge problem because of the way how the slippy map is rendered?
>
> We can much better focus on getting the job done, than criticizing each
> other. If 150 people are fixing 100 multipolygons each, this is doable! We
> could do it with the help of OSM inspector, and eventually a MapRoulette
> task.
>
> Jochen
>>
> Frank
>
> p.s. Are you still wearing your t-shirt with Lake Manicouagan on it, based
> on OSM data? I hope it doesn't contain wrong tagging or imported data. ;)
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20170630/fc02c086/attachment.html>


More information about the Talk-ca mailing list