Postleitzahlen in Deutschland: Fehler finden via Overpass-Turbo

Dank des genialen Web-Dienstes http://wiki.openstreetmap.org/wiki/Overpass_turbo lassen sich fast beliebige Objekte in den OSM-Daten nach einer gewissen Selektion anhand logischer Regeln darstellen.

Ein Anwendungsfall dafĂŒr wĂ€re:

In den OSM-Daten gibt es (hier mal fĂŒr Deutschland dargestellt) einzelne Objekte wie Punkte oder GebĂ€ude mit Adress-Daten nach dem addr:xxx-Muster

Weiterhin sind die Gebiete der Postleitzahlenbereiche bis auf einige LĂŒcken sehr gut in dem OSM-Daten mit Grenzrelationen erfasst.

Rein logisch dĂŒrften sich innerhalb einer Grenzrelation mit postal_code=XXXXX also nur Einzel-Objekte mit addr:postcode=XXXXX finden.

Einige Tests zeigen aber: dem ist nicht so!

Um solche Fehler zu finden und zu visualisieren, lĂ€sst sich eine Abfrage fĂŒr Overpass-Turbo formulieren. Diese Abfrage findet sich (weil es bestimmt noch Änderungen oder ErgĂ€nzungen geben wird) im OSM-Wiki unter http://wiki.openstreetmap.org/wiki/Overpass_turbo/Examples#Quality_assurance_of_postal_codes

Wer also an einer PrĂŒfung der gesamten Postleitzahlen-Objekte in den OSM-Daten interessiert ist, kann ja mal beliebige PLZ mit der dortigen Abfrage probieren. Und falls sich Fehler finden lassen, dann vielleicht erstmal in der genannten Tabelle im Wiki eintragen und noch nocht sofort die OSM-Daten korrigieren.

Fragen, Anregungen, WĂŒnsche? Immer her damit!

Stephan

EDIT: Link zu overpass-turbo.eu hinzugefĂŒgt im Wiki

Und: eine Menge Postleitzahlen aus seiner eigenen grĂ¶ĂŸeren Umgebung zum Testen findet man z.B. in den Stellenanzeigen der Tageszeitung, welche ja morgen am Samstag normalerweise vermehrt drin sind.

HĂŒbsches Werkzeug. Mußte mich bremsen, nicht gleich loszulegen, da einige offesichtliche Fehler angezeigt wurden.
In einem Fall (72770) werden allerdings auch signals und turning circle (genau auf PLZ-Grenze) per Kreis markiert.

Standard bei der Kartenanzeige des Overpass-Turbo. Alle Knoten die Taggs haben werden hervorgehoben. Das erfolgt unabhÀngig davon, ob die Taggs etwas mit der Abfrage zu tun haben oder nicht. Bei Routen taucht das oft auf. Im Fall der GebÀude mit abweichenden Adressen sind das z.B. hÀufig gekennzeichnete EingÀnge.

Wenn also ein Knoten mit irgendwelchen Taggs (auch unabhÀngig von der PLZ) Teil der PLZ-Grenze sind, so werden die angezeigt. In anderen FÀllen kann das ein guter Hinweis sein, dass man sich eine Situation ggfs. einmal genauer ansehen sollte.

PS: Vielen Dank an stephan75 fĂŒr diese sehr nĂŒtzliche Anwendung.
Es fehlt beim Beispiel nur ein direkter Link zum Overpass-Turbo.
Ach ja und Dank an Roland und Manuel fĂŒr diese beiden tollen Tools.

Edbert (EvanE)

Danke fĂŒr den Hinweis.

Dieses Verhalten ist hier sogar von Vorteil, da reale Objekte (Ampel) mMn nicht auf virtuelle Grenzen (boundaries) gehören (selbst wenn die entlang der Staße verlĂ€uft), d.h. hier kann auch nachgearbeitet werden.

Meine bisherigen Favoriten sind:

Karlsruhe mit PLZ 76131, 76133, 76135, 76137

sowie 40547, 38114 und 47798 
 alles so schön bunt hier :slight_smile:

1 Fehler in meiner Gemeinde. :stuck_out_tongue:

