Skip to content
LoginRegister
DEENFRIT
Home
Open data platform mobility Switzerland
  2. Cookbook
  3. HAFAS Raw Data Format (HRDF)

HAFAS Raw Data Format (HRDF)

August 2024 version. You can find information on continuous adjustments in our Changelog.

Current information on releases

Realisation specifications RV 2.0.6 and 2.0.7

Activation of the adjustments in accordance with the new realisation specifications RV 2.0.6 and 2.0.7 is planned for 29 October 2024. [Update 2024-10-25: Activation has been postponed to a date yet to be determined.] Both specifications are implemented simultaneously. Test data is available on Test data sets HRDF realisation specifications 2.0.6 and 2.0.7 .

The following files are affected by the new HRDF version:

File FPLAN

*GR lines are no longer supported
*SH lines are no longer supported
*VV lines are now supported. They include

  • Estimated delay in minutes
  • Stop from which the delay applies
  • Stop to which the delay applies
  • Departure time
  • Time of arrival

Example

 

File ATTRIBUT

The description now starts in column 5 (instead of 4).

Example (new): 

Old:

Files ATTRIBUT_DE / ATTRIBUT_EN / ATTRIBUT_FR / ATTRIBUT_IT

The files ATTRIBUT_DE, ATTRIBUT_EN, ATTRIBUT_FR, ATTRIBUT_IT are no longer provided. However, the different language variants are all contained in the ATTRIBUT file.

 

File BETRIEB 

  • First line: Unique identifier (SBOID) (after the “N”) is provided.
  • Second line: From version 2.0.7, there can only be one TU code per SBOID.

Example (new with SBOID):

Old (currently without SBOID):

 

File BHFART

  • From version 2.0.7, only the BHFART file will be made available.
  • If known, the global IDs (for Switzerland the Swiss Location ID (SLOID)) of the stop and track are provided.
    • with an “A” as a prefix, the global IDs of the stops are made available
    • With an “a” as a prefix, the global IDs of the tracks are made available
  • A stop can have several quays (i.e. places for boarding and alighting at the stop in question, for example). The same quay can be assigned to several stops.
  • The “Country” information is provided for each stop with the identifier L
  • The “Canton” information is provided for each stop. The information is transmitted with an *I line and the infotextcode “KT”

The SLOIDs are already productively exchanged in the BHFART_60 file.

 

File GLEISE 

The files GLEISE_WGS and GLEISE_LV95 will now be available. The other GLEIS_xx files will no longer be available.

 

File KMINFO

The “Comment” column begins with the special character % from position 21.

Example (new):

Old:

 

File ZUGART

  • The mode of transport is now also supplied for each offer category. The information is transmitted with an *I line and the infotextcode “VM”.
  • The attribute “Ausgabesteuerung” now has two digits. The attributes that occur after this are shifted by one position.

Example (new):

Old:

 

Background

What is HRDF?

The Hafas Raw Data Format (HRDF) is a proprietary file format for timetable data.

Who is behind it?

The company Hacon has developed the Hacon Fahrplan-Auskunfts-System (HAFAS), which uses HRDF for data exchange.

Why does the Open Data platform offer this?

The HAFAS system (see above) is widely used in public transport, which has made HRDF one of the standards in the industry. It also covers many aspects of customer information that are not (currently) available in other formats.

You can find more information on the assessment of HRDF as a standard in the report (German) by the Federal Office of Transport (FOT).

How do I access the data/interfaces?

Data

The timetable in HRDF format (e.g. for 2024): https://opentransportdata.swiss/en/dataset/timetable-54-2024-hrdf

For the car transport (e.g. for 2024): https://opentransportdata.swiss/en/dataset/timetable-54-2024-hrdf-autoverlad

The current draft timetable: https://opentransportdata.swiss/en/dataset/timetable-54-draft-hrdf

Interfaces

HRDF is not an interface standard.

Technical description

What information do we map with HRDF? (size)

  • Swiss public transport timetable data and journeys in the area close to the Swiss border.
    • Note: For cross-border trains, the Swiss part of the journey is included up to the first commercial stop abroad (in the direction of abroad) or the last commercial stop abroad (in the direction of Switzerland).
  • All information for an entire timetable period (e.g. 2024).

