Mangelhafte Suchfunktion von OpenStreetmap

WST1961 · 2021-10-27 17:22:22

the-asca wrote:

Ok, dieses "OT Deining"-Beispiel ist kein Beispiel dafür, dass es was in Nominatim oder der Oberfläche zu verbessern gäbe, sondern tatsächlich in den Quelldaten.
Denn Nominatim findet halt "82544 Deining" weil es als einzelner Node erfasst ist. Damit ist aber natürlich Nominatim nicht klar, dass die Häuser rings um (wie weit denn auch?) zu "82544 Deining" gehören. Die Häuser selbst haben halt nur erfasst:
addr:city=Egling
addr:postcode=82544
addr:street=...
addr:housenumber=...
ohne
addr:suburb=Deining
Ist ja dann unklar, dass es der Ortsteil Deining von Egling ist. Teils sind die Häuser auch erfasst mit:
addr:city=Egling
wie die #6 und #4 und dann werden sie auch gefunden.
Also entweder müsste man überall sie so erfassen:
addr:city=Egling
addr:postcode=82544
addr:suburb=Deining
addr:street=...
addr:housenumber=...
Oder aber man gibt die Daten an diesem Way an, welcher alles umschließt?
https://www.openstreetmap.org/way/77813399
Da bin ich mir aber nicht sicher, ob das jetzt so "richtig" wäre oder doch besser eine Relation, welche diesen Way als auch die Node halt umfasst?

Ich weiß es nicht was die bessere Variante ist, die paar Adressen in der Moosstraße hab ich jetzt man mit addr:suburb getaggt.

the-asca wrote:

Des weiteren hattest du einen Typo-Fehler, du hast adr:suburb geschrieben statt addr:suburb. Habe ich eben fix gefixt: https://www.openstreetmap.org/changeset/113023793

Danke, und wieder was gelernt.

Jo Cassel · 2021-10-27 17:50:17

dieterdreist wrote:

[...]
insbesondere dass es Sinn machen soll, in, um, im, nahe bei, in der Nähe von, usw. für jeden einzelnen Suchbegriff erneut komplett zu wiederholen kann ich mir nicht vorstellen. Das müsste man mit einer einmaligen Übersetzung ausreichend beschrieben haben.
Für die Angabe von Synonymen und Pluralformen wäre es vielleicht auch sinnvoller, das übersichtlicher zu sammeln.
[...]

... genau das waren auch meine Gedanken, nach meinem Berg-Test, warum müssen die Einschub-Phrasen abgearbeitet werden, warum braucht es für ein Synonym einen kompletten neuen "Datensatz", wo doch zusätzlich 1x Singular + 1x Plural völlig ausreichen sollten.
(Und mit nur immer genau einem Tag wird sich schwerlich alles korrekt auflösen lassen.)

Den Ansatz die Community da mitwerkeln zu lassen finde ich super, aber als "Übergabeschnittstelle" für einfache Fälle würde ich mir eine einfache Lösung wünschen:
Tag:natural=peak
DE:Singular/Plural: Berg/Berge; Gipfel/Gipfel; Berggipfel/Berggipfel; Berg-Gipfel/Berg-Gipfel;
(Das könnte auch einfach in/mit der jeweiligen Tag-Dokumentation passieren, statt auf abgelegenen Wiki-Seiten)

MKnight · 2021-10-27 21:10:49

WST1961 wrote:

Nachgesehen habe ich schon auf der Website von dooley, aber mir hat sich noch nicht erschlossen, wie mir das helfen soll. Vielleicht mag mich jemand erhellen, Danke.

Ich hatte nicht geschaut, bin davon ausgegangen, dass https://osm-suspects.gbconsite.de/#18/4 … tive-dupes mehr Fehler wirft.
Gerade doch mal geschaut, und das Problem ist: Da aktuell nur recht wenig Adressen dort eingetragen sind, gibt es auch recht wenig Fehler

MKnight · 2021-10-27 21:15:51

Jo Cassel wrote:

