androidseb / mapmarker

Repository to host the Map Marker app resources (Website, Web App, App Binaries, etc.)
14 stars 2 forks source link

Improve HERE places search API UX to include search results outside of the current map view (i.e. avoid hard-cut filter) #78

Closed cdaller closed 1 month ago

cdaller commented 2 months ago

Redacted description

The HERE places API search results are hard-cut limited to the currently visible map area - this can be improved by making results lean towards the map center instead of being completely cut off.

Original description

After some experiments with the HERE places search I discovered, that the search result heavily depends on the map that is currently shown.

  • Map shows whole Europe and search for "paris" - perfect!
  • Map shows a small part of Austria and search for "paris" - France's capital is not found :-(
  • Map shows western part of China and Kasachstan and search for "paris" - 3 towns named paris are found, but none is the one in France :-)

Sometimes this is really cool to search only in the neighbourhood, but it is also quite unexpected.

Strange also, that using the REST API directly via curl, I find only France's Paris and the rest call does not even include coordinates:

curl "https://geocode.search.hereapi.com/v1/geocode?q=paris&limit=10&apiKey=xxx"

{"items":[{"title":"Paris, Île-de-France, France","id":"here:cm:namedplace:20002128","resultType":"locality","localityType":"city","address":{"label":"Paris, Île-de-France, France","countryCode":"FRA","countryName":"France","stateCode":"IDF","state":"Île-de-France","county":"Paris","city":"Paris","postalCode":"75001"},"position":{"lat":48.85717,"lng":2.3414},"mapView":{"west":2.22383,"south":48.81571,"east":2.4698,"north":48.90248},"scoring":{"queryScore":1.0,"fieldScore":{"city":1.0}}}]}

Which API are you using in the app?

androidseb commented 2 months ago

Hello,

you're correct, the external places search in Map Marker is specific to the current map area visible on screen. Some APIs prioritize search results, some other like HERE cut out results that are out of bounds.

For the HERE source, the app uses the discover API endpoint with the q and in parameters - you can find the API documentation here:

https://www.here.com/docs/bundle/geocoding-and-search-api-v7-api-reference/page/index.html#/paths/~1discover/get

Are you trying to achieve something in particular with this understanding?

cdaller commented 2 months ago

I just wanted to understand, why the search results were quite unexpected for me. Searching for "paris" and not finding the town in France seems quite strange to me. It is nice to get the results ranked in the order of importance or map visibility, but not finding it at all was really unexpected. And this also makes the search for me quite unusable, because you can never rely on the results.

Example: I want to see the map (markers) near a town I know I have been before, but the map is currently showing something completely different. Quick changing the map view to the search result is impossible or at least not reliable.

But ok, I know understand the reasons behind it and will learn to live with it.

Maxbe it is a good idea to use the "geocode" service I used above or even cooler to let the user choose if he wants to search in the curently shown region or globally? What do you think of it?

androidseb commented 2 months ago

Other search sources "skew" the search results towards the current map view, but don't apply a hard filter like the one applied in the HERE API with the in parameter.

I understand this is not a good user experience, so I worked on fixing it - I've improved the app's code to return results from outside the map view as well when searching with HERE maps search now (by using the at parameter instead of in). Results will still be skewed towards the user's map view, but the HERE API forces one of these map view parameters to be present to return results, so this is the most lenient implementation we'll get.

I've made these changes in version 3.10.0_736_beta, you can try out these changes there if you're curious, or wait for 3.10.0 to be live to the public in the next few weeks.

I'll rephrase this Github issue's title and initial description to more appropriately reflect the improvement that was made, but feel free to open a new separate issue if you feel like this is not enough, thanks.