Offene Verkehrsdaten in Österreich: Status der Verkehrsverbünde

Wer in Österreich eine Fahrplan-App, einen Routenplaner oder eine Verkehrsanalyse bauen möchte, braucht zuverlässige Rohdaten: Abfahrtszeiten, Linienverläufe, Haltestellen und idealerweise die aktuelle Lage im Netz. Lange Zeit lagen diese Daten verstreut bei einzelnen Verkehrsbetrieben, in uneinheitlichen Formaten und hinter individuellen Verträgen. Seit 2024 hat sich das grundlegend verschoben. Die Soll-Fahrplandaten praktisch aller großen Verkehrsverbünde sind heute offen verfügbar, gebündelt über eine zentrale Plattform und unter klaren Lizenzbedingungen.

Diese Seite ordnet ein, was „offen“ in diesem Zusammenhang konkret bedeutet, welcher Datenhalter was bereitstellt, und wo der Unterschied zwischen einem statischen Soll-Fahrplan und echten Echtzeitdaten liegt. Alle Angaben verweisen auf die offiziellen Bezugsquellen und tragen ein Stand-Datum.

Was offene Verkehrsdaten sind

Offene Verkehrsdaten sind maschinenlesbare Datensätze zum öffentlichen Verkehr, die unter einer freien Lizenz und über eine dokumentierte Schnittstelle bereitstehen. Der Begriff umfasst drei Bedingungen, die zusammengehören: ein offenes Format, das jede Software lesen kann, eine Lizenz, die Weiterverwendung erlaubt, und einen Zugang ohne individuelle Vertragsverhandlung. Fehlt eine dieser drei, sind die Daten zwar vielleicht digital vorhanden, aber nicht offen.

Der weltweite Standard für Soll-Fahrpläne heißt GTFS (General Transit Feed Specification). Ein GTFS-Datensatz ist eine ZIP-Datei aus mehreren CSV-Tabellen: Haltestellen mit Koordinaten, Linien, Fahrten, Abfahrtszeiten und Kalender für Betriebstage. Weil das Format einfach und stabil ist, lesen es nahezu alle Routing-Engines und Karten-Dienste direkt ein.

Für die aktuelle Lage im Netz gibt es eine Ergänzung namens GTFS-RT (Realtime). Sie liefert Verspätungen, Ausfälle und Fahrzeugpositionen als laufend aktualisierten Datenstrom und setzt einen passenden Soll-Fahrplan voraus. Daneben existiert in Europa die NeTEx/SIRI-Familie, die deutlich umfangreicher ist und etwa Tarife und Anschlussbeziehungen abbilden kann. In der Praxis bleibt GTFS für Entwickler das gängigste Einstiegsformat, weil es schlank ist und am breitesten unterstützt wird.

Der Unterschied zwischen „offen“ und „nur online verfügbar“ entscheidet in der Praxis oft über ein Projekt. Eine PDF-Fahrplantabelle auf einer Betreiber-Website ist digital, aber nicht offen: Sie lässt sich nicht zuverlässig automatisiert auslesen und steht unter keiner klaren Weiterverwendungslizenz. Ein GTFS-Datensatz unter CC BY dagegen erfüllt alle drei Bedingungen und kann ohne Rückfrage in eine Anwendung übernommen werden. Genau diese Unterscheidung war der Kern der Open-Data-Debatte der vergangenen Jahre.

Wo die Daten zentral liegen

Das Herzstück der offenen ÖV-Daten in Österreich ist die Plattform der Mobilitätsverbünde Österreich (MVO) unter data.mobilitaetsverbuende.at. Dort bündeln die sieben regionalen Verkehrsverbünde ihre Soll-Fahrplandaten an einer Stelle. Statt sich an jeden Verbund einzeln zu wenden, lädt man die GTFS-Datensätze für das gewünschte Gebiet oder österreichweit herunter. Der Zugang ist kostenlos, erfordert aber eine einmalige Registrierung, die vor allem der Nutzungsstatistik und der Lizenz-Zustimmung dient.

