Pflege der deutschen PLZ-Daten in OSM

Ich kenne diesen Beitrag: Man hätte auch 7 oder 9 nehmen können, die 8 passt als Richtschnur halt am ehesten.

Ob es sich wirklich gelohnt hat, den (identischen) postal_code_level an jede der 8000 Relationen zu hängen, sei dahingestellt - ein Eintrag im Wiki über die PLZ in Deutschland hätte vielleicht auch gereicht. Aber gemessen an addr:country=DE an Millionen von Gebäuden sind das ja nur Peanuts.

Keine Frage: Die Querverbindung PLZ zu admin ist nicht notwendig. Ob ein zusätzlicher Hinweis per 7,8,9 irgendwo von Vorteil ist, kann ich nicht absehen. Genau so habe ich aber auch meine Zweifel, dass der postal_code_level in der jetzigen Form je von irgend jemand notwendig gebraucht wird.

Das ist vor allem für den Vergleich internationaler Postleitzahlsysteme untereinander sinnvoll. Da gilt halt “andere Länder, andere Systeme”. Von daher ist es durchaus sinnvoll den postal_code_level in einem Land einheitlich zu haben.

Edbert (EvanE)

Nach einer Feiertagspause auch mein Kommentar zum Thema postal_code_level != 8:

Eine Zahl-Semantik bzgl. der Verwebung oder Überlappung mit Gemeindegrenzen halte ich für nicht sinnvoll. Beide Grenzen sind ja quasi unabhängig. Daher ergibt das wenig Sinn. Die Beziehung zu admin-Grenzen ergibt sich aus der räumlichen Überlappung.

Ob wir jemals Relationen für Postleitregionen oder -zonen haben werden, weiß ich auch nicht. Wenn dann wohl eher über Relationen mit parts/subareas.

Was ich mir auch vorstellen könnte, sind viell. postal_code-boundaries mit level < 8. Damit könnte man das System der Post besser abbilden. Ortseinträge im Postsystem (Gemeinde, Ortsteil, Hof etc.) könnten dann mit einer eigenen Relation und dem “echten” Namen der Post für dieses Gebiet dargestellt werden.

Wäre es nicht toll, dieses PLZ-Projekt auch in einem iotw darzustellen?
Bild-Vorschläge könnt Ihr hier: http://wiki.openstreetmap.org/wiki/Featured_image_proposals posten.

naja, ich weiss nicht so: “mein” PLZ-Bild war ja sehr nützlich als noch nicht alle administrativen PLZ-Gebiete auf “richtige” PLZ-Gebiete umgestellt waren. Aber jetzt ist es doch einfach nur eine komplette (ich hoffe wenigstens) gelb eingefärbte Deutschlandkarte, die nicht allzuviel hermacht.

ok, wer will, findet die Images ja hier im Thread.

Gruss
walter

Habe im Wiki-Artikel unten eine Übersichtskarte (inkl. PLZ-Regionen und -Zonen) verlinkt. Wäre die interessant?

Gefällt mir.

Alternativ könnte man vielleicht auch eine vorher/nachher-Karte nehmen.

Bittschön:

Die älteste Grafik, die ich noch finden konnte:

https://wiki.openstreetmap.org/wiki/File:Plz-statistik-brd.png vom 1.12.

und der Stand beim Abschluß:

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz-lage20131221.png

Gruss
walter

Habe eine Gegenüberstellung erstellt und als iotw vorgeschlagen:
https://wiki.openstreetmap.org/wiki/Featured_image_proposals#consolidation-project_of_the_German_postal_code.3D.2A-relations
Änderungen/Verbesserungen sind natürlich willkommen.

Wobei da leider nicht so richtig rüberkommt, dass es am Anfang (Oktober) ja viele weiße Flächen ohne jegliche PLZ-Zuordnung gab (u.a. in Hamburg, Hannover, Düsseldorf, Magdeburg). Darüber hinaus gab es auch falsche PLZs.
Ich hätte da viell. noch alte Vergleichsdaten, müsste die aber sehr aufwendig zusammensuchen und aufbereiten.

Wir wollten ja eigentlich type=boundary für unsere postal_code-Relation durchsetzen. Da hat sich einiges getan, aber es gibt noch viele multipolygon-Relationen. Hier mal eine Übersicht für die Postleitzonen (stand 31.12.2013):


Zone;Anzahl multipolygon
0;338
1;144
2;77
3;190
4;100
5;399
6;451
7;182
8;728
9;928

Apropos, wir haben in Deutschland inzwischen nur noch 128 Gemeinden, die nicht als boundary, sondern als multipolygon getypt sind. All diese Gemeinden befinden sich übrigens in Schleswig-Holstein (Reg-Code 0105*).

Bislang ist der tag boundary=postal_code im Wiki nicht so richtig dokumentiert. Das sollte aber unbedingt geschehen, mindestens hier. Eine deutsche Dokumentation wäre natürlich auch schön.
Ich habe die Seite bereits erstellt, aber ein bischen mehr Inhalt wäre doch schön. Wer macht das?

Danke. Habe ein paar kleinere Anpassungen gemacht.

Du hast jetzt *onArea * auf no gesetzt, was ich eigentlich auch richtig finde, aber wo kommen dann die 3664 Wege mit boundary=postal_code her?

Ups. Ja, da war ich etwas voreilig. Die Beschreibung bezog sich nur auf die Grenzrelationen. Wie bei boundary=administrative auf ways für die Grenzwege gibt es das natürlich auch bei postal_code, wenn es keine Übereinstimmung mit einer admin-Grenze gibt.

hi, bei Stade ist noch ein größeres PLZ-Loch. da hat mal wieder jemand dran rumgeschraubt. Das andere Loch bei Salzgitter hab ich gefixt.

Gruss
walter

Sollte jetzt gefixt sein.

danke, dauert noch ein wenig, bis der Server das anzeigt.

Das andere Loch war echt heftig. 2 Stunden Arbeit zum Fixen. Newbie, seit 23.12.2013 dabei, hat mal eben ein paar Grenzen reingezogen. An Grenzpolygone hab ich mich erst nach ca 1 Jahr OSM rangetraut. Nun denn, zumindest schafft er mit josm.

Gruss
walter

kreativ ist er auch noch: Schnappt sich die Residential seine Dörfer, macht jeweils eine AL-10 Boundary-Rel draus (1 Member!) und hat damit seine AL10-Grenzen fertig. Toll.

Detailinfo am Rande: Die Gemeinde Schmiedeberg (PLZ bisher 01762) wurde in die Gemeinde Dippoldswalde (PLZ 01744) eingemeindet. Dabei wurde offenbar auch die PLZ Schmiedebergs auf 01744 geändert. Die Dt. Post weiß auf ihrer Website davon allerdings nichts. Dennoch ist diese Info wohl zuverlässig (lokale Quelle: geri-oc) und so bereits auch in Wikipedia eingetragen.

Fazit: Die Post aktualisiert ihrer Online-Datenbank erst mit Ausgabe der Mitteilungsblätter jedes Quartal. Bis dahin können die dort angefragten Daten wohl auch falsch/veraltet sein!

wer ändert bei uns und wann?

Wenn sich die von uns angenommene Anzahl der PLZ in D (8201) ändert, würde ich das gerne mitbekommen. sonst schreie ich immer und suche verzweifelt das “Problem”.
Am Jahresanfang hatten wir wieder “nur” 8200. War in Kiel, lag genau an der Küste und somit in meiner QGIS-Auswertung nicht so leicht auffindbar :frowning: Muß ich mal verbessern.

gruss
walter