Den Ansatz die Community da mitwerkeln zu lassen finde ich super, aber als "Übergabeschnittstelle" für einfache Fälle würde ich mir eine einfache Lösung wünschen:
Tag:natural=peak
DE:Singular/Plural: Berg/Berge; Gipfel/Gipfel; Berggipfel/Berggipfel; Berg-Gipfel/Berg-Gipfel;
(Das könnte auch einfach in/mit der jeweiligen Tag-Dokumentation passieren, statt auf abgelegenen Wiki-Seiten)

Is mir auch aufgefallen, für "in", "in der Nähe von" "bei" usw usf. brauchts imho nicht jeweils 'ne eigene Definition. Eigentlich brauchts gar keine, Suchbegriff XY sollte stumpf alles relevante ausgeben und solche "Füllworte" wegwerfen.

tux67 · 2021-10-29 16:15:12

Hi,

ich weiß nicht ob's hier hinpasst, aber in Mönchengladbach habe ich nach einpflegen der Stadtteilgrenzen durch einen Mapper mal bewusst nach Ortsteilen gesucht. Zur Zeit ist hier eine lustige Gemengelage von place Nodes, landuse=residential mit Ortsnamen und admin boundaries.
Wenn man zum Beispiel nach "Rheindahlen" sucht, findet man nur eine Admin Boundary ( Rheindahlen-Land, West, Mönchengladbach, North Rhine-Westphalia, Germany) , aber nicht den Place node der nur den Namen Rheindahlen trägt oder die Admin Boundary Rheindahlen-Mitte.

Gibt's da irgendeine Hierarchie oder Logik bei der Suche? Die Place nodes finde ich dabei unerlässlich als Bestandteil des Ergebnisses, da Otto Normaluser eher nach dem simplen OT Namen sucht, als den Stadtbezirksnamen (der auch mehrere OT's beinhalten kann).

Gruß
tux67

Jo Cassel · 2021-10-29 18:14:58

tux67 wrote:

[...]m Beispiel nach "Rheindahlen" sucht, findet man nur eine Admin Boundary ( Rheindahlen-Land, West, Mönchengladbach, North Rhine-Westphalia, Germany) , aber nicht den Place node der nur den Namen Rheindahlen trägt oder die Admin Boundary Rheindahlen-Mitte.[...]

Beim Tagging der Grenzrelationen und der zugehörigen place-nodes läuft in OSM öfters was suboptimal...

Es gibt die Grenzrelation "Rheindahlen-Mitte"
https://www.openstreetmap.org/relation/13155289
und den place-node "Rheindahlen"
https://www.openstreetmap.org/node/59970201
beide mit identischen Wikidata-Tag

So ein node lässt sich der Grenzrelation als label oder admin_centre fest zuordnen, vgl.
https://wiki.openstreetmap.org/wiki/DE: … nselemente
was auch unbedingt empfehlenswert ist, und sei es nur um Tag-Dopplung zu vermeiden.
Außerdem würde ich hier der Grenzrelation ein alt_name=Rheindahlen spendieren (oder "Rheindahlen-Mitte" zum alt_name umtaggen) - dann dürfte das auch mit der Suche klappen.

WST1961 · 2021-10-29 20:46:58

MKnight wrote:

WST1961 wrote:
Nachgesehen habe ich schon auf der Website von dooley, aber mir hat sich noch nicht erschlossen, wie mir das helfen soll. Vielleicht mag mich jemand erhellen, Danke.
Ich hatte nicht geschaut, bin davon ausgegangen, dass https://osm-suspects.gbconsite.de/#18/4 … tive-dupes mehr Fehler wirft.
Gerade doch mal geschaut, und das Problem ist: Da aktuell nur recht wenig Adressen dort eingetragen sind, gibt es auch recht wenig Fehler

Danke, zwei Fehler korrigiert.

dieterdreist · 2021-10-29 23:31:44

wie seht ihr das bei place-Flächen für die es keine admin boundary gibt?
Ein Beispiel: https://www.openstreetmap.org/relation/5454344

Soll oder kann man da zusätzlich entsprechende place nodes machen, oder wenn kann man sie auch weglassen?

SafetyIng · 2021-10-30 10:05:12

dieterdreist wrote:

