Hi, wie ich an der überwältigen Resonanz erkenne, herrscht hier ein wahnsinniges Interesse, die OSM-Daten sauber zu bekommen
Nun denn,
ich habe inzwischen herausgefunden, wo die meisten defekten Multipolygone und Boundaries von osm2pgsql kommentarlos hingeschoben werden:
Sie landen in planet_osm_line, genau dort wo auch richtigerweise lineare Relationen (Routen!) hinkommen. Ist im Nachhinein auch fast logisch, da diese aufgrund des Fehlers eben keine geschlossene Linien (Polygone) sind und dafür zu den einfachen Linen geschoben werden.
Da musste erst mal drauf kommen.
Der type (multipolygon oder boundary) wird natürlich nicht übernommen
somit werden aus dem defekten MP #4077706 und der Boundary #4077792 jeweils zwei Linien mit -RELID als Key.
osm_id | tags | st_summary | st_astext
----------+-------------------------------------------+-----------------------------+---------------------------------------------------------------------------------------------------------------------
-4077706 | "landuse"=>"farmland" | LineString[b] with 5 points | LINESTRING(8.0948198 50.1052632,8.0946501 50.1050122,8.0937544 50.1051622,8.0940938 50.1056641,8.0948858 50.105404)
-4077706 | "landuse"=>"farmland" | LineString[b] with 2 points | LINESTRING(8.0951168 50.105372,8.0950272 50.105239)
-4077792 | "boundary"=>"region", "admin_level"=>"17" | LineString[b] with 5 points | LINESTRING(8.0948198 50.1052632,8.0946501 50.1050122,8.0937544 50.1051622,8.0940938 50.1056641,8.0948858 50.105404)
-4077792 | "boundary"=>"region", "admin_level"=>"17" | LineString[b] with 2 points | LINESTRING(8.0951168 50.105372,8.0950272 50.105239)
(4 rows)
Da kommt richtig Freude auf - aber zumindest sehe ich jetzt einen Weg, defekte Flächenrelationen in der DB zu finden.
Gruss
walter
ps: Gerade auf OSM-DEV eingetrudelt:
MapQuest has spent some work converting osm2pgsql to C++, and have put
up a pull request to merge our work back upstream to osm2pgsql.
In theory, this should have no real impacts for anyone simply using
osm2pgsql, as any of the dependencies required will be found on any
rendering server using Mapnik 2. The main impacts will be for
developers, and some speed increases.
There is also a new backend, the multi-backend. This will have more
long-term impact, but is a new feature, and will only be of use to those
running multiple servers, or requiring multiple rendering databases with
different style files.
More information can be found on the pull request at
https://github.com/openstreetmap/osm2pgsql/pull/187