Search

[steinbro]

Has anyone in @openscape-community/app gotten anywhere with restoring the location search feature? I was hoping it was just a matter of getting a new API key from Bing Maps or the like, but I'm afraid there's more code that's missing.

[bramd]

I also concluded that it was not just putting in an API key. I'm not really sure what would be the best path forward here:

1. Restore Bing functionality: Bing search never worked well for me in Soundscape. Bings locations are very bad in my region (The Netherlands). Many POIs were missing or outdated, so this would not be my personal preference.
2. Use another commercial service like Google Maps/Places, Google has much better data in my region
3. Use Nominatim: I think we will exceed the API limits and would have to host something if we do this, see https://operations.osmfoundation.org/policies/nominatim/. They also state that it is not yet suitable for autocomplete search, what Soundscape currently implements

[steinbro]

I do like the idea of having search use OSM data as well. Even in geographies with better Bing coverage, it did bother me that there were places in the search results that weren't in the callouts, and vice versa.

It looks like there are a few choices for OSM-powered search: https://wiki.openstreetmap.org/wiki/Geocoding

In particular, Photon looks promising: it's based on Nominatim but supports autocomplete, and has a public API. The ToS are less explicit,, but perhaps it's worth implementing something compatible and figuring out the hosting as needed. https://photon.komoot.io/

[steinbro]

I managed to get search working against the public Photon API server at photon.komoot.io/. You can find this in a new branch photon-search -- feel free to test it out. I'd still like to make it show the full address in the results listing, and to clean up the code a bit.

Note that it's not currently enabled for autocomplete, only for explicit hit-enter searches. If we want to use a public server like this, it's probably friendlier to send fewer requests. But if we wanted to enable it for autocomplete as well, it's just a matter of replicating the same logic that I added to searchWithText in the partialSearchWithText method.

[Oliver2213]

This is awesome! I found and forked a docker container of this (here). It works in my tests; I substituted the global POI database dump with a smaller extract (the entire thing is 69G compressed).
Using the instructions in the README to build and bring up the docker compose project, I can query the container.
If this is the source we want to go with, it would be pretty easy to use this on our servers so we don't risk getting cut off at some arbitrary usage threshold.

[steinbro]

Thanks! This was easier than we feared, thanks to the existence of an appropriate OSM-based tool. The code to render the results was still present -- all we needed to do was fill in the function that returns a list of points of interest from a search term.

The one bug I'd like to fix is that the place name is getting stripped: once you click on a search result, the name shown is just "Near " which is also what shows up if you save it as a beacon. I'm probably just using the wrong class; I picked GenericLocation since it was easy to instantiate, but it's explicitly described as "used for POIs that were created based on the user's current location."

[steinbro]

Upon further investigation, the place name does work sometimes. I think this is a good-enough solution for now, so I merged it.