Darunter findet man in blassem grau “place:postcode” mit der richtigen Postleitzahl 80796 und Relation: https://www.openstreetmap.org/relation/1100786. Die korrekte Relation umschließt die besagten Objekte vollständig.
Ich kann in den Daten für beide Relationen keinen Fehler finden. Was genau passiert hier?
dies ist ein bekanntes Problem von Nominatim, das vielerorts auftritt. Nominatim bestimmt die Postleitzahl eines Objekts nicht durch Ueberpruefung, in welchem Postleitzahlengebiet dieses liegt, sondern mit Hilfe eines Algorithmus, der Abstände zu Zentren von solchen Gebieten bestimmt. Entscheidend auf
ist die Spalte “Distance”. Wie du siehst, liegt 80801 minimal näher am Objekt als 80797 und macht damit das Rennen. Kann man nachrechnen, die GPS Koordinaten der Zentren sind unter “Centre Point (lat,lon)” bei den Gebieten angegeben. (Unterschied sind glaube ich etwa 60m).
@limes11: D.h., die aktuelle Regelung ist “einfach so lassen, bis sich irgendwann seitens Nomatim hoffentlich etwas ändert?” Oder sollte man bei falsch berechneten Objekten die PLZ manuell nachtragen? Das Wiki (https://wiki.openstreetmap.org/wiki/DE:Key:postal_code) empfiehlt ja, die PLZ nicht von Hand pro Objekt einzutragen.
@geri-oc: Mir ist auch aufgefallen, dass 277971324 eine PLZ mit angegeben hat, während die Gebäude haben. Problem ist ja, dass Nomatim bei den Häusern eine falsche PLZ berechnet. Die Änderung gestern hat nach meinem Verständnis keinen Einfluss auf den Fehler.
Das ist im Wiki auf der Seite (Änderung durch geow) etwas sehr unglücklich ausgedrückt.
An Adressen kann und darf (und meiner Meinung nach auch soll) selbstverständlich die PLZ hinterlegt werden, mit dem Key addr:postcode.
Auch postal_code “nicht in Deutschland” zu verwenden, ist eigentlich nicht korrekt. Denn die PLZ-Gebiete in Deutschland verwenden den natürlich. Ansonsten wären ja alle PLZ in Deutschland fehlerhaft erfasst
Die verwenden den aber nur in boundary=postal_code und nicht per postal_code=….
“die PLZ nicht von Hand pro Objekt einzutragen” ist eine Überinterpretation des Wiki-Absatzes, kann aber passieren, wenn man postal_code und postcode nicht genau liest. Für Neulinge ist das aber zugegebenermaßen schon ziemlich verwirrend.
Danke, ich habe die PLZ bei den betroffenen Gebäuden manuell hinterlegt. Ich überlege mir gerade auch eine neue Formulierung für das Wiki, was ich dann auch ändern würde. Wie wäre z.B.:
Klar, schon ein bissel Rechenpower, aber ach Mensch trotzdem rechne ich in Zukunft nicht mit Pi = 3 und freue mich über meine schnellen aber sehr unpräzisen Ergebnisse.
Naja, eindeutig halt kein Fehler somit in den Daten und diese so anzupassen, dass die Anzeige in Produkt xy passt entspricht ja nicht der OSM-Denke. Die PLZ ans Objekt zu packen birgt halt die Gefahr, dass man bei PLZ-Gebietsänderungen halt dann vergisst diese jeweils an den Objekten auch mit zu ändern. Vl. entscheidet ja München mal irgendwann diese Zig-Zack-Linien quer über die Straßenzüge zu begradigen. Schwups hat man dann wieder falsche PLZ-Angaben, diesmal dann aber direkt schon in den Daten.
Daher wäre ich eher dafür Nominatim zu fixen, als PLZ-Angaben zu den Objekten zu ergänzen.
Da meckert aber ganz schnell ein OSMsuspects!
Ich finde das einfachste ist die komplette Adresse. Und warum für die Auswertung etwas einfaches “komplizieren”.
Höre ich da heraus, dass PLZ dasselbe Schicksal ereilen sollte wie associatedStreet—Relationen weg, dafür alles an die Objekte? (PLZ-Gebietsvisualisierungen könnten ja weiterhin per Voronoi visualisiert werden.) Das gefiele mir.
Ich habe auch nie verstanden, weshalb Nominatim damit so große Probleme hat. Offensichtlich ist es simpel, solche Gebietsabfragen für andere Größen durchzuführen, Zitat von https://www.openstreetmap.org/user/lonvia/diary/43143
It is more a textual description where the place is located, in which suburb, city, state, country etc. This information is fairly easy to compute from OSM data. There are areas for all these administrative areas. So Nominatim just needs to check in which areas a place is inside, order all appropriately and there is the address.
In vielen anderen Ländern sind “boundary=postal_code” nicht erfasst oder unvollständig, in diesen Fällen wird man mit Approximationen leben müssen. Wenn allerdings, wie in Deutschland, diese Einträge auf hohem Niveau sind, warum kann dann der Algorithmus nicht bevor er die beschriebenen geometrischen Näherungen anwendet, zunächst nach solchen schauen? Und zwar nicht nach deren Zentren sondern nach den tatsächlichen Grenzen. Wenn das für die anderen Größen fairly easy ist, wieso nicht für die Postleitzahl?
Nein - es gibt PLZ-Relationen und Gebäude/POI mit Adressen. Beides hat seine Berechtigung. So gibt es Gebäude die außerhalb der “importierten” PLZ liegen mit der richtigen PLZ. Da ändere ich schon einmal die Relation - wenn ich vor Ort die Adresse kenne. Außerdem ist QS-Tool Adressen Deutschland eine gute Hilfe.
