1

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.

2

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.

3

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)

4

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.

5

Meine bisherigen Favoriten sind:

Karlsruhe mit PLZ 76131, 76133, 76135, 76137

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

6

1 Fehler in meiner Gemeinde. :stuck_out_tongue:

7

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.

8

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.

9

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.

10

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?

11

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 …

12

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.

13

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.

14

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.

15

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?

16

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

17

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

18

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

19

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.

20

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.