ich versuche die korrekten PLZ zu einem bestimmten Stadtteil zu finden(mit Postgres!), in meinem Fall für den Stadtteil Burgaltendorf in Essen.
Dazu habe ich mir zunächst alle Treffer aus planet_osm_polygon mit boundary =‘postal_code’ aus NRW herausgesucht, sowie den Stadtteil über boundary=‘administrative’ und admin_level =‘10’ (für Bugaltendorf die osm_id=-3213293).
Da ein Stadtteil ja mehrere PLZ haben kann, dachte ich mir es wäre eine schlaue Idee mit ST_intersects abzufragen welche PLZ Bereiche(planet_osm_polygon mit boundary =‘postal_code’ ) den Stadtteil Burgaltendorf(osm_id=-3213293) schneiden.
Das funktioniert auch, allerdings bekomme ich mehr PLZ dabei heraus, als es sein dürften. Eigentlich sollte es nur die PLZ 45289 sein, doch ich bekomme noch 4 weitere PLZ, die aber hauptsächlich in anderen Stadtteilen liegen.
Ich vermute es liegt daran, dass evtl. die PLZ Grenzen oder Stadtteilgrenzen zu ungenau sind und sich in Randbereichen überlappen, weswegen ST_intersects dann nicht funktionieren kann.
Gibt es einen anderen, genaueren Weg die korrekte PLZ zu finden?
Die Abfrage kriegst du übrigens auch mit Overpass Turbo hin: http://overpass-turbo.eu/s/9NH . Und ja, die Postleitzahlen-Grenzen sind nicht deckungsgleich mit den Stadtteilgrenzen ( http://overpass-turbo.eu/s/9NJ ). Stellt sich die Frage ob das wirklich so ist oder einfach eine Ungenauigkeit!?
Was du machen könntest ist evtl. einfach die Stadtteilgrenzen ein wenig zu schrumpfen und dann zu hoffen, dass die “falschen” PLZ-Grenzen bei einer Abfrage damit dann rausgefallen sind.
Zu allererst würde ich mal bei der Post.de im PLZ-Bereich überprüfen, ob die Daten in OSM korrekt sind.
Das ist erlaubt und du kannst auch die PLZ korrigieren oder mitunter die PLZ-Grenze verschieben.
Ansehen kannst du dir die in meiner PLZ-Karte (siehe Footer).
Ansonsten kannst du die Daten auch in QGIS visualisieren, da dort auch Postgresql-Daten verwendet werden können.
Gruss
walter
ach ja, ich glaube nicht, dass die PLZ-Bereiche der Post 100%-ig mit Stadtteilgrenzen identisch sind. Da weicht die Post mitunter stark von ab. Der post geht es nur um die Organisation der Zustellbezirke und mit Stadtteilen haben die eigentlich nix am Hut. Das ist dann eher zufällig, wohl weil irgend ein Sachberabeiter irgendwann mal einen Strich ziehen musste.
Na dann ist es ja vielleicht auch korrekt, dass in obigem Stadtteil eben vier Postleitzahlen verwendet werden. Von daher ist das Ergebnis von make122 vielleicht ja schon korrekt und bedarf keiner Korrektur mehr.
Einfach ist es nur nicht, festzustellen was richtig ist. Und dafür ist die Post-Seite da. Mir gefällt z.B. der hellblaue Node im Süd-Osten nicht. wie wäre es, wenn du das überprüft und ggf korrigierst?
Hab mit mal im Westen die Überruhrstrasse angesehen. so bei HN 467/485 - und da stimmt die PLZ-Grenze definitiv nicht. Die von mir angenommene Lage ist aber dennoch mit der AL10 NICHT deckungsgleicht. Damit wirst du leben müssen.
jetzt sieht es schon wesentlich besser aus. Und da ich davon ausgehe, dass die Adminstrative Grenze bestimmt aus ALK stammt und die PLZ in der Ecke jetzt richtig sind, ist es klar zu erkennen, dass sich die Post mit ihren PLZ-Grenzen eben nicht zu 100% an die Admin-Grenzen hält.
Nicht deckungsgleich - könnte man ja aber mal nachziehen.
In diesem Zusammenhang:
Ich wäre ja dafür, so weit wie möglich, die admin-Grenzen auch für die PLZ-Relation zu verwenden, und letztere nur da, wo es nötig ist, anzupassen.
Dieses - in meinen Augen unnötige - parallele Wirrwarr von verschiedenen Grenzlinien macht die Lage beim Mappen nicht unbedingt übersichtlicher …