Soll oder kann man da zusätzlich entsprechende place nodes machen, oder wenn kann man sie auch weglassen

Persönlich sage ich, dass man ihn weglassen kann, place=* wird über 1 Mio. mal an Ways und 1/4 Mio. mal an Relationen verwendet. Da sollte man dann davon ausgehen, dass sowas ausgewertet wird.... Wenn nicht, sollte der Datenauswerter sich anpassen.

Jo Cassel · 2021-10-30 10:13:01

dieterdreist wrote:

wie seht ihr das bei place-Flächen für die es keine admin boundary gibt?
Ein Beispiel: https://www.openstreetmap.org/relation/5454344
Soll oder kann man da zusätzlich entsprechende place nodes machen, oder wenn kann man sie auch weglassen?

Mmh ... als Fläche...Da habe ich ehrlich gesagt keine Erfahrung, sehe das aber eher kritisch.
Die Kombination Grenzrelation + place-node (in so einem Fall als label eingebunden) halte ich für besser und auswertungsfreundlicher.

Aber zu italien/Rom kann ich da nichts sagen ... sowas z.B.
https://www.openstreetmap.org/relation/1458218
admin_level=10
population=195867
kommt mir seltsam vor.

tux67 · 2021-10-30 11:45:54

Jo Cassel wrote:

Beim Tagging der Grenzrelationen und der zugehörigen place-nodes läuft in OSM öfters was suboptimal...
...

Danke .. ich hab' mal einen Optimierungs-Feldversuch gestartet ...

dieterdreist · 2021-10-30 22:31:13

Jo Cassel wrote:

Aber zu italien/Rom kann ich da nichts sagen ... sowas z.B.
https://www.openstreetmap.org/relation/1458218
admin_level=10
population=195867
kommt mir seltsam vor.

was ist daran komisch?

Ist so ähnlich wie hier
https://www.openstreetmap.org/relation/16347

Last edited by dieterdreist (2021-10-30 22:36:41)

Jo Cassel · 2021-10-31 11:16:05

... Dort ist hinter der 9 immerhin noch etwas Platz.
Meine Sorge ist, wenn die 10 levels "aufgebraucht" sind, weichen Mapper möglicherweise deswegen auf place-Flächen aus,
obwohl ein durchgängiges admin_level-Schema (+place-node) perspektivisch die bessere Erfassungsmethode wäre, auch und gerade hinsichtlich von Suche und Auswertung.

Zu Berlin, dort ist die admin_level=9-Grenzrelation mit einem place=borough-node verbunden, soweit so gut,
warum diese Relation selbst *zusätzlich auch noch* als place=borough getaggt worden ist, ist mir allerdings schleierhaft.

SimonPoole · 2021-10-31 11:32:28

Jo Cassel wrote:

... Dort ist hinter der 9 immerhin noch etwas Platz.
Meine Sorge ist, wenn die 10 levels "aufgebraucht" sind, weichen Mapper möglicherweise deswegen auf place-Flächen aus,
obwohl ein durchgängiges admin_level-Schema (+place-node) perspektivisch die bessere Erfassungsmethode wäre, auch und gerade hinsichtlich von Suche und Auswertung.
... .

Es gibt nun mal viele benannte Orte die keine administrativen Einheiten sind und einfach was zu erfinden was in Realität nicht existiert, ist nicht sonderlich sinnvoll (ja ich weiss Deutschland geht da seinen eigenen Sonderweg). Sinnvoller wäre es sich auf eine vernünftige Unterstützung von place-Flächen (inklusive Flachen + Zentrum Kombinationen) zu einigen.

dieterdreist · 2021-10-31 14:16:52

nach 10 kommt 11. Wir haben uns damals für 10 entschieden, weil immer eins dazwischen ausgelassen wurde, es könnte ja genauso gut sein, dass man zukünftig irgendwann eine Stufe dazwischen braucht. Übliche admin levels sind hier 2, 4, 6, 8 und ggf. 10

Jo Cassel · 2021-10-31 17:52:50

