|
Hello, When performing searches that yield multiple results, I've noticed what looks like an intuitive ordering in the output. For instance, searching London yields the English capital as first result, as opposed to the London county in Ontario, Canada or the city in Arkansas, USA; searching Manhattan gives the New York City municipality as first result, as opposed to the city in Kansas, USA or the locality in Poland; searching Berlin yields the German capital as first result as opposed to any of the (surprisingly numerous) cities named Berlin in the US. I've also noticed that the Geopy Nominatim client, when configured to return exactly one result, seems to always return the first one. Is it true that results are ordered according to certain criteria? In that case, are the criteria documented? It would actually be helpful for me if this was the case, but I'd love to understand if this is a feature provided by design, a best-effort kind of thing that is provided but isn't guaranteed by the API, or mere coincidence. Thanks! |
|
(Can't seem to add a comment). The default settings are in When you install Nominatim yourself, and added the wikipedia ranking file (described in the install instructions), it will be almost the same as nominatim.openstreetmap.org. There's a difference searching via a browser (e.g. on openstreetmap.org) and via a script (e.g. geopy): a browser will send your preferred language, and the website usually the current viewpoint of the map. That gives additional hints to the ranking. For example if the map is zoomed a London in the United States then London, UK is less relevant. You can set those with the OK, now having a look at
(14 May '20, 17:41)
Shai
|
|
Yes, results are ordered and this is documented in Nominatim's documentation. Of special interest are probably the chapter on Place Ranking and Wikipedia & Wikidata. Great, thank you Jochen, I totally missed that section. So, Place Ranking section describes how places are ranked using search ranks and address ranks, which it states are assigned to places on import. It then explains how may one go about configuring ranks. However, I haven't configured any ranks when I imported data into my database, and judging by the intuition I explained in the original post, ranks definitely seem to have been assigned automatically. In that case, do we know with what criteria? Also, is it the same as the online Nominatim? Thanks again.
(14 May '20, 14:29)
Shai
|
|
Hi everyone, I've got a follow-up issue: The Nominatim search results are displayed in the left side pane on openstreetmap.org. However, at the same time, the map already zooms in on the first result. I assume that this will lead many (perhaps less tech-savvy) users to miss the other search results. As has been said in this thread before, there are ranking mechanisms, so in many cases this behaviour is fine. And in other cases, the user should notice that the map is not showing the desired place and then find the other search results. My issue is with cases where all n search results are equally plausible, and the user is not familiar with the region (which is why he/she uses a map service) so as to recognize an undesired result. Now the first search result only has a chance of 1/n for being the desired result. In these cases, it would make more sense not to immediately zoom in on the first result, but keep the current view, or even display a more prominent notification saying that the search term is ambiguous. Example: Surprisingly many towns, villages, municipalities have multiple cases of double, triple, quadruple occurrences of the same street name, under the same postal code. In Germany, these can be remnants from the nation-wide consolidation of villages into larger municipalities in the 1970s or from the change to 5-digit postal codes in the 1990s. In most towns, such duplicates have been resolved, but in many cases, they have not (e.g., when residents resisted renaming of their street). For example, in the municipality of Burgwedel (postal code 30938, Germany), there are 19 doubles, 5 triplets, and one quadruplet street name ("Hinter den Höfen"), for a total of 57 streets in this small municipality of 20k residents alone. Other cases can quickly be found on the internet, probably in other countries as well. Only the address system of Deutsche Post / DHL properly deals with this and asks for the specific village or district when entering an address for parcel shipment. Most other systems deal with this poorly, Google Maps even shows only one search result. This issue constantly annoys, sometimes endangers the affected residents: Consider streetmap users such as visitors, delivery services, and sometimes even ambulances. Nowadays many of those tend to rely on search engines and go for the result they are given, especially if the map zooms in on one address - just tap on "calculate route" and off you go - probably to the wrong address in another village. Additional address information given by the resident is often omitted by the navigation or address handling systems, or missed by those navigating there. Therefore, my feature request would be to deal with search results differently, if their probability score (?) is the same, and bring this to the user's attention or even force him/her to make a choice, before zooming in on one of the possible addresses. Thanks! 1
This is not a discussion board. Please use https://community.openstreetmap.org or the issue tracker at https://github.com/openstreetmap/openstreetmap-website/issues for your ideas.
(29 Mar '23, 16:55)
Spiekerooger
... but the topic is very closely related to the original topic of this thread. For once someone searches for existing threads before posting, and it still isn't right ;-)
(29 Mar '23, 16:59)
Soundlover
@Soundlover This is not a thread. OSM Help is a Question&Answer platform. One question - multiple answers. Posting a subsequent question as an answer is not supported. In such case please always create a new question.
(31 Mar '23, 08:17)
scai ♦
|
Thanks to both, it doesn't seem like I'm able to upvote your answers :( but I appreciate the help.