Postcode Map Version 3.2 mit verbesserter Grenzdarstellung

Communities Deutschland (Germany)
114
  • Suche geht wieder: Es gab bei einer dringend notwendig gewordenen Aufräumaktion am Sonntag wohl kleinere “Kolateralschäden” :wink:
  • und die PLZ-Flächen sehen jetzt wohl ohne Kante besser aus. (1 x Reload im Browser machen oder 2 Stunden warten)
    Der Grund ist mir inzwischen klar und das erschien mir als die einfachste Lösung.

Gruss
walter

115

Hallo Walter

Suche klappt wieder. :slight_smile:
“Kolateralschäden” kommen bei der Weiterentwicklung immer mal wieder vor.

Die Grenzen waren ja nur eine optische Irritation.
So wie es jetzt ist, geht es gut und wenn es noch einfacher ist dann umso besser.

Edbert (EvanE)

116

Da mir das auch bei der ORM mit einem kleinen Unterschied zur bisherigen Beschreibung aufgefallen ist: Woher kommen die Graustufen-Kacheln? Werden da die normalen ihrer Farben beraubt? Bei der ORM scheint mir das so zu sein und dort sieht man nur die jeweilige Farb-Variante, nicht die anderen beiden (was bei der OSMPC-Karte mangels weiteren Layern nicht sichtbar war).

117

Nachdem das Raid5 endlich wieder rennt, ist die PLZ-Karte wieder online.

Allerdings wird es noch einige Tage dauern bis das Lag von 26 Tagen !!! abgebaut ist. Der Lag steht ja am unteren Ende der Karte und wird minütlich aktualisiert. Ein Klick auf den Link zeigt eine kleine Grafik.

Datenverluste gab es übrigens nicht, nur das Raid hat sich “ein wenig geziert”.

118

Warum sollten Gemeinde-Relationen nicht mit “postal_code” markiert werden? Ich sehe das anders. Eine Unterscheidung zu den “echten” PLZ-Gebieten kann auch über “postal_code_level” erfolgen.
Ist eine Gemeinde nicht identisch mit dem PLZ-Gebiet, sollte “postal_code_level=8” nicht gesetzt sein. Andernfalls würde ich die Kombi mit “postal_code” erlauben. Langfristig sollte es wohl für alle PLZ dedizierte Relationen geben. Aber auch dann ist es nicht notwendig, den “postal_code” bei Gemeinden zu löschen.

119

Laut Post gibt es in DE 8208 Zustellgebiete.
Status quo der PLZ in OSM (20.10.2013):
Es gibt 6043 dedizierte postal_code-Relationen. 5 sind nicht eineindeutig (PLZ: 38486, 15236, 22113, 16835, 18249)
Es gibt für davon nicht erfasste PLZ 1095 PLZ-getaggte Admin-Relationen mit postal_code_level=8.
Außerdem gibt es noch 1069 Gemeinden, für die keine PLZ-Relation gegeben und kein postal_code_level getaggt sind, die aber einen postal_code haben.
Davon sind 14 PLZ nicht eindeutig (2 Gemeinden mit gleicher PLZ).
Insgesamt sind 8188 PLZ erfasst. Fehlen noch 20 PLZ.

120

Hallo Gehrke,

tja, da gibt es wohl derzeit verschiedene Auffassungen:

Meiner Meinung nach sollte in den OSM-Daten eine Grenzrelation (egal ob postal_code oder admin) zu einer bestimmten PLZ nur ein einziges Mal vorkommen.

Wenn neben einer postal_code Relation nun auch noch eine administrative Relation die gleiche PLZ enthält, so ist es in meinen Augen eine redundante Datendoppelung.

Denn wenn man argumentieren wollte, dass an die admin_Relationen die PLZ-Werte zusätzlich enthalten sein sollen (wegen Zuordnung Gemeinde → PLZ) dann müsste ja an JEDE admin-Relation die entsprechende PLZ! Hmmm …

Und wenn die admin-Relation kleiner ist als die PLZ-Relation? … oder gar GRÖßER , d.h. eine Gemeinde hat mehrere PLZ … dann mit Semikolon trennen???

Eine Lösung sollte gefunden werden …

Gruß, Stephan

121

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.

122

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”

123

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.

124

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

125

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.

126

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.

127

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.

128

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)

129

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

130 

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

131

53567 und 53572 sind auch erledigt.

132

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

133

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