# GTFS, GTFS-RT und GBFS: Was sind die Unterschiede?

> Vergleichen Sie GTFS, GTFS-RT und GBFS, um Ihre Mobilitätsdaten auszuwählen: geplante Fahrpläne, aktuelle Informationen, Stationen und geteilte Fahrzeuge.

Source: https://www.roote.ai/de/guides/gtfs-gtfs-rt-und-gbfs-was-sind-die-unterschiede/
Language: de
Author: ROOTE

GTFS Schedule beschreibt das geplante Verkehrsangebot. GTFS Realtime, oft GTFS-RT genannt, übermittelt aktualisierte Betriebsinformationen. GBFS beschreibt Sharing-Mobilitätsdienste, insbesondere deren Stationen und verfügbare Fahrzeuge gemäß veröffentlichter Feeds. Wählen Sie das Format basierend auf der Fragestellung, die Ihre Anwendung lösen soll.

Diese Formate organisieren die Daten; sie garantieren weder deren Verfügbarkeit überall noch die Qualität jedes Feeds.

## GTFS zur Darstellung des geplanten Angebots

Ein GTFS Schedule-Datensatz besteht aus tabellarischen Dateien, die unter anderem Betreiber, Haltestellen, Linien, Fahrten und deren Abfahrten beschreiben. Die Kalender geben die relevanten Tage an. Die Dateien sind über Identifikatoren verbunden. [GTFS Schedule Referenz](https://gtfs.org/documentation/schedule/reference/).

Damit lassen sich Fragen beantworten wie „Wo befindet sich diese Haltestelle?“ oder „Welche Abfahrt ist für diesen Dienst geplant?“. Um einen Fahrplan zu nutzen, müssen Kalender und die Beziehungen zwischen den Dateien interpretiert werden.

Allein die Liste von Haltestellen zu lesen reicht also nicht, um Abfahrten zu rekonstruieren. Umgekehrt kann eine Haltestellenposition nützlich sein, auch ohne Fahrzeiten anzuzeigen.

## GTFS-RT zur Aktualisierung von Betriebsinformationen

GTFS Realtime kann Fahrtenupdates, Fahrzeugpositionen und Alerts liefern. Fahrtenupdates betreffen insbesondere Abfahrten und Dienständerungen. Die Feeds nutzen Protocol Buffers, ein strukturiertes Serialisierungsformat. [Einführung GTFS Realtime](https://gtfs.org/documentation/realtime/reference/).

Ein Anbieter kann einzelne Kategorien veröffentlichen, ohne alle anderen zu liefern. Die Existenz eines Positionsfeeds garantiert keine Schätzungen für alle Haltestellen.

Unterscheiden Sie in der Schnittstelle die geplante Abfahrt von der aktualisierten Schätzung. Unser Leitfaden [theoretische Fahrpläne und Echtzeit](https://www.roote.ai/de/guides/fahrplaene-fuer-busse-differenz-zwischen-theoretischen-und-echtzeitinformationen/) erklärt diesen Unterschied aus Nutzersicht.

## GBFS für Sharing-Mobilität

GBFS verwendet JSON-Feeds zur Beschreibung eines Sharing-Mobilitätsdienstes. Je nach System und Version können sie Stationen, deren Status, Fahrzeuge und weitere Merkmale des Dienstes informieren. Die Dokumentation unterscheidet insbesondere zwischen Stationsinformationen und Verfügbarkeitsstatus. [GBFS Dokumentation](https://github.com/MobilityData/gbfs/blob/v2.3/gbfs.md).

Trennen Sie in Ihrer Anwendung relativ stabile Standorte von sich schnell ändernden Zuständen. Bewahren Sie bei der Interpretation die Formatversion und die relevante Zeitstempelung auf.

Ein Verfügbarkeitsfeed ist keine Buchungs- oder Entsperrungs-API. Er unterstützt die Entdeckung des Angebots; der Vermietungsprozess gehört zum jeweiligen Dienst.

## Vergleichen nach Anwendungsfall

| Bedarf | Zu prüfendes Format |
| --- | --- |
| Haltestellen und geplante Linien beschreiben | GTFS Schedule |
| Geplante Abfahrten und Betriebstage interpretieren | GTFS Schedule |
| Abfahrten aktualisieren oder Betriebsinformationen erhalten | GTFS-RT, je nach veröffentlichten Feeds |
| Stationen oder Sharing-Fahrzeuge lokalisieren | GBFS, je nach veröffentlichten Daten |

Beispielkonzept: Eine Karte zeigt Straßenbahn-Haltestellen und Fahrradstationen. Sie nutzt strukturierte Daten für Standorte und aktuelle Zustände zur Fahrradverfügbarkeit. Beide Ebenen haben unterschiedliche Anforderungen an Cache und Aktualisierung.

## Grenzen jeder Quelle beachten

Prüfen Sie Versionen, optionale Felder, Abdeckung und Nutzungsrechte. Eine ID ist nur im Kontext sinnvoll: Zwei Anbieter können identische Strings für verschiedene Entitäten verwenden.

Berücksichtigen Sie auch fehlende oder veraltete Daten. Eine leere Liste aus einem nicht verfügbaren Feed darf nicht als fehlender Dienst interpretiert werden. Vermeiden Sie, unbekannte Informationen stillschweigend mit Null zu ersetzen.

## Feeds direkt oder über eine API nutzen

Direkte Integration macht Sie verantwortlich für Sammlung, Validierung und Interpretation der Quellen. Eine API kann ein gemeinsames Contract System bieten, doch prüfen Sie immer deren Abdeckung, Warnungen und Bedingungen.

Für einen ersten ROOTE-Anwendungsfall lesen Sie bitte [wie Haltestellen in der Nähe mit einer API gesucht werden](https://www.roote.ai/de/guides/wie-sucht-man-in-der-naehe-liegende-verkehrshaltestellen-mit-einer-api/). Starten Sie vom Bedarf Ihrer Schnittstelle und prüfen Sie dann die tatsächlich verfügbaren Felder.

## Auszüge lesen und eine Architektur auswählen

Im GTFS Schedule verknüpft ein Auszug aus stop_times.txt eine Fahrt, eine Haltestelle und eine geplante Durchfahrt. Das untenstehende verkürzte Beispiel dient der Veranschaulichung: Es stellt kein vollständiges GTFS-Dataset dar und seine Identifikatoren müssen mit trips.txt, stops.txt und den Kalendern verknüpft werden.

Bei GTFS Realtime suchen Sie die relevante Einheit: Ein TripUpdate kann eine Durchfahrt aktualisieren, eine VehiclePosition beschreibt eine Position und eine Alert übermittelt eine Serviceinformation. Eine Fahrzeugposition ist nicht automatisch eine Ankunftsschätzung. Das übertragene Format ist Protocol Buffers; eine diagnostische JSON-Darstellung ist nicht der Referenz-Binärstream.

Im GBFS beschreibt station_information die Stationen, während station_status deren veröffentlichte Zustände angibt. Die Namen einzelner Zähler und die verfügbaren Dateien ändern sich je nach Version. Der untenstehende JSON-Auszug zeigt GBFS 2.3 mit den Feldern num_bikes_available und num_docks_available; prüfen Sie die Version, bevor Sie ein Beispiel übernehmen.

Eine Standortkarte kann mit den strukturellen Daten beginnen. Ein Bildschirm für kommende Abfahrten benötigt daraufhin entsprechende Aktualisierungen und einen explizit geplanten Fallback. Ein Bildschirm für verfügbare Fahrräder muss Zähler, Mietbedingungen und zeitliche Gültigkeit verwalten. Diese drei Bildschirme teilen nicht automatisch dieselbe Cache-Strategie.

```
# Extrait pédagogique de stop_times.txt
trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip_demo,08:10:00,08:10:00,stop_demo,1

# Extrait pédagogique de station_status en GBFS 2.3
{
  "station_id": "station_demo",
  "num_bikes_available": 3,
  "num_docks_available": 7,
  "is_installed": true,
  "is_renting": true,
  "is_returning": true,
  "last_reported": 1720000000
}
```

[Verfügbarkeiten von Fahrrädern und ihre Aktualität formatieren](https://www.roote.ai/de/guides/fahrradverfugbarkeit-zeitnah-in-app-zeigen/)

[Wählen Sie eine API oder ein MCP für Ihr Produkt](https://www.roote.ai/de/guides/api-oder-mcp-mobilitaetsdaten-integration-wahl/)

## Häufige Fragen

### Enthält GTFS automatisch Echtzeitdaten?

Nein. GTFS Schedule stellt das geplante Angebot dar; aktuelle Informationen kommen aus anderen Feeds, speziell GTFS-RT.

### Ermöglicht GBFS das Entsperren eines Fahrrads?

Es beschreibt den Dienst und dessen öffentliche Daten. Die Vermietung erfolgt über vom Betreiber bereitgestellte Funktionen.

### Garantiert ein Standardformat vollständige Abdeckung?

Nein. Das Format definiert eine Struktur; Abdeckung und veröffentlichte Informationen hängen von den Quellen ab.