Traffic Flow - Protobuf

Last edit: 2026.03.17 TomTom Orbis Maps

Purpose

The TomTom Traffic Flow - Intermediate Service - Protobuf (hereafter called ‘Service’) is designed for server-to-server integration with traffic control center, routing, navigation, and mapping applications. It contains real-time travel times and speeds for segments, based on TomTom’s Traffic technology, with several possible configurations.

This document describes the data exchange method and the payload description of the Service interface.

Scope

This document gives basic information on the Service and shows how to configure it to work with your environment. The user is expected to have basic installation knowledge and experience using protocol buffers.

Intended audience

This document is intended to be used by TomTom partners and customers (decision makers and developers).

Features

TomTom offers traffic flow data to customers. A custom product is configured based upon your specific needs. The product is static, so included regions and features are fixed (once the product is configured), it contains standard configuration and also provides customizable configuration options (see section Available features ).

Request data

The Service uses RESTful API (Representation State Transfer) technology. Since you only need to use one URL, the service is relatively uncomplicated to use. To make a request, the URL is constructed as shown in the following sections.

Important

To use this Service, ensure that all prerequisites are met as described in the section A secure connection or at Authentication for client certificate access.

HTTPS Method: `GET`

For ease of viewing and identification:

Constants and parameters enclosed in curly brackets { } must be replaced with their values.
Please see the following Request parameters section with the required and optional parameters tables for their values.

The generic request format is as follows.

get

URL example

1
https://{baseURL}/tsq/hdf-detailed/{productName}/{apiKey}/content.proto[?flowType={flowType}]

The following is an example URL:

get

URL example

1
https://cert-traffic.tomtom.com/tsq/hdf-detailed/DEU/{Your_API_Key}/content.proto

The following is an example cURL request:

get

cURL request example

1
curl --compressed -XGET 'https://cert-traffic.tomtom.com/tsq/hdf-detailed/DEU/{Your_API_Key}/content.proto'

Request parameters

The following table provides a detailed explanation of the available fields that were previously shown.

Required parameters	Description
`baseURL` string	Base URL for calling the API. Value: `cert-traffic.tomtom.com`
`productName` string	Name of the product (feed) you are requesting. These will be indicated to you as part of the provisioning process. Typically, it explains the country (country code), and the location referencing method (see Location referencing ). Examples: `DEU-OPENLR`, `DEU-IDLR-OSM`
`apiKey` string	Authorization key for access to the API. Value: Your valid API key.

Optional parameters Description

Optional parameters	Description
`flowType` string	When the feed is requested without the parameter `flowType` it contains ALL messages covered by the feed. In that case, the field `averageSpeed` in a message represents the current speed for congested road segments and the free-flow speed for non-congested road segments. By using the `flowType` parameter, the response can be shaped to only support a certain speed type. This also affects the number of messages in the response. There are two values supported for this parameter: `ff`, gets the messages for ALL road segments covered by the feed. The field averageSpeed in the message provides the free-flow speed for the affected road segment. `nff`, only gets the messages for road segments that are NOT in a free-flow state. The field `averageSpeed` of a message provides the currently measured speed for the affected road segment. When using this parameter, at the first request the free-flow information should be downloaded. Afterwards, non-free-flow information can be downloaded for each future request. The free-flow and non-free-flow data are related. The segments for both files should be in sync, otherwise there is a mismatch in the locations of the free-flow data. Therefore, every time the non-free-flow information is downloaded, it must be checked. This insures that the non-free-flow data corresponds to the free-flow data (that the user already has). The verification is done by confirming the `clientID` within `supplierAndClientInfo` in protocol buffers format. If the `clientID` of the non-free-flow content does not match the `clientID` of the free-flow content that was downloaded with the first request, the free-flow information must be re-requested. See more details in the FAQ about speeds in non free flow feed page. Values: `flowType=nff`, `flowType=ff`

flowType
string

When the feed is requested without the parameter flowType it contains ALL messages covered by the feed. In that case, the field averageSpeed in a message represents the current speed for congested road segments and the free-flow speed for non-congested road segments. By using the flowType parameter, the response can be shaped to only support a certain speed type. This also affects the number of messages in the response. There are two values supported for this parameter:

