uii, hast ja ganz gute Augen. Ich hab einfach plz+admin addiert und war mit 8201 eigentlich ganz happy.
Hätte ich vorher den Dublettentest laufen lassen, hätte ich gleich gemerkt, daß ein gewisser wambacher gestern wohl gepennt hat Werd ihn mal ansprechen.
Jetzt, da das geschafft ist, mach ich mich noch an die Bereinigung der anderen Daten. Da geht es bei den PLZ-Boundaries mit note/name/decription noch drunter und drüber; und bei den administrativen Grenzen sollten wird uns mal verbindlich auf den Ersatz für postal_code einigen. Da gibt es ja auch noch verschiedene Versionen.
Da gibt es ja eine starke Tendenz. Ich glaube außer bei “admin_centre:postal_code” ist bei den anderen Vorschlägen kaum ein Eintrag dazugekommen.
Ich könnte mir noch vorstellen, dass man “admin_centre:postcode” analog zu “addr:postcode” verwendet. Schließlich geht es ja jetzt nicht mehr um die PLZ für ein Gebiet, sondern um die Adresse der (Gemeinde-)Verwaltung.
Übrigens: Kann es sein (z.B. in Schleswig-Holstein und viell. auch in Rheinland-Pfalz), dass diese Adresse gar nicht innerhalb der Gemeinde liegt?
Auch ich möchte hier nochmal allen Unterstützern danken. Wir haben viel geschafft, aber wir sind auch nicht wirklich fertig.
Gebiete müssen in Details korrigiert (dwellings mit abweichender PLZ) und Tags harmonisiert (notes, type=boundary!) werden. Ferner ist die PLZ-Welt ja leider eine dynamische.
Uii, hab gerade mal eine zu triviale Query über die PLZ-Daten gefahren und siehe da: 8227 Treffer! Hab aus Versehen die “normalen” Polygone mit ausgewertet.
Man kann sich in OSM auf nichts verlassen. Ich werde weiter immer nur Relationen mit “boundary=postal_code” herausfiltern. Welche 2 Elemente sind denn übrig?
Zwei Boundaries mal OHNE PLZ. Werd ich jetzt erledigen.
Zur Erklärung dieser unerwarteten Treffer: Ich hab bisher sehr explizit auf PLZ (genau 5 Zeichen und nur Relationen) abgefragt und dabei sind mir einige durch die Lappen gegangen. Jetzt hab ich eine ganz banale Abfrage ohne diese Einschränkungen gemacht - halt so einfach, dass sie jeder leicht und sicher verwenden kann. Und jetzt tauchen die Irrläufer halt auf.
Gruss
walter
done
943740 war als boundary=postal_code getaggt und ist jetzt korrekt boundary=administrative user:wambacher
3351884 ist ein Problem mit den Rohdaten oder mit meiner Datenbank. Das ist eine TMC-Area in Leipzig, die bei mir aus bisher ungeklärten Gründen als plz-Boundary ankommt. Sehr misteriös.
Nachtrag: Bei der TMC-Area hatten die Ways boundary=postal_code ! Der Tag ist dann durch osm2pgsql an die Relation “gewandert”. Toll.
Mal eine weitere Konsistenzprüfung: Welche PLZ in addr:postcode (ways, nodes) sind eigentlich nicht durch das postal_code der boundaries abgedeckt.
Ergebnis: 690 verschiedene PLZ alleine für ways.
Erklärung: Oft handelt es sich wohl um Postfach-PLZ. Ob das so i.O. weiß ich nicht. Da es ja keine physischen Hausadressen sind, ist das nicht richtig, oder?
Manche sind auch Großempfänger-PLZ, z.B. PLZ 51368 für Bayer AG in Leverkusen. Was ist mit denen?
das ist ja quasi logisch bei Amtsverwaltung - das ist ja Sinn der Sache, die Verwaltung zusammenzufassen.
Ich frage mich auch, was admin_centre:postcode überhaupt bezwecken soll.
ohne :street und :city ist das ja nahezu sinnlos.
Und mit hat das schon wieder Nachschlagewerk-Charakter.
Da hilft es auch nicht, wenn Gemeinde und Sitz der Verwaltung die gleiche PLZ haben …
Wenn jetzt noch bei unserer Gemeinde als admin_centre der Sitz der Amtsverwaltung eingetragen wird und dann das label (Gemeindename) beim admin_centre gerendert wird, ist das Chaos nahezu perfekt.