Pflege der deutschen PLZ-Daten in OSM

Hallo!

Dieser Thread diskutiert das Vorgehen und die Fortschritte bei der Konsolidierung der (vornehmlich deutschen) PLZ-Daten in OSM.
Damit führt er die betreffenden Posts aus dem Thread zur OSMPC Map separat weiter.

Diskutiert wurde dort insbesondere die vollständige Abbildung der PLZ-Gebiete in dedizierten “boundary=postal_code”-Relationen.
Darüber hinaus ist zu klären, wie und ob PLZ-Angaben in admin-Relationen noch Anwendung finden sollen.

Ziel ist einerseits eine aktuelle und vollständige PLZ-Karte für Deutschland (bzw. die konsistenten Daten für deren Erstellung) und eine Einigung über das “korrekte” Tagging (mit einem entsprechenden Wiki-Beitrag).

Viele Grüße
Jan

Wiki-Artikel zum Thema: Konsolidierung der PLZ-Relationen in Deutschland 2013
Für Kontrolle und Überblick: Wambachers PLZ-Karte

Status quo der deutschen PLZ in OSM (23.11.2013, ca. 21:00 Uhr):

  • Echte PLZ-Relationen: 6266

  • PLZ ohne eigene Relation: 1942 (davon 978 mit postal_code_level=8)

  • Erfasste PLZ: 8208 (in DE mit tag postal_code und boundary=postal_code oder boundary=administrative)

  • PLZ-Gebiete in DE: 8208 (laut Dt. Post AG, Stand Mai 2013; unbekannt ob mit oder ohne die 4 DE-PLZ in Österreich)

  • Bekannte fehlende PLZ: keine

  • Offene Polygone: (unbekannt)

Fazit: Alle PLZ sind abgedeckt, wenn nicht noch falsche dabei sind.

Aktuellere Werte sind im Wiki-Artikel zu finden.

Vorschlag:

  • Nur echte PLZ-Relationen: boundary=postal_code, da diese auch mehrere Gemeinden oder Verwaltungsbereiche betreffen können.
  • Administrative in PLZ überführen und in admniistrative key-postal_code ändern in postcode (damit noch findbar)

Ich versuche mal, die aktuellen offenen Punkte/Fragen zusammenzustellen:

1: Es gibt Gebiete, wo die PLZ nur in Administrativen Grenzen erfasst sind.
2: Es gibt Gebiete, wo sowohl “echte” PLZ-Relationen als auch Admin-Relationen mit postal_code vorhanden sind.
3: Welchen “Namen” sollen die PLZ-Relationen erhalten? (note? description? identifier? ?)
4: was machen wir mit dem postal_code in den Admin-Boundaries?
5: manche Relationen sind noch mit type=multipolygon erfasst.
6: tbc.

Meine Vorschläge:
1: Admin-Boundaries duplizieren, im Original postal_code und postal_code_level entfernen, in der Kopie die administrativen Tags entfernen.
was mit postal_code geschieht, siehe 4.
2: Admin-Boundaries bereinigen
3: unklar. Derzeit haben von 6172 PLZ-Relationen 5851 note, 151 name, 0 ref, identifier 4 und 59 description, wobei mehrfache Tags auch vorkommen.
Was mit der Differenz zu den 6172 ist, hab ich noch nicht rausgefunden aber der Trend ist klar.
4: postcode gefällt mir ganz gut. sollte nach einem Vorschlag von Gehrke die PLZ der Gemeindeverwaltung sein.
5: auf type=boundary umstellen

Gruss
walter

edit: tüpo

Hallo Walter

Zu Punkt 3:
Ich würde die note=* lassen und die name=* zu note=* ändern. Gegebenfalls kann man zur Einführung identifier als zusätzliches Tagg verwenden.
Die 59 description=* würde ich ebenfalls lassen wie sie sind. Gegebenenfalls würde ich ein früheres note=* wieder ergänzen.

