[Talk-ca] Multipolygon problems

James james2432 at gmail.com
Fri Jun 30 20:03:26 UTC 2017


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" <james2432 at gmail.com> wrote:

> To be fair....your example is from Canvec 4.0.....that's reaaaaaaaaaaallly
> old....was 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" <jochen at remote.org> wrote:
>
>> On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
>> > Maybe I'm not understanding it, but in the OSM inspector [1] I just see
>> one
>> > case of old style multipolygon, in Manitoba. Last week, when you posted
>> your
>> > original message, I just saw one case in New Brunswick. IIRC, it was a
>> park,
>> > 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  jochen at remote.org  https://www.jochentopf.com/
>> +49-351-31778688
>>
>> _______________________________________________
>> 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/ee59abfe/attachment-0001.html>


More information about the Talk-ca mailing list