Open jrharshath opened 10 years ago
+1 - there was some discussion of improving search in this OBA-dev list thread.
From that thread, here's how search on Android currently works:
For reference, here's the OBA Android code that does the following to implement unified search:
- Call routes-for-location API
- Call stops-for-location API
- Combine results in single list
Note that no independent geocoding service is currently used, but it could be added.
The main question here is what search provider we use, and how we rank those results in context of the existing route/stop search results coming from the OBA REST APIs above when displayed to the user.
Main choices for address search provider:
We have options to use all three in OpenTripPlanner Android, but it has no where near the same level of use as OBA.
This would likely be accomplished as part of #25, trip planning.
This is also been requested for accessibility reasons (see https://github.com/OneBusAway/onebusaway-android/issues/355):
Allowing to search by address is really useful for blind users, who can't navigate the map. (I've also heard it requested by sighted Android OBA users.)
This could also be implemented in the context of improved search (https://github.com/OneBusAway/onebusaway-android/issues/309).
I just stumbled on this old issue when looking for something else.
An update - we support address search for trip planning origin and destination via the Google Places API, but the primary search in the app still uses the OBA REST APIs which require inputting stop, route IDs. We can't just switch to Google Places for the main search because we can't input stop, route IDs.
Pelias is a possible option going forward to support address, POI, and ID search.
It seems like the search bar on the OBA app does not support searching for addresses.
My hunch is that users expect the search to work like search works on google maps. I suggest that when an address is searched for, the map pans and zooms to that address, and shows the bus stops close to that address.