[out:json][timeout:300];
// Area für Merchweiler in .a1 merken
area["boundary"="administrative"]["de:amtlicher_gemeindeschluessel"="10043113"]->.a1;
// Area in .a1 umwandeln in eine Relation und dafür die Wege/ Knoten ermitteln
// Ergebnis in .n1 merken. In .n1 sind nun alle Wege/Knoten, die den
// Rand der boundary=administrative Relation beschreiben
rel(pivot.a1); > -> .n1;
// Für die Area .a1 (Merchweiler) alle Knoten ermitteln, die einen Tag haben
// Annahme: es gibt mindestens einen Knoten in der Area
// Ergebnis in .n2 merken. Knoten, die den Rand der Area beschreiben
// sind dort noch enthalten
node[~"."~"."](area.a1) -> .n2;
//Randknoten rauswerfen
(.n2; - .n1;);
//Alle Areas ermitteln, in denen innere Knoten in Merchweiler vorkommen
is_in;
//Filtern auf Areas mit boundary=postal_code
area._["boundary"="postal_code"];
//Area wieder in eine Relation umwandeln
rel(pivot);
//und ausgeben
out geom;
Wenn man davon ausgeht, dass diese Daten in der OSM Datenbank noch aktuell sind, könnte man doch über diese nodes leicht an die PLZ kommen. Ich habe mal stichprobenartig 15 Gemeinden quer durch Deutschland überprüft und die Daten sind sowohl vorhanden als auch korrekt.
Wie würde ich denn nun vorgehen, wenn ich sagen wir die PLZ aller ~11000 Gemeinden abfragen möchte? Gibt es eine Möglichkeit, mit der Overpass API eine Liste aller Gemeindeschlüssel zu importieren und dann beispielsweise über eine for-Schleife alle Gemeinden abzuarbeiten?
<mode=“Advocatus diaboli”>
Die — rechnet man seine Arbeitszeit mit — kostengünstigste Lösung ist, bei Postdirekt die CD “DATAFACTORY BASIC” zu bestellen, die Daten in eine MySQL/PostgreSQL/YouNameItSQL-DB einzuspielen und darauf Selects loszulassen.
Also für ganz DE wird dir Roland sicher früher oder später auf die Finger hauen (->lese: eigene Instanz aufbauen!!), aber für’s Saarland kann man das schon noch laufen lassen:
Danke schonmal für die zahlreiche Hilfe. Ich habe das Problem gleich mal als Anlass genommen mich in die Overpass QL einzuarbeiten Aber verstehe natürlich noch nicht alles…
Die Idee, die Rand nodes aus dem set zu nehmen und auf den Rest is_in anzuwenden klingt gut. Leider funktionierts aber bei couchmapper’s Vorschlägen (Post #9 und #13) noch nicht vollständig richtig.
Für die Gemeinde Merchweiler (“de:amtlicher_gemeindeschluessel”=“10043113”) erhält man in beiden Fällen die PLZ 66589, 66299, 66287. Laut Wikipedia ist 66589 richtig. Zunächst dachte ich, dass es sich hier um eine lokale Mapping Ungenauigkeit handelt, also dass die “Nachbar-PLZ-area” die Gemeindegrenze an einer Stelle nur um wenige Meter überschneidet. Ich habe mir dieses Beispiel in JOSM angesehen. Dem ist aber nicht so. Die Grenze zwischen PLZ 66589 und 66299 verläuft über die identischen nodes wie auch die Grenze der Gemeinde. Der Logik entsprechend sollte 66299 also nicht gefunden werden.
Wo steckt der Fehler?
Ah ok gut, ich hatte mich auch schon gefragt ob ich völlig blöd bin und erst (vor deinem hilfreichen Kommentieren) andere Ausgaben gesehen hatte
Nun gibt es noch solche Fälle, wie ich sie schon angesprochen habe:
Eppelborn (“de:amtlicher_gemeindeschluessel”=“10043111”) liefert die PLZ 66571 und 66822. Nur 66571 ist vermutlich richtig. Das liegt daran, dass lediglich das Gebiet einer Shell Tankstelle (ID 139856533), welche sich innerhalb der Eppelborn Fläche befindet, der PLZ 66822 zugeordnet ist. Der Rest dieser PLZ liegt außerhalb von Eppelborn.
Kann man diese “kleinen Ungenauigkeiten” herausfiltern, indem man verlangt, dass z.B. mindestens 50 nodes des sets innerhalb einer area mit dem tag “boundary”=“postal_code” liegen müssen?