[Talk-ca] Multipolygon problems

James james2432 at gmail.com
Fri Jun 30 19:57:42 UTC 2017


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/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  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/4ebd9bbf/attachment.html>


More information about the Talk-ca mailing list