GTFS

GTFS ( General Transit Feed Specification ) ist eine Spezifikation für allgemeine ÖPNV-Daten, die ein einheitliches Datenformat für Fahrpläne und zugehörige geografische Informationen definiert. ^{[ 1 ]} GTFS enthält ausschließlich statische oder planmäßige Informationen über ÖPNV-Dienste und wird daher auch als GTFS Static oder GTFS Schedule bezeichnet , um es von der GTFS Realtime- Erweiterung zu unterscheiden, die die Weitergabe von Echtzeitinformationen zum Status von Diensten regelt. ^{[ 1 ] [ 2 ]}

Was später zu GTFS werden sollte, begann 2005 als Nebenprojekt des Google- Mitarbeiters Chris Harrelson. Dieser experimentierte mit Möglichkeiten, ÖPNV-Daten in Google Maps zu integrieren , als er von Tim und Bibiana McHugh, einem Ehepaar und IT-Managern bei TriMet , dem Verkehrsbetrieb von Portland , Oregon, hörte. ^{[ 3 ]} McHugh war frustriert darüber, in unbekannten Städten keine Wegbeschreibungen für den öffentlichen Nahverkehr zu finden, während gängige Kartendienste damals bereits benutzerfreundliche Autorouten anboten. ^{[ 4 ]}

Bibiana und Tim McHugh nahmen schließlich Kontakt zu Google auf und stellten dem Unternehmen CSV- Exporte der TriMet-Fahrplandaten zur Verfügung. Im Dezember 2005 war Portland die erste Stadt, die in der ersten Version des Google-Fahrplanplaners „Transit Trip Planner“ aufgeführt wurde. ^{[ 5 ]} Im September 2006 wurden fünf weitere US-amerikanische Städte in den Google Transit Trip Planner aufgenommen und das Datenformat als Google Transit Feed Specification veröffentlicht . ^{[ 6 ]}

In den Vereinigten Staaten gab es vor der Einführung von GTFS keinen Standard für Fahrpläne im öffentlichen Nahverkehr, nicht einmal einen faktischen Standard . Laut Timothy Moore, dem langjährigen Website-Manager von BART , musste BART vor GTFS verschiedenen Datennutzern unterschiedliche Formate bereitstellen, weshalb ein standardisiertes Format für den öffentlichen Nahverkehr sehr wünschenswert war. ^{[ 3 ]} Die öffentlich und frei verfügbare Formatspezifikation sowie die Verfügbarkeit von GTFS-Fahrplänen führten schnell dazu, dass Entwickler ihre Software für den öffentlichen Nahverkehr auf diesem Format basierten. Dies resultierte in „Hunderten nützlicher und beliebter Anwendungen für den öffentlichen Nahverkehr“ ^{[ 4 ]} sowie in Katalogen mit verfügbaren GTFS-Feeds. Dank des gemeinsamen Datenformats, das diese Anwendungen verwenden, müssen Lösungen nicht individuell auf einen Verkehrsbetrieb zugeschnitten werden, sondern lassen sich problemlos auf jede Region ausweiten, in der ein GTFS-Feed verfügbar ist.

Aufgrund der weiten Verbreitung des Formats wurde der Namensbestandteil „Google“ im ursprünglichen Namen als irreführend angesehen, „dass einige potenzielle Nutzer von der Einführung von GTFS absehen“. Infolgedessen wurde 2009 vorgeschlagen, den Namen der Spezifikation in General Transit Feed Specification zu ändern. ^{[ 7 ]}

GTFS wird typischerweise zur Bereitstellung von Daten für den öffentlichen Nahverkehr in multimodalen Routenplanungsanwendungen verwendet . In den meisten Fällen wird GTFS mit einer detaillierten Darstellung des Straßen- und Fußwegenetzes kombiniert, um die Routenplanung von Punkt zu Punkt und nicht nur zwischen Haltestellen zu ermöglichen. Diese Daten werden häufig mithilfe von GTFS-Realtime erweitert, um Verspätungen, Ausfälle und geänderte Fahrten in Echtzeit-Routenplanungsabfragen einzubeziehen. OpenTripPlanner ist eine Open-Source-Software , die die Routenplanung mit einer Kombination aus GTFS- und OpenStreetMap -Daten ermöglicht. ^{[ 8 ]} Es existieren weitere allgemeine Anwendungen, wie beispielsweise die ArcMap Network Analyst-Erweiterung, die GTFS für die Routenplanung im öffentlichen Nahverkehr integrieren kann. ^{[ 9 ]}

GTFS wurde ursprünglich für die Verwendung in Google Transit entwickelt , einer Online-Anwendung zur multimodalen Reiseplanung.