ff, gets the messages for ALL road segments covered by the feed. The field averageSpeed in the message provides the free-flow speed for the affected road segment.
nff, only gets the messages for road segments that are NOT in a free-flow state. The field averageSpeed of a message provides the currently measured speed for the affected road segment.

When using this parameter, at the first request the free-flow information should be downloaded. Afterwards, non-free-flow information can be downloaded for each future request. The free-flow and non-free-flow data are related. The segments for both files should be in sync, otherwise there is a mismatch in the locations of the free-flow data. Therefore, every time the non-free-flow information is downloaded, it must be checked. This insures that the non-free-flow data corresponds to the free-flow data (that the user already has).

The verification is done by confirming the clientID within supplierAndClientInfo in protocol buffers format. If the clientID of the non-free-flow content does not match the clientID of the free-flow content that was downloaded with the first request, the free-flow information must be re-requested. See more details in the FAQ about speeds in non free flow feed page.
Values: flowType=nff, flowType=ff

Request headers

Since flow feeds can be very large, TomTom recommends optimizing the information transmission as much as possible. Through optimization, the client receives more up-to-date information.

All responses will be gzip compressed as it significantly reduces the payload size. The use of the HTTP header Accept-Encoding is required. For more information see our page about Gzip compression .

Headers	Description
If-Modified-Since	TomTom recommends using the standard HTTP header `If-Modified-Since` with the last value of `Last-Modified` received. When this header is used properly, you avoid unnecessarily downloading identical content. For details, see the HTTP/1.1 standard (RFC2616 section 14.25) . Value: Example: `Wed, 21 Oct 2015 07:28:00 GMT`

Response data

Response codes

Response code	Description
200 OK	Indicates that the request has succeeded. The response body will contain the requested data.
304 Not Modified	Only used if the `If-Modified-Since` header has been set by the client. Indicates that the requested data has not been modified since the last request. For more information see Request headers .
401 Unauthorized	Indicates that the request requires user authentication information. The client MAY repeat the request with a suitable Authorization header field.
406 Not Acceptable	The server doesn’t find any content that conforms with the `Accept-Encoding` header sent in the request. This may happen if `Accept-Encoding` is set to `identity` or `gzip;q=0` or if no `Accept-Encoding` header is present. If the `Accept-Encoding` header is not set or does not support gzip, the server will return a 406 status code with a message indicating the issue.

Response example

If you make the following request:

get

URL example

1
https://cert-traffic.tomtom.com/tsq/hdf-detailed/DEU/{Your_API_Key}/content.proto?flowType=nff

You can expect a response that contains protocol buffers binary data. The textual representation of this data could look like this:

1
metaInformation {
2
  createTimeUTCSeconds: 1452092910
3
  supplierAndClientInfo {
4
    clientID: "db14af1d-3827-4d61-8525-8f70bc1c5b3f15e87601"
5
    supplierID: "TomTom Traffic Service"
6
  }
7
}
8
[...]
9
trafficFlow {
10
  location {
11
    openlr: "\013\t\223\332%UF\033`\013\001)\002$\033S~"
12
  }
13
  speed {
14
    averageSpeedKmph: 5
15
    travelTimeSeconds: 334
16
    confidence: 97
17
    relativeSpeed: 0.106
18
    trafficCondition: STATIONARY_TRAFFIC
19
  }
20
}
21
[...]

Response - Protobuf payload specification (analysis of the received output)

Protocol buffers is the de-facto standard for encoding and transmitting any structured information in a compact, platform-independent way. TomTom uses protocol buffers (version 2) format for the output payload. After defining the data structure an encoder and a decoder can be generated for integration into C++, Java and several other languages. Also see http://code.google.com/p/protobuf or https://protobuf.dev for more information.

Important: Protocol buffers schema

Our output type uses the proprietary TomTom protocol buffers message types. The data structure of the protocol buffers output is defined in the schema file ProtobufTrafficFlow_v12.proto . TomTom supports schema version 11 and above.

All fields are marked as optional, as recommended by Google, but the output always contains flow information (including a location).

