Skip to content


Is there such thing as a journey planner service?

A “journey planner” function means searching for services that will get you from one stop to another. These two stops do not necessarily have to be on the same route/line. In other words, your journey may also involve changes. It is also known as a “route finder”.
Although does not offer a service of this kind, it does provide the fundamental data and timetable datasets you would need to develop your own journey planner. also enables you to add real-time information to your journey planner if you integrate one of the two journey forecast APIs.

What is the difference between real-time, forecast and actual information?

The terms are often used synonymously in different combinations. Real-time information is data that is produced and transmitted on an ad hoc basis. It may comprise planning, forecast and/or actual information.
Forecast information refers to the data calculated based on the current situation, e.g. arrival and departure time at/from the next stop.
Actual information refers to data on when and where services actually ran. This information is rarely available in real time and can usually only be generated retrospectively.

Which stop list should I use?

Even just on, there are several lists and tables of stops in Switzerland. More can be found on other platforms and portals. Because all the data on stops in Switzerland comes from DiDok, this dataset is to be regarded as the most original and most up-to-date source of information. There is also the station list, which is an extract from the current timetable dataset (HRDF) and which serves as a basis for requests concerning the departure/arrival Display.

Problems with the character set when importing the CSV files in Excel

The CSV files are coded in UTF-8. This can cause problems when opening the CSV files «normally» in Excel because Excel assumes a different character set.

The following procedure can help here: Create an empty Excel sheet and then select Data / Get External Data / From Text in the menu. After selecting the file, in the next dialogue step you can enter «Unicode (UTF-8)» under File Origin.

What kind of message will I get if the quota of my API key has been exceeded?

A status 429 is returned.

The service’s answer is then:

Why do the trip_ids from the realtime not match those in the static?

Is the trip you are talking about missing in the static File or only in GTFSR?

Because if a trip is missing in the static file its normal that you cant find it in the GTFSR file.

What does a realtime message that does not include “stop_time_updates” mean?

Real-time messages without “stop_time_updates” are trips without real-time. We have changed that. Travels without real time are no longer transmitted

For which services is there realtime – and how many trips is that?

How many: Currently always as many as you as answer in the GTFSR response get.
The following transport agencies deliver realtime data:

The trip update for trip_id =”94.TA.42-2-Y-j17-1.55.H” provides a stop update for stop_id =”8507483:0:3″ with the sequence “4”, but this trip in GTFS on sequence “4” has the stop_id =”8507483:0:4″.

That’s right. This is how track changes are displayed in GTFSR. We implemented this with the last release. GTFS 8507483: 0: 4 and GTFSR 8507483: 0: 3 “means that the planned track is 4, but the current track is now 3 due to changes. We recommend that you only map at the level of the stops.

GA and HTA file: Is it planned to publish this data on the basis of the municipalities?

