PLZ von Gemeinden - Datenbankabfrage?

Duvodas wrote:

Kann mir jemand sagen, ob solch eine Abfrage machbar ist?

Ja.

Sie ist. Mit der CSV-Ausgabe kann man auch nur die Postleizahl-Liste erhalten.

/edit: Link für CSV

rayquaza wrote:

Sie ist.

Geht bei mir mit den meisten Gemeinden nicht - Output Menge ist leer.

Wie ist denn bei Overpass "(area.searchArea)" nach DE-9IM definiert?

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29 wrote:

Nodes are found if they are properly inside or on the border of the area. Ways are found if at least one point (also points on the segment) is properly inside the area. A way ending on the border and not otherwise crossing the area is not found. Relations are found if one of its members is properly inside the area.

F*… Kann man irgendwie einen ganz ganz kleinen Buffer um die Grenze legen?

Prinzipiell geht das ja schonmal in die richtige Richtung.

Blöd, dass der area Filter die relations nicht erfasst, wenn sie nur Elemente auf dem Rand der area haben. Da muss es doch irgendeine Lösung für geben?

Kann ich die Area auch über den Gemeindeschlüssel definieren? geocodeArea akzeptiert ja nur den Namen der Gemeinde oder? Und der ist ja leider nicht immer eindeutig...

rayquaza wrote:

https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#By_area_.28area.29 wrote:

Nodes are found if they are properly inside or on the border of the area. Ways are found if at least one point (also points on the segment) is properly inside the area. A way ending on the border and not otherwise crossing the area is not found. Relations are found if one of its members is properly inside the area.

F*… Kann man irgendwie einen ganz ganz kleinen Buffer um die Grenze legen?

Irgendwie mit around, aber das verstehe ich nicht

http://wiki.openstreetmap.org/wiki/Over … 8around.29

rayquaza wrote:

F*… Kann man irgendwie einen ganz ganz kleinen Buffer um die Grenze legen?

Das ist doch alles Gefrickel. Gibt es in Overpass also kein vernünftiges Intersection-Konzept? Dann doch besser PostGIS. Ist aber natürlich auch nicht so einfach...

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

[out:json][timeout:50];
{{geocodeArea:Landkreis␣Goslar}}->.searchArea;
(
relation["boundary"="administrative"]["de:amtlicher_gemeindeschluessel"="03153017"](area.searchArea)->.b;
relation["boundary"="postal_code"](around.b:1)
);
out␣body;
>;
out␣skel␣qt;

Man muss anpassen

• die Nominatim-Area, in der man sucht (im Zweifelsfall Deutschland nehmen)
  
• den AGS, nachdem man sucht
  

...Aber damit kriegt man auch die PLZ, die direkt an die Gemeinde mit dem AGS angrenzen.

Als Basis zum Weiterarbeiten ist das aber vielleicht schon nützlich

Gehrke wrote:

rayquaza wrote:

F*… Kann man irgendwie einen ganz ganz kleinen Buffer um die Grenze legen?

Das ist doch alles Gefrickel. Gibt es in Overpass also kein vernünftiges Intersection-Konzept? Dann doch besser PostGIS. Ist aber natürlich auch nicht so einfach...

Eben. Einiges geht schnell, einiges nicht. So wie immer ;-)

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?

Duvodas wrote:

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.

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

Nahmd,

Duvodas wrote:

Ich möchte (falls möglich automatisiert) eine Liste Gemeinden anhand ihres Schlüssels in eine Abfrage stecken und eine Liste aller PLZ erhalten, deren Gebiet die jeweilige Gemeinde überschneidet. Leider kenne ich mich bisher kaum mit Overpass API aus.
Kann mir jemand sagen, ob solch eine Abfrage machbar ist?

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

Gruß Wolf

Duvodas wrote:

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?

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.

rayquaza wrote:

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

Das geht auch mit is_in - einfach mal selbst ausprobieren... 😎

