Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

Ich finde, das kann man ziemlich eindeutig machen:

  • Wenn Gemeinde und PLZ-Gebiet übereinstimmen (sehr häufig), reicht es, die PLZ der admin-Relation hinzuzufügen. Eine eigene PLZ-Relation ist entbehrlich, aber nicht verboten.

  • Wenn ein admin-Gebiet (Stadt) in mehrere PLZ-Gebiete aufgeteilt ist oder wenn ein PLZ-Gebiet über admin-Grenzen hinausgeht, braucht man PLZ-Relationen. Die können dann Linienzüge (ways) der admin-Grenzen mitverwenden.
    Wenn mehrere Gemeinden die gleiche PLZ haben, ist deren Außengrenze zugleich die Grenze des PLZ-Gebietes. Diese enthält also nur admin-ways.
    Es gibt aber auch PLZ-Gebiete (z.B. in interkommunalen Gewerbegebieten), die sogar Teil von zwei Landkreisen sind und keine Grenzen mit admin-Gebieten gemeinsam haben. Diese PLZ-Relationen enthalten folglich gar keine admin-ways.

Mein Vorschlag ist und bleibt: PLZ-Relationen sind als selbstständige Grenzrelationen unabhängig von eventuell identischen Gemeindegrenzen zu erfassen.

Es gibt zwar nicht wenige Gemeinden, wo beide Grenzen zur Zeit identisch sind - das kann und wird sich aber jederzeit ändern. Entweder ändern sich die Administrativen Grenzen wegen Gebietsänderungen oder die Post baut was um. In beiden Fällen gibt es nur Probleme in den OSM-Daten, weil dann “plötzlich und unerwartet” ehemals deckungsgleiche Gebiete unterschiedlich werden.

Je sauberer und konsequenter die Trennung ist, umso einfacher wird es für alle:

  • Für die “Grenz-Mapper” bei Änderungen der Administrativen Grenzen.
  • Für “PLZ-Mapper” bei Änderungen der PLZ-Gebiete.
  • Für Kartenersteller und Auswerter, da nicht 3 (drei) Möglichkeiten bedacht werden müssen.

Weiterhin wären solche Konstrukte wie “mehrere Gemeinden haben eine gemeinsame PLZ” nicht notwendig.

Gruss
walter

p.s. Meine PLZ-Karte klemmt immer noch - der Update ist zäh und hinkt mächtig hinterher . Ausserdem hat der Upgrade auf Ubuntu 13.10 meine iptables-Konfiguration zerschossen, sodaß der Server eh nicht erreichbar ist.

Wie sagt man so schön: “Erst hatten wir kein Glück und dann kam auch noch Pech dazu”

Ich hoffe, damit sind nur dedizierte Relationen gemeint. Wo identisch, müssen die Grenzwege gemeinsam verwendet werden. Das ist der beste Weg um adjazente Regionen zu erkennen.

Oft fällt ja beides zusammen - wenn auch verzögert. Fusionierte Gemeinden, die vorher eigene PLZ hatten, bekommen teils bald danach eine gemeinsame.
Es müssen also eh oft Änderungen gemacht werden. Wo ist das Problem, wenn etwas, dass mal deckungsgleich war, es nicht mehr ist? Die Welt ändert sich. OSM passt sich an.

Sauber soll es sein - keine Frage. “Reine” Admin-Grenzmapper, wenn es so etwas gibt, sollten sich aber bei Grenzänderungen eh Gedanken um Auswirkungen auf andere Grenzen machen.
PLZ-Mapper sind immer mit beiden konfrontiert: Admin-Grenzen und postalischen.
Kartenersteller und Auswerter für PLZ müssen, nach meiner Ansicht folgendes extrahieren: Alle postal_code-Grenzen und alle admin-Grenzen die mit postal_code_level=8 getaggt sind. Klingt für mich recht einfach. Eventuell reicht bald auch nur postal_code_level=8.