No, we cannot publish this data at the community level, as we do not know the allocation to the community.  We made this list based on the customer’s address and he does not indicate his municipality there.
However, you can do this in the same way as SRF:
The information on the interactive map and the values in the article are taken from the Direct Transport Switzerland data set ( for the distribution of GA and Half-Fare travelcard between 2012 and 20116.  In a first step, the assignment to the data of the permanent resident population valid at that time was based on the postal code (31.12.2015).  The GWR correspondence table published by the FSO (as at 01.01.2017) was used for the subsequent comparison between postal code and municipality.  This made it possible to establish a direct link to the generalised municipal boundaries published by the FSO as of 1.1.2017 and to the spatial structure of Switzerland.  Due to averaging data for postal codes with less than 20 subscriptions, the map may be slightly distorted, especially in small communities.
Details on this
lante track is 4, but the current track is now 3 due to changes.  We recommend that you only map at the level of the stops.

Are there any differences in the quality of the delivered API values? Are the origin of the data, method of calculation and latencies the same everywhere?

All request types have the same data source. Therefore, none of the request types is to be preferred. Please select the request that best suits your application.

Which transport companies provide real-time data?

You can find an overview here:
The list contains all transport companies/business organizations for which real-time is available.

What do the first and last two sections of trip_id mean? For example, {405}.TA.26-752-j17-1.{3}.{R}

The trip_id consists of the following parts: “<consecutive number in the trips.txt>.<service_id>.<route_id>.DIVA route number>.DIVA direction of travel>”

route_id = <DIVA site branch>-<DIVA line number>-<DIVA project short name>-<DIVA line version number>

Why are queries only allowed for direct journeys?

Until now, the connection logic was provided by However, this service was discontinued on 31.07.2018.

In order to continue to ensure access, which a large and growing number of innovative projects require, now provides its own backend, which, thanks to the new real-time data from, can also provide up-to-the-minute timetable queries and route calculations.

As a result, users change as little as possible in absolute terms, the interface is largely identical, but proprietary SBB data such as the capacity utilisation indicator are no longer included in the data.

The new implementation can now be tested at, the conversion to the new solution took place on July 31, 2017.

The service is offered by and as a “best-effort” service, without guarantees for the availability or quality of the data and calculations. Depending on the application, the Viadi API is also available:

How does the data from the sensor reach the open data platform öV Schweiz at the transport company?

We cannot go into detail here, as this also differs depending on the TRANSPORT COMPANY. The big pictransport companyre below shows the rough overall contexts from the data sources to the publication of the information/data:

The complexity and variability of the transport companies (TRANSPORT COMPANY) is not shown on the Big Pictransport companyre. However, there are many solutions and different characteristics, so one TRANSPORT COMPANY uses one Excel, while another TRANSPORT COMPANY uses a fully integrated system for all layers.

Basically, however, a distinction can be made between three shifts in the transport companies:

1st stops: form the foundation of public transport and are therefore identified and managed throughout Switzerland by the national DiDok system.

2nd Timetable system: Each transport company creates the timetables that are to be communicated to the customer. On the one hand, the TRANSPORT COMPANY itself will publish the timetables (e.g. as a poster at the stop), on the other hand, the timetable data must be included in a larger pool.

The (operational) control system is used for ad hoc planning, i.e. changes to the original planning are either recorded (e.g. delays) or actively made (e.g. detours). This layer also contains very simple systems (e.g. a mobile phone), which only records the current position and calculates the forecast.

The fact is that there are numerous systems at the numerous transport companies that can behave differently in the processing as well as in the provision of data. This heterogeneity is relativized and standardized in intermediate steps.

Intermediate stages

Before the data is published, it is collected. In a first step, the data is combined in a regional data collector or a regional data hub. Here, too, the big pictransport companyre has been simplified, as the regional systems can include fully integrated systems (e.g. interconnected systems), systems from a nationally operating company (e.g. Postbus) or a hub that collects data nationwide (e.g. Bernmobil). Here, too, there is more than one system per shift (exception: stops), but not as many as with the source systems.

Sooner or later, however, the data will land in the three national systems DiDok (stops), INFO+ (timetable) or CUS (real-time). Currently, only DiDok and INFO+ can be assumed to have received the corresponding data from all Swiss universities of technology. At CUS, only a selection of the TRANSPORT COMPANY currently provide real-time data. There are two reasons for this:

  1. not every TRANSPORT COMPANY has an (operating) control system.

2.not every TRANSPORT COMPANY, which has an (operating) control system or not every data hub, provides data in the desired format.

The aim, however, is that, over time, as many Swiss universities as possible will deliver real-time data.


The data are transferred from the national collection systems into two publication systems:

1st cube: cube prepares the data so that they can be neatly published on (the annual timetable to check before it is valid) and on (the valid annual timetable).

2nd Open Data Platform: There is also an upstream system (similar to Kubus) that prepares and merges the data, but it is fully integrated so that all data can be published on in a consolidated form. The platform also brings together data from the different layers of national systems so that output is integrated accordingly.


Could it be that on lines where the data quality is poor, a gtfsrt entity with delay=0 is always delivered instead of no gtfsrt entity at all?

No, that is not the case. Either a ride real time and all delays are 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 could not process the message with the forecast.

I get an illogical or incorrect result from an API.

Actually, such cases are very easy to understand if you have the necessary information. Please use the contact form to send us the following information:
time of request GTFSR
Answer GTFSR
Inquiry timing VDV 431
Inquiry VDV 431
Answer VDV 431
VV 454 OFF Message

Where can I find the formation of the trains?

Unfortunately, the formation is not currently available “open”. The release of this data is currently not planned. If this should change, you as a registered platform user will be the first to know by e-mail. Another way to stay up to date is to subscribe to our Twitterfeed.

You can find the SBB formation here:

When will the route_short_name be changed?

We cannot easily solve the route_short_name theme because of the data modeling (imaginary line numbers get the Y as suffix, so that they are recognizable as such).

But we were wondering if there would be another data field that we could use:

We could also export the names of the means of transport texts that we have recently written in the route_description to the route_long_name (or route_short_name). If there are changes in this respect you will find out in the release notes.

Is mapping between route IDs in GTFS and HRDF possible?

In HRDF, the following trip fields form a unique key:

“Journey number”



This can be found in the “*Z-line” of the file “FPLAN”.

In GTFS (and GTFS-RT) this is the “Trip_ID” in the file “trips.txt”. The routes (in “routes.txt”) and trips are automatically numbered. This means that they are not stable even between GTFS versions.

If the actual timetable is to come from HRDF and your algorithms are designed for it, you still have to import the GTFS static into your database and create a matching.

How best to do this can be found on this cookbook page:

Verwendung von HRDF Fahrplänen zusammen mit GTFS-RT


Why doesn’t the platform deliver the shapes.txt file?

This is about the (changed) route of the replacement trains. Route progressions can be exported to the file shapes.txt (

BUT: We use OpenStreetMap as GIS. We are not allowed to upload this data to Google due to copyright restrictions, therefore the export of the file is deactivated. Since the data is also used by Google, an activation is unfortunately not possible.


How exactly is “Halt auf Dem Demand” published in the actual data?

The topic of stopping on demand is a complex one. Because it is not the same operationally and commercially. Stephan Bundi speaks of the commercial part. This is an attribute that is added to the customer timetable. INFO+ is a commercially oriented product. Operationally there is no’maybe’ stop. Either stop or drive through, you have to be able to plan the routes. As a rule, a stop is taken into account on request as a normal stop. When the train passes through, it can wait at a station or signal. The other way around, he can’t drive any faster. So it’s planned with the stop.

Here the normal case, e.g. 13.2. or at the example 18549:



Here the BLS (please always mention train numbers, not lines): Example 15732 Ziegelbrücke


  • One recognizes the stop on demand by the fact that ZBR has the same arrival as departure in the COMMERCIAL time (first column). It’s the only way to tell the time.
  • In OPERATING planning (second column) the stop is planned as normal as in MEP (Marin). There is no’maybe’.
    You can see from the stop code that the train only stops (and the LF), which is 14 instead of 11 as usual (in the service timetable)
  • If the train has really stopped or passed through, you can see by the DIFFERENCE between the DIFFERENCE (measured time), which is 22 seconds late here and then suddenly 36 seconds early. That means the train went through there. There is no flag for easy query!
  • To make it more complicated: The train did not leave MEP (Marin) about 49 seconds too early. The graphic above shows the PROGNOSE. There is then the whole thing again with the ACTUAL values. There the train in Marin waits for the planned departure.

How is international transport covered?

TFS data is based on HRDF data. The HRDF file contains only public transport in Switzerland. International trains are (usually) terminated at the first commercial stop abroad. In reality, of course, they’re moving on. In some cases, the international journey ends at the last stop in Switzerland (e.g. Geneva) or contains 1-2 stops/operating points abroad.

The public transport Switzerland file also contains the route network of SBB GmbH in Germany. There are historical reasons for this.

What information does GTFS provide?

The three types of additional information are:
Trip Updates
Service Alerts
Vehicle Positions

Trip Updates

Example: “Bus 18 is currently 10 minutes behind schedule”.

Delays, changed routes, replacement vehicles or cancellations for individual lines are published here on an ongoing basis in order to enable passengers to plan as precisely as possible.

Service Alerts

Example: “Station Bern Weissenbühl is currently closed due to an accident”.

In the event of a shift of the stopping edge or generally unforeseen events affecting a stop, a route or the entire network, short messages can be published to keep passengers informed and explain the reason for the change.

Service alerts are not available on the platform.

Vehicle Positions

Example: “This bus is at 18h23 at the stop Bern Bahnhof”.

Information on the location of individual transit vehicles can be published here. In addition, the current load of the vehicle, the vehicle type or other similar information can also be provided.

The vehicle positions are not available on the platform.

How is the Trip ID composed?

The trip ID consists of different DIVA numbers/fields and has nothing to do with the HRDF data. (What is the GTFS ID? Doesn’t tell me anything…)

If the data user had compared the matching HRDF data with the corresponding GTFS data, he might have found the match himself. However, this could not work because the two data records did not match. Took me some time to figure out that he compares apples to oranges. 😉

The assignment is not quite 1:1, since the trip ID (= trip number) does not have to be unique within an HRDF data record, but with the help of stops and stopping times, as the data user has done, the suitable trip can be found as follows:

The trips.txt contains the trip_short_name:


“26-94-j18-1″,”TA+b20xg”,”310.TA.26-94-j18-1.3.R”,”Zürich Oerlikon, Bahnhof”,”13628“,”1”

This corresponds to the trip number (external train number) in the *Z line of the FPLAN file:


As the trip number does not have to be unique within an HRDF feed, you should also use the stop times and stop_ids of the trip from the stop_times.txt for assignment:















 The two days younger HRDF feed (e.g. 05.02.2018) always matches the GTFS feed (e.g. 07.02.2018):


Which means of transport stop at which stops?

Which means of transport stop at these offices would you have to derive from the timetable. The timetable contains all the information you need to find your way around Swiss public transport. The timetable contains all basic information (stops, lines, topology, etc.) on the one hand, and all information relevant to time (calendar, timetables and stop times, etc.) on the other, so that any form of timetable information (for a stop, but also a route search/route/journey planner) can be created using this data. The timetable information provided (HRDF and GTFS) is optimized for customer information.

General information:







How do I get an account so I can request a key for the real-time API?

The open data platform öV Schweiz offers various APIs.

An API key is required to access this API. This token can be obtained through the Developer Portal. To do this, please register on the open data platform öV Schweiz.

The token must be sent in the HTTP header as “Authorization” for each request. Use is subject to certain limits.

The Developer Portal allows:
Creation of API keys
Deleting API keys
Monitor how much of the quota is consumed by the key.

No more real time data is delivered!

Any failures would be logged at

According to which principle are the didok abbreviations assigned?

The abbreviations are assigned according to availability. The current rules are as follows:

  • The abbreviation begins with the same letter as the name
  • Maximum length four characters.
  • Usually no numbers are used.

What are the different limits for the data access for the different interfaces?

Further information can be found here:

The limits refer to the following APIs:

Stop request
Trip Request
Trip Info Request

It is true that the GTFS reeuqests are limited to 2 / min. It is not necessary to send further requests, as the data is not updated more frequently.