Skip to content

timetables GTFS

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: https://opentransportdata.swiss/de/dataset/go-realtime

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.

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.

Is mapping between route IDs in GTFS and HRDF possible?

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

 

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…)

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