Offene Bahndaten nutzen: Datenquellen für eigene Projekte

Aktualisiert: August 2026 – Irgendwann reicht die App nicht mehr: Du willst eine eigene Abfahrtstafel für den Flurmonitor, eine Auswertung, welche Baureihen an deinem Hausbahnhof durchkommen, oder eine Karte mit deinen Lieblingsstrecken. Dieser Guide zeigt, welche offenen Bahndaten es gibt, wie aktuell und wie zugänglich sie sind – und wie du aus einem Download in kurzer Zeit etwas Eigenes baust.

Open Data Bahn: Welche Daten es überhaupt gibt

Offene Bahndaten zerfallen in drei Kategorien: Solldaten (der geplante Fahrplan), Echtzeitdaten (die Abweichung vom Plan) und Infrastrukturdaten (Strecken, Betriebsstellen, Bahnhöfe). Für Fahrpläne hat sich GTFS als Austauschformat durchgesetzt, für Echtzeit GTFS-Realtime und SIRI, für europäische Standardisierung NeTEx.

Der wichtigste Einstieg ist ein nationaler Zugangspunkt, über den Mobilitätsdaten in Deutschland zentral auffindbar gemacht werden; ergänzend betreiben viele Verbünde und Verkehrsunternehmen eigene Datenseiten. Die Schnittstellenstandards dahinter kommen im deutschsprachigen Raum überwiegend vom Verband Deutscher Verkehrsunternehmen. Welche Datensätze dort aktuell liegen und unter welcher Lizenz, legen die Anbieter selbst fest – und ändern es gelegentlich. Wie unterschiedlich die Verbünde damit umgehen, zeigt der Echtzeit-Check der Verkehrsverbünde.

Die Datenquellen im Überblick

Die folgende Tabelle ordnet die gängigen Quellentypen nach dem ein, was für ein Projekt wirklich zählt: Format, Aktualität, Zugangshürde und Lizenzlage. Konkrete Lizenzen stehen immer am Datensatz selbst – die Spalte beschreibt nur, was typisch ist.

Quellentyp	Format	Typische Aktualität	Zugangshürde	Lizenzlage
Bundesweiter Solldatensatz	GTFS, teils NeTEx	Aktualisierung in Tages- bis Wochenrhythmus	Download, meist ohne Anmeldung	offene Lizenz, in der Regel mit Namensnennung
Verbund-Solldaten	GTFS	wie oben, teils feiner gepflegt	Datenseite des Verbunds	je Verbund unterschiedlich
Echtzeit-Feeds	GTFS-Realtime, SIRI	Sekunden bis wenige Minuten	oft Registrierung nötig	häufig mit Nutzungsbedingungen
Betreiber-Schnittstellen	JSON, XML	nahe am Betriebsleitsystem	Anmeldung, teils Kontingente	anbieterspezifisch
Infrastruktur aus OpenStreetMap	OSM-Rohdaten, Vektorkacheln	laufend, community-gepflegt	frei, aber Aufbereitung nötig	offene Datenlizenz mit Share-alike
Bahnhofs- und Stationsdaten	CSV, JSON	selten, planungsgetrieben	meist offen	offene Lizenz, Angaben prüfen
Fahrzeug- und Sichtungswissen	Listen, Foren, Apps	laufend, aber unvollständig	frei lesbar, kaum maschinenlesbar	urheberrechtlich geschützt, Nutzung klären

Die letzte Zeile ist die entscheidende Lücke: Alles, was mit konkreten Fahrzeugen zu tun hat, fehlt in den offiziellen Datenströmen komplett. Genau deshalb existieren Communitys – nachzulesen im Überblick zu Live-Sichtungen im Trainspotting.

GTFS verstehen: die fünf Dateien, die zählen

Ein GTFS-Archiv enthält meist ein Dutzend Dateien, aber für den Anfang brauchst du nur fünf. Sie hängen über IDs zusammen wie Tabellen in einer Datenbank.

• stops.txt – alle Haltestellen mit ID, Name und Koordinaten. Dein Einstiegspunkt, wenn du von einem Ort aus denkst.
• routes.txt – die Linien mit Kurzname, Langname und Verkehrsmitteltyp. Hier trennst du Bahn von Bus und Tram.
• trips.txt – die einzelnen Fahrten einer Linie, jeweils mit Richtung und Verweis auf einen Kalendereintrag.
• stop_times.txt – die mit Abstand größte Datei: jede Ankunft und Abfahrt jeder Fahrt an jeder Haltestelle. Hier steckt die eigentliche Information.
• calendar.txt und calendar_dates.txt – an welchen Wochentagen eine Fahrt verkehrt und welche Ausnahmen gelten. Ohne diese Dateien baust du versehentlich eine Tafel, die auch sonntags Schulbusse zeigt.

Vom Download zur eigenen Abfahrtstafel

Der schnellste Weg zu einem sichtbaren Ergebnis führt über sechs Schritte. Jeder davon ist für sich klein – die Kunst liegt darin, sie in dieser Reihenfolge zu gehen und nicht mit Echtzeit anzufangen.

Echtzeitdaten anbinden: worauf es ankommt

