Calculate Route

Service version: 1
Last edit: 2024.01.16

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.
  • Additional routing information such as optimized waypoint order or turn by turn instructions is also available, depending on the options selected.

Run this endpoint

You can easily run this and other endpoints. Go to the TomTom API Explorer page and follow the directions.

Request data

HTTPS methods: GET POST

Constants and parameters enclosed in curly brackets { } must be replaced with their values.

Generic request format

The following request URL contains all of this endpoint's respective parameters. For their details, please see the Common Routing Parameters page. In addition this endpoint supports guidance functionality that is collectively described in the Guidance Instructions page.

get
Generic request example
1https://{baseURL}/routing/{versionNumber}/calculateRoute/{routePlanningLocations}/{contentType}?key={Your_API_Key}
2&callback={callback}
3&maxAlternatives={alternativeRoutes}
4&alternativeType={alternativeType}
5&minDeviationDistance={integer}
6&minDeviationTime={integer}
7&supportingPointIndexOfOrigin={integer}
8&computeBestOrder={boolean}
9&routeRepresentation={routeRepresentation}
10&computeTravelTimeFor={trafficTypes}
11&vehicleHeading={integer}
12&sectionType={sectionType}
13&report={effectiveSettings}
14&departAt={time}
15&arriveAt={time}
16&routeType={routeType}
17&traffic={boolean}
18&avoid={avoidType}
19&prefer={preferType}
20&travelMode={travelMode}
21&hilliness={hilliness}
22&windingness={windingness}
23&vehicleMaxSpeed={vehicleMaxSpeed}
24&vehicleWeight={vehicleWeight}
25&vehicleAxleWeight={vehicleAxleWeight}
26&vehicleNumberOfAxles={vehicleNumberOfAxles}
27&vehicleLength={vehicleLength}
28&vehicleWidth={vehicleWidth}
29&vehicleHeight={vehicleHeight}
30&vehicleCommercial={boolean}
31&vehicleLoadType={vehicleLoadType}
32&vehicleAdrTunnelRestrictionCode={vehicleAdrTunnelRestrictionCode}
33&vehicleEngineType={vehicleEngineType}
34&handsFreeDrivingCapability={handsFreeDrivingCapability}
35&constantSpeedConsumptionInLitersPerHundredkm={CombustionConstantSpeedConsumptionPairs}
36&currentFuelInLiters={float}
37&auxiliaryPowerInLitersPerHour={float}
38&fuelEnergyDensityInMJoulesPerLiter={float}
39&accelerationEfficiency={float}
40&decelerationEfficiency={float}
41&uphillEfficiency={float}
42&downhillEfficiency={float}
43&consumptionInkWhPerkmAltitudeGain={float}
44&recuperationInkWhPerkmAltitudeLoss={float}
45&constantSpeedConsumptionInkWhPerHundredkm={ElectricConstantSpeedConsumptionPairs}
46&currentChargeInkWh={float}
47&maxChargeInkWh={float}
48&auxiliaryPowerInkW={float}
49&chargeMarginsInkWh={commaSeparatedFloats}
50&extendedRouteRepresentation={extendedRouteRepresentation}

GET URL example

Note: Line breaks are designated by "\".

get
Request URL example
1https://api.tomtom.com/routing/1/calculateRoute/\
252.50931,13.42936:52.50274,13.43872/json?\
3&vehicleHeading=90&sectionType=traffic\
4&report=effectiveSettings&routeType=eco\
5&traffic=true&avoid=unpavedRoads\
6&travelMode=car&vehicleMaxSpeed=120\
7&vehicleCommercial=false&vehicleEngineType=combustion\
8&key={Your_API_Key}

GET curl command example

Note: Line breaks are designated by "\".

