GTFS vs. NeTEx — die zwei Open-Standards für Transit-Daten im DACH 2026

Wer in Deutschland im Mai 2026 eine Fahrplanauskunft auf dem Handy aufruft — DB Navigator, Öffi, VBB-Fahrinfo, MVG Fahrinfo, HVV-App — bekommt am Ende der Anfrage eine Antwort, die auf einer von zwei großen Open-Standards-Familien beruht: GTFS oder NeTEx. Meistens auf beiden. Die zwei Standards sind das tragende Fundament des digitalen ÖPNV im DACH-Raum — gleichermaßen kritisch wie selten erklärt. Wer sie auseinanderhält, versteht, warum manche Fahrplandaten in der App aktuell sind und manche nicht, warum die DELFI-Plattform die zentrale Rolle spielt, die sie spielt, und warum die EU-Verordnung 2017/1926 für die nächsten Jahre der bestimmende regulatorische Rahmen bleibt.

Zwei Standards, zwei Geschichten

GTFS — die General Transit Feed Specification — ist 2005 in Portland geboren. Das städtische ÖPNV-Unternehmen TriMet wollte seine Fahrpläne in Google Maps integrieren, Google hatte kein einheitliches Datenformat für ÖPNV-Daten, und ein Google-Ingenieur namens Chris Harrelson entwickelte gemeinsam mit Bibiana McHugh von TriMet ein einfaches CSV-basiertes Format: stops.txt, routes.txt, trips.txt, stop_times.txt. Das war zunächst „Google Transit Feed Specification”. Als der Standard 2010 freigegeben wurde und seine Verbreitung über Google hinaus wuchs, wurde aus dem „G” für Google das „G” für General.

Der Erfolg von GTFS beruht auf seiner Einfachheit. Die GTFS-Spezifikation umfasst rund 25 Tabellen in CSV-Form. Wer einen Stadt-Verkehrsbetrieb hat und Fahrpläne abbilden will, kann das mit einem mittleren technischen Aufwand. Heute pflegen weltweit über 10.000 Verkehrsbetriebe ein GTFS-Feed, die meisten in Form von täglichen oder wöchentlichen ZIP-Pakaten zum Download.

NeTEx — Network Timetable Exchange — ist die europäische Antwort und kommt aus der Normungswelt. Der Standard wurde vom CEN-Technischen-Komitee 278 entwickelt, der Arbeitsgruppe für Intelligent Transport Systems im europäischen Normungsinstitut. Die ersten NeTEx-Teile wurden 2014 als CEN/TS 16614 veröffentlicht, die Vollversion als europäische Norm EN 16614 in den Folgejahren. NeTEx ist XML-basiert, deutlich umfangreicher als GTFS und auf die Abbildung komplexer europäischer Tarifstrukturen ausgelegt — Zonen, Preisstufen, Verbund-Tarife, eTicketing-Tarife.

Die zwei Standards stehen nicht im Widerspruch zueinander; sie haben verschiedene Stärken. GTFS ist agile, leichtgewichtig, von einer großen Open-Source-Community getragen. NeTEx ist umfassend, formal, in der europäischen Regulierung verankert. Im DACH-Raum laufen 2026 beide Standards parallel — die Frage ist, in welchem Anwendungskontext welcher Standard dominiert.

Datenmodell-Vergleich: das CSV-File gegen das XML-Schema

Der Unterschied im Datenmodell ist greifbar. Ein GTFS-Feed ist ein ZIP-Archiv mit etwa 25 CSV-Dateien. Die Pflichtfelder sind überschaubar: stops.txt (Haltestellen mit Koordinaten), routes.txt (Linien), trips.txt (konkrete Fahrten), stop_times.txt (Ankunfts-/Abfahrtszeiten je Fahrt und Halt), calendar.txt (Betriebstage). Ein typischer GTFS-Feed eines Stadtverkehrsbetriebs ist 5 bis 50 Megabyte groß; ein bundesweiter Feed wie der von der Verband Deutscher Verkehrsunternehmen (VDV) bereitgestellte BAG-ÖPNV-Datensatz liegt im Bereich von einigen hundert Megabyte.

