Postleitzahlen werden in der OSM-Suche oft zum falschen Gebiet geordnet, und eine Suche anhand der Postleitzahl ist oft gar nicht möglich.
Beispiel-Suche: “Pleißenbachstraße, Limbach-Oberfrohna” wird gefunden “Pleißenbachstraße, Limbach-Oberfrohna, Zwickau, Sachsen, 09224, Deutschland, Europäischen Union” Die PLZ ist falsch, eine solche Grenze existierte auch niemals. Die Grenze, die ich für derartige Fehler verantwortlich machte - eine Grenze ohne PLZ und die fälschlicherweise um Niederfrohna (ein vollkommen eigenständiger Ort) außen herum führte - habe ich vor 14 Tagen gelöscht. Geändert hat sich seit dem in der Datenbank jedoch nichts. Als Postleitzahlenbuch ist OSM demnach nicht zu verwenden.
OT: Der Tag swimming pool wird in Mapfactor Navigator als POI verwendet. Pleißa sieht daher dort echt lustig aus Das muss ich dort mal posten.
Ich finde in Limbach-Oberfrohna keine Postleitzahl. Möglicherweise benutzt Nominatim dann, wenn ein Punkt nicht in einem Postleitzahl-Boundary liegt, die nächstgelegene Postleitzahlgrenze? Das würde die 09224 erklären.
Vollständigkeit und Fehlerfreiheit sind bei einem offenen und verteilten Projekt nur schwer™ zu erreichen.
.oO( bei geschlossenen und proprietären aber auch. )
Gruß Wolf
Edit: es fängt damit an, das am Ende von “administrative” das “e” fehlt.
Das verstehe ich jetzt nicht: Warum soll dieser Way wegen einer weit entfernten Hausnummer in 09224 sein, wo er doch in Limbach-Oberfrohna (mit der erkannten Postleitzahl 09212) ist? Und was haben “unvollständige Hausnummer-Nodes” damit zu tun?
Ich hab auch nicht verstanden, was Nominatim da treibt und nur auf die Analyseseite verlinkt. Aus irgendwelchen Gründe meint die Suche, dass der Knoten 1201546126 maßgeblich für die PLZ im Suchergebnis ist (Type: place:postcode). Könnte ein Bug sein.
Ich wusste auch nicht, dass es “Verwaltungsgemeinschaften” gibt, bis ich in OSM die meiner Gemeinde gesehen habe (ich wollte deshalb eigentlich auch das Wort unterstreichen, aber die Forensoftware wollte nicht).
Zum Reverten: In JOSM das undelete-Plugin installieren, dessen Dialog aufrufen (iirc im Datei-Menü), die ID der oben genannten Relation eingeben, bestätigen. Vor Hochladen nochmal drüberschauen nicht vergessen (besonders, ob es immernoch geschlossen ist)!
Vielen Dank. Werde mal das Undelete-Plugin installieren. Leider habe ich die Relation ohne nochmal ins Forum zu schauen neu erstellt weil mir das mit dem XML-Download zu kompliziert war. Vielleicht schaue ich dennoch dass ich die Original-Relation wiederherstelle.
Grainau werde ich auch noch ändern. Und für die Postleitzahl werde ich eben Postleitzahlen zu den Hausnummern hinzufügen. In Rußdorf hat das jedenfalls geholfen. Nominatim scheint die Grenzen zu ignorieren.
Du solltestet nicht so pauschal urteilen. Es ist nur einfach sehr schwierig in den Daten zu suchen und dabei sämtliche Hirachien zu berücksichtigen. Daher wird den Adressen oft auch die Straße als Tag und nicht über eine Relation beigefügt. Bzw. man überlässt es erst recht nicht dem Auswerter die Zuordnung des Gebäudes zu einer nahegelegenen Straße zu machen.
Das würde nicht nur viel rechenaufwand bedeuten, sondern führt auch zu Fehlinterpretation.
Die Straßennamen werden ja in der Regel in ein Gebäude mit rein geschrieben, nur Postleitzahl und Ort und Ortsteil fehlen häufig.
Straßen kann man deshalb nicht über Relationen hinzufügen, weil sie nicht geschlossen sind. Man müsste Grenzen für Straßen bauen, das wäre sehr aufwendig und das muss genau sein, dass kein Häuschen, das weitab der Straße doch noch dazu gehört, raus fällt aus dem Straßengebiet. Postleitzahlen sind jedoch geschlossene Gebiete und die Grenzen existieren denke ich mal alle. Allerdings sind die Grenzen oft sehr ungenau, so dass Häuser aus dem Gebiet fallen wenn man sie nicht korrigiert. Vielleicht werden die Grenzen deshalb ignoriert. Hätte OSM genaue Grenzen wäre die Postleitzahl, der Ort und der Ortsteil anhand der Grenzen automatisch zu ermitteln. Nicht vorhanden oder selten vorhanden sind Grenzen für Ortsteile die alle dieselbe Postleitzahl haben.
Die Grenze von limbach ist sehr ungenau und viele Häuser waren wirklich auf der falschen Seite. So nahe Röhrsdorf und extrem an der Grenze zu Callenberg, da diese gewissermaßen unlogisch verläuft.
Also kurz gesagt: Ohne funktionierende und genaue Grenzen braucht man vollständige Adressangaben in jeder Hausnummer.
Relation heisst nicht zwingend Grenzrelation: associatedStreet
Allerdings werden die Grenzen auch nur korrigiert werden, wenn sie nicht ignoriert werden. Nominatim als Referenzimplementierung sollte sie imo beachten.
Du meinst gar keine (also auch keine administrative) Grenze vorhanden? Das liegt dann vermutlich daran, dass Daten für die Einteilung unterhalb von admin_level=8 (Gemeinden) schwerer zu erhalten sind.
Meinst du Postleitzahl- oder Verwaltungs-Grenze? Bei letzterer prüfe vor Verschiebungen unbedingt genau, welche Quelle genauer ist (bei ersterer natürlich auch, aber da sind nötige Korrekturen eher wahrscheinlich).
Würde ich anders sehen: Ohne funktionierende und genaue Grenzen braucht man funktionierende und (hinreichend) genaue Grenzen
Wenn jede Adresse auch PLZ und Ort enthält dann kann jeder Texteditor diese in der OSM Datei finden.
Wenn man sich hier jedoch auf Grenzen verlässt, dann erfordert das entweder große Vorbereitungen oder aber eine Datenbank die damit umgehen kann. Aber wenn schon zwei Informationen von verschiedenen Grenzen geprüft werden müssen, dann wird das auch nicht schneller oder leistungsfähiger.
Wenn man dann auch noch eine unscharfe Suche zulassen möchte dann wird er Suchraum sehr groß.
per Relation/Grenze entweder eigenständig als boundary=postal_code oder als Zusatzangabe an einer administrative-Grenze
im Node/Way/MP des Gebäudes als addr:postcode
Beides zusammen ist theoretisch redundant, in der Praxis aber doch hilfreich.
Die Auswerter tun sich mit postcode am Gebäude viel leichter als per Auswertung ob innerhalb einer boundary. Insbesondere sind die PLZ-boundaries innerhalb Gemeinden oft nur sehr grob, so dass an den Grenzen die Zuordnung häufig nicht stimmt.
Anders sieht es aus, wenn Gemeindegrenzen und PLZ-Grenzen übereinstimmen, da die admin-Grenzen z.B. in BaWü ziemlich genau sind. Da konnte ich mit der Postcode-Map von wambacher (als sie noch verfügbar war) einige falsch getaggte addr:postcode an Gebäuden identifizieren und korrigieren. Das kommt vor allem an Stellen zu tragen, an dem Wohn-/Gewerbegebiete direkt aneinander grenzen. Auf dem flachen Land, wo die besiedelten Gebiete weit auseinander liegen, reicht die PLZ an den Grenzen eigentlich aus.
Wie so häufig ist keine der beiden Methoden für sich allein die einzig wahre.
Grenzen von Gemeinden und PLZ sind durch Gemeindezusammenschlüsse meist schon unterschiedlich. Dazu kommen Grenzen von Verwaltungsgemeinschaften, die auch mehrer Gemeinde- oder PLZ-Grenzen enthalten können. Auch auf dem flachen Land liegen teilweise Gebäude verschiedener Grenzen (Verwaltung, Gemeinde, PLZ) eng nebeneinander.
Die einfachste Methode, auch für Neueinsteiger, ist das setzen des kompletten addr:* Blockes (was allerdings von Nominatim nicht genutzt wird (?) - und durch naheliegende places oder Grenzen “falsch” gefunden wird).
Die beiden unvollständigen Hausnummern-Knoten habe ich jetzt mal in das umgebende Gebäude geschoben (Changeset 18207763) und die beiden Knoten gelöscht. Immerhin tauchen diese beiden Knoten sowie die beiden aktualisierten Gebäude jetzt nicht mehr bei Nominatim auf der Analyseseite auf.
Es ist nicht erforderlich dass die PLZ-Gebiete und Gemeindegebiete übereinstimmen, es reicht, wenn die PLZ-Grenzen Teile der administrativen Grenzen “mitnutzen”. Das muss dann natürlich in eine eigene postal_code-Relation, die sich schnell aus Mitgliedern der admin-Relationen zusammenstellen lässt.
Dass auch auf dem flachen Land bewohnte Gebiete aneinander stoßen können, ist klar. Da ist addr:postcode dann hilfreich. Ich meine nur, dass diese redundanten Tags in weiten Gebieten nicht notwendig bis überflüssig sind.
Fehlzuordnungen per näher liegendem place-Nodes sprechen eher dafür, die place-Informationen nicht an einen mehr oder weniger geschickt gewählten Knoten irgendwo im Gebiet zu heften, sondern in die Gebietsgrenze oder -relation mit aufzunehmen.
Damit kommen wir aber wieder an das Grundproblem, wie stark wir das Taggen an die Fähigkeiten und Probleme der Auswerter wie Nominatim anpassen. Wir taggen zwar nicht für den Renderer, aber auch nicht so gern nur für die Datenbank, sondern für den Nutzer.
Place-Nodes beschreiben -für mich- “places” (Plätze/Lokalitäten): überschaubare Bereiche mit geringer Ausdehnung.
Städte, Stadtteile oder PLZ-Gebiete gehören nicht dazu.
Aus einem Knoten die Eigenschaften einer (undefinierten) Fläche ableiten zu wollen, halte ich für sehr gewagt.
Das muss ich dort mal posten.
)