Die Einschränkung auf postal_code_level=8 ist auch robuster. Es kann doch nicht sein, dass das PLZ-Gebilde zusammenbricht, wenn mal einer voreilig eine PLZ an der Gemeinde annotiert.

Status quo der PLZ in OSM (08.11.2013, ca. 21:00 Uhr):
Es gibt 6111 dedizierte postal_code-Relationen. Eine ist nicht eineindeutig (PLZ: 16835)
Es gibt für davon nicht erfasste PLZ 1078 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1013 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.
Davon sind 5 PLZ nicht eindeutig (je 2 Gemeinden mit gleicher PLZ: 53567, 53572, 74426, 77709, 77866).

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8196 PLZ erfasst. Fehlen noch 12 PLZ (wenn keine falschen dabei sind).

Nachdem vor einigen Tagen die auf osm2pgsql basierend PLZ-Karte Version 3.0 live gegangen ist, hab ich über die neue DB (auf den mehrfachen Wunsch eines einzelnen Mappers ;)) eine Abfrage laufen lassen, die hier schon mal für die alte DB gepostet wurde:


select * 
  from 
       ( SELECT count(postal_code) count,
                postal_code
           FROM planet_osm_polygon
          WHERE osm_id < 0
            AND boundary in ('administrative','postal_code')  
            AND postal_code != ''
            AND st_intersects(way,(select way from planet_osm_polygon where osm_id in(-51477)))
          group by postal_code
          order by count(postal_code) desc, postal_code 
       ) foo
 where count > 1

Resultat: Liste aller PLZ, die in mehr als einer Grenzrelation erscheinen.


count | postal_code 
-------+-------------
    10 | 67808
     8 | 67822
     7 | 07980
     6 | 79692
     5 | 49163
     5 | 49762
     5 | 55599
     4 | 09526
...
     2 | 97786
     2 | 97901
     2 | 99441
     2 | 99510
     2 | 99897
(356 rows)

Komplette Liste unter http://osm.wno-edv-service.de/DataServer/osm/forum/doppelte_plz.txt

gruss
walter

ps: An alle osm2pgsql-Anwender. In der Abfrage postal_code durch tags->‘postal_code’ ersetzen und dann sollte die auch bei euch laufen.

Auf die Gefahr hin, mich zu wiederholen ;): Ich habe damit kein Problem. Für PLZ 67808, 67822 usf. gibt es ja eine dedizierte postal_code-Relation (auch mit entsprechendem postal_code_level).
Für mich “überschreibt” das dann alle anderen Relationen mit gleicher PLZ. Nach meiner Auswertungsmethode und Zählung bleiben nur 5 “doppelte” PLZ übrig (siehe oben). Vor einigen Wochen waren das noch fast 50.

Nach einer kurzen Überprüfung in “meiner” Gegend sind da “false alarms” dabei, und zwar wenn eine Gemeinde/PLZ-Gebiet Exklaven hat. Das wird dann als 2 gezählt.
Korrigiere: Das ist nicht der Grund für count=2, sondern Eintrag in boundary=administrative & boundary=postal_code wie unten.

An anderen Stellen wird es als 2 gezählt, wenn bei Übereinstimmung postal_code sowohl in admin-Grenze als auch in PLZ-Relation auftaucht. Diese Doppelzählung ist an einigen Stellen dadurch beseitigt worden, dass der postal_code-Eintrag aus der PLZ-Relation entfernt wurde
(mit note=old postal_code border). Da könnte man mMn die PLZ-Relation dann auch gleich ganz löschen, da obsolet.
Alternative wäre das Löschen/Umbenennen des PLZ-Eintrags in admin-Relation, wenn der postal_code=xxxxx nur einmal auftauchen soll.

