Uii, hab gerade mal eine zu triviale Query über die PLZ-Daten gefahren und siehe da: 8227 Treffer! Hab aus Versehen die “normalen” Polygone mit ausgewertet.
Die Wege des Mappers sind undurchschaubar: http://www.openstreetmap.org/browse/way/221076401/history insgesamt 24x (Ich hab die bereits bereinigt)
macht netto 8203 - immer noch 2 zuviel?
Gruss
walter
Man kann sich in OSM auf nichts verlassen. Ich werde weiter immer nur Relationen mit “boundary=postal_code” herausfiltern. Welche 2 Elemente sind denn übrig?
hab sie gerade gefunden:
....
1159776 | 99996
1159783 | 99998
943740 |
3351884 |
(8203 rows)
Zwei Boundaries mal OHNE PLZ. Werd ich jetzt erledigen.
Zur Erklärung dieser unerwarteten Treffer: Ich hab bisher sehr explizit auf PLZ (genau 5 Zeichen und nur Relationen) abgefragt und dabei sind mir einige durch die Lappen gegangen. Jetzt hab ich eine ganz banale Abfrage ohne diese Einschränkungen gemacht - halt so einfach, dass sie jeder leicht und sicher verwenden kann. Und jetzt tauchen die Irrläufer halt auf.
Gruss
walter
done
943740 war als boundary=postal_code getaggt und ist jetzt korrekt boundary=administrative user:wambacher 
3351884 ist ein Problem mit den Rohdaten oder mit meiner Datenbank. Das ist eine TMC-Area in Leipzig, die bei mir aus bisher ungeklärten Gründen als plz-Boundary ankommt. Sehr misteriös.
Nachtrag: Bei der TMC-Area hatten die Ways boundary=postal_code ! Der Tag ist dann durch osm2pgsql an die Relation “gewandert”. Toll.
also sind wir wieder im Grünen Bereich 
Walter, den Treffer 3351884 verstehe ich jetzt nicht.
hab es gerade geändert. z.B. http://www.openstreetmap.org/way/87544901/history als member der TMC-Area
Puh, das Teil hat mich schon länger geärgert.
Gruss
walter
id | postal_code
----------+-------------
1306692 | 01067
1306695 | 01069
...
1159779 | 99994
1159776 | 99996
1159783 | 99998
(8201 rows)
Mal eine weitere Konsistenzprüfung: Welche PLZ in addr:postcode (ways, nodes) sind eigentlich nicht durch das postal_code der boundaries abgedeckt.
Ergebnis: 690 verschiedene PLZ alleine für ways.
Erklärung: Oft handelt es sich wohl um Postfach-PLZ. Ob das so i.O. weiß ich nicht. Da es ja keine physischen Hausadressen sind, ist das nicht richtig, oder?
Manche sind auch Großempfänger-PLZ, z.B. PLZ 51368 für Bayer AG in Leverkusen. Was ist mit denen?
Moin,
das ist ja quasi logisch bei Amtsverwaltung - das ist ja Sinn der Sache, die Verwaltung zusammenzufassen.
Ich frage mich auch, was admin_centre:postcode überhaupt bezwecken soll.
ohne :street und :city ist das ja nahezu sinnlos.
Und mit hat das schon wieder Nachschlagewerk-Charakter.
Da hilft es auch nicht, wenn Gemeinde und Sitz der Verwaltung die gleiche PLZ haben …
Wenn jetzt noch bei unserer Gemeinde als admin_centre der Sitz der Amtsverwaltung eingetragen wird und dann das label (Gemeindename) beim admin_centre gerendert wird, ist das Chaos nahezu perfekt.
Gruß
Georg
Edit: Rechtschreibfehler zu spät entdeckt
Die Frage ist durchaus legitim. Es steht ja auch noch im Raum, das komplett wegzulassen. Deswegen habe ich auch das Ämter-Beispiel aufgeführt.
Gestern war (endlich wieder) so ein Tag.
und jetzt bitte noch irgendein neues projekt, macht auch vielmehr spaß für sowas zu mappen, “mappen im auftrag”.
bzgl. “name|description → note” sollte ich jetzt alle fertig haben
Hab mal eine aktuelle Liste erstellt. Sieht ganz gut aus
EDIT: Habe nach einigen kleineren Korrekturen Liste nochmals aktualisiert.
2.EDIT: und nochmals: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/alle_plz_20131224-2.txt
so, jetzt zünde ich mal den Weihnachtsbaum an - und wenn die Feuerwehr wieder weg ist, mach ich eventuell noch etwas weiter.
Gruss
walter
Da sich die Schreibweise note= in PLZ-Relationen per dookratischer Abstimmung in D durchgesetzt hat, habe ich die redundanten (experimentellen) Tags mit identifier= entfernt.
Beim weiteren Aufräumen von is_in_postal_code zu admin_centre:postal_code ist mir der Gedanke gekommen, die Information “dieses PLZ-Gebiet umfasst mehrere Gemeinden” in einem Tag postal_code_level=7 unterzubringen.
Das Entsprechende könnte man bei Kommunen machen, die in mehrere PLZ-Gebiete aufgeteilt wurden (postal_code_level=9).
Damit könnten die in D sonst ziemlich informationsarmen postal_code_level eine sinnvolle Zusatzaufgabe erfüllen.
Der internationalen Bedeutung (bisher einziger Daseinszweck) als Detaillierungshinweis des nationalen Systems würde das mMn nicht zuwiderlaufen, da das ziemlich gleich wie die admin_level 7,8,9 zu sehen ist.
Die Leitzonen, wenn das je mal erfasst werden sollte, würden nicht kollidieren, da diese dann eher unter postal_code_level=5 oder 6 laufen würden.
irgendwie hab ich da ein ungutes Gefühl (falls ich dich richtig verstanden habe). Werden da nicht wieder durch die “Hintertür” administrative Informationen in die PLZ-Grenzen reingeschmuggelt? Die haben wir doch erst so mühsam entkoppelt.
Was haben wir denn?
1: PLZ gilt exakt für genau eine einzige Gemeinde (PLZ-Grenze und Admin-Grenze sind deckungsgleich)
2: PLZ gilt für ein Teilstück einer Stadt
3: PLZ-Gebiet enthält exakt mehrere Gemeinden (PLZ-Grenze ist sozusagen “outer” der Gemeinden)
4: PLZ-Gebiet enthält nicht alles einer Gemeinde (Rest beim “Nachbarn”)
5: PLZ-Gebiet enthält Gemeinden und Teile vom Nachbarn.
x: ???
Das nur mit postal_code_level in der PLZ-Relation ausdrücken zu wollen, fällt mir bei 4&5 ff schwer.
Ich würde davon Abstand nehmen.
Rein theoretisch könnte man zusätzlich zu den bestehenden PLZ-Grenzen mit postal_code_level=8 solche mit PCL=7 und PCL=9 einführen und die den enthalteten Gemeinden zuordnen.
Sorry, das tu ich mir nicht an. Bin froh, dass die letzte Aktion fast erledigt ist.
Gruß
walter
Die Level 7 und 9 habe ich nur in Analogie zu admin vorgeschlagen: 8+ bei Fall 2, 8- bei Fall 3 und 5 (mehrere Gemeinden).
Das soll nur ein Hinweis sein, der Einstufungen unterstützt, ohne Anspruch auf Vollständigkeit. Den Fall 4 und alle sonstigen Zweifelsfälle würde ich bei level=8 belassen.
Momentan sieht man die Fälle 2 und 3 nur, wenn man die admin- und PLZ-Nachbarrelationen abklappert oder in einer Liste wie hier weiter vorn im Thread nachsieht. Das muss nicht notwendig in der OSM-DB landen, nur ist hier der (Speicher-)Aufwand minimal, da ein überall vorhandenes, aber kaum genutztes Tag (postal_code_level) mit verwendet wird.
Ich wäre vorsichtig damit in postal_code_level etwas anderes als die Acht einzutragen. In Postleitzahlen Deutschland 2010 steht folgendes:
Das sollte man nicht ohne weitreichende Diskussion (das Forum reicht nicht aus) ändern.
Edbert (EvanE)
Hi Edbert,
ich zumindest möchte auch nichts an der bestehenden Struktur ändern. Meine 5 Punkte sollen nur zeigen, daß man das garnicht sauber hinkriegen würde, selbst wenn man “dürfte”.
Ein irgendwie gearteter Mix zwischen Gemeindegrenzen und PLZ-Grenzen ist wohl nicht sauber hinzubekommen. Des weiteren bezweifle ich, daß genau dieser Wunsch auf Talk so geäußert wurde (seichter: bitte link nennen).
Mir reicht es auf jeden Fall, daß ich in Deutschland für jeden Punkt genau feststellen kann, in welcher Gemeinde und in welchem PLZ-Gebiet er liegt - und das völlig unabhängig voneinander. Eine Querverbindung dazwischen brauch ich eigentlich nicht.
Gruss
walter
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.