Ja, in der Art. Habe das bei mir für alle PLZ durch ein SQL-Aggregat hinbekommen, das auch passende Admin-Relationen einschließt (keine Dubletten).
Die zweite Grafik ergibt mMn nicht so viel Sinn, weil die dritte PLZ-Ziffer keine strukturierende/gliedernde Bedeutung hat, auch wenn die Wahrscheinlichkeit groß ist, dass Gebiete à la 123XX zusammenhängen.
jo, ist so machbar und für mich auch kein Problem. Das ist aber für die wenigsten Mapper zumutbar. Versuch das mal mit der Overpass hinzukriegen. Ich bin und bleibe dafür, die PLZ-Gebiete auf ganz Deutschland anzupassen, damit es eben nicht so kompliziert oder gar erst möglich wird. Gestern hab ich mal das Saarland eingemeindet umgewandelt.
Stimmt - sieht aber sehr hübsch aus 
Hab damit versucht, die Einfärbung der unterschiedlichen Bereiche hinzukriegen.
Gruss
walter
ps: wie sieht denn dein DB-Umfeld aus?
meines: Dicker Server, Full Planet, Postgresql 9.1, PostGis 2.0, osm2pgsql, minütliche Diffs, Programmierung in Java, OpenLayers, Qgis
Da bist Du mir schon noch voraus. Ich bin im Moment auf Deutschland fixiert und arbeite nur mit daily snapshots mit PostgreSQL 9.3, PostGIS 2.1 und leider auch noch nicht osm2pgsql. 
Für gewisse Beschränkungen habe ich neben den Hardware-Anforderungen auch gute inhaltliche Gründe für meine Anwendungen. Ich will nicht, dass jede minütliche Änderung meine Datenbasis zerschießt.
Programmierung auch in Java, teilweise Qgis, teilweise eigene Java-Tools für das Rendering. Bspw. nutze ich einen speziellen Algorithmus zur Linienzug-Approximation für große Karten.
Aber ich plane, mir parallel eine Infrastruktur für den Planet mit osm2pgsql und continuous synchronization aufzubauen. Dafür komme ich zwecks Rat eventuell nochmal auf Dich zurück.
Nochmal eine Frage zum leidigen Thema PLZ-Suche der Post:
Es ist nicht gestattet, den PLZ-Server der Post AG zu nutzen, um die Postleitzahlen für eine bestimmte Straße zu finden. Aber für Kontrollzwecke ist die Nutzung erlaubt.
Quelle: OSM-Wiki
Was heißt das eigentlich? Und wo ist in der Praxis der Unterschied? Kontrollzweck wäre wenn eine Straße oder ein Haus eine PLZ in OSM hat und ich will prüfen, ob die auch stimmt. Richtig?
Darf ich es ändern/korrigieren, wenn es nicht stimmt? Wenn nein, darf ich es einem Dritten erzählen, dass es nicht stimmt, und der korrigiert es dann in OSM? Oder brauche ich noch eine Indirektion mehr? Oder was soll das Ganze?
Ich rede hier nicht von mechanischen Änderungen, sondern von sich Informieren und neues Wissen in Handeln umsetzen.
Das ist doch alles verrückt! Ich glaube, ich muss noch mal meinen Anwalt fragen.
Don’t Panic
Dieser Kommentar ist für mich “Sekundärliteratur”, deren Quelle nicht gesichert ist. Relevant ist - für mich - der vollständige darunter zitierte Brief, solange es nicht eine anders lautende schriftliche Stellungnahme der Post neueren Datums gibt. Oder sowas steht eventuell in deren Impressum?
eventuell hat der Autor des Kommentares mal mit der Post telefoniert und entsprechende Aussagen erhalten
Schau mal in der History des WIKIs nach, wer das hingeschrieben hat und frag ihn. Eventuell ist ja auch nur das automatische Auslesen wie bei einer Georeferenzierung gemeint.
Gruss
walter
ach ja: ich verwende die Straßensuche bei denen nicht. Ich schau mir das gesamte Gebiet in der Übersichtkarte an und wenn unser Grenzen einigermaßen passen, reicht mir das.
Nee. Keine Panik, nur ein bisschen Frustration bzgl. so viel Unsicherheit, teils rechtlichen Fehlinformationen und Copyright-Wahnsinn im Allgemeinen. Aber gegen diesen Wahnsinn machen wir ja auch OSM.
Im Zuge des Konsolidierungsprozesses ist ein bunter Strauss postalischer Tags entstanden.
Ich habe im Wiki-Artikel mal eine Auswertung aufgeführt.
Wem weitere Tags begegnet sind, melde mir die bitte.
Wir sollten versuchen, bald eine einheitliche Linie zu finden, um späteren Aufwand zu minimieren.
EDIT: Ach ja. Gestern wurden mal wieder 6 Postalische Relationen beschädigt. Bin noch beim Reparieren…
Ich habe meine Kenntnisse des britischen Englisch hervorgekramt und hier sowie da gegen gecheckt.
Danach tendiere ich zu postcode, weil kurz und bündig. Da es zusammengeschrieben ist, sparen wir auch noch den fehleranfälligen Unterstrich.
Gut, aber mit welcher Semantik? Ein Vorteil bei “admin_centre:postcode” bzw. “admin_centre:postal_code” ist die klare Unterscheidbarkeit und Bedeutung im Gegensatz zu “postal_code”. “admin_centre:postcode” wäre außerdem sogar analog zu “addr:postcode”. Mit “de:plz” wurde wohl der Versuch unternommen, einen Schlüssel analog zu “de:regionalschluessel” für offizielle Angaben zu finden.
Aber einige haben die berechtigte Frage aufgeworfen, ob man das überhaupt braucht bzw. wo diese Information am besten aufgehoben ist. Wenn “admin_centre” auch ein member node in der Grenzrelation ist, kann man die PLZ z.B. auch da notieren. Der “radikalste” Standpunkt ist: Der AGS und Regionalschlüssel identifizieren die Gemeinde eindeutig; daher können wir uns PLZ (und auch population etc.) auch aus einer anderen freien Quelle holen (z.B. Wikipedia oder DESTATIS-Datei) und müssen das nicht doppelt abbilden und pflegen.
Ich bin da noch unentschlossen. Es ist natürlich generell einfacher, wenn man sich Infos nicht aufwendig zusammensuchen muss. Nicht jeder User/Auswerter kann das außerdem leicht (automatisch) hinbekommen.
Die Frage müsste wohl sein: Gibt es eine “OSM-only”-Anwendung, wo man die PLZ der Gemeinde braucht (vorausgesetzt es gibt auch eine PLZ-Relation)?
Ich tendiere derzeit zu admin_centre:postal_code, weil das irgenwann mal hier so vorgeschlagen wurde. Mit dem langen Key hab ich keinerlei Probleme, da ich mit Josm schaffe. Bei einer neuen Josm-Session muss ich den 1x eingeben, danach kommt er automatisch hoch, wenn ich nur “adm” eingebe. Was will ich mehr?
Gruss
walter
ps: diesen Key auf den letztendlich beschlossenen finalen Wert umzustellen, ist doch ein Klacks.
Reden wir aneinander vorbei?
Ich denke bei postcode an den Flächenumriss des Bereiches, in dem die PLZ gilt. admin_centre:postal_code steht für mich eher an der zentralen Verwaltung (Rathaus) irgend eines admin-Bereiches. Das könnte dann auch die Postfach-PLZ sein, die ja von der Gebiets-PLZ abweicht, wenn es größere Einheiten sind.
Ja, da ich das falsche Zitat eingefügt hatte.
jetzt sollte es passen.
Gruss
walter
ps: bin leicht unter Zeitdruck. werde das heute noch mal genau checken.
Nee, die meinte ich gar nicht. Zwar gibt es hier international auch einzelne Unterschiede. Aber in Deutschland und darüber hinaus ist postal_code für PLZ-Relationen, und Straßen weit verbreitet und weitgehend einheitlich. Das würde ich jetzt nicht mehr in Frage stellen, auch wenn “postcode” vielleicht schöner ist.
Dann belasse ich es auch dabei: very british ‘postal_code’ instead of ordinary ‘postcode’ 
Habe mal die aktuelle PLZ-Grafik in das Wiki gestellt. Sonst wird das (arme) Forum überlastet 
Weitere Grafiken folgen.
Und solange das Projekt läuft, werde ich die wohl täglich aktuell halten (müssen).
Derzeit versuche ich die Erstellung in QGIS zu automatisieren, bekomme dann aber andere Dubletten als bei manueller Erstellung. Irgendwo klemmt es da wohl noch.
Gruss
walter
Mit dem Entfernen der admin-PLZ-Dubletten geht es ja offensichtlich gut voran. Wenn ich nicht irre, bleiben nur noch Fälle in Zone 0.
ich glaube, du irrst. siehe Grafik im wiki. Allerdings nehmen die Administrativen PLZ-Grenzen ab und die “echten” zu. Und das ist wesentlich wichtiger als die Dubletten.
Hier mal was neues: PLZ-Zonen
groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz-zonen01.png
ist auch gleich im Wiki
Gruss
walter
Die Grafik ist aber von 15:30 Uhr und ich bin in der Gegenwart 
Anmerkungen aus meiner Sicht zur Wiki-Seite hier, da ich auf die Diskussion dort nicht zugreifen kann:
Das note in den PLZ-Relationen wurde kritisiert, da es eine andere Bedeutung habe. Andere Möglichkeiten wie identifier wurden vorgeschlagen, im Moment wird aber von denen nur note z.B. für die Relationslisten in JOSM ausgewertet.
Das Entfernen der postal_code-Dubletten in den admin-Relationen ist wohl unstrittig. Es gab aber mindestens einmal den Wunsch die PLZ-Informationen in den admin-Relationen zu behalten, da die Information zwar im Prinzip aus den PLZ-Relationen zu gewinnen sei, aber mit viel höherem Aufwand.
Als vorsichtiger Mensch habe ich den postal_code-Tag daher nicht gelöscht, sondern nur durch Umbennung “unschädlich” gemacht. Späteres Löschen/Umbennen geht viel schneller als etwaiges Wiederherstellen.
Ich habe dafür die temporären Tags “is_in_postal_code” (es gibt noch mehr admin-Relationen mit derselben PLZ) und “de:plz” (genau ein admin-Gebiet mit dieser PLZ, aber Grenzen verschieden) verwendet. Die werden anders als postcode nirgends sonst verwendet und können daher nicht verwechselt werden.
Bei Konsens können die umbenannt, gelöscht oder was auch immer werden.
Die 1:1-Gebiete (identische Grenzen) haben (für mich) keine Priorität.
Interessant wäre es, die kleinen Flecken oder eher Pünktchen zu identifizieren. Dort scheinen sich winzige Flächen ohne jegliche PLZ-Relationsabdeckung zu befinden, richtig? Ich vermute dort Mapping-Fehler.