NeTEx

Kurzbeschreibung

Network Timetable Exchange (NeTEx) ist der Standard der EU für Fahrplandaten und wurde vom European Committee for Standardization (CEE) entwickelt. Es basiert auf Transmodel, dem europäischen Referenzdatenmodell für den öffentlichen Verkehr.

Auf dieser Cookbook-Seite werden Unterschiede und Besonderheiten der Schweizer Implementation von NeTex im Vergleich zu anderen Ländern der EU hervorgehoben und erklärt.

Fachliche Beschreibung 

Network Timetable Exchange (NeTEx) schafft eine einheitliche Plattform für den Austausch von Verkehrsdaten zur Fahrplanerstellung für Bahn, Bus, Seilbahnen, Schiffe sowie lokale Anbieter anderer Mobilitätsformen – wie Fahrräder und E-Scooter.

Die NeTEx-Gruppe besteht (Stand 2025) aus 12 Ländern, die dieses Format aktiv nutzen, sowie weiteren 5 Ländern, die sich in der Implementierungsphase befinden. Der Markt wächst weiter – auch über Europa hinaus, wie das Beispiel des australischen Bundesstaates Victoria zeigt.

Für die Schweiz ist der NeTEx-Datenstandard von grosser Bedeutung, um den effizienten Austausch von Fahrplandaten zwischen internationalen Verkehrsunternehmen zu ermöglichen. So kann den Endkunden ein zuverlässiger und nahtloser Fahrplan von Punkt A nach B angeboten werden: Wenn beispielsweise eine Person den Fahrplan für eine Zugverbindung von Zürich nach Lyon (F) betrachtet, sind alle Verbindungen und Umstiege in beiden Ländern enthalten.

Neben NeTEx gibt es auch andere Formate für Fahrplandaten, wie HRDF oder GTFS.

GTFS (General Transit Feed Specification)

• Herkunft: Entwickelt von Google in Zusammenarbeit mit TriMet (Portland, USA), inzwischen weiterentwickelt durch MobilityData.
• Format: Eine Sammlung von CSV- (Text-)Dateien, gebündelt in einem ZIP-Archiv.
• Struktur: Einfaches, tabellarisches Format mit vordefinierten Dateien wie stops.txt, routes.txt, trips.txt, stop_times.txt usw.
• Schwerpunkt: Weit verbreitet für Fahrplanauskunft, Echtzeitinformationen und Open-Data-Portale.

Detaillierte Informationen zu GTFS im GTFS-Cookbook.

HRDF (HAFAS Raw Data Format)

• Herkunft: Entwickelt von HaCon, einem deutschen Unternehmen (heute Teil von Siemens).
• Format: Proprietäres, binäres oder textbasiertes Format, das intern im HAFAS-System von HaCon verwendet wird.
• Struktur: Stark auf Leistung optimiert, jedoch erschwert menschenlesbar und nicht öffentlich dokumentiert.
• Schwerpunkt: Hauptsächlich in deutschsprachigen Ländern im Einsatz (z. B. Deutsche Bahn, SBB) für interne Planungs- und Fahrplansysteme.

Detaillierte Informationen zu HRDF im HRDF-Cookbook.

Technische Beschreibung

Dateistruktur und Benennung

NeTEx-Dateien sollten klar, konsistent und maschinenlesbar benannt werden. Ein typisches Schema könnte so aussehen:

[Modul]_[Region]_[Version]_[Datum]_[Typ].xml

• Timetable_CH_2025_v1.2_20250801.xml – Fahrplandaten für die Schweiz, Version 1.2, erstellt am 1. August 2025
• FareFrame_ZH_v3.0_20250715.xml – Tarifdaten für Zürich, Version 3.0
• ServiceFrame_BE_v2.1_20250820.xml – Linien- und Dienstinformationen für Bern

Grundlagen von NeTEx

NeTEx verwendet ein modulares XML-Schema, das auf Transmodel basiert. Es definiert abstrakte Datenmodelle für verschiedene Bereiche des öffentlichen Verkehrs, z. B. Haltestellen, Linien, Fahrpläne, Tarife und Betriebsdaten. Die wichtigsten Elemente des NeTEx-XML sind die Frames. Jedes Frame beinhaltet fachspezifische Informationen zur Bildung eines Transportmittels. 