Bitte beachten, dass es auch Objekte mit spezieller PLZ gibt. Blindes Copy&Paste richtet hier mehr Schaden an als Nutzen. Ebenso sind die Grenzrealtionen der PLZ-Gebiete nicht sonderlich genau, sodass es in den Randbereichen zu Unstimmigkeiten kommen kann.

Ich hatte diesen Thread nicht so verstanden, dass da automatisch korrigiert werden soll, sondern dass die Ausgabe dafĂŒr verwendet wird, genauer nachzusehen. Ich kenne die Grenze meiner Gemeinde ziemlich gut, wĂ€re aber nie auf die Idee gekommen, dass einzelne GebĂ€ude in mehreren Hundert Metern Abstand von der Gemarkungsgrenze falsch zugeordnet sein könnten. Um solche Fehler aufzudecken, hilft so ein Tool ungemein.

Nach ersten Erfahrungen in der Umgebung gibt es auf dem flachen Land kaum Fehler, was nicht ĂŒberrascht, da dort die Ortschaften weit genug getrennt sind. In verdichteten Gebieten und insbesondere in StĂ€dten mit PLZ-Bezirken aber gibt es fast immer Ungereimtheiten. Zum Teil sind HĂ€user und ganze StraßenzĂŒge falsch zugeordnet, zum Teil ist aber auch die PLZ-Grenze zu grob, schneidet z.B. Straßenbögen ab.

Daneben gibt es auch SonderfĂ€lle wie interkommunale Gewerbegebiete, die zu zwei Gemeinden gehören, von den Straßen her (und damit auch fĂŒr die Post) aber einseitig erschlossen sind. Da weichen Gemeindegrenze und PLZ-Grenze deutlich voneinander ab.

FĂŒr mich ist die hier adressierte Problematik der (eigentlich unnötigen) Redundanz geschuldet, dass die PLZ an zwei logisch verschiedenen Stellen auftaucht: An der Grenze und am Haus. Eine alleinige Zuordnung per Grenze kann man im Moment aber auch nicht machen, da die PLZ-Grenzen oft nicht genau genug sind.

Also ich weiß nicht wie es in anderen StĂ€dten ausschaut, aber bei mir sind die Straßen meist komplett Postleitzahlen zugeordnet und nicht nach Linien, die auf dem Stadtplan einfach gezogen wurden. Das fĂŒhrt dann auch dazu, dass einzelne Straßen (Straße A) weit in das andere Postleitzahlgebiet hereinragen. Alle umliegenden Straßen (B-Straßen), gehören einem anderen Postleitzahlenbezirk an.

Wenn dann EckhĂ€user an Kreuzungen zur B Straße gehören, haben HĂ€user, die aneinander gebaut sind, unterschiedliche Postleitzahlen. Dies kann mit den Gebietsgrenzen nur abgebildet werden, wenn die HĂ€usernodes von der Grenzrelation verwendet werden. Ein so genauer Verlauf ist mir bei mir in der Gegend noch nicht aufgefallen.

In dieser Abfrage ist es so, das ein Haus, dass von der Grenze geschnitten wird, zu beiden PLZ Gebieten gezÀhlt wird.
Ich vermute, auch wenn die Grenzrelation zwischen zwei HÀusern, die sich Nodes teilen herlÀuft, werden beide HÀuser geladen und auch eines als falsch angezeigt.

Abgesehen davon, dass ich immer was zum meckern finde, ist es ein nĂŒtzliches Tool, mit dem ich wohl noch die ein oder andere falsche Postleitzahl bei mir finden werde.

Ja, es ist interessant, auf welche problematischen Stellen man da kommen kann.

Zwischenzeitlich könnte ich noch ca. 20 weitere PLZ in die Wiki-Tabelle ergÀnzen, mal schauen wie ich das schaffe.

Ansonsten wĂŒrde ich nun sagen: Feuer Frei fĂŒr alle Korrekturen!!

Denn ein paar Anschauungsfehler werden bestimmt noch bleiben.

PS: es gibt auch “doppelte” Relationen mit postal_code=xxxxx wie jene fĂŒr 52525, 52538 oder 06193 
 brauchen wir da eigene “entkoppelte” PLZ-Relationen?
