PLZ von Gemeinden - Datenbankabfrage?

Hier mal ein ganz anderer Ansatz mit is_in: http://overpass-turbo.eu/s/6iR


[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;

Ich bin gerade auf die openGeoDB nodes gestoßen, die sowohl die Gemeindeschlüssel als auch die der Gemeinde zugeordneten PLZ enthalten.

k="openGeoDB:community_identification_number"
k="openGeoDB:postal_codes"

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.

[out:csv("openGeoDB:postal_codes";false)][timeout:25];
(
  node["openGeoDB:community_identification_number"="16069001"];
);
out;

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?

Vorsicht: die openGeoDB wurden irgendwann mal importiert, werden aber kaum gepflegt.

Nahmd,

<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.

Gruß Wolf

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:

http://overpass-turbo.eu/s/6iS

Prinzipiell würde ich empfehlen, einen Extrakt von Geofabrik zu nehmen und damit eine eigene DB zu füttern.

Oder anders gesagt: Wenn du die Daten aus diesen Tags nutzen willst nutze lieber direkt die openGeoDB.

Eine Lösung für die Grenzsuchanfrage (aka “zu welchem Landkreis gehört Kleinstadt”) würde mich jedenfalls dennoch interessieren.

OpenGeoDB ist da zu veraltet, soweit ich informiert bin.

Das geht auch mit is_in - einfach mal selbst ausprobieren… :sunglasses:

Ich beginne zu verstehen. Vielen Dank!

is_in wird aber doch nicht funktionieren, wenn sich z.B. 2 Gemeinden eine PLZ teilen, oder?

nö, und ausserdem ist is_in am Aussterben und auf keinen Fall komplett.

Gruss
walter

Wie bitte?

Ich rede hiervon: http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Query_for_areas_.28is_in.29

Beispiel: http://overpass-turbo.eu/s/6iu

Ok, war auf dem falschen Dampfer. weitermachen :wink:

Gruss
walter

Das klingt so ähnlich wie “intersect”. Funktioniert aber nicht, wenn die boundary/exterior-Punkte auch gelten.

Naja, das kommt auf die Query an. In Post #9 / #13 habe ich die Ränder ja auch explizit rausgeworfen.

Ah, dann wäre das ja ok. Für mich ist Overpass leider weitgehend Kauderwelsch.

Gut, ich habe im Post #9 noch die Kommentare ergänzt. War vorgestern zu faul.

Danke schonmal für die zahlreiche Hilfe. Ich habe das Problem gleich mal als Anlass genommen mich in die Overpass QL einzuarbeiten :wink: 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?

Das liegt an folgendem Knoten: http://www.openstreetmap.org/node/652433309

Dummerweise überlebt der die (.n2; - .n1;) Geschichte und zieht dann zwei benachbarte postal_areas mit in das Ergebnis.

Edit: klassisches User too stupid problem. Hab heute beim Kommentieren ein “>” durch ein “node(r)” ersetzt. Das war Blödsinn, ist gefixt.

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 :wink:

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?