... Na, dann würde ich die 11 auch nutzen + verbundenen place-node
http://overpass-turbo.eu/s/1czk
aber bitte ohne Doppelung des place=* an der admin_level-Grenzrelation.

(Generell würde ich empfehlen sowas nicht für nur eine Grenzrelation zu machen, sondern soweit möglich für die komplette übergeordnete Gebietskörperschaft. Dies scheint so ein z.Zt. isoliert rumgeisternder Rione-place-node
https://www.openstreetmap.org/node/5566077492
)

dieterdreist · 2021-10-31 19:27:05

Jo Cassel wrote:

(Generell würde ich empfehlen sowas nicht für nur eine Grenzrelation zu machen, sondern soweit möglich für die komplette übergeordnete Gebietskörperschaft. Dies scheint so ein z.Zt. isoliert rumgeisternder Rione-place-node
https://www.openstreetmap.org/node/5566077492
)

für Monti gibt es glaube ich keine Gebietskörperschaft, aber der node ist sowieso eine Doppelung, das Viertel ist hier: https://www.openstreetmap.org/relation/5451988

Jo Cassel · 2021-10-31 20:06:57

... ist mir klar, findet sich ja in der Abfrage in #66.

Dein hinzugefügter alt_name geht in die richtige Richtung,
aber warum nicht alle Rione (einheitlich) zur admin_level-Grenzrelation umtaggen und mit (einheitlichen) place-nodes versorgen/verbinden...

dieterdreist · 2021-10-31 21:05:09

Jo Cassel wrote:

... ist mir klar, findet sich ja in der Abfrage in #66.
Dein hinzugefügter alt_name geht in die richtige Richtung,
aber warum nicht alle Rione (einheitlich) zur admin_level-Grenzrelation umtaggen und mit (einheitlichen) place-nodes versorgen/verbinden...

die Rione waren auch schonmal admin level 10 in OpenStreetMap, allerdings gibt es sie verwaltungsmäßig nicht mehr, das ist alles Municipio I. Ursprünglich war Monti der name und der sperrige Name war official_name. Die Änderung wo der admin level und einfache Name entfernt wurden ist von einem bekannten Remotebesserwissermapper, leider damals ein bisschen spät entdeckt.

Placenodes braucht man dagegen eher nicht, wenn man schon ein Polygon hat, die Nodeposition wäre arbiträr.

Last edited by dieterdreist (2021-10-31 21:07:28)

the-asca · 2021-10-31 21:27:21

Die ganze Seite 3 von dem Thema ist irgendwie recht Off-Topic. Eventuell in ein neues Thema auslagern, sodass hier weiterhin um das Kernthema der Suchfunktion diskutiert werden kann bzw. es auch nachträglich lesbar bleibt, wenn man sich zu diesem Sachverhalt informieren will?
Klar, saubere Daten, verbessern auch die Ergebnisse einer Suche, da aber dann können wir gleich 50% aller Themen hier einfügen ;-)

Jo Cassel · 2021-11-01 11:01:03

@dieterdreist
In der Wikipedia haben die Rione mehrsprachige Artikel - wenn sie in OSM(-Daten) nicht gefunden und/oder angezeigt werden sollen,
dann sollte alles ganz genauso bleiben wie es jetzt ist:
place-Flächen mit kryptischen Namen statt boundaries + place-Nodes;-)

@the-asca
Was die POI-Suche anbelangt hatte ich in #52 (auf Seite 3) eine mögliche Lösung skizziert:
Das Wortfeld wird standardisiert in der zugehörigen Tag-Dokumentation erfasst, am besten in der zentralen Vorlage der jeweiligen Sprachversion.
Wirklich Eingegangen ist darauf bisher niemand, umgesetzt wird es wohl nicht, stattdessen wird weitergewurstelt und weitergemosert;-)

Last edited by Jo Cassel (2021-11-01 11:02:20)

dieterdreist · 2021-11-01 14:33:11

Jo Cassel wrote:

wenn sie in OSM(-Daten) nicht gefunden und/oder angezeigt werden sollen,
dann sollte alles ganz genauso bleiben wie es jetzt ist:
place-Flächen mit kryptischen Namen statt boundaries + place-Nodes;-)