How is the information structured? (model)

An HRDF export consists of several files, which almost all have to be viewed together for an overall picture. For details, please refer to the realisation specification (RV v2.0.5 (July 2023, German) or RV v2.0.7 (May 2024)) and the official HRDF documentation (available on request: contact form).

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.

Please note:

  • NOMEN EST OMEN does NOT (always) apply to HRDF files. For example, the “BAHNHOF” file contains not only railway stations, but all stops (including bus stops, for example).
  • The format of the HRDF files is designed for a compact, machine-readable structure. Therefore:
    • are frequently related but not identical contents in the same file
    • contents are indicated with an “*” followed by a letter, e.g. “*Z” (so the interpreting system knows what comes next)
    • the structure of each line following an “*” is strictly regulated in the HRDF documentation. Each part of a line has a predetermined width (number of characters), the parts are separated by spaces. Example:
      • It can be defined that the first part of a line contains the ID of a stop and may only be 5 characters long and the next part (from character 6 to character 10) identifies the company owning the stop.
      • So the line could look like this: 12345_67891, where _ visualises the space. If there is no company and the field is optional, then characters 6-10 would only be spaces.
    • HRDF thus differs from other common file formats such as CSV, where content is separated with a comma, or JSON, where content is represented in a structured way (with various characters): content in HRDF is limited in its scope and position on each line.
  • There are files that are part of the HRDF export we provide that are empty. These are only included in the sense of interoperability of decreasing systems. We deliberately do NOT list them in the following description.

Overall, the HRDF data can be divided into (1) master data, (2) time-relevant data, (3) timetable data and (4) transfer data. We will go into the content in more detail below.

Technical description (What is in the HRDF files? (contents))

This section roughly describes each individual file of the HRDF model including examples from the HRDF export (detailed information can be found in the RV and HRDF documentation). In addition, we do not describe the files alphabetically, but starting from node files. For example, we first introduce FPLAN as one of the central files and then describe the files referenced by this file, etc. Thus we divide the description into:

  • Timetable file (FPLAN) and its references and general information
    • You need to find out:
      • when will
      • travelled from where to where
      • on which days of the year
      • By which means of transport
      • with which line
      • with which additional services and restrictions
      • with which further details (SJYID, etc.)
    • As well as for time-relevant information:
      • Validity
      • Public holidays
      • Time zones
  • Stops file (BAHNHOF) and its references
    • Needed for the following information on stops:
      • Name
      • Grouping of several stops
      • Coordinates of the stops
      • ID of the stops
      • Transfer information within and between stops

Timetable file (FPLAN) and its references and general information

Extract from the model overview. An arrow means that a key is “pointed to” in the referenced file:

Area Specialised content  File name Description
Time-relevant data Validity of the delivery ECKDATEN

Life of the timetable

The timetable data is valid for the defined period. The duration usually corresponds to that of the timetable period

Can be read in decoupled from other data.
Time-relevant data General public holidays FEIERTAG

List of public holidays that apply in Switzerland.

In addition to the date of the holiday, the description of the holiday is listed in four languages: DE, FR, IT, EN

Can be read in decoupled from other data.
Time-relevant data Time zones ZEITVS

Definition of the time zones, including the date when the summer and winter time changes take place

Further details on this topic and its implementation in Switzerland can be found in the RV

There are 2 types of representation:

  • Type 1:
    • Railway station number
    • (general) time difference compared to GMT
    • Time difference that applies to the following period
    • FromDate (the time difference applies from this day)
    • Time (from this time)
    • UntilDate (the time difference applies until this date)
    • Time (at this time)
    • Comment (further time periods are also available in the Swiss export, before the comment)
  • Example (excerpt):

  • Typ 2:
    • Railway station number
    • Railway station number
  • Example (excerpt):
Time-relevant data Validity in the year BITFELD

