GTFS Realtime (GTFS-RT) is an extension to GTFS Static and enhances the static transit information with real-time information. GTFS real-time data is reconciled with GTFS static data. The real-time feed includes all known changes in public transport in Switzerland in the overall preview window (three hours) for all transport undertakings which deliver real-time data.
Technical description
GTFS-RT enables the static transit information to be enhanced with three different types of supplementary information. These three sources of enhancement are usually available separately via HTTP and are updated regularly so that developers can choose which real-time data they would like to use to enhance their applications.
The three types of supplementary information are:
- Trip updates
- Service alerts
- Vehicle positions (are not published on the Open Data Platform Mobility Switzerland)
Trip updates
Example: “18 bus is currently 10 minutes late”
In this case, delays, modified routes, replacement vehicles or cancellations for individual lines are constantly published to enable passengers to plan their journeys as accurately as possible.
Service alerts
Example: “Bern, Weissenbühl station is currently closed due to an accident”
If the stop for boarding is moved or generally unforeseen events occur which have an impact on a stop, route or the whole network, brief messages can be published to keep passengers up to date and explain the reason for the change.
Data set: GTFS Realtime – Service Alerts
Vehicle positions
Example: “This bus is located at the stop Bern, Bahnhof at 18:23”
In this case, information about the location of individual transit vehicles can be published. In addition, the vehicle’s current occupancy rate, the vehicle type or similar information can be provided.
Vehicle positions are not available on the platform.
You can find an extensive list of the individual information units at https://developers.google.com/transit/gtfs-realtime/reference/
Key concepts
- GTFS Static: Publication of static transit information in GTFS format.
- GTFS Realtime: Publication of real-time information to enhance the static GTFS data, in the form of protocol buffers.
Technical aspects
The SBB provides Trip updates via a GET request.
Authorisation and Open Services
An API key is required to access this API. It can be obtained via the Developer Portal. You need a key of the type “Default Key”. The token must be sent in the HTTP header as “Authorization”.
Test-Key: 57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1
Maximum number of requests per minute
You can submit a maximum of two requests per minute to the interface using its key. A sliding window is used.
When the request is made too quickly, the following message is returned:
|
1 2 3 |
{ "error": "Rate limit exceeded" } |
Reference to GFTS Static
Every GTFS-RT feed is based on an item of GTFS Static data. This is provided on Mondays and Thursdays (see next section for disruptions). Each time at 3 pm, the GTFS-RT feed will be switched to the new GTFS Static. As many of the IDs (“service_id”, “trip_id”) are regenerated for each version of GTFS Static, it is vital to refer to the correct GTFS Static to ensure the interface is correctly implemented.
| Publication GTFS-S | Activation GTFS-RT |
| Monday between 9 and 10 am | Monday 3 pm |
| Thursday between 9 and 10 am | Thursday 3 pm |
Management of disruptions
If something goes wrong during the regular releases on Monday or Thursday, the corrected GTFS data pair will be published as soon as possible after the disruption.
In these cases, GTFS Realtime is switched to this new version 6 hours after the publication of the corresponding GTFS Static data set (which can also be recognised by the respective feed version in GTFS Realtime).
Access URL
HTTP GET at https://api.opentransportdata.swiss/gtfsrt2020
(NB: No “/” at the end)
With the Authorization header and Content type= “text/XML” or “application/XML”
Content type: We suggest you set “application/octet-stream”.
Data structure (protocol buffer)
The format GTFS Realtime is based on protocol buffers, which is a language- and platform-neutral mechanism for bring data into a serial sequence. It is designed in binary format, which makes it smaller, faster and simpler than XML. The data structure is defined in a gtfs-realtime.proto file, which is used to generate source code to translate the structured data simply into various languages (Java, C++, Python etc.).
Data structure (JSON)
The platform also provides a JSON implementation as an alternative option.
The request is then submitted via the URL: HTTP GET https://api.opentransportdata.swiss/gtfsrt2020?format=JSON
Please note that the JSON option is not standardised.
Use of JSON for test purposes only
JSON may only be used for test purposes, e.g. if a developer of a new app wants to see in readable form what data is contained in our GTFS-RT.
In the end, the GTFS-RT interface should not be operated in readable JSON, but in binary form (without ?FORMAT=JSON) for the following reasons:
- binary is much more performant than JSON and there is much more data to transfer and read in JSON (a JSON message is up to approx. 11 MB in size),
- JSON is not specified, with binary GTFS-RT the GTFS client can rely on it conforming to the GTFS-RT standard
Accuracy
The delays have an accuracy of one tenth of a minute (0.1 min = 6 s).
Compression
It will soon be possible to obtain the JSON flow in compressed form too.
The following header must be included to do this:
|
1 |
Accept-Encoding: gzip, deflate |
A compression level of around 90% is achieved. This means that the data will be transferred much more quickly.
Interpretation of data
The GTFS specification can be consulted directly in order to obtain the exact interpretation of the data.
The major special case are platforms, which are described on the GTFS website.
Other important points
- GTFS-RT only provides new data if something has changed. Only the departure forecast is taken into account by our system. If the departure forecast remains the same and only the arrival forecast changes, no GTFS-RT message is generated for this journey.
-
If a journey runs on time, it is output with “Delay“: 0 on the StopTimeUpdate. For example:
Questions & Answers
| What does a real-time message without “stop_time_updates” mean? | Real-time messages without “stop_time_updates” are triggers without real-time. Changes have been made in this regard so that journeys without real time are no longer transmitted. |
| Could it be that on the lines where the data quality is poor, a gtfsrt entity is always delivered with delay=0 instead of no gtfsrt entity being delivered at all? | No, that is not the case. Either a journey has real time and all delays are also displayed or it has no real time. Delay 0 means real time and on time. Either we did not receive a delay in VDV 454 AUS, or we were unable to process the message with the forecast. |
More detailed information
You can find more detailed information about GTFS Realtime on Google’s GTFS developer website: https://developers.google.com/transit/gtfs-realtime/