The following table contains a brief description of the supported message types used in the data structure. More detailed information about the individual message fields can be found in the following sections: some fields are filled in by default, other fields require a specific feature to be enabled with the product.

Protocol buffers message type	Description
`TrafficFlowGroup`	The traffic flow group is the top-level message. It provides meta data (see `MetaInformation`) and the flow entries themselves, whereby `TrafficFlowWithPredictionPerSection` is used when the optional feature Flow prediction is activated and `TrafficFlow` otherwise.
`MetaInformation`	The meta information message provides data shared by all traffic flow messages.
`SupplierAndClientInfo`	The supplier and client information message identifies the client and the supplier.
`TrafficFlow`	The traffic flow message assigns speed information to a location. It may also identify road blockages.
`TrafficFlowWithPredictionPerSection`	This message assigns current and future speed information to sections of a location at several points in time.
`Speed`	The speed message subsumes all speed and travel time related information. Which fields are set depends on the customizable product configurations (see the section Available features ).
`SectionSpeed`	The `SectionSpeed` message provides speed information for the section of a location. The section is indicated by the offset of the starting point from the start point of the location. The ending offset is either the end of the location or the start of the next section, if there is a next section. `SectionSpeed` may also identify road blockages.
`SpeedVector`	`SpeedVector` provides a set of section speed information details at a point in a future time. This time value indicates the number of minutes, relative to the creation time of this message, as established by the `MetaInformation` message.

Location referencing

OpenLR

Geographical representation of the road segments is an important part of the payload. The following geographical representations that are supported:

by default OpenLR location referencing is used,
optionally Identifier-based location referencing based on OSM way IDs , or
optionally Identifier-based location referencing based on GERS IDs can be provided.

OpenLR is a dynamic location referencing method that allows referencing of any road on the complete digital map. Because of its flexibility, it is possible to describe traffic events on high-level and lower-level road classes that are usually not covered by TMC. The method is available free of charge. The service uses binary format version 3, as described in the OpenLR whitepaper. The whitepaper, software developer kit, and open source reference implementations are available for download from the OpenLR website . TomTom offers support for third parties to implement and test their own implementations.

OpenLR example (here printed using C escape sequences)

1
location {
2
  openlr: "\v\254\320.!\367\n\033l\a\000Z\376\223\033\000"
3
  lengthInMeters: 425
4
}

Identifier-based location referencing using OSM way IDs

Identifier-based location referencing OSM way IDs (hereafter called ‘IDLR-OSM’) is offered as an alternative method of location referencing besides OpenLR and Identifier-based location referencing using GERS IDs . It is not enabled by default and can be enabled upon request.

To obtain OSM way IDs from the feed, you must request them using the URL parameter flowType=ff. A detailed explanation of how to use this parameter can be found in the section on Request Parameters .
Please note that OSM way IDs are static data. They should only be re-requested as part of the flowType=ff feed (as mentioned in the first point) when there has been a change to the ff feed.
You can use the OpenLR codes to link messages from the nff feed to the corresponding messages in the ff feed, allowing you to identify the GERS IDs that were previously downloaded with the ff feed.

The following example shows a trafficFlow message with an IDLR-OSM in the segmentIds field indicated by type: OSM_WAY_ID that is composed of six OSM way IDs. All IDs use the forward direction, the first ID uses a start-offset, the second through fifth IDs have no offsets, and the sixth ID uses an end-offset. The affected location is the concatenation of all IDs minus the offset information.

Example

1
trafficFlow {
2
  location {
3
    openlr: "\v\211\302\310.P\211\033n\36418\324\253\033r\344\360I\324\036\033m\350>W\331\341\033l\3572Y\333t\033y\377\344"
4
    lengthInMeters: 28533
5
    segmentIds {
6
      type: OSM_WAY_ID
7
      segmentId {
8
        id: 230910249
9
        backwards: false
10
        startOffsetInMeters: 3031
11
      }
12
      segmentId {
13
        id: 631550315
14
        backwards: false
15
      }
12 collapsed lines
16
      segmentId {
17
        id: 631550313
18
        backwards: false
19
      }
20
      segmentId {
21
        id: 406702546
22
        backwards: false
23
      }
24
      segmentId {
25
        id: 406702549
26
        backwards: false
27
      }
28
      segmentId {
29
        id: 406702547
30
        backwards: false
31
        endOffsetInMeters: 11317
32
      }
33
    }
34
  }
35
  speed {
36
    averageSpeedKmph: 65
37
    travelTimeSeconds: 1580
38
    confidence: 100
39
  }
40
}

