[Talk-at] OSM Nominatim Adress Suche in Wien

wolfbert osmbox at posteo.de
Sun Feb 18 20:24:56 UTC 2018


Johann, das ist exakt, worauf ich in meinem vorigen Post hinaus wollte: es ist ** irrelevant ** was die Adress-Suche liefert, das ist ein Problem von Nominatim (es würde schon reichen, wenn es  zusätzlich zur Allerweltssuche eine strukturierte Maske nebst Indizes gäbe, dann wäre das alles kein Thema). 

 

Unsere Aufgabe ist es, die Daten möglichst strukturiert und auswertbar bereit zu stellen. Befindet sich auf einem Punkt address:unit, dann kann man zur Suche z.B. wie folgt vorgehen (hierarchisch vom Spezifischen zum Allgemeineren, und in Kombination; gemappt wird umgekehrt):

 

·         (Prio 3) Man beachte die weiteren Adressdaten auf diesem Punkt,

·         (Prio 2) die Adressdaten des Gebäudes auf dem Umriss,

·         (Prio 1) die Adressdaten in Relationen und umgebenden Polygonen, (-> Anlage)

·         (Prio 4) an nahen Adresspunkten innerhalb des Umrisses,

·         (Prio 5) ev. noch interpolierte Adressen / anliegende Straßen,

·         ev. Ergänzung noch fehlender Bestandteile (z.B. aus PLZ-Relationen, nahen Straßen, etc.)

 

Lautet die Hausnummer auf „*/*“ dann legt man addr:unit eben implizit an.

Wenn das alles noch nicht reicht, und es tatsächlich zwei Adressen auf gleicher Ebene gibt, dann bliebe noch Friederichs Vorschlag mit den Identadressen. In der Suche können alle diese Adresskombinationen gefunden werden. 

 

Zur Veranschaulichung siehe z.B. die Adresse Vorgartenstraße 158-170/11 (https://osm.org/go/0JrJmG1KX)

Mit obigem Verfahren ergibt sich:

 

·         Vorgartenstraße 158-170/11 (die offizielle Adresse)

·         Vorgartenstraße 164/11 (alternativ/halb-offiziell und genauer für den Zusteller)

·         Jungstraße 9/11 (auch damit kommt man hin)

 

Was mich dazu bringt, dass komplexe Anlagen mit Ortskenntnis und manuell modelliert werden sollten, und nach einem Schema (das aber verschiedene Wege zulässt). Überspezifikation (also z.B. komplette Adresse auf allen Stiegen) ist unschön, aber kein Hindernis (der Renderer z.B. hat es aber ungleich schwerer, weil er ermitteln müsste, was denn nun die „gemeinsame“ Adresse ist, um dann die redundanten Bestandteile weg zu lassen – in obigem Beispiel gibt es 158-170 ja auch mehrfach, weil die Anlage implizit in der gemeinsamen Hausnummer steckt).

 

So, das wurde wieder viel zu lang, LG

Wolfgang

 

 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.openstreetmap.org/pipermail/talk-at/attachments/20180218/686fd92f/attachment.html>


More information about the Talk-at mailing list