[Erledigt] Nominatim findet die Adresse nicht. Liegt es an label/munic

limes11 · 2020-08-03T12:00:35.000Z

Es wäre vielleicht gut, diese Sache in nur einem thread zu diskutieren. Es wurde in dem anderen ja bereits sehr viel detaillierteres zu der Situation geschrieben.

“Andere Adressen im Ort die vergleichbar sind werden gefunden.”

Andere Adressen wie Objekte in der Kurt-Schumacher-Strasse sind nicht mit der Situation vergleichbar. Entscheidend bei dem angesprochenen Problem ist doch, dass es keine Strasse gibt, die “Aussenliegend” heisst.

dooley · 2020-08-03T12:07:49.000Z

Nur leicht OT: Nominatim ist für mich persönlich ein einziges Drama. Dieses Zusammenreimen von Daten, die so nicht in OSM erfasst sind, wirft ein ganz schlechtes Bild auf OSM.

Ein unbedarfter und ortskundiger Benutzer sucht z.B. die Hauptstraße Offenburg und sieht solche Angaben (CJD, Uffhofen, Bohlsbach, Bleiche) in den einzelnen Suchergebnissen.

Der User schlägt doch die Hände übern Kopf zusammen und fragt sich, was an OSM besser sein soll wie bei den Konkurrenten.

limes11:

Entscheidend bei dem angesprochenen Problem ist doch, dass es keine Strasse gibt, die “Aussenliegend” heisst.

Das sollte doch bei der Suche IN OSM-Daten keine Rolle spielen? Die Adresse wurde so erfasst und muß genau so auch gefunden und ausgegeben werden. Ob eine Straße gleichen Namens existiert oder nicht, ist Sache von QA-Tools, nicht von Nominatim.

Meine Meinung.

EinKonstanzer · 2020-08-03T16:43:12.000Z

limes11:

Es wäre vielleicht gut, diese Sache in nur einem thread zu diskutieren. …

Da geht es aber um was anderes… Eigentlich, ursprünglich…

dooley:

…

limes11:

Entscheidend bei dem angesprochenen Problem ist doch, dass es keine Strasse gibt, die “Aussenliegend” heisst.

Das sollte doch bei der Suche IN OSM-Daten keine Rolle spielen? Die Adresse wurde so erfasst und muß genau so auch gefunden und ausgegeben werden. Ob eine Straße gleichen Namens existiert oder nicht, ist Sache von QA-Tools, nicht von Nominatim. …

Genau und deshalb hat das mit dem “Außenliegend” und der Diskussion nichts zu tun.

Es wird immer besser…

Die Suche nach “Außenliegend 13, Hainburg”

Browsercache, Cookies usw. Löschen
Erste Suche: Treffer ist https://www.openstreetmap.org/node/240041456
“Kartendaten” über das Ebenenmenü aktivieren, und dann wieder deaktivieren
Suchen. Erster Treffer ist jetzt: https://www.openstreetmap.org/way/35284141

Was steckt da für ein Sinn dahinter?

therdt · 2020-08-03T18:05:58.000Z

Meiner bescheidenen Erfahrung nach geht die Lösung tief in die Datenbank hinein.

Kann wer beurteilen, was beim SELECT “Außenliegend 13, Hainburg” tatsächlich in der Datenbank ankommt und wie die Datenbank mit dieser Frage umgeht? Wer kann sowas untersuchen?

SimonPoole · 2020-08-03T21:51:04.000Z

Ihr habt aber auch schon alle den grossen blauen Link oberhalb der Suchresultate gesehen?

Der geht auf https://nominatim.openstreetmap.org/ die Benutzung würde ich empfehlen wenn ihr die Resultate analysieren wollt, aber vielleicht macht ja das wilde Spekulieren mehr Spass.

lonvia · 2020-08-04T07:11:38.000Z

dooley:

Nur leicht OT: Nominatim ist für mich persönlich ein einziges Drama. Dieses Zusammenreimen von Daten, die so nicht in OSM erfasst sind, wirft ein ganz schlechtes Bild auf OSM.

Ein unbedarfter und ortskundiger Benutzer sucht z.B. die Hauptstraße Offenburg und sieht solche Angaben (CJD, Uffhofen, Bohlsbach, Bleiche) in den einzelnen Suchergebnissen.

