Introduction & technical description
GTFS-Realtime is a standard developed by Google that enables transport companies to provide real-time information about various services.
The service is an extension to GTFS Static and enriches 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 companies which deliver real-time data.
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.
- Vehicle positions (currently not provided)
- Trip updates (provided by SBB)
- Service alerts (provided by SBB)
Vehicle positions
Contain data on events that have already occurred (e.g. “The vehicle was at this location one minute ago”),
Example: “This bus is at the Bern Bahnhof stop at 18h23”
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 other similar information can be provided.
Vehicle positions are not available on the platform.
You can find an extensive list of the individual possible information units at https://developers.google.com/transit/gtfs-realtime/reference/
Trip updates
Example: “Bus 18 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
Event information (service alerts) provide information about foreseeable or unforeseeable events that affect a station, a route or the entire network (e.g. “Line 3 is closed until 15:00 due to a traffic accident)
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.
Swiss implementation
Two of the three services are currently implemented in Switzerland. Namely “Trip Update” and “Service Alerts”
- The OpenDataPlatform currently only supports GTFS-RT “Trip Update” – Version 1.0. Please note that 2.0 elements are currently ignored.
- The OpenDataPlatform currently supports GTFS-RT “Service Alerts” – Version 2.0. Please note these differences in the service versions
- With your key, you can perform a maximum of two queries per minute on the interface.
- The real-time feed includes all known changes in public transport in Switzerland in the entire preview window (three hours) for all transport companies that provide real-time data.
- There is an update rule for delays for GTFS-RT. For example, if an entire journey is delayed by 5 minutes, this is only displayed at the first stop. The import delay must be updated for all further stops.
- The update must be carried out for arrival and departure times. 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 unchanged and only the arrival forecast changes, no GTFS-RT message is generated for this journey
Access to the service
SBB provides Trip updates via a GET request.
You can submit a maximum of two requests a minute to the interface using its key. A sliding window is used.
API | Link |
GTFS-RT
Service Alerts |
https://api.opentransportdata.swiss/gtfs-sa |
A token is required to access the API. To generate and receive a token, you have to register on the Open Data Platform Mobility Switzerland.
After successful registration, the “API Keys” tab must be selected. There you can obtain the corresponding key for the platform in the “Developer Dashboard” under “My Keys”.
The key is sent to the e-mail address provided during registration.
Data structure (protocol buffer)
The GTFS ServiceAlert data exchange format is based on Protocol Buffers, which is a language- and platform-neutral mechanism for serialising data. 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 query is then made via the URL: HTTP GET https://api.opentransportdata.swiss/gtfsservicealerts/?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-SA interface should not be operated in readable JSON, but binary (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
Description of the service
Special features compared to SIRI-SX
GTFS ServiceAlerts | SIRI-SX |
The agency is also supplied for each stop / stopping point.
"informedEntity" : [ { "agencyId" : "820" , "stopId" : "ch:1:sloid:89712" }, { "agencyId" : "801" , "stopId" : "ch:1:sloid:89712" } ], |
< StopPlaces > < AffectedStopPlace > < StopPlaceRef >ch:1:sloid:89712</ StopPlaceRef > < PlaceName >Kriens, Grosshofstrasse</ PlaceName > </ AffectedStopPlace > </ StopPlaces > |
The line direction is also supplied for each line
"informedEntity" : [ { "agencyId" : "801" , "routeId" : "96-186-7-j23-1" , "directionId" : 0 }, { "agencyId" : "801" , "routeId" : "96-186-7-j23-1" , "directionId" : 1 }, { "agencyId" : "801" , "routeId" : "96-186-2-j23-1" , "directionId" : 0 }, { "agencyId" : "801" , "routeId" : "96-186-2-j23-1" , "directionId" : 1 } ], |
< AffectedNetwork > < AffectedLine > < AffectedOperator > < OperatorRef >ch:1:sboid:100602</ OperatorRef > </ AffectedOperator > < LineRef >85:801:1867</ LineRef > < PublishedLineName >677</ PublishedLineName > </ AffectedLine > < AffectedLine > < AffectedOperator > < OperatorRef >ch:1:sboid:100602</ OperatorRef > </ AffectedOperator > < LineRef >85:801:1862</ LineRef > < PublishedLineName >675</ PublishedLineName > </ AffectedLine > </ AffectedNetwork > |
General mapping between GTFS Service Alerts and SIRI-SX
GTFS implementation
- Multilingual edition (DE, FR, IT, EN) of the Lang texts
- GTFS: “headerText” corresponds to SIRI-SX <SummaryText (L)>
- GTFS “descriptionText” is composed as follows, whereby several values per element are also strung together:
- Reason <ReasonContent>
- Duration <DurationContent>
- Information – <RemarkContent> – If supplied, not provided by all business organisations
- Effects <ConsequenceContent>
- Recommendation <RecommendationContent>
- Remark – <DescriptionContent> → If supplied, not provided by all business organisations
- Uri – Not available on current Prod version
- Label – not available on current prod version
- GTFS “activePeriod” is filled from <ValidityPeriod>
- All CH characteristics of the information space can be processed
- Events with multiple customer information can be processed (currently only VIA)
- Processing ValidityPeriod and PublicationWindow according to profile CH (i.e. always display all messages)
General description of the service (Google)
Service Alerts | Realtime Transit | Google for Developers
Existing elements according to GTFS:
Differences to the Google implementation:
message
Alert |
Link: https://developers.google.com/transit/gtfs-realtime/reference#message-alert
All elements are supported |
||||||||||||||||
message TimeRange
|
Link: https://developers.google.com/transit/gtfs-realtime/reference#message-timerange
Swiss Implementation Name (activePeriod) All elements are supported |
||||||||||||||||
message
EntitySelector |
Link: https://developers.google.com/transit/gtfs-realtime/reference#message-entityselector
Swiss Implementation Name (informedEntity) The following elements are not used
|
||||||||||||||||
message
TripDescription |
Link: https://developers.google.com/transit/gtfs-realtime/reference#message-tripdescriptor
Message is not supported / used |
||||||||||||||||
enum
ScheduleRelationship |
Enum is not supported / used in the Service Alert implementation. | ||||||||||||||||
Enum
Cause |
https://developers.google.com/transit/gtfs-realtime/reference#enum-cause
All listed values are used. Any not listed will not be used.
|
||||||||||||||||
Enum
Effect |
https://developers.google.com/transit/gtfs-realtime/reference#enum-effect
No effects are currently used. There is only the value “Condition: Unknown” from the EMS and the mapping to GTFS “Unknown_Effect” |
||||||||||||||||
message
TranslatedString |
https://developers.google.com/transit/gtfs-realtime/reference#message-translatedstring
All elements are supported |
Additional services:
Existing data records
The following business organisations provide event information: Business organisations – Data | Open Data Platform Mobility Switzerland (opentransportdata.swiss)