get
Request curl command example
1curl -X GET "https://api.tomtom.com/routing/1/calculateRoute/\
252.50931,13.42936:52.50274,13.43872/json?\
3vehicleHeading=90&sectionType=traffic
4&report=effectiveSettings\&routeType=eco\
5&traffic=true&avoid=unpavedRoads&travelMode=car\
6&vehicleMaxSpeed=120&vehicleCommercial=false\
7&vehicleEngineType=combustion&key={Your_API_Key}" -H "accept:*/*"

POST URL example

post
Request URL example
https://api.tomtom.com/routing/1/calculateRoute/52.50931,13.42936:52.50274,13.43872/json?key={Your_API_Key}

POST curl command examples

post
Request curl command example
1curl -X POST "https://api.tomtom.com/routing/1/calculateRoute/52.50931,13.42936:52.50274,13.43872/json?key={Your_API_Key}" -H "Content-type:application/json" -d \
2'{
3 "supportingPoints": [
4 {
5 "latitude": 52.5093,
6 "longitude": 13.42936
7 },
8 {
9 "latitude": 52.50844,
10 "longitude": 13.42859
11 }
12 ],
13 "avoidVignette": [
14 "AUS",
15 "CHE"
16 ]
17}'
post
Request curl command with per leg parameters example
1curl -X POST "https://api.tomtom.com/routing/1/calculateRoute/52.50931,13.42936:52.511572,13.416830:52.521860,13.427642:52.50274,13.43872/json?key={Your_API_Key}" -H "Content-type:application/json" -d \
2'{
3 "legs" : [
4 {
5 "routeType" : "eco",
6 "routeStop": {
7 "pauseTimeInSeconds": 610
8 }
9 },
10 {
11 },
12 {
13 "routeType": "thrilling",
14 "windingness": "low",
15 "hilliness": "high"
16 }
17 ]
18}'

Types

The following data table describes a subset of the types that can be used in the Calculate Route service; the remaining types are listed on the Common Routing Parameters page.

TypeDescription
circle

A circle with a center point and a radius (in meters). The radius must be a positive integer with the maximum value of 135000.
Example: circle(52.37245,4.89406,10000)

generalizedLocation

A location or a circle.
Examples:

  • 52.37245,4.89406
  • circle(52.37245,4.89406,10000)
commaSeparatedFloats

Comma-separated list of floats.
Example: 1.23,0

point

To be used in the POST data only.
Please refer to the Common Routing Parameters page.

Request headers

There currently are no additional headers specific to the Calculate Route service. The common headers are listed on the Common Routing Parameters page.

Base path parameters

The following table describes a subset of the parameters that can be used in the Calculate Route service. The remaining parameters are listed on the Common Routing Parameters page.

  • 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

versionNumber
integer

The service version number.
Value: The current value is 1.

routePlanningLocations
string

Locations through which the route is calculated. The following constraints apply:

  • At least two locations must be provided.
  • The first location in the sequence defines the origin and must be a location.

  • The last location in the sequence defines the destination and must be a location.

  • One or more optional intermediate generalizedLocations (known as waypoints in this context) may be provided:

    • The maximum allowed number of waypoints is 150.
    • A waypoint of type location results in an extra leg in the response, a waypoint of type circle does not.

    • Circle waypoints cannot be used when computeBestOrder is true.

Values: Colon-delimited generalizedLocations, with the constraints mentioned above.

Request parameters

The following table describes a subset of the parameters that can be used in the Calculate Route service; the remaining parameters are listed on the Common Routing Parameters page.

  • There are no required parameters. All of the following parameters are optional.
  • The order of these optional request parameters is not important.
Optional parametersDescription

maxAlternatives
integer

Number of desired alternative routes to be calculated. The value provided:

  • Must be an integer in the range 0-5.
  • Using a value greater than 0 in conjunction with computeBestOrder set to true is not allowed.

  • Fewer alternative routes may be returned if either fewer alternatives exist, or the requested number of alternatives is larger than the service can calculate.

Default value: 0
Maximum value: 5

alternativeType
string

When maxAlternatives is greater than 0, allows to specify the objective of computing alternative routes: finding routes that are significantly different than the reference route, or finding routes that are better than the reference route. Possible values are:

  • anyRoute: returns alternative routes that are significantly different from the reference route.

  • betterRoute: only returns alternative routes that are better than the reference route, according to the given planning criteria (set by routeType). If there is a road block on the reference route, then any alternative that does not contain any blockages will be considered a better route. The summary in the route response will contain information (see the planningReason parameter) about the reason for the better alternative.

Note: The betterRoute value can only be used when reconstructing a reference route. Default value: anyRoute
Other values: betterRoute

minDeviationDistance
integer

All alternative routes returned will follow the reference route (see the POST data parameters section) from the origin point of the calculateRoute request for at least this number of meters.

  • Can only be used when reconstructing a route.
  • The minDeviationDistance parameter cannot be used in conjunction with arriveAt.

Default value:0

minDeviationTime
integer

All alternative routes returned will follow the reference route (see the POST data parameters section) from the origin point of the calculateRoute request for at least this number of seconds.

  • Can only be used when reconstructing a route.
  • The minDeviationTime parameter cannot be used in conjunction with arriveAt.

Default value:0

supportingPointIndexOfOrigin
integer

Largest index in the supportingPoints array (see the POST data parameters section) for which supportingPoints, supportingPointIndexOfOrigin lies on or before the origin point.
The Routing API uses this index as a hint to disambiguate situations where the supportingPoints in the POST data are not planar, or where they come back close to the origin at a later point in the reconstructed route. In these cases, the supportingPointIndexOfOrigin can explicitly identify if the origin is meant to be on the later part of the route, or not.

  • Can only be used when reconstructing a route.
  • Cannot be used in conjunction with arriveAt.

Minimum value: 0
Maximum value: Size of supportingPoints array - 1.

computeBestOrder
boolean

Re-orders the route waypoints with a fast heuristic algorithm to reduce the overall route length. Note that based on the heuristic nature of the algorithm, optimality is not guaranteed. Yields best results when used in conjunction with routeType shortest.
Possible boolean values are:

  • true: compute a better order, if possible

    • Not allowed to be used in conjunction with a maxAlternatives value greater than 0.

    • Not allowed to be used in conjunction with circle waypoints.

    The response will include the reordered waypoint indices in the field optimizedWaypoints.

  • false: use the locations in the given order.

    • Not allowed to be used in conjunction with routeRepresentation=none.

Default value:false

routeRepresentation
string

Specifies the representation of the set of routes provided as a response.
Possible values are:

  • polyline: includes routes in the response.

  • summaryOnly: as per polyline, but excluding the points elements for the routes in the response.

  • none: only includes the optimized waypoint indices but does not include the routes in the response. This parameter value can only be used in conjunction with computeBestOrder=true.

Default value: polyline
Other values:

  • summaryOnly
  • none

computeTravelTimeFor
string

Specifies whether to return additional travel times using different types of traffic information (none, historic, live) as well as the default best-estimate travel time.
Possible values are:

  • none: do not compute additional travel times.

  • all: compute travel times for all types of traffic information, specifying all results in the fields:

    • noTrafficTravelTimeInSeconds
    • historicTrafficTravelTimeInSeconds
    • liveTrafficIncidentsTravelTimeInSeconds

    being included in the summaries in the route response.

Default value: none
Other value: all

vehicleHeading
integer

The directional heading of the vehicle, in degrees starting at true North and continuing in a clockwise direction.

  • North is 0 degrees.
  • East is 90 degrees.
  • South is 180 degrees.
  • West is 270 degrees.

Maximum value: 359
Other values: 0-359

sectionType
string

Specifies which of the section types is reported in the route response. sectionType can be specified multiple times (e.g., ...&sectionType=tollRoad&sectionType=tollVignette&...).
Possible values are:

  • carTrain: sections of the route that are car trains.

  • ferry: sections of the route that are ferries.

  • tunnel: sections of the route that are tunnels.

  • motorway: sections of the route that are motorways.

  • pedestrian: sections of the route that are only suited for pedestrians.

  • tollRoad: sections of the route that require a toll to be paid.

  • toll: sections of the route with the usage-based toll collection system (i.e., distance-based tolls, toll bridges and tunnels, weight-based tolls).

  • tollVignette: sections of the route that require a toll vignette to be present.

  • country: sections indicating which countries the route is in.

  • travelMode: sections in relation to the request parameter travelMode.

  • traffic: sections of the route that contain traffic information.

  • carpool: sections of the route that require use of carpool (HOV/High Occupancy Vehicle) lanes.

  • urban: sections of the route that are located within urban areas.

  • unpaved: sections of the route that are unpaved.

  • lowEmissionZone: sections of the route that are located within low-emission zones.

  • roadShields: sections with road shield information. A road shield section contains:

    Notes: If this section type is requested, calculateRouteResponse contains the additional field roadShieldAtlasReference.
    Please refer to the notes about the road shield atlas for further information.
    The road shields are only available in these supported countries.

  • speedLimit: Sections with legal speed limit information. maxSpeedLimitInKmh: The maximum legal speed limit in kilometers/hour. This can be time-dependent and/or vehicle-dependent.

    • Time can be set by either the departAt or arriveAt request parameter. In the case of a time-dependent speed limit, the section will contain the speed limit effective at the time the planned route would enter this section.

    • Vehicle information can be set by adjusting the travelMode and vehicle* request parameters.

    • Requesting legal speed limits is only valid if travelMode is adjusted to be a motorized vehicle ( car, truck, taxi, bus, van, or motorcycle).

Default value: travelMode
Other values:

  • carTrain
  • country
  • ferry
  • motorway
  • pedestrian
  • tollRoad
  • toll
  • tollVignette
  • traffic
  • tunnel
  • carpool
  • urban
  • unpaved
  • lowEmissionZone
  • roadShields
  • speedLimit

chargeMarginsInkWh
comma-separated floats

Specifies a list of margins in kilowatt-hours (kWh) for computing reachableRouteOffsets.

  • Can only be used when all of constantSpeedConsumptionInkWhPerHundredkm, maxChargeInkWh, and currentChargeInkWh are specified.

  • The items in the list must be in strictly decreasing order.
  • The list is restricted to exactly one item.

Minimum value: 0
Maximum value: 0

extendedRouteRepresentation
string

Specifies the extended representation of the set of routes provided as a response. <extendedRouteRepresentation> can be specified multiple times (e.g., ...&extendedRouteRepresentation=distance&extendedRouteRepresentation=travelTime&... ). <extendedRouteRepresentation> can only be specified when contentType is json and routeRepresentation is polyline.
Possible values are:

  • distance: Includes distances to route polyline points in the response.

  • travelTime: Includes travel times to route polyline points in the response.

Values:
  • distance
  • travelTime

Deprecation notice

March 15, 2024

  • Value tollRoad for the input parameter sectionType as well as the respective response section type TOLL_ROAD have been deprecated.
  • This section will be withdrawn following a 12 months deprecation period.
  • The planned withdrawal date is March 15, 2025.
  • Following withdrawal, requests for toll road section may result in an HTTP 400 error in the response.

We recommend using toll and toll vignette sections instead.

Further parameters not contained in the preceding table can be specified. A complete list is located in the Common Routing Parameters page. This page also includes the parameters used to define a detailed vehicle consumption model.

Using the detailed consumption model has two consequences for a calculateRoute request:

  • When the parameter routeType is set to eco, then the Consumption Model will be taken into account for route planning.
  • When constantSpeedConsumption* is specified, the response will include either fuelConsumptionInLiters or batteryConsumptionInkWh (for vehicleEngineType set to combustion or electric, respectively) as an additional field in each summary element.

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.

  • 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.
  • The alternative routes are calculated between the origin and destination points specified in the routePlanningLocations, passing through all intermediate locations specified in the pointWaypoints field.
  • If supportingPointIndexOfOrigin is not used, and both minDeviationDistance and minDeviationTime 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.
  • The reference route may contain traffic incidents of type ROAD_CLOSURE, which are ignored for the calculation of the reference route's travel time and traffic delay.

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 the supportingPoints.
  • The reference route, returned as the first route in the calculateRoute response, will start at the origin point specified in the calculateRoute request. The initial part of the input reference route up until the origin point will be excluded from the response.
  • The values of minDeviationDistance and minDeviationTime determine how far alternative routes will be guaranteed to follow the reference route from the origin point onwards.
  • The route must use departAt.
  • The vehicleHeading is ignored.

The following table describes a subset of the parameters that can be used in the Calculate Route service; the remaining parameters are listed on the Common Routing Parameters page.

ParameterDescription
supportingPoints

An array of point objects, to be used as input for route reconstruction.

pointWaypoints

An array of pointWaypoint objects, to be used to represent waypoints when reconstructing a route.

  • If specified, the array must not be empty.
pointWaypoint

Contains one waypointSourceType and one supportingPointIndex object.

waypointSourceType

Denotes the source of the waypoint. Possible values:

  • USER_DEFINED: a waypoint that was explicitly defined by the user.

supportingPointIndex

An index into the supportingPoints array that denotes the location of the waypoint on the reference route.

  • Must be inside supportingPoints array boundaries.

reassessmentParameterSets

An array of reassessmentParameterSet objects, to be used as input for route reassessment.

  • Route reassessment provides information on how some properties of the route would be different with different input values (note that reassessment does not affect the shape of the route). For example, route reassessment can be used to quantify the impact of air conditioning use on total power consumption.

  • If specified, the array must contain exactly one entry.
  • A reassessmentParameterSet object is a set of parameters used together to reassess the planned route. Such an object must contain at least one parameter; currently the only supported parameter is auxiliaryPowerInkW.

legs
array

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.
If the legs field is present in the POST data, then the number of elements in the array must be equal to the number of waypoints + 1.
It is prohibited to use per leg parameters together with circle waypoints.
If there is no need to specify any parameters for some leg, then an empty object must be specified.
It may contain the following fields:

  • routeType: specifies the type of optimization used when calculating the leg. For the details, please see the Common Routing Parameters page.
    Default value: fastest

  • hilliness: specifies the degree of hilliness for a thrilling route. For the details, please see the Common Routing Parameters page.
    Default value: normal

  • windingness: specifies the level of turns for a thrilling route. For the details, please see the Common Routing Parameters page.
    Default value: normal

  • routeStop: an object of RouteStop type with additional parameters for the stop at the end of the current leg. It must be omitted if not needed.

For an example that uses the legs field, please see the POST curl command examples section.

RouteStop

Optinal parameters

Description

pauseTimeInSeconds
integer

Specifies the waiting time at route stops (including charging time). It must be 0 in the last leg (the destination).
Default value: 0

Request content example

post
Request content example
1{
2 "supportingPoints": [
3 {"latitude": 52.50930, "longitude": 13.42936},
4 {"latitude": 52.50844, "longitude": 13.42859},
5 {"latitude": 52.50601, "longitude": 13.42742}
6 ],
7 "pointWaypoints": [
8 {
9 "waypointSourceType": "USER_DEFINED",
10 "supportingPointIndex": 0
11 },
12 {
13 "waypointSourceType": "USER_DEFINED",
14 "supportingPointIndex": 1
15 }
16 ],
17 "avoidVignette": [
18 "AUS",
19 "CHE"
20 ],
21 "reassessmentParameterSets": [
22 {
23 "auxiliaryPowerInkW": 0.3
24 }
25 ],
26 "legs": [
27 {
28 "routeType": "eco",
29 "routeStop": {
30 "pauseTimeInSeconds": 610
31 }
32 },
33 {
34 },
35 {
36 "routeType": "short"
37 }
38 ]
39}

Response data

Response headers

There currently are no additional response headers specific to the Calculate Route service; the common response headers are listed on the Common Routing Parameters page.

Response codes

There currently are no additional response codes specific to the Calculate Route service; the common response codes are listed on the Common Routing Parameters page.

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.

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 "noTrafficTravelTimeInSeconds": 120,
13 "historicTrafficTravelTimeInSeconds": 157,
14 "liveTrafficIncidentsTravelTimeInSeconds": 161,
15 "batteryConsumptionInkWh": 0.155,
16 "deviationDistance": 1735,
17 "deviationTime": 127,
18 "deviationPoint": {
19 "latitude": 52.50904,
20 "longitude": 13.42912
21 },
22 "reachableRouteOffsets": [
23 {
24 "chargeMarginInkWh": 0.0,
25 "routeOffsetInMeters": 1147,
26 "point": {
27 "latitude": 52.51565,
28 "longitude": 13.43979
29 },
30 "pointIndex": 50
31 }
32 ]
33 },
34 "routeReassessments": [
35 {
36 "batteryConsumptionInkWh": 0.2,
37 "reachableRouteOffsets": [
38 {
39 "chargeMarginInkWh": 0.0,
40 "routeOffsetInMeters": 1147,
41 "point": {
42 "latitude": 52.51565,
43 "longitude": 13.43979
44 },
45 "pointIndex": 50
46 }
47 ]
48 }
49 ],
50 "legs": [
51 {
52 "summary": {
53 "lengthInMeters": 108,
54 "travelTimeInSeconds": 11,
55 "trafficDelayInSeconds": 0,
56 "trafficLengthInMeters": 0,
57 "departureTime": "2015-04-02T15:01:57+02:00",
58 "arrivalTime": "2015-04-02T15:02:07+02:00",
59 "noTrafficTravelTimeInSeconds": 10,
60 "historicTrafficTravelTimeInSeconds": 11,
61 "liveTrafficIncidentsTravelTimeInSeconds": 11,
62 "batteryConsumptionInkWh": 0.1,
63 "originalWaypointIndexAtEndOfLeg": 0,
64 "userDefinedPauseTimeInSeconds": 1020
65 },
66 "points": [
67 {
68 "latitude": 52.50931,
69 "longitude": 13.42937
70 },
71 {
72 "latitude": 52.50904,
73 "longitude": 13.42912
74 },
75 ...further points...
76 ]
77 },
78 ...further legs...
79 ],
80 "progress": [
81 {
82 "pointIndex": 0,
83 "travelTimeInSeconds": 0,
84 "distanceInMeters": 0
85 },
86 {
87 "pointIndex": 5,
88 "travelTimeInSeconds": 7,
89 "distanceInMeters": 74
90 },
91 ...further progresses...
92 {
93 "pointIndex": 87,
94 "travelTimeInSeconds": 161,
95 "distanceInMeters": 1147
96 }
97 ],
98 "sections": [
99 {
100 "startPointIndex": 0,
101 "endPointIndex": 3,
102 "sectionType": "TRAVEL_MODE"
103 "travelMode": "other"
104 },
105 {
106 "startPointIndex": 3,
107 "endPointIndex": 7,
108 "sectionType": "TRAVEL_MODE"
109 "travelMode": "car"
110 },
111 {
112 "startPointIndex": 2,
113 "endPointIndex": 5,
114 "sectionType": "TOLL_ROAD"
115 },
116 {
117 "startPointIndex": 3,
118 "endPointIndex": 4,
119 "sectionType": "TUNNEL"
120 },
121 {
122 "startPointIndex": 0,
123 "endPointIndex": 1,
124 "sectionType": "PEDESTRIAN"
125 },
126 {
127 "startPointIndex": 3,
128 "endPointIndex": 4,
129 "sectionType": "TRAFFIC",
130 "simpleCategory": "JAM",
131 "effectiveSpeedInKmh": 40,
132 "delayInSeconds": 158,
133 "magnitudeOfDelay": 1,
134 "tec": {
135 "effectCode": 4,
136 "causes": [
137 {
138 "mainCauseCode": 1
139 },
140 {
141 "mainCauseCode": 26,
142 "subCauseCode": 2
143 }
144 ]
145 }
146 },
147 ...further sections...
148 ]
149 }
150 ...further routes...
151 ],
152 "optimizedWaypoints": [
153 {
154 "providedIndex": 0,
155 "optimizedIndex": 1
156 },
157 {
158 "providedIndex": 1,
159 "optimizedIndex": 0
160 }
161 ...further optimized waypoints...
162 ],
163 "report": {
164 "effectiveSettings": [
165 {
166 "key": "avoid",
167 "value": "motorways"
168 },
169 {
170 "key": "computeBestOrder",
171 "value": "true"
172 },
173 ...further settings...
174 ]
175 }
176}

Example of an error response

If an error occurs, the response contains the description of the error. The error response would look like this:

Error response example - JSON
1{
2 "formatVersion": "0.0.12",
3 "detailedError": {
4 "code": "<error code>",
5 "message": "Error message"
6 }
7}

Special behavior for content type JSONP

When the contentType=jsonp is used, the returned HTTP status code is always OK (200). Reference: JSONP - JSON with Padding

  • This ensures that the jsonp callback will be invoked on the client side regardless of the outcome of the request.
  • In order to provide the client with the actual status of the request, a field called statusCode is added to the response body.

Currently, the preceding statement is not true for certain types of errors described below.

  • For those errors the HTTP status code is returned as normal (400, 500, ...) and the response content type is text/xml independent from the request content type.
  • For those errors, the content does not follow the documented format for error responses.
  • Note: This imperfection should not cause problems during normal use of the API.

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 fieldDescription

formatVersion
string

The format version.

routes
array of route objects

The request may return more than one route.
Each object has at least a summary field and a legs field. It may contain other fields depending on the request parameters.

summary
summary object

The summary of a route, or of a route leg.
The summary object may be extended with new fields in the future; clients should ignore fields they do not recognize.

routeReassessments
array of objects

  • Included if reassessmentParameterSets is specified.

  • Each object in the array corresponds to the entry with the same index in reassessmentParameterSets (see the POST data parameters) and contains the results of a reassessment using the corresponding reassessmentParameterSet.

  • The objects describe particular aspects of the route as a whole. Their values may differ from those reported in the route summary.

  • If the reassessmentParameterSet contains auxiliaryPowerInkW, then the corresponding object may contain the following fields (see individual field descriptions for details):

    • batteryConsumptionInkWh
    • reachableRouteOffsets
  • The objects in this array may be extended with new fields in the future; clients should ignore fields they do not recognize.

legs
array of leg objects

A description of a part of a route, comprised of an array of points.

  • Contains the summary and points fields.

  • Each additional waypoint provided in the request will result in an additional leg in the returned route.

points
array of objects

Each object in the array is a location on the surface of the globe defined by its latitude and longitude fields.

sections
array of section objects

This array is available inside routeobjects.

  • Contains one or more section objects.

  • The structure of section objects is given below.

startPointIndex
number

Index of the first point (offset 0) in the route this section applies to (only included for a routeRepresentation polyline).

endPointIndex
number

Index of the last point (offset 0) in the route this section applies to (only included for a routeRepresentation polyline).

countryCode
string

A 3-character

ISO 3166-1 alpha-3

country code.

simpleCategory
string

Type of the incident.

  • Can currently be JAM, ROAD_WORK, ROAD_CLOSURE, or OTHER.

  • See the tec field for detailed information.

effectiveSpeedInKmh
number

The effective speed of the incident in km/h, averaged over its entire length.

delayInSeconds
number

The delay in seconds caused by the incident.

magnitudeOfDelay
number

The magnitude of delay caused by the incident.
Possible values:

  • 0: unknown

  • 1: minor

  • 2: moderate

  • 3: major

  • 4: undefined, used for road closures and other indefinite delays

These values correspond to the values of the response field magnitudeOfDelay

tec
object

Details of the traffic event. It uses the definitions in the

TPEG2-TEC

standard. It can contain the effectCode and causes fields.

effectCode
number

The effect on the traffic flow. Contains a value in the tec001:EffectCode table, as defined in the

TPEG2-TEC

standard. Can be used to color-code traffic events according to severity.

causes
array of objects

Each object in the array describes one cause of the traffic event.

  • It can contain mainCauseCode and subCauseCode fields.

  • It can be used to define iconography and descriptions.

mainCauseCode
number

The main cause of the traffic event. Contains a value in the tec002:CauseCode table, as defined in the

TPEG2-TEC

standard.

subCauseCode
number

The sub-cause of the traffic event. Contains a value in the sub cause table defined by the mainCauseCode, as defined in the

TPEG2-TEC

standard.

lengthInMeters
number

The route or leg length in meters.

travelTimeInSeconds
number

The estimated travel time in seconds. Note that even when traffic=false, travelTimeInSeconds still includes the delay due to traffic.

trafficDelayInSeconds
number

The delay in seconds compared to free-flow conditions according to real-time traffic information.

trafficLengthInMeters
number

The portion of the route or leg, expressed in meters, that is affected by traffic events which cause the delay.

noTrafficTravelTimeInSeconds
number

The estimated travel time in seconds calculated as if there are no delays on the route due to traffic conditions (e.g., congestion). Included if requested using the computeTravelTimeFor parameter.

historicTrafficTravelTimeInSeconds
number

The estimated travel time in seconds calculated using time-dependent historic traffic data. Included if requested using the computeTravelTimeFor parameter.

liveTrafficIncidentsTravelTimeInSeconds
number

The estimated travel time in seconds calculated using real-time speed data. Included if requested using the computeTravelTimeFor parameter.

deviationDistance
number

The distance (in meters) from the origin point of the calculateRoute request to the first point where this route forks off from the reference route.

  • If the route is identical to the reference route, then this field is set to the length of the route.

  • Included in all alternative (but not reference) route summary fields.

deviationTime
number

The travel time (in seconds) from the origin point of the calculateRoute request to the first point where this route forks off from the reference route.

  • If the route is identical to the reference route, then this field is set to the estimated travel time of the route.

  • Included in all alternative (but not reference) route summary fields.

deviationPoint
object

The coordinates of the first point following the origin point of the calculateRoute request where this route forks off from the reference route.

  • If the route is identical to the reference route, then this field is set to the coordinates of the last point on the route.

  • Included in all alternative (but not reference) route summary fields.

fuelConsumptionInLiters
number

The estimated fuel consumption in liters using the Combustion Consumption Model. Included if:

  • The vehicleEngineType is set to combustion .

  • The constantSpeedConsumptionInLitersPerHundredkm is specified.

  • The value will be non-negative (i.e., positive).

batteryConsumptionInkWh
number

The estimated electric energy consumption in kilowatt hours (kWh) using the Electric Consumption Model.

  • Included if:

    • vehicleEngineType is set to electric.

    • constantSpeedConsumptionInkWhPerHundredkm is specified.

  • The value of batteryConsumptionInkWh includes the recuperated electric energy and can therefore be negative (which indicates gaining energy).

  • If both maxChargeInkWh and currentChargeInkWh are specified, recuperation will be capped to ensure that the battery charge level never exceeds maxChargeInkWh.

  • If neither maxChargeInkWh nor currentChargeInkWh are specified, unconstrained recuperation is assumed in the consumption calculation.

reachableRouteOffsets
array of objects

This field is included if chargeMarginsInkWh is specified. It is not present in the leg summary field. Each object in the array corresponds to an entry in chargeMarginsInkWh, and describes the reachable point on the route with respect to the charge margin specified there. Effectively, the farthest the vehicle can go on the route on its current charge, without depleting the battery beyond the specified margin.

  • Objects in the array contain the following fields:

    • chargeMarginInkWh: the charge margin this reachable point is calculated for.

    • point: location of the reachable point defined as a latitude longitude pair.

    • pointIndex: largest index in the polyline of the route for which points, pointIndex lies on or before point.

    • routeOffsetInMeters: the distance from the start of the route to the reachable point.

  • Note that:

    • If currentChargeInkWh is less than or equal to chargeMarginInkWh, routeOffsetInMeters is zero.

    • routeOffsetInMeters is at most lengthInMeters.

    • Charging stops are ignored in the computation so that e.g., live traffic is used as if driving past any charging station.

optimizedWaypoints
array of objects

A description of an optimized sequence of waypoints. It shows the index from the user-provided waypoint sequence for the original and optimized list. For instance, a response:

1{
2 "optimizedWaypoints": [
3 {
4 "providedIndex": 0,
5 "optimizedIndex": 1
6 },
7 {
8 "providedIndex": 1,
9 "optimizedIndex": 2
10 },
11 {
12 "providedIndex": 2,
13 "optimizedIndex": 0
14 }
15 ]
16}

means that:

  • The original sequence is 0, 1, 2.

  • The optimized sequence is 1, 2, 0.

Since the index starts by 0 the original is "first, second, third", while the optimized is "second, third, first".

departureTime
string

The estimated departure time for the route or leg. Specified as a dateTime.

arrivalTime
string

The estimated arrival time for the route or leg. Specified as a dateTime.

effectiveSettings
array of objects

Each object in the array represents an effective parameter or a data used when calling the Calculate Route API. Each object has fields key and value both containing a string describing the input and its value.

statusCode
number

The original HTTP status code as listed in the response codes (note: included for content type jsonp only).

planningReason
string

The reason for a better route proposal. Can currently be:

  • Blockage in case the reference route contains road blockages. The returned value is implementation-defined in case both reasons for a better proposal are applicable to the same route.

  • Better_Proposal in case the alternative type is better than the reference route, according to the given planning criteria (set by routeType).

This field is included in the response only if the route is requested with alternativeType=betterRoute. This field is not present in the leg summary field.

progress
array of progress point objects

This field is included if extendedRouteRepresentation is used.

  • It always contains entries for the first and the last point in the route.

  • For any pair of consecutive entries in the progress array, progress for pointIndex values that are not explicitly present and are enclosed by said pair, can be linearly interpolated by summing up straight line distances of the leg points.

  • The Haversine formula is precise enough to compute such distances.

A progress point object may contain the following members:

  • pointIndex: index of the point (offset 0) in the route this object applies to.

  • distanceInMeters: distance (in meters) from the start of the route to this point. This field is included if extendedRouteRepresentation value distance is used.

  • travelTimeInSeconds: travel time (in seconds) from the start of the route to this point. This field is included if extendedRouteRepresentation value travelTime is used.

originalWaypointIndexAtEndOfLeg
number

The index of the waypoint at the end of the leg that corresponds to:

  • The index of this waypoint in the list of waypoints from the routePlanningLocations base path parameter in the request (the first waypoint has an index equal to 0).

  • The index of this waypoint in the pointWaypoints field when reconstructing a route.

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.

userDefinedPauseTimeInSeconds
number

Contains the value of pauseTimeInSeconds, if it was specified for the corresponding leg. This field is not present in the route summary field.

roadShieldAtlasReference
string

The base URL of the Road Shields service to fetch the road shield atlas and metadata resources.
Currently available resources are:

  • sprite.png
  • sprite.json

We recommend to cache the sprite atlas (sprite.png) and metadata (sprite.json) as it changes infrequently and is large compared to a typical road shield description.
Please refer to the

Road Shield service

for further information. The returned road shield references correspond to the asset names in the Road Shield service.

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 fieldDescription

sectionType
string

Contains the response section type.

Request section typeResponse section type
carTrainCAR_TRAIN
countryCOUNTRY
ferryFERRY
motorwayMOTORWAY
pedestrianPEDESTRIAN
tollRoadTOLL_ROAD
tollTOLL
tollVignetteTOLL_VIGNETTE
trafficTRAFFIC
travelModeTRAVEL_MODE
tunnelTUNNEL
carpoolCARPOOL
urbanURBAN
unpavedUNPAVED
lowEmissionZoneLOW_EMISSION_ZONE
roadShieldsROAD_SHIELDS
speedLimitSPEED_LIMIT

The COUNTRY sections span between country border crossings, from the departure, or to the destination.

  • The section additionally contains countryCode.

  • If the route has disjointed parts in the same country, there will be several sections with the same countryCode.

  • If no country can be assigned to a part of the route, as for example in international waters, there may be no country section for this part.

    • A TOLL_VIGNETTE section additionally contains a countryCode since toll vignettes are often specific to a country.

    • A TRAFFIC section may additionally contain any of the following: simpleCategory, effectiveSpeedInKmh, delayInSeconds, magnitudeOfDelay, tec.

    • TRAVEL_MODE sections cover the whole route. Each section's travel mode is reported in travelMode .

    • CARPOOL sections contain parts of the route that are only open to HOV (high-occupancy vehicles) at the time of traversal. Roads with at least one unrestricted lane are not part of a CARPOOL section.

    • ROAD_SHIELDS sections contain an array of roadShieldReference objects. Please refer to the structure of a road shield reference object for further information.

travelMode
string

This field is either set to the value given to the request parameter travelMode, if this travel mode is possible, or to other which indicates that the given mode of transport is not possible in this section. This field can only be used within sections of type TRAVEL_MODE.

Structure of an error response

JSON fieldDescription

detailedError
object

This object provides a representation of the error message. It contains a code and a message field.

JSON field

Description

code
string

The (non-complete) list of error codes is:

Error code

Description
MAP_MATCHING_FAILURE

One of the input points (Origin, Destination, Waypoints) could not be matched to the map because there is no known drivable section near this point. This error code is always followed by a description of one point that was not matchable:

  • Origin (Latitude, Longitude)
  • Destination (Latitude, Longitude)
  • Waypoint N (Latitude, Longitude)
NO_ROUTE_FOUND

No valid route could be found.

CANNOT_RESTORE_BASEROUTE

The route reconstruction using supportingPoints failed.

BAD_INPUT

Some input parameter combination was not valid.

COMPUTE_TIME_LIMIT_EXCEEDED

The request exceeded the internal compute time limit and was canceled.

message
string

A human readable error message.

  • It is a freeform string which may be extended in the future, so it is recommended to only match substrings of the description.

  • The string always contains an error code.

Example of a description string:

Engine error while executing route request: MAP_MATCHING_FAILURE: Origin (54.3226, 3.11463)

Engine error while executing route request: MAP_MATCHING_FAILURE: Origin (54.3226, 3.11463)

Engine error while executing route request: MAP_MATCHING_FAILURE: Waypoint 3 (54.3226, 3.11463)

statusCode
number

The original HTTP status code as listed in response codes (included for content type jsonp only).

Structure of a road shield reference object

JSON field

Description

roadShieldReference
object

This object describes a single road shield reference. It contains the following fields:

reference
string

A unique identifier for the road shield.

shieldContent
string

An optional string to be shown on the road shield.

affixes
array of strings

An optional list of possible affixes that can be shown in addition to the shieldContent.