Zu Punkt 4:
Das postcode gefällt mir wegen der Verwechslungsgefahr überhaupt nicht. Wenn man die PLZ des Verwaltungszentrums eintragen will, dann sollte man das auch deutlich sagen. Etwas wie admin_centre:postcode würde diese Anforderung erfüllen.

Einfach postcode für diese Funktion wieder zu verwenden öffnet Missverständnissen Tür und Tor.

Edbert (EvanE)

Ich habe das bei ein paar Gebieten gemacht: Ist nicht viel, zieht sich aber doch hin. Problem: Es gibt hunderte davon. Für mich lohnt sich der Aufwand bei 1:1-Gebieten nicht, aber wer es unbedingt machen will …

Zwingend für mich da, wo mehrere Gemeinden dieselbe PLZ haben → PLZ-Relation, postal_code aus admin-Rel. löschen oder umbenennen (mein Vorschlag: per is_in_ unschädlich machen)

Gegen note gibt es Einwände wegen des eigentlichen Zweckes, description ist eigentlich auch für etwas anderes gedacht (und wird in JOSM auch nicht in der Relationenliste angezeigt), name führt zu Doppelanzeigen in der Karte, identifier ist ein Versuchsballon (wird natürlich nicht angezeigt)

keine Einwände (meinerseits)

+1

Finde ich auch treffender, insbesondere da, wo es mehrere PLZ pro Kommune gibt.

Zusatz: Ist eine Anwendung denkbar, wo man alle PLZen einer Kommune aufgelistet haben möchte?

lohnt sich wohl nicht. umtaggen sollte reichen.


 ?column? | postal_code |              description              |    note    
----------+-------------+---------------------------------------+------------
  1437293 | 51107       | 51107 Köln                            | 
  1437290 | 51069       | 51069 Köln                            | 
  1435109 | 53844       | 53844 Troisdorf                       | 
  1434451 | 53177       | Bereich mit Postleitzahlen 53177 Bonn | 53177 Bonn
  1437294 | 51143       | 51143 Köln                            | 
  1434546 | 53123       | Bereich Postleitzahlen 53123 Bonn     | 53123 Bonn
  1434470 | 53225       | Bereich Postleitzahlen 53225 Bonn     | 53225
  1434453 | 53125       | Bereich mit Postleitzahl 53125 Bonn   | 53125 Bonn
  1435448 | 50739       | 50739 Köln                            | 
  1435426 | 50935       | 50935 Köln                            | 
  1435451 | 50933       | 50933 Köln                            | 
  1435434 | 50767       | 50767 Köln                            | 
  1435449 | 50827       | 50827 Köln                            | 
  1435442 | 50825       | 50825 Köln                            | 
  1435431 | 50735       | 50735 Köln                            | 
  1435424 | 50733       | 50733 Köln                            | 
  1437284 | 51105       | 51105 Köln                            | 
  1437283 | 51063       | 51063 Köln                            | 
  1437286 | 51103       | 51103 Köln                            | 
  1437295 | 51065       | 51065 Köln                            | 
  1437288 | 51149       | 51149 Köln                            | 
  1437291 | 51067       | 51067 Köln                            | 
  1437292 | 51145       | 51145 Köln                            | 
  1435429 | 50969       | 50969 Köln                            | 
  1435443 | 50939       | 50939 Köln                            | 
  1435435 | 50858       | 50858 Köln                            | 
  1435428 | 50829       | 50829 Köln                            | 
  2024404 | 50968       | 50968 Köln                            | 
  1435439 | 50996       | 50996 Köln                            | 
  1435427 | 50765       | 50765 Köln                            | 
  1435450 | 50999       | 50999 Köln                            | 
  1435436 | 50937       | 50937 Köln                            | 
  1434472 | 53119       | Bereich Postleitzalen 53119 Bonn      | 53119 Bonn
  1434471 | 53117       | 53117 Bonn                            | 
  1434454 | 53179       | Bereich mit Postleitzahlen 53179 Bonn | 53179 Bonn
  1434459 | 53175       | Bereich Postleitzahlen 53175 Bonn     | 53175 Bonn
  1434457 | 53173       | 53173 Bonn                            | 
  1434468 | 53227       | 53227 Bonn                            | 
  1435430 | 50668       | 50668 Köln                            | 
  1434543 | 53127       | Bereich Postleitzalen 53127 Bonn      | 53127 Bonn
  1435438 | 50678       | 50678 Köln                            | 
  1435440 | 50677       | 50677 Köln                            | 
  1435421 | 50931       | 50931 Köln                            | 
  1435432 | 50823       | 50823 Köln                            | 
  1435444 | 50679       | 50679 Köln                            | 
  1457041 | 51379       | 51379 Leverkusen                      | 
  1457042 | 51371       | 51371 Leverkusen                      | 
  1435437 | 50670       | 50670 Köln                            | 
  1434541 | 53113       | Bereich Postleitzahlen 53113 Bonn     | 53113 Bonn
  1434469 | 53229       | Bereich Postleitzahlen 53229 Bonn     | 53229 Bonn
  1434477 | 53111       | Bereich Postleitzalen 53111 Bonn      | 53111 Bonn
  1435445 | 50859       | 50859 Köln                            | 
  1437285 | 51109       | 51109 Köln                            | 
  1457038 | 51373       | 51373 Leverkusen                      | 
  1437287 | 51061       | 51061 Köln                            | 
  1457037 | 51377       | 51377 Leverkusen                      | 
  1457043 | 51469       | 51469 Bergisch Gladbach               | 
  1437289 | 51147       | 51147 Köln                            | 
  1435425 | 50769       | 50769 Köln                            | 