Day-specific definition of the validity of the timetable information. The validity is defined using a bit pattern. Each day is represented by a bit. In each case, 4 bits are combined to form a hexadecimal digit.

To interpret the bit field, it is important to understand how the timetable years work (more information here). A timetable year usually lasts one year, but the timetable year begins on the 2nd weekend in December. This means that a timetable year is not always the same length. To deal with this, the bit field is assumed to be 400 days long.

File contains:

  • Bit field code
  • Bit field definition

Example (excerpt) – Hex insetead of bits:
Timetable data Timetable FPLAN

 List of journeys and by far the largest and most comprehensive file in the HRDF export.

This file contains:

  • *Z lines: as header information for the run. Further details on this topic and its implementation in Switzerland can be found in the RV. It includes:
    • The journey number (primary key with the TU code)
    • Transport company (TU) code (see File BETRIEB_*)
      • For the TU code = 801, the region information must also be taken into account. This information is contained in line *I with the INFOTEXTCODE RN.
    • Option
      • NOT PART OF HRDF. 3-digit means of transport variant code without technical meaning
    • (optional) Number of cycles
    • (optional) Cycle time in minutes
  • Example (excerpt):
  • *G-lines: Reference to the offer category (s. ZUGART file). It includes:
    • Reference to the offer category
      • The term “Angebotskategorie” (offer category) may have a different meaning here than in colloquial language! A colloquial term (also according to the HRDF doc.) would be “transport mode type”.
    • Stop from which the offer category applies
    • Stop up to which the offer category applies
  • Example (excerpt):

  • *A VE lines: Reference to the validity information (see file BITFELD). Further details on this topic and its implementation in Switzerland can be found in the RV. It includes:
    • Stop from which the offer category applies
    • Stop up to which the offer category applies
    • Reference to the validity information. In Switzerland: 000000 = always.
  • Example (excerpt):

  • *A *-lines: Reference to offers (s. file ATTRIBUT). It includes:
    • The offer code
      • The term “Angebot” (offer) may be imprecise here. The HRDF doc. uses the word “Attribut” (attribute), which is also somewhat imprecise. Basically, it is a collective term for extensions (e.g. dining car) or restrictions (e.g. no bicycles) that apply.
    • Stop from which the offer category applies
    • Stop up to which the offer category applies
    • Reference to the validity information
  • Example (excerpt):

  • *I-lines: Reference to notes (s. INFOTEXT file). Further details on this topic and its implementation in Switzerland can be found in the RV. It includes:
    • Informational text code. In Switzerland: XI not supported. Permitted codes see list (DE / FR).
    • Stop from which the info text applies
    • Stop up to which the info text applies
    • Reference to the validity information. In Switzerland: If not available = always.
    • Reference to the info text
    • Departure time
    • Time of arrival
    • Comments:
      • The Swiss Journey ID (SJYID) is identified via the *I line with the code JY
  • Example (excerpt):

  • *L lines: Line information or reference to the line information (see file LINIE). It includes:
    • Line information, reference to external file if necessary.
    • Stop from which the line is valid
    • Stop to which the line is valid
    • Departure time
    • Time of arrival
  • Example (excerpt):

  • *R lines: Reference to the direction text (see file RICHTUNG / DIRECTION). It includes:
    • Direction (H=forward,R=backward)
    • Reference to direction code
    • Stop from which the direction applies
    • Stop to which the direction applies
    • Departure time
    • Time of arrival
    • Comments:
      • R without information = no direction
  • Example (excerpt):

  • *GR lines: supported but not available in Switzerland.
  • *SH lines: supported but not available in Switzerland.
  • *CI/CO lines: It includes:
    • Number of minutes at check-in(CI)/out(CO)
    • Stop from which the direction applies
    • Stop to which the direction applies
    • Departure time
    • Time of arrival
  • Example (excerpt):

  • Once all the lines described have been defined, the run is described with the journey times:
    • Stop (s. BAHNHOF and others)
    • Arrival time: Negative = No possibility to get out
    • Departure time: Negative = No boarding option
    • Journey number
    • Administration
  • Example (excerpt):
Timetable data Through-connections DURCHBI

