General Transit Feed Specification

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 8. Februar 2022 um 11:07 Uhr durch imported>-stk(48223) (So hoffentlich verstaendlicher.).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
General Transit Feed Specification
Dateiendung: .zip
Erstveröffentlichung: 27. September 2006
Erweitert von: CSV
Standard(s): De-facto-Standard
Website: developers.google.com

Die General Transit Feed Specification (GTFS) definiert ein digitales Austauschformat für Fahrpläne des öffentlichen Personenverkehrs und dazugehörige geografische Informationen wie z. B. die Standorte von Haltestellen.

Geschichte

Rechts eine Karte mit einem Streckenverlauf von Start- zu Zielort, links die Auswahl von Fahrtkombinationen mit Sharing-Fahrrädern und Straßenbahnfahrten
Fahrplanauskunft auf Basis von GTFS- und GBFS-Daten
Datei:Mapnificent reachability map of Karlsruhe, 2020 data.png
GTFS-Erreichbarkeitsanalyse mit Mapnificent

Das spätere GTFS-Format begann 2005 als Nebenprojekt des Google-Mitarbeiters Chris Harrelson, der „mit Möglichkeiten herumspielte, Nahverkehrsdaten in Google Maps zu integrieren, […] als er von den verheirateten IT-Managern Tim und Bibiana McHugh erfuhr, die für das Verkehrsunternehmen TriMet in Portland arbeiteten“[1]. McHugh war ebenfalls frustriert über das Problem, an ÖPNV-Auskünfte in fremden Städten zu gelangen – während Online-Kartendienste zu dieser Zeit bereits einfach zu benutzende Routenplaner für den Automobilverkehr anboten[2].

Das Ehepaar McHugh versorgte Google nach einer ersten Kontaktaufnahme mit CSV-Exporten der TriMet-Fahrpläne. Im Dezember 2005 wurde Portland als erste Stadt in die initiale Version von Googles Transit Trip Planner aufgenommen[3]. Im September 2006 folgten fünf weitere US-amerikanische Städte, und das benutzte Datenformat wurde als Google Transit Feed Specification veröffentlicht[4].

Anders als in Europa hatte es in den Vereinigten Staaten bis dahin keine Standardisierungsbemühungen für Fahrplandaten des ÖPNV gegeben, und es existierte auch kein einheitlicher Industriestandard. Der langjährige BART-Website-Manager Timothy Moore wird zitiert, dass BART vor der Einführung von GTFS verschiedene Nutzer ihrer Fahrplandaten mit jeweils verschiedenen Datenformaten belieferte, was ein einheitliches Datenformat sehr erstrebenswert gemacht habe.[1] Die öffentlich frei verfügbare GTFS-Formatspezifikation sowie die Verfügbarkeit verschiedener Fahrplandatensätze im GTFS-Format führten dazu, dass Softwareentwickler ihre Anwendungen auf diesem Format basieren ließen. Das Ergebnis dieser Entwicklung waren „hunderte nützlicher und weitverbreiteter Nahverkehrsanwendungen“[2] sowie Verzeichnisdienste für verfügbare GTFS-Feeds. Da all diese Anwendungen auf einem einheitlichen Datenformat basierten, waren sie nicht mehr auf ein bestimmtes Verkehrsunternehmen oder einen bestimmten Verkehrsverbund maßgeschneidert, sondern konnten einfach auf jede beliebige Region ausgeweitet werden, für die ein GTFS-Feed bereitstand.

Aufgrund der weiten Verbreitung des Formats wurde das „Google“ im ursprünglichen Namen der Spezifikation als Fehlbezeichnung angesehen, „die manche potenzielle Nutzer davon abhalten könnte, GTFS einzuführen“. Als Folge dessen wurde 2009 vorgeschlagen, das Datenformat in General Transit Feed Specification umzubenennen.[5]

Struktur

Ein GTFS-„Feed“ ist eine Sammlung von mindestens sechs und bis zu 15 CSV-Dateien (mit der Dateiendung .txt), die in einem ZIP-Archiv zusammengefasst sind. Gemäß Spezifikation sollen die CSV-Dateien bevorzugt im UTF-8-Format angelegt sein.

Alle CSV-Dateien bilden gemeinsam ein Abbild einer relationalen Datenbank, das den öffentlich sichtbaren Fahrplan eines Verkehrsunternehmens oder -verbundes wiedergibt. Im Gegensatz zu europäischen Industriestandards für ÖPNV-Austauschformate wie Transmodel oder VDV-45X beinhaltet GTFS lediglich Sollfahrpläne, die für Fahrgäste bestimmt sind. Die im Umfang mächtigeren Industrieformate sind im Gegensatz zu GTFS auch dazu angelegt, beispielsweise Leerfahrten, Fahrzeugumläufe oder Dienstpläne zu modellieren.[6]

Für die Anreicherung eines Fahrplanauskunftssystems mit Echtzeitdaten und temporären Fahrplanänderungen existiert die Erweiterung GTFS Realtime, die ähnliche Funktionen wie die europäisch genormte SIRI-Schnittstelle übernimmt.[7][8]

Weblinks

Einzelnachweise

  1. a b Wade Roush: Welcome to Google transit: How (and why) the search giant is remapping public transportation Archiviert vom Original am 24. März 2016. In: Community Transportation. 2012. Abgerufen am 14. März 2016.
  2. a b Lauren Dyson, Brett Goldstein, Abhi Nemani: Beyond Transparency. Code for America Press, 2013, S. 125–135.
  3. Avichal Garg: Public Transit via Google. In: Official Google Blog . Abgerufen am 14. März 2016.
  4. Chris Harrelson: Happy Trails with Google Transit. In: Official Google Blog . Abgerufen am 14. März 2016.
  5. Joe Hughes: proposal: remove „Google“ from the name of GTFS. In: General Transit Feed Spec Changes . Google Groups. Abgerufen am 14. März 2016.
  6. Stefan Kaufmann: Opening Public Transit in Germany. A Status Quo. 2014, S. 36–37 (englisch, dbis.eprints.uni-ulm.de [PDF; 9,0 MB]).
  7. What is GTFS-realtime?. In: Google Developers . Google.
  8. Netex and SIRI - OpenTripPlanner 2. In: opentripplanner.org. Abgerufen am 7. Februar 2022 (englisch).