NeTEx ist deutlich umfangreicher. Der Standard kennt fünf Profile (Network, Timetable, Fares, Accessibility, Operating Information), die einzeln oder kombiniert genutzt werden können. Ein NeTEx-Dokument ist ein XML-Baum mit hunderten von Element-Typen — Site, Quay, ScheduledStopPoint, Line, JourneyPattern, ServiceJourney, FareZone, FareProduct, AccessibilityAssessment. Die Spezifikation ist als CEN-Dokument frei verfügbar und umfasst über 800 Seiten Dokumentation.

Die größere Komplexität hat einen Grund: NeTEx kann Dinge abbilden, die in GTFS nur mit Behelfslösungen gehen. Tarif-Architekturen — VBB A/B/C-Zonen, RMV-Preisstufen, MVV-Zonen-Modell, HVV-Ringe — lassen sich in NeTEx sauber modellieren, während GTFS sie nur über das GTFS-Fares-v2-Erweiterungsprofil erfasst, das erst 2023 produktiv wurde und in Deutschland 2026 noch nicht überall umgesetzt ist. Barrierefreiheits-Informationen — Aufzüge, Rolltreppen, taktile Leitsysteme, Stufenfreiheit — sind in NeTEx über das Accessibility-Profil strukturiert, in GTFS nur rudimentär (Flag pro Haltestelle).

Im DACH-Raum bedeutet das: Wer ein einfaches App-Routing bauen will (Stadt-Fahrplan, Linien, Abfahrtszeiten), kommt mit GTFS aus. Wer eine bundesweite Auskunft mit Tarif-Info, eTicketing-Integration und Barrierefreiheits-Filter bauen will, braucht NeTEx.

Realtime-Pendants: GTFS-RT gegen SIRI

Beide Standards haben Realtime-Pendants, die separat zu betrachten sind.

GTFS-Realtime ist das Echtzeit-Format der GTFS-Familie. Es nutzt nicht CSV, sondern Protobuf — Googles Binärformat — als Übertragungsformat. Drei Feed-Typen sind definiert: TripUpdates (Verspätungen, Streichungen, geänderte Halte), VehiclePositions (GPS-Position der Fahrzeuge), Alerts (Störungs-Meldungen). GTFS-RT ist im weltweiten App-Ökosystem extrem verbreitet, weil Google Maps, Apple Maps, Citymapper, Transit und eine Reihe weiterer Apps GTFS-RT-Feeds nativ konsumieren.

SIRI — Service Interface for Real-time Information — ist das europäische Realtime-Pendant. Der Standard ist ebenfalls aus dem CEN-Umfeld (CEN/TS 15531) und XML-basiert. SIRI kennt mehrere Service-Module: StopMonitoring (Echtzeit-Abfahrten an einer Haltestelle), VehicleMonitoring (Fahrzeug-Positionen), SituationExchange (Störungsmeldungen, vergleichbar GTFS-RT-Alerts), ConnectionMonitoring (Anschluss-Überwachung), ProductionTimetable (kurzfristige Fahrplanänderungen). Im Gegensatz zu GTFS-RT ist SIRI sehr stark vom Service-Pull-Modell geprägt: Der Konsument fragt periodisch ab, der Anbieter antwortet mit der aktuellen Lage. GTFS-RT setzt überwiegend auf Push-Modelle und kompaktes Binärformat.

In der DACH-Praxis 2026 nutzen die Verkehrsverbünde überwiegend SIRI für die interne Anschluss-Sicherung und für die Datenweitergabe an DELFI. Für die App-Anbindung an internationale Apps (Google Maps, Apple Maps) wird die SIRI-Datenbasis in GTFS-RT konvertiert. Open-Source-Tools wie der siri-gtfs-bridge und der navitia-converter machen die Konvertierung praktikabel, sie ist aber nicht trivial: SIRI ist semantisch reicher als GTFS-RT, und einige Informationen gehen bei der Konvertierung verloren.

