Wenn ich wirklich die Felswand Pizzeria suchen würde oder den Berg Shell, dann ginge das wahrscheinlich nur mit Nominatim, die Suchmaschinen würden nur Pizzerien „Felswand“ liefern, bzw. Tankstellen und corporate infos.
Aber davon abgesehen, ein Ergebnis weit weg will man schonmal grundsätzlich selten, fast alle Suchanfragen gehen über lokale Themen.
da bekomme ich ein village in Nigeria, eine Residential auf den Philippinen und als drittes einen fast food in Hillingdon greater London und als viertes ein Restaurant in Paris. Auch wenn ich die Siedlungen und Straßen vor den Pois finden will, die Pois will ich lokal, nicht zufällig.
Wenn man dem aktuellen Kartenausschnitt (und in höheren Zoomstufen mit puffer drumrum) noch viel mehr Gewicht geben würde wäre das auf jeden Fall sinnvoll. Dass ich in Rom Pizza suche und nur was in London und Paris finde, daran sollte man doch was ändern, oder?
Wenn man noch einen Ort dazuschreibt sieht es natürlich anders aus, aber ohne Ort ist doch klar dass die Pois lokal sein müssen.
Nominatim hat diese Fähigkeit (Lokailtät des derzeitigen Kartenausschnitts zu beachten), sie wird aber auf der Webseite openstreetmap.org nicht eingesetzt.
Das ist also ein Frontendproblem. Da bräuchte es ein Häckchen in der Art von “nur im Kartenausschnitt suchen” und dann ginge das besser.
Beispiel (Karte auf Hamburg gezoomt und Pizzeria gesucht) mit dem Frontend von Nominatim, wo man es anwenden kann:
Allerdings scheint es da bei Leipzig ein Problem zu haben mit “Copyshop in Leipzig”, da kommt bei mir nur ein Ergebnis, während ich über overpass einige finde: https://overpass-turbo.eu/s/1cmr
Edit: bei “Copyshop in Leipzig” muss ein komisches Problem vorliegen, hier mit einer Nominatim Installation z.B. bei osmap.de funktioniert es (auch wenn da das Frontend die Ergebnisse auf 5 begrenzt).
Also: so mangelhaft wie behauptet, ist in meinen Augen die Suche über Nominatim nicht. Oftmals sind es eher ungenügende Frontends, die die Fähigkeiten von Nominatim nicht ausschöpfen.
Les’ dir allein mal den Betreff dieses Themas durch. Er lautet nicht “Mangelhaftes Suchen mit Nominatim”, sondern “Mangelhafte Suchfunktion von OpenStreetmap(.org/de)”. Aber ist schonmal schön zu wissen, dass Nominatim mehr kann, als die aktuellen Frontends anbieten.
Nichtdestoweniger gibt’s wohl aber auch weiterhin noch Probleme direkt mit Nominatim, wenn wie oben geschildert Errors zurückkommen; bei Erstsuche kein Ergebnis kommt; “komische Probleme” vorliegen; etc. Das trübt halt zusätzlich, sodass OSM-Neunutzer (die nicht einfach Reload machen) halt schnell zu dem Ergebnis kommen “OSM taugt nichts”, was natürlich falsch bezüglich dem Datenbestand ist.
Und du kannst halt nicht von Otto Normal erwarten, dass er sich an eine Suchsyntax für Basissuchen halt hält. Für die meisten ist es nicht verständlich, wenn “Copyshop Leipzig” andere Ergebnisse als “Copyshop in Leipzig” liefert. Otto Normal beschäftigt sich auch nicht damit ob etwas ein “POI” oder nur “ein Objekt” ist und er entsprechend anders suchen müsste. Wenn also das die eine gewählte Suchanfrage von vielen möglichen (und für Otto Normal gleichen) Suchanfragen halt kein Ergebnis liefert - dann heißt es für ihn, dass die gesuchten Dinge nicht in OSM existieren. Findet er sie dann auf anderem Wege, findet er OSM halt kacke.
Das geht mir hier nicht darum irgendwas schlecht zu reden, sondern einfach nur die Sichtweise von einfachen Nutzern darzulegen. Und wie man dem ganzen Verlauf hier entnehmen kann, haben auch regelmäßige OSM-Nutzer mit der/n Suchfunktion(en) ihre Probleme.
Denn wie ich zu Beginn schon schrieb:
Also sollte die Frage lauten: Welche Dinge können wir jetzt konkret tun, damit es aus Nutzersicht besser wird:
Checkbox auf der Webseite für lokale Suche
Hierzu ein Issue am besten erstellen und wenn jemand Webentwicklung kann, am besten gleich Codeänderung dabei vorschlagen
(heißt lokale Suche, dass nur in der BBox gesucht wird? Frage ist halt, ob nicht eher eine einstellbare Umkreissuche vom aktuellen Mittelpunkt sinniger/intuitiver wäre. Denn vl. bin ich gerade sehr nah rangezoomt und erhalte dann ein “hier gibt es nichts”, obwohls nur 400m weiter existiert)
bessere Liste der Suchergebnisse, darunter fällt:
bei Klick wird nicht alles neu geladen, sondern nur die Karte dorthin verschoben, sodass man wieder zurückgehen kann zur Ergebnisliste
(sprich ein Zurück zur Ergebnisliste erzeugt nicht quasi erneut die gleiche Suche, wie es aktuell ist)
sauberes Paging und kein unnachvollziehbarer “mehr”-Button
Option, dass man alle Ergebnisse (ggf. nur der aktuellen Ergebnislisten-Seite) zusammen auf der Karte als Marker sieht
Das sind auch Punkte, die man ebenso als Issue einstellen kann und ideal ein Webentwickler Code-Vorschläge macht[/*]
[*]Stabilität von Nominatim verbessern. Sprich keine 502, keine "gibt keine Ergebnisse" obwohl gleiche Suche kurz später welche liefert (oder ist das ein Frontend-Fehler?), etc.[/*]
[*]Nominatim beibringen Sucheingaben besser zu verstehen. Darunter fällt das Einbeziehen von Übersetzungen, Synonymen und leicht geänderte Schreibweisen von Suchbegriffen.
Idealer weise sollte "Kopieren ", "Kopie ", "Kopierladen ", "Kopierladen in ", "Copyshop ", "Copyshop in ", ... allesamt eben mind. sämtliche Copyshops in halt auflisten (Dass natürlich bei "Kopie " auch noch deutlich mehr Beifang entsteht ist klar und erwartbar, aber eben nicht, dass viele Copyshops wegfallen wie's aktuell ist).[/*]
und 2. könnte ich mich sehen, dass ich mich da reinarbeite. Aktuell privat und beruflich leider kaum Zeit… naja, Weihnachtsurlaub st ja nicht mehr weit
Bei 3. und 4. kann ich außer Theorie und Gedanken nicht mehr zu Beisteuern.
Gruß,
asca
PS: Nachdem jetzt einige Zeit beim Schreiben vergangen ist, kommt nun der 502-Error aktuell nicht mehr… hmm…
Die 502er sehe ich heute auch oft, da scheint Nominatim überlastet zu sein. Das ist ein grundsätzliches Philosophieproblem der fehlenden Zugriffsbeschränkung, die immer wieder zu viele Scraper etc. auf den Plan ruft.
Ansonsten ist die Liste von Dir, the-asca, eine sehr gute Ideenliste der Verbesserungsvorschläge für das Frontend und andere Verbesserungen.
Die Tabellen im Wiki zu den einzelnen Sprachen bei der SpecialPhrases sind sonst ziemlich selbst erklärend.
(Dabei bitte beachten: ist leider manchmal unpraktisch, besser ist <in|in der Nähe von| im|etc.> ). Ok bei z.B. Zahnarzt/Apotheke/Spielplatz, etc., schwierig bei z.B. Restaurant oder Hotel etc. Wenn man da verwendet, dann bitte mit Operator ‘-’ (any).
Warum? Weil z.B. mit Restaurant Roma direkt ein Restaurant namens Restaurant Roma in X gemeint sein kann und nicht alle Restaurants in Rom.
Man könnte eine DB auf Tilebasis aufsetzen, in dem restlos alle Begriffe des jeweiligen Tiles unter dessen Tilenummer gespeichert sind. Je nach Zoomstufe sind ja immer nur eine begrenzte Anzahl Tiles zu sehen. Eine Suchfunktion braucht nun also nur noch die Nummern der sichtbaren Tiles aufrufen und deren Einträge mit dem Suchbegriff abgleichen.
“Bayern” würde also nur gefunden, wenn man auf Europaebene rauszoomt. Hat man auf München gezoomt, wird z.B. der Laden eines bekannten Fußballvereins gefunden und dessen Sportgelände.
Eventuell könnte man überlegen halt dem Nutzer alternative Suchvorschläge zu machen, wenn sich dafür ein Algorithmus findet, wie man aus einer gegebenen Suchanfrage halt Alternativen erzeugt.
Sprich dass halt bei “Restaurant Roma” irgendwo steht (direkt als Link um entsprechende Suche anzutriggern): Meinten sie vl. “Restaurant in Roma” oder “Restaurant bei Roma”?
Da kann man sicherlich was aus den SpecialPhrases-Listen was schaffen. Oder halt gleich im Frontend, dass dieses halt dann diese Suchen gleich mit anstößt, was natürlich für mehr Nominatim-Last erzeugen würde. Aber aus Nutzersicht halt besser gleich Alternativ-Ergebnisse zu sehen.
Warum etwas neues erfinden, wenn’s wohl Nominatim schon kann?
dass es für ein paar wenige Typologien geht und für andere nicht, ist Teil des Problems. Die Nutzer denken, man kann nach POIs suchen (über den typ), weil es manchmal funktioniert.
Kleine Anmerkung … das letzte Mal, als ich da was eingetragen habe( 2017), hat’s 'ne ganze Weile gedauert, bis jemand die Änderungen mit in die aktuelle Suchsystematik übernommen hatte (soweit ich mich erinnere ein manueller, sporadisch angestossener Prozess).
Ja, das ist ein manueller Prozess, der nicht regelmäßig stattfindet. Umsomehr lohnt es sich wohl, die gewünschten Eintragungen drin zu haben, bevor dieser Prozess das nächste Mal durchläuft.
Spätestens wenn Nominatim auf 4.0 springt, dürfte es ein neuladen der Datenbank geben und diesen Moment will man doch nicht verpasst haben.
Gutes Beispiel für die Suche, auf https://openstreetmap.de/karte.html 82544 Deining eingeben und suchen lassen. Es wird der richtige Ort gefunden. Jetzt noch die Moosstr. 8, getrennt durch ein Komma dran hängen und Suchen. Jetzt landet man in (92364 Deining) der Oberpfalz, obwohl es die Moosstr. 8 in 82544 Deining gibt und sogar die Hausnummer getaggt ist. Google Maps hab ich nicht probiert, aber Bing Maps findet es korrekt, zuerst den Ort, dann zusätzlich noch die Hausnummer in der Straße.
Gibt es eine Stelle an die man sich wenden kann? Ist die Programmierung hier so kompliziert um das ‘richtige’ Ergebnis anzuzeigen?
Ich empfehle OpenStreetMap Freunden und Bekannten, wenn ich dann allerdings solche Beispiele genannt bekomme, kann ich immer nur den Kopf schütteln über so eine grottenschlechte Programmierung. Sorry, anders kann ich es nicht nennen.
Deining ist ein Ortsteil von Egling, siehe Wikipedia: https://de.wikipedia.org/wiki/Egling Die Moosstr. gibt es nur in Deining, nicht in Egling. Aber trotzdem wird z.B. im Ausweis Egling, OT Deining eingetragen. Was taggt man dann richtigerweise? Beide Orte? Oder Egling OT Deining?
Dass ich den Ort selbst eingetragen habe, ist richtig. Es wurde mir kein Deining im Dropdown angeboten, deshalb hatte ich Egling genommen. Hab es jetzt auf Deining abgeändert.
Such doch mal nach 82544 Egling und nach 82544 Deining. Bei Egling wird nicht direkt Egling gefunden, sondern ‘weit’ weg vom eigentlichen Egling: https://www.openstreetmap.org/edit#map=18/47.92294/11.51040 In Egling hab ich jetzt den postalcode 82544 nachgetragen.
BTW: Eine Suche auf Bing Maps nach Moosstr.8, 82544 Egling bringt das richtige Ergebnis, die Moosstr. 8 in Deining.
Aus den OSM-Daten ist nicht ersichtlich, dass Deining ein Ortsteil von Egling ist. Eine irgendwie geartete Zuordnung könnte man mit viel gutem Willen durch spatiale Abfragen erreichen, wenn es genau dieses Deining überhaupt als Place- oder administrative Entität in OSM gäbe. Gibt es aber nicht, weil ein Mapper vor einem Monat den place-key gelöscht hat.
Ohne jetzt Dein spezielles Problem besonders analysiert zu haben, im Wiki gibt’s da Beschreibungen dazu, das muss man nicht im Forum erfragen. Hint: addr:city und addr:suburb könnte Abhilfe schaffen oder bei dooley mal den Link in der Signatur klicken und auf Deinen Bereich zoomen. (Oder beides)
Grundsätzlich, auch wenn man mit iD unterwegs ist, sollte man das Wiki beachten. Da gibt es eine nette Seite, die das mit den Adressen IMHO recht gut erklärt: https://wiki.openstreetmap.org/wiki/DE:Key:addr
In dem Fall wäre addr:city = Egling und addr:suburb = Deining wohl nicht verkehrt.
