"How to" for the Oneline Search SDK

The Scout SDK OneLine experience is an improvement over the existing search capabilities, allowing users to easily enter a variety of local search queries in a single text box. It has the capability to parse what the users are looking for (business name, address, airport) and to deliver relevant results centered around a set location.

By default OneLine queries OpenStreetMap based results.

Additional search sources may be queries by adding additional 3'rd party search providers (Apple search, Foursquare, Tripadvisor, etc.) - the integration with the 3'rd party data sources will be done client side.

Currently the OneLine API does not identify category searches (searching for "restaurant" or "hotel") or reverse geocoding requests (searching for a coordinate).

It is up to the client to determine that we are dealing with a category search or a reverse geocoding request and redirect the call to the appropriate API (category search /nearby search or reverse geocoding API).

The connected (or cloud version) of the OneLine search will provide the ability to query the entire world at all times: you will be able to search for addresses and POIs in Paris, France even though you are currently in New York, NY, US.

The onboard (embedded or offline) version of the OneLine search provides an experience similar to "connected" but with reduced scope - only the available offline packages will be queried. (one has to have the offline package available locally on the device).

3'rd party search providers may, or may not be available in the embedded mode - availability varying based on provider and the integration details.

For the rest of the document, unless specifically mentioned, we will be referring to the OpenStreetMap powered search capabilities.

When search is performed in a text box, the query will be sent to all available search providers, the results being merged back to one results list when they become available.

The OneLine algorithm does limited query classification (i.e. breaking down "11 Main Street, Sunnyvale, CA" into "11 = door number", "Main Street = Address", "Sunnyvale = City", "CA = State") as it mostly relies on direct text match + scoring algorithm.

This means that the original query "11 Main Street, Sunnyvale, CA" will be treated as text and it will be matched against a number of combinations, both addresses and POIs, and once all the candidate results have returned another scoring session happens, the candidate most similar to the original query (text wise) surfacing on top.

The OneLine search will query both the places (POI) database and the address database trying to match the input string - in the aggregated result list both types of responses, addresses and POIs, will be present.

Since the OneLine tool has very limited logical understanding of the input text (query classification) as it mostly relies on text search, it is important to understand what are the supported input strings and what are the limitations.

I.e. Searching for "McDonalds, San Francisco" will return results while searching for "McDonalds, 235 Front St, San Francisco" will not return any results as the POIs and addresses are not connected in the backend (a POI does not have an address associated to it, only a location).

Below table depicts fuzzy search variations which the SDK offers support:

POI discovery is handled by the nearby search and the category search APIs.

As the user starts typing the system tries to generate relevant suggestions based on matches made based on the partial query. The same matching & scoring rules apply for both complete and incomplete queries.