Skip to content

FAQ

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 opentransportdata.swiss 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. opentransportdata.swiss also enables you to add real-time information to your journey planner if you integrate one of the two journey forecast APIs.


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.


Even just on opentransport.swiss, 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.


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.


A status 429 is returned.

The service’s answer is then:


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.


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


How many: Currently always as many as you as answer in the GTFSR response get.
The following transport agencies deliver realtime data: https://opentransportdata.swiss/de/dataset/go-realtime


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.


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 (opentransportdata.swiss) 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 https://srfdata.github.io/2017-09-sbb-ga-halbtax/#sbb__bfs_raumgliederungen
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.


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.


You can find an overview here:
https://opentransportdata.swiss/de/dataset/go-realtime
The list contains all transport companies/business organizations for which real-time is available.


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>


Until now, the connection logic was provided by transport.opendata.ch. 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, search.ch now provides its own backend, which, thanks to the new real-time data from opentransportdata.swiss, can also provide up-to-the-minute timetable queries and route calculations.

As a result, transport.opendata.ch 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 transport-beta.opendata.ch, the conversion to the new solution took place on July 31, 2017.

The service is offered by search.ch and Opendata.ch 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: https://viadi-api.ch/


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.

Publication

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 fahrplanentwurf.ch (the annual timetable to check before it is valid) and on fahrplanfelder.ch (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 opentransportdata.swiss in a consolidated form. The platform also brings together data from the different layers of national systems so that output is integrated accordingly.

 


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.


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


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: data.sbb.ch


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.


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

“Journey number”

“Administration”

“Variant”

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

 


This is about the (changed) route of the replacement trains. Route progressions can be exported to the file shapes.txt (https://developers.google.com/transit/gtfs/reference/#shapestxt).

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.

 


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:

 unbenannt

unbenannt

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

unbenannt

  • 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.

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.


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.


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:

route_id,service_id,trip_id,trip_headsign,trip_short_name,direction_id

“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:

unbenannt

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:

 

trip_id,arrival_time,departure_time,stop_id,stop_sequence,pickup_type,drop_off_type

“310.TA.26-94-j18-1.3.R”,”13:37:00″,”13:37:00″,”8587651″,”1″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:38:00″,”13:38:00″,”8587652″,”2″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:39:00″,”13:39:00″,”8591263″,”3″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:41:00″,”13:41:00″,”8591347″,”4″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:42:00″,”13:42:00″,”8591047″,”5″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:43:00″,”13:43:00″,”8591113″,”6″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:44:00″,”13:44:00″,”8591330″,”7″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:45:00″,”13:45:00″,”8591319″,”8″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:46:00″,”13:46:00″,”8591175″,”9″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:46:00″,”13:46:00″,”8591273″,”10″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:48:00″,”13:48:00″,”8591382″,”11″,”0″,”0″

“310.TA.26-94-j18-1.3.R”,”13:49:00″,“13:49:00″,”8580449”,”12″,”0″,”0″

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

unbenannt


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: https://opentransportdata.swiss/de/cookbook/infoplus/

HRDF

Data: https://opentransportdata.swiss/de/dataset/timetable-2018-hrdf

Description: https://opentransportdata.swiss/de/cookbook/hafas-rohdaten-format-hrdf/

GTFS

Data: https://opentransportdata.swiss/de/dataset/timetable-2018-gtfs

Description: https://opentransportdata.swiss/de/cookbook/gtfs/


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.


Any failures would be logged at http://status.opentransportdata.swiss/


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.

Further information can be found here: https://opentransportdata.swiss/de/datenlimit-und-verrechnung/

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.