Skip to content

Using HRDF timetables together with GTFS-RT

When using GTFS-RT, it is assumed that a static GTFS file is being used as the basis.

The Open Data Platform provides one.

But many operators prefer the (more powerful) HRDF format.

In HRDF the following journey fields form a unique key:

  • “Journey number”
  • “Management”
  • “Option”

This is found in the “*Z line of the file “FPLAN”.

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

If the actual timetable is to originate from HRDF and its algorithms are configured for this, they must still import the GTFS Static into the database and produce a matching.

The following procedure is recommended:

Import the current GTFS Static into your database

Import the current GTFS Static into a database (e.g. using https://github.com/cbick/gtfs_SQL_importer). A simple SQL script is an example.

You must understand the structure of GTFS: https://developers.google.com/transit/gtfs/reference/

Import the necessary files from HRDF to a database

You must import data from different files from HRDF. The structure is described here: https://opentransportdata.swiss/wp-content/uploads/2016/10/hrdf.pdf

From “FPLAN”:

The traffic periods must also be integrated (“BITFELD” file). You need this to determine the days of operation.

Data is required from the “INFOTEXT” file to identify the correct train numbers in the event of failures. If the train number changes (in the case of failures), the original train number is saved in the “Infotext” field in “INFOTEXT”. This means that the value “Z0” in HRDF must still be correctly referenced.

Through-services must also be imported. Through-services are two journeys which are made by the same train. Through-services are contained in the “DURCHBI” file.

In GTFS the through-services are already joined together to form the trip. Therefore, Trip A and Trip B, which are linked in HRDF via DURCHBI, are already in GTFS as A->B. The following elements should feature in the record as a minimum:

  • Journey number
  • Management
  • Option
  • Start location
  • Destination location
  • Start time
  • Destination time
  • Line
  • Direction
  • Operation period
  • Z0
  • ZN

Matching data

You can now match the records via:

  • Start location
  • Start time
  • Destination location
  • Destination time
  • Direction
  • Day of operation

Matching can also be carried out using the travel distance, in which case the day of operation can be discarded. Matching via the travel distance matches the exact route.

Please note:

  • There are more trips in GTFS than journeys in HRDF.
  • Cross-border trains are truncated at the border station on the Open Data Platform. If you have obtained the timetables from another source, this may be different.
  • You can determine the start/destination location also from the travel distance from “FPLAN”.Matching can be carried out statically or dynamically, depending on what your application requires. In any case, you must include the relevant day as this is the only way to ensure that they can identify the relevant trip and the relevant HRDF-FPLAN-Entry uniquely. Example:
  • You can do this using, for instance, a getTripfromHRDF function (Journey ID, Management, Version, Day of operation).
  • You can create a getHRDFfromTrip(trip_id, day of operation) function.
  • You create for each day of operation a view/table of the trips and their mapping to HRDF (NB: In the worst-case scenario, 130,000 journeys x 400 days)