Wenn jemand ein Christliches Jugenddorf als place=neighbourhood taggt (https://www.openstreetmap.org/node/5699462932), dann kommt halt tendenziell Mist raus. Kann man drüber jammern oder man kann die Daten fixen.

Ich habe vor ein paar Wochen den geographischen Einfluss von place=neighbourhood entschärft, dass wirkt sich aber erst schrittweise auf die Datenbank aus, weil es keinen Neuimport gab. Alles ums CCJD habe ich mal gerade aktualisiert.

Aber das nur so nebenbei.

lonvia · 2020-08-04T07:39:14.000Z

Die Spekulationen hier sind interessant, aber leider völlig irrelevant für die original gepostete Adresse. Der Grund, warum Nominatim die Addresse nicht finden kann, liegt einzig und allein am addr:street=Außenliegend.

Nominatim berechnet die Addresse zu einer Hausnummer nicht vollständig, sondern sucht sich ein Bezugsobjekt, von dem es die Addresse verwendet. Gewöhnlich ist das eine Strasse. Dazu schaut es zuerst in das addr:street Tag und versucht eine Strasse (oder Fussweg oder Platz) in der Nähe zu finden, die den gleichen Namen hat. Wenn es da nichts gibt, dann nimmt es einfach die Strasse, die am nächsten zum Objekt ist. Eine Ausnahme von diesem Algorithmus macht Nominatim, wenn es ein addr:place Tag findet. Dann sucht es nach einem place, landuse oder admin-Boundary mit einem entsprechenden Namen und benutzt das als Grundlage für die Addresse. addr:housenumber und addr:housename werden dann noch für Hausnummer/-name benutzt. Alle weiteren addr:*-Tags an dem Hausnummer-Objekt werden komplett ignoriert.

Im Fall der originalen Addresse gab es also ein ‘addr:street=Außenliegend’. Also hat Nominatim ganz brav eine Strasse namens ‘Außenliegend’ gesucht und nicht gefunden. Da es auch kein addr:place gibt, hat es also die Hausnummer dann einfach der nächsten Strasse, in diesem Fall die ‘L 3065’.

Bei der Suche geht das ähnlich, nur rückwärts. Nominatim macht die Annahme, dass eine Hausnummer immer zusammen mit dem Namen von seinem Bezugsobjekt auftaucht. Sprich, es ist seehr unwahrscheinlich, dass jemand “13, Hainburg” eintippt, wenn er “Hauptstr 13, Hainburg” sucht. Diese Einschränkung sorgt dafür, dass viele unwahrscheinliche Suchergebnisse weggeworfen werden, aber es sorgt eben auch dafür, dass ein Objekt nicht gefunden werden kann, wenn das Bezugsobjekt, wie oben falsch zugeordnet wurde. Nominatim erwartet jetzt also zwingend ‘L 3065 13’ in der Suche, ‘13 Außenliegend’ bringt keine Ergebnisse, weil der addr:street-Tag ja weggeworfen wurde in der Annahme, dass der gleiche Name ja auch im Bezugobjekt auftaucht.

Wie schon im anderen Thread beschrieben empfehle ich, die Addressen mit

addr:place=Hainburg
addr:housenumber=13 Außenliegend

zu taggen. Dann wird die Stadt selber das Bezugsobjekt und ‘Außenliegend’ gehört halt zur Hausnummer. Leider wird das vermutlich ‘Außenliegend 13’ immernoch nicht finden, weil bei der Hausnummer die Annahme darin steckt, dass die Reihenfolge der Worte nicht beliebig ist.

Wer sich mehr dafür interessiert, wie Nominatim Adressen berechnet, dem sei mein Vortrag auf der FOSSGIS 2013 ans Herz gelegt. Was dort erzählt wird, ist immernoch aktuell: https://www.youtube.com/watch?v=f-lGGpuUtOw

dieterdreist · 2020-08-04T07:54:24.000Z

Jeder hat so seine Erwartungen, was Nominatim alles erkennen soll, z.B. in den USA soll wenn die Straße ref=NY 214 getaggt ist und keinen Namen hat, Nominatim erkennen dass das das gleiche ist wie „State Highway 214“, in Italien dass „Viale Guglielmo Marconi“ auch als „Vle Marconi“ oder vielleicht auch (inkorrekt) als „Via Marconi“ gesucht werden könnte, oder „Via XXV Aprile“ als „Via 25 Aprile“ (bzw. anders rum), dass „Via Camillo Benso Conte di Cavour“ als „Via Cavour“ gesucht wird, dass „Via Rosa Raimondi Garibaldi“ nicht „Via Garibaldi“ ist (weil das nach einem viel bekannteren Garibaldi getaggt ist), und dass „Via Alessandra Macinghi Strozzi“ dasselbe ist wie „Via Macinghi Strozzi“ aber keinesfalls „Via Strozzi“.
Außerdem gibt es Gegenden der Welt, wo sich Adressen nicht auf Straßen beziehen, oder wo es Hausnamen anstatt Hausnummern sind, oder Entfernungsangaben statt Hausnummern, und manche Suchen betreffen POI Namen und nicht Adressen, Etc etc.
Das Thema ist extrem kompliziert, dazuhin sind die Angaben sowohl in der Suche als auch in der db oft unvollständig. Wahrlich keine leichte Aufgabe.

dieterdreist · 2020-08-04T08:00:02.000Z

lonvia:

Dann wird die Stadt selber das Bezugsobjekt und ‘Außenliegend’ gehört halt zur Hausnummer. Leider wird das vermutlich ‘Außenliegend 13’ immernoch nicht finden, weil bei der Hausnummer die Annahme darin steckt, dass die Reihenfolge der Worte nicht beliebig ist.

das wiederum wird im Rendering ziemlich sperrig werden

lonvia · 2020-08-04T09:22:59.000Z

dieterdreist:

lonvia:

Dann wird die Stadt selber das Bezugsobjekt und ‘Außenliegend’ gehört halt zur Hausnummer. Leider wird das vermutlich ‘Außenliegend 13’ immernoch nicht finden, weil bei der Hausnummer die Annahme darin steckt, dass die Reihenfolge der Worte nicht beliebig ist.

das wiederum wird im Rendering ziemlich sperrig werden

Auch wieder wahr. Dann weiss ich auch nicht so richtig weiter. Das ganze pass nun wirklich in kein Schema, was wir haben, ausser addr:full. Vielleicht dann so:

addr:city=Hainburg
addr:housenumber=13
addr:full=13 Außenliegend, Hainburg, 63512

Und dann muss halt jemand Nominatim mal addr:full beibringen.

GeorgFausB · 2020-08-04T09:47:42.000Z

Moin,

ich verstehe, dass die (Nominatim-)Suche in den OSM-Daten nicht ganz einfach ist.
Und ich formuliere auch oft etwas sarkastisch und überspitzt, was dann vielleicht als zu scharf rüberkommt - ich versuche mich zu bessern.

Zum Verständnis mal meinen Ansatz, wie ich die Adresssuche betrachte:

Ich verstehe die Adressangaben addr:* als Umsetzung der (geografisch relevanten) verschiedenen Felder in einer postalischen Adresse.
Beschränkt (vorerst) auf Deutschland:

übersetzt

addr:suburb
addr:street addr:housenumber
addr:postcode addr:city

Eine Suche unabhängig von verknüpften Objekten (wie highway=, place=) würde m. E. nur diese Felder in den Adress-Objekten vergleichen und könnte damit alle Address-Objekte finden.

Mir stellen sich daher zwei Fragen:

a) Woraus ergibt sich der Bedarf, das physische Strassen-Objekt einbeziehen zu müssen?
Inwiefern ergeben sich “viele unwahrscheinliche Suchergebnisse”, wenn dies nicht gemacht wird?

