Intermediate Traffic Service API - FAQ
Frequently Asked Questions
How big are the feeds?
The sizes of the incident feed and flow feeds differ by country.
The following table shows sizes of gzip compressed snapshots of our feeds, based on the country and feed type. Detailed flow feeds show the measurement for non-free-flow (nff) and free-flow (ff). The 50th (p50) and 95th (p95) percentiles are given, better reflecting daytime variations. The values are rounded up to multiples of 100 kilobytes to compensate for seasonable effects. The feed sizes for the detailed flow feed also take into account predictive flow.
This data is from June 2020 (during the COVID-19 pandemic).
Country | Incidents Datex2
| Incidents Datex2
| Flow Protobuf (detailed)
| Flow Protobuf (detailed)
| Flow Protobuf (detailed)
|
---|---|---|---|---|---|
AND | 100 | 100 | 100 | 100 | 100 |
ARE | 100 | 100 | 100 | 100 | 400 |
ARG | 100 | 100 | 100 | 200 | 2500 |
AUS | 400 | 400 | 300 | 700 | 5600 |
AUT | 200 | 200 | 100 | 200 | 3000 |
BEL | 300 | 300 | 200 | 400 | 1700 |
BGR | 100 | 100 | 200 | 300 | 1900 |
BHR | 100 | 100 | 100 | 100 | 100 |
BIH | 100 | 100 | 100 | 100 | 300 |
BLR | 100 | 100 | 100 | 200 | 1900 |
BRA | 100 | 100 | 300 | 800 | 7100 |
BRN | 100 | 100 | 100 | 100 | 100 |
CAN | 200 | 200 | 300 | 500 | 3400 |
CHE | 300 | 300 | 200 | 300 | 2000 |
CHL | 100 | 100 | 100 | 100 | 1300 |
COL | 100 | 100 | 100 | 100 | 800 |
CZE | 200 | 200 | 200 | 300 | 3300 |
DEU | 1000 | 1100 | 1400 | 2000 | 19100 |
DNK | 100 | 100 | 100 | 200 | 900 |
EGY | 100 | 100 | 100 | 200 | 1800 |
ESP | 200 | 200 | 400 | 600 | 11300 |
EST | 100 | 100 | 100 | 100 | 600 |
FIN | 200 | 200 | 100 | 200 | 2800 |
FRA | 300 | 300 | 800 | 1700 | 18200 |
GBR | 700 | 700 | 200 | 600 | 3100 |
GIB | 100 | 100 | 100 | 100 | 100 |
GRC | 100 | 100 | 200 | 200 | 3300 |
HKG | 100 | 100 | 100 | 100 | 100 |
HRV | 100 | 100 | 100 | 100 | 1400 |
HUN | 200 | 200 | 200 | 200 | 1700 |
IDN | 100 | 100 | 200 | 400 | 1500 |
IND | 100 | 100 | 600 | 1200 | 11400 |
IRL | 100 | 100 | 100 | 200 | 1100 |
ISL | 100 | 100 | 100 | 100 | 200 |
ISR | 100 | 100 | 100 | 200 | 600 |
ITA | 300 | 300 | 600 | 1200 | 10600 |
JPN | 100 | 200 | 1300 | 2700 | 6100 |
KAZ | 100 | 100 | 100 | 100 | 500 |
KEN | 100 | 100 | 100 | 100 | 400 |
KWT | 100 | 100 | 100 | 100 | 200 |
LIE | 100 | 100 | 100 | 100 | 100 |
LSO | 100 | 100 | 100 | 100 | 100 |
LTU | 100 | 100 | 100 | 100 | 600 |
LUX | 100 | 100 | 100 | 100 | 300 |
LVA | 100 | 100 | 100 | 100 | 400 |
MAC | 100 | 100 | 100 | 100 | 100 |
MAR | 100 | 100 | 100 | 100 | 900 |
MCO | 100 | 100 | 100 | 100 | 100 |
MEX | 100 | 200 | 500 | 700 | 7900 |
MLT | 100 | 100 | 100 | 100 | 100 |
MOZ | 100 | 100 | 100 | 100 | 300 |
MYS | 100 | 100 | 100 | 200 | 1300 |
NGA | 100 | 100 | 100 | 200 | 1000 |
NLD | 200 | 200 | 200 | 300 | 1900 |
NOR | 200 | 200 | 100 | 200 | 2200 |
NZL | 100 | 100 | 100 | 200 | 600 |
OMN | 100 | 100 | 100 | 100 | 200 |
PER | 100 | 100 | 100 | 100 | 900 |
PHL | 100 | 100 | 200 | 300 | 700 |
POL | 200 | 200 | 300 | 500 | 6200 |
PRT | 100 | 100 | 100 | 200 | 3400 |
QAT | 100 | 100 | 100 | 100 | 200 |
ROU | 100 | 100 | 200 | 300 | 2000 |
RUS | 300 | 400 | 600 | 1000 | 4200 |
SAU | 100 | 100 | 100 | 100 | 1000 |
SGP | 100 | 100 | 100 | 100 | 200 |
SMR | 100 | 100 | 100 | 100 | 100 |
SRB | 100 | 100 | 100 | 200 | 600 |
SVK | 100 | 100 | 100 | 200 | 1200 |
SVN | 100 | 100 | 100 | 100 | 1200 |
SWE | 200 | 200 | 100 | 200 | 2700 |
THA | 100 | 100 | 300 | 500 | 3000 |
TUR | 200 | 300 | 500 | 700 | 8900 |
TWN | 100 | 100 | 300 | 400 | 1200 |
UKR | 100 | 100 | 200 | 300 | 4300 |
URY | 100 | 100 | 100 | 100 | 300 |
USA (middle) | 600 | 700 | 1000 | 1600 | 11600 |
USA (north) | 600 | 700 | 700 | 1200 | 9000 |
USA (south east) | 400 | 400 | 700 | 1300 | 8700 |
USA (south west) | 300 | 400 | 900 | 1500 | 9100 |
VAT | 100 | 100 | 100 | 100 | 100 |
VNM | 100 | 100 | 100 | 200 | 1100 |
ZAF | 100 | 200 | 200 | 400 | 3400 |
I have access to multiple incident and / or flow feeds. How many feeds can be downloaded and processed in parallel?
There is no ideal setup for downloading and processing the feeds as there are many parameters that can have an influence on the overall performance. The following are just a few parameters (there may be more):
- The bandwidth of the internet connection from your servers to your internet service provider (ISP).
- The potential limitation of network bandwidth between your ISP and TomTom.
- The latency between your system and TomTom servers deployed in (Western) Europe.
- The performance of your system in ingesting and processing the retrieved data.
Due to these limitations we can make the following general recommendations:
-
It may be advisable to download and process only a few feeds in parallel, or to download the individual feeds with a certain time delay.
-
Your client should support TCP window scaling. With this option, we can send more data to your client before an acknowledgement comes back from your client. This improves throughput, especially in low latency connections. Latency is determined with tools like PsPing (https://docs.microsoft.com/en-us/sysinternals/downloads/pstools). To test latency between your servers and
traffic.tomtom.com
, use the following command:psping traffic.tomtom.com:443Further examples of how to use PsPing are found on the download page. While this tool is only available for Windows, there are alternatives for other operating systems here: https://alternativeto.net/software/psping. Since ICMP is not supported by our service, the usual ping command will not work.
-
Always use gzip compression by specifying the standard HTTP header
Accept-Encoding: gzip
. -
Always use the
If-Modified-Since
header with the time stamp of theLast-Modified
header for the last snapshot received in the same feed. This eliminates the possibility of downloading data that you already have. -
Use free-flow (ff) / non-free-flow (nff) update mechanism for all flow feeds. This significantly reduces the total bandwidth consumption when compared with full-feed downloads. The same information is retrieved!
Do the feeds contain specific events on road regulations due to COVID-19?
As movement restrictions are lifted after the COVID-19 lockdown, various local, regional, and national authorities introduce various measures that impact road regulations. Even if these impacts are only on a temporary basis, they can affect traffic in a significant way by creating closures due to change of permitted road use, restricting road access to local residents only, introducing new bike lanes, or reduced speed limits.
TomTom strives to provide up-to-date information about these dynamically changing road conditions through the TomTom Traffic Incidents – Intermediate Service API. During the unprecedented COVID-19 situation, TomTom is working together with our partners and authorities to ensure high-quality, reliable information.
TomTom delivers the following event types related to the COVID-19 pandemic.
Event | Alert-C event codes |
---|---|
Closed to all traffic. | 401 |
Closed to through traffic. | 493 + 1854 |
Closed based on other restrictions/conditions (i.e., the purpose of travel in case of border closures). | 493 |
Reduced amount and/or width of lanes lane layout (i.e., when increasing space for bikes and pedestrians). | 518 |
Any event in any country related to COVID-19 contains at least "COVID-19" in the comment field. The text may also contain further information.
Where is the Intermediate Traffic Service hosted?
This service is hosted on Microsoft Azure. Since Microsoft Azure hosts services in the public cloud, the IPs are non-static. One result is that the IPs can change at any time. For this reason, filters restricting outbound connection to our service will not work. You must rely on the host name for determining the IP address of this service.
What is the difference between Flow DatexII, Flow – Protobuf and Flow Detailed Protobuf?
The following tables lists all flow features and their availability depending on the product type ( Flow, Flow Detailed) and output format (DATEX II, Protobuf).
Individual Feature | Description | Flow - DATEX II | Flow - Protobuf | Flow Detailed - Protobuf | Flow Detailed Legacy - Protobuf |
---|---|---|---|---|---|
High road coverage | Feed covers road segments with high functional road classes and also many road segments with low functional road classes. | No | No | Yes | Yes |
Traffic Condition | Provides a textual traffic condition indicator (e.g., 'stationary traffic' or ‘slow traffic’). | Yes | Yes | Yes | Yes |
Heavy traffic | Adds support for the traffic condition “heavy traffic”. This feature only works in combination with the Traffic Condition feature. | Yes | Yes | Yes | Yes |
Relative Speed | Provides an additional percentage value of the current speed compared to free flow. | Yes | Yes | Yes | Yes |
Miles per hour | Mph is reported in addition to the speeds reported in kph. | Yes | Yes | Yes | Yes |
Time to usual | Provides time in minutes for the speed to return to usual speed (Speed Profile). | No | Yes | Yes | Yes |
HOV lanes | Adds separate speed entries for lanes reserved for high-occupancy vehicles. | No | Yes | Yes | Yes |
Predictive Flow (15, 30, 45 minutes) | Provides predictive speeds for 15, 30, and 45 minutes in the future. | No | Yes | Yes | No |
Predictive Flow (24h) | Provides predictive speeds for up to 24 hours in the future. | No | Yes | No | No |
Dynamic sectioning | Allows sectioning which describes the road links in smaller sections when conditions vary considerably within a longer stretch. In case of prediction, sectioning is supported only for 15, 30, 45 minutes. | No | Yes | Yes | No |
Map version | Provides the map version being used. | Yes | Yes | Yes | Yes |
TMC | TMC location codes. | Yes | Yes | Yes | No |
OpenLR | OpenLR binary strings. | Yes | Yes | Yes | Yes |
TMC + OpenLR | OpenLR binary strings and TMC location where available in one feed. Requires that both referencing methods are supported in the requested country(s). | Yes | Yes | Yes | No |
What speeds are contained in the non free flow (nff) feeds?
The Intermediate Flow feed has the concept of a free flow (ff) feed and a non-free flow (nff) feed, as explained in the documentation (TomTom Traffic Flow - Intermediate Service - Protobuf). The nff-feed consists of the flow feed segments which contain a traffic delay. The threshold for the nff-feed is per default set at 90% of the free flow speed, so all segments between 90-100% free flow speed are not reported in the nff-feed.
However, TomTom offers the configuration option to increase or decrease the threshold of the nff-feed.
A low threshold (e.g., 70%) will heavily reduce the feed size of the nff-feed, which might be desirable
if there are bandwidth constraints for the customer receiving the feed. A high threshold (e.g., 99%) will
allow that more live data is send through the nff-feed but will also increase the feed size.
The filtering is explained by the following graph:
What are the use cases to have both TMC and OpenLR in the same Flow (Detailed) feed?
The possibility to have have TMC and OpenLR in a single flow feed facilitates different use cases on the client side. Clients that are operating a hosted traffic service can serve TMC-only, OpenLR-only, or TMC-or-OpenLR (hybrid approach) devices from a single B2B feed. The vast majority of all TMC links can also be represented as OpenLR location reference.
However, in some cases the encoding is not possible. For that reason clients that intend to use the hybrid approach need to ignore all flow messages with only TMC information. These stretches are covered by other flow messages with only OpenLR location information. The following table outlines the rules by device requirement that need to be applied to cover all necessary flow segments.
Use case | Filtering |
---|---|
TMC-only | ![]() |
OpenLR-only / TMC or OpenLR (hybrid) | ![]() |
What are the definitions of the different traffic condition values in the Flow feed?
The traffic condition indicates the traffic status according to the relative speed of the location. It is aligned with the traffic jams reported in the corresponding Incident feed. When the relative speed of an entire flow segment or a flow section is below 90% and there is no traffic jam reported in the Incident feed, the "heavy traffic" traffic condition is used to indicate a slight reduction in traffic flow.
Traffic condition | Relative speed range |
---|---|
free traffic | 90% - 100% |
heavy traffic | 62.5% - 90% |
slow traffic | 35% - 62.5% |
queuing traffic | 25% - 35% |
stationary traffic | 0% - 25% |
There are three other traffic conditions defined in our schemas:
- "closed" means that you cannot pass the road segment,
- "long queues traffic" is not used and
- "unknown" indicates that a traffic condition is not provided.
How does one go about identifying all roads that are currently closed, using the Incident Feed?
Customers shall only rely on the NetworkManagementTypeEnum
value roadClosed
to identify closures.
I use detailed Flow (Dynamic Sectioning) and I want to enable the 15/30/45 minute prediction. How will enabling prediction affect the flowType setting?
Enabling prediction doesn't affect the flowType
(ff
/nff
) mechanism. The only effect is that all the messages will be enriched with prediction info, including the free-flow messages.
How, exactly, do I access TomTom's Intermediate Traffic Feed?
The Intermediate Traffic Service is an API. The TomTom Intermediate Traffic feed can be accessed using any interface that supports REST HTTP GET communication, depending upon one's development or application requirements:
- For an initial check of the data and to test access to the feeds, tools such as Postman or the command line tool CURL can be used. Since our default authentication mechanism requires a valid client certificate, feed access with a web browser may not work.
- For productive use, a programmatic setup should be used for sending these GET requests and receiving the responses. Typical modern general-purpose programming languages provide HTTP client libraries to accomplish this, including, but not limited to Python, Java, or C++.
If you intend to retrieve the data at a high frequency (for example, every minute), we recommend using the
standard HTTP header If-Modified-Since
with the value of HTTP header Last-Modified
of the
last response received. When this header is used properly, you avoid unnecessarily downloading identical content.
The use of additional recommended HTTP headers is explained on the individual pages of the product documentation.