feat: use user location and map viewport to bias location search results

[ltseng]

The specific feedback from the usability study initially indicated that perhaps we were returning the wrong search results, or that perhaps we were being too conservative with the filters, but we investigated a bit more and found that Mapbox may not actually have the information people wanted, compared to Google Maps or OpenStreetMaps. For example, one participant was trying to find the Santa Fe Mount Baldy peak, but kept being given the Mount Baldy Trailhead near Santa Fe instead. That peak wasn’t shown in Mapbox, but was in Google Maps and OSM. We landed on wanting to give users more information, rather than less.

Current behavior: type=lace,address,street,block,poi

Desired behavior: No filters

[ltseng]

Tagging @david-code @Hanal-code @DerekCaelin @CourtneyLee333 @shrouxm for awareness.

From a quick DM with David, it sounds like the default results aren't very useful, which is why we chose these filters in the first place. I think it would be nice to be able to play with this, but perhaps it would be more useful to use the Search API playground here instead of making a new app update?

[david-code]

From a quick DM with David, it sounds like the default results aren't very useful, which is why we chose these filters in the first place. I think it would be nice to be able to play with this, but perhaps it would be more useful to use the Search API playground here instead of making a new app update?

Yeah, looking a bit closer, I think the reason I removed some topics is because they were missing coordinates associated with the result (i.e. brand). So I think that I was just trying to get the easiest version working. It would be a good idea to compare the Search Playground Lilian linked with the results the app is providing. If there are useful results that our app is not providing, then we should definitely update the app. Might be worthwhile coming up with a bunch of specific search cases to compare with.

[CourtneyLee333]

I notice on our app when I type my address (where I currently am - 47 Haywood Rd) I get a similar but not correct result as the top match, then the other matches are far away: The same thing happens on the Search API playground. But when I select Optional Parameters > proximity > coordinate and use the location icon to choose my location on the map, the results are what I expect:

The Search API does not seem to accept coordinates, but the Geocoding API does. Do we need to provide a toggle for the user to choose search vs. enter coords?

In some quick experimenting with the Search API playground, I don't see a problem with the default, full set of search options. But it also seems that the geocoding API allows for general searches in addition to coords, so maybe that's the better one to use?

[Hanal-code]

+1 on Mapbox Geocoding API. It worked better when explored -- better search suggestions and X button to clear the input field.

However, when I followed the steps of copy & paste the coordinates from Google Map to Mapbox (as we heard from the user), I got 'Latitude out of range' error message. It turned out that Mapbox input fields expects thelongitude, latitude while Google maps and Apple maps displays the coords latitude, longitude -- Is it something we can change easily?

[Google Map: lat, long]

[Mapbox Geocoding playground: long, lat]

[shrouxm]

thoughts:

geocoding is a slightly different use-case than search. geocoding means finding the best possible coordinates for a given address string. reverse geocoding means finding the best possible address string for a given set of coordinates. what the search API does is try to guess which possible address strings you might be intending to find given a (potentially incomplete) address string. so geocoding will work better if you're directly pasting a complete address string, but we can't rely on that API to build the "list of suggestions that gets more accurate the more text you type into the search bar" experience

we haven't set up the mobile app to be location-aware while doing a geographic search yet, so i think that is definitely the next step to try. i'm not sure if the web app is doing that on the 1000L side. there are two ways for the search to be location-aware:

• the way that courtney found, proximity to a given coordinate (in our case, the user's location)
• proximity to the map viewport, so that if users are looking at a location that is far away from their current location, the results are biased towards what would be visible on the screen

a key difference between our experience and other geographic search experiences is that we don't display geographic search results on the map. in other apps, if the list of suggested search results doesn't have what you want, you can hit enter and transition to a mode where all potential results are displayed on the map and you can start refining by moving the map, adding filters, etc. so we're asking those initial results to do a lot more lifting on their own than in other apps, and i'm not sure there's a way to avoid the experience being at least a bit degraded compared to apps that do let you do a more interactive search refinement

in any case we should configure the search to be aware of the user's location and maybe map viewport to start and see how much that helps!

[CourtneyLee333]

Thanks for all that, Garo! Basing proximity on the user's viewport makes sense to me as a good assumption.

[ltseng]

Should this issue be closed in favor of #446?

[shrouxm]

i will close #446 in favor of this since the discussion is more fleshed out here