Search
Search
Request URI
Request URI | Supported Methods |
---|---|
/v5/search/json | GET, POST |
GET
Please note that GET API only provides basic search function. For full search function (query with filters), please use POST API.
Request Parameters
Name | Description | Required |
---|---|---|
location | Geo-coordinate of the user location (latitude and longitude separated by ","). If parameter anchor doesn't exist, then the location will be used as the search anchor. |
Yes |
anchor | Geo-coordinate of the search anchor point (latitude and longitude separated by ",") | No |
intent | Intent of the search, supported:
|
No |
limit | Number of results in response. Default value: 10 | No |
locale | The preferred language for the response content. | No |
page_context | Parameter to fetch the search results for next page. If page_context is passed in the request, all other parameters will be ignored. | No |
query | Support free text query and multibox query. | No |
show_address_lines | An optional parameter to return formatted address in one or multiple lines. If this parameter is set, "address_lines" will be returned in response. | No |
user_id | The id associated with the user who is sending the request. | No |
1 |
|
POST
The Search POST API provides a powerful flexibility for the developer. Here are some of the search features provided by the API.
- 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. This is 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.
Request Body
Name | Data Type | Required/Optional | Description |
---|---|---|---|
requestParam | EntitySearchRequest | required | Request object to customize the request. |
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 |
|
Response Body
Top-level JSON object:
Name | Data Type | Required/Optional | Description |
---|---|---|---|
status | Status | required | Status |
response_time | Number | required | Response time in milliseconds. |
reference_id | String | required | Reference id associated with response. |
has_more | Boolean | required | Information that can be used to make decision whether to send new request to get additional results or not. If value is "true" then the subsequent call can be made to retrieve more data. If value is "false" then no additional results can be obtained. |
search_metadata | SearchMetaData | Optional | Describes what is returned in the results. |
pagination_context | PaginationContext | Optional | List of convenient URLs. (e.g. link to request previous page or next page) |
results | [ Entity ] | required | List of results that match search criteria. |
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 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 |
|
Status Code
Code | Message | Description |
---|---|---|
12200 | SUCCESS | Indicates that no errors occurred. |
12400 | INVALID_REQUEST | Indicates either that a required parameter is missing or value of a parameter cannot be parsed. |
12500 | INTERNAL_SERVER_ERROR | Indicates technical difficulties on API. |
Onebox Search
Used for free search text with location is around a single point (query and point). Telenav Onebox search is semantic based free text query search. Many different entity types can be searched by providing a text query with support for fuzzy matching capabilities (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.
1 |
|
1 2 3 4 5 6 7 8 9 |
|
Category Filter Search
Used to search by specific category around a specific location. A list of category ids and a geopoint for location need to be provided. Typically 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:
1 2 3 4 5 6 7 8 9 10 |
|
In above category example, adding 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 is 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 the Discover Category API
To use this category filter search the developer must create a CategoryFilter object and add 1 or more category ids to this object. The CategoryFilter object must be applied to a SearchFilters object before the search is executed or called. A geopoint just be set to provide the location context for search.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
Brand Filter Search
Telenav brand filter search feature enables search for specific brands or chains. To use this API you need 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. The Brand Search can be used instead of onebox search when the search intent is known to be for specific brand. Some brands have name variations, so using a brand filter search is recommended for this case.
To use this feature the developer must create a BrandFilter object and add 1 or more brand ids to this object. The BrandFilter object must be applied to a SearchFilters object before the search is executed or called.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
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, and to ensure optimal performance, the count of points in the filter is limited to a maximum of 200.
A corridor filter search is a form of a geo-filter that limits search to the bounds of the provided geometry. The constraining geometry here is the route (represented as a coordinate list) with a buffer applied to each side of the route. The developer creates a CorridorGeoFilter object that includes a list of coordinate points for the route. The CorridorGeoFilter object is applied to a SearchFilters object before search is executed or called.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
Polygon Search
The polygon search feature enables search results to be constrained 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. A common usage for polygon search is limited results to the boundaries of a city or other administrative area. Though it can represent any geographic area. To derive a rectangle from the polygon, the length of the diagonal of the rectangle is limited to a maximum of 300 km.
A polygon filter search is a form of a geo-filter that limits search to the bounds of the provided geometry. The constraining geometry here is the polygon geometry. The developer creates a Polygon object with a list of coordinate points for the polygon. A minimum of 3 points are required. The polygon object automatically closes itself by connecting the first and last point objects.
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 |
|
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. 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. The length of the diagonal of the BBox is limited to a maximum of 300 km.
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 creates a BBox object with two coordinates (bottomLeft, topRight).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
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.
1 |
|
1 2 3 4 5 6 7 8 9 10 |
|
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 it 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. 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 |
1 2 3 4 5 6 7 8 9 10 11 |
|
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 object.
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, set the charger brands in the EVFilter object. 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, set the connector types in the EVFilter object. The below table contains examples of commonly used connector types:
ID | Connector Type |
---|---|
30001 | J1772 |
30002 | SAE Combo |
30003 | CHAdeMO |
30004 | Type 2 |
30005 | Type 3 |
30006 | Tesla |
30007 | NEMA |
30008 | NEMA 14-50 |
30009 | Plug Type F |
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, set the power feed levels in the EVFilter object. Currently supported power levels are:
ID | Power Level |
---|---|
1 | Level 1 |
2 | Level 2 |
5 | DC Fast |
Filter by Customer Charge Level
This feature enables a drive to find EV charge stations by customer charge level such as level 3 which means the maxPower > 15KW, <= 50KW. Used in Europe and Australia. To filter stations by customer charge level, set the customer charge levels in the EVFilter object. Currently supported customer charge levels are:
ID | Customer charge Level |
---|---|
1 | Normal charge, maxPower <= 6kW |
2 | Sem-fast charge, 6KW < maxPower <= 15KW |
3 | Fast charge, 15KW < maxPower <= 50KW |
4 | Super fast charge, maxPower > 50KW |
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, the free connectors are returned. When set to false only, the paid connectors are returned. When set to null, all connectors are returned.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
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.
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
Search By Exit
Request URI
Request URI | Supported Methods |
---|---|
/v5/search/byexit/json | POST |
POST
Request Body
Name | Data Type | Required/Optional | Description |
---|---|---|---|
requestParam | EntitySearchByExitRequest | required | Request object to customize the request. |
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 |
|
Response Body
Top-level JSON object:
Name | Data Type | Required/Optional | Description |
---|---|---|---|
status | Status | required | Status |
response_time | Number | required | Response time in milliseconds. |
reference_id | String | required | Reference id associated with response. |
results | [ EntityExit ] | required | List of results that match search criteria. |
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 |
|
Status Code
Code | Message | Description |
---|---|---|
12200 | SUCCESS | Indicates that no errors occurred. |
12400 | INVALID_REQUEST | Indicates either that a required parameter is missing or value of a parameter cannot be parsed. |
12500 | INTERNAL_SERVER_ERROR | Indicates technical difficulties on API. |