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" <james2...@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" <joc...@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 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