Calculate Route
Important notes:
- This TomTom Orbis API is in public preview.
- This API is powered by TomTom Orbis Maps.
- See the TomTom Orbis Maps documentation for more information.
Purpose
The Calculate Route service calculates a route between an origin and a destination, passing through waypoints if they are specified.
- The route will take into account factors such as current traffic and the typical road speeds on the requested day of the week and time of day.
- Information returned includes the distance, estimated travel time, and a representation of the route geometry.
Run this endpoint
You can easily run this endpoint. Go to the TomTom Routing API Playground page and follow the directions.
Request data
HTTPS method: GET
POST
Constants and parameters enclosed in curly brackets { } must be replaced with their values.
Generic request format
1https://{baseURL}/maps/orbis/routing/calculateRoute/{routePlanningLocations}/{contentType}?key={Your_API_Key}2&apiVersion={integer}3&maxAlternatives={alternativeRoutes}4&alternativeType={alternativeType}5&minDeviationDistance={integer}6&minDeviationTime={integer}7&supportingPointIndexOfOrigin={integer}8&routeRepresentation={routeRepresentation}9&vehicleHeading={integer}10§ionType={sectionType}11&routeType={routeType}12&reconstructionMode={reconstructionMode}13&traffic={traffic}14&avoid={avoidType}15&travelMode={travelMode}16&vehicleEngineType={vehicleEngineType}17&vehicleWeight={vehicleWeight}18&constantSpeedConsumptionInkWhPerHundredkm={ElectricConstantSpeedConsumptionPairs}19¤tChargeInkWh={float}20&maxChargeInkWh={float}21&accelerationEfficiency={float}22&decelerationEfficiency={float}23&uphillEfficiency={float}24&downhillEfficiency={float}25&consumptionInkWhPerkmAltitudeGain={float}26&recuperationInkWhPerkmAltitudeLoss={float}27&auxiliaryPowerInkW={float}28&extendedRouteRepresentation={extendedRouteRepresentation}
GET URL example
Note: Linebreaks are designated by "\".
1https://api.tomtom.com/maps/orbis/routing/calculateRoute/\252.50931,13.42936:52.50274,13.43872/json?\3&vehicleHeading=90§ionType=traffic\4&routeType=efficient&traffic=live&avoid=unpavedRoads\5&travelMode=car&vehicleEngineType=combustion\6&key={Your_API_Key}
GET curl command example
Note: Linebreaks are designated by "\".
1curl -X GET '"https://api.tomtom.com/maps/orbis/routing/calculateRoute/\252.50931,13.42936:52.50274,13.43872/json?\3vehicleHeading=90\4§ionType=traffic\5&routeType=efficient&traffic=live&avoid=unpavedRoads\6&travelMode=car&vehicleEngineType=combustion\7&key={Your_API_Key}" -H "accept:*/*" -H "TomTom-Api-Version:2"'
POST URL example
https://api.tomtom.com/maps/orbis/routing/calculateRoute/52.50931,13.42936:52.50274,13.43872/json?apiVersion=2&key={Your_API_Key}
POST curl command example
1curl -X POST "https://api.tomtom.com/maps/orbis/routing/calculateRoute/52.50931,13.42936:52.50274,13.43872/json?key={Your_API_Key}" -H "Content-type:application/json" -H "TomTom-Api-Version:2" -d \2'{3 "supportingPoints": [4 {5 "latitude": 52.5093,6 "longitude": 13.429367 },8 {9 "latitude": 52.50844,10 "longitude": 13.4285911 }12 ]13}'
POST curl command example with encoded polyline
1curl -X POST "https://api.tomtom.com/maps/orbis/routing/calculateRoute/52.50931,13.42936:52.50274,13.43872/json?key={Your_API_Key}" -H "Content-type:application/json" -H "TomTom-Api-Version:2" -d \2'{3 "encodedPolyline": "ogcph^_esc_GnxOf`N",4 "encodedPolylinePrecision": 75}'
POST curl command example with entry points
1curl -X POST "https://api.tomtom.com/maps/orbis/routing/calculateRoute/52.328416,13.626480:52.36428,13.508614/json?key={Your_API_Key}" -H "Content-type:application/json" -d \2'{3 "legs" : [4 {5 "routeStop": {6 "entryPoints": [7 {8 "latitude": 52.36443,9 "longitude": 13.5092910 },11 {12 "latitude": 52.38909,13 "longitude": 13.5178114 },15 {16 "latitude": 52.37038,17 "longitude": 13.5214918 },19 {20 "latitude": 52.36281,21 "longitude": 13.5103122 }23 ]24 }25 }26 ]27}'
Types
The following data table describes the types that can be used in the Calculate Route service.
Type | Description |
---|---|
| Latitude, longitude pair (in EPSG:4326 projection), with the following constraints:
Example: |
| A |
| A date and time specified in RFC 3339 format with an optional time zone offset. Examples:
|
| Comma-separated |
Request headers
The following data table describes supported HTTP request headers.
- Required headers must be used or the call will fail.
- Optional headers may be used.
- The order of request headers is not important.
Optional headers | Description |
---|---|
TomTom-Api-Version | Specifies API version Note: this header is required if the query parameter |
Accept-Encoding | Requests that the response be compressed.
Value: |
Content-Encoding | Specifies the compression used for the request body. Currently, only
Note: This header is optional and can only be used for
Values:
|
Content-Type | Specifies the MIME type of the body of the request. Note: This header is required for Value: |
Tracking-ID | Specifies an identifier for the request.
|
Base path parameters
The following table describes the parameters that can be used in the Calculate Route service.
- Required parameters must be used or the call will fail.
- The order of the required parameters is important and must be followed.
- There are no optional parameters.
Required parameters (Base path) | Description |
---|---|
| Locations through which the route is calculated. The following constraints apply:
Values: Colon-delimited |
| Base URL for calling the API. |
| The content type of the response structure. Only possible value:
|
Request parameters
The following table describes the parameters that can be used in the Calculate Route service.
- Required parameters must be used or the call will fail.
- Optional parameters may be used.
- The order of the optional request parameters is not important.
Required parameters | Description |
---|---|
| Authorization key to access the API.
Value: Your valid |
| Specifies the API version. Note: This parameter is not required if the header |
Optional parameters | Description | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Number of desired alternative routes to be calculated. The value provided:
Default value: | ||||||||||||||||
| When
Note: The | ||||||||||||||||
| All alternative routes returned will follow the reference route (see the
POST data parameters section) from
the origin point of the
0 | ||||||||||||||||
| All alternative routes returned will follow the reference route (see the
POST data parameters section) from
the origin point of the
0 | ||||||||||||||||
| Largest index in the array of
Minimum value: | ||||||||||||||||
| Specifies how to reconstruct a given polyline or individual legs.
Note: This parameter can only be used when a route or legs are provided as part
of the request by using
Note: In any of the modes, the algorithm might relax certain restrictions near the origin and destination to offer a more sensible route instead of a no route found response. This ensures that routes planned with our service can be reconstructed.
| ||||||||||||||||
| Specifies the representation of the set of routes provided as a response.
Default value:
| ||||||||||||||||
| The directional heading of the vehicle, in degrees starting at true North and continuing in a clockwise direction.
Maximum value: | ||||||||||||||||
| Specifies which of the section types is reported in the route response.
| ||||||||||||||||
| Specifies the extended representation of the set of routes provided as a
response.
| ||||||||||||||||
| Decides how traffic is considered for computing routes.
Default value: | ||||||||||||||||
| Specifies something that the route calculation should try to avoid when
determining the route. The
| ||||||||||||||||
| Specifies the type of optimization used when calculating routes.
Default value: | ||||||||||||||||
| Default value and only allowed value: | ||||||||||||||||
| The engine type of the vehicle. When the value is | ||||||||||||||||
| Weight of the vehicle in kilograms. |
The Electric Consumption model
The route calculation uses the electric consumption model when the vehicleEngineType
is set to electric
and the constantSpeedConsumptionInkWhPerHundredkm
is specified.
When the electric consumption model is used, then the response additionally contains batteryConsumptionInkWh
in the route and leg summaries.
When used together with the routeType
value efficient
, then route planning takes into account the consumption model.
The following data table describes all of the parameters that can be specified in a request using the electric model.
- Required parameters must be used or the call will fail.
- Optional parameters may be used.
- The order of parameters in a request is not important.
Required parameters | Description |
---|---|
| Specifies the speed-dependent component of consumption.
Consumption rates for speeds not in the list are found as follows:
The list must contain between 1 and 25 points (inclusive), and may not contain duplicate points for the same speed.
Minimum value: |
Optional parameters | Description |
---|---|
| Specifies the current electric energy supply in kilowatt hours (kWh). |
| Specifies the maximum electric energy supply in kilowatt hours (kWh)
that may be stored in the vehicle's battery. |
| Specifies the amount of power consumed for sustaining auxiliary systems,
in kilowatts (kW). It can be used to specify consumption due to devices
and systems such as AC systems, radio, heating, etc. |
| Specifies the efficiency of converting electric energy to kinetic energy
when the vehicle accelerates (i.e.,
Minimum value: |
| Specifies the efficiency of converting kinetic energy to electric energy
when the vehicle decelerates (i.e.,
Minimum value: |
| Specifies the efficiency of converting electric energy to potential
energy when the vehicle gains elevation (i.e.,
Minimum value: |
| Specifies the efficiency of converting potential energy to electric
energy when the vehicle loses elevation (i.e,
Minimum value: |
| Specifies the electric energy in kWh consumed by the vehicle through
gaining 1000 meters of elevation.
Minimum value: |
| Specifies the electric energy in kWh gained by the vehicle through
losing 1000 meters of elevation.
Minimum value: |
It is possible that a particular set of consumption parameters is rejected, even though it might fulfill all the explicit requirements specified above. This will happen when the value of a specific parameter, or a combination of values of several parameters, is deemed to lead to unreasonable magnitudes of consumption values.
If that happens, it most likely indicates an input error, as proper care is taken to accommodate all sensible values of consumption parameters. In case a particular set of consumption parameters is rejected, the accompanying error message will contain a textual explanation of the reason(s).
To give the feeling of the magnitudes of reasonable parameter values, the following data table provides an example of sensible values.
Parameter | Sensible values for the electric consumption model |
---|---|
constantSpeedConsumptionInkWhPerHundredkm | 50,8.2:130,21.3 |
vehicleWeight | 1900 |
currentChargeInkWh | 43 |
maxChargeInkWh | 85 |
auxiliaryPowerInkW | 1.7 |
accelerationEfficiency | 0.66 |
decelerationEfficiency | 0.91 |
uphillEfficiency | 0.74 |
downhillEfficiency | 0.73 |
consumptionInkWhPerkmAltitudeGain | 7.0 |
recuperationInkWhPerkmAltitudeLoss | 3.8 |
POST data parameters
The supportingPoints
field is used to reconstruct a route.
This route is then used as a reference route for route reassessment, or calculating zero or more alternative routes.
- There are two options how to pass
supportingPoints
: for the entire route or per leg. - The provided sequence of supporting points is used as input for route reconstruction.
- The
pointWaypoints
field is used to represent waypoints when reconstructing a route. - If
supportingPointIndexOfOrigin
is not used, and bothminDeviationDistance
andminDeviationTime
are set to zero, then these origin and destination points are expected to be at (or very near) the beginning and end of the reference route, respectively.
Using supportingPointIndexOfOrigin
, or setting at least one of minDeviationDistance
or minDeviationTime
to a value greater than zero, has the following consequences:
- The origin point of the
calculateRoute
request must be on (or very near) the input reference route.- If this is not the case, an error is returned.
- However, the origin point does not need to be at the beginning of the input reference route (it can be thought of as the current vehicle position on the reference route).
- If used,
supportingPointIndexOfOrigin
must precisely indicate the location of the origin point in relation to thesupportingPoints
.
- The reference route, returned as the first route in the
calculateRoute
response, will start at the origin point specified in thecalculateRoute
request. The initial part of the input reference route up until the origin point will be excluded from the response. - The values of
minDeviationDistance
andminDeviationTime
determine how far alternative routes will be guaranteed to follow the reference route from the origin point onwards. - The
vehicleHeading
is ignored.
The following table describes the parameters that can be used in the Calculate Route service.
Parameter | Description |
---|---|
avoidAreas object | Defines areas of certain shapes to avoid when planning routes. Supported shapes include |
rectangles array | This is an array of objects with a maximum of ten elements. Each object describes an axis-aligned rectangle, defined using the fields
|
southWestCorner object | The south-west corner of a rectangle. It is an object consisting of a |
northEastCorner object | The north-east corner of a rectangle. It is an object consisting of a |
| Locations to be used as input for route reconstruction. |
| A string in the
encoded polyline format,
representing the locations to be used as input for route reconstruction. |
| The precision used to encode the polyline in the |
pointWaypoints | An array of
|
pointWaypoint | Must contain one |
waypointSourceType string | Denotes the source of the waypoint. Possible values:
|
supportingPointIndex integer | An index into the
|
| An array of objects with the parameters for the computation of each leg. If the parameter is such
that it is available for use in the query parameters, then its simultaneous use in the query
parameters and in the POST data is prohibited, and such a request will be returned with an error.
|
RouteStop
Optional parameters | Description |
---|---|
pauseTimeInSeconds integer | Specifies the waiting time at route stops (including charging time).
It must be 0 in the last leg (the destination). |
entryPoints array of EntryPoint objects | Specifies the entry points for the stop at the end of the current leg. The route to the stop is calculated based on these entry points. Entries with the same location are not allowed. |
EntryPoint
Parameters | Description |
---|---|
latitude float | Latitude of the entry point. Required. |
longitude float | Longitude of the entry point. Required. |
Request content example
Note: for the purpose of brevity the following example may contain fields that are incompatible with others, and in practice only a subset of them will be present in the request.
1{2 "avoidAreas": {3 "rectangles": [4 {5 "southWestCorner": {6 "latitude": 48.81851,7 "longitude": 2.265938 },9 "northEastCorner": {10 "latitude": 48.90309,11 "longitude": 2.4111512 }13 }14 ]15 },16 "supportingPoints": [17 {"latitude": 52.50930, "longitude": 13.42936},18 {"latitude": 52.50844, "longitude": 13.42859},19 {"latitude": 52.50601, "longitude": 13.42742}20 ],21 "encodedPolyline": "ogcph^_esc_GnxOf`Nvmn@fzU",22 "encodedPolylinePrecision": 7,23 "pointWaypoints": [24 {25 "waypointSourceType": "USER_DEFINED",26 "supportingPointIndex": 027 },28 {29 "waypointSourceType": "USER_DEFINED",30 "supportingPointIndex": 131 }32 ],33 "legs": [34 {35 "routeType": "efficient",36 "routeStop": {37 "pauseTimeInSeconds": 610,38 "entryPoints": [39 {40 "latitude": 52.50601,41 "longitude": 13.4274242 }43 ]44 }45 },46 {47 "supportingPoints": [48 {49 "latitude": 52.5093,50 "longitude": 13.4293651 },52 {53 "latitude": 52.50844,54 "longitude": 13.4285955 }56 ],57 "encodedPolyline": "ogcph^_esc_GnxOf`N",58 "encodedPolylinePrecision": 759 },60 {61 "routeType": "short"62 }63 ]64}
Response data
Response headers
The following table describes the possible HTTP response headers.
Header | Description |
---|---|
Access-Control-Expose-Headers | The service whitelists response headers that browsers are allowed to
access. |
Access-Control-Allow-Origin | The service allows cross-origin resource sharing. |
Content-Encoding | The service supports HTTP compression if requested by the client. |
Content-Type | The format of the response. |
Cache-Control | The Cache-Control general-header field is used to specify directives
that must be obeyed by all caching mechanisms along the request/response
chain. It is supported by HTTP/1.1 clients. It may not be supported by
HTTP/1.0 clients.
|
Pragma | The Pragma general-header field is used to specify directives that might
apply to any recipient along the request/response chain. It is supported
by HTTP/1.0 client.
Value: |
Tracking-ID | This is an identifier for the request. If |
Warning | This may be sent for deprecated features. |
Response codes
The following table describes the possible HTTP response codes.
Code | Meaning & possible causes |
---|---|
200 | OK: A route or range was calculated and the body of the response contains the data for a successful response. |
400 | Bad request: One or more parameters were:
|
403 | Permission, capacity, or authentication issues:
|
404 | Not Found: The requested resource could not be found, but it may be available again in the future. |
405 | Method Not Allowed: The client used a HTTP method other than GET or POST. |
408 | Request timeout: The client took too long to transmit the request. |
414 | Requested uri is too long. |
415 | Unsupported Media Type. |
429 | Too Many Requests: Too many requests were sent in a given amount of time for the supplied API Key. |
500 | An error occurred while processing the request. Please try again later. This can also indicate that the request reached an internal computation time threshold and timed out. |
502 | Internal network connectivity issue. |
503 | Service currently unavailable. |
504 | Internal network connectivity issue. |
596 | Service not found. |
Example of a successful response
The routes in a successful response are listed in the order of decreasing optimality. In case the request includes the supporting points supportingPoints
field, the response will specify the reconstructed route before any alternative routes.
Note: for the purpose of brevity the following example contains all the fields described in this document. In practice some fields are incompatible with others, and only a subset of them will be present in the response depending on the given request parameters.
A response could look like this: (Note: Comments are contained within ... ...
.)
Response body - JSON
1{2 "formatVersion": "0.0.12",3 "routes": [4 {5 "summary": {6 "lengthInMeters": 1147,7 "travelTimeInSeconds": 161,8 "trafficDelayInSeconds": 15,9 "trafficLengthInMeters": 147,10 "departureTime": "2015-04-02T15:01:57+02:00",11 "arrivalTime": "2015-04-02T15:04:38+02:00",12 "batteryConsumptionInkWh": 0.15513 },14 "legs": [15 {16 "summary": {17 "lengthInMeters": 108,18 "travelTimeInSeconds": 11,19 "trafficDelayInSeconds": 0,20 "trafficLengthInMeters": 0,21 "departureTime": "2015-04-02T15:01:57+02:00",22 "arrivalTime": "2015-04-02T15:02:07+02:00",23 "batteryConsumptionInkWh": 0.1,24 "originalWaypointIndexAtEndOfLeg": 0,25 "userDefinedPauseTimeInSeconds": 1020,26 "entryPointIndexAtEndOfLeg": 027 },28 "points": [29 {30 "latitude": 52.5093087,31 "longitude": 13.429373732 },33 {34 "latitude": 52.5090373,35 "longitude": 13.429125836 },37 ...further points...38 ],39 "encodedPolyline": "}lcph^qmsc_GrhD|yC",40 "encodedPolylinePrecision": 741 },42 ...further legs...43 ],44 "progress": [45 {46 "pointIndex": 0,47 "travelTimeInSeconds": 0,48 "distanceInMeters": 0,49 "batteryConsumptionInkWh": 050 },51 {52 "pointIndex": 5,53 "travelTimeInSeconds": 7,54 "distanceInMeters": 74,55 "batteryConsumptionInkWh": 0.00256 },57 ...further progresses...58 {59 "pointIndex": 87,60 "travelTimeInSeconds": 161,61 "distanceInMeters": 1147,62 "batteryConsumptionInkWh": 0.15563 }64 ],65 "sections": [66 {67 "startPointIndex": 0,68 "endPointIndex": 3,69 "sectionType": "TRAVEL_MODE"70 "travelMode": "other"71 },72 {73 "startPointIndex": 3,74 "endPointIndex": 7,75 "sectionType": "TRAVEL_MODE"76 "travelMode": "car"77 },78 {79 "startPointIndex": 2,80 "endPointIndex": 5,81 "sectionType": "TOLL"82 },83 {84 "startPointIndex": 3,85 "endPointIndex": 4,86 "sectionType": "TUNNEL"87 },88 {89 "startPointIndex": 0,90 "endPointIndex": 1,91 "sectionType": "PEDESTRIAN"92 },93 {94 "startPointIndex": 3,95 "endPointIndex": 4,96 "sectionType": "TRAFFIC",97 "simpleCategory": "JAM",98 "effectiveSpeedInKmh": 40,99 "delayInSeconds": 158,100 "magnitudeOfDelay": 1,101 "tec": {102 "effectCode": 4,103 "causes": [104 {105 "mainCauseCode": 1106 },107 {108 "mainCauseCode": 26,109 "subCauseCode": 2110 }111 ]112 }113 },114 ...further sections...115 ]116 }117 ...further routes...118 ]119}
Example of an error response
If an error occurs, the response contains the description of the error. The error response would look like this:
1{2 "formatVersion": "0.0.12",3 "detailedError": {4 "code": <error code>,5 "message": "Error message"6 }7}
Structure of a successful response
Note that some names are implicitly defined. One example is the name leg
when describing legs
as an array of leg
objects.
JSON field | Description |
---|---|
formatVersion string | The format version. |
| The request may return more than one route. |
| The summary of a route, or of a route leg. |
| A description of a part of a route, comprised of an array of points.
|
| Each object in the array is a location on the surface of the globe
defined by its |
| A string in the
encoded polyline format,
representing the array of points describing a part of a route. |
| The precision used to encode the polyline in the |
| Included if requested using the
|
| Index of the first point (offset |
| Index of the last point (offset |
| A 3-character ISO 3166-1 alpha-3 country code. |
| Type of the incident.
|
| The effective speed of the incident in km/h, averaged over its entire length. |
| The delay in seconds caused by the incident. |
| The magnitude of delay caused by the incident.
These values correspond to the values of the response field
|
| Details of the traffic event. It uses the definitions in the
TPEG2-TEC
standard. It can contain the |
| The effect on the traffic flow. Contains a value in the
|
| Each object in the array describes one cause of the traffic event.
|
| The main cause of the traffic event. Contains a value in the
|
| The sub-cause of the traffic event. Contains a value in the sub cause
table defined by the |
| The route or leg length in meters. |
| The estimated travel time in seconds depending on
|
| The delay in seconds compared to free-flow conditions according to
real-time traffic information.
Note that this is zero if |
| The portion of the route or leg, expressed in meters, that is affected by traffic events which cause the delay. |
| The distance (in meters) from the origin point of the
|
| The travel time (in seconds) from the origin point of the
|
| The coordinates of the first point following the origin point of the
|
| The estimated departure time for the route or leg. Specified as a
|
| The estimated arrival time for the route or leg. Specified as a
|
| The reason for a better route proposal. Can currently be:
This field is included in the response only if the route is requested
with |
| The estimated electric energy consumption in kilowatt hours (kWh).
|
| This field is included if
A
|
| The index of the waypoint at the end of the leg that corresponds to:
This field is not provided if the end of the leg corresponds to the destination or to a new charging waypoint that is not present in the request. |
| Contains the value of |
| Identifies the entry point that was used for the route at the end of the leg. |
Structure of the section
object
Each section
object contains additional information about parts of a route. A section
object contains at least the fields startPointIndex
, endPointIndex
, and sectionType
.
JSON field | Description | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Contains the response section type.
| ||||||||||||||||||||||||||||||
| This field is either set to the value given to the request parameter
|
Structure of an error response
JSON field | Description | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
detailedError object | This object provides a representation of the error message. It contains
a
|
Route geometry representation formats
Certain request and response fields that describe route geometry as a polyline support two alternative representation formats:
- An array of points defined as raw decimal coordinates, such as the
supportingPoints
field in requests and thepoints
field in responses. - An encoded polyline string, such as the
encodedPolyline
field in both requests and responses.
Where documented, either of the two representations can be used. This is purely a matter of representation and is independent of any other statements about route geometry. The field containing the array of points is used as a stand-in for the concern of route geometry. For brevity, any references and constraints related to the polyline are stated using the stand-in only.
Using encoded polylines can significantly reduce the data size of requests and responses.
Encoded polyline format
For efficient representation of polylines as encoded polyline strings, this service uses an extended version of the
Encoded Polyline Algorithm Format.
The original algorithm limits coordinate precision to 5 decimal places by using a multiplier of 1e5
for the decimal values.
The extension allows using multipliers of both 1e5
and 1e7
.
These multipliers correspond to precisions of 5 and 7 decimal places.
Please note that each field in the encoded polyline format may have limitations on its supported precisions.
Since the encoded polyline string doesn't contain information of the precision or multiplier used, this information must be provided separately alongside each encoded polyline string.
We recommend taking special care when using the higher precision, as some encoding implementations may suffer internal overflows with the higher multiplier.
Encoding
When encoding a polyline, select a supported precision and use the respective multiplier for the decimal value instead of the fixed 1e5
multiplier in the original algorithm (refer to the following table).
Otherwise, the encoding process remains the same as in the original algorithm.
Ensure to send the precision used alongside each encoded polyline string in the request.
Decoding
When decoding a received polyline, use the provided precision next to the encoded polyline string to determine the appropriate multiplier for the decimal value instead of the fixed 1e5
multiplier in the original algorithm (refer to the following table).
Otherwise, the decoding process remains the same as in the original algorithm.
Note that each encoded polyline string is accompanied by the precision used for its encoding.
Precisions and multipliers
The following table illustrates the relationship between precision and multiplier:
Precision | Multiplier |
---|---|
5 | 1e5 |
7 | 1e7 |