Skip to content

HAFAS Raw Data Format (HRDF)

The timetable data is supplied on the Open Data Platform in two formats. GTFS and HAFAS Raw Data Format (HRDF).

Functional description

The HRDF file contains all the master data for understanding a timetable and the timetables for public transport in Switzerland.

Key concepts


The HRDF file only includes public transport in Switzerland. International trains are (in most cases) terminated at the first commercial stop abroad. The reality is, of course, is that they continue their journey. In some cases, the international journey terminates at the last stop in Switzerland (e.g. Geneva) or includes another 1-2 stops/operating points abroad.

The file for public transport in Switzerland also includes the network map for SBB GmbH in Germany. There are ultimately historical reasons for this.

Who should use HRDF

HRDF files are relatively complex. Therefore, they should not be used unnecessarily.

Example 1: Extract from BITFELD file:

This file contains bitmaps which are used to determine on which day a form of transport is operating.

Example: Extract from BFKOORD_GEO file:

This file contains the stops’ coordinates. The name of the stop is only contained in a “Comment” field.

Technical aspects

HRDF is a relatively old format. The individual text files are roughly similar to individual tables in a relational database. However, the individual parts can have varying content.

Data structure

The HRDF file is a ZIP file which contains ASCII files. The Latin-1 character set is used. They are not CSV files, but the old-fashioned fixed-length fields, which means that different lines can have different content.

To a certain extent, the HRDF file can be viewed as a database dump. The individual files in the ZIP correspond to individual tables or objects.


It is a good idea to read the complete description carefully about how to use HRDF files. You can find out more in this PDF: hrdf.

From the end of January 2017, an extension will be used to generate the files, which is described here: Komm-HR16_D_Erweiterungen-bei-HRDF.pdf.

There are now a number of special topics discussed below.

Means of transport

In HRDF the means of transport are contained in the “ZUGART” file. The detailed information is contained in the first section. Columns 1-3 feature the short name and columns 5-6 contain the product class (0-13).

The second section contains classes (for grouping types), options (search) and categories (names of types). The whole thing is output in different languages.

Although “<>” tags are used, it is not XML format.

Extracting offers from HRDF

An offer is used to describe a service or customer-related attribute of the means of transport (e.g. minibar). Offers can be valid for the whole of the means of transport’s operation or for parts of it.

The offers are fixed as attributes in HRDF in the files “ATTRIBUT_DE”, “ATTRIBUT_EN”, “ATTRIBUT_FR” and “ATTRIBUT_IT”:

A dining car is given the attribute code “WR”. Attributes can also be used for stops. The “*A” lines in “METABHF” are an example of this.

In specific terms, a dining car in an “*A” line is used in the actual timetable file “FPLAN”:

This applies to the dining car:

  • Is included from Stop “8504371” (Biel/Bienne).
  • Until Stop “8504378”.
  • There is space for a bitmap of the days on which the attribute is valid. If the information is not provided, as in this case, this applies to every day.
  • Departure time (14:00)
  • Arrival time (15:15)
  • The comments are not broken down here (everything after “%”).

Extracting lines from HRDF

A line is a key concept in public transport in Switzerland. You can find out more about it in Journey ID.

Lines are used directly in the file “FPLAN”. Please note that lines are not globally unique. They are unique for each type of administration (=business organisation).

In “FPLAN” the “*L” line is the source for the line number.

The first field indicates the line number:

In this case, we have line “221”.

The “*Z” line (and also the comments) tell us that journey number “000007” and business organisation “801” (PAG, i.e. Postauto) are involved.

Calendar/Bitmap days

Refer to the page on the subject Calendar.

Interchanges in HRDF

Some interchanges are contained in the metastations (see below).

Other relevant aspects are contained in other different files:


  • Stop number
  • Interchange time IC-IC
  • Interchange time for all others
  • (optional) Plain text for stop name


  • The interchange priority for the relevant station is defined in this file.


  • It may be important that at particular stops there has to be a switch between two business organisations. The relevant times are saved in “UMSTEIGV”.


  • Similar to “UMSTEIGV” but for lines.


  • In this case, the interchange time between individual journeys is specified.

Additional information about service points

As mentioned above, they are contained in the “ATTRIB_XX” files.


Initial information about metastations is available here.

In HRDF the structure is as follows (“METABHF”).

First come the transit Connections:

Transit connections:

  • First stop
  • Second stop
  • Duration of transit
  • (optional) “S” as the separator for the seconds marker for walking time
  • (optional) seconds marker for walking time

The “*A” lines stand for an attribute:

  • It corresponds to the attribute codes from the “ATTRIBUT_XX” files (“XX” represents the language).
  • Specifically in the above case, the “Y” stands for “on foot”.

The actual information is then found in the stop group section:

  • Code for the collective term (stop code)
  • “:”
  • List of other stops


A through-service means that two independent journeys are combined to ultimately form a continuous journey. This is the case, for instance, for a train which actually changes train number, but still continue its journey. This also means, in most cases, that passengers can remain in their seats.

Through-services are contained in the “DURCHBI” file.

The structure comprises:

  • First journey: Journey number, administration (which means business organisation), last stop’s code
  • Second journey: Journey number, administration
  • Day of operation field number (see Calendar)
  • (optional) first stop of the 2nd journey
  • (optional) attribute highlighting through-service
  • Comments (mostly the relevant railway station)

In the case of cross-border trains, only the Switzerland part is contained in the HRDF. However, no through-service is indicated in this case, even though there is one.

Extensions for HRDF deliveries from autumn 2017

The following extensions are planned for autumn 2017:

  • Different names for the same train stop in the “station” file
  • Integration of border Points

Different names for the same train stop in the “station” file

It sometimes happens that the name of a train stop is changed. Currently, the name that is valid on the export day is always transmitted. With the new extension the name will be communicated as follows:

  • For the present timetable period, the current name will continue to be transmitted.
  • For the upcoming timetable period, the name will be transmitted that is valid on the timetable period’s first day of validity.

Integration of border points

Border points are communicated in a new way. They may represent national borders or other types of borders. Border points can be represented by either real or virtual train stops. The virtual border points are also transmitted in the GRENZHLT file.

Changes active as of July 2021

Export HRDF 5.40

Scope of export

SLOID (Swiss Location ID) of the tracks / stop edges provided.

The file with the properties of the stops is made available twice. Only one file can be used at a time:


The file with the use of the track information is made available three times. Only one file can be used at a time:

  • The content and scope of the GLEIS file remains unchanged.
    File GLEIS_LV5 now contains the SLOID of the tracks / retaining edges, if available.
  • The coordinates are defined according to the regulations of LV_95
    File GLEIS_WGS now contains the SLOID of the tracks / retaining edges, if available.
  • The coordinates are defined according to the regulations of WGS84


Example scope of an export 5.40.41:

File type BHFART_60.

In this file type, the SLOID of the stops and tracks / stop edges are transmitted. Example:

File type GLEIS_LV95

In this file type, the SLOID and coordinates, if available, are transmitted according to LV95 of the tracks / stop edges.


File type GLEIS_WGS

In this file type, the SLOID and coordinates, if available, according to WGS84 of the tracks / stop edges are transmitted.



More detailed information