bei den Namen gebe ich dir vollkommen Recht, das mögen ja offizielle Namen sein die man auch beim Lesen gut zuordnen kann, aber mit der üblichen Suche findet man sie so nicht, und der allgemein übliche Name ist auch einfacher, ein oder mehrere alt_name machen daher Sinn.

Dass aber place Objekte nicht gefunden werden wenn sie nicht auf einem Node sind, stimmt nicht, Nominatim findet place polygone und sie sind da auch vorteilhaft (weil die Ausdehnung nicht geraten werden muss). Der OpenStreetMap-carto Stil erwartet zwar glaube ich nodes für place, aber der verliert auch immer mehr an Bedeutung, seit sich die Vektortiles so sehr verbreiten. Bei Mapbox sind die Flächen places drin, bei tilemaker in der Standardkonfiguration bisher noch nicht, aber das wird vermutlich noch kommen.

Last edited by dieterdreist (2021-11-01 14:34:46)

the-asca · 2021-11-01 15:45:11

Kurz ein wenig weitermosern: ;-)

Ich suchte die Pfarrer-Theile-Str 1B, 13591 Berlin und ich erhalte... nichts.
Warum? Es ist sogar mit dieser Hausnummer erfasst: https://www.openstreetmap.org/node/5612339039
Umschließend ist die PostalCode-Relation: https://www.openstreetmap.org/relation/1405891
und die Relation für Berlin: https://www.openstreetmap.org/relation/62422

Es ist auch egal ob "Str" oder Straße" oder "1b" oder "1B" oder mit/ohne Komma. allerdings lasse ich die PLZ und Berlin weg, dann finde ich es direkt:
https://www.openstreetmap.org/search?qu … ile-Straße 1B
mit Beschreibungstext "Haus 1B, Pfarrer-Theile-Straße, Staaken, Spandau, Berlin, 13591, Deutschland"
Irgendwie scheint es sich an dem "Berlin" in der Suchanfrage zu stören. Klar, jetzt kann man sicherlich irgendwas an den Daten schubsen, dass es passt (addr-Tags ergänzen oder so), aber eigentlich ist alles doch gegeben?

In OSM bin ich es echt gewohnt zigfach Suchanfragen zu formulieren, aber das kann halt ja nicht sein.
Davon ganz ab, hat man mir die Addresse geschickt als "Pfarrer-Theile-Str 1.B 13591 Berlin", Immerhin positiv überrascht, dass (sofern ich "Berlin" halt wegnehme) Nominatim der Punkt nicht sosehr stört, als dass es die ganze Straße nicht mehr findet - nur halt das Haus selbst nicht.

