Skip to content

Real time data from road traffic counters

Traffic counters can be found along important road segments in order to measure all traffic movements by direction and time. They are able to count, classify and determine the speed of all vehicles crossing specific locations.

In Switzerland, road authorities are at any level in charge of operating their network of permanent automatic traffic counting stations on the country’s most important thoroughfares. The ultimate goal is to record all traffic movements by direction and time. This dataset can be seen as a common pot that regroups this type of data for all road authorities interested in sharing their data.

Description of the data

Format

DATEX II is the standard for the exchange of road traffic related data. The format is based on a specific XML schema. Each country is enabled to generate and publish specific profiles according to its needs.

The Swiss profile for DATEX II is based on DATEX II version 2.3.

Update frequency

The data is updated every minute and concerns the traffic movements of the previous full minute. New data always replaces the last published data. Historic data is not available for this dataset. The data from the last minute is always published 20 seconds after a full minute in UTC 0.

Content

The data relates to the static master data set “Traffic Counters (Road Traffic)” which can be found here or via this very same API.

Static data

The measurement site table (MST) informs users about the traffic counters network. Usually, traffic counters record data from more than one traffic lane. Multiple detectors are therefore used. In this context, detectors are called “Measurement Site Record” (MSR) and each of them has a unique ID in DATEX II.

The measurement site record table reveals information such as counters’ IDs, Supplier identifiers and georeferencing.

Dynamic data

The data is aggregated and published every minute. Basically, it provides the number of vehicles and average speed in two categories per “Measurement Site Record” (MSR):

  1. Light vehicles such as cars, motorbikes, buses and small delivery trucks (Swiss Class 1 to 7)
  2. Heavy goods vehicles such as trucks and trucks with trailers (Swiss Class 8 to 10)

For error handling purposes, two additional categories are communicated:

  1. The number of vehicles with no classification
  2. The number of vehicles with invalid speed (implausible data)

Example of dynamic data

Link between static and dynamic data

Each dynamic data publication links to an actual MST’s version. If the version number of the MeasurementSiteTable which is referenced in the dynamic data has increased (measurementSiteTableReference), please request the new MST by using the “pullMeasurementSiteTable” operation.

Filtering

As the complete dynamic data XML can be heavy to process, it is possible to request the data for a selection of MSR. The filter is transferred in an optional data structure (‘GenericPayLoad’) in the SOAP request for the ‘pullMeasuredData’ operation. According to the DATEX II profile for traffic data in Switzerland, the GenericPayload must contain the following elements:

  • Lang: enter “en” as default value
  • publicationTime: enter the current request timestamp
  • country: enter your country of origin
  • nationalIdentifier: With the pull service, this does not act as an identifier for authentication because IDs for consumers are not standardized. You can enter what you want here, it has no effect
  • Counters’ IDs are separated once with a colon and once with a dot.
    • XX: = acronym of the supplier (e.g. CH: = FEDRO, ZH: = Canton of Zürich)
    • = Counting station ID (e.g. 0610., or 0043.)
    • Detector ID going from 01 to 09 (e.g. 01, 02)
  • Filtering is supported by two possible syntax: MQTT and Regular Expressions (online regex tester)
  • On the right side of the colon, MQTT-Syntax can be used.
    • “+” is a one-level wildcard and can therefore be used several times.
    • “#” is an all-sublevels wildcard and can therefore only be used once and only at the end.

Example:

  1. MQTT-Syntax: CH:0610/# is translated in the regular expression CH:0610.[0-9.]* which will request all detectors of the counting station CH:0610
  2. CH:0610/+ (identical to 1. as long as the registrar does not use any further steps to the right of the “:”)
  3. CH:+.+ (all counting stations with all detectors of the supplier “CH”)
  4. CH:# (identical to 3., as long as the registrar does not use any further steps to the right of the “:”)
  5. CH:+. # (Formally allowed, result identical to 4.)

For version, the value “0” is interpreted as “current version” and includes numbers 1 or higher. This is useful as not all MSR IDs that match a wildcard expression necessarily have the same version.

For a complete example of a filtered request please refer to the examples page.

According to the examples above, a filter could look as follows:

<measuredDataFilter xsi:type="dx223:MeasuredDataFilter">
    <dx223:measurementSiteTableReference xsi:type="dx223:_MeasurementSiteTableVersionedReference" targetClass="MeasurementSiteTable" id="OTD:TrafficData" version="0"/>
    <dx223:siteRequestReference xsi:type="dx223:_MeasurementSiteRecordVersionedReference" targetClass="MeasurementSiteRecord" id="CH:0003.01" version="0"/>
    <dx223:siteRequestReference xsi:type="dx223:_MeasurementSiteRecordVersionedReference" targetClass="MeasurementSiteRecord" id="CH:0003/02" version="0"/> 
    <dx223:siteRequestReference xsi:type="dx223:_MeasurementSiteRecordVersionedReference" targetClass="MeasurementSiteRecord" id="CH:0346\.[0-9]*" version="0"/>
    <dx223:siteRequestReference xsi:type="dx223:_MeasurementSiteRecordVersionedReference" targetClass="MeasurementSiteRecord" id="CH:0347/+" version="0"/>
    <dx223:siteRequestReference xsi:type="dx223:_MeasurementSiteRecordVersionedReference" targetClass="MeasurementSiteRecord" id="CH:0610/#" version="0"/>
    <dx223:siteRequestReference xsi:type="dx223:_MeasurementSiteRecordVersionedReference" targetClass="MeasurementSiteRecord" id="CH:067[0-9.]*" version="0"/>