(59 rows)

Recht langer tag, aber da könnte ich mit leben. Ich habe lange hin- und herüberlegt, ob postcode oder sogar einfach postal_code reichen würde (wäre ja für die Auswertung kein Problem mehr, sobald komplette PLZ-Relationen da sind). Gegen postcode spricht aus meiner Sicht, dass wir damit einen tag-key mit eigener Bedeutung haben, der aber sehr, sehr ähnlich zu postal_code wäre. (Verwechslungsgefahr!).

Gegen postal_code spricht, denke ich, Folgendes: Normalerweise gibt postal_code die PLZ für das gesamte Element (Relation, Polygon, Street) an. Bei admin-Relationen gilt dies jedoch (sehr) oft nicht. Bei Großstädten ist das klar. Aber selbst bei ländlichen Gemeinden, die vermeintlich nur eine PLZ haben (auch laut Wikipedia oder Post-PLZ-Suche), gibt es dann doch wieder abseitige Gebiete (Höfe am Gemeinderand), die eine andere PLZ haben.

Fazit: Entweder gar keine PLZ-Angaben für Gemeinden oder eine klar abgegrenzte Angabe mit eigener Bedeutung wie admin_centre:postcode.
Im Moment tendiere ich zu letzterem - wie von mir bereits vorgeschlagen mit Bezug zu den offiziellen Angaben von DESTATIS.

Natürlich ist solch eine Anwendung denkbar. Ich hätte das gerne. Aber es wäre, wie bereits angedeutet, mit tags an den admin-Relationen (Beispiel is_in_postal_code) nicht vernünftig zu leisten. Sowas ist sehr fehleranfällig und schwer zu warten.

Der einzige Weg dafür scheint mir tatsächlich ein spatial query zu sein, also die Überlappung von admin-Relationen mit postal-Relationen.

Ich möchte noch einmal eine kleine Lanze für das Tagging mit “postal_code_level=8” brechen.