Echtzeit-Feeds sind kein eigenständiger Fahrplan, sondern eine Korrekturschicht. GTFS-Realtime kennt drei Meldungstypen, und die Unterschiede sind praktisch relevant:

• TripUpdate – Verspätungen, geänderte Halte und Fahrtausfälle. Das ist der Typ, den du für eine Abfahrtstafel brauchst.
• VehiclePosition – die aktuelle Fahrzeugposition. Nur nutzbar, wenn der Anbieter sie freigibt; bei Bahnverkehren deutlich seltener als bei Bussen.
• Alert – Störungs- und Umleitungsmeldungen als Freitext, verknüpft mit betroffenen Linien oder Stationen.

Zwei Fallstricke tauchen bei fast jedem Projekt auf. Erstens: IDs müssen zusammenpassen. Ein Echtzeit-Feed referenziert Fahrten eines bestimmten Solldatensatzes. Mischst du Feed und Fahrplan aus unterschiedlichen Quellen, findest du keine Treffer. Zweitens: Abfragefrequenz respektieren. Ein Feed, der alle 30 Sekunden neu erzeugt wird, muss nicht öfter abgefragt werden – häufigere Zugriffe bringen keine besseren Daten, kosten aber Kontingent.

Wie stark sich Datenqualität und Anzeige unterscheiden können, merkst du sofort im Vergleich mit fertigen Werkzeugen. Der Vergleich der Zugradar-Tools zeigt, welche Aufbereitung andere aus denselben Rohdaten machen, und die Anleitung zum Verfolgen von DB-Zugnummern erklärt, wie du eine einzelne Fahrt sauber identifizierst.

Infrastrukturdaten für Fotostandorte und Karten

Für Spotter ist oft nicht der Fahrplan das Interessante, sondern die Strecke. Hier liefern Community-Projekte auf Basis von OpenStreetMap die praktischste Grundlage: Gleisverläufe, Elektrifizierung, Streckennummern, Betriebsstellen und teilweise Signale sind dort kartiert und lassen sich als Kartenebene einbinden.

Drei Hinweise dazu:

• Vollständigkeit ist nicht garantiert. Community-Karten sind gut, aber nicht amtlich. Für die Standortplanung reicht das, für betriebliche Aussagen nicht.
• Share-alike beachten. Offene Kartendaten stehen häufig unter Lizenzen, die abgeleitete Datenbanken wieder öffnen müssen. Für eine Karte auf deiner Website ist meist nur der Quellenhinweis nötig; wer Daten weiterverarbeitet, sollte genauer hinsehen.
• Zugänglichkeit prüfen. Eine Karte zeigt Gleise, aber keine Betretungsrechte. Gleisbereiche und Betriebsanlagen sind grundsätzlich tabu – jeder Standort muss von öffentlich zugänglichem Grund erreichbar sein.

Wer die eigenen Daten samt Karte veröffentlichen will, findet die technische Umsetzung im Guide zum Aufbau einer eigenen Spotter-Website. Und wenn es um historische Aufnahmen statt um Live-Daten geht, lohnt der Blick ins Eisenbahnarchiv mit historischen Eisenbahnfotos.

Häufige Fehler bei eigenen Datenprojekten

• Mit Echtzeit anfangen. Ohne funktionierende Solldatenbasis hat der Realtime-Feed nichts, worauf er verweisen könnte. Erst Fahrplan, dann Korrektur.
• Verkehrstage ignorieren. Eine Tafel ohne Kalenderprüfung zeigt Fahrten, die es an diesem Tag gar nicht gibt – der häufigste Anfängerfehler überhaupt.
• Zeitzonen und Betriebstage verwechseln. GTFS erlaubt Zeiten über 24 Uhr hinaus, etwa 25:10 für eine Fahrt nach Mitternacht. Wer das naiv parst, verliert den Nachtverkehr.
• Lizenzhinweise weglassen. Namensnennung ist bei offenen Daten die Regel, nicht die Ausnahme. Ein Satz im Impressum kostet nichts.
• Aus Fahrtdaten auf Fahrzeuge schließen. Eine Zugnummer sagt etwas über Gattung und Laufweg, aber nichts über die eingesetzte Baureihe. Wie viel eine Nummer tatsächlich verrät, erklärt der Beitrag zum Entschlüsseln von Zugnummern.
• Tunnel- und Sonderverkehre übersehen. Für unterirdische Strecken gelten eigene Ortungsprinzipien, wie der Beitrag zum U-Bahn-Tracking im Tunnel zeigt – Fahrzeugpositionen fehlen dort besonders häufig.

Fazit

Offene Bahndaten sind zugänglicher, als die meisten vermuten: Ein GTFS-Archiv und ein Tabellenprogramm reichen für das erste sichtbare Ergebnis, und der Sprung zu Echtzeit ist danach überschaubar. Der eigentliche Aufwand steckt nicht im Download, sondern in Sorgfalt – bei Verkehrstagen, IDs und Lizenzen. Und eine Grenze bleibt unabhängig vom technischen Können bestehen: Welches Fahrzeug wirklich fährt, steht in keinem Feed.