What's the appetite for a search overhaul?

[ersinakinci]

🚀 feature request

Description

I just started using OsmAnd yesterday and it looks like the weakest link is search. Like most new users coming from Google Maps/Apple Maps/non-OSM search, I found the search results confusing, so I dug into reasons why:

1. Google Maps-style autocompleted, instantly available, highly relevant search depends on a global server infrastructure and a constant connection to that infrastructure. OsmAnd search is offline, which means that any search algorithm's performance is tied to the processing capacity of each device. Even with the right algorithm in place, it may not be reasonable to expect Google-like searches given that OsmAnd needs to run on everything from an iPhone 12 Pro to some 8-year old Android phone.

2. There's no way to search by address unless the address is available in the underlying OSM dataset. This limitation makes sense, but it's surprising coming from Google, which has practically every address in the world.

3. The search interface is split between "Favorites," "Categories," and "Address." "Favorites" is self-explanatory, but the distinction between "Categories" and "Address" is misleading. "Categories" lists location types, which can be used for searching nearby POI's, but more importantly the search field works differently. If I want to find my favorite taqueria by name, searching for El Parasol under "Address" won't bring up any POI's, but under "Categories" it will. So really, "Categories" is a POI's + addresses search--but it's not clear why there's a distinction between the two, which again confuses new users.

4. Search isn't global, it tries to search near your current location on the map. Probably related to point 1.

5. There isn't any tutorial or message in the app that adjusts user expectations. I understand how it may be possible that the developers, perhaps frustrated by hundreds of new users over the years saying "I typed in X address and it didn't work," might resist adding a tutorial. Why should OsmAnd cater to the expectations of, say, a Google Maps user? Should the user not take the time (as I have) to understand OsmAnd and the OSM ecosystem on their own terms? Alas, when we build a product, we must always consider the user first, and from searching the Google Group archives and GitHub issues, it's very clear that many, many new users are frustrated or even turned away simply due to a lack of understanding. A little bit of nudging and education would go a long way.

6. (Unconfirmed speculation): Is it possible that POI's recently added to OSM and made available in the app through OsmLive don't appear in OsmAnd's search results? I purchased an OsmLive subscription because the address I wanted to route to wasn't available in OSM, so I quickly added the location and, an hour later, I was thrilled to see it show up on the app's map. I haven't been able to find that location in the search results, however, which is really frustrating since I can see it clearly in the app. Perhaps a technical limitation?

All this is to say that there appears to be a combination of technical limitations, UI design issues, and perhaps historical/cultural reasons that conspire to make search confusing.

My question is: what's the appetite among the OsmAnd dev team for a complete overhaul of search? I'm interested in taking this on as a side project, but I don't want to start unless there's a real willingness to merge a major change.

Describe the solution you'd like

In an ideal world, I'd like to see Google Maps-style full-text, autocompleted, global place search (or global as limited to the maps downloaded on the user's device).

If the team is committed to keeping the current search engine, I'd like to investigate changes to the UI to make it friendlier for newcomers and, hopefully, more streamlined and predictable.

If the team is open to a new search engine but is concerned about performance on older devices, I'd look into having a dual-engine setup (e.g., bring back the "legacy mode" switch with the current search engine becoming the new legacy).

Describe alternatives you've considered

I looked into OsmAnd alternatives that can parse addresses such as Maps.Me, but none have the other features that I'm looking for (offline-first/privacy-respecting, open source, OsmLive updates).

Some have mentioned third party apps that look up addresses and convert them to GPS coordinates, which can be used by OsmAnd, but this option is too disruptive.

Caveats

Note, I'm just a lone hacker with some wild ideas, crazy ambition and lots of ignorance. But I'm willing to roll up my sleeves and get dirty 😄.

Also, I'm mostly a web developer by trade who's done some iOS development. I haven't done any Android development before. If I were to get started on the iOS version, would an Android dev be able to work with me to port changes?

[vshcherb]

You can even create search algorithm in Javascript / Web and it will be ported through all apps. Unfortunately, you would need to have API to read binary maps. We have that API present in Java and in C++ but probably some ports are doable if you are hungry to try to solve this problem.

[nyanmeister]

I should be able to type a number, and just have the standard search attempt to find existing building numbers (addr:housenumber) based on this. The difficulty of the search problem (which really needs to be solved) seems like it's really being blown out of proportion. The map should be able to easily find an address I've fully entered into the system, without a 4-5 step process that often times still doesn't get the address I've uploaded.

Another good feature if search gets addressed would be to include alternative names, e.g. name:<lg>, short_name, alt_name, old_name, etc.

[littlehelper]

Like @ersinakinci mentioned in the initial post under point 3, I find it confusing too that addresses are shown when selecting "categories" tap. Compared to the "address" tap where only adresses are shown, I would expect that with "categories" tap only POIs would be shown. A possibility to search only for POIs' names without knowing their exact POI category would be very handy as it would prevent from addresses "hidding" (POI) results of interrest.