[OSM-talk] Fixing broken multipolygons, some notes

Andreas Vilén andreas.vilen at gmail.com
Sun Mar 19 09:03:31 UTC 2017


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 <frederik at 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 frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20170319/2a5bf3a9/attachment.html>


More information about the talk mailing list