Identifier-based location referencing using GERS IDs

Identifier-based location referencing Global Entity Reference System (hereafter called ‘IDLR-GERS’) is offered as an alternative method of location referencing besides OpenLR and IDLR-OSM . It is not enabled by default and can be enabled upon request.

To obtain GERS IDs from the feed, you must request them using the URL parameter flowType=ff. A detailed explanation of how to use this parameter can be found in the section on Request Parameters .
Please note that GERS IDs are static data. They should only be re-requested as part of the flowType=ff feed (as mentioned in the first point) when there has been a change to the ff feed.
You can use the OpenLR codes to link messages from the nff feed to the corresponding messages in the ff feed, allowing you to identify the GERS IDs that were previously downloaded with the ff feed.

The following example shows a trafficFlow message with an IDLR-GERS in the segmentIds field indicated by type: GERS_ID that is composed of five GERS IDs. All IDs use the backwards direction, the first ID uses a start-offset, the second through fourth IDs have no offsets, and the fifth ID uses an end-offset. The affected location is the concatenation of all IDs minus the offset information.

Example

1
trafficFlow {
2
  location {
3
    openlr: "\v\004\'|#U\0203\345C\001}\374\216#ffZ"
4
    lengthInMeters: 979
5
    segmentIds {
6
      type: GERS_ID
7
      segmentId {
8
        id: 319719336117268785
9
        backwards: false
10
        startOffsetInMeters: 1594
11
        idHigh: 604038967628660735
12
      }
13
      segmentId {
14
        id: 319712699939139853
15
        backwards: false
16
        idHigh: 613046166810001407
17
      }
10 collapsed lines
18
      segmentId {
19
        id: 323919439968428109
20
        backwards: false
21
        idHigh: 617549766435536895
22
      }
23
      segmentId {
24
        id: 319695982581605327
25
        backwards: false
26
        idHigh: 613046166810001407
27
      }
28
      segmentId {
29
        id: 319411736432914706
30
        backwards: false
31
        endOffsetInMeters: 1398
32
        idHigh: 604038967628660735
33
      }
34
    }
35
  }
36
  speed {
37
    averageSpeedKmph: 38
38
    travelTimeSeconds: 93
39
    confidence: 100
40
  }
41
}

Note that a 128-bit GERS ID is composed of two 64-bit values represented by the fields id and idHigh. The field idHigh contains the most significant bits, while id contains the least significant bits. The following pseudocode illustrates how these fields should be combined.

1
gers_id = (idHigh << 64) | id

For more information on how to use GERS IDs, please visit the Overture Maps website .

Available features

This section describes the available features of the Service. Some features are enabled by default, while others are optional and can be enabled upon request.

Dynamic sectioning

Availability This feature is enabled by default.

Description

Availability	This feature is enabled by default.
Description	Dynamic sectioning describes the flow segments in smaller sections when conditions vary considerably within a longer road stretch. The Service uses the message type `SectionSpeed` to report sections. They are ordered by their offset relative to the start of the affected location. This offset is indicated by the `startOffsetInMeters` field of a `SectionSpeed` message. A section ends when the subsequent section starts. The last section ends at the end of the affected location indicated by the `lengthInMeters` field in the `Location` message. Note that this feature is also available for the flow message type `TrafficFlowWithPredictionPerSection`.

Dynamic sectioning describes the flow segments in smaller sections when conditions vary considerably within a longer road stretch. The Service uses the message type SectionSpeed to report sections. They are ordered by their offset relative to the start of the affected location. This offset is indicated by the startOffsetInMeters field of a SectionSpeed message. A section ends when the subsequent section starts. The last section ends at the end of the affected location indicated by the lengthInMeters field in the Location message.