Aber wenn halt solch legitime Suchanfragen schon Nominatim aus'm Tritt bringen können, dann stell ich mal gar nicht den Wunsch, dass es auch das Haus finden würde bei Eingaben wie:
"Pfarer-Theile-Str 1B 13591 Berlin", "Pfarrer-Teile-Str 1B 13591 Berlin" oder "Pfarrer-Thaile-Str 1B 13591 Berlin"
Sowas schreibt jemand schnell mal (sei's weil man die Adresse z.B. gesagt bekommt). Ja, wäre schön, wenn dann eben nicht nur "kein Ergebnis gefunden" käme, sondern auch phonetisch gesucht werden würde.

Gruß,
asca

PS: @Jo Cassel: #52 les ich mir in ruhiger Minute nochmal durch, hab ich glaub ich übersehen, wegen dem ganzen OT hier. Will das neue Beispiel nur kurz hier aufschreiben.

Jo Cassel · 2021-11-01 17:40:12

dieterdreist wrote:

[...]
Dass aber place Objekte nicht gefunden werden wenn sie nicht auf einem Node sind, stimmt nicht, Nominatim findet place polygone und sie sind da auch vorteilhaft (weil die Ausdehnung nicht geraten werden muss). Der OpenStreetMap-carto Stil erwartet zwar glaube ich nodes für place, [...]

Dass place Objekte nicht *gefunden* werden wenn sie nicht auf einem Node sind, habe ich nie behauptet.

Aber wird denn ein flächiger place-Name von einem Renderer auch *angezeigt*, angesichts der Namens-Dopplungsgefahr zu den (global weit überwiegenden) nodes?
Das ist imho kein Problem von carto oder von vector-Karten, sondern von OSM-grundsätzlich.
In Rom gibt es wohl großflächig place-Flächen (statt boundaries + place-nodes) und damit auch keine Stadtteil-Beschriftungen - das muss man mögen.
Mein Fall wäre das nicht, dies indirekt so vorzugeben.
(sorry @the-asca, aber das wollte ich noch klarstellen)

dieterdreist · 2021-11-02 01:30:46

Jo Cassel wrote:

Aber wird denn ein flächiger place-Name von einem Renderer auch *angezeigt*, angesichts der Namens-Dopplungsgefahr zu den (global weit überwiegenden) nodes?
Das ist imho kein Problem von carto oder von vector-Karten, sondern von OSM-grundsätzlich.
In Rom gibt es wohl großflächig place-Flächen (statt boundaries + place-nodes) und damit auch keine Stadtteil-Beschriftungen - das muss man mögen.
Mein Fall wäre das nicht, dies indirekt so vorzugeben.
(sorry @the-asca, aber das wollte ich noch klarstellen)

wie gesagt, die werden angezeigt, auch dedupliziert, aber halt nicht von Carto.

Announcement

#51 2021-10-27 17:22:22

Re: Mangelhafte Suchfunktion von OpenStreetmap

#52 2021-10-27 17:50:17

Re: Mangelhafte Suchfunktion von OpenStreetmap

#53 2021-10-27 21:10:49

Re: Mangelhafte Suchfunktion von OpenStreetmap

#54 2021-10-27 21:15:51

Re: Mangelhafte Suchfunktion von OpenStreetmap

#55 2021-10-29 16:15:12

Re: Mangelhafte Suchfunktion von OpenStreetmap

#56 2021-10-29 18:14:58

Re: Mangelhafte Suchfunktion von OpenStreetmap

#57 2021-10-29 20:46:58

Re: Mangelhafte Suchfunktion von OpenStreetmap

#58 2021-10-29 23:31:44

Re: Mangelhafte Suchfunktion von OpenStreetmap

#59 2021-10-30 10:05:12

Re: Mangelhafte Suchfunktion von OpenStreetmap

#60 2021-10-30 10:13:01

Re: Mangelhafte Suchfunktion von OpenStreetmap

#61 2021-10-30 11:45:54

Re: Mangelhafte Suchfunktion von OpenStreetmap

#62 2021-10-30 22:31:13

Re: Mangelhafte Suchfunktion von OpenStreetmap

#63 2021-10-31 11:16:05

Re: Mangelhafte Suchfunktion von OpenStreetmap

#64 2021-10-31 11:32:28

Re: Mangelhafte Suchfunktion von OpenStreetmap

#65 2021-10-31 14:16:52

Re: Mangelhafte Suchfunktion von OpenStreetmap

#66 2021-10-31 17:52:50

Re: Mangelhafte Suchfunktion von OpenStreetmap

#67 2021-10-31 19:27:05

Re: Mangelhafte Suchfunktion von OpenStreetmap

#68 2021-10-31 20:06:57

Re: Mangelhafte Suchfunktion von OpenStreetmap

#69 2021-10-31 21:05:09

Re: Mangelhafte Suchfunktion von OpenStreetmap

#70 2021-10-31 21:27:21

Re: Mangelhafte Suchfunktion von OpenStreetmap

#71 2021-11-01 11:01:03

Re: Mangelhafte Suchfunktion von OpenStreetmap

#72 2021-11-01 14:33:11

Re: Mangelhafte Suchfunktion von OpenStreetmap

#73 2021-11-01 15:45:11

Re: Mangelhafte Suchfunktion von OpenStreetmap

#74 2021-11-01 17:40:12

Re: Mangelhafte Suchfunktion von OpenStreetmap

#75 2021-11-02 01:30:46

Re: Mangelhafte Suchfunktion von OpenStreetmap

Board footer