Tooling: gtfsvtor, navitia, OpenTripPlanner

Wer mit den Standards arbeitet, kommt an einem überschaubaren Tooling-Ökosystem nicht vorbei.

gtfsvtor ist der inoffizielle, aber faktische Validator für GTFS-Feeds. Das Java-Tool wurde von MobilityData (der Stiftung, die GTFS heute pflegt) als Nachfolger des älteren feedvalidator etabliert. Es prüft einen Feed gegen die Pflicht-Tabellen, die Konsistenz der Fremdschlüssel-Beziehungen, die zeitliche Plausibilität der Fahrten. Wer als Verkehrsbetrieb einen GTFS-Feed veröffentlicht, lässt ihn vorher durch gtfsvtor laufen — das ist der Standard im Mai 2026.

Navitia ist das französische Open-Source-Routing-Backend, das von der Firma Hove (vormals Kisio Digital) entwickelt und unter AGPL veröffentlicht wird. Navitia frisst sowohl GTFS- als auch NeTEx-Eingaben und liefert eine Routing-API, die OpenStreetMap-basiertes Fußgänger-Routing mit ÖPNV-Routing kombiniert. Das französische Mobilitätsportal nutzt Navitia, das italienische ebenso. In Deutschland wird Navitia von einigen kleineren Verbünden eingesetzt, größere Verbünde nutzen eher proprietäre Routing-Engines wie die EFA von Mentz oder die HAFAS-Familie der HaCon.

OpenTripPlanner (OTP) ist das amerikanische Open-Source-Pendant. OTP wurde von TriMet (Portland) initiiert, ist Java-basiert und ebenfalls AGPL. OTP unterstützt GTFS- und NeTEx-Eingaben und kombiniert ÖPNV-Routing mit Fahrrad- und Auto-Routing. In Deutschland wird OTP von MobilityData für Deutschland als Backend für eine offene Routing-API getestet; das Projekt ist 2025 angelaufen und liefert 2026 erste produktive Schnittstellen, allerdings nicht flächendeckend.

HAFAS und EFA sind die proprietären Größen im DACH-Raum. HAFAS — Hannoveraner Fahrplan-Auskunfts-System — der HaCon (Hannover) ist die Routing-Engine, die unter dem DB Navigator (40 Millionen+ Installationen weltweit), unter den Apps der ÖBB, der SBB-CFF-FFS und vieler regionaler Verbünde läuft. EFA — Elektronische Fahrplan-Auskunft — der Mentz GmbH (München) ist das funktionale Äquivalent für MVV, VRR, VBB und eine Reihe weiterer Verbünde. Beide Systeme sind kommerzielle Closed-Source-Produkte, sie konsumieren aber GTFS- und NeTEx-Daten und exportieren in beide Formate.

DELFI: der nationale Aggregations-Hub

Die DELFI — durchgängige elektronische Fahrgastinformation — ist die zentrale Datendrehscheibe des deutschen ÖPNV. DELFI ist eine Bund-Länder-Organisation, in der die ÖPNV-Aufgabenträger der Länder kooperieren, um eine bundesweit konsistente Fahrgastinformation zu ermöglichen. Die Aufgabe: Datenströme aus den Verkehrsverbünden aggregieren, validieren, harmonisieren und als bundesweite Datenbasis bereitstellen — sowohl für die statische Fahrplan-Information als auch für die Echtzeitdaten.