Wie lassen sich solche Doppelungen automatisch finden, Datenbankabgleich aller Relationen auf Doppelungen?

Dieses spezielle Thema (werde aber auch noch auf das ursprĂŒngliche Fehler-Modell zurĂŒckkommen) ließ mir ja keine Ruhe, denn diese Doppelungen mĂŒssen doch irgendwie systematisch ermittelbar sein.

Hab da mal folgendes probiert:

die OSM-Daten fĂŒr Deutschland als PBF-Datei von geofabrik.de herunterladen

1.) mittels osmconvert.exe in das o5m Format umwandeln

2.) mittels

osmfilter.exe  -v germany.o5m --drop-nodes --drop-ways --ignore-dependencies --keep-relations="postal_code= and boundary=" -o=plz.osm

einen Filter angewandt, welche nur noch alle Relationen OHNE Wege und Nodes behĂ€lt, welche die SchlĂŒssel postal_code= UND boundary= haben.

3.) dann wieder mit osmconvert.exe eine CSV-Datei erstellt:

osmconvert.exe plz.osm -o=plz.csv --csv="@id postal_code note name" --csv-headline

damit erhĂ€lt man eine “Tabelle” mit der OSM-ID jeder Relation, dem jeweiligen Wert von postal_code=, note= und name=

4.) nun die erstellte CSV-Datei in eine beliebige Tabellenkalkulation importieren, wie z.B. LibreOffice.
Dabei auf folgendes achten: Text ist in UTF-8-Kodierung 
 und die Spalten fĂŒr postal_code, note und name sollten schon gleich das Format “Text” zugewiesen bekommen, denn sonst wird u.U. von z.B. Postleitzahlen mit fĂŒhrender Null eben diese weggekĂŒrzt.

5.) Dann zwischen die Spalten postal_code und note eine neue leere Spalte einfĂŒgen, nennen wir sie mal Spalte C mit dem Spaltenkopf “doppelt”

In Spalte B (postal_code) finden sich nun alle fĂŒnfstelligen Postleitzahlen, die in Deutschland an irgendwelchen Grenzrelationen hĂ€ngen.

5a.) die gesamte Tabelle nun nach der Spalte “postal_code” aufsteigend sortieren.

6.) In der Zelle C2 (Spalte “doppelt”) nun folgende logische Formel einfĂŒgen:

=WENN(ODER(B2=B3;B2=B1);1;"")

Diese Formel zeigt eine 1 in der Spalte C, wenn zwei gleiche PLZ in der Spalte B vorhanden sind.

7.) Jetzt fĂŒr die gesamte Tabelle einfach den “AutoFilter” einschalten (MenĂŒ: Daten) 
 in Excel oder anderen Programmen mĂŒsste es diese Funktion auch geben 
 und den Filter fĂŒr Spalte “doppelt” dann so einstellen, dass er nur noch Zeilen mit dem Wert 1 zeigt 
 Tadaaa !!!

Somit haben wir nun eine Liste aller Grenzrelationen in Deutschland, die einen Wert bei postal_code=XXXXX haben, und dieser Wert kommt noch bei mindestens einer weiteren Relation vor.

Denn nach meinem VerstÀndnis sollte in den OSM-Daten eine Grenzrelation zu einer bestimmten Postleitzahl nur genau ein mal vorkommen, und nicht doppelt.

Ergebnis: Derzeit haben wir zu genau 480 betroffenen Postleitzahlen doppelte oder sogar mehrfache Grenzrelationen.

8.) Damit man diese Doppelungen nun sich anschauen kann, hab ich zwei weitere Spalten rechts angefĂŒgt und dort mit dem Calc-Befehl VERKETTEN jeweils eine URL zu jeder Relation unter osm.org sowie eine URL zur Darstellung via OverpassAPI gebastelt.

Es hat sich gerade bei der Darstellung in OverpassAPI gezeigt, dass es wohl etliche identische doppelte Relationen fĂŒr bestimmte Orte gibt. Ich glaube diese Gebiete erkennt man daran, dass diese dort in einem krĂ€ftigeren Gelb-Ton angezeigt werden, oder?

