Status quo der PLZ in OSM (10.11.2013, ca. 21:00 Uhr):
Es gibt 6123 dedizierte postal_code-Relationen. Eine ist nicht eineindeutig (PLZ: 16835)
Es gibt für davon nicht erfasste PLZ 1077 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1006 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.
Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8205 PLZ erfasst. Fehlen noch 3 PLZ (wenn denn keine falschen dabei wären!).
Lücken bestehen noch in Düsseldorf. Dort fehlen 18 PLZ-Gebiete: 40210, 40211, 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239, 40591.
Nur zur Sicherheit: Das ist mE in Ordnung, wenn es gleichzeitig eine postal_code-Relation gibt. Wenn die aber fehlt, die PLZ also nur in der admin_relation festgehalten wurde, sollte man den Schlüssel postal_code beibehalten.
Übrigens: Ich habe in DE keine obsolete_boundary mit postal_code mehr gefunden. Bei den von mir umbenannten Relationen habe ich das schon vor längerer Zeit hinausgeworfen, gerade um solche Auswertungen wie hier nicht zu irritieren.
Im offiziellen Gemeindeverzeichnis von DESTATIS ist ja genau eine PLZ für jede Gemeinde angegeben.
Dies ist die PLZ des Verwaltungssitzes und könnte auch in OSM eingepflegt werden - ggf. mit speziellem tag wie z.B. “admin_postcode” o.s.ä.
Ich finde, “is_in_postal_code” bzw. “postcode” statt “postal_code” verführt eher zu Fehlern, da die Abgrenzung nicht klar erkennbar ist.
Das könnte bei größeren Städten auch zu Missverständnissen führen. Da gehören zu einer admin-Relation mehrere Postleitzahlen. Wenn, dann nicht an die Relation, sondern an das admin_centre (so vorhanden).
“is_in_postal_code” bzw. “postcode” sollen “postal_code”-Dubletten verhindern und haben nur noch informellen Charakter. Sie sind eigentlich nicht notwendig, da redundant zur post_code-Relation. Das ist aber beileibe nicht die einzige Stelle in OSM, wo Daten nicht nur dort eingetragen werden, wo sie erforderlich sind, sondern auch da, wo sie vielleicht mal interessieren.
Wo ist das Missverständnis? Es gibt nur einen “admin_postcode” (siehe DESTATIS). Daher ja nicht “postal_code”, “postcode” usvwm. Man müssten den tag natürlich dokumentieren…
“Nur informeller Charakter”? Das überzeugt mich nicht und ist noch viel missverständlicher.
Sehe ich ja auch so. Daher plädiere ich für PLZ-Karten für eine Filterung nach postal_code_level=8 (zumindest bei admin-Relationen).
Den Schlüssel postal_code_level habe ich nur in http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 gefunden mit dem Hinweis, dass der nur für internationale Einordnung gewünscht werde und in DE immer auf 8 stehen solle. Als Filter taugt das in DE also nicht. Falls es andere Verwendungen von postal_code_level geben sollte, sind sie zumindest nicht gut dokumentiert.
Als Filter taugt es deshalb, weil es gerade nicht bei jeder Gemeinde gesetzt ist (insb. wenn diese schon durch eine postal_code-Relation abgedeckt wird).
In der Tat kann das aber nur ein temporäres Hilfsmittel sein. Langfristig brauchen wir eine komplette Abdeckung mit boundary=postal_code.
Wir können uns nicht darauf verlassen, dass es keine “falsche” Relation mit “postal_code” tag gibt.
Die internationale Einordnung (im anderen Sinne) ist übrigens auch noch ein unschönes Thema: Wie erkennt man anhand der Daten eine deutsche (bzw. österreichische etc.) PLZ? Bisher gar nicht.
Man muss schon ein spatial query machen, was ja im Zweifel weniger intuitiv ist als direkt die Daten zu fragen (zumindest sind die geoms aber indiziert).
Ein tag zur “postal_authority” oder einfach nur etwas Ähnliches wie “addr:country” oder “is_in:country” könnte da helfen.
Ich bin auch der Meinung, dass es in Gemeinden kein tag “postal_code” geben sollte, sobald es eine passende Relation mit “boundary=postal_code” gibt.
Bei anderen (Multi-)Polygonen (z.B. “landuse=residential”) sollte es die Auswertung aber nicht stören.
Dann schreibe aber bitte nicht auch der Meinung, da genau hier der Unterschied zwischen unseren Auffassungen liegt.
Ich bin für ein generelles Bereinigung der Gemeinde-Relationen, auch wenn es noch keine eigene PLZ-Relation gibt.
Rel duplizieren, jeweils die unpassenden Werte raus, Ruhe ist - und zwar für immer, da Gebietsreformen und PLZ-Änderungen total entkoppelt sind. So, als ob wir 2 verschiedene Layer in der DB hätten.
Einen Hinweis, welche Postleitzahlen für eine Gemeinde gelten, halte ich schon für sinnvoll. Allerdings sollte das nicht dazu führen, dass es Dubletten gibt.
Von daher halte ich einen Schlüssel is_in_postal_code durchaus für sinnvoll. Der Schlüssel postcode sollte für diesen Zweck jedoch nicht verwendet werden, da er zu leicht verwechselt wird oder gar in guter Absicht wieder zu postal_code geändert wird.
Um allen Verwechselungen aus dem Weg zu gehen, schlage ich FYI_postal_code (For Your Information / Deutsch: Zu ihrer Information) als (international verständlichen) Schlüssel für diesen Zweck vor. (Wegen bekannter Abkürzung ausnahmsweise Großbuchstaben im Schlüssel).
Als Wert für FYI_postal_code ist eine Liste (mit ‘;’ getrennt) von Postleitzahlen zugelassen.
Dass es keine zwei postal_code-Einträge für das selbe Gebiet geben sollte, darin sind wir uns einig.
Ein Eintrag mit postal_code_level in der admin-Relation als Hinweis darauf, dass es hier keine PLZ-Relation gibt - damit kann ich leben, auch wenn ich bezweifle, dass das außer von ein paar Spezialisten beachtet wird.
Das langfristige Ziel, alles per boundary=postal_code abzudecken, sehe ich nicht so zwingend. Bei uns in der Gegend stimmen in 90% der Gemeinden PLZ und Gemeindegrenze überein und da wird sich die nächsten 20 Jahre vermutlich auch nichts ändern. In den größeren Städten gibt es mehrere PLZ-Gebiete, eines ist sogar Landkreis-übergreifend und ein paar wenige Gemeinden sind in einem PLZ-Gebiet zusammengefasst.
Da ist das Anlegen einer Relation, um einen Eintrag in der admin-Relation zu ersetzen, mMn überflüssig (schadet aber auch nicht).
Aber in anderen Gegenden (Streusiedlungen, andere Kommunalstruktur) mag das anders aussehen.
Wie wäre es, wenn man für rein informelle Einträge (FYI) nicht neue Schlüssel erfindet, sondern schlicht “note=postcode(PLZ) yxz” (o.ä.) verwendet? Das kann jeder lesen, verstehen und es stört (hoffentlich) nirgends.
Schlecht, da note=* für Hinweise an andere Mapper gedacht ist und nicht, um darin Informationen zum Objekt unterzubringen. Weiter erscheinen Objekte mit note=* im FIXME-Layer vieler Garmin-Karten und sind dort nur als Notiz an andere Mapper erwünscht.
Hier geht es um eine gezielte Information (die Postleitzahlen) zu einem Objekt (administrative Grenze). Das verdient nach meiner Meinung durchaus einen eigenen Schlüssel.
Da gibt es dann ein schlechtes Vorbild: In fast jeder post_code-Relation gibt es ein note= , vermutlich damit der Name irgendwo in der Relation auftaucht. Müssten die dann folglich alle raus?
Die “note” in den PLZ-Relationen finde ich auch nicht so glücklich. Einige hatten ja “description” vorgeschlagen. “name” fände ich am besten, aber das wird ja auch immer gezeichnet. "label " fände ich auch gut.
Das ist der Punkt, weswegen ich auf das Problem aufmerksam wurde.
Ein note=* wird als Benennung in der Relationen-Liste von JOSM verwendet. Aus diesem Grund hat man diese Methode für die PLZ-Relationen vorgeschlagen. Wirklich zufrieden damit ist kaum einer, aber es hilft halt die Relationen auseinander zu halten, ohne das Name-Tagg mit seinen unerwünschten Auswirkung beim Rendern von Boundary-Relationen dafür zu benutzen.
Ich denke, das die Mapper gerne eine andere Lösung für eine sinnvolle Anzeige in der Relationsliste verwenden würden, wenn es sie denn gäbe.
Aber bei administrativen Relationen haben wir ja in der Regel Namen, so dass dies kein Grund wäre.
Das war wohl meine Idee - Shame on me
Historie: Am Anfang (2011?) stand da name=Stadt, dann name=PLZ Stadt und daraus wurde dann note= PLZ Stadt, damit es auf der Mapnik-Karte nicht stört aber dennoch (im Josm) zu identifizieren ist.
Nun stört note auch - könnte man description nehmen? Weil irgend eine Bezeichnung muß das Teil ja behalten.