Die Bahn liefert ihre Daten zusätzlich über ein eigenes Portal. Auf data.oebb.at veröffentlicht die ÖBB den österreichweiten Bahnfahrplan als GTFS, der jeweils zum Fahrplanwechsel im Dezember aktualisiert wird. Für den Wiener Stadtverkehr betreiben die Wiener Linien ihr eigenes Open-Data-Angebot, das als einziger großer Datensatz auch offene Echtzeitdaten enthält.

Diese Dreiteilung ist wichtig zu verstehen: Die MVO-Plattform deckt die Verbünde ab, ÖBB und Wiener Linien ergänzen sie um eigene Quellen. Für ein Projekt, das ganz Österreich abbilden soll, kombiniert man in der Regel den MVO-Gesamtdatensatz mit dem ÖBB-Bahnfahrplan.

Vollständig deckungsgleich mit dem realen Angebot ist die offene Datenlage damit aber nicht in jedem Detail. Einzelne kommunale Betriebe, touristische Sonderverkehre oder kurzfristige Schienenersatzverkehre tauchen nicht immer im offenen GTFS auf, weil sie organisatorisch außerhalb der Verbund-Datenflüsse liegen. Für die allermeisten Anwendungsfälle ist die Abdeckung dennoch hoch, und sie wächst mit jeder neuen Datenlieferung. Wer eine spezielle Region oder einen Nischenverkehr braucht, prüft am besten den konkreten Datensatz, statt von Vollständigkeit auszugehen.

Status der Verkehrsverbünde im Überblick

Bei den Soll-Fahrplänen ist die Lage heute eindeutig: Alle großen Datenhalter stellen GTFS offen bereit. Bei der Echtzeit klafft dagegen weiterhin eine Lücke. Offene GTFS-RT-Feeds liefern bislang nur die Wiener Linien und die Linz AG; bei den übrigen Verbünden ist Echtzeit entweder nur in den eigenen Apps sichtbar oder gar nicht offen abrufbar.

Diese Grafik einbetten

<a href=”https://offene-oeffis.at/offene-verkehrsdaten/”><img src=”https://offene-oeffis.at/wp-content/themes/offene-oeffis/assets/images/gtfs-status-2026.svg” alt=”Status der offenen Verkehrsdaten in Österreich 2026 – offene-oeffis.at” width=”760″></a><br /> <p>Quelle: <a href=”https://offene-oeffis.at/offene-verkehrsdaten/”>Offene Öffis – Status der Verkehrsverbünde</a></p>

Eine tagesaktuelle, filter- und sortierbare Fassung dieser Matrix steht auf der Startseite im Bereich Daten-Status. Sie führt zu jedem Eintrag die Lizenz und das jeweilige Stand-Datum.

GTFS und GTFS-RT: der Unterschied zählt

Der häufigste Stolperstein bei ÖV-Projekten ist die Verwechslung von Soll-Fahrplan und Echtzeit. Ein GTFS-Datensatz beschreibt den geplanten Betrieb: Linie X fährt laut Fahrplan um 8:14 Uhr ab. Ob dieser Zug tatsächlich pünktlich, verspätet oder ausgefallen ist, steht dort nicht. Genau diese Lücke füllt GTFS-RT mit drei Nachrichtentypen: Trip Updates für Verspätungen und Ausfälle, Vehicle Positions für die Fahrzeugortung und Service Alerts für Störungsmeldungen.

Für eine Anwendung, die nur Verbindungen ausrechnet oder Linienpläne anzeigt, genügt der Soll-Fahrplan vollständig. Sobald eine App jedoch eine verlässliche Abfahrtstafel mit Live-Minuten verspricht, braucht sie GTFS-RT. Und hier ist die Auswahl in Österreich klein: Außerhalb von Wien und Linz lässt sich eine offene, flächendeckende Echtzeit-Abdeckung derzeit nicht realisieren. Wer das übersieht, baut ein Produkt, das in der Demo überzeugt, im Alltag aber an falschen Live-Daten scheitert.