Die Sinnhaftigkeit und der Nutzen dieses tags bei PLZ-Relationen kann mit Recht angezweifelt werden.
Ich sehe aber auch Argumente dafür. Es besteht ja eine gewisse Parallelität mit “admin_level=8”. Wenn man nun fragt: “Aber was sind dann andere levels?”, sage ich, in Deutschland gibt es neben Postleitgebieten (5 Ziffern) ja noch Postleitregionen (erste 2 Ziffern) und Postleitzonen (führende Ziffer). Ich könnte mir vorstellen, dass es hier nochmal eine sinnvolle Anwendung für Relationen auf diesen Ebenen geben könnte. Als “postal_code_level” könnte ich mir da (ähnlich zu den admin-Relationen) die Werte 4 (PLZ-Zone) und 6 (PLZ-Region) vorstellen.

Darüber hinaus gibt es in Europa und der Welt ja unterschiedliche Postgebiete für jede Nation. Diese hätten, auch wenn es sie (noch) nicht explizit in OSM gibt, dann logischerweise postal_code_level=2.
Passend zu diesem internationalen Thema: Wie markieren wir eine PLZ-Relation bzgl. des Postleitsystems bzw. “operators”?

mal so ins Blaue gedacht: Die PLZ für das “Gemeindezentrum” / Stadtverwaltung / admin_centre, … steht doch im Wiki, genauso wie andere Daten, die wir bei OSM nicht unbedingt pflegen (wollen). Reicht das nicht aus?

Das ist mMn genau der richtige Weg, mit OSM-Daten umzugehen: Relationen oder auch ein einfache geschlossene Ways beschreiben Flächen; mit Flächen kann die jedes vernünftige GIS-Programm “rechnen” und unsere Datenbank “spricht” GIS.
Jeder von euch, der z.B. zum Rendern eine eigene kleine DB erstellt - und sei es auch nur zum einmaligen Gebrauch - hat die tollsten technischen Voraussetzungen - er muss sie nur benutzen.


select distinct adm.name,
                -(pc.osm_id) osm_id,
                pc.postal_code,
                coalesce(pc.note,pc.name,pc.tags->'description') "Name"
  from planet_osm_polygon adm, 
       planet_osm_polygon pc
 where adm.osm_id='-62713'
   and pc.boundary='postal_code'
   and pc.way && adm.way
   and st_intersects(st_buffer(pc.way,-0.00001),adm.way)
 order by pc.postal_code;

 name  | osm_id  | postal_code |    Name     
-------+---------+-------------+-------------
 Essen | 2085719 | 45127       | 45127 Essen
 Essen | 2081504 | 45128       | 45128 Essen
 Essen | 2073330 | 45130       | 45130 Essen
 Essen | 2070572 | 45131       | 45131 Essen
 Essen | 2060351 | 45133       | 45133 Essen
 Essen | 2055204 | 45134       | 45134 Essen
 Essen | 2064512 | 45136       | 45136 Essen
 Essen | 2079745 | 45138       | 45138 Essen
 Essen | 2094676 | 45139       | 45139 Essen
 Essen | 2133092 | 45141       | 45141 Essen
 Essen | 2101976 | 45143       | 45143 Essen
 Essen | 2083959 | 45144       | 45144 Essen
 Essen | 2082575 | 45145       | 45145 Essen
 Essen | 2074930 | 45147       | 45147 Essen
 Essen | 2063069 | 45149       | 45149 Essen
 Essen | 2010974 | 45219       | 45219 Essen
 Essen | 2047909 | 45239       | 45239 Essen
 Essen | 2046171 | 45257       | 45257 Essen
 Essen | 2047771 | 45259       | 45259 Essen
 Essen | 2100882 | 45276       | 45276 Essen
 Essen | 2050992 | 45277       | 45277 Essen
 Essen | 2100868 | 45279       | 45279 Essen
 Essen | 2049452 | 45289       | 45289 Essen
 Essen | 2139190 | 45307       | 45307 Essen
 Essen | 2139191 | 45309       | 45309 Essen
 Essen | 2131119 | 45326       | 45326 Essen
 Essen | 2095780 | 45327       | 45327 Essen
 Essen | 2104867 | 45329       | 45329 Essen
 Essen | 2074493 | 45355       | 45355 Essen
 Essen | 2106265 | 45356       | 45356 Essen
 Essen | 2072078 | 45357       | 45357 Essen
 Essen | 2055456 | 45359       | 45359 Essen