GTFS wird häufig in der Forschung zur Erreichbarkeit des öffentlichen Nahverkehrs eingesetzt , typischerweise zur Schätzung von Reisezeiten mit öffentlichen Verkehrsmitteln von einem Punkt zu vielen anderen Punkten zu verschiedenen Tageszeiten. ^{[ 10 ] [ 11 ]} Studien haben solche Anwendungen jedoch aufgrund ihrer alleinigen Abhängigkeit von Fahrplänen in Frage gestellt, da Zuverlässigkeitsprobleme und regelmäßige Fahrplanabweichungen nicht berücksichtigt werden. ^{[ 12 ]}

GTFS wurde verwendet, um Veränderungen der Erreichbarkeit aufgrund von Änderungen im öffentlichen Nahverkehr zu messen, seien sie tatsächlich ^{[ 13 ]} oder geplant ^{[ 14 ]} . Die Analyse von Veränderungen im Zeitverlauf kann durch einen einfachen Vergleich veröffentlichter GTFS-Daten desselben Verkehrsunternehmens aus verschiedenen Zeiträumen erfolgen. Für den Vergleich des bestehenden Angebots mit geplanten Infrastruktur- oder Angebotsänderungen muss ein zukünftiges GTFS häufig manuell auf Basis der geplanten Angebotsmerkmale erstellt werden ^{[ 14 ] .}

Öffentliche GTFS-Feeds wurden in einer Vielzahl von Feed-Registern zusammengeführt:

• Die Mobility Database (2023 - heute) baut auf TransitFeeds (2013-2024) auf, das ein Verzeichnis von GTFS- und GTFS-Realtime -Feeds sowie eine interaktive Website zum Durchsuchen der Feed-Inhalte unterhielt.
• Transitland (seit 2014) betreibt ein Verzeichnis von GTFS- und GTFS-Realtime -Feeds in über 55 Ländern und bietet sowohl eine interaktive Website als auch APIs zur Abfrage der Feed-Inhalte. Transitland wurde ursprünglich von Mapzen entwickelt und wird nun von Interline Technologies betreut .
• Der GTFS-Datenaustausch, archiviert am 25. April 2013 in der Wayback Machine (2008–2016), ermöglichte es öffentlichen Verkehrsbetrieben jeder Größe, Kopien ihrer GTFS-Feeds hochzuladen. Die Website ist nicht mehr aktiv.

Ein GTFS-Feed ist eine Sammlung von mindestens sechs und maximal 13 CSV- Dateien (mit der Dateiendung .txt ), die in einer .zip- Datei enthalten sind. Die bevorzugte Zeichenkodierung ist UTF-8 . Die zugehörigen CSV-Tabellen beschreiben gemeinsam den Fahrplan eines Nahverkehrssystems, wie er für Fahrgäste sichtbar ist. Die Spezifikation ist so konzipiert, dass sie für die Reiseplanung ausreicht, eignet sich aber auch für andere Anwendungen wie die Analyse von Servicelevels und allgemeinen Leistungskennzahlen. Im Gegensatz zu europäischen Standards für den Datenaustausch im öffentlichen Nahverkehr wie Transmodel oder VDV -45X umfasst GTFS ausschließlich Fahrplaninformationen, die an Fahrgäste verteilt werden sollen. Es beschränkt sich außerdem auf planmäßige Informationen und enthält keine Echtzeitinformationen. Echtzeitinformationen können jedoch gemäß der zugehörigen GTFS-Realtime- Spezifikation mit GTFS-Plänen verknüpft werden. ^{[ 1 ] [ 2 ]}

Im Folgenden werden die für einen gültigen GTFS-Datenfeed erforderlichen Tabellen beschrieben. Jede Tabelle ist eine Textdatei im CSV-Format , deren Dateiname dem Tabellennamen mit der Endung „.txt“ entspricht. Für die unten stehende Tabelle „agency“ wäre beispielsweise eine CSV-Datei namens „agency.txt“ Bestandteil eines gültigen GTFS-Feeds.

Die Agenturtabelle enthält Informationen über die jeweilige Verkehrsbehörde, einschließlich Name, Website und Kontaktinformationen.

Pflichtfelder:

• Name der Agentur
• Agentur-URL
• Zeitzone der Agentur

Die Routentabelle identifiziert unterschiedliche Routen. Dies ist zu unterscheiden von unterschiedlichen Routings (oder Pfaden), von denen mehrere zu einer einzigen Route gehören können.

Pflichtfelder:

• route_id ( Primärschlüssel )
• Routenkurzname
• Routenname
• Routentyp
• Hintergrundfarbe
• Vordergrundfarbe

Pflichtfelder:

• trip_id (Primärschlüssel)
• route_id ( Fremdschlüssel )
• service_id (Fremdschlüssel)