Ich beginne zu verstehen. Vielen Dank!

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

Gehrke wrote:

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/Over … 28is_in.29

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

couchmapper wrote:

Wie bitte?

Ich rede hiervon: http://wiki.openstreetmap.org/wiki/Over … 28is_in.29

Ok, war auf dem falschen Dampfer. weitermachen 😉

Gruss
walter

couchmapper wrote:

Ich rede hiervon: http://wiki.openstreetmap.org/wiki/Over … 28is_in.29

The results are all areas which contain at least one of node from the input set or the specified coordinates.

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

Gehrke wrote:

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.

couchmapper wrote:

Gehrke wrote:

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

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?

Filtern geht nicht, aber wie wär's mit Zählen: http://overpass-turbo.eu/s/6jb

/*
Zur␣administrativen␣Grenze␣von␣Eppelborn␣alle␣Postal_code␣boundaries␣samt
Zahl␣der␣jeweils␣dort␣enthaltenen␣Knoten␣ausgeben␣␣␣␣␣␣␣␣␣␣-␣couchmapper␣301114
*/

[timeout:300]
[out:csv(␣postal_code,␣::count)];

area["boundary"="administrative"]["de:amtlicher_gemeindeschluessel"="10043111"]->.a1;
rel(pivot.a1);␣>␣->␣.n1;
node[~"."~"."](area.a1)␣->␣.n2;
(.n2;␣-␣.n1;)->.n0;
.n0␣is_in;
area._["boundary"="postal_code"];
foreach->.pc␣(
.pc␣out;
node[~"."~"."](area.pc)->.pcn;
(.pcn;␣.n0;)->.alles;
(.pcn;␣-␣.n0;)->.pcn_ohne_n0;
(.n0;␣-␣.pcn;)->.n0_ohne_pcn;
((.alles;␣-␣.pcn_ohne_n0;)␣-␣.n0_ohne_pcn;);
out␣count;
);

postal_code	@count
66571
851
66822
1

Geht natürlich auch für alle Gemeinden im Saarland: http://overpass-turbo.eu/s/6j9

Ist aber alles nicht mehr so ganz im sweet spot von Overpass API: hier hätte ich wohl schon längst zu PostGIS gegriffen 😎

Ich würde auf keinen Fall davon ausgehen, dass die Wikipedia-Angaben richtig/vollständig sind. Auch eine Abfrage bei der DPAG liefert nicht alle PLZ einer Gemeinde.

kommen wir mal von der Theorie zur Praxis:

select␣-plz.osm_id,␣plz.note,-boundary.osm_id,boundary.name
from␣planet_osm_polygon␣plz,
planet_osm_polygon␣boundary
where␣boundary.boundary='administrative'
and␣plz.boundary␣=␣'postal_code'
and␣length(boundary.tags->'de:amtlicher_gemeindeschluessel')␣>5
and␣st_intersects␣(boundary.way,␣␣plz.way)
order␣by␣boundary.name,␣plz.note;

ergibt http://osm.wno-edv-service.de:82/images … meinde.txt

Gruss
walter

ps: um die Umlaute und andere Feinheiten kümmere ich mich später mal.

wambacher wrote:

um die Umlaute und andere Feinheiten kümmere ich mich später mal.

Gut, dann fangen wir mal bei den eigentlichen Daten an: 😎

␣␣␣3346971␣|␣66265␣Heusweiler␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣1187149␣|␣Eppelborn
1184805␣|␣66557␣Illingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣1187149␣|␣Eppelborn
1184803␣|␣66571␣Eppelborn␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣1187149␣|␣Eppelborn
3348207␣|␣66636␣Tholey␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣1187149␣|␣Eppelborn
3348209␣|␣66646␣Marpingen␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣1187149␣|␣Eppelborn
3348204␣|␣66822␣Lebach␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣1187149␣|␣Eppelborn

