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.
Um 19:20 Uhr Z-Zeit war es soweit! Mit Edit 19021162 sind nun alle PLZs Düsseldorfs und damit vielleicht gar alle Deutschlands mit einer postal_code- oder admin-Boundary (admin_level=8) erfasst.
Eine Menge Arbeit findet damit einen Abschluss. Aber das führt jetzt natürlich nur zum nächsten Schritt: einem kontinuierlichen Verbesserungsprozess. Die bestehenden Gebiete sind bzgl. ihrer Detailausdehnung zu überprüfen. Außerdem müssen alle Änderungen der PLZ-Gebiete mitgepflegt werden.
Ich habe mich ja nicht an der PLZ-Karte gestoßen, sondern am irrwitzigen Verlauf der Grenze. Der ist nicht besser geworden.
Was besser geworden ist, ist aber die Karte insbesondere bei hohen Zoomleveln, dadurch konnte ich jetzt eine kleine Unstimmigkeit erkennen: Die Grenze geht jetzt sogar durch ein Doppelhaus, bei dem die Hälften zu verschiedenen Straßen gehören. Das artet fast schon in Micro-Tagging aus.
Pah, Kleinkram Postleitzahlen / Straßenzugehörigkeit. Hier gibt es zwei Häuser, durch die genau die Grenze zwischen Bonn und Königswinter (Rhein-Sieg-Kreis) geht.
(Am Berghang 10 und 12 in Königswinter).
Es gibt schon ziemlich verrückte Sachen
Edbert (EvanE)