Technisch unterscheiden sich beide Welten auch im Umgang: Den Soll-Fahrplan lädt man als Paket herunter und liest ihn einmal ein. Den Echtzeit-Feed fragt eine Anwendung dagegen in kurzen Abständen wiederholt ab, oft im Bereich von etwa einer halben bis einer Minute, und schreibt die Abweichungen auf den Soll-Fahrplan. Diese laufende Abfrage kostet Rechenzeit und erfordert eine robuste Fehlerbehandlung, falls der Feed kurzzeitig nicht antwortet. Ein sauberer Soll-Fahrplan als Grundlage bleibt damit auch für Echtzeit-Anwendungen unverzichtbar.

Realistisch ist deshalb ein gestaffelter Ansatz: ein bundesweiter Routenplaner auf GTFS-Basis, ergänzt um echte Echtzeit dort, wo Feeds existieren. Mehrere der verfügbaren Apps und Routenplaner arbeiten genau nach diesem Muster.

Lizenzen und Nutzungsbedingungen

Offene Daten sind nicht gemeinfrei. Sie stehen unter einer Lizenz, die Weiterverwendung erlaubt, dafür aber Bedingungen stellt — meist eine Namensnennung. Bei den österreichischen ÖV-Daten ist die Lage überschaubar:

• ÖBB und Wiener Linien veröffentlichen unter Creative Commons Namensnennung 4.0 (CC BY 4.0). Erlaubt ist nahezu jede Nutzung, auch kommerziell, solange die Quelle korrekt genannt wird.
• Die Verbünde über die MVO-Plattform stehen unter freien Nutzungsbedingungen, die kommerzielle Verwendung einschließen; die jeweils gültige Fassung wird bei der Registrierung bestätigt.

Die Namensnennung ist keine Formalie. Wer einen Datensatz weiterverarbeitet, muss den Urheber an geeigneter Stelle ausweisen, etwa im Impressum oder einem Datenhinweis der App. Bei kombinierten Datensätzen — etwa MVO plus ÖBB — werden beide Quellen genannt. Das klingt aufwendiger, als es ist: Ein kurzer Hinweis pro Datenquelle erfüllt die Bedingung. Wichtig ist nur, die konkrete Lizenz pro Feed zu prüfen, weil sich Bedingungen mit neuen Datenständen ändern können.

In der Praxis sieht ein korrekter Hinweis schlicht aus. Eine Formulierung wie „Fahrplandaten: Mobilitätsverbünde Österreich; Bahnfahrplan: ÖBB (CC BY 4.0)“ reicht aus, sofern sie für Nutzer auffindbar ist. Entscheidend ist, dass jede genutzte Quelle erkennbar bleibt und der Lizenztyp stimmt. Wer Daten zusätzlich verändert oder anreichert, weist diese Bearbeitung am besten ebenfalls aus, um die Herkunft der Originaldaten von eigenen Ergänzungen zu trennen.

Datenformate und Schnittstellen

In der Praxis begegnen Entwicklern in Österreich vor allem diese Formate:

• GTFS Static — die ZIP-Datei mit dem Soll-Fahrplan. Sie wird periodisch neu veröffentlicht und als Ganzes heruntergeladen. Für die meisten Projekte ist das der Ausgangspunkt.
• GTFS-RT — ein Echtzeit-Datenstrom im Protocol-Buffers-Format, der laufend abgefragt wird. Er ergänzt einen vorhandenen Soll-Fahrplan und ist ohne diesen nicht sinnvoll nutzbar.
• OJP (Open Journey Planner) — eine API-Schnittstelle für Verbindungsabfragen, die einzelne Betreiber zusätzlich anbieten. Statt Rohdaten herunterzuladen, stellt man hier konkrete Anfragen.

Ein GTFS-Static-Paket besteht im Kern aus einer Handvoll Textdateien mit fester Bedeutung. Wer einmal hineingeschaut hat, versteht das Format schnell:

Datei	Inhalt
stops.txt	Haltestellen mit Name und Koordinaten
routes.txt	Linien mit Typ (Bus, Tram, Bahn) und Bezeichnung
trips.txt	einzelne Fahrten je Linie und Richtung
stop_times.txt	Abfahrts- und Ankunftszeiten je Fahrt und Halt
calendar.txt	Betriebstage und Geltungszeiträume

Vor dem produktiven Einsatz empfiehlt sich ein Validierungslauf, etwa mit dem quelloffenen GTFS-Validator, der Strukturfehler und Inkonsistenzen meldet. So fallen fehlerhafte Zeitangaben oder verwaiste Haltestellen auf, bevor sie in der Anwendung landen.

Auf europäischer Ebene kommt die NeTEx/SIRI-Familie hinzu, die über die nationalen Zugangspunkte (siehe unten) bereitsteht. Sie ist mächtiger, aber auch deutlich komplexer in der Verarbeitung. Für einen schnellen Einstieg bleibt GTFS die pragmatische Wahl; NeTEx lohnt sich, wenn Tarif- oder Anschlussinformationen exakt abgebildet werden müssen. Werkzeuge wie OpenTripPlanner nehmen GTFS und GTFS-RT direkt entgegen und sind ein guter Startpunkt für eigene Routing-Dienste.

So greift man praktisch auf die Daten zu

Der Weg von der Registrierung bis zum ersten eigenen Routing dauert weniger als einen Nachmittag. In Kurzform:

1. Registrieren auf der MVO-Plattform und gegebenenfalls bei data.oebb.at. Beide Konten sind kostenlos.
2. Datensatz wählen: das passende Verbundgebiet oder den österreichweiten GTFS-Gesamtdatensatz, dazu bei Bedarf den ÖBB-Bahnfahrplan.
3. Lizenz prüfen und die Namensnennung notieren, die später in der Anwendung erscheinen muss.
4. GTFS einlesen in eine Routing-Engine wie OpenTripPlanner oder in eine eigene Datenbank. Die CSV-Struktur ist dokumentiert und stabil.
5. Optional Echtzeit anbinden über GTFS-RT, sofern für das Gebiet ein offener Feed existiert — derzeit Wien und Linz.
6. Aktualisierung einplanen: Soll-Fahrpläne ändern sich vor allem zum Dezember-Fahrplanwechsel, teils unterjährig. Ein regelmäßiger Abgleich hält die Anwendung korrekt.

Wer keine eigene Infrastruktur betreiben will, findet im Katalog der Apps und Bibliotheken fertige Werkzeuge, die auf denselben offenen Daten aufsetzen.

Häufige Fehler beim Einsatz offener ÖV-Daten

Aus wiederkehrenden Projekterfahrungen lassen sich einige Stolpersteine benennen, die sich leicht vermeiden lassen:

• Echtzeit vortäuschen. Eine Abfahrtstafel ohne offenen GTFS-RT-Feed kann nur Soll-Zeiten zeigen. Sie als „live“ zu kennzeichnen, führt Nutzer in die Irre, sobald ein Zug verspätet ist. Außerhalb von Wien und Linz ist offene Echtzeit derzeit schlicht nicht verfügbar.
• Datenstand einfrieren. Wer einen GTFS-Datensatz einmalig importiert und nie aktualisiert, zeigt nach dem nächsten Fahrplanwechsel falsche Zeiten. Ein automatischer Abgleich gehört von Anfang an eingeplant.
• Lizenzhinweis vergessen. Die Namensnennung ist Pflicht, nicht Kür. Sie fehlt erfahrungsgemäß am häufigsten — und ist mit einem kurzen Datenhinweis am einfachsten zu erfüllen.
• Validierung überspringen. Roh übernommene Daten enthalten gelegentlich Inkonsistenzen. Ein Validierungslauf vor dem Produktivbetrieb erspart schwer auffindbare Fehler im Routing.

Vom Datensilo zum offenen Netz