b) Woraus ergibt sich der Bedarf, den Ortsteil in addr:place setzen zu müssen, wenn addr:street nicht belegt ist?
Warum geht es nicht mit dem existierenden addr:suburb?

Grüße
Georg

dieterdreist · 2020-08-04T11:21:25.000Z

GeorgFausB:

Woraus ergibt sich der Bedarf, den Ortsteil in addr:place setzen zu müssen, wenn addr:street nicht belegt ist?
Warum geht es nicht mit dem existierenden addr:suburb?

addr:place bedeutet, dass die Hausnummer sich nicht auf eine Straße bezieht, addr:suburb ist dagegen die üblicherweise redundante Angabe eines Stadtteils bei einer herkömmlichen Adresse

lonvia · 2020-08-04T12:20:50.000Z

GeorgFausB:

Ich verstehe die Adressangaben addr:* als Umsetzung der (geografisch relevanten) verschiedenen Felder in einer postalischen Adresse.
Beschränkt (vorerst) auf Deutschland:

übersetzt

addr:suburb
addr:street addr:housenumber
addr:postcode addr:city

Eine Suche unabhängig von verknüpften Objekten (wie highway=, place=) würde m. E. nur diese Felder in den Adress-Objekten vergleichen und könnte damit alle Address-Objekte finden.

