To be fair, "the local community" in this case is probably mostly me and my interpretation of the Swedish community's reaction when someone tried to remove Corine imagery rather carelessly (introduced a lot of new errors) a couple of years ago. It's too bad that we're talking about a region when no one from that region is posting in this mailing list (even though I'm sure many read it).
Also, as has been pointed out earlier, Corine data might be bad, but does not contain that many pure data errors as we define them. This is approximately the area in Sandor's link in OSM inspector: http://tools.geofabrik.de/osmi/?view=areas&lon=10.35829&lat=60.44245&zoom=10 This is probably the worst problem area but that has been mapped by hand: http://tools.geofabrik.de/osmi/?view=areas&lon=14.63086&lat=56.93988&zoom=9 The main problem with Corine is that oftentimes the landuse data overlaps villages (which I found when I mapped mountain villages in southern Spain last week as well) and also when someone has been mapping by hand and doesn't clean up the Corine data while doing that (I have been doing a lot of cleanup here, but lots of fixing remains, but as you can see, no mapping errors: http://tools.geofabrik.de/osmi/?view=areas&lon=16.63835&lat=56.73536&zoom=12 ). Maybe new error tools can be developed to find for example when Corine data overlaps other landuse data, or it can be taught to analyze imagery for buildings inside farmland/forest tags? /Andreas On Sat, Mar 18, 2017 at 11:24 PM, Frederik Ramm <frede...@remote.org> wrote: > Sandor, > > if I understand you correctly your basic message is "let's try and > improve osm2pgsql's polygon interpretation rules instead of fixing the > data", or at least "while we wait for the data fixing to be completed". > > I think this is not a good idea because, as you remark yourself, those > working with the OSM source data directly will not profit from more > magic in osm2pgsql. We would have more situations where someone > processes OSM data with, say, QGIS and thinks "uh, I must have done > something wrong, because on the OSM map there's a forest here and on my > map there isn't". > > Fixing the data in OSM is the better approach. In many cases, broken > polygons are a result of a broken import or careless editing and if > MapRoulette prompts someone to open their editor in that location, they > are likely to find quite a few other things worth of attention. > > > The “Fixing broken polygons”, especially programmatic/mass fixing, could > > be more dangerous to all users. > > I wholly agree that, with perhaps a very few narrowly defined > exceptions, nobody should make an attempt to fix broken polygons > automatically because many things go wrong (and the automatic fix would > not give us the advantage I mentioned above, that someone looking at the > data in the area might find other things amiss). > > > Let us look at a map extract from the > > mentioned Scandinavian forests > > It has been suggested to completely remove some CORINE-based landcover > import in Scandinavia on the basis that not only there are many broken > polygons, but also that it bears very little resemblance to the reality > on the ground. People have said it is a nicely painted map but not much > more. But I believe the local community said they preferred a nicely > painted and somewhat wrong map over having to trace the forests from > aerial imagery themselves ;) > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
