Pflege der deutschen PLZ-Daten in OSM

Um es etwas deutlicher zu sagen: Bei den paar Fällen die ich so nebenbei mitbekommen habe (z.B. via OSM-Notes; mir sind Postleitzahlen eigentlich egal) waren immer die Tags falsch und die Grenzen richtig…

Für die Anwendungen, die damit nicht umgehen können [1] könnte ja jemand™ ein einfaches Tool zum Vorbereiten der Daten schreiben :wink:

[1]: Usecase: direkte Nutzung von kleinen .osm-Extrakten; Software: (fast?) alle ohne Datenbank; Device: potentiell alle. Wir haben zu wenig Tools, die OSM-Daten in benutzbarere Datenformate konvertieren und zu viele, die OSM-Daten direkt nutzen.

@wambacher: Wohin sollte dein Link zeigen?

Stimme Dir zu.

Zum Usecase meine ich das etwas konkreter, z.B.: “User nutzt OsmAnd (oder sonst was) auf dem Handy, um die Postleitzahl eines Gebäudes nachzuschlagen, weil er dem Bewohner einen Brief schicken will.”

Wie wahrscheinlich ist dieser Usecase? Nach meiner Einschätzung nahe 0. Dann eher “User öffnet Google Maps (leider), um PLZ nachzuschlagen” oder “User öffnet spezielle App (mit OSM-Datenbasis), um PLZ nachzuschlagen”.

User öffnet OSM And und sucht eine Adresse weil er dahin navigiert werden möchte. PLZ dient zur Unterscheidung der verschiedenen Adressen mit gleichem Ort und gleicher Straße! Wie wahrscheinlich ist dieser Fall?
Insbesondere nach Eingemeindungen etc.
Die Frage nach dem ortsteil möchte ich gleich ausschließen, da auf Postalischen Adressen diese oft nicht vorhanden sind.
Außerdem können sie dazu dienen Tipfehler zu erkennen.
Beispiel: Charlottenstraße in Berlin

Usecase:

Ja, den kann ich mir gut vorstellen. Problem: Die meisten Adressen sind schon jetzt nicht mit addr:postcode annotiert (oder falsch). Die Straße selbst vielleicht eher?
Die robuste Lösung einer Software müsste dann doch sein, (1) Kontextinformationen (z.B. Straße oder eben Postcode-Polygon) einzubeziehen und (2) ggf. die (vermeintlichen) Treffer zur Auswahl zu stellen, wenn keine sichere Zuordnung möglich ist.

EDIT: Wie schon angemerkt, könnte eine Software, die mit dem Kontext nichts anzufangen vermag, alternativ auch als lokaler Aufbereitungsschritt für den Dateninput alle Adressen mit addr:postcode annotieren.

sorry, hab ihn korrigiert, siehe oben und hier

Was bedeutet die 75?

