Search throws away most results

[Profpatsch]

When I search (with Nominatim) in poor-maps, I get “no results” quite often (even for trivial searches).

e.g. friedberg ludwigstraße 26
There are at least 10 results Nominatim knows, compare: http://www.openstreetmap.org/search?query=friedberg%20ludwigstra%C3%9Fe%2026#map=18/48.35461/10.98271&layers=T

Are you sure you are querying Nominatim right?

[otsaloma]

Poor contains two different Nominatim geocoders: MapQuest (open.mapquest.com) and OpenStreetMap (nominatim.openstreetmap.org). If I remember correctly, MapQuest uses an older version of Nominatim, while OpenStreetMap should be more up-to-date.

I specifically added the OpenStreetMap one because MapQuest seems to have given up on updating, but I didn't dare make it the default because they state that "We are in principle happy for the public API to be used by external users for creative and unexpected uses. However, be aware that the service runs on donated servers and has a very limited capacity."

Regarding your query, it seems to work fine with OpenStreetMap's Nominatim, while MapQuest gives no results. If you change it to "ludwigstraße 26, friedberg", it works fine with both. While these geocoders try to understand many forms, to my knowledge, that comma separated form of increasing generality is more common, usually the preferred one and possibly also faster.

I understand this can be difficult to figure out when seeing only "no results". I'm open to suggestions on how to make it more usable.

Also, note that OpenStreetMap based routers use the Nominatim geocoder with a preference toward the MapQuest one.

[Profpatsch]

Hm, why not use both (or even all?). A user doesn’t know the differences between the providers.

I see two ways to improve the „no results“ screen:

1. Create a developer-chosen preference chain and automatically use the next one when there are no results
2. Use the same chain but start up multiple requests and display them in order of backend preference (maybe with annotations at the start of each new provider if need be). Of course with deduplication.

As a user I’d prefer the second one, since it gives me a greater range of possible results to choose from. Maybe not query all by default, only the first three and add an option to “search additional providers”.

[otsaloma]

1. Create a developer-chosen preference chain and automatically use the next one when there are no results

I think this is the better approach. I already have such a chainer and it's used by the routers. I can just replace the separate Nominatims with that in the Search too. I probably should have done it already back when I added the second Nominatim.

https://github.com/otsaloma/poor-maps/blob/master/geocoders/nominatim.py

2. Use the same chain but start up multiple requests and display them in order of backend preference

Querying multiple providers would be too slow, ordering of results would be bad and deduplication might not be trivial either if the providers use different versions of Nominatim and maybe different versions of OSM data.

[Profpatsch]

Querying multiple providers would be too slow

Hm, there’s futures for that. :) Network IO for small requests is definitely not bounded by bandwidth, but by server response time.

deduplication might not be trivial

That might be, I don’t know how well equality comparison works on OSM objects (I think it might be reasonably sane).

[otsaloma]

Hm, there’s futures for that. :) Network IO for small requests is definitely not bounded by bandwidth, but by server response time.

Yes, true. But either you need to wait for all servers to respond before combing the results and showing them (and thus being always limited by the slowest one) or you need inject new results in while the user is already looking through the list. Both sound bad to me.

[Profpatsch]

Hm, if you already sort the providers by preference, you’d wait for the topmost to return, display that and then display the others once they become available. But maybe that’s an anti-pattern.

[otsaloma]

If the user is already scrolling through the list, then you can't really add them in the order of relevance, you'd need to put entries from later providers in the very bottom. So, e.g. if you search for "something, rome", you'd get

• Results from Rome, Lazio from provider 1
• Results from various US Romes from provider 1
• Results from Rome, Lazio from provider 2
• Results from various US Romes from provider 2

If the user is interested in Rome, Lazio, he'll stop scrolling when he sees those Rome, Georgia, Rome, New York, etc.