Dat kann so nicht stimmen... da dürften maximal 66571 und 66822 rauskommen (siehe vorheriger Post).

Gehrke wrote:

Auch eine Abfrage bei der DPAG liefert nicht alle PLZ einer Gemeinde.

Hast du ein Beispiel hierzu?

couchmapper wrote:

Dat kann so nicht stimmen... da dürften maximal 66571 und 66822 rauskommen (siehe vorheriger Post).

Jo, ist logisch. Wieder mal das blöde st_intersects, was den Rand mit nimmt. Nun denn, dann buffern wir halt.
Die 2-3, die ich überprüft hatte, waren natürlich sauber 🙁

Gruss
walter

TobWen wrote:

Gehrke wrote:

Auch eine Abfrage bei der DPAG liefert nicht alle PLZ einer Gemeinde.

Hast du ein Beispiel hierzu?

23701 Süsel. Es gibt in Süsel auch Adressen in PLZ 23684. Das ist aber nur eins von zig oder hunderten Beispielen.

wambacher wrote:

Wieder mal das blöde st_intersects, was den Rand mit nimmt.

ST_Relate

Gehrke wrote:

wambacher wrote:

Wieder mal das blöde st_intersects, was den Rand mit nimmt.

ST_Relate

ach du grüne neune, da muß ich mich mal reinknien.

Danke für den Tip
walter

uii, wenn ich eine Testauswertung mit Eppelborn und Umgebung füttere, kommt tatsächlich das Richtige raus:

select␣-b.osm_id␣border,b.name,-p.osm_id␣pcborder,p.note
from␣planet_osm_polygon␣b,
planet_osm_polygon␣p
where␣b.osm_id␣in␣(-1187149)
and␣p.osm_id␣in␣(-3346971,-1184805,-1184803,-3348207,-3348209,-3348204)
and␣b.way␣&&␣p.way
and␣ST_Relate(b.way,p.way,'T********')
order␣by␣b.name,b.osm_id␣desc,␣p.note
;

border␣␣|␣␣␣name␣␣␣␣|␣pcborder␣|␣␣␣␣␣␣note
---------+-----------+----------+-----------------
1187149␣|␣Eppelborn␣|␣␣1184803␣|␣66571␣Eppelborn
1187149␣|␣Eppelborn␣|␣␣3348204␣|␣66822␣Lebach
(2␣rows)

Gehrke wrote:

23701 Süsel. Es gibt in Süsel auch Adressen in PLZ 23684. Das ist aber nur eins von zig oder hunderten Beispielen.

Woran machst du fest, dass sie dort wirklich (noch) gültig ist?

TobWen wrote:

Gehrke wrote:

23701 Süsel. Es gibt in Süsel auch Adressen in PLZ 23684. Das ist aber nur eins von zig oder hunderten Beispielen.

Woran machst du fest, dass sie dort wirklich (noch) gültig ist?

An den Straßennamen dort, die für Pönitz gelistet sind.

so, 2. und hoffentlich erfolgreicher Versuch:

select␣-b.osm_id,b.name,p.note
from␣planet_osm_polygon␣b,
planet_osm_polygon␣p
where␣b.boundary='administrative'
and␣p.boundary␣=␣'postal_code'
and␣length(b.tags->'de:amtlicher_gemeindeschluessel')␣>5
and␣b.way␣&&␣p.way
and␣ST_Relate(b.way,p.way,'T********')
order␣by␣b.name,b.osm_id␣desc,␣p.note;

http://osm.wno-edv-service.de:82/images … relate.txt

Gruss
walter

Jau! Würde noch die ungefähre Fläche mit einbauen, damit man mini-fatzen besser sehen kann:
ceil(st_area(st_intersection(b.way,p.way))) as area

Ok die Daten sehen gar nicht so schlecht aus, wenn man die rechte Spalte als Gemeindename heranzieht. Diesmal habe ich aber k.A. wie sie zustande kommen... Kannst du noch die Gemeindeschlüssel dazu ausgeben?