List of ride pairs that form a contiguous run. Travellers can remain seated.

This construct is used, among other things, for the formation of the wing trains. File contains:

  • Journey no. 1
  • TU code 1
  • Last stop 1
  • Journey no. 2
  • TU code 2
  • Traffic days (see BITFELD file)
  • First stop 2

Example (excerpt):
Master data Service categories (aka means of transport (type)) ZUGART List of service categories. Per language the (Class:) grouping of offer categories with identical characteristics. (Option:) Search criteria for the application for connection search. (Categorie:) Designation of the offer category.

Note again: The term “Angebotskategorie* (offer category) may have a different meaning here than in colloquial language! A colloquial term (also according to the HRDF doc.) would be “means of transport” (type).

This file is modified in Switzerland:

  • Offer category definition (or generic definition):
    • Offer category code/class code
    • Category Product class
    • Tariff group (always A)
    • Output control (always 0)
    • Generic name
    • Surcharge (always 0)
    • Flag (N: local transport, B: ship)
    • Reference to category, see below.
  • Example (excerpt):

  • Introduction Text definition with <text>
  • Specify language with e.g. <German>
  • Product classes:
    • Product class Number between 0-13
    • Product text
  • Example (excerpt):

  • Options:
    • Option definition Number between 10-14 (Further details on this topic and the implementation in Switzerland can be found in the RV)
  • Example (excerpt):

  • Categories:
    • Generic long name number Number between 0-999 (see above)
  • Example (excerpt):
Master data Offers ATTRIBUT

List of abbreviations describing additional offers (e.g.: dining car) or restrictions (e.g.: seat reservation obligatory).

Note again: The term “Angebot” (offer) may be imprecise here. The HRDF doc. uses the word “attribute”, which is also somewhat imprecise. Basically, it is a collective term for extensions (e.g. dining car) or restrictions (e.g. no bicycles) that apply. An overview of the means of transport (and instructions) can be found in the following link: Lists of means of transport and instructions

This file contains: 

  • The list of offers

Example (excerpt):

  • Description of how the offers can be displayed. This information is actively maintained in the timetable collection

Example (excerpt):

  • Description in the following languages : German, English, French, Italian

Example (excerpts):
Master data Info texts INFOTEXT_*

*DE,*FR,*IT,*EN

Additional information on objects (journeys, lines, etc.). This information can either be

  • be simple texts, e.g.:   000018154 Rollstühle können mit Unterstützung des Fahrpersonals befördert werden.  OR
  • Values with semantic meaning. This means values that cannot be represented in any other way and have therefore been “outsourced” to INFOTEXT, e.g.  000000000 ch:1:sjyid:100001:3-002

The INFOTEXTCODE attribute defines whether these are simple texts or texts with a semantic meaning. The INFOTEXTCODE is not in the INFOTEXT file, but only in the INFOTEXT referencing files, e.g. FPLAN.

A list of the INFOTEXTCODE used can be found under the following LINK..
Master data Lines LINIE

List of lines. The file contains:

  • Line ID (not unique line by line!)
  • Line property code
  • Characteristic

The following property codes are supported:

  • Line type K : Line key
  • Line type W : internal line designation
  • Line type N T : Line abbreviation
  • Line type L T : Line name
  • Line type R T : Line region name (reserved for FOT ID)
  • Line type D T : Line description
  • Line type F : Line colour
  • Line type B : Line background colour
  • Line type H : Main line
  • Line type I : Line info texts

Example (excerpt):
Master data Direction RICHTUNG

Directional information. More details:

  • Direction ID (see FPLAN)
  • RichtungsText

For example, if a train travels between Sargans and Chur, it is labelled as travelling in the direction of Chur.

Example (excerpt):
Master data Transport company BETRIEB_**DE,*FR,*IT,*EN List of transport companies. The term “transport company” is understood in different ways. In the context of opentransportdata.swiss, it is understood that it is an organisation that is responsible for the runs described in the FPLAN. A detailed description of the transport companies and business organisations can be found here.