Hier sind schon einige Annahmen drin, die problematisch sind.

A) Du hast gerade ein Schema definiert, dass nur auf Deutschland beschränkt ist. Das kann Nominatim natürlich nicht machen, der muss weltweit funktionieren. Das heisst Nominatim müsste die Schemata für jedes Land kennen. Das hat aber keiner je definiert oder dokumentiert. Da kommt man also nicht weiter. Es braucht etwas allgemeineres.

B) Du nimmst an, dass alle Addressen immer vollständig mit allen addr:-Tags versehen sind. Das ist nicht einmal in Deutschland der Fall, ausserhalb von Deutschland wird es noch dünner. Wie soll der Geocoder jetzt feststellen, dass Tags fehlen? Gegen die offizielle Liste vergleichen? Das bringt uns zurück zu Problem A.

C) Du nimmst an, dass alle Addressen in das von dir gewählte Schema passen. Ich denke, das haben wir in diesem Thread schon nachgewiesen, dass das nicht einmal in Deutschland funktioniert.

GeorgFausB:

Mir stellen sich daher zwei Fragen:

a) Woraus ergibt sich der Bedarf, das physische Strassen-Objekt einbeziehen zu müssen?

Es macht die Suche robuster. Dass addr:-Tags selten vollständig sind, hatte ich bereits erwähnt. Dann kann man aus den Strassen- und Boundary-Objekten noch zusätzliche Infos ziehen wie alternative Namen oder Namen in anderen Sprachen. Das wird besonders wichtig, wenn Orte mehrsprachig sind und man nicht überall die addr:-Tags in allen lokalen Sprachen anhängen will. Aber es hilft dir natürlich auch wenn du einen Ort im Ausland suchst. Und letztendlich ist eine postalische Adresse nicht immer das gleiche wie eine textuelle Ortsbeschreibung. Einfaches Beispiel: im deutschen Addressformat oben hast du das Bundesland weggelassen, was völlig korrekt ist. Die Suche sollte aber schon das richtige ergeben, je nachdem ob du “Hauptstr 3, Neustadt, Sachsen” oder “Hautpstr 3, Neustadt, Baden-Würtemberg” suchst.

Und dann gibt es noch einen implementierungstechnischen Grund. Nominatim indiziert zur Zeit ca. 150 Millionen Objekte auf Hausnummer-Niveau. Das macht mehr als die Hälfte der Datenbank aus. Wenn man für alle die vollständig Adresse speichern würde, würde das die Grösse der Datenbank mal eben verdoppeln. Sprich, aus 800GB werden 1.5TB. Das ist nicht wenig.

GeorgFausB:

b) Woraus ergibt sich der Bedarf, den Ortsteil in addr:place setzen zu müssen, wenn addr:street nicht belegt ist?
Warum geht es nicht mit dem existierenden addr:suburb?

Das ist historisch gewachsen. Früher gab es nur das addr:housenumber Tag und die implizite Annahme war, dass es sich auf die nächste Strasse bezieht. Dann hat man festgestellt, dass es auch andere Arten von Hausnummern gibt. Man brauchte also eine explizite Kennzeichung, die sagt, dass sich die Nummer nicht auf eine Strasse bezieht. Natürlich hätte man auch ein anderes bestehendes addr:-Tag nehmen können, aber dann hätte man sich einigen müssen auf welches. addr:city, addr:suburb, addr:block, … Es gibt da einige Varianten, die je nach Land besser oder schlechter passen. Deshalb hat man ein neues Tag genommen, dass jetzt ausdrückt, dass es der ‘Anker’ zur Hausnummer ist unabhängig davon, wie das sonstige lokale Addressformat aussieht.

dieterdreist · 2020-08-04T12:41:15.000Z

lonvia:

Hautpstr 3, Neustadt, Baden-Würtemberg

interessanterweise findet er das nicht (0 Treffer) weil 2 Tippfehler drin sind, korrigiert man die Straße wird es aber gefunden. Könnte man Nominatim evtl. etwas fehlertoleranter einstellen?