Eine Tabelle lĂ€sst sich dann z.B. via “csv2wp” von CSV in eine Wikimedia-Tabelle umwandeln(copy&paste). Eine erste Version mit Datenbestand 04.07.2013 habe ich mal unter http://wiki.openstreetmap.org/wiki/User:Stephan75 eingestellt.

Findet jemand hierzu grundsÀtzliche (Denk-)Fehler oder Verbesserungen? Oder wer will kann auch schon Relationen berichtigen 


Ich habe mir ein paar Duplikate (Konstanz) angesehen, die ich als “false alarms” ansehe:
Dort wurde in einer “boundary=administrative”-Relation eines Stadtteils per postal_code=xxx die Info hinterlegt, zu welchem PLZ-Gebiet der Ortsteil gehört. FrĂŒher war das als addr:postcode-Tag gespeichert, das sollte aber keine wesentliche Rolle spielen.
Als doppelt sehe ich nur “boundary=postal_code” mit gleichem postal_code=xxx an.
Dazu mĂŒsste in der Abfrage unter 2.) der Filter auf --keep-relations=“postal_code= and boundary=postal_code” geĂ€ndert werden. Momentan werden da sĂ€mtliche boundaries erfasst. Das setzt natĂŒrlich voraus, dass alle PLZ-boundaries auch so erfasst wurden.

Das sehe ich etwas anders, und das kann man auch so in den gesamten OSM-Daten sehen:

FĂŒr ganz viele Gemeinden, wo die politische Grenze mit dem PLZ-Grenze identisch ist, findet sich der Tag postal_code=XXXXX an der Relation mit boundary=administartive. Da gibt es keine extra Relation mit boundary=postal_code.

Diese Relationen sollte man also immer mit einbeziehen.

Das ganze war auch schon mal Thema im Jahr 2011: http://forum.openstreetmap.org/viewtopic.php?id=12726

Konsens daraus:
Wenn es fĂŒr ein Gebiet schon eine admin_Grenzrelation gibt, wo noch postal_code=XXXXX fehlt und die PLZ-Grenze mit der Gemeindegrenze identisch ist, dann keine neue Relation anlegen, sondern bei der alten admin_Relation einfach postal_code=XXXXX hinzufĂŒgen.

Wenn fĂŒr EIN grĂ¶ĂŸeres PLZ-Gebiet eine postal_code-Relation existiert und darin mehrere kleine admin-Relationen sind (z.B. kleine Stadtteile oder Ortsteile), dann sollte an diesen kleineren admin-Relationen KEIN postal_code vorhanden sein, denn dies wird durch die “grĂ¶ĂŸere” PLZ-Relation abgedeckt. Beispiele: PLZ 99100 oder 53913

Falls fĂŒr eine Gemeinde deren admin-Grenze und die PLZ-Grenze identisch ist, und es bereits zwei deckungsgleiche Relationen (einmal boundary=administrative und einmal boundary=postal_code) gibt, so könne diese zwei Relationen von mir aus bestehen bleiben 
 es wĂ€re aber zu ĂŒberlegen, dass der SchlĂŒssel postal_code=XXXXX an der admin-Relation ĂŒberflĂŒssig ist.

Ich werde mich mal an die ersten Korrekturen wirklich offensichtlicher Fehler machen.

Tjaaa, in den vergangenen Monaten hat sich ja bei den PLZ-Daten fĂŒr Deutschland so einiges getan:

FĂŒr jedes Gebiet zu einer Postleitzahl existiert nun (also Ende Dezember 2013) jeweils eine einzige Grenzrelation vom Typ postal_code, und von allen politischen Grenzrelationen sollten die PLZ-Angaben verschwunden oder zumindest umgetaggt worden sein. Großen Dank an alle Mitstreiter!!!

Die nun so erreichte Datenlage lĂ€sst mich auf den Anfang dieses Themas (siehe oben) zurĂŒck kommen, und zwar die Abfrage nach allen Objekten innerhalb einer PLZ-Relation XXXXX mit addr:postcode<>XXXXX