Die DELFI nutzt im Datenfluss überwiegend NeTEx und SIRI, weil das die EU-konformen Formate sind. Die Verkehrsverbünde liefern ihre Daten in unterschiedlicher Vollständigkeit und Qualität an DELFI; DELFI harmonisiert und aggregiert. Die aggregierte Datenbasis wird seit 2022 über die Mobilitätsdaten-Plattform des Bundesministeriums für Digitales und Verkehr (BMDV) — die mCLOUD-Nachfolge — als Open Data zur Verfügung gestellt. Externe Entwickler können seither die bundesweiten Daten konsumieren, was zuvor an verteilten Schnittstellen und unklaren Lizenzbedingungen gescheitert war.

Die Qualität der DELFI-Daten ist im Mai 2026 deutlich besser als 2022, aber nicht perfekt. Lücken bestehen vor allem dort, wo regionale Verbünde nicht oder unvollständig liefern — typischerweise kleinere ländliche Räume in Brandenburg, Mecklenburg-Vorpommern, Teilen Sachsens. Die Echtzeitdaten-Abdeckung ist in Großstadt-Räumen nahezu vollständig, in ländlichen Räumen lückenhaft. Der bundesweite Zielwert einer 95-prozentigen Echtzeitdaten-Quote ist 2026 noch nicht erreicht; der DELFI-Statusbericht für Q1/2026 nennt 81 Prozent.

EU-VO 2017/1926: der regulatorische Rahmen

Wer den DACH-Datenstandard-Diskurs verstehen will, muss die EU-Verordnung 2017/1926 mitlesen. Die Verordnung — vollständig: Delegierte Verordnung (EU) 2017/1926 der Kommission vom 31. Mai 2017 zur Ergänzung der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates hinsichtlich der Bereitstellung EU-weiter multimodaler Reiseinformationsdienste — verpflichtet die EU-Mitgliedstaaten, statische Reise- und Verkehrsdaten in standardisierten Formaten über nationale Zugangspunkte (NAP — National Access Points) zugänglich zu machen.

Die Pflicht zur Bereitstellung statischer Transit-Daten in NeTEx ist seit dem 1. Dezember 2019 wirksam. Für Realtime-Daten (SIRI) gilt eine entsprechende Pflicht seit dem 1. Dezember 2020. Die Bundesrepublik hat die NAP-Funktion auf die Mobilitätsdaten-Plattform des BMDV übertragen, die wiederum die DELFI-Datenbasis als Backend nutzt.

In den letzten Jahren ist die Verordnung mehrfach konkretisiert worden. Die delegierte Verordnung 2024/1276 — wirksam seit dem 1. Januar 2026 — hat die Anforderungen erweitert: Tarif-Informationen, Barrierefreiheits-Daten, Carsharing- und Bikesharing-Bestände müssen ebenfalls über die NAPs zugänglich sein. Das ist 2026 noch nicht überall umgesetzt; die Bundesregierung hat im April 2026 einen Statusbericht an die EU-Kommission vorgelegt, der die Lücken transparent benennt.

Die regulatorische Wirkung ist beträchtlich. Sie zwingt die Verkehrsverbünde, ihre Daten zu öffnen, in standardisierten Formaten bereitzustellen und für externe Anwendungen zugänglich zu machen. Das ist der Hintergrund, vor dem die internationale App-Landschaft — DB Navigator, Öffi, Citymapper, Transit, Trafiklab — überhaupt mit deutschen Daten arbeiten kann.

Schweizer und österreichischer Vergleich

Die Schweiz hat eine eigene Tradition. Der OpenTransportData.swiss-Hub des Bundesamts für Verkehr (BAV) ist das schweizerische NAP-Pendant. Die SBB-CFF-FFS liefert ihre Daten in GTFS und NeTEx an OpenTransportData; die BLS, die regionalen Bus- und Tram-Betriebe sind ebenfalls angeschlossen. Die Schweiz nutzt das Taktfahrplan-Konzept — die Begegnung der Linien jede halbe Stunde an den Knotenpunkten Bern, Zürich, Olten, Luzern — als strukturelles Element der Fahrplangestaltung; das ist für die Datenmodellierung sekundär, aber für das Routing entscheidend, weil Anschlusssicherung in der Schweiz strikter gehandhabt wird als anderswo.