Es folgt ein Kurzbeschrieb der Frames mit den wichtigsten Klassen. Detailliertere Informationen sind unter folgendem Link zu finden: NeTEx – Transmodel (https://transmodel-cen.eu/index.php/netex/).

FrameDefaults 

FrameDefaults sind ein Mechanismus zur Definition von Standardwerten, wie z.B. Zeitzone, Lokalzeit, Sprachauswahl. 

CompositeFrame

Ein CompositeFrame fasst mehrere thematisch zusammenhängende Datenrahmen (Frames) in einer einzigen Datei zusammen, z. B. FrameDefaults, ResourceFrame, SiteFrame, ServiceFrame, ServiceCalendarFrame, TimetableFrame. Nützlich für die strukturierte Bereitstellung komplexer Datensätze, wo verschiedene Aspekte des öffentlichen Verkehrs gemeinsam benötigt werden.

ResourceFrame

ResponsibilityRoleAssignment

Verknüpft eine Organisation (SBB, DB, BLS, etc)., mit einer bestimmten Rolle in Bezug auf ein anderes Element (z. B. eine Linie, ein Fahrplan, ein Service).

TypeOfProductCategory

Ein klassifizierendes Element, das die Art des Produkts beschreibt (z. B. Zugtyp, Busangebot, Serviceklasse).

TypeOfNotice

Definiert Hinweisarten oder Angebote, die in der Fahrgastinformation verwendet werden. Es handelt sich um eine Typdefinition, die von konkreten Notice-Elementen referenziert wird

SiteFrame

TopographicPlace

Dient der geografischen Einordnung von Haltestellen und anderen Standorten. In der Schweiz wird dabei meist der Kanton (nicht die Gemeinde) als TopographicPlace verwendet, um eine einheitliche und übersichtliche Struktur zu gewährleisten.

StopPlace

Beschreibt verschiedene Aspekte einesphysischen Zugangspunkts zum Verkehr, wie zum Beispiel eine Haltestelle oder Station; in der Schweiz bezieht es sich auf einen Kanton oder eine Region.

Quay

Gehört immer zu einem StopPlace. Es handelt sich um eine Einrichtung wie ein Bahnsteig, eine Halteposition oder ein Steg, an dem Fahrgäste Zugang zu öffentlichen Verkehrsmitteln, Taxis, Autos oder anderen Transportmitteln haben. Ein Quay kann einen oder mehrere Fahrzeughalteorte bedienen und mit einem oder mehreren Haltepunkten verknüpft sein.

ServiceFrame 

Direction

Eine Direction beschreibt eine Fahrtrichtung innerhalb einer Linie z.B. „Richtung Bahnhof“ oder „Richtung Flughafen “. Sie hilft, Fahrten innerhalb einer Linie zu unterscheiden – z. B. Hin- und Rückfahrt. 

Line

Repräsentiert eine Verkehrslinie im öffentlichen Verkehr, z. B. eine Buslinie, Tramlinie oder Zugverbindung, i.e. „Buslinie 10“ oder „S-Bahn S3“.  Sie gruppiert Fahrten, die unter derselben Liniennummer oder -bezeichnung laufen. 

DestinationDisplays

Visuelle Zielanzeige, die Fahrgästen mitteilt, wohin ein Fahrzeug fährt. Wird oft mit einer ServiceJourney oder VehicleJourney verknüpft und ist besonders relevant für die Fahrgastinformation – z. B. auf Bussen, Zügen oder elektronischen Anzeigen.

ScheduledStopPoint 

Ein zentrales Konzept. Es handelt sich um den „Punkt“, der im Fahrplan verwendet wird, an dem ein Dienst hält. Ein ScheduledStopPoint kann sich entweder auf einen Quay (z. B. Bahnsteig, Halteposition) oder nur auf einen StopPlace (z. B. Bahnhof, Haltestelle) beziehen. Die Hierarchieebene wird dabei nicht durch das Element selbstbestimmt (siehe PassengerStopAssignment).

PassengerStopAssignment

Das Hauptelement, das die Zuordnung beschreibt. Es gibt die Reihenfolge an, in der dieser Haltepunkt innerhalb einer Route oder eines JourneyPatterns erscheint. Es verweist auf den logischen Haltepunkt im Fahrplan, den “ScheduledStopPointRef”, welches auf den “StopPlaceRef” auf den physischen Ort (z. B. eine Haltestelle) bezieht. 

Notice

Definiert wiederverwendbare Textelemente, die als Hinweise verwendet werden können – etwa als Fussnoten in Fahrplänen, als Durchsagen oder andere Mitteilungen. NOTICES werden anderen Elementen über eine NOTICE ASSIGNMENT zugeordnet. Sie können mit einem TYPE OF NOTICE klassifiziert werden.

Das Element  dient als Container, um vordefinierte Hinweise oder Mitteilungen – wie etwa Fahrgastinformationen, betriebliche Hinweise oder Servicemeldungen – gezielt mit bestimmten Objekten innerhalb der Fahrplandaten zu verknüpfen. Dazu zählen unter anderem:

• ServiceJourneys (konkrete Fahrten)
• JourneyParts (Teilabschnitte einer Fahrt)
• TrainBlocks (Zugumläufe)
• StopPoints (Haltepunkte)
• OperatingDays (Betriebstage)

ServiceCalendarFrame

AvailabilityCondition

Eine Spezialisierung der VALIDITY CONDITION, um präzise zeitliche Bedingungen zu definieren. Zum Beispiel kann ein Eingang eines StopPlace gültig sein (er existiert), aber nicht zu jeder Zeit verfügbar sein (z. B. geschlossen zwischen 21:00 Uhr und 6:00 Uhr). Sowohl VALIDITY CONDITIONs als auch AVAILABILITY CONDITIONs können mit demselben Objekt verknüpft werden

ServiceCalendar

Das Verkehrsangebot eines öffentlichen Verkehrsunternehmens wird so gestaltet, dass es unterschiedlichen Nachfragen gerecht wird. Um die Angebotsplanung zu vereinfachen, erstellen nahezu alle Betreiber ihren Produktionsplan anhand einer Klassifizierung nach Tagesarten, die das Nachfrageverhalten oder andere Merkmale zusammenfasst – zum Beispiel Werktag, Wochenende, Schulferien, Markttag usw. Langfristig geplante Fahrpläne werden über den sogenannten Verkehrskalender erstellt, in dem Kalendertage als spezifische Tagesarten (DAY TYPEs) klassifiziert werden.

DayTypes

Fahrpläne werden über den sogenannten Verkehrskalender erstellt, in dem Kalendertage als spezifische Tagesarten (DAY TYPEs) klassifiziert werden.

TimetableFrame

ServiceJourney

Ist ein Fahrzeuglauf, bei der Fahrgäste an Haltestellen ein- oder aussteigen dürfen. Sie beschreibt die Verkehrsleistung zwischen einem Start- und einem Zielpunkt, wie sie öffentlich kommuniziert wird.

DestinationDisplayRef 
Beschreibt die visuelle Zielanzeige, die mit einem Haltevorgang (Call) verknüpft ist. Sie ist wichtig für die Fahrgastinformation, z. B. auf Fahrzeuganzeigen oder in elektronischen Fahrplänen.

NoticeAssignments
Wird innerhalb der ServiceJourney verwendet. In diesem Fall gilt die Mitteilung für die gesamte Fahrt. Ist eine Mitteilung nur für einen Teil der ServiceJourney gültig, erfolgt die Zuordnung in allen betreffenden Call-Elementen.

Call
Stellt eine Sicht dar, die Daten zum einzelnen Haltestellenbesuch zusammenführt. Geordnete Sammlungen von Call-Elementen können in ServiceJourney-Instanzen enthalten sein, die über NeTEx ausgetauscht werden.

RequestStop
Kennzeichnug für Bedarfshalte (“Halt auf Verlangen”). Wird häufig im ländlichen Raum oder bei On-Demand-Verkehren verwendet. Es kann in Fahrgastinformationssystemen entsprechend gekennzeichnet werden (z. B. mit einem Symbol oder Hinweistext). Wichtig für die Fahrzeitberechnung, da Bedarfshalte ggf. übersprungen werden und somit die Reisezeit verkürzt wird.

StopUse
Ein Attribut, das angibt, welche Funktion ein Haltepunkt innerhalb einer VehicleJourney erfüllt. Es beschreibt, ob der Halt für:

• Zustieg (boarding),
• Ausstieg (alighting),
• beides (both),
• oder keine dieser Funktionen (pass-through)

genutzt wird.

TrainNumber

Die TrainNumber bestehen derzeit aus maximal sechs Ziffern. Eine ServiceJourney kann grundsätzlich mehrere unterschiedliche Zugnummern enthalten, während ein JourneyPart jeweils nur auf eine einzelne TrainNumber verweist. In der Schweiz gibt es keinen Unterschied zwischen der veröffentlichten und der produktiven TrainNumber.

FacilitySet

Ein strukturiertes Element, das zur Zuweisung von Einrichtungen zu einer ServiceJourney oder einem JourneyPart verwendet wird. SKI klassifiziert diese Einrichtungen in folgende Gruppen:

• Unterkunftseinrichtungen
• Verpflegungseinrichtungen
• Tarifklassen
• Gruppenbuchungseinrichtungen
• Gepäcktransport-Einrichtungen
• Mobilitätseinrichtungen
• Einrichtungen zur Minderung von Störungen
• Kommunikationseinrichtungen für Fahrgäste
• Reservierungseinrichtungen für Dienste
• Ticketausgabeeinrichtungen
• UIC-Zugtarife

Diese Klassifizierung ermöglicht eine standardisierte Beschreibung der verfügbaren Services entlang einer Reise. Die Liste kann bei Bedarf erweitert werden, sofern die jeweilige Kategorie in den NeTEx-Spezifikationen definiert ist.

JourneyMeeting

Beschreibt die Möglichkeit, Fahrpläne unter Berücksichtigung verschiedener Umsteigemöglichkeiten zu planen:

• Umstieg zu einem anderen Dienst, bei dem nur die Ankunfts- oder Abfahrtszeit bekannt ist.
• Allgemeiner: Ein Dienst, dessen Fahrplan sich nach der festgelegten Zeit eines externen Ereignisses richtet, das diesen Dienst entweder speist oder von ihm gespeist wird.
• Organisation eines Treffpunkts (Hubs) zwischen mehreren Diensten innerhalb eines definierten Zeitfensters; dies stellt eine vereinfachte Spezifikation mehrerer Umstiege dar. Falls erforderlich, kann dies detailliert durch mehrere INTERCHANGE RULEs oder SERVICE JOURNEY INTERCHANGEs beschrieben werden.
• Festlegung eines Treffpunkts (Zeit und Ort) für jede Fahrt, die diesen Termin wahrnehmen kann.

InterchangeRule 

Regelwerk, das es ermöglicht, geplante Umsteigevorgänge im Fahrplan zu dokumentieren, ohne die genauen Details beider beteiligten ServiceJourneys angeben zu müssen. Es dient dazu, potenzielle Umsteigebeziehungen zwischen Fahrten zu definieren und zu strukturieren, insbesondere wenn diese nicht vollständig spezifiziert sind.

InterchangeRuleParameter
Element innerhalb des TimetableFrame zur Spezifikation von Parametern für geplante Umsteigevorgänge zwischen verschiedenen ServiceJourneys. Es definiert die Bedingungen und Einschränkungen, unter denen ein Umstieg als gültig betrachtet wird – etwa hinsichtlich des Verkehrsmittels (Mode), der Linie (Line) oder der Fahrtrichtung (Direction).
Diese Parameter ermöglichen eine flexible Modellierung von Umsteigebeziehungen, ohne dass die vollständigen Details der beteiligten Fahrten angegeben werden müssen. Sie sind insbesondere dann nützlich, wenn Umsteigevorgänge dynamisch oder regelbasiert geplant werden sollen.

InterchangeRuleTiming
Element innerhalb des TimetableFrame, um zeitliche Bedingungen für geplante Umsteigevorgänge zwischen verschiedenen ServiceJourneys zu definieren. Es legt fest, wie viel Zeit für einen Umstieg erforderlich oder zulässig ist – beispielsweise Mindest- oder Höchstwartezeiten zwischen einer Zubringer- und einer Verteilerfahrt an einem gemeinsamen Haltepunkt (ScheduledStopPoint).

Eigenschaften des Schweizer Profils

Die Schweiz verwendet ein nationales NeTEx-Profil, das auf dem europäischen Standard basiert, aber auf die spezifischen Anforderungen der Schweizer Verkehrsdaten zugeschnitten ist.

• Das Profil ist deutschsprachig dokumentiert und basiert auf sogenannten „Calls“, also spezifischen Datenanforderungen. 
• Eine französische Version ist geplant bzw. kann maschinell übersetzt werden, um die Mehrsprachigkeit der Schweiz zu berücksichtigen.
• Es wird 2x pro Woche über die Plattform opentransportdata.swiss exportiert und umfasst alle öffentlichen Verkehrsmittel der Schweiz für das jeweilige Fahrplanjahr.
• Aufgrund der Datenmenge werden die Exporte in mehrere Dateien aufgeteilt, z. B. nach TimetableFrame, ServiceFrame, SiteFrame etc., um die Verarbeitung zu erleichtern

On-Demand-Verkehr

Für On-Demand-Verkehr (ODV) existieren spezialisierte Konzepte, die ebenfalls im Schweizer Profil berücksichtigt werden. Ein On-Demand-Angebot ist eine Dienstleistung, bei der der Fahrgast über einen Buchungsvorgang eine Fahrt bestellt – oft unabhängig von festen Haltestellen oder Fahrplänen. Es handelt sich um bestellte Sammelfahrten, bei denen mehrere Fahrgäste mit ähnlichen Transportbedürfnissen gemeinsam befördert werden. Auf öv-info findet man weitere Informationen zum Thema ODV: On Demand Verkehr (Rufbus). Es existiert zudem ein Fachkonzept On-Demand-Verkehr für den Schweizer öV: https://www.oev-info.ch/sites/default/files/2023-04/fachkonzept_on-demand_v2.0.pdf.pdf

Eine Übersicht zum ODV auf opentransportdata.swiss findet man im Cookbook unter NeTEx – On Demand Verkehre.

NeTEx Import- & Exportprozesse

• Export- und Importfrequenz: 2x pro Woche, jeweils über Fahrplan 2025 (NeTEx) – Datensatz – opentransportdata.swiss – CKAN data catalog
• Datenumfang: Enthält den gesamten öffentlichen Verkehr der Schweiz für das jeweilige Fahrplanjahr.
• Dateigrösse: Sehr gross (bis über 4 GB), daher aufgeteilt nach Frames (z. B. TimetableFrame, ServiceFrame):

Frame	Kurzdefinition
TimetableFrame	Enthält die zeitliche Planung von Fahrten (VehicleJourneys) inkl. Haltepunkte und Zeiten.
ServiceFrame	Beschreibt die betrieblichen Aspekte von Linien und Fahrten, z. B. JourneyPatterns und Routes.
SiteFrame	Definiert geografische Orte wie Haltestellen, Bahnhöfe oder Zugangspunkte.
ResourceFrame	Enthält Ressourcen wie Fahrzeuge, Personal oder Betriebseinheiten.
ServiceCalendarFrame	Legt die Gültigkeit von Fahrten fest, z. B. Kalendertage, Perioden und Ausnahmen.
CommonFrame	Beinhaltet gemeinsam genutzte Elemente wie Organisationen, Codes, Tarife oder Referenzen.
AccessibilityFrame	Beschreibt barrierefreie Eigenschaften von Haltestellen, Fahrzeugen und Diensten.
FareFrame	Enthält Tarifinformationen, Preisregeln und Tickettypen.

Beispieldaten

Ein Beispiel von NeTex-XML-Daten mit den obengenannten Frames: https://github.com/user-attachments/files/18201746/swiss_mikro.zip

Typische Bestandteile im Dateinamen:

Bestandteil	Beschreibung
Modul	z. B. Timetable, FareFrame, ServiceFrame
Region	z. B. CH, ZH, BE (ISO oder interne Kürzel)
Version	z. B. v1.0, v2.3
Datum	Format: YYYYMMDD
Typ	Optional: z. B. Full, Delta, Test, Export

Validierung & Fehlerbehebung bei NeTex-Daten

NeTEx-Daten beinhalten zahlreiche Zeilen XML und kann auch unübersichtlich wirken und dafür gibt es verschiedene kostenlose Werkzeuge. Die populärsten sind:

• Strukturprüfung mit XSD – Die NeTEx-Daten basieren auf einem XML-Schema (XSD), das die formale Struktur der Daten definiert. Die Schweiz verwendet ein eigenes NeTEx-Profil, das auf dem europäischen Standard basiert, aber auf nationale Anforderungen zugeschnitten ist: NeTEx Realisation directive for public transport in Switzerland
• Die aktuelle Version des XMD-Schemas wird auf GitHub (https://github.com/NeTEx-CEN/NeTEx) gepflegt und ist öffentlich zugänglich: https://www.oev-info.ch/sites/default/files/2024-05/NeTEx_Core-Realisation_Guide_TP_Suisse-v1.00.pdf

Validierungsapplikationen:

• Der Netex Validator (https://github.com/entur/netex-validator-java) von Entur ist eine Java-basierte Validierungsbibliothek, die speziell für die Prüfung von NeTEx-Datensätzen entwickelt wurde – insbesondere im Kontext des Nordic NeTEx Profils, das in Norwegen und anderen skandinavischen Ländern verwendet wird.
• XMLSpy ist ein kostenpflichtiges XML-Editor- und Entwicklungswerkzeug von Altova, das zur Validierung von NeTEx-Daten verwendet werden kann. Die Validierung erfolgt anhand der zugehörigen XML-Schema-Dateien (XSD), die die Struktur und Regeln der NeTEx-Daten definieren.

Empfehlungen für Tools und Workflows

Konvertierung & Verarbeitung

Tool	Zweck	Quelle
MMTIS/Badger	Konvertiert GTFS → NeTEx EPIPNeTEx EPIP → GTFS	GitHub – MMTIS/badger: Timetable conversions
GTFS2NeTEx Converter	Konvertiert GTFS → NeTEx	Interoperable Europe Portal
Damu	Konvertiert NeTEx → GTFS	GitHub – entur/damu
geOps GTFS Feed	Tägliche GTFS-Konvertierung aus HRDF	geOps GTFS Feed

FAQ

Warum gibt es so viele verschiedene Formate für Transportdaten?

Unterschiedliche Bedürfnisse und Anwendungsfälle:

• GTFS (General Transit Feed Specification): Einfach, weit verbreitet, ideal für Fahrplan-Apps und Routing.
• NeTEx (Network Timetable Exchange): Komplexer, detaillierter, für tiefgreifende Netzmodellierung und europäische Interoperabilität.
• HRDF (Hafas Raw Data Format): Proprietär, sehr detailliert, vor allem in der Schweiz und Deutschland verbreitet.
• Transmodel: Ein konzeptionelles Modell, auf dem NeTEx basiert – für Planung, Betrieb und Analyse.

Jedes Format wurde für bestimmte Zwecke entwickelt – z. B. GTFS für Google Maps, NeTEx für EU-weite Datenintegration, HRDF für interne Systeme. Die technologische Entwicklung der Transportdaten spielt auch eine sehr grosse Rolle. Ältere Formate wie HRDF sind textbasiert und schwer zu validieren. Neuere Formate wie NeTEx basieren auf XML und erlauben strukturierte, maschinenlesbare Daten, die leichter automatisiert verarbeitet werden können.

Sind die Datenstrukturen selbsterklärend?

NeTEx basiert auf einem sehr detaillierten Datenmodell (Transmodel), was zu einer steilen Lernkurve führt. Die Struktur ist modular und tief verschachtelt – das erschwert die Verarbeitung ohne spezialisierte Tools.

#AutoTranslate