Note that this feature is also available for the flow message type TrafficFlowWithPredictionPerSection.

Example

1
trafficFlow {
2
  location {
3
    openlr: "\v\254\320.!\367\n\033l\a\000Z\376\223\033\000"
4
    lengthInMeters: 425
5
  }
6
  speed {
7
    averageSpeedKmph: 11
8
    travelTimeSeconds: 144
9
    confidence: 81
10
  }
11
  sectionSpeed {
12
    startOffsetInMeters: 0
13
    speed {
14
      averageSpeedKmph: 2
15
      travelTimeSeconds: 115
16
      confidence: 81
17
    }
18
  }
19
  sectionSpeed {
20
    startOffsetInMeters: 48
21
    speed {
22
      averageSpeedKmph: 46
23
      travelTimeSeconds: 29
24
      confidence: 81
25
    }
26
  }
27
}

Flow prediction

Availability	This feature is optional and can be enabled upon request.
Description	Flow prediction uses the message type `TrafficFlowWithPredictionPerSection`. The current speed and predictive speeds for 15, 30, 45 minutes in the future are reported with sectioning if applicable.

Example

1
trafficFlowWithPredictionPerSection {
4 collapsed lines
2
  location {
3
    openlr: "\013\265\215\373\034\271\032\022V\031\371\033\000\031\022\010"
4
    lengthInMeters: 1518
5
  }
6
  speedVector {
7
    minutesInFuture: 0
8
    sectionSpeed {
9
      startOffsetInMeters: 0
10
      speed {
11
        averageSpeedKmph: 10
12
        travelTimeSeconds: 238
13
      }
14
    }
15
    sectionSpeed {
16
      startOffsetInMeters: 673
17
      speed {
18
        averageSpeedKmph: 48
19
        travelTimeSeconds: 63
20
      }
21
    }
22
  }
23
  speedVector {
24
    minutesInFuture: 15
14 collapsed lines
25
    sectionSpeed {
26
      startOffsetInMeters: 0
27
      speed {
28
        averageSpeedKmph: 10
29
        travelTimeSeconds: 240
30
      }
31
    }
32
    sectionSpeed {
33
      startOffsetInMeters: 673
34
      speed {
35
        averageSpeedKmph: 48
36
        travelTimeSeconds: 63
37
      }
38
    }
39
  }
40
  speedVector {
41
    minutesInFuture: 30
14 collapsed lines
42
    sectionSpeed {
43
      startOffsetInMeters: 0
44
      speed {
45
        averageSpeedKmph: 31
46
        travelTimeSeconds: 77
47
      }
48
    }
49
    sectionSpeed {
50
      startOffsetInMeters: 673
51
      speed {
52
        averageSpeedKmph: 51
53
        travelTimeSeconds: 60
54
      }
55
    }
56
  }
57
  speedVector {
58
    minutesInFuture: 45
14 collapsed lines
59
    sectionSpeed {
60
      startOffsetInMeters: 0
61
      speed {
62
        averageSpeedKmph: 31
63
        travelTimeSeconds: 78
64
      }
65
    }
66
    sectionSpeed {
67
      startOffsetInMeters: 673
68
      speed {
69
        averageSpeedKmph: 51
70
        travelTimeSeconds: 60
71
      }
72
    }
73
  }
74
}

HOV Flow

Availability This feature is optional and can be enabled upon request.

Description

Adds separate speed entries for lanes reserved for high-occupancy vehicles, for now only the current speed for the whole location is available. The following example shows TrafficFlow message with two speed entries, one for the regular lanes and one for the HOV lane(s).

Note that this feature is also available for the flow message type TrafficFlowWithPredictionPerSection.

Example

