Table of contents

Search on the page

NeTEx

Brief Description

Network Timetable Exchange (NeTEx) is the EU standard for timetable data and was developed by the European Committee for Standardization (CEN). 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

Network Timetable Exchange (NeTEx) creates a standardised platform for the exchange of traffic data for scheduling of 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 – including beyond Europe, as the example of the Australian state of Victoria shows.

For Switzerland, the NeTEx data standard is of great importance for enabling the efficient exchange of timetable data between international transport companies. This allows end customers to be offered a reliable and seamless timetable from points 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), since 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 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 harder to read and not publicly documented.
  • Focus: Used mainly in German-speaking countries (e.g. Deutsche Bahn, SBB) for internal planning and timetable systems.

Detailed information on HRDF in HRDF cookbook.

Technical Description

File structure and naming

NeTEx files should be named clear, consistent and machine-readable. A typical scheme 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 1 August 2025
  • FareFrame_ZH_v3.0_20250715.xml – Tariff data for Zurich, version 3.0
  • ServiceFrame_BE_v2.1_20250820.xml – Line and service information for Bern

NeTEx basics

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

Below is a brief description of the frames with the most important classes. More detailed information can be found via 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, such as FrameDefaults, ResourceFrame, SiteFrame, ServiceFrame, ServiceCalendarFrame, TimetableFrame, into a single file. Useful for the structured delivery of complex data sets where different aspects of public transport are required together.

Resource frame

ResponsibilityRoleAssignment

Links an organisation (SBB, DB, BLS, etc.) to a certain 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 the types of notice or offers to be used in passenger information. It is a type definition referenced by specific notice elements

SiteFrame

TopographicPlace

Used to classify stops and other locations geographically. In Switzerland, the canton (not the municipality) is usually used as TopographicPlace to ensure a uniform and clear structure.

StopPlace

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

Platform

Always belongs to a StopPlace. A device such as a platform, stopping point or footbridge where passengers have access to public transport, taxis, cars or other means of transport. A quay can serve one or more vehicle stops and be linked to one or more stops.

ServiceFrame

Direction

A direction describes a direction of travel within a line, e.g. ‘Towards the station’ or ‘Towards the airport’. It helps to distinguish 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 journeys that run under the same line number or designation.

DestinationDisplays

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

ScheduledStopPoint

A central concept. It is the ‘point’ used in the timetable where a service stops. A ScheduledStopPoint can refer either to a quay (e.g. platform, stop position) or to a StopPlace only (e.g. station, stop). The hierarchical level is not self-determined by the element (see PassengerStopAssignment).

PassengerStopAssignment

The main element describing the assignment. It specifies 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 physical location (e.g. a stop) to the ‘StopPlaceRef’.

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 to link predefined notices or messages – such as passenger information, operational notices or service messages – to specific objects within the timetable data. These include, but are not limited to:

  • ServiceJourneys (specific trips)
  • JourneyParts (sub-sections of a journey)
  • TrainBlocks (train rotations)
  • StopPoints (stopping points)
  • OperatingDays (operating days)

ServiceCalendarFrame

AvailabilityCondition

A specialisation of the VALIDITY CONDITION to define precise time conditions. For example, an input 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 services of a public transport company are designed to meet different demands. To simplify service planning, almost all operators create their production plan based on a classification by day types that summarise demand behaviour or other characteristics – for example, working days, weekends, school holidays, market days, etc. Long-term timetables are created using a transport calendar, in which calendar days are classified as specific day types (DAY TYPES).

DayTypes

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

TimetableFrame

Service Journey

A journey of a vehicle during which passengers are allowed to board or alight at stops. It describes the traffic service between a start point and a destination as it is publicly communicated.

Destination displayRef
Describes the visual destination display linked to a stop procedure (call). It is important for passenger information, e.g. on vehicle displays or in electronic timetables.

Notice assignments
Is used within the ServiceJourney. In this case, the message applies to the entire journey. If a message is only valid for part of the ServiceJourney, it is mapped to all call elements involved.

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

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

Stop use
An attribute that indicates the function of a stopping point within a VehicleJourney. It describes whether the stop for:

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

is used.

Train number

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

