Postleitzahlen-Polygone aus OpenStreetMap-Adressdaten interpolieren

In Deutschland sind die Postleitzahlen-Polygone in OpenStreetMap (OSM) weitgehend korrekt und vollständig vorhanden. Daher dachte ich bis vor einigen Tagen noch, dass das zumindest in Westeuropa für alle Länder gilt. Eine Recherche führte aber zu dem Ergebnis, dass in vielen Ländern gar keine, kaum oder zumindest lückenhafte Polygone für die Postleitzahlengebiete vorhanden sind. Selbst im Großraum Paris fehlt zum aktuellen Zeitpunkt im Februar 2023 noch ein großer Teil der Banlieue, wie man bei Ausführung dieser Abfrage auf Overpass Turbo¹ sehen kann:

// postalcode relations for Île-de-France region
[out:json][timeout:25];
(
  {{geocodeArea:Île-de-France"}}->.a;
  (
    relation[boundary=postal_code](area.a);
  );
);
// print results
out body;
>;
out skel qt;

Im E-Mail-Verteiler des Club UNIGIS wurde kürzlich die Frage gestellt, ob es eine offene Quelle der Postleitzahlen-Polygone für ganz Europa gebe. Sollten die Interessierten, die eine ausführliche Suche starteten, nicht falsch liegen, lautet die Antwort leider: Nein! Es gibt zwar einiges zu Postleitzahlen, aber keinen brauchbaren Polygon-Datensatz. Genannt wurden als Teilschritte zum Ziel zum Beispiel Postleitzahlen bei GeoNames sowie der eurostat-Datensatz mit Postleitzahl-Punktdaten für die EU-Staaten. Letzterer stellte sich bei genauerer Überprüfung jedoch als sehr ungenau dar, da die Punkte oftmals nicht den Zentroiden der Polygone entsprechen – verglichen mit Postleitzahl-Polygonen aus OSM im deutschen Raum – und oftmals sogar in benachbarten Polygonen liegen. ESRI und Growth from Knowledge (GfK) wurden als mögliche kostenpflichtige Quellen genannt, sofern dort entsprechende Datensätze vorhanden sind.

Auf Grundlage der vorhandenen Punktdaten wurde die Voronoi-Methode als Mittel der Wahl zum Generieren der Polygone empfohlen. Damit erreicht man zwar eine flächendeckende Polygonstruktur, aber diese ist sehr ungenau, wenn sie nur auf einzelnen Postleitzahl-Punkten beruht. Daher ist der beste Weg, diese Methode auf die kompletten, also auch mit Postleitzahlen versehenen Adresspunkte der betreffenden Region anzuwenden. Das führt natürlich zu neuen Problemen, denn komplette Adressdatensätze sind auch nicht frei verfügbar.

Die Frage lautet also: Wie genau lassen sich Postleitzahlen-Polygone der gewünschten Region aus OpenStreetMap-Adressdaten generieren? Obwohl ich glücklicher Weise Postleitzahlengebiete meist nur in Deutschland benötige, wo sie in guter Qualität vorhanden sind, führte ich in zwei ausgewählten Regionen Tests durch: Stadtteile Eppendorf, Harvestehude und Hoheluft-Ost am nordwestlichen Rand des Hamburger Gründerzeitgürtels. In Hamburg sind die Gebäude bis auf Einzelfälle komplett, Adressdaten weitgehend vollständig und alle Postleitzahlenpolygone vorhanden. Das zweite Untersuchungsgebiet ist die gesamte Stadt Basel. Hier sind die Gebäude vollständig und genauer² als in Hamburg, allerdings sind die Adressdaten in manchen Stadtbereichen sehr lückenhaft und es sind keine Postleitzahlenpolygone vorhanden.

Der Weg für die Erstellung der interpolierten Postleitzahlen-Polygone ist jeweils:

1. Daten (Adress-Punktdaten und Grenze des Untersuchungsraums als Polygone) per Abfrage auf Overpass Turbo für die gewählte Region herunterladen (Format GeoJSON),
2. Daten in QGIS laden,
3. alle Attributspalten außer addr:postcode aus dem Datensatz der Gebäude-Centroide entfernen (aus Gründen der Performanz),
4. Voronoi-Interpolation (eines der Vektor-Geometriewerkzeuge in QGIS) des Punktdatensatzes mit ausreichend Puffer zum Abdecken des gesamten Untersuchungsgebiets durchführen,
5. Voronoi-Datensatz auf das Projektgebiet zuschneiden und
6. nach dem Postleitzahlenfeld (addr:postcode) auflösen.

Im Hamburger Fall ist anschließend der Vergleich mit den dort in OSM vorhandenen Gebäudepolygonen möglich und aufschlussreich.

Untersuchungsgebiet 1: Drei Stadtteile im Bezirk Hamburg-Nord

Mit folgender Abfrage auf Overpass-Turbo werden die Zentroide der mit Adressdaten inklusive Postleitzahlen versehenen Gebäude ermittelt und als GeoJSON exportiert:

[out:json][timeout:25];
(
  {{geocodeArea:Hamburg}}->.a;
  area[boundary=administrative][admin_level=10][name~"Eppendorf|Hoheluft-Ost|Harvestehude"]->.b;
  nwr[building]["addr:postcode"](area.a)(area.b);
  nwr[entrance]["addr:postcode"](area.a)(area.b);
);
out center;

Dazu ist wichtig zu wissen, dass die Adressdaten der Gebäude in OSM in den untersuchten Bereichen entweder als Attribute des Gebäudes selbst (way oder relation) eingetragen sind oder als Attribute des Haupteingangs (node), zum Beispiel bei Reihenhäusern oder Mehrfamilienhäusern, die so eingetragen sind, dass sie mehrere Adressen beinhalten. Es gilt in anderen Regionen zu überprüfen, ob dort die Abfrage angepasst werden muss, um alle Adressdaten mit Postleitzahlen einzuschließen.

Mit einer weiteren Abfrage werden nun separat die Stadtteilgrenzen des gewählten Bereichs ermittelt und als GeoJSON exportiert:

[out:json][timeout:25];
(
  {{geocodeArea:Hamburg}}->.a;
  rel[boundary=administrative][admin_level=10][name~"Eppendorf|Hoheluft-Ost|Harvestehude"](area.a);
);
out body;
>;
out skel qt;

Zusätzlich werden für den Hamburger Fall noch die Postleitzahlenbereiche des gewünschten Stadtbereichs abgefragt und als GeoJSON heruntergeladen:

[out:json][timeout:25];
(
  {{geocodeArea:Hamburg}}->.a;
  area[boundary=administrative][admin_level=10][name~"Eppendorf|Hoheluft-Ost|Harvestehude"]->.b;
  relation[boundary=postal_code](area.a)(area.b);
);
out body;
>;
out skel qt;

In QGIS werden dann mit den so erzeugten Datensätzen die oben zusammenfassend beschriebenen Schritte durchgeführt. Hier einmal die Illustration einiger Zwischenschritte.

Im Ergebnis sieht der Vergleich zwischen den interpolierten Postleitzahlen-Polygonen und den aus OSM extrahierten Polygonen wie folgt aus.

Die Redundanz der Postleitzahlen als Attribut der Polygone und als Attribut der gebäudebezogenen Adressdaten führt hier nur in wenigen Fällen zu fehlerbedingten Abweichungen. Im Einzelfall ist zu überprüfen, auf welcher Seite der Fehler liegt. Bei kleinen Inseln ist es sehr wahrscheinlich, dass für die betreffenden Gebäude falsche oder nicht-geografische Postleitzahlen eingetragen wurden. Im Untersuchungsgebiet wäre zu klären, ob 20246 tatsächlich die geografische Postleitzahl nur eines Teilgebiets des Universitätsklinikums Hamburg-Eppendorf ist. Bei Abweichungen am Rand der Postleitzahlengebiete kann der Fehler auf beiden Seiten liegen.

Untersuchungsgebiet 2: Stadt Basel

Hier werden die für das erste Untersuchungsgebiet oben beschriebenen Schritte entsprechend durchgeführt, wobei der Schritt der OSM-Postleitzahlenpolygone ausgelassen wird, da diese Daten hier fehlen.

Ermittlung der Adresspunkte per Overpass Turbo:

[out:json][timeout:25];
(
  {{geocodeArea:Basel}}->.a;
  nwr[building]["addr:postcode"](area.a);
  nwr[entrance]["addr:postcode"](area.a);
);
out center;

Extraktion des Stadtgebiets von Basel aus OSM-Daten (anhand des eindeutigen Identifizierers nach swisstopo-Systematik):

[out:json][timeout:25];
(
  relation["swisstopo:SHN"=CH12002701];
);
out body;
>;
out skel qt;

Das Vorgehen ist auch in QGIS analog zu dem für Untersuchungsgebit 1, allerdings ohne die Schritte für die OSM-Postleitzahlenpolygone. Hier einmal einmal ein paar Zwischenschritte.

Im Ergebnis stellen sich die für Basel interpolierten Postleitzahlen-Polygone dar wie nachfolgend abgebildet.

Grundsätzlich lässt sich auf Basis des Ergebnisses sagen, dass sich selbst bei in Teilbereichen sehr lückenhaften Adressdaten akzeptable Polygone generieren lassen. Einige offensichtliche Fehler im Datenbestand sowie einige zu überprüfende Bereiche werden deutlich. Es scheint korrekt zu sein, dass ein Teil im Süden Basels zum Postleitzahlgebiet 4052 gehört, das eigentlich im Osten der Stadt und nicht direkt benachbart zu diesem Bereich liegt.

Fazit und Ausblick

Zumindest für weite Teile Europas, in denen bisher keine Postleitzahlen-Polygone in OSM vorhanden sind, lassen sich mit dieser Methode voraussichtlich in akzeptaber Qualität Postleitzahlen-Polygone generieren. Voraussetzung ist, dass Gebäude bzw. Eingänge mit Adressdaten zu großen Teilen vorhanden sind. In einem weiteren Schritt müsste die Methodik nun in weiteren Gebieten überprüft werden. Dann könnte eine Übersetzung in ein Online-Tool erfolgen, das die angegebenen Schritte für gewählte Gebiete automatisch durchführt und einen Export in einem gängigen Geodaten-Austauschformat anbietet. Solch ein Algorithmus sollte auch die Grenzen von Städten und Gemeinden sowie Stadt- und Ortsteilen mit einbeziehen, ermitteln können, ob Postleitzahlengrenzen in bestimmten Bereichen administrativen Grenzen folgen und diese dann dort als Grundlage für die Polygone nehmen. Das ist dann aber doch etwas umfangreicher und nun ruft erst einmal Modul 6 im UNIGIS-Masterstudium.

Anmerkungen

1 Ich bin großer Fan von Overpass Turbo, aber eher bezogen auf die Funktionalität, nicht so sehr wegen der Syntax. Für automatisierte Prozesse, die viele Abfragen generieren, sollte man sich aber eine eigene Instanz der Overpass API und der zugehörigen Werkzeuge auf einem eigenen Server installieren.

2 Bei einem früheren Projekt stellte ich fest, dass sich die Gebäude in der Schweiz genau mit denen aus offiziellen Katasterquellen decken, was dafür spricht, dass es dort keine Lizenzprobleme gibt bezüglich des Imports offizieller Katasterdatensätze für die Gebäude. In Deutschland passt die Lizenz für die ALKIS-Daten nicht zur OSM-Lizenz. Allerdings habe ich das noch nicht weiter untersucht.