osm2pgsql erstellt aus allen OSM-Daten, die wir mit den Editoren erstellen, eine Arbeitskopie für verschiedene Anwendungen und u.A. für Mapnik, dem Renderer.
Dabei werden nur Relationen übernommen mit type=multipolygon, type=boundary und type=route. Alle anderen Relationen werden verworfen.
/* Only a limited subset of type= is supported, ignore other */
if ( (strcmp(type, "route") != 0) && (strcmp(type, "multipolygon") != 0) && (strcmp(type, "boundary") != 0))
return 0;
aus den File output-pgsql.c von osm2pgsql.
Somit stehen in der Datenbanktabelle, die u.a. von Mapnik für openstreetmap.org und natürlich auch openstreetmap.de verwendet werden, diese Flächen einfach nicht drin.
Und was da nicht drin ist, kann nur mit extremen Klimmzügen aus anderen Daten zusammengeflickt werden.
Ich freue mich auf die erste Mapnik-Karte einer Stadt, die auch die Umweltzone enthält. Aber nicht als Overlay sondern gerendert in den Tiles. Wer das hinkriegt, hat wirklich was drauf.
So sieht grob der Datenfluß bei OSM aus:
User → Editor → API → Rohdaten-DB ->osmosis → DIFF-File → osm2pgsql → Render-DB → Mapnik → Tiles → Karte
osm2pgsql ist somit ein wichtiges, unverzichtbares Glied der Kette. (*)
Die Overpass greift direkt auf die noch “unverfälschte” Rohdaten-DB zu und findet die UZ noch, aber dann?
Mein Vorschlag: macht type=boundary und tobt euch bei dem Boundary-Tag aus.
*) Natürlich kann man osm2pgsql ändern, aber dazu muß man die Autoren , die mWn froh sind, dass das Teil überhaupt läuft, erst einmal bringen. Und kaum ist das geschafft, kriegen wir type=nature_reservate, type=hazard_zone, und vieles mehr.
Gruss
walter
NACHTRAG: Das ganze hier bezieht sich natürlich nur auf die Umweltzonen, die als Relation erfasst werden, weil sie z.B “Löcher” haben oder aus mehreren Teilflächen bestehen. “Einfache” Polygone sind hiervon nicht betroffen.
