Table of contents

Search on the page

NeTEx

Brief Description

The Network Timetable Exchange (NeTEx) is the EU standard for timetable data and was developed by the European Committee for Standardization (CEE). It is based on Transmodel, the European reference data model for public transport.

This Cookbook page highlights and explains the differences and peculiarities of the Swiss implementation of NeTex compared to other EU countries.

Access the Data

Functional Description

The Network Timetable Exchange (NeTEx) creates a unified platform for exchanging traffic data to create timetables for trains, buses, cableways, boats and local providers of other forms of mobility, such as bicycles and e-scooters.

The NeTEx Group (as of 2025) consists of 12 countries that are actively using this format, as well as a further 5 countries that are in the implementation phase. The market continues to grow – even beyond Europe, as the example of the Australian state of Victoria shows.

For Switzerland, the NeTEx data standard is of great importance to enable the efficient exchange of timetable data between international transport companies. This enables end customers to be offered a reliable and seamless timetable from point A to B: For example, if a person looks at the timetable for a train connection from Zurich to Lyon (F), all connections and changes in both countries are included.

In addition to NeTEx, there are also other formats for timetable data, such as HRDF or GTFS.

GTFS (General Transit Feed Specification)

  • Origin: Developed by Google in collaboration with TriMet (Portland, USA), now further developed by MobilityData.
  • Format: A collection of CSV (text) files, bundled in a ZIP archive.
  • Structure: Simple, tabular format with predefined files such as stops.txt, routes.txt, trips.txt, stop_times.txt etc.
  • Focus: Widely used for timetable information, real-time information and open data portals.

Detailed information on GTFS in the GTFS Cookbook.

HRDF (HAFAS Raw Data Format)

  • Origin: Developed by HaCon, a German company (now part of Siemens).
  • Format: Proprietary, binary or text-based format used internally in HaCon’s HAFAS system.
  • Structure: Highly optimised for performance, but difficult to read and not publicly documented.
  • Focus: Mainly used in German-speaking countries (e.g. Deutsche Bahn, SBB) for internal planning and timetable systems.

Detailed information on HRDF in the HRDF Cookbook.

Technical Description

File structure and naming

NeTEx files should be named clearly, consistently and machine-readable. A typical schema could look like this:

[Module]_[Region]_[Version]_[Date]_[Type].xml

  • Timetable_CH_2025_v1.2_20250801.xml – Timetable data for Switzerland, version 1.2, created on 1 August 2025
  • FareFrame_ZH_v3.0_20250715.xml – Fare Data for Zurich, Version 3.0
  • ServiceFrame_BE_v2.1_20250820.xml – Line and service information for Bern

Basics of NeTEx

NeTEx uses a modular XML schema based on Transmodel. It defines abstract data models for different areas of public transport, e.g. stops, lines, timetables, tariffs and operating data. The most important elements of the NeTEx XML are the frames. Each frame contains technical information for forming a means of transport.

