ich beneide euch ja dass ihr da die Datenbanken am Laufen habt, um die Doppelungen bei den Relationen zu finden. Soweit bin ich technisch halt noch nicht vorgedrungen …
Deshalb bleibt mir ja die (optische) Kontrolle der Relationen anhand deren PLZ über den Overpass-Turbo.
An Wambacher die Frage: wie oft wird die Textliste auf deiner Seite so aktualisiert? Kannst du da noch einen Zeitstempel mit darstellen?
Und du hattest die Liste doch auch mal in der Art erweitert, dass die ID der betroffenen Relationen hintereinander weg gelistet wurden, nur mit Komma getrennt, damit man die gut in JOSM über Shift-Strg-O reinladen kann.
Wäre das noch machbar?
Dank schonmal an alle für die Bemühungen beim Aufräumen!!
Stephan
EDIT:
Die Erweiterung der Liste mit den Relations-IDs braucht man vielleicht gar nicht, denn der Overpass-Turbo hat eine Export-Funktion, um die gefundenen Daten (hier also die “doppelten” Relationen) per Remote-Funktion (siehe JOSM-Einstellungen) direkt reinzuladen … sehr schön!!
Duplikat mit 77866 jetzt per “Objekt Laden” gefunden (s.o.). Hatte vorher nur in der Gegend von Rheinau (Baden) nachgesehen, war aber ganz woanders, da als rechtsrheinische Quasi-Exklave zu Rheinau/Rhinau (Elsass) gehörend. Falschen PLZ-Hinweis gelöscht, da Gebiet ohne Häuser.
So. Jetzt weiter nach Düsseldorf. Meine Recherchen haben ergeben, dass dort noch ganze 20 (!) PLZ-Gebiete fehlen.
Die Gewinnzahlen lauten: 40210, 40211, 40212, 40213, 40215, 40217, 40219, 40221, 40223, 40225, 40227, 40229, 40231, 40233, 40235, 40237, 40239, 40477, 40479, 40591 (ohne Gewähr).
Es wäre schön, wenn jemand die “Patenschaft” für einige wenige davon übernehmen könnte.
Wenn die Angabe noch stimmt, dass es in DE 8208 PLZ-Gebiete gibt, heißt das auch, dass noch mind. 10 falsche PLZs herumgeistern (obsolete_boundaries nicht mitgezählt).
Etwa 10 falsche hatte ich in den letzen Tagen schon gefunden und entfernt/entwidmet.
Ich hab mit den größten Querschläger mal näher angesehen: 67808 in groß
Es handelt sich um ein PLZ-Gebiet als MP-Relation mit fünf Outern (Gelb) und um neun Gemeindegrenzen ebenfalls mit postal_code=67808 (Violett, dick gestrichelt) Macht zusammen 10. Das ist ja ansich nicht “sooo schlimm”, da die PLZ-Relation ja sauber erscheint.
Mich stört nur, dass es bei den Gemeindegrenzen drunter und drüber geht. Einige sind deckungsgleich, einige fehlen und im Süd-Westen sind Gemeindegrenze und PLZ-Grenze nicht deckungsgleich. Letzteres ist sehr oft der Fall und absolut normal, da sich die Post nicht an Gemeindegrenzen halten muss, wird und kann. Das ist deren eigenes Reich und das teilen die nach ihren Bedürfnissen ein - und das ist gut so.
Aus diesem Grunde “beantrage” ich, daß alle PLZ-Informationen aus den Administrativen Grenzen entfernt werden, da sie teilweise falsch, nie statisch und eh unvollständig sind. Nach der Devise: “was nicht in OSM drin steht, ist nicht falsch und braucht auch nicht gepflegt werden”.
Gruss
walter
Gerade gesehen: im Nord-Westen ist Baierfeld-Steckweiler auch nur halb drin. Ob das postalisch richtig ist, kann ich nicht beurteilen ohne auf die PLZ-Karte der Post zu schielen. Auf jeden Fall sind dort in OSM PLZ-Grenze und Gemeindegrenze auch nicht identisch.
Ja das ist schon ein PLZ-Monster. Im Allgemeinen fällt auf, dass Rheinland-Pfalz eine sehr “ungewöhliche” PLZ-Struktur hat: Modell zerfetzter Flickenteppich.
Ein Blick auf die PLZ-Karte der Post wird Dir hier leider auch nicht viel weiterhelfen. Dass Bayerfeld-Steckweiler nur “halb drin” ist, geht auf mich zurück. Man muss sich alle Adressen anschauen, um eine geeignte Grenzen zu ziehen.
Die Post selbst kriegt das nicht immer so gut hin. Letzlich gibt es ja, Du weißt das natürlich, auch keine “echten” PLZ-Gebiete als definierte Flächen, sondern nur Punkte mit Adressen.
Die Devise für die deshalb künstlichen Flächen sollte nach meiner Meinung sein: Wenn dort ein Haus stünde, welche PLZ hätte es dann. Klar: Das ist zu einem gewissen Maß Spekulation. Aber wenn die Realität etwas anderes hervorbringt, wird es in OSM halt angepasst.
Ich habe die Information an den Gemeindegrenzen postal_code in postcode geändert.
Wir haben hier auch Verwaltungsgemeinschaften mit mehreren PLZ - postcode=01738;01774;01762. Ab 2014 wird Schmiedeberg (01762) zu Dippoldiswalde (01744) gehören und auch die PLZ-Grenze auf 01744 verändert.
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.