Ich glaube Du hast an diesem Bereich gearbeitet. Da ist wohl jetzt etwas kaputt repariert worden. Der Teil nördlich von dem Bach gehört verwaltungstechnisch zu dem Ortsteil Ekelsdorf und somit zur Gemeinde Süsel. Postalisch wird dieser Teil aber über die PLZ 23684 abgewickelt (siehe http://www.openstreetmap.org/changeset/19905714). Deswegen habe ich mit an dieser Stelle die administrative Grenze von der postalische getrennt.

Oder weißt Du was anderes? Wenn nicht, dann mache bitte deine Änderungen rückgängig!

Christian

75 Abweichungen zwischen addr:postcode und boundary=postal_code

Ich habe die Adressen des Gebiets bei der Dt. Post überprüft (weil dort “Irrläufer” waren) und bekam die Antwort, dass die Straßen zu Scharbeutz und nicht zu Süsel gehören. Stimmt das nicht (mehr)? Kennst Du jemanden, der dort wohnt, um eine definitive Antwort zu bekommen?

EDIT: Im Web ( http://www.vg-eutin-suesel.de/Gemeinde-S%C3%BCsel/Gemeinde/Dorfschaften/Ekelsdorf ) ist das auch komisch. Einer der Kontaktpersonen für Süsel-Ekelsdorf wohnt in Scharbeutz im fraglichen Gebiet.

EDIT 2: Im dort verlinkten Gemeindeplan (Google Maps) ist das fragliche Gebiet auch nicht Teil von Süsel.

85092 vs. 85101 Lenting (1137 Fälle) und 85092 vs. 85120 Hepberg (785 Fälle) sind weitgehend korrigiert. Weitere Beispiele für die schlechte Qualität von “addr:postcode|city”.

Kann ich so nicht unterschreiben.
Ich kümmere mich gerade um “Kleinvieh” auf dem flachen Lande, bis die BW-Liste aktualisiert wird.
Da hat bisher fast immer addr:postcode gestimmt und die richtige PLZ-Grenze wich um ein paar Meter von der Gemeindegrenze ab, die bisher als PLZ-Grenze verwendet wurde.

Na ja, ich hatte jetzt schon ca. 5000 Fälle.

Interessant. War die Gemeindegrenze da auch falsch? Oder wie kam es zu diesem Effekt? Ein Beispiel wäre gut.

denkt bitte daran, daß die Daten bestimmt von unterschiedlichen Mappern stammen und nicht überall qualitativ gleich gut/schlecht sind. Ihr vergleicht gerade Äpfel mit Birnen.

Gruss
walter

@seichter: BW rennt seit 16:00 uhr - bayern hat fast 8 Stunden gebraucht. warum auch immer.

Die Ausgangsdaten für die PLZ-Gebiete (siehe Import/Catalogue/Postleitzahlen_Deutschland_2010) haben einen deutlichen Versatz (leider nicht einheitlich). Dieser Versatz wurde beim händischen Import nicht immer vollständig ausgeglichen. Von daher ist bei Korrekturen immer zu prüfen, was den nun falsch ist: Das PLZ-Gebiet oder die PLZen an Gebäuden.

Innerhalb Bonns wurde der Versatz der PLZ-Gebiete zwar in Ost-West-Richtung anhand des Rheins korrigiert, nicht jedoch der Versatz in Nord-Süd-Richtung. Daher gibt es in Bonn reichlich Fehler, die jedoch in der Mehrheit an der falschen Lage der PLZ-Gebiete liegt und nicht an den PLZen der Gebäude.

(Die Grenzen der Ortsteile innerhalb einer größeren Stadt haben leider nur geringe Relevanz bzgl. der PLZ-Gebiete.)

Edbert (EvanE)

Klar. In Großstädten muss man in Übergangsbereichen eh immer Straße für Straße kontrollieren.
Auf addr:postcode verlasse ich mich dabei aber nie.

In Bonn waren es ca. 500 Abweichungen. In manchen Landgemeinden haben wir gleich mal um die 1000 falsche addr:postcode.
Ich gebe zu, ich bin etwas frustriert ob der vielen Fehler, die ich so sehe. Über falsche PLZ-Grenzen ärgere ich mich natürlich auch.

z.B.: “Im Schwanenstein” gehört postalisch zu Hirschberg, politisch zu Schriesheim. Die Gemeindegrenzen stimmen hier fast auf den Meter (Maps4BW/LGL).
Solche kleine Abweichungen von admin zu postal gibt es in der Prärie immer wieder, sind auch meist nur ein paar Häuser. Ohne addr:postcode wäre das nie aufgefallen.
Ich will auch nur sagen, dass beides seine Berechtigung hat. Nachsehen muss man trotzdem immer: Ich hatte auch schon genug Irrläufer durch Zahlendreher.

Ich kann das bei der DPAG nicht nachvollziehen. 69493 und 69198 gehören jeweils einheitlich zu einer Gemeinde.
“Im Schwanenstein” hat PLZ 69493 wie auch Hirschberg, zu dem es gehört. Ist addr:postcode also wieder falsch?

EDIT: Die Nachbarstraße “In den Langen” und seine Höfe liegen laut OSM auf dem Gebiet von Schriesheim. Das scheint falsch zu sein (trotz LGL-Info)!

Siehe auch: http://www.obsthof-volk.de/content/kontakt/index.php (Website zu einem Node dort)
Google zeigt die Grenze wie LGL.

gerade fertig geworden. Startzeit und damit Stand 16:00 Uhr.

als nächstes wird NRW kommen - wenn nicht einer einen besonderen Wunsch hat. NRW, RP, Saarland, Sachsen, und Sachsen-Anhalt sind im “Angebot” :wink:

Gruss
walter

NRW wird auch recht lange dauern. Denke, das wäre einer gute Aufgabe Deines Rechners für die Nacht.

EDIT: Typo

ist irgendwie merkwürdig. die haben alle vor 2-3 Tagen maximal 4 Stunden gebraucht. Kann aber sein, daß irgend ein Autovacuum-Worker die DB etwas belastet. Updates kommen auch viele rein. Der Lag beträgt derzeit 2 Stunden.

Zur Abwechslung mal ein Bundes-Ranking “buildings/ways with housenumber & postcode” (ohne nodes!):


 1. Hamburg (107.357)
 2. Dortmund (97.029)
 3. Köln (68.944)
 4. Frankfurt am Main (66.665)
 5. Bielefeld (58.786)
 6. Düsseldorf (48.724)
 7. Bremen (43.921)
 8. Berlin (43.040)
 9. Braunschweig (37.212)
10. Karlsruhe (37.014)

EDIT: Hamburg korrigiert (Doppelzählung)

Also ich bin da vorhin mal hingefahren. Die Lage ist im Grunde genommen tatsächlich so, wie sie vorher eingetragen ist. Postalisch läuft das Ganze unter Pönitz (bzw. Scharbeutz) gehört aber administrativ zu Süsel.

Ich habe noch eine Anwohnerin gefragt, wie sich das Ganze verhält und sie verdrehte nur die Augen und meinte, daß es kompliziert sei und kein Navi Ihre Adressen findet (siehe auch hier. Auch die Gemeinde Süsel schreibt mittlerweile bei der Ausgabe von Personalausweisen die Adresse als “23684 Pönitz/Scharbeutz” rein.

@Gehrke: Also bitte wieder die Admin-Grenze zurücksetzen.

Ich werde die Adressen dann mal auf “addr:city=Pönitz”, “addr:suburb=Broderdammskamp” und “addr:place=Ekelsdorf” setzen.

Christian