1
trafficFlow {
2
  location {
3
    openlr: "\v\251\003-!\331\326\001\f!\002K\371\264\001\037"
4
    lengthInMeters: 1939
5
  }
6
  speed {
7
    averageSpeedKmph: 76
8
    travelTimeSeconds: 92
9
    confidence: 100
10
  }
11
  speed {
12
    averageSpeedKmph: 90
13
    travelTimeSeconds: 78
14
    confidence: 100
15
    speedCondition {
16
      laneType: HIGH_OCCUPANCY
17
    }
18
  }

Map version

Availability This feature is optional and can be enabled upon request.

Description

Provides name and version of the map that was used to create the content. The map version is reported with the mapVersion field in the MetaInformation message.

Note that this feature is also available in snapshots with the flow message type TrafficFlowWithPredictionPerSection.

Example, minimal snapshot with a single message and meta information

1
metaInformation {
2
  createTimeUTCSeconds: 1696833480
3
  supplierAndClientInfo {
4
    clientID: "5b5977db-ab96-4599-b079-314a09cb9f204045d8f9"
5
    supplierID: "TomTom Traffic Service"
6
  }
7
  mapVersion: "nam2023.06.060"
8
}
9
trafficFlow {
10 collapsed lines
10
  location {
11
    openlr: "\v\215\332\024\'V\'\033e!\b\034\003\357\023B\034\004\311\005\005\023B\001\000O\000G\023D\003\001\004\000\223\023C\001\000E\000B\023\341#\371\025\375\022?\"\b"
12
    lengthInMeters: 6125
13
  }
14
  speed {
15
    averageSpeedKmph: 43
16
    travelTimeSeconds: 513
17
    confidence: 100
18
    relativeSpeed: 1.0
19
    trafficCondition: FREE_TRAFFIC
20
  }
21
}

Meta information & supplier and client information

Availability This feature is enabled by default.

Description

Availability	This feature is enabled by default.
Description	The `MetaInformation` message type provides data shared by all traffic flow messages. It contains: the creation time (TomTom uses the Epoch Linux Timestamp, which represents the number of seconds since January 1st, 1970 at UTC. For details, check https://www.unixtimestamp.com ) and the supplier and client information in the `SupplierAndClientInfo` message.

The MetaInformation message type provides data shared by all traffic flow messages. It contains:

the creation time (TomTom uses the Epoch Linux Timestamp, which represents the number of seconds since January 1st, 1970 at UTC. For details, check https://www.unixtimestamp.com ) and
the supplier and client information in the SupplierAndClientInfo message.

Example of MetaInformation with fields provided by default

1
metaInformation {
2
  createTimeUTCSeconds: 1696832700
3
  supplierAndClientInfo {
4
    clientID: "5b5977db-ab96-4599-b079-314a09cb9f204045d8f9"
5
    supplierID: "TomTom Traffic Service"
6
  }
7
}

The SupplierAndClientInfo is crucial for accessing a flow feed using the recommended free-flow (ff) / non-free-flow (nff) update mechanism as explained in the section Request parameters under the optional URL parameter flowType. The same mechanism needs to be applied for requesting Identifier-based location referencing using OSM way IDs or GERS IDs .

Relative speed

Availability This feature is optional and can be enabled upon request.

Description

When enabled, the relative speed to the free-flowing speed is given as a ratio (e.g., 0.250 indicates a current real-time speed that is 25% of free flow speed) in field relativeSpeed in the Speed message.

Note that this feature is also available for the flow message type TrafficFlowWithPredictionPerSection.

Example

1
trafficFlow {
2
  location {
3
    openlr: "\013\265f\361\034J\374\001\0349\363A\006\013\001\014"
4
  }
5
  speed {
6
    averageSpeedKmph: 23
7
    travelTimeSeconds: 534
8
    confidence: 99
9
    relativeSpeed: 0.229
10
  }
11
}

Speed message default information

Availability This feature is enabled by default.

Description

Availability	This feature is enabled by default.
Description	The `Speed` message subsumes all speed and travel time related information. It consists of the following default information: `averageSpeedKmph`: The current average speed on the affected location in kilometers per hour. `travelTimeSeconds`: The current average travel time to pass the affected location or free-flow travel time if average speed is 0 km/h (in seconds). `confidence`: A measure of confidence values that rates the reliability of this speed estimate. The quality, amount, and age of live data for the affected location contribute to this score. It scales from 0 (no confidence) to 100 (fully confident about the estimate). Note that the same default information is provided in `Speed` messages for the flow message type `TrafficFlowWithPredictionPerSection`.

The Speed message subsumes all speed and travel time related information. It consists of the following default information:

averageSpeedKmph: The current average speed on the affected location in kilometers per hour.
travelTimeSeconds: The current average travel time to pass the affected location or free-flow travel time if average speed is 0 km/h (in seconds).
confidence: A measure of confidence values that rates the reliability of this speed estimate. The quality, amount, and age of live data for the affected location contribute to this score. It scales from 0 (no confidence) to 100 (fully confident about the estimate).

Note that the same default information is provided in Speed messages for the flow message type TrafficFlowWithPredictionPerSection.

Example: default information in a flow message without prediction

1
trafficFlow {
4 collapsed lines
2
  location {
3
    openlr: "\v\254\320.!\367\n\033l\a\000Z\376\223\033\000"
4
    lengthInMeters: 425
5
  }
6
  speed {
7
    averageSpeedKmph: 11
8
    travelTimeSeconds: 144
9
    confidence: 81
10
  }
11
}

Time to usual

Availability	This feature is optional and can be enabled upon request.
Description	Provides the time duration (in minutes) for the average speed (of the entire location) of a flow message to return to the usual speed (speed profile). This feature is only available for flow message types `TrafficFlowWithPredictionPerSection`.

Example

1
trafficFlowWithPredictionPerSection {
45 collapsed lines
2
  location {
3
    openlr: "\v\n\031\\&\0032\v(\n\003q\377x\v\030"
4
    lengthInMeters: 622
5
  }
6
  speedVector {
7
    minutesInFuture: 0
8
    sectionSpeed {
9
      startOffsetInMeters: 0
10
      speed {
11
        averageSpeedKmph: 13
12
        travelTimeSeconds: 179
13
        confidence: 100
14
      }
15
    }
16
  }
17
  speedVector {
18
    minutesInFuture: 15
19
    sectionSpeed {
20
      startOffsetInMeters: 0
21
      speed {
22
        averageSpeedKmph: 13
23
        travelTimeSeconds: 179
24
      }
25
    }
26
  }
27
  speedVector {
28
    minutesInFuture: 30
29
    sectionSpeed {
30
      startOffsetInMeters: 0
31
      speed {
32
        averageSpeedKmph: 49
33
        travelTimeSeconds: 46
34
      }
35
    }
36
  }
37
  speedVector {
38
    minutesInFuture: 45
39
    sectionSpeed {
40
      startOffsetInMeters: 0
41
      speed {
42
        averageSpeedKmph: 49
43
        travelTimeSeconds: 46
44
      }
45
    }
46
  }
47
  timeToUsualInMinutes: 26
48
}

Traffic condition

Availability This feature is optional and can be enabled upon request.

Description

Provides a textual traffic condition indicator. When enabled, a categorization of current traffic condition is given. It can be any value out of seven values (see more details on FAQ about the definition of traffic conditions ):

FREE_TRAFFIC
HEAVY_TRAFFIC
SLOW_TRAFFIC
QUEUING_TRAFFIC
STATIONARY_TRAFFIC
CLOSED
UNKNOWN

Note that this feature is also available for the flow message type TrafficFlowWithPredictionPerSection.

Example

1
trafficFlow {
2
  location {
3
    openlr: "\013\265f\361\034J\374\001\0349\363A\006\013\001\014"
4
  }
5
  speed {
6
    averageSpeedKmph: 23
7
    travelTimeSeconds: 534
8
    confidence: 99
9
    trafficCondition: STATIONARY_TRAFFIC
10
  }
11
}

Traffic Flow - Protobuf

Purpose

Scope

Intended audience

Features

Request data

Important

HTTPS Method: GET

Request parameters

Request headers

Response data

Response codes

Response example

Response - Protobuf payload specification (analysis of the received output)

Important: Protocol buffers schema

Location referencing

OpenLR

Identifier-based location referencing using OSM way IDs

Identifier-based location referencing using GERS IDs

Available features

Dynamic sectioning

Flow prediction

HOV Flow

Map version

Meta information & supplier and client information

Relative speed

Speed message default information

Time to usual

Traffic condition

HTTPS Method: `GET`