Common Routing Parameters
Purpose
This document provides fundamental route planning parameters and types that can be used, among others, in the:
- Calculate Route service
- Calculate Reachable Range service
Please be aware that this document does not specify the complete request or response format. To maintain forward compatibility you must be able to process responses with additional non-documented data fields. Our deprecation policy only covers the documented subset of these formats.
Types
Types subset | 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.
|
| Comma-separated |
| Comma-separated |
Request data
Request headers
The following data table describes HTTP request headers of particular interest to the Calculate Route and Calculate Reachable Range service clients.
- 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 |
---|---|
Accept-Encoding | Requests that the response be compressed. |
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
Parameter subset
The following data table describes a subset of the parameters that can be used in the Calculate Route and Calculate Reachable Range services.
- Required parameters must be used or the call will fail.
- Optional parameters may be used.
Required parameters | Description |
---|---|
| Base URL for calling the API.
|
Optional parameters | Description |
---|---|
| The content type of the response structure.
Note: If the content type is |
Request parameters
Request parameters are presented in two sections:
- The Common Routing Parameters section describes common parameters that affect the routing algorithm in various ways.
- The Consumption Model Parameters section describes a particular subset of parameters that define a detailed Consumption model.
Section 1. Common Routing Parameters
This section presents a set of loosely connected parameters that influence the operation of the routing algorithm. While some of them are associated, the majority can be used independently of the others.
- Required parameters must be used or the call will fail.
- Optional parameters may be used.
Required parameters | Description |
---|---|
| Authorization key to access the API. |
Optional parameters | Description | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Specifies the | ||||||||||||||||||||
| Specifies which data should be reported for diagnostic purposes. A
possible value is:
Default value: | ||||||||||||||||||||
| The date and time of departure from the origin point.
Default value: | ||||||||||||||||||||
| The date and time of arrival at the destination point.
The
It cannot be used in | ||||||||||||||||||||
| Specifies the type of optimization used when calculating routes.
Default value: | ||||||||||||||||||||
| Possible values are:
Depending on availability, the Routing API takes road closures and road works
into account that are up to 60 days in the future. | ||||||||||||||||||||
| Specifies something that the route calculation should try to avoid when
determining the route. The
Note: In | ||||||||||||||||||||
| Specifies something that the route calculation should try to prefer when
determining the route.
| ||||||||||||||||||||
| Specifies the hands-free driving capability of the vehicle.
The available hands-free driving data is matched against
| ||||||||||||||||||||
| The mode of travel for the requested route.
Note that travel modes
Default value:
| ||||||||||||||||||||
| Degree of hilliness for a thrilling route.
| ||||||||||||||||||||
| Level of turns for
| ||||||||||||||||||||
| Maximum speed of the vehicle in kilometers/hour.
Default value: | ||||||||||||||||||||
| Weight of the vehicle in kilograms.
Default value: | ||||||||||||||||||||
| Weight per axle of the vehicle in kilograms. A value of
| ||||||||||||||||||||
| Number of axles of the vehicle. A value of | ||||||||||||||||||||
| Length of the vehicle in meters, including the length of any additional
equipment, e.g., trailers, bike racks, etc. A value of | ||||||||||||||||||||
| Width of the vehicle in meters. A value of | ||||||||||||||||||||
| Height of the vehicle in meters. A value of | ||||||||||||||||||||
| Vehicle is used for commercial purposes and thus may not be allowed to
drive on some roads. | ||||||||||||||||||||
| Specifies types of cargo that may be classified as hazardous materials
and are restricted from some roads. The
or
).
Use these values for routing in the USA:
Use these values for routing in all other countries:
Notes:
| ||||||||||||||||||||
| If
Notes:
Values (specify at most one):
Reference: | ||||||||||||||||||||
| Specifies the route calculation should try to avoid ETC-transponder-only toll roads when determining the route if a vehicle does not have an ETC transponder. Possible values are:
If this parameter is not specified, ETC-transponder-only toll roads are not avoided. | ||||||||||||||||||||
| Specifies the precision of coordinates in the response.
Default 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. This ensures that routes planned with our service can be reconstructed.
| ||||||||||||||||||||
| Specifies the preference of roadside on arrival to waypoints and destination. Stop on the road has to be set at least two meters to the preferred side, otherwise the behavior will default to "anySide". Possible values are:
Default value: |
Section 2. Consumption model parameters
Routing provides a set of parameters for a detailed description of a vehicle-specific Consumption model.
- These parameters can be specified in a
calculateRoute
request. - They must be specified in a
calculateReachableRange
request.
Depending on the value of vehicleEngineType
, we support two principal Consumption models:
- Combustion consumption model
- Electric consumption model
Note:
- Specifying parameters that belong to different models in the same request is an error.
- A Consumption model cannot be used with the
travelMode
values ofbicycle
andpedestrian
.
Parameter constraints
In both Consumption models, explicitly specifying some parameters requires specifying some others as well. In addition, some parameters are mutually exclusive. These are the constraints:
- All parameters require
constantSpeedConsumption*
to be specified by the user.- It is an error to specify any other Consumption model parameter (with the exception of
vehicleWeight
) ifconstantSpeedConsumption*
is not specified.
- It is an error to specify any other Consumption model parameter (with the exception of
accelerationEfficiency
anddecelerationEfficiency
must always be specified as a pair (i.e., both or none).- If
accelerationEfficiency
anddecelerationEfficiency
are specified, the product of their values must not be greater than1
(to prevent perpetual motion).
- If
uphillEfficiency
anddownhillEfficiency
must always be specified as a pair (i.e., both or none).- If
uphillEfficiency
anddownhillEfficiency
are specified, the product of their values must not be greater than1
(to prevent perpetual motion).
- If
consumptionInkWhPerkmAltitudeGain
andrecuperationInkWhPerkmAltitudeLoss
must always be specified as a pair (i.e., both or none).- If they are specified,
recuperationInkWhPerkmAltitudeLoss
must not be greater thanconsumptionInkWhPerkmAltitudeGain
(to prevent perpetual motion).
- If they are specified,
- If
*Efficiency
parameters are specified by the user, thenvehicleWeight
must also be specified.- When
vehicleEngineType
iscombustion
,fuelEnergyDensityInMJoulesPerLiter
must be specified as well.
- When
- If
*Efficiency
parameters are specified by the user, thenconsumptionInkWhPerkmAltitudeGain
andrecuperationInkWhPerkmAltitudeLoss
cannot be specified. maxChargeInkWh
andcurrentChargeInkWh
must always be specified as a pair (i.e., both or none).
Note that if only constantSpeedConsumption*
is specified, no other consumption aspects are taken into account, i.e., slopes and vehicle acceleration are not considered for consumption computations.
Selecting the Consumption model
There are two available Consumption models: Combustion and Electric.
- A model is selected by specifying the corresponding
constantSpeedConsumption*
parameter and possibly further parameters that belong to the same model. - The chosen model must match the value of the
vehicleEngineType
parameter.
Optional parameter | Description |
---|---|
| The engine type of the vehicle. When a detailed Consumption model is
specified, it must be consistent with the value of
|
The Combustion consumption model
Details
The Combustion consumption model is used when the vehicleEngineType
value is set to combustion
. The following data table describes all of the parameters that can be specified in a request using the Combustion 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.
Consumption specified for the largest speed must be greater than or equal to that of the penultimate largest speed.
Minimum value: |
Optional parameters | Description |
---|---|
| Weight of the vehicle in kilograms.
Minimum value: |
| Specifies the current supply of fuel in liters. |
| Specifies the amount of fuel consumed for sustaining auxiliary systems
of the vehicle, in liters per hour. It can be used to specify
consumption due to devices and systems such as AC systems, radio,
heating, etc. |
| Specifies the amount of chemical energy stored in one liter of fuel in megajoules (MJ).
Minimum value: |
| Note: This must be paired with
Minimum value: |
| Note: This must be paired with
Minimum value: |
| Note: This must be paired with
Minimum value: |
| Note: This must be paired with
Minimum value: |
The Electric Consumption model
Details
The Electric Consumption model is used when vehicleEngineType
is set to electric.
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: |
| Note: This is only required if any *Efficiency parameter is set.
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: |
Sensible values of consumption parameters
Details
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).
Example
To give the feeling of the magnitudes of reasonable parameter values, the following data table provides an example of sensible values for the Combustion and Electric models.
Parameter | Sensible values by model |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
POST data parameters
Details
Some parameters can be provided using the HTTP POST
method.
- The POST data should be in JSON format, see the Content-Type header.
- All POST data parameters are optional.
- It is an error to use the HTTP POST method if no POST data parameters are provided.
There is an upper limit on the total size of the POST data.
- Exceeding this limit results in a response with the response code
413
, indicating invalid POST data. - The client must not rely on the exact value of this limit.
- The current limit is 10 MB.
The following table describes a subset of the parameters that can be used in the Calculate Route and Calculate Reachable Range services.
Parameter | Description |
---|---|
| This is an array of strings. Each string should be a 3-character, ISO 3166-1, alpha-3 country code.
Note: It is an error to specify both |
| This is an array of strings. Each string should be a 3-character, ISO 3166-1, alpha-3 country code.
Note: It is an error to specify both |
| Defines areas of certain shapes to avoid when planning routes. Supported
shapes include |
| This is an array of objects, with a maximum of ten elements. Each object
describes an axis-aligned rectangle, defined using the fields
|
| The south-west corner of a rectangle. It is an object consisting of a
|
| The north-east corner of a rectangle. It is an object consisting of a
|
Avoiding roads with usage-based toll collection
There is special behavior where only roads with usage-based toll collection could be avoided.
Scenario 1:
avoid = tollRoad
"allowVignette": [value]
Result:
Roads with usage-based toll collection are avoided. Toll roads requiring vignettes are also avoided,
except in selected countries (marked as value
above) where toll roads with vignettes are allowed.
Note:
in this scenario avoidVignette
has to be None
.
Scenario 2:
avoid = tollRoad
"avoidVignette": [value]
Result:
Roads with usage-based toll collection are avoided. Toll roads requiring vignettes are allowed, except
in selected countries (marked as value
above) where toll roads with vignettes are avoided.
Note:
in this scenario allowVignette
has to be None
.
Request content example
1{2 "avoidVignette": ["AUS", "CHE"],3 "avoidAreas": {4 "rectangles": [5 {6 "southWestCorner": {7 "latitude": 48.81851,8 "longitude": 2.265939 },10 "northEastCorner": {11 "latitude": 48.90309,12 "longitude": 2.4111513 }14 }15 ]16 }17}
Response data
Response headers
The following data table describes HTTP response headers of particular interest to Calculate Route and Calculate Reachable Range service clients.
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. The service supports specifying the desired
response format. See the
|
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. |
Tracking-ID | This is an identifier for the request. If |
Warning | This may be sent for deprecated features. |
Response codes
The following table describes HTTP response codes of particular interest to Calculate Route and Calculate Reachable Range service clients.
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:
|
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. |
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 |