Den count=2 gibt es auch, wenn zwei Gemeinden in einem PLZ-Gebiet liegen.
Da wäre mein Vorschlag, bei den Gemeinden, wenn man denn die Zugehörigkeit zur PLZ auch in der admin-Relation haben möchte, das mit “is_in_postal_code” aufzuführen. Dann sieht man auch sofort, dass die zugehörige PLZ-Relation noch mehr umfasst.
Dasselbe könnte man auch erreichen, wenn schon ein is_in-Eintrag vorhanden ist. Da macht dann ein weiterer komma-separierter Eintrag mit PLZ den Kohl auch nicht mehr fett.

Status quo der PLZ in OSM (09.11.2013, ca. 21:00 Uhr):
Es gibt 6113 dedizierte postal_code-Relationen. Eine ist nicht eineindeutig (PLZ: 16835)
Es gibt für davon nicht erfasste PLZ 1078 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1013 Gemeinden, die einen postal_code-Tag haben, für die aber keine PLZ-Relation gegeben und kein postal_code_level getaggt sind.
Davon sind 5 PLZ nicht eindeutig (je 2 Gemeinden mit gleicher PLZ: 53567, 53572, 74426, 77709, 77866).

Laut Post gibt es in DE 8208 Zustellgebiete.
Insgesamt sind 8198 PLZ erfasst. Fehlen noch 10 PLZ (wenn keine falschen dabei sind).
Die Lücken sind zu finden in Düsseldorf (Süd) und Hamburg (Ost)

74426, 77709 sind erledigt, 77866 habe ich nur einmal (auch mit Nominatim) in DE gefunden.


planet2=# select osm_id,tags from planet_osm_polygon where postal_code='77866';

 -1085763 | "name"=>"Rheinau, gemeindefreies Gebiet", "osm_uid"=>"399898", "boundary"=>"administrative", "osm_user"=>"hhh_thanatos", "way_area"=>"0.00120577", "wikipedia"=>"de:Rheinau (gemeindefreies Gebiet)", "admin_level"=>"8", "osm_version"=>"11", "postal_code"=>"77866", "osm_timestamp"=>"2013-09-11T09:06:38Z", "de:regionalschluessel"=>"083179971971", "de:amtlicher_gemeindeschluessel"=>"08317971"
  -452971 | "name"=>"Rheinau", "osm_uid"=>"399898", "boundary"=>"administrative", "osm_user"=>"hhh_thanatos", "way_area"=>"0.00889395", "wikipedia"=>"de:Rheinau (Baden)", "admin_level"=>"8", "osm_version"=>"17", "postal_code"=>"77866", "osm_timestamp"=>"2013-09-11T09:09:24Z", "de:regionalschluessel"=>"083170153153", "TMC:cid_58:tabcd_1:Class"=>"Area", "TMC:cid_58:tabcd_1:LCLversion"=>"9.00", "TMC:cid_58:tabcd_1:LocationCode"=>"3118", "de:amtlicher_gemeindeschluessel"=>"08317153"

Gruss
walter

53567 und 53572 sind auch erledigt.

Hallo Gehrke, seichter und Wambacher,

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.

Deswegen auch nochmal der Hinweis auf http://wiki.openstreetmap.org/wiki/Overpass_turbo/Examples/Postal_Codes_Quality_Assurance

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!!

Habe, soweit ich das gerade überblicke, die PLZs für Hamburg soeben komplettiert.
Details älterer Grenzen dort sind jedoch noch fehlerhaft.

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 widme mich mal den PLZs 40477 und 40479. Das wird aber heute wohl nichts mehr.

EDIT: Wird doch 'was. Sind beide gerade fertig. Morgen schnappe ich mir noch 40211.

Hab ich gerade ersetzt. Timestamp ca 20:15 heute. Nach der Auflistung der Dubletten schau ich mal. Sollte eigentlich 'ne einmalige Sache sein, aber …

Gruss
walter

EDIT: Nochmal den Link: http://osm.wno-edv-service.de/DataServer/osm/forum/doppelte_plz.txt

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.