Bei Freiburg i.B. istwar etwas im Argen: 79211 Denzlingen. Ist gefixt.
EDIT: Done.
Nur noch Postleitregion 49, dann sind wir fertig. Letzte Chance mitzumachen!
493xx, 494xx, 495xx, 496xx
Ich halte mich da jetzt erstmal raus.
EDIT: Update
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.
postal_code | osm-id plz | osm-id admin
-------------+------------+--------------
48612 | 3389428 | 155783
(1 row)
ok, hab ich beseitigt. jetzt sind die 8201 wohl wieder ok.
Gruss
walter
Jetzt hab ich’s doch gemacht. Ich glaube, alle PLZ-Relationen sind erstellt.
Danke!
Eine fehlte noch. War die Grenze von Quakenbrück. Dubletten haben wir auch keine.
Hier mal die Lage vom 21.12. ca 1:20 Uhr
groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz-lage20131221.png
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.
edit: typo
wird es langsam Zeit, sich bei allen zu bedanken, die dazu beigetragen haben.
Danke!
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.
Die Wege des Mappers sind undurchschaubar: http://www.openstreetmap.org/browse/way/221076401/history insgesamt 24x (Ich hab die bereits bereinigt)
macht netto 8203 - immer noch 2 zuviel?
Gruss
walter
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?
hab sie gerade gefunden:
....
1159776 | 99996
1159783 | 99998
943740 |
3351884 |
(8203 rows)
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.
also sind wir wieder im Grünen Bereich 
Walter, den Treffer 3351884 verstehe ich jetzt nicht.
hab es gerade geändert. z.B. http://www.openstreetmap.org/way/87544901/history als member der TMC-Area
Puh, das Teil hat mich schon länger geärgert.
Gruss
walter
id | postal_code
----------+-------------
1306692 | 01067
1306695 | 01069
...
1159779 | 99994
1159776 | 99996
1159783 | 99998
(8201 rows)
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?
Moin,
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.
Gruß
Georg
Edit: Rechtschreibfehler zu spät entdeckt
Die Frage ist durchaus legitim. Es steht ja auch noch im Raum, das komplett wegzulassen. Deswegen habe ich auch das Ämter-Beispiel aufgeführt.
Gestern war (endlich wieder) so ein Tag.
und jetzt bitte noch irgendein neues projekt, macht auch vielmehr spaß für sowas zu mappen, “mappen im auftrag”.
bzgl. “name|description → note” sollte ich jetzt alle fertig haben
Hab mal eine aktuelle Liste erstellt. Sieht ganz gut aus
EDIT: Habe nach einigen kleineren Korrekturen Liste nochmals aktualisiert.
2.EDIT: und nochmals: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/alle_plz_20131224-2.txt
so, jetzt zünde ich mal den Weihnachtsbaum an - und wenn die Feuerwehr wieder weg ist, mach ich eventuell noch etwas weiter.
Gruss
walter