Auf der oben auch schon verlinkten Wikiseite http://wiki.openstreetmap.org/wiki/Overpass_turbo/Examples/Postal_Codes_Quality_Assurance ist ja beschrieben, wie man diese PrĂŒfung mittels overpass-api anstoßen und mit overpass-turbo darstellen kann, aber nur fĂŒr eine einzelne PLZ.

Mir schwebt aber nun auch eine systematische Auswertung vor.
Da es ja aber in unserem Lande derzeit 8.201 verschiedene Gebiets-Postleitzahlen gibt, wollte ich mal die Datenbank-Profis fragen:

  1. Wie mĂŒsste die oben genannte Abfrage nach den “unzutreffenden” addr:postcode-Objekten innerhalb einer PLZ-Relation fĂŒr eine lokale OSM-Datenbank lauten?

  2. Und kann man dann diese Abfrage per Batch oder Schleife fĂŒr alle gĂŒltigen PLZ in Deutschland durchlaufen lassen?

  3. Und dann das Ergebnis sortieren nach der Anzahl der gefundenen “vermeintlichen Fehler”?

Dabei sollten wir aber beim Ergebnis immer im Auge behalten:

Die derzeitigen PLZ-Grenzen können ungenau sein! Deshalb nur sehr mit Bedacht die Daten betrachten.
Aber vielleicht lassen sich ja so exemplarische Unstimmigkeiten finden.

Und kann man auf openstreetmap.org auch nach Postleitzahlen (evtl. vielleicht sogar nicht nur nach ganzen sondern nach auch nach nur nach der ersten Stelle oder den ersten zwei, drei, vier)? Oder ist das zumindest geplant? Oder gibt es dafĂŒr eine Spezialkarte?

Da fehlt ein Verb ausser “können”, ich nehme an du meinst “suchen”? Hiernach kann Nominatim das eventuell vielleicht mit etwas GlĂŒck. Mir wird daraus nicht direkt klar, ob die Grenzen berĂŒcksichtigt werden oder Nominatim das als Tag am Objekt brĂ€uchte (was wir ja nicht wollen).

Frage Fragen Fragen :wink:

zu 1:

  • welche “lokale OSM-Datenbank” meinst du?
  • hast du eine und wenn ja, welche? Postgresql/Postgis oder was anderes?
  • welche Software? pgsql?, qgis?
  • welches Schema? osm2pgsql oder Osmosis/Snapshot?
  • welcher Datenumfang? Ich nehme man an, germany

zu 2: ja
zu 3: ja

Das geht - theoretisch - in einer einzigen SQL-Abfrage, die ich aber nicht aus dem Ärmel ziehen kann.

schleife ĂŒber alle plz-relationen in de
   suche alle plz-nodes und plz-ways, die nicht in das aktuelle Gebiet passen
   zÀhle die fehler

end loop
sortiere absteigend nach fehlerzahl
ausgabe;

das ganze innerhalb von qgis und schwupps haben wir eine schöne Grafik :wink:
Soweit die fĂŒrchterlich graue Theorie.

geht bestimmt auch mit der Overpass, aber bei der Overpass muß ich passen - schönes Wortspiel :wink:

Schau’n mer mal - aber 1-2 Tage wird es schon dauern.

Gruss
walter

Was willst du denn erreichen/abfragen?

Gehrke hat doch schon eine schöne PLZ-Karte mit den Zonen gemacht. Die steht einige BeitrĂ€ge zurĂŒck hier im Thread.
Nee, hier steht was: http://forum.openstreetmap.org/viewtopic.php?pid=388226#p388226

Ansonsten schildere bitte mal genau dein Anliegen.

Gruss
walter

Ich bin mir nicht sicher, ob man mit dem Ergebnis allzu viel anfangen kann.
Wenige Fehler können bedeuten:

  • sauber gemappte Gegend (wenig Nacharbeit)
  • Gegend fast ohne addr:postcode (viel Nacharbeit)

Aber ansonsten eine hilfreiche Erinnerung (die Query war noch gespeichert), denn in der OSMPC-Karte fĂ€llt es nicht auf, wenn die PLZ-Grenzen ein GebĂ€ude “streifen”. Wenn die Grenze zwischen ReihenhĂ€usern und DoppelhĂ€usern durchgeht, ist der “Fehler” allerdings nicht zu beseitigen.
Bei Lindau soll es sogar ein Haus geben, bei dem die Landesgrenze zwischen KĂŒche und Wohnzimmer verlĂ€uft.