Each TU is described in detail with 2 lines:

  • The first line:
    • Operator no. (for BETRIEB / OPERATION file)
    • Short name (after the “K”)
    • Long name (after the “L”)
    • Full name (after the”V”)
  • The second line:
    • Operator no. (for BETRIEB / OPERATION file)
    • “:”
    • TU code (or administration number)
      • Several TU codes can be listed. These share the information in the first line.

Example (excerpt):

Stops file (BAHNHOF) and its references

Extract from the model overview. An arrow means that a key is “pointed to” in the referenced file. For a better overview, BAHNHOF / STATION and BETRIEB / OPERATION are represented by placeholders.

Not repeated: ZUGART, LINIE, BETRIEB_*, FPLAN:

Bereich Fachlicher Inhalt Dateiname Beschreibung
Master data Stops BAHNHOF

List of stops A detailed description of the stops (incl. Meta-stops (see METABHF file)) can be found here.

The file contains stops that are referenced in various files:

  • Stop number, from DiDok (in future atlas), with a 7-digit number >= 1000000
    • The first two numbers are the UIC country code
  • Stop name with up to 4 types of designations:
    • Up to “$<1>”: official designation from DiDok/atlas
    • Up to “$<2>”: long designation from DiDok/atlas
    • Up to “$<3>”: Abbreviation from DiDok/atlas
    • Up to “$<4>”: alternative designations from the timetable collection

Example (excerpt):

  • Auxiliary stops have an ID < 1000000.
    • They serve as a meta operating point and as an alternative to the name of the DiDok/atlas system. They allow you to search for services with these names in an online timetable without knowing the exact name of the stop according to DiDok/atlas.

Example – Search for Basel instead of “Basel SBB” (excerpt):
Master data Meta stops METABHF

Grouping of stops for the search. By grouping the stops, the search for transport chains takes place at all stops in the group.

There are 2 parts. file contains:

  • Part One – Transitional Relationships:
    • *A-line: Transition
      • followed by the attribute code
    • Meta stop ID
    • Stop ID
      Transition time in minutes
  • Part two – stop groups:
    • Number of the collective term
    • “:”
    • Numbers of the summarised stops

Example (excerpt):

  • The stop 8500010 = “Basel SBB” includes the actual stops (see BAHNHOF file)
    • 8500146 = “Basel, railway station entrance Gundeldingen$<1>$Basel, railway station entrance Gundeldingen$<2>”
    • 8578143 = “Basel, Bahnhof SBB$<1>”
Master data Stop coordinates BFKOORD_*

*WGS84, *LV95

 List of stops with their geo-coordinates. File contains:

  • Stop number
  • Longitude
  • Latitude
  • Height

Example (excerpt):
Master data Station type BHFART*

*, *_60

 Definition of the type of stops, i.e. whether the stop should be able to serve as a start and/or destination, or as a via location, and whether it has a global ID (for Switzerland the Swiss Location ID (SLOID)).

The BHFART_60 variant of the BHFART file also contains the risers (with an “a” as a prefix) of the stations (with an “A” as a prefix). So if the example below says “A”, it describes a stop and not a platform belonging to this stop. A stop can have several platforms (i.e., for example, places to board and alight at the stop in question). File contains:

  • Restrictions:
    • These stops are not to be offered as start, destination or via entries
    • B = Selection and routing restrictions
      • Selection restriction (usually “3” – start/finish restricted)
      • Routing restriction (usually empty “”)
  • and the Global ID of the stop and track:
    • G = Global ID (in Switzerland: SLOID)
      • Type designator (“a”/”A”, “A” only for *_60)
      • SLOID

The format is included:

  • Stop number
  • Code (e.g.: see above) M*W
  • Code details (e.g.: see above, a, A)
  • Value (e.g.: see above) 3, “”, SLOID)

Example (excerpt):

Caveat: There are currently no different sloids for sectors and sector groups. However, these can have their own coordinates. Depending on the application, the sloid (if it is used as an id) should be supplemented with “: “+”designation” (e.g. ch:1:sloid:7000:501:34:AB) in the internal system. However, this is NOT a new official ID.
Master data Transfer priority BFPRIOS Definition of the priority of the stops The transfer priority allows you to select the transfer point if there are several transfer options. It is shown with a value between 0 and 16, where 0 is the highest priority and 16 is the lowest priority. File contains:

  • HS no.
  • Priority
  • HS name

