Improve place search speed by ~10x

[leekleak]

I was testing to see why places search did not work for me but it seems like it was just incredibly sluggish.
The culprit was the around parameter which is very very slow for some reason. I changed it to use a bounding box and that had a huge impact where a simple search of around 4km went from 10s to less than 1 for me.

The only downside is that the radius setting is mostly inaccurate as bounding box parameters are degrees and not meters. I used an approximation where 0.00001deg is around 1.1m, so if the radius is set to 4km, the results will come from around 4.5km radius (actually more since the bounding box is a rectangle and not a circle, so at the extreme you could get results from up to 6.3km)

Not sure what to do with the setting though - maybe make the settings vague to reduce the impression of specificity... Or maybe the results should be filtered out and discarded if they are too far away.

[shtrophic]

The bounding box will have a different size at different latitudes and same settings, correct?

[leekleak]

The bounding box will have a different size at different latitudes and same settings, correct?

Yes. When I looked at approximations the article claimed that the rate is steady in most inhabitable areas, however the more I think about it the less sense that makes. I'll add a conversion tommorow.

[shtrophic]

There are some static convenience methods somewhere in the android.Location class for working with the earth ellipsoid... I don't remember for sure if that was its fully qualified name... Might help!

[leekleak]

Seems like a pretty simple fix. I also added a check to throw away results outside the search radius.

[shtrophic]

If it actually makes it possible to go to downtown new york and query "pizza" with a search radius of 10km, I'm all for it :)

LGTM 👍🏼

[leekleak]

If it actually makes it possible to go to downtown new york and query "pizza" with a search radius of 10km, I'm all for it :)

It does!

Also, just another thing I noticed -- It seems like the results are also different (better!) than before. It looks like the search by name tag currently times out when looking for pizza at nyc leaving only results by brand tag, which are much more rare and thus much farther away.

[shtrophic]

Makes sense.

Osm search could be improved still, ideally with something like a local cache of that bounding box, to run some more advanced queries on. I once had the idea to match for localized user searches and then translate that into a osm category, e.g. a user types "bäckerei", which will then be queries as category:bakery, and so on. Would probably take too much effort though, for such a niche feature... Anyway, thanks for taking the time and looking into my Osm code :)

[MM2-0]

I once had the idea to match for localized user searches and then translate that into a osm category, e.g. a user types "bäckerei", which will then be queries as category:bakery, and so on. Would probably take too much effort though, for such a niche feature..

We already have localized strings for the most important categories. Adding a reverse lookup string matching between string resource and OSM category and including that category in the overpass query actually sounds pretty doable. Not a bad idea at all.

[leekleak]

Actually I think a better idea would be to have a little table of preset amenity types appear when searching (either automatically or whenever you select to specifically search locations). You click the type you want and it searches the nearby features. I think trying to guess what the user wants just from the search input (especially concerning localized text) can be mildly to extremely finicky.

[shtrophic]

I think trying to guess what the user wants just from the search input (especially concerning localized text) can be mildly to extremely finicky.

That's my concern as well. For example, for terms with accents, like "café" we would have to ask ourselves if we'd also accept "cafe". (And I'm sure there are more complicated cases.) Is that easily possible? After all, we cannot keep track of all variations in all languages. Or does weblate make this possible?

Actually I think a better idea would be to have a little table of preset amenity types appear when searching

That's more UI and we already have the filterbar... And I have the feeling that many users don't know how to use that correctly anyway?

[leekleak]

Also, we can't expect an average user to know any osm tags. I myself would get a headache trying to figure out wheter I should write "Shop", "Store", "Grocery" or "Supermarket" as to me they mean the exact same thing.

That's more UI and we already have the filterbar...

I imagined something like this popping up once you specify you will be searching places.

And I have the feeling that many users don't know how to use that correctly anyway?

Oh absolutely! I only understood that I had to press the "Online Results" to search places and wikipedia once I literally opened up the code of the app.

[MM2-0]

That's my concern as well. For example, for terms with accents, like "café" we would have to ask ourselves if we'd also accept "cafe". (And I'm sure there are more complicated cases.) Is that easily possible?

We already do that for the app search, all accents are stripped and some sort of fuzzy matching is applied.

Step 1: Read the available strings from resources and put them in a List<Pair<String, String>> with the appropriate category name as the second argument of each pair.

Step 2: Filter that list using the same string maching logic we apply when we are filtering the list of apps.

Step 3: Add the categories to the overpass query