Gehrke wrote:

An den Straßennamen dort, die für Pönitz gelistet sind.

Wieso tun alle hier immer so geheimnisvoll? Sag' doch einfach mal welche...

couchmapper wrote:

Jau! Würde noch die ungefähre Fläche mit einbauen, damit man mini-fatzen besser sehen kann:
ceil(st_area(st_intersection(b.way,p.way))) as area

fatzen? http://www.enzyklo.de/Begriff/Fatzen

oder meintest du Fetzen?

wambacher wrote:

meintest du Fetzen?

Ja genau, das war moselfränkisch. LOL.

couchmapper wrote:

wambacher wrote:

meintest du Fetzen?

Ja genau, das war moselfränkisch. LOL.

ok, mach ich halt Fatzen - und die AGS kommen auch. Dauert nur, da die Abfrage nicht gerade flott geht.

Super, danke!

feddich: http://osm.wno-edv-service.de:82/images … d_area.txt

Musste den Job nochmals laufen lassen, da die Formel von couchmapper nicht ganz passte.

select␣-b.osm_id␣osm_id,b.name,
b.tags->'de:amtlicher_gemeindeschluessel'␣ags,
p.note,
st_area(geography(st_intersection(b.way,p.way)))␣/␣1000000␣area
from␣planet_osm_polygon␣b,
planet_osm_polygon␣p
where␣b.boundary='administrative'
and␣p.boundary␣=␣'postal_code'
and␣length(b.tags->'de:amtlicher_gemeindeschluessel')␣>5
and␣b.way␣&&␣p.way
and␣ST_Relate(b.way,p.way,'T********')
order␣by␣b.name,b.osm_id␣desc,␣p.note;

Area ist in Km²

Gruss
walter

TobWen wrote:

Gehrke wrote:

An den Straßennamen dort, die für Pönitz gelistet sind.

Wieso tun alle hier immer so geheimnisvoll? Sag' doch einfach mal welche...

Ich habe das nicht alles im Kopf, sondern muss es erst nachschlagen. Außerdem habe ich anderes zu tun.

Messenkamp ist eine Straße, die in Süsel liegt und bei Pönitz gelistet ist. Die Siedlung heißt Broderdammskamp.
Ist aber auch ohne Geheimwissen herauszufinden, wenn man sich in OSM die PLZ-Relation 23684 anschaut.

Ich muss nochmal Salz in die Wunde streuen. Auch OSM vermag nicht, die absolut richtige Antwort zu liefern. Das liegt natürlich einerseits an Spezialfällen, die nicht richtig in den postal boundaries abgebildet sind. Andererseits gibt es Probleme mit unbewohnten Gemeindeexklaven, die aber nicht als PLZ-Exklaven gemappt sind, was eigentlich auch keinen Sinn macht, weil es dort ja keine Adressen gibt.

Zweite schlechte Nachricht: Ob es in einer Gemeindeexklave wirklich keine Adressen gibt, kann OSM auch (noch) nicht sicher sagen.

Super, danke für eure Hilfe! Ich habe nun nicht nur die gesuchten Daten (so gut sie OSM liefern kann) bekommen sondern mich nebenbei auch in die Datenbankabfrage eingearbeitet 🙂

Duvodas wrote:

Super, danke für eure Hilfe! Ich habe nun nicht nur die gesuchten Daten (so gut sie OSM liefern kann) bekommen sondern mich nebenbei auch in die Datenbankabfrage eingearbeitet 🙂

jaja, die OSM-Truppe ist schon ein starker Verein.

Mein inoffizieller Wahlspruch: "Einzeln sind wird stark, gemeinsam unausstehlich" 😉

ach ja: "so gut sie OSM liefern kann": hast du da eine bessere Quelle? Inzwischen korrigiert sogar die Post ihre Verzeichnisse nach unseren Fehlermeldungen.

Gruss
walter