Manchmal ist ein Joke wohl doch nicht so einfach zu erkennen - besonders wenn man sich gerade ernsthaft mit dem Thema beschäftig.
also: Die Post fotografiert Briefumschläge aber doch hoffentlich keine Briefe 
Gruss
walter
Argh, ich habe das jetzt als Pars pro toto angesehen
Diskrepanz zwischen https://navigator.tu-dresden.de/geb%C3%A4ude/zin / https://www.openstreetmap.org/way/25720750#map=18/51.02048/13.72796 (addr:postcode) und der OSM boundary https://www.openstreetmap.org/relation/1306702#map=17/51.02015/13.72814
Kann jemand mit Wissen mal nachschauen bzw. korrigieren?
Korrigiert. Tauchte bloß komischerweise bei wambachers Fools-Auswertung nie auf.
Edit: Hab ich irgendwie falsch geändert, muss ich nochmal ran… fertsch
Danke!
Mit dem DPAG-Mitteilungsblatt 03/2017 haben sich keine großen Änderungen ergeben (5 Ortschaften wechseln die PLZ). Die Straßendaten habe ich noch nicht geprüft.
EDIT: Die Ortschaften sind jetzt wieder richtig zugeordnet.
Zu den Straßendaten: In Bitterfeld-Wolfen ist die Wasserturmstr. neu geordnet worden (Vor-Ort-Kenntnisse vor!).
Alles andere sind offenbar neue oder entfallene Straßen
Wieder mal eine PLZ-Boundary kaputt: https://www.openstreetmap.org/relation/1353110#map=12/52.0257/13.7695
Wäre bitte jemand mit Erfahrung so nett?
Erfahrung bekommt man durch Übung - wie wär’s ?
Gruss
walter
ps: da sind auch einige Admin-Boundaries betroffen.
Ach Walter. Du weisst doch, bei Fehlern, bei denen potentiell mehrere Relationen betroffen sind, spiele ich lieber Chef: “Mach, dass es geht”. 
Thomas, kannst du mal bitte bei Gelegenheit nach https://www.openstreetmap.org/relation/1307177#map=15/51.1501/13.9857 schauen? Hängt wahrscheinlich mit deiner gestrigen Änderung an https://www.openstreetmap.org/relation/1307179#map=15/51.1521/13.9860 zusammen.
repariert.
Sven
Ich dachte eigentlich, dass ich alle Relationen geladen hätte. Anscheinend nicht.
Die Straßennamen in einem admin_level=8-Bereich sollten ohnehin eindeutig sein, weil die Feuerwehr das meist so will — Gefahrenabwehr und so. So oder so ähnlich meine ich es in den letzten Eingemeindungsverträgen meiner Region mal gelesen zu haben.
Ich habe mich Monate hinweg gewundert warum Nominatim auf Suchabfragen falsche Postleitzahlen anzeigt (auch konkreter Natur, bspw: 16909 schlossstrasse => ergab 16918…) welche oft schon länger nicht mehr gültig sind.
Heute bin ich dem ganzen auf die Spur gekommen, Nominatim hangelt sich der Addresshirarchie entlang (ausgenommen sind PLZ-Gebiete) und nimmt den eindeutigsten, meiner Meinung nach den letzten PLZ-Treffer als Ausgabeergbnis.
Genau hier sind mir dann die fehlerhaft getaggten Ortspunkte aufgefallen, nach PLZ-Korrektur des Ortsteils Freyenstein bez. des Beispiels oben (91380235) erscheint auch das korrekte Ergebnis bei Nominatim.
Meine systematische Überprüfung (bisher nur auf place:‘suburb’, ‘hamlet’, ‘village’, ‘town’, ‘city’) ergabe um die 120 Treffer => Ortspunkt-PLZ != PLZ-Gebiet.
Ich würde diese nach und nach abarbeiten, jedoch weiß ich nicht soll der Tag postal_code in den Ortspunkten korrigiert oder besser ganz entfernt werden?
Wenn du mit Ortspunkten place-Nodes meinst: ja, da sind PLZ absoluter Blödsinn, da die Adminitiven Daten eben NICHT das PLZ-Gebiet festlegen. Aus diesem Grunde habe wir ja vor einigen Jahre die oft von den Admingrenzen abweichenden PLZ-Grenzen erfasst.
PLZ an place-Nodes sind definitiv Blödsinn - zumindest in DE. Und sie müssen mMn raus.
Gruss
walter
ps: danke für deine Analyse - darauf wäre ich nicht gekommen.
Wenn das (Freyenstein) ein place-Node ist, dann meinte ich so einen
Falls es allgemein entfernt werden soll!? Gibt es eine Möglichkeit einer Routine um alle postal_code Tags der entsprechenden place-Nodes in einem Wisch zu entfernen?
Das sind nämlich einige, knapp 8000
Theoretisch ja - aber das könnte Ärger geben.
Ansonsten frag mal den User, der das vor 2 Jahren eingegeben hat (zumindest hier): https://www.openstreetmap.org/node/91380235/history
Gruss
walter
mmh,
dann entferne ich erstmal die fehlerhaften Tags mit entsprechenden Hinweis, und werde die Prüfung regelmäßig durchführen.