Optionale Felder:

• block_id - Die Block-ID gibt den Fahrplanblock an , zu dem eine Fahrt gehört.

Pflichtfelder:

• stop_id (Primärschlüssel)
• trip_id (Fremdschlüssel)
• Ankunftszeit
• Abfahrtszeit
• Stoppsequenz

Beachten Sie, dass die Verweilzeit durch die Differenz zwischen Ankunfts- und Abfahrtszeit modelliert werden kann. Viele Agenturen scheinen die Verweilzeit jedoch für die meisten Haltestellen nicht zu modellieren.

Die Haltestellentabelle definiert die geografischen Standorte jeder einzelnen Haltestelle oder Station im Verkehrssystem sowie optional einige der mit diesen Haltestellen verbundenen Annehmlichkeiten.

Pflichtfelder:

• stop_id (Primärschlüssel)
• Haltestellenname
• stop_lon
• stop_lat

Die Kalendertabelle definiert wiederkehrende Servicemuster, beispielsweise für jeden Werktag. Nicht wiederkehrende Servicemuster, etwa für einmalige Sonderereignisse, werden in der Tabelle „calendar_dates“ definiert.

Pflichtfelder:

• service_id (Primärschlüssel)
• Montag
• Dienstag
• Mittwoch
• Donnerstag
• Freitag
• Samstag
• Sonntag
• Startdatum
• Enddatum

Die Tabelle „Kalenderdaten“ ist optional und dient dazu, Ausnahmen in der Datei „calendar.txt“ zu erfassen. Dies kann das Hinzufügen oder Entfernen von Tagen umfassen, beispielsweise für Feiertagsdienste. Die Datei enthält lediglich drei Spalten: die Dienst-ID, das Datum und den Ausnahmetyp (hinzugefügt oder entfernt). Eine Dienst-ID muss nicht in der Datei „calendar.txt“ vorhanden sein, um in diese Tabelle aufgenommen zu werden.

Fahrpreisinformationen für die Strecken eines Verkehrsunternehmens.

Regeln zur Anwendung von Tarifen für Reiserouten.

Die meisten Tarifstrukturen verwenden eine Kombination der folgenden Regeln:

• Der Fahrpreis hängt vom Abfahrts- oder Zielbahnhof ab.
• Der Fahrpreis hängt davon ab, durch welche Zonen die Reiseroute führt.
• Der Fahrpreis hängt von der gewählten Route ab.

Regeln für das Zeichnen von Linien auf einer Karte zur Darstellung der Strecken eines Verkehrsunternehmens.

Diese Tabelle gibt den Takt (Zeit zwischen den Fahrten) für Strecken mit variabler Taktfrequenz an.

Regeln für das Herstellen von Verbindungen an Umsteigepunkten zwischen Strecken.

Optional können ein Start- und ein Ablaufdatum für den Feed festgelegt werden. Behörden können Feeds veröffentlichen, die mehrere Tage in der Zukunft liegen. Daher speichern Reiseplanungssoftware-Anwendungen mehrere Feed-Versionen und den jeweils korrekten Feed für einen bestimmten Tag oder eine bestimmte Uhrzeit.

Übersetzungen

Die Übersetzungstabelle besteht aus folgenden Spalten: Tabellenname, Feldname, Feldwert, Datensatz-ID, Unterdatensatz-ID, Sprache und Übersetzung. Übersetzungen werden in den jeweiligen Tabellen gespeichert, und jedes Textfeld oder jede URL kann übersetzt werden. GTFS verwendet zwei Arten von Schlüsseln in der Schlüssel-Wert-Tabelle. Die Datensatz-ID ist eine ID für das Feld, z. B. für Haltestellen oder Fahrten, während der Feldwert dem ursprünglichen Inhalt des Feldnamens entspricht. Tabellen, die ein Tupel mit zwei Werten verwenden , wie z. B. Haltestellenzeiten, nutzen Datensatz-ID und Unterdatensatz-ID zur Darstellung des Tupels. Die Übersetzungsspalte enthält die Ausgabe.

• Bing Maps
• Google Transit
• Reiseplaner
• Offener Standard

Dieser Artikel enthält Auszüge aus „Opening Public Transit Data in Germany“ von Stefan Kaufmann, das unter einer Creative Commons Attribution 3.0 Unported Lizenz verfügbar ist.

• Google-Dokumentation zur GTFS-Spezifikation
• Geschichte von GTFS
• GTFS-Tools
• Das GTFS-Ressourcenzentrum wird von MobilityData verwaltet.
• Der allgemeine Artikel „Spezifikation für Transit-Feeds“ auf TransitWiki enthält Informationen zu Geschichte, Verwendung und Anwendungen, Produktionsmethoden und bewährten Verfahren.