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