Facility set

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

  • Accommodation facilities
  • Catering facilities
  • Fare classes
  • Group booking facilities
  • Luggage transport facilities
  • Mobility facilities
  • Disturbance mitigation facilities
  • Passenger communication equipment
  • Reservation facilities for services
  • Ticket issuing facilities
  • UIC train fares

This classification enables a standardised description of the services available throughout a journey. The list can be expanded if necessary, provided the category in question is defined in the NeTEx specifications.

JourneyMeeting

Describes the option of planning timetables which take into account various transfer options:

  • Transfer to a different service for which only the arrival or departure time is known.
  • More general: A service whose schedule is based on the specified 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 represents a simplified specification of several changes. If necessary, this can be described in detail by several INTERCHANGE RULES or SERVICE JOURNEY INTERCHANGEs.
  • Determine a meeting point (time and place) for each trip that can attend this appointment.

InterchangeRule 

Regulation that makes it possible to document planned changes in the timetable without having to provide the exact details of both service journeys involved. It serves to define and structure potential change relationships between journeys, especially if these are not fully specified.

InterchangeRuleParameters
Element within the TimetableFrame for the specification of parameters for planned transfer operations between different service journeys. It defines the conditions and restrictions under which a transfer is considered valid – for example, in terms of the mode of transport, line or direction.
These parameters enable transfer relationships to be modelled flexibly without having to specify full details of the journeys involved. They are particularly useful if transfer procedures have to be planned dynamically or rule-based.

Interchange rule timing
Element within the TimetableFrame to define the time conditions for planned transfer operations between different service journeys. It defines the time required or allowed for a transfer – for example, minimum or maximum waiting times between a feeder journey and a distribution journey at a shared stopping point (ScheduledStopPoint).

Characteristics of the Swiss profile

Switzerland uses a national NeTEx profile which 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 so-called ‘calls,’ i.e. specific data requirements.
  • A French version is planned or can be machine-translated to take account of Switzerland’s multilingualism.
  • 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 amount of data, the exports are split into several files, such as 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 offer is a service where the passenger orders a journey via a booking process – often independent of fixed stops or timetables. These are ordered consolidated journeys in which several passengers with similar transport requirements are transported together. You can find further information on ODS 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 on opentransportdata.swiss can be found in the Cookbook at NeTEx – On Demand Services.

NeTEx import & export processes

Frame Short definition
TimetableFrame Contains the timing of trips (VehicleJourneys), including stopping points and times.
ServiceFrame Describes the operational aspects of lines and trips, e.g. journey patterns and routes.
SiteFrame Defines geographical locations such as stops, stations or access points.
Resource frame Contains resources such as vehicles, personnel or operating units.
ServiceCalendarFrame Defines the validity of trips, e.g. calendar days, periods and exceptions.
CommonFrame Contains shared items such as organizations, codes, tariffs, or references.
AccessibilityFrame Describes accessibility features of stops, vehicles and services.
FareFrame Includes fare information, price rules and ticket types.

Sample data

An example of NeTex XML data with the above 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 abbreviations)
Version e.g. v1.0, v2.3
Date Format: YYYYMMDD
Type Optional: e.g. Full, Delta, Test, Export

Validation & Troubleshooting with NeTex data

NeTEx data contains many lines of XML and can be confusing. There are various free tools for this. The most popular are:

Validation applications:

  • The Netex Validator (https://github.com/entur/netex-validator-java) by Entur is a Java-based validation library specifically developed for testing NeTEx datasets – especially in the context of the Nordic NeTEx profile used in Norway and other Scandinavian countries.
  • XMLSpy is an Altova paid XML editor and development tool that can be used to validate NeTEx data. Validation is done against 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 Convert GTFS → NeTEx EPIPNeTEx EPIP → GTFS GitHub – MMTIS/badger: Timetable conversions
GTFS2NeTEx Converter Convert GTFS → NeTEx Interoperable Europe Portal
Damu Convert 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, more detailed, for in-depth network modelling and European interoperability.
  • HRDF (Hafas Raw Data Format): Proprietary, very detailed, mainly widespread in Switzerland and Germany.
  • Transmodel: A conceptual model on which NeTEx is based – for planning, operations and analysis.

Each format was 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 is also very important. 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 processed more easily 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. Its structure is modular and deeply nested, which makes processing difficult without specialised tools.

#AutoTranslate