feddich! ich hab es wohl fast schon hingekriegt. Es fehlt nur noch das Sortieren nach FehlerhĂ€ufigkeit, aber da sehe ich eigentlich keinen Sinn drin. Hier mal eine kleine Liste fĂŒr “meine” Ecke, dem Rheingau-Taunus-Kreis bei Wiesbaden.


                        browse                        | postcode |        PLZ-Gebiet         
------------------------------------------------------+----------+---------------------------
 http://www.openstreetmap.org/browse/way/85485499     | 65262    | 65232 Taunusstein
 http://www.openstreetmap.org/browse/way/128024718    | 65323    | 65232 Taunusstein
 http://www.openstreetmap.org/browse/way/224540456    | 65323    | 65232 Taunusstein
 http://www.openstreetmap.org/browse/way/229768293    | 65377    | 65307 Bad Schwalbach
 http://www.openstreetmap.org/browse/way/119497719    | 65326    | 65321 Heidenrod
 http://www.openstreetmap.org/browse/way/198795968    | 54321    | 65321 Heidenrod
 http://www.openstreetmap.org/browse/way/198795969    | 54321    | 65321 Heidenrod
 http://www.openstreetmap.org/browse/node/2106956423  | 65239    | 65329 Hohenstein
 http://www.openstreetmap.org/browse/way/50414426     | 65344    | 65343 Eltville am Rhein
 http://www.openstreetmap.org/browse/way/93445380     | 65343    | 65346 Eltville am Rhein
 http://www.openstreetmap.org/browse/way/146381531    | 65343    | 65346 Eltville am Rhein
 http://www.openstreetmap.org/browse/way/181334365    | 65343    | 65346 Eltville am Rhein
 http://www.openstreetmap.org/browse/node/2361331359  | 65343    | 65346 Eltville am Rhein
 http://www.openstreetmap.org/browse/relation/1926281 | 65346    | 65347 Eltville am Rhein
 http://www.openstreetmap.org/browse/relation/1926282 | 65346    | 65347 Eltville am Rhein
 http://www.openstreetmap.org/browse/way/224758861    | 65501    | 65510 HĂŒnstetten, Idstein
 http://www.openstreetmap.org/browse/way/222541523    | 66527    | 65527 Niedernhausen
(17 rows)

die Fehler mach ich natĂŒrlich bald raus.

Ich schmeisse nachher die Auswertung fĂŒr Deutschland an und bin mal gespannt, wie lange die braucht.
Wenn jetzt noch jemand ganz schnell eine Liste haben möchte (Stadt oder Kreis, mehr nicht) bitte kurz ID der administrativen Grenze angeben.

Gruss
walter

ach ja, so geht das in Sql:


\set boundary -62746

select wno_asosmlink(osm_type::text,foo.osm_id) browse,postcode,pol.note "PLZ-Gebiet"
  from (
     select osm_id
           ,'N' osm_type
           ,way geom
           ,"addr:postcode" postcode
      from planet_osm_point 
     where "addr:postcode" <> ''
       and way &&      (select way from planet_osm_polygon where osm_id=:boundary)
       and st_contains((select way from planet_osm_polygon where osm_id=:boundary), way)

   union
    
     select abs(osm_id) osm_id
           ,case
              when osm_id > 0 then 'W'
              else                 'R'
            end osm_type 
           ,way geom
           ,"addr:postcode" postcode
      from planet_osm_polygon 
     where "addr:postcode" <> '' 
       and pointonsurface &&      (select way from planet_osm_polygon where osm_id=:boundary)
       and            st_contains((select way from planet_osm_polygon where osm_id=:boundary), pointonsurface)

   ) foo,
     planet_osm_polygon pol
 where st_contains(way,geom)  
   and boundary='postal_code'
   and postcode <> pol.postal_code
 order by pol.note,foo.osm_id
;

23 Sekunden Laufzeit.