I’m having trouble getting the search on the website to produce reliable results. Here is an example searching for a peak in Croatia. I enter the exact correct name of the peak and the first 3 results are totally irrelevant to the query. The fourth one is related but instead of it being the actual peak it’s a tourist path that leads to it. I’ve replicated this issue with many different queries and it seems to me that it’s a rare exception to get the first result to be the place I’m searching for.
Is this a known issue? Is this somehow not an issue?
Also, I noticed that the results are better if the map is positioned closer to the place I’m searching for but that behaviour kind of contradicts the very meaning of searching for something …
Here is another example. OSM finds the node with no issues whatsoever. ORS fails to produce anything even remotely usable. Aren’t you guys running off of OSM data? What is the issue here?
yes and no, this is kind of a known issue we’ve also had some internal discussions about alrady.
You can take a look at this document for a bit mor information on why the the search is currently the way it is.
We were using the autocomplete endpoint in our classic client which finds the peak fine but has some inconsistency issues.
Also note this issue in the repository.
If you want to provide further suggestions or information.
“Is this a known issue? Is this somehow not an issue?” → this is more a design decision than an issue. As far as I could verify, it return the best results for most of the cases, but not for 100% of the cases. Other approaches could bring better results for, for example, POIs, but not so gut results for addresses. There is no perfect solution that will bring what the user expects for in the first position in 100% of the cases.
“Also, I noticed that the results are better if the map is positioned closer to the place I’m searching for but that behaviour kind of contradicts the very meaning of searching for something” → actually there is no contradiction. In general it is expected that the search prioritize nearby places. In the global scale there are a lot of redundancies and names that mean something in one place might mean another thing in another country. Additionally, most of the searches are looking for nearby places. But you always have the option to be more specific and type, for example, “Veliki Kabal, Croatia” or its equivalent in Croatian. By the way, other very popular search engine also use an nearby priority approach.
It is important to have in mind that several factors play a role in the search results, like the browser language, the current map center and the way you type the search, if it is more structured or just a plain text. An overall idea is that the application does not know what is the place you are searching for and it will use the information available to try to guess it. In the first case the app has highlighted the results which have an 100% match with the text you entered.
As said by Amandus, if you have suggestions about how to improve the overall results considering the many cases the search has to deal with, please reopen the issue.
First of all thanks guys for having this discussion with me, appreciate it. I really like this project - the features combined with the Outdoors layer make it one of the best OSM-related apps on the web, if not the best one. Maybe that’s the reason the way the search works is bugging me so much
In the global scale there are a lot of redundancies and names that mean something in one place might mean another thing in another country.
Then why don’t you return the point that bears the name that is closest to the viewport position?
But you always have the option to be more specific and type, for example, “Veliki Kabal, Croatia”
No, I don’t. If I’m not anywhere close to Croatia Veliki Kabal, Croatia will not produce anything. Forcing me to drag and scroll all over the place to focus on Croatia to be able to search for that point just because I was just now looking at something somewhere else in EU… is really weird and super user unfriendly. What other “very popular” search engine does that? I’ve tried all of them, including vanilla OSM itself. Every search engine finds the point I’m looking for, pretty much immediately, regardless of where I’m on the map… What ORS does does not even begin to compare to anything I’ve ever experienced on any map web. Example would be awesome if you disagree.
like the browser language
Totally irrelevant. I mean, just because I’m not Croatian my search results are doomed to be less useful… Come on!
An overall idea is that the application does not know what is the place you are searching for and it will use the information available to try to guess it.
Well, if I write in a name of a mountain that has no numbers in it and posibly not even a comma then should it be clear that it is not an address and that you should query for a OSM feature first before trying to decipher the input as an address?
In the first case the app has highlighted the results which have an 100% match with the text you entered.
That’s clearly not true. Just because I typed a name Veliki Kabal you put a place that has a substring(!!!) Kabal in it right in the first place? I’m having really hard time trying to understand when and to whom this could possibly be useful.
A mountain that is in viewport. Exact name supplied. 6th result. Why? How on earth (pun intended) is the first result in any way relevant to what I wrote in the search box? Playing with it further it seems your search algo is useful and reasonably correct only for searching for exact addresses (will find address when exact regardless of where the viewport is focused) and really bad for everything else. You surely can’t consider that satisfactory for most users…? Does it really have to be one or the other? You provide hiking & MTB routing, outdoor maps etc… Such hard focus on building addresses seems counterproductive.
Your blind spot is that you focus too much on what it is that you are searching for, while the search engine has no clue and also has to provide me with results. For example:
No, of course that is not clear. I frequently search for a street name, or a city or village. No numbers, no comma’s, nothing special, just a bit a of text without spaces even. It happens that that bit of text, in my case, is part of an address. In your case it happens to be NOT part of an address. You know you are writing the name of a mountain, but how is the search engine supposed to know that?
Again: No. Language is definitely relevant. Similar words can mean completely different things in different languages, so language IS very important. For example the word “slot” in Dutch means castle, and in English it means a place in a queue for example. In Dutch, there are numerous locations on the map that have “slot” in them, so they are of importance to the search engine. In English, that word would not nearly have as much importance in my search (or at least, it shouldn’t). Language definitely matters as part of the context of the search. And in order to come up with satisfying results, that context in which a search is done is everything. But the search engine has to make guesses as to what that context is.
It’s clear that the way the search results are ordered frustrate you, and of course things could always be better. But take a good look at your own screenshot: the search results are ordered by TYPE of search result: localities and counties first, then venues, then streets. From the venues your search result is the third, and it looks like that happens because it is the furthest away. To me it seems that the ordering takes place as follows: category - distance. Is that misleading? No. Is that different from what you expect? Yes. Is it different than other search engines? From what you are saying, that seems to be the case. I couldn’t say, I haven’t done any comparative research. But there is nothing wrong with doing things differently.
Oh, and what would you prefer: having to scroll the map, or always search worldwide?
or
I sometimes search worldwide, and it is surprising to see how many placenames for example come back from all over the world when I am convinced that there’s only a place in my own country… so where you search IS important. But how else can the search engine know where you are searching, if it isn’t through either the viewport or what you type in for search terms? It can’t read your mind and say: oh, he is looking for something in Croatia, even if his map is centered on Scotland, so you know what: I’ll just give him Croatian results. Unless your browser language is set to Croatian, in that case this could happen. But it still isn’t mind reading.
And the large search engine I mentioned earlier? It would spot me being on a work trip in Germany from my ip adress (from the hotel), so would redirect me to their .de domain and give me all sorts of German results. But I was searching for accommodation for my next trip, in Italy. So results in Germany were, how shall I put it, unhelpful to say the least. Annoying? Yes, very. But again an attempt to use available context to make search results more helpful - which misfired in this case unfortunately.
Maybe a bit of a rambling post, and I hope I’m not offending you (definitely not my intention - on the contrary, I think this is a good and interesting discussion!). I just wanted to point out that some of the things you remark on, are simply very context-sensitive, and that context could be quite the reverse from yours. But the search engine has to assemble that context from what it can see, and that is very little.