Österreich hat den mobilitaetsdaten.gv.at-Hub als NAP. Die ÖBB liefert ihre Fernverkehrs-Daten ein, die regionalen Verkehrsverbünde — VOR, VVT, VVV, OÖVV — ihre Daten. Das österreichische KlimaTicket Ö ist über NeTEx-Tarif-Strukturen abgebildet, was die Integration in Apps wie den DB Navigator (für grenzüberschreitende Routings) erlaubt.

Der DACH-Vergleich zeigt: Die EU-VO 2017/1926 hat in allen drei Ländern (Österreich vollständig, Deutschland vollständig, Schweiz partiell durch das bilaterale Abkommen) die Datenöffnung beschleunigt. Die Qualität der Daten variiert noch, die Datenmodelle konvergieren — überwiegend in Richtung NeTEx mit GTFS-Konversion für die App-Anbindung.

Was 2026 noch hakt

Drei Bruchstellen bestehen im Mai 2026.

Erstens, die Tarif-Abdeckung in NeTEx. Die Tarif-Daten der deutschen Verkehrsverbünde sind in NeTEx erfasst, aber nicht alle Verbünde liefern die Tarif-Informationen vollständig. Wer eine bundesweite Tarif-Auskunft bauen will (zum Beispiel um zu berechnen, was eine bestimmte Verbindung im Einzeltarif kostet — relevant für D-Ticket-Skeptiker und Gelegenheitsnutzer), trifft auf Lücken.

Zweitens, die Realtime-Qualität in ländlichen Räumen. Die SIRI-Datenabdeckung in den Großstadt-Verbünden ist exzellent, in den ländlichen Räumen häufig nur teilweise oder verzögert. Das ist nicht primär ein Daten-Standard-Problem, sondern eine Infrastruktur-Frage (Bordrechner, GPS-Versorgung, Mobilfunk-Anbindung).

Drittens, die GTFS-vs-NeTEx-Doppelpflege. Viele Verkehrsverbünde pflegen beide Formate parallel — NeTEx für die EU-konforme Datenbereitstellung, GTFS für die App-Anbindung. Das verdoppelt die Pflege-Aufwand und führt zu Inkonsistenzen zwischen den Formaten. Eine zentrale Konversion (NeTEx als Master, GTFS als Konvertierungs-Output) wäre die saubere Lösung, ist aber in den Verbund-Prozessen erst in Ansätzen umgesetzt.

Schluss: zwei Standards, ein Datenökosystem

Wer im Mai 2026 in Deutschland eine ÖPNV-App nutzt, profitiert von einer Datenarchitektur, deren Komplexität für den Endnutzer unsichtbar bleibt: GTFS als das leichte, breit verbreitete App-Format; NeTEx als das umfassende, EU-konforme Tarif- und Strukturformat; SIRI und GTFS-RT als die zwei Realtime-Pendants. DELFI als der nationale Aggregations-Hub, der die Daten der Länder zusammenführt. Die Mobilitätsdaten-Plattform des BMDV als der nationale Zugangspunkt nach EU-VO 2017/1926.

Die nächsten Jahre werden die Datenmodelle weiter konvergieren — NeTEx als Master, GTFS als Export. Die Realtime-Qualität wird steigen, getrieben durch die EU-Pflicht und die Verbraucher-Erwartung. Und die Tarif-Daten werden — voraussichtlich — die nächste große Baustelle sein, weil die Tarif-Strukturen der Verbünde 2026 noch zu wenig standardisiert in den NAPs landen.

Das ist die unscheinbare Infrastruktur, auf der die digitale ÖPNV-Nutzung steht. Sie funktioniert, wenn man weiß, dass sie aus zwei Standards besteht, die parallel laufen — und dass die Konvergenz keine Frage des Standards, sondern eine Frage des Datenmanagements ist.