Dass offene ÖV-Daten heute selbstverständlich wirken, ist jung. Um 2013 stellten in Österreich praktisch nur Wien und Linz ihre Fahrpläne offen bereit; der Rest lag hinter Einzelverträgen oder gar nicht digital vor. Die Forderung nach offenen Mobilitätsdaten kam damals stark aus der Zivilgesellschaft und der Open-Data-Bewegung, die den volkswirtschaftlichen Wert frei nutzbarer Verkehrsdaten betonte.

Der entscheidende Schritt kam 2024 mit der zentralen Bündelung über die Mobilitätsverbünde Österreich. Seither liegen die Soll-Fahrpläne aller Verbünde an einer Stelle und unter einheitlichen Bedingungen. Die offene Echtzeit ist der nächste, noch unfertige Abschnitt dieses Wegs. Die längere Geschichte von 2013 bis 2026 zeichnet diese Entwicklung mit ihren Meilensteinen nach.

Wie offen sind Österreichs ÖV-Daten wirklich?

Eine nüchterne Bilanz zum Stand Juni 2026: Bei den statischen Soll-Fahrplänen ist die Öffnung abgeschlossen — alle zehn großen Datenhalter stellen GTFS frei und unter einheitlichen Bedingungen bereit. Bei der offenen Echtzeit sieht es anders aus. Offene GTFS-RT-Feeds liefern nur die Wiener Linien und die Linz AG, also zwei von zehn. Die statische Offenheit liegt damit faktisch bei hundert Prozent, die offene Echtzeit-Abdeckung bei rund zwanzig.

Diese Differenz ist der eigentliche Gradmesser. Solange Verspätungen, Ausfälle und Fahrzeugpositionen außerhalb von Wien und Linz nicht offen abrufbar sind, lässt sich eine verlässliche, anbieterunabhängige Live-Auskunft für ganz Österreich nicht bauen — der wirtschaftliche und gesellschaftliche Nutzen offener Mobilitätsdaten entsteht aber gerade dort, wo Anwendungen die tatsächliche Lage im Netz abbilden. Der nächste sichtbare Fortschritt wäre deshalb nicht ein weiterer Soll-Fahrplan, sondern der erste offene Echtzeit-Feed eines Flächen-Verbunds außerhalb der beiden Ballungsräume.

Der europäische Rahmen

Österreichs Öffnung steht nicht für sich, sondern folgt einer EU-Vorgabe. Die Delegierte Verordnung (EU) 2017/1926 verpflichtet die Mitgliedstaaten, statische und — wo vorhanden — dynamische Reise- und Verkehrsdaten über einen nationalen Zugangspunkt (National Access Point, NAP) bereitzustellen. Ziel ist ein EU-weiter Rahmen für multimodale Reiseinformationsdienste, der Fahrpläne, Tarife und Echtzeitlage über Länder- und Verkehrsmittelgrenzen hinweg zusammenführt.

Für Österreich bedeutet das: Die nationale Bereitstellung ist nicht nur ein freiwilliges Open-Data-Projekt, sondern auch Umsetzung verbindlicher europäischer Vorgaben. Das erklärt die Standardisierung auf NeTEx/SIRI auf EU-Ebene und stützt die Erwartung, dass die offene Echtzeit-Abdeckung mittelfristig wächst.

Der nationale Zugangspunkt ist dabei kein zweiter, konkurrierender Datentopf, sondern die formale Klammer, die Österreichs Quellen für die EU sichtbar macht. Praktisch greifen Entwickler weiterhin auf die bekannten Plattformen — MVO, ÖBB, Wiener Linien — zu; der Zugangspunkt verweist auf genau diese Bestände und beschreibt sie nach einheitlichem Muster. Wer grenzüberschreitende Anwendungen plant, findet über die nationalen Zugangspunkte der Nachbarländer vergleichbar strukturierte Daten und kann so etwa eine Verbindung von Salzburg nach München aus zwei nationalen Beständen zusammenführen.

Häufige Fragen

Einen verständlichen Einstieg in das österreichische ÖV-System insgesamt — Verbünde, Netze und Tarife — bietet die Übersicht zu öffentlichem Verkehr in Österreich.