Below is a brief description of the frames with the most important classes. More detailed information can be found at the following link: NeTEx – Transmodel (https://transmodel-cen.eu/index.php/netex/).

FrameDefaults

FrameDefaults are a mechanism for defining default values, such as time zone, local time, language selection.

CompositeFrame

A CompositeFrame combines several thematically related data frames (frames) into a single file, e.g. FrameDefaults, ResourceFrame, SiteFrame, ServiceFrame, ServiceCalendarFrame, TimetableFrame. Useful for the structured provision of complex data sets where different aspects of public transport are needed together.

ResourceFrame

ResponsibilityRoleAssignment

Links an organisation (SBB, DB, BLS, etc.) with a specific role in relation to another element (e.g. a line, a timetable, a service).

TypeOfProductCategory

A classifying element that describes the type of product (e.g. train type, bus offer, class of service).

TypeOfNotice

Defines types of notice or offers that are used in passenger information. This is a type definition that is referenced by specific notice elements

SiteFrame

TopographicPlace

Is used for the geographical classification of stops and other locations. In Switzerland, the canton (not the municipality) is usually used as the topographic place to ensure a uniform and clear structure.

StopPlace

Describes different aspects of a physical access point to transport, such as a stop or station; in Switzerland, it refers to a canton or a region.

Quay

Always part of a StopPlace. It is a facility such as a platform, a stopping position or a pier where passengers have access to public transport, taxis, cars or other means of transport. A quay can serve one or more vehicle stopping points and be linked to one or more stopping points.

ServiceFrame

Direction

A direction describes a direction of travel within a line, e.g. ‘Towards station’ or ‘Towards airport’. It helps to distinguish between journeys within a line – e.g. outward and return journeys.

Line

Represents a public transport line, e.g. a bus line, tram line or train connection, i.e. ‘Bus line 10’ or ‘S-Bahn S3’. It groups trips that run under the same line number or designation.

DestinationDisplays

Visual destination display that tells passengers where a vehicle is going. Often linked to a ServiceJourney or VehicleJourney and is particularly relevant for passenger information – e.g. on buses, trains or electronic displays.

ScheduledStopPoint

A central concept. This is the ‘point’ used in the timetable where a service stops. A ScheduledStopPoint can refer either to a quay (e.g. platform, stopping position) or only to a StopPlace (e.g. station, stop). The element does not determine the hierarchy level itself (see PassengerStopAssignment).

PassengerStopAssignment

The main element describing the assignment. It indicates the order in which this stopping point appears within a route or journey pattern. It refers to the logical stopping point in the timetable, the ‘ScheduledStopPointRef,’ which refers to the ‘StopPlaceRef’ of the physical location (e.g. a stop).

Notice

Defines reusable text elements that can be used as notes, such as footnotes in timetables, announcements or other messages. NOTICES are assigned to other elements via a NOTICE ASSIGNMENT. They can be classified with a TYPE OF NOTICE.

The element serves as a container for linking predefined notices or messages – such as passenger information, operational notices or service messages – to specific objects within the timetable data. This includes, but is not limited to:

  • ServiceJourneys (specific journeys)
  • JourneyParts (sections of a journey)
  • TrainBlocks (train rotations)
  • StopPoints (stopping points)
  • OperatingDays (Operating Days)

ServiceCalendarFrame

AvailabilityCondition

A specialisation of the VALIDITY CONDITION to define precise temporal conditions. For example, an entry of a StopPlace may be valid (it exists) but not available at all times (e.g. closed between 21:00 and 06:00). Both VALIDITY CONDITIONs and AVAILABILITY CONDITIONs can be linked to the same object

ServiceCalendar

The transport service offered by a public transport company is designed to meet different demands. To simplify service planning, almost all operators create their production plan based on a classification by day type, which summarises demand patterns or other characteristics – for example working day, weekend, school holidays, market day, etc. Timetables planned for the long term are created via the so-called transport calendar, in which calendar days are classified as specific day types (DAY TYPES).

DayTypes

Timetables are created via the traffic calendar, in which calendar days are classified as specific day types (DAY TYPES).

TimetableFrame

ServiceJourney

A route during which passengers are allowed to board or alight at stops. It describes the traffic performance between a starting point and a destination as communicated to the public.

DestinationDisplayRef
Describes the visual destination display associated with a stopping process (call). It is important for providing passenger information, e.g. on vehicle displays or in electronic timetables.

Notice assignments
Used within the ServiceJourney. In this case, the message is valid for the entire journey. If a message is only valid for part of the ServiceJourney, it is assigned in all relevant call elements.

Call
Represents a view that combines data on the individual stop visit. Ordered collections of call elements can be contained in ServiceJourney instances that are exchanged via NeTEx.

Request Stop
Labelling for required stops (‘request stop’). Often used in rural areas or for on-demand services. It can be labelled accordingly in passenger information systems (e.g. with a symbol or information text). Important for calculating journey times, as required stops may be skipped, thus shortening the journey time.

StopUse
An attribute that specifies the function a stopping point fulfils within a VehicleJourney. It describes whether the stop serves:

  • Boarding (boarding),
  • Exit (alighting),
  • both (both),
  • or none of these functions (pass-through)

is used.

TrainNumber

The TrainNumber currently consists of a maximum of six digits. A ServiceJourney can generally contain several different train numbers, while a JourneyPart only refers to a single TrainNumber. In Switzerland, there is no difference between the published and the productive TrainNumber.

FacilitySet

A structured element used to assign facilities to a ServiceJourney or JourneyPart. SKI classifies these facilities into the following groups:

  • Accommodation facilities
  • Catering facilities
  • Tariff classes
  • Group booking facilities
  • Luggage transport facilities
  • Mobility facilities
  • Facilities for mitigating disturbances
  • Communication equipment for passengers
  • Reservation facilities for services
  • Ticket issuing devices
  • UIC train tariffs

This classification enables a standardised description of the services available along a journey. The list can be expanded if necessary as long as the relevant category is defined in the NeTEx specifications.

JourneyMeeting

Describes the possibility of planning timetables taking into account various interchange options:

  • Change to another service where only the arrival or departure time is known.
  • More general: A service whose schedule is based on the fixed time of an external event that either feeds or is fed by that service.
  • Organisation of a meeting point (hub) between several services within a defined time window; this is a simplified specification of several changes. If necessary, this can be described in detail by several INTERCHANGE RULEs or SERVICE JOURNEY INTERCHANGEs.
  • Determination of a meeting point (time and place) for each journey that can make use of this date.

InterchangeRule 

A set of rules that makes it possible to document planned interchange processes in the timetable without having to specify the exact details of both ServiceJourneys involved. It is used to define and structure potential interchange relationships between journeys, especially if they are not fully specified.

InterchangeRuleParameters
Element within the TimetableFrame for specifying parameters for planned changes between different ServiceJourneys. It defines the conditions and restrictions under which a change is considered valid – for example, with regard to the means of transport (mode), the line or the direction of travel (direction).
These parameters allow for flexible modelling of interchange relationships without having to specify the complete details of the journeys involved. They are particularly useful if interchange processes are to be planned dynamically or based on rules.

InterchangeRuleTiming
Element within the TimetableFrame for defining the time conditions for planned changes between different ServiceJourneys. It defines how much time is required or permitted for a changeover – for example, minimum or maximum waiting times between a feeder journey and a distribution journey at a common stopping point (ScheduledStopPoint).

Characteristics of the Swiss profile

Switzerland uses a national NeTEx profile that is based on the European standard but tailored to the specific requirements of Swiss traffic data.

  • The profile is documented in German and is based on ‘calls,’ i.e. specific data requirements.
  • A French version is planned or can be machine translated to take account of Switzerland’s multilingual nature.
  • It is exported twice a week via the opentransportdata.swiss platform and covers all public transport in Switzerland for the relevant timetable year.
  • Due to the volume of data, the exports are split into several files, e.g. TimetableFrame, ServiceFrame, SiteFrame, etc., for ease of processing

On-demand services

There are specialised concepts for on-demand services (ODV) which are also taken into account in the Swiss profile. An on-demand service is a service where a passenger orders a journey via a booking process – often regardless of fixed stops or timetables. These are ordered group journeys where several passengers with similar transport needs are transported together. Further information on ODV can be found at öv-info: On-demand services (on-demand bus). There is also a specialist concept for on-demand services for Swiss public transport: https://www.oev-info.ch/sites/default/files/2023-04/fachkonzept_on-demand_v2.0.pdf.pdf

An overview of the ODV at opentransportdata.swiss can be found in the Cookbook at NeTEx – On-demand services.

NeTEx import & export processes

Frame Short definition
TimetableFrame Contains the time planning of journeys (vehicle journeys), including stops and times.
ServiceFrame Describes the operational aspects of lines and journeys, e.g. journey patterns and routes.
SiteFrame Defines geographical locations such as stops, stations or access points.
ResourceFrame Contains resources such as vehicles, personnel or operating units.
ServiceCalendarFrame Defines the validity of journeys, e.g. calendar days, periods and exceptions.
CommonFrame Includes shared items such as organizations, codes, plans, or references.
AccessibilityFrame Describes accessible characteristics of stops, vehicles and services.
FareFrame Includes fare information, pricing rules and ticket types.

Example data

An example of NeTex XML data with the above-mentioned frames: https://github.com/user-attachments/files/18201746/swiss_mikro.zip

Typical components in the file name:

Component Description
Module e.g. Timetable, FareFrame, ServiceFrame
Region e.g. CH, ZH, BE (ISO or internal abbreviation)
Version e.g. v1.0, v2.3
Date Format: YYYYMMDD
Type Optional: e.g. Full, Delta, Test, Export

Validation & troubleshooting of NeTex data

NeTEx data contains many lines of XML and can also appear confusing and there are various free tools available for this purpose. The most popular ones are:

Validation applications:

  • The Netex Validator (https://github.com/entur/netex-validator-java) from Entur is a Java-based validation library specifically developed for checking NeTEx datasets – especially in the context of the Nordic NeTEx profile used in Norway and other Scandinavian countries.
  • XMLSpy is a paid XML editor and development tool from Altova that can be used to validate NeTEx data. Validation is carried out using the associated XML Schema (XSD) files that define the structure and rules of the NeTEx data.

Recommendations for tools and workflows

Conversion & Processing

Tool Purpose Source
MMTIS/Badger Converts GTFS → NeTEx EPIPNeTEx EPIP → GTFS GitHub – MMTIS/badger: Timetable conversions
GTFS2NeTEx Converter Converts GTFS → NeTEx Interoperable Europe Portal
Damu Converts NeTEx → GTFS GitHub – entur/damu
geOps GTFS Feed Daily GTFS conversion from HRDF geOps GTFS Feed

FAQs

Why are there so many different formats for transport data?

Different needs and use cases:

  • GTFS (General Transit Feed Specification): Simple, widely used, ideal for timetable apps and routing.
  • NeTEx (Network Timetable Exchange): More complex, detailed, for in-depth network modelling and European interoperability.
  • HRDF (Hafas Raw Data Format): Proprietary, very detailed, mainly used in Switzerland and Germany.
  • Transmodel: A conceptual model on which NeTEx is based – for planning, operation and analysis.

Each format has been developed for specific purposes – e.g. GTFS for Google Maps, NeTEx for EU-wide data integration, HRDF for internal systems. The technological development of transport data also plays a very important role. Older formats, such as HRDF, are text-based and difficult to validate. Newer formats, such as NeTEx, are based on XML and allow structured, machine-readable data that can be more easily processed by automated means.

Are the data structures self-explanatory?

NeTEx is based on a very detailed data model (Transmodel), which leads to a steep learning curve. The structure is modular and deeply nested, making processing difficult without specialised tools.

#AutoTranslate