Hi sarah,

i'm doing the missing boundaries task trying to fix as many bad boundary polygons as possible.

Working with osm2pgsql too i decided some month ago to disallow osm2pgsql to automatically fix these geometries by adding --exclude-invalid-polygon. In the first days i got a lot of missings but the commiunity helped me to fix all of them :)

go on and disable as much of automatic "fixing" as possible. sooner or later these real errors - which are unvisible to end users - will be fixed.

see you in karlsruhe, walter


Am 15.02.2017 um 23:51 schrieb Sarah Hoffmann:
Hi,

let me add a bit of motivation to this. For osm2pgsql, the software
that process the OSM data for rendering the map on osm.org, we are
currently discussing about changing the algorithm that assembles the
polygons[1]. The new algorithms will be a lot faster but that comes
at the price that it is less tolerant with invalid geometries. A lot
of bad geometries that are currently still drawn some way or another
will be simply dropped. I'm convinced that in the long run this
stricter handling will be good not only for data consumers but also
for mappers, who will see immediately when they made a mistake.
However, in the short run a switch from the old algorithm to the
new one will leave a few bald patches on the map.

There is a comparison map where you can see the changes:

https://osmium.osm2pgsql.paulnorman.ca

There are some notable holes, for example in the woods of
Scandinavia. It would be great if they are gone by the time we
switch the software.

Sarah


[1] https://github.com/openstreetmap/osm2pgsql/pull/684

On Wed, Feb 15, 2017 at 04:20:53PM +0100, Jochen Topf wrote:
There are a lot of (multi)polygons in OSM that are broken in one way or
another. And we have to fix them. While some of the broken ones appear
on the map just fine, some don't appear and some mess up the map. And
some of those that appear fine on the main OSM map will not show up on
other maps where different software is used.

A while ago I set up a web page at http://area.jochentopf.com/ and a
Github repository at https://github.com/osmlab/fixing-polygons-in-osm
devoted to that issue that I never announced properly. Go there and read
up in more detail where the problems are and how we are going to fix
them.

Yesterday I launched several Maproulette challenges that allow you to
easily help with the "cleaning up" effort. Read
http://area.jochentopf.com/fixing.html for more details on those
Maproulette challenges. This is a huge effort that will take a long time
and we really need any help we get. The challenges posted today are only
the beginning. They only show the about 6,500 ways worldwide tagged as
buildings (with less than 100 nodes) where the way intersects itself.

I have decided to start with a simple problem like this, to learn how
the Maproulette stuff works and how well, you, the community, responds.
Especially for beginners fixing those building is much easier than
starting with 10,000 node multipolygons with possibly multiple errors in
them. (If you want to, you can still do that. All multipolygon errors
show up in the OSM Inspector areas view at
http://tools.geofabrik.de/osmi/?view=areas )

Jochen
--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Reply via email to