</measuredDataFilter>

Technical setup

Authorization with API key

An API key is necessary to get the dynamic data. The key can be obtained through the developer portal. You will need a key of the type “Traffic counters (road traffic)”.

When logged in, go to the menu “API keys” and select the corresponding key:

The token should be sent in the HTTP header with the name “Authorization” (see example below).

Such a key allows for 260,000 queries within 6 months.

URL to pull data

The OpenTransportData (OTD) platform offers a PULL interface where the data can be accessed over http POST requests (SOAP, not REST).

https://api.opentransportdata.swiss/TDP/Soap_Datex2/Pull

Attention: no “/” at the end of the URL

With the Authorization Header and Content-Type = “text/XML” or “application/XML”

Authorization header

SOAP operations

As described in the WSDL File, there are three possible operations:

  • pullMeasurementSiteTable: answers with the full and up-to-date MST
  • pullMeasuredData: answers with up-to-date dynamic data
  • keepAlive: for developing purposes

Always use SOAP operations. We created a SOAPUI project to show it.

Access to the data (conditional Open Data)

As part of the data exchange strategy of the FEDRO, this data is available under the concept of “conditional open data”. The goal is to encourage potential traffic data owners to participate in this data community by supplying some of their traffic data. In exchange, they get a full open data access. However, users can access the data during six months without any restriction. If a user needs longer access to the data, please contact the FEDRO administrator. For more detail, please read the FEDRO terms and conditions.

Expected data quality

The data is transmitted in “best effort” mode with minimal plausibility checks and it has not been formally verified. For more precision, the data should be correlated with other data such as construction sites etc. Therefore, there might be differences between this “raw” data and the official road authorities’ statistics.

Error Handling

Error code Description, Translation
EMPTY_RESPONSE EN:   The data provider is offline.

DE:   Der Datenlieferant ist offline.

FR:   Le fournisseur de données est hors ligne.

IT:     Il fornitore di dati è offline.

PRV_OFFLINE EN:   A third party supplying system is currently offline.

DE:   Ein Drittanbieter-System ist momentan offline.

FR:   Un système d’approvisionnement tiers est actuellement hors ligne.

IT:     Un sistema di fornitura di terze parti è attualmente offline.

AGG_OFFLINE EN:   The aggregation module is currently offline.

DE:   Der Aggregationsdienst ist momentan offline.

FR:   Le service d’agrégation est actuellement hors ligne.

IT:     Il servizio di aggregazione è attualmente offline.

VD_OFFLINE EN:   Communication interruption with the vehicle detector or vehicle detector is offline. No reception of traffic messages.

DE:   Die Kommunikation zum Verkehrszähler ist unterbrochen oder der Verkehrszähler ist offline. Es werden im Moment keine Daten empfangen.

FR:   La communication avec le compteur de trafic est interrompue ou le compteur de trafic est hors ligne. Aucune donnée n’est reçue pour le moment.

IT:     La comunicazione con il contatore del traffico viene interrotta o il contatore del traffico è offline. Al momento non vengono ricevuti dati.

VD_ERROR EN:   The vehicle detector is defect and is therefore not transmitting any data or the transmitted data are invalid.

DE:   Der Verkehrszähler ist defekt und sendet daher keine oder ungültige Daten.

FR:   Le compteur de trafic est défectueux et n’envoie donc aucune donnée ou des données invalides.

IT:     Il contatore di traffico è difettoso e quindi non invia dati o dati non validi.

SENSOR_ERROR EN:   The sensor of the vehicle detector is defect and is therefore not transmitting data or the transmitted data are invalid.

DE:   Der Sensor des Verkehrszählers ist offline oder defekt und sendet daher keine oder ungültige Daten.

FR:   Le capteur du compteur de trafic est hors ligne ou défectueux et n’envoie donc aucune donnée ou des données invalides.

IT:     Il sensore del contatore di traffico è difettoso e quindi non invia dati o dati non validi.

SENSOR_WWD EN:   The sensor has detected traffic in wrong direction. Possible reasons: due to diversion in construction zone, wrong way driving.

DE:   Der Sensor hat Verkehr in Gegenrichtung detektiert. Mögliche Ursachen: Umleitung wegen Baustelle, Falschfahrer oder zum Beispiel durch ein Überholmanöver.

FR:   Le capteur a détecté du trafic dans la direction opposée. Causes possibles: Déviation due à un chantier de construction, conducteur roulant en sens inverse ou par exemple lors d’un dépassement.

IT:     Il sensore ha rilevato il traffico nella direzione opposta. Possibili cause: Deviazione a causa del cantiere, contromano.

More information about DATEX II

https://datex2.eu/

Traffic Data Downloader

The “Traffic Data Downloader” tool allows you to conveniently download and save the current data and master data on your computer. The tool generates a CSV file for each download started.

Traffic Data Downloader V1.0 is freely available. Once the application is launched, you only have to enter your API key, define the output folder and start the download.