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