(32 rows)
Time: 182,183 ms

Gruss
walter

ps: coalescs() listet den ersten gefundenen Wert auf, also erst Note, dann Name, dann Description
st_buffer() verkleinert das zu suchenden Gebiet ein wenig, damit die umliegenden Städte nicht einbezogen werden
und st_intersects() macht den eigentlichen Job.

Und A && B nutzt den Geo-Index, um nicht jedes Polygon mit jedem anderen vergleichen zu müssen, nehme ich an.

Das Konstrukt mit st_buffer() gefällt mir weniger. Müsste es nicht auch gehen mit st_crosses() OR st_contains() statt st_intersect() ?

Die Performanz wäre aber zu prüfen.

Jo, ist irgendwie schneller als ohne. Bei manchen spatialen Abfragen steht in der Doju, dass er sowas automatisch macht, aber bei st_intersects nicht. Da bin ich auf Nummer sicher gegangen.

Mag sein, aber hier ging es mir erstmal darum, das Prinzip anschaulich darzustellen - und die Frage von seichter mit einem klaren JA zu beantworten.

Gruss
walter

So. Ich habe heute 7 PLZ-Relationen in Düsseldorf von Haus zu Haus gezeichnet und bin ganz geschafft.
5 PLZ bleiben (dort) übrig. Nächste Woche könnte der große Moment kommen: Alle PLZ-Gebiete in OSM abgedeckt!

Noch ein paar Fakten zur Konsolidierung:

Folgende PLZ gehören weder zu einer PLZ-Relation noch zu einer Gemeinde, sondern nur zu einer Verwaltungsgemeinschaft oder zu einem Ortsteil:
06792, 06796, 14789, 23569, 23570, 23629, 27412, 27419, 27628, 27729, 37136, 38173, 38312

EDIT: Habe nun alle umgewandelt (als boundary=postal_code dupliziert).

Im Moment sind nur 1024 PLZ-Relationen als “type=boundary” getaggt. Der Rest (5053) ist “type=multipolygon”.

Das soll aber nicht heißen, dass ich das nicht ändern wollte.

Schadensbericht. Was durch den Oberförster gestern postalisch kaputt gegangen ist:

55234 Albig, 55599 Gau-Bickelheim, 67292 Kirchheimbolanden, 67294 Kirchheimbolanden, 67808 Steinbach, 67819 Kriegsfeld, 67822 Winterborn

EDIT: Nach den Korrekturen von Frederik ist wieder alles in Ordnung.

Wenn ich mir nach getaner Arbeit die folgende Gegend ansehe http://osm.wno-edv-service.de/plz/?zoom=16&lat=48.482&lon=9.21759&layers=BTTFTTTFFFFTT, kommen mir schon Zweifel, ob innerstädtische PLZ-boundaries Sinn machen.
Zur Erläuterung: Hier haben Längs- und Querstraßen unterschiedliche PLZ, bei Eckhäusern hängt die Zugehörigkeit davon ab, welcher Straße sie zugeordnet wurden.

Das ist aber auch ein Extremfall. Und so schlimm finde ich es auch gar nicht. Durch Walters neue Art Grenzen zu zeichnen (mit Margin), sieht es reingezoomt auch schlimmer aus als es ist.

Ein Nutzen der PLZ-Gebiete ist ja auch, dass man geographisch (spatial query) die PLZ eines Hauses/Punktes ermitteln kann. Die sind ja nicht immer getaggt.

Sehe ich schon ein. In dieser Gegend habe ich aber versucht, darauf zu achten, dass die PLZ auch an den Häusern hängt, aus den Grenzen allein wird man da ja (mit dem Auge) nicht schlau.