Search
The search package provides all of the classes for search. Search is the most powerful set of classes and provides much flexibility for the developer. Following are some of the search features provided by the classes.
- Onebox search - Location based semantic search finds POIs (points of interest) and addresses using free text or tagged query syntax. Advanced semantic knowledge and underlying search technology provide highly relevant search results by simply entering a free text query in a single text field (one-box). This is the foundation of Telenav search and great search flexibility.
- Category filter search - Enables POI search by specific category. Telenav supports over 100 POI categories.
- Brand filter search - Enables POI search by specific business brand name or chain name.
- Corridor search - Enables POIs to be found within a specific corridor; also called "Search Along Route" to constrain search results to places near driver's route.
- Polygon search - Constrains search results to any polygon shape.
- Bounding box search - Constrains search results to a rectangular bounding box.
- Reverse geocoding (RGC) - RGC service returns an address based on a coordinate (latitude/longitude) value.
- Voice Search - Enables support for free text and structured text queries for voice search use cases.
- Electric vehicle charge station search - Specialized search services for electric charge stations.
- Anchor search - To specify search location if the search location is different from the current vehicle position.
Please see the API reference for the main classes related to Search.
Onebox Search
Use the one box search method when search input is provided in the form of free search text and location is around a single point. At a minimum developer needs to provide query and point. Telenav one box search is semantic based free text query search. Many different entity types can be searched by providing a text query in the .setquery method. Search supports fuzzy matching capabilities such that the query does not need to exactly match desired search entity. The onebox text parser can identify the following entity types from the free form query text:
- Address (full or partial)
- Point of interest (exact or inexact match)
- Category name (including synonyms)
- Street (with or without street type)
- City In addition to these entity types, additional query patterns can be supported such as querying street intersection, POI name in city, etc.
Fuzzy one box: Note that query does not need to be exact as semantic search will consider approximate names and ‘fuzzy match’ entities which are similarly named.
Key methods
Method | Details |
---|---|
location(location: TNEntityGeoPoint) | A geopoint value of the user’s location using geographic coordinates of latitude and longitude. For example, TNEntityGeoPoint(lat: 0, lon: 0) |
query(query: String) | For one box search this value is free-text query. Query can support search for an address, point of interest (POI), street, or city. In addition, there are additional more complex search patterns which are supported. Query search patterns are localized so expected search patterns for supported locale are accepted. |
Search API sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Response example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
|
Category Filter Search
The category filter search enables search by specific category around a specific location. To use category search the developer needs to provide a list of category ids and a geopoint for location.
Category filter search is often used when HMI interface includes buttons or category hierarchical interface allowing user to select desired POI category such as restaurant, fuel, or parking.
Telenav POI categories support a hierarchical model with parents and child nodes. A child node will only return POIs which belong to the category of that node. If a parent category calls in the service then all children within that parent will be returned in the service. Consider below example: Parent (2041) Restaurant (226) Steakhouse (267) Pizza (263) Mexican (261) .... Coffee and Bakery (890) Bagels and Donuts (230) Bakeries (231) Coffee (241)
In above category example, add category id 2041 to category filter will produce a results list including POIs with categories of all restaurants and coffee/bakery POIs. If category 226 added to category filter then result entities include POIs of categories restaurants of various styles and cuisine types. If category id 263 is added to category filter then only pizza POIs will be in the result entities list.
The list of supported categories and their ids can be retrieved using TNEntityClient.getCategories()
To use the category filter search, the developer must invoke the .categoryFilter(ids)
method of TNEntitySearchQueryBuilder
with ids: Array<String>
containing 1 or more identifiers of category.
Key methods
Method | Details |
---|---|
location(location: TNEntityGeoPoint) | A geopoint value of the user’s location using geographic coordinates of latitude and longitude. |
categoryFilter(categoryIDs: [String]) | The category IDs array |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Brand Filter Search
Telenav brand filter search feature enables search for specific brands or chains. To use brand filter search the developer needs to build a list of brand ids and provide a geopoint for search anchor location. Using a brand search enables all POIs that belong to the brand to be part of entities results list even if the brand may have name variations. Telenav supports hundreds of popular consumer brands across categories such as food, coffee, hotels, restaurants, fuel, and other. Such brands include Starbucks, Chipotle, Subway, HIlton, Best Buy, Nordstrom, Chevron, and many others. Use brand search instead of onebox search when search intent is known to be for specific brand. As some brands have name variations using a brand filter search is recommended for this case.
To use the brand filter search the developer must invoke the .brandFilter(brandIDs)
method of TNEntitySearchQueryBuilder
with brandIDs: Array<String>
containing 1 or more brand identifiers.
Key methods
Method | Details |
---|---|
location(location: TNEntityGeoPoint) | A geopoint value of the user’s location using geographic coordinates of latitude and longitude. |
brandFilter(brandIDs: [String]) | Array of brand ids |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 |
|
Response example
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 |
|
Corridor Search
The corridor search features enables developer to apply a search buffer which is limited to an area which is within a buffer range of driver’s current route. This feature is also referred to as "Search Along Route". Either a place keyword query, category filter, or brand filter must also be supplied to indicate the search intent within the corridor. A prerequisite of building this filter is acquiring a route. The route is acquired from a separate service from search and is typically represented in the form of a polyline (list of coordinates). The developer needs to apply a buffer width (in meters) to the route.
A corridor filter search is a form of a geo-filter. A geo-filter limits search to the bounds of the provided geometry. In the case of corridor search the constraining geometry is the route (represented as a coordinate list) with a buffer applied to each side of the route. To build a corridor filter, the developer uses the .corridorGeoFilter(_route, routeWidth)
method of TNEntitySearchQueryBuilder
. The parameters to be passed in are _route: Array<TNEntityGeoPoint>
containing an array of geopoints representing the route and routeWidth: Double
containing a double value representing the buffer width.
Key methods
Method | Details |
---|---|
query(query: String) | Free form search text indicating search intent Note: category or brand filter can be used in place of query text |
corridorGeoFilter(route: [TNEntityGeoPoint], routeWidth: Double) | The corridor geofilter created above, and route width. |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Polygon Search
The polygon search feature enables search results to be constrained to within the spatial boundaries of the respective polygon. Either a query, category filter, or brand filter must also be supplied to indicate the search intent within the polygon. The polygon can represent any area although it is recommended that the polygon size is kept to a plausible search extent to reasonable fill the polygon area with entity search results. Although the polygon can represent any geographic area, a common usage for polygon search is limited results to the boundaries of a city or other administrative area.
A polygon filter search is a form of a geo-filter. A geo-filter limits search to the bounds of the provided geometry. In the case of polygon search the constraining geometry is the polygon geometry. To build a polygon filter the developer uses TNEntitySearchQueryBuilder
and passes array of TNEntityGeoPoint
. A minimum of 3 points are required and the polygon object automatically closes itself by connecting the first and last point objects.
Key methods
Method | Details |
---|---|
query(query: String) | Free form search text indicating search intent Note: category or brand filter can be used in place of query text |
polygonGeoFilter(polygon: [TNEntityGeoPoint]) | The polygon geofilter created above |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Bounding Box Search
The bounding box search feature enables search results to be constrained within the spatial boundaries of the respective rectangle. Either a query, category filter, or brand filter must also be supplied to indicate the search intent within the rectangle. The rectangle can represent any area although it is recommended that the rectange size is kept to a plausible search extent so the search results can reasonably fill the rectangle area with entity search results. Although the rectangle can represent any geographic area, a common usage for rectangle search may be a user drawn search area or limiting results to a given map zoom level or map extent.
A bounding box search is a form of a geo-filter. A geo-filter limits search to the bounds of the provided geometry. In the case of bounding box search the constraining geometry is the rectangle geometry. To build a bounding box filter the developer uses the bboxGeoFilter()
method with two coordinates (bottomLeft, topRight).
Key methods
Method | Details |
---|---|
query(query: String) | Free form search text indicating search intent Note: category or brand filter can be used in place of query text |
bboxGeoFilter(bottomLeft: TNEntityGeoPoint, topRight: TNEntityGeoPoint) | The rectangle geofilter created above |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
Radius Search
The radius search constraints search to the radius around specified point.
Key methods
Method | Details |
---|---|
query(query: String) | Free form search text indicating search intent Note: category or brand filter can be used in place of query text |
location(location: TNEntityGeoPoint) | A geopoint value of the user’s location using geographic coordinates of latitude and longitude. For example, TNEntityGeoPoint(lat: 0, lon: 0) |
radiusGeoFilter(radiusInMeter: Double) | Radius in meters around location |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 10 11 |
|
Reverse Geocoding
Reverse geocoding (rgc) provides methods to convert a geographic coordinate into a real world address. When using rgc the only entity type returned is an address. RGC is useful when application needs to display an address (or city) from a given location.
To instruct the search request to utilize reverse geocoding the search intent must be set for rgc and the location as a geopoint must be provided.
Key methods
Method | Details |
---|---|
location(location: TNEntityGeoPoint) | The coordinate used to RGC to equivalent address |
searchOptions(searchOptions: TNEntitySearchOptions) | The coordinate used to RGC to equivalent address |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
RGC also support returning both Address
and Place
, it's triggered by setting latitude,longitude
as query parameter.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Voice Search
Search supports both free text and structured text queries for voice search use cases. Typically, a speech to text engine will accept voice input and convert into text; the converted text can be ‘parsed’ with tags assigned and sent as a query to search as structured (tagged) text or ‘unparsed’ and sent as a free text query. The Search API supports such structured text with tags and a speech to text engine can use these tags to build a structured query.
Query Tags
Tag | Description |
---|---|
WHAT | Tag used for POI name, chain name or category label. |
WHERE | Tag that indicates a full address or partial address including street and/or city. |
CATEGORYID | Id of the identified category. |
ALT_WHAT | Alternate homophonic WHAT |
ALT_WHERE | Alternate homophonic WHERE |
; (semi colon) |
Tag separator |
|| (double pipe) |
Homophonic group separator |
("Alternate homophonic" words are alternate words for the same sound)
Query Syntax
query=tag1=v1;tag2=v2||tag3=v3;tag4=v4;...
- Query Example
Voice Input | Search Query |
---|---|
Find McDonald's | WHAT=McDonald's |
Find Restaurant | CATEGORYID=226 |
Find Great America Parkway | WHERE=Great America Parkway |
Find Restaurant near Great America Parkway | CATEGORYID=226;WHERE=Great America Parkway |
Find McDonald's near Great America Parkway | WHAT=McDonald’s;WHERE=Great America Parkway |
Find McDonald's restaurant near Great America Parkway | CATEGORYID=226;WHAT=McDonald's;WHERE=Great America Parkway |
- Query Examples (with homophones)
Voice Input | NLU Candidates | Search Query |
---|---|---|
Find McDonald's | POI: McDonald's | Mac Donalds | MacDonald's | WHAT=McDonald's||ALT_WHAT=Mac Donalds||ALT_WHAT= MacDonald's |
Find Fischer Street | Street: Fisher Street | Fischer Street | Ficher Street | WHERE=Fisher Street||ALT_WHERE=Fischer Street||ALT_WHERE=Ficher Street |
Find McDonald's near Fischer Street | POI: McDonald's | Mac Donalds | MacDonald's Street: Fischer Street |
WHAT=McDonald's;WHERE=Fisher Street||ALT_WHAT=Mac Donalds;ALT_WHERE=Fisher Street||ALT_WHAT= MacDonald's;ALT_WHERE=Fisher Street |
Find McDonalds near Fischer Street | POI: McDonald's | Mac Donalds | MacDonald's Street: Fisher Street | Fischer Street | Ficher Street Note: if there are various combinations, preferably use only top 3 alternatives |
WHAT=McDonald’s;WHERE=Fisher Street||ALT_WHAT= McDonald’s;ALT_WHERE= Fischer Street||ALT_WHAT= MacDonald’s;ALT_WHERE=Fisher Street |
Sample Code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
|
EV Charge Station Search
There are specialized classes available specifically for electric charge station category. These classes enable filtering search by important characteristics for the electric vehicle driver. In addition there are classes which are associated with entity details of a charge station such as connector types, connector counts, power feed type, and charge network (brand).
To build these features the developer will use the EVFilter class.
Filter by Charge Network
This feature enables a driver to find EV charge stations for a specific charging network such as Chargepoint or EVgo. To filter charge station search by network use the .evFilterChargerBrands
method within TNEntitySearchParamsBuilder
.The following table shows some common charge networks and their respective ids:
ID | Charge Network |
---|---|
99100001 | ChargePoint |
99100002 | Blink |
99100003 | eVgo |
99100010 | ElectrifyAmerica |
Filter by Connector Type
This feature enables a driver to find EV charge stations by specific connector type such as J1772, CCS, etc. To filter charge stations by connector type use the .evFilterConnectorTypes
method within TNEntitySearchParamsBuilder
. The below table contains examples of commonly used connector types:
ID | Connector Type |
---|---|
30001 | J1772 |
30002 | SAE Combo |
30003 | CHAdeMO |
Filter by Charge Level
This feature enables a drive to find EV charge stations by specific power (charge) level such as Level 2 or DC Fast. To filter stations by charge level use the .evFilterPowerFeedLevels
method within TNEntitySearchParamsBuilder
. Currently supported power levels are:
ID | Power Level |
---|---|
1 | Level 1 |
2 | Level 2 |
5 | DC Fast |
6 | Ultra Fast |
Filter for free chargers
This feature allows users to find EV charge stations that are free to use. When this filter is set to true only free connectors are returned, when set to false only paid connectors are returned, and when set to null all connectors are returned.
Filter by power
This feature enables a drive to find EV charge stations by specific power range in KW. To filter charge stations by power use the .evFilterMinPower
& .evFilterMaxPower
method within TNEntitySearchParamsBuilder
.
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
EV feature also supports two special search:
Exclusion filter: Specify the EV network to be excluded.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Searching by OCPI location ID:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Anchor Search
Usually the location used for current vehicle position (CVP) and search point is the same. When the vehicle position and the desired search location are not the same, the search location can be specified by setting parameter anchor
.
- If both
location
andanchor
exist:location
will be used as current vehicle position to calculate driving distance and driving time.anchor
will be used as search location.
- if only
location
exist:location
will be used as the current vehicle position and search position.
Key methods
Method | Details |
---|---|
query(query: String) | Free form search text indicating search intent Note: category or brand filter can be used in place of query text |
location(location: TNEntityGeoPoint) | A geopoint value of the user’s location using geographic coordinates of latitude and longitude. For example, TNEntityGeoPoint(lat: 0, lon: 0) |
anchor(location: TNEntityGeoPoint) | A geopoint value of the search location using geographic coordinates of latitude and longitude. For example, TNEntityGeoPoint(lat: 0, lon: 0) |
Sample code
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|