Pflege der deutschen PLZ-Daten in OSM

Das ist sehr merkwürdig. Wenn ich danach suche, bekomme ich als Antwort 73655 Bärenbach, Eulenhof, Ilgenhof, Pfahlbronner Mühle.

Ach ja: Weitere Fehler: 73642 Eibenhof, 73642 Köshof

Die Frage ist wahrscheinlich, wo gesucht. Die Postseite schweigt sich zu Eibenhof und Köshof aus, die Grenze auf der Karte folgt aber hier der Gemeindegrenze. Was der Postbote macht, könnte wieder eine andere Frage sein, denn die beiden Höfe lassen sich von Norden (73642 Welzheim) viel besser erreichen als von Plüderhausen/Walkersbach aus.
Weiter unten ist berücksichtigt (auch in der PLZ-Karte), dass der Haselhof direkt neben Walkersbach liegt, obwohl auf Markung Alfdorf.
Ich habe es aber schon lange aufgegeben, die Logik in der PLZ-Grenzziehung zu entdecken.

edit: vertippt

Du kannst als Ort (nicht als Straße) z.B. einfach “Eibenhof” eingeben und bekommst die PLZ 73655.
Die Post-eigene Karte ist im Zweifel leider überhaupt nicht zu gebrauchen.

EDIT: Typo

Noch eine Anmerkung zum note-Tag:

Ich bin nicht dafür, kleine Gehöfe etc. in der Auflistung der Gemeinden des Key “note” aufzuführen. Also z.B. “12345 MeineStadt, Hinterstwinkelhof” oder “12345 MeineStadt mit Hinterstwinkelhof”.
Begründung: Bei PLZ-Gebieten mit vielen inkludierten Höfen verschmutzen wir gehörig das Label.

Wenn wir diese Informationen über postalische Einschlussgebiete (außerhalb großer Gemeindeteile) überhaupt namentlich aufnehmen, dann doch eher über einen dedizierten Tag (z.B. “included_dwellings”) oder über einen Relationmember mit einer Rolle wie “includes_dwelling” o.s.ä. z.B. für den place node. Ich würde es im Moment aber einfach rauslassen.

Nochmal überdacht: Solche dwellings kann man ja auch über ein spatial query (z.B. place nodes) ermitteln. Der Key “note” is nur ein Label zur Identifikation und Lesbarkeit und somit möglichst kurz.

EDIT: Typo, Begründung, spatial query

Habe eben noch 6 zerstörte Relationen (innerhalb <24h!) repariert. Es sollte daher im Moment keine weißen Flecken mehr geben (außer den Seen in Bayern).

Prima, was machen wir mit denen? Zuschütten oder so lassen?

Gruss
walter

Der Bodensee ist auch ohne PLZ(en). Da merkt man es aber nicht so, da am Rand von DE.
Wen’s stört, der kann ja Ammersee und Starnberger See Dießen und Starnberg zuschlagen, so wie es mit den alten PLZ-Grenzen der Fall war. Das Gemeindegebiet geht ja nur bis zum Seeufer. Dem Postboten kann es egal sein.
(Gibt vermutlich weniger Protest wie beim Zuschütten.)
Der Chiemsee hat übrigens eine eigene PLZ (na gut, etwas gemogelt: ist die der Insel Frauenchiemsee).

Ich tendiere zu Zuschütten im Sinne von “einem Gebiet zuschlagen”.
Dann wäre Deutschland postalisch partioniert (außer Bodensee und Küsten – und Rheinau!). Außerdem könnte man durch Kombination
aller PLZ mit gleicher erster oder gleichen 2 führenden Ziffern auch die Postleitzonen bzw. Postleitregionen einfach bauen.

Meinst du sowas?

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz_leitregionen.png

groß: http://osm.wno-edv-service.de:8080/DataServer/osm/forum/plz-06.png

Daten sind leicht veraltet und an der Optik dreh ich noch.

Gruss
walter

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 :wink:
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. :frowning:
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.