Nachtrag: sehe gerade dass es in manchen Sprachen Baden-Wurtemberg bzw Baden-Wuertemberg heißt (bzw so gemappt ist), evtl liegt es daran dass das erkannt wird.

geri-oc · 2020-08-04T13:57:28.000Z

dieterdreist:

Nachtrag: sehe gerade dass es in manchen Sprachen Baden-Wurtemberg bzw Baden-Wuertemberg heißt (bzw so gemappt ist), evtl liegt es daran dass das erkannt wird.

Das ist das Problem - also das (richtig) korrigieren.

dieterdreist · 2020-08-04T15:28:07.000Z

ich spreche die Sprachen nicht, kann da also nicht weiterhelfen

dooley · 2020-08-05T13:25:51.000Z

lonvia:

Wenn jemand ein Christliches Jugenddorf als place=neighbourhood taggt (https://www.openstreetmap.org/node/5699462932), dann kommt halt tendenziell Mist raus. Kann man drüber jammern oder man kann die Daten fixen.

Sorry, aber das halte ich für ne Ausrede. Das Problem, das Nominatim sich für die Suchergebnisanzeige was zusammenreimt, was so einfach nicht stimmt, besteht doch auch mit richtig (als Nodes) getaggten suburbs.

Suche “badenia offenburg” > Suchergebnis No. 3 > Restaurant Badenia, 28, Hauptstraße, Bohlsbach, Offenburg, Verwaltungsgemeinschaft Offenburg, Ortenaukreis, Baden-Württemberg, 77652, Germany

Getaggt beim Restaurant (Node) ist keine Adresse.

Ok ist es wenn man die fehlenden Bestandteile eindeutig herleiten kann, das sind alle Bestandteile außer “Bohlsbach”, weil es dazu Boundaries gibt. Bohlsbach ist als place-Node erfasst und wird zugefügt, weil es zufälligerweise (!) der näheste place-Node ist. Hat mit der Badenia aber mal so garnix zu tun.

IMHO sollte Nominatim darauf verzichten, “zu raten”. Was nicht da ist und auch nicht eindeutig ergänzt werden kann, wird halt nicht angezeigt.

Und zum Problem “Außerhalb”, “Außenliegend”: Die Adressen sind eben so erfasst. Dann sollte man auch diese Angaben verwenden und nicht versuchen, das besser zu machen wie der Erfasser. Verzweigungen in der Art

wenn addr:street dann add:street sonst suche_strasse(koordinaten)

sollte das Problem deutlich entschärfen.

Aber ich jammere lieber.

dieterdreist · 2020-08-05T16:15:45.000Z

dooley:

Ok ist es wenn man die fehlenden Bestandteile eindeutig herleiten kann, das sind alle Bestandteile außer “Bohlsbach”, weil es dazu Boundaries gibt. Bohlsbach ist als place-Node erfasst und wird zugefügt, weil es zufälligerweise (!) der näheste place-Node ist. Hat mit der Badenia aber mal so garnix zu tun.

Ich finde den Versuch, auch aus Nodes noch was herauszuraten, im Prinzip nicht schlecht, besser wäre aber in jedem Fall, place-Objekte auch als Flächen zu erfassen, weil bei place-Nodes fehlt grundsätzlich die wichtigste Information: worauf sich das bezieht außerhalb genau des getaggten Punktes.

therdt · 2020-08-06T15:15:18.000Z

Ich habe jetzt den Thread nochmal komplett gelesen, vor allen Dingen die qualifizierten Erklärungen von lonvia nebst dem … herausvordernden Video über die Hintergründe von Nomiatim (ich habe tatsächlich nicht alles in gänze verstanden).

Subsumierend scheine ich feststellen zu müssen, dass es derzeit keine Möglichkeit gibt, das Haus “Außenliegend 13” regelgerecht zu beschreiben UND dafür zu sorgen, das es durch Nomiatim durch normale Suchanfragen gefunden wird. (wie markiert man einen Thread eigentlich als “gelöst” bzw. “erledigt”?

dieterdreist · 2020-08-06T15:27:59.000Z

es ist ja jetzt nicht erledigt, vielmehr sollte man überlegen ob man nicht speziell für solche Situationen, wo es per Konvention postalische Zusätze gibt, die keinem place oder admin-Objekt entsprechen, einen neuen tag einführen könnte.