Example (excerpt):

  • If it is possible to change trains in Pregassona, Basel SBB or Basel St. Johann with otherwise equivalent train connections, Basel SBB is preferred.
Master data Weighting of transfer points KMINFO This file is primarily relevant for HAFAS. HAFAS recognises transfer points automatically. This file should therefore only be used to assign numbers of 2 30000 and 0 (see below). In Switzerland, however, it contains more figures. Specifically, various numbers between 0 and 30000. The same figures indicate a similarly manageable changeover. The file differs from BFPRIOS in that it defines closures and transfers in general, i.e. a location can or cannot be used for transfers. The further division is a configuration of the changeover logic used in addition to BFPRIOS. File contains:

  • HS no.
  • Transfer station
    • 30000 = transfer point
    • 0 = Blocking
    • All other numbers are also used to represent transfer points (see above).
  • HS name

Example (excerpt):
Timetable data Track and bus platform information GLEISE_*

*WGS, *LV95

List of track and bus platform information.

File contains:

  • The first part defines validities, TUs and journeys, which are associated with the track infrastructure in the second part:
    • HS no.
    • Journey number
    • Transport company code
    • Track link ID “#…”
    • Service running times;
    • Days of operation

Example (excerpt):

  • The second part describes the infrastructure (tracks or bus platforms) of the stop:
    • HS no.
    • Track link ID “#…” linked with part 1 in combination with HS no.
    • G = track, A = section, T = separator

Description

This creates the overall picture by linking the two pieces of information.

IMPORTANT NOTE on *WGS and *LV95, as well as “GLEIS” vs “GLEISE”: These two files will replace the “pure” GLEIS and GLEIS_* files in Switzerland in 2024. So GLEISE_WGS and GLEISE_LV95 remain. Accordingly, we have also documented these directly here.

With the replacement, only the second part changes as follows (further details on this topic and the implementation in Switzerland can be found in the RV):

  • HS no.
  • Track link ID “#…” linked with part 1 in combination with HS no.
  • Changed: Track = G, A = Section, g A = Swiss Location ID (SLOID), k = Coordinates (longitude, latitude, altitude)
    • Important: contrary to the standard, track and section data are in different lines and not in one!
  • Description
    • ‘ ‘ means no explicit designation at the location

Example (excerpt):
Transfer data Transfer time between journeys UMSTEIGZ List of journey pairs that have a special transfer relationship. File contains:

  • HS no. (see BAHNHOF / STATION)
  • Journey no. 1 (see FPLAN)
  • TU code 1 (see BETRIEB / OPERATION_*)
  • Journey no. 2
  • TU code 2
  • Transfer time in min.
  • Traffic day bitfield (see BITFELD file)
  • HS name

Example (excerpt):
Transfer data Transfer time at a stop UMSTEIGB General transfer time or per stop. The file contains:

  • a general default value for all stops if no other, more specific value is defined

Example (excerpt):

  • one transfer time per stop:
    • Transfer time in minutes between service category (means of transport type) IC-IC
    • Transfer time for all other offer categories
    • HaltestellenName

Example (excerpt):
Master data Transfer time between lines UMSTEIGL Transfer time per category of service and/or line. The file contains:

  • Stop number
  • Administration 1 (see BETRIEB / OPERATION file)
  • Type (offer category) 1
  • Line 1 (* = quasi-interchange times)
  • Direction 1 (* = all directions)
  • Administration, type, line, direction 2
  • Transfer time in min.
  • “!” for guaranteed changeover
  • HaltestellenName

Example (excerpt):
Master data Transfer time between transport companies UMSTEIGV Transfer time between two transport companies:

  • Stop number or @
  • Administrative designation 1
  • Administrative designation 2
  • Minimum transfer time between administrations
  • Stop designations

Example (excerpt):