Best Practices für GTFS

Kern-GTFS

Die folgenden Vorgehensweisen werden für die Beschreibung öffentlicher Verkehrsmittel in GTFS (General Transit Feed Specification) empfohlen. Sie beruhen auf den Erfahrungen der Mitglieder der Arbeitsgruppe zu den Best Practices für GTFS und anwendungsspezifischen GTFS-Empfehlungen. Weitere Informationen finden Sie unter Häufig gestellte Fragen (FAQs).

Dokumentstruktur

Die Best Practices sind in drei Hauptabschnitte unterteilt:

Häufig gestellte Fragen (FAQs)

Warum sind diese Best Practices für GTFS wichtig?

Mit den Best Practices für GTFS soll Folgendes erreicht werden:

  • Bessere Funktionen für Nutzer von Apps für öffentliche Verkehrsmittel
  • Umfassende Dateninteroperabilität, damit Softwareentwickler Anwendungen, Produkte und Dienste einfacher bereitstellen und skalieren können
  • Vereinfachung des Einsatzes von GTFS in verschiedenen Anwendungskategorien (über den ursprünglichen Schwerpunkt der Fahrtenplanung hinaus)

Ohne koordinierte Best Practices für GTFS werden die Anforderungen und Erwartungen für verschiedene Anwendungen mit GTFS-Unterstützung möglicherweise unkoordiniert festgelegt. Dies führt zu unterschiedlichen Anforderungen und anwendungsspezifischen Datasets sowie zu einer geringeren Interoperabilität. Vor der Veröffentlichung der Best Practices gab es mehr Unklarheiten und Meinungsverschiedenheiten in Bezug auf die korrekte Formatierung von GTFS-Daten.

Wie und von wem wurden diese Best Practices zusammengestellt?

Diese Best Practices wurden von einer Arbeitsgruppe aus 17 Organisationen entwickelt, die an GTFS beteiligt sind, einschließlich App-Anbietern und Datennutzern, Verkehrsunternehmen und Beratern, die sich intensiv mit GTFS befassen. Die Arbeitsgruppe wurde vom Rocky Mountain Institute einberufen und unterstützt.

Die Mitglieder der Arbeitsgruppe haben über die einzelnen Best Practices abgestimmt. Die meisten Best Practices wurden einstimmig akzeptiert. In einigen wenigen Fällen beschränkte sich die Zustimmung zu Best Practices auf die große Mehrheit der Organisationen.

Warum reicht es nicht aus, einfach nur die GTFS-Referenz zu ändern?

Sehr gute Frage! Die Prüfung der Spezifikation, der Datennutzung und der Anforderungen hat tatsächlich einige Änderungen an der Spezifikation zur Folge gehabt (siehe geschlossene Pull-Anfragen in GitHub). Für Änderungen an der Spezifikationsreferenz sind strengere Überprüfungen und mehr Kommentare erforderlich als für die Best Practices. Dennoch war es erforderlich, sich auf klare Best Practice-Empfehlungen zu einigen.

Die Arbeitsgruppe geht davon aus, dass einige Best Practices für GTFS letztlich in die Core GTFS-Referenz aufgenommen werden.

Prüfen GTFS-Validierungstools die Einhaltung dieser Best Practices?

Derzeit gibt es kein Tool, das auf die Einhaltung aller Best Practices prüft. Verschiedene Validator können prüfen, ob einige dieser Best Practices eingehalten werden. Eine Liste der verfügbaren GTFS-Validator finden Sie hier. Wenn Sie einen GTFS-Validator entwickeln, der auf diesen Best Practices beruht, senden Sie bitte eine E-Mail an gtfs@rmi.org.

Ich vertrete einen Betreiber. Was kann ich tun, damit unsere Software-Dienstleister und -Anbieter diese Best Practices befolgen?

Verweisen Sie Ihren Software-Dienstleister oder -Anbieter auf diese Best Practices. Wir empfehlen, sowohl die URL für die Best Practices für GTFS als auch die Core-Referenz der Spezifikation für GTFS-produzierende Software anzugeben.

Was sollte ich tun, wenn ich feststelle, dass ein GTFS-Datenfeed nicht diesen Best Practices entspricht?

Nehmen Sie Kontakt mit dem Ersteller des Feeds über die vorgeschlagenen Felder feed_contact_email oder feed_contact_url in feed_info.txt (sofern vorhanden) auf. Sie können ihn sonst auch über die Kontaktdaten auf der Website des Betreibers oder des Erstellers erreichen. Wenn Sie den Ersteller des Feeds über das Problem informieren, verweisen Sie auf die Diskussion zur entsprechenden Best Practice für GTFS. Weitere Informationen finden Sie unter Links zu diesem Dokument.

Ich möchte eine Änderung oder Ergänzung für die Best Practices vorschlagen. Wie muss ich vorgehen?

Senden Sie eine E-Mail an gtfs@rmi.org oder öffnen Sie im GitHub-Repository zu den Best Practices für GTFS ein Problem oder eine Pull-Anfrage.

Wie kann ich mitmachen?

Senden Sie eine E-Mail an gtfs@rmi.org.

Veröffentlichung von und allgemeine Vorgehensweisen für Datasets

Allgemeine Empfehlungen
Datasets sollten unter einer öffentlichen, permanenten URL mit dem Namen der ZIP-Datei veröffentlicht werden (z. B. www.IhrUnternehmen.de/gtfs/gtfs.zip). Idealerweise sollte die Datei direkt heruntergeladen werden können, ohne dass eine Anmeldung erforderlich ist. Dies erleichtert den Download durch Softwareanwendungen, in denen diese Daten genutzt werden. Es wird empfohlen und ist gängige Praxis, ein GTFS-Dataset öffentlich zum Download zur Verfügung zu stellen. Wenn ein Datenanbieter den Zugriff auf GTFS jedoch aus Lizenzierungs- oder anderen Gründen steuern muss, bietet es sich an, dazu API-Schlüssel zu verwenden. Automatische Downloads sind dann leichter möglich.
GTFS-Daten werden in Iterationen veröffentlicht, sodass eine einzelne Datei an einem festen Speicherort immer die aktuelle offizielle Dienstbeschreibung für einen oder mehrere Betreiber enthält.
Speichern Sie nach Möglichkeit dauerhafte IDs (ID-Felder) für stop_id, route_id und agency_id für alle Dateniterationen.
Ein GTFS-Dataset sollte den aktuellen und einen bevorstehenden Dienst enthalten (auch als „zusammengeführtes Dataset“ bezeichnet). Mit der Funktion Merge des Google-Tools „transitfeed“ lässt sich aus zwei verschiedenen GTFS-Feeds ein zusammengeführtes Dataset erstellen.
  • Das veröffentlichte GTFS-Dataset sollte immer mindestens für die nächsten 7 Tage gültig sein – und idealerweise so lange, wie der Fahrplan voraussichtlich gilt.
  • Das GTFS-Dataset sollte nach Möglichkeit mindestens die nächsten 30 Tage abdecken.
Entfernen Sie alte Dienste (abgelaufene Kalender) aus dem Feed.
Wenn eine Dienständerung innerhalb von maximal 7 Tagen wirksam wird, sollte sie über einen GTFS Realtime-Feed (Diensthinweise oder Updates zu Fahrten) vorgenommen werden – nicht über ein statisches GTFS-Dataset.
Der Webserver, auf dem die GTFS-Daten gehostet werden, muss so konfiguriert sein, dass das Datum der Dateiänderung korrekt gemeldet wird (siehe HTTP/1.1 – RFC 2616, Abschnitt 14.29).

Nach Datei sortierte Empfehlungen für Vorgehensweisen

In diesem Abschnitt finden Sie die Best Practices, die entsprechend der GTFS-Referenz nach Datei und Feld organisiert sind.

Alle Dateien

Feldname Empfehlung
Gemischte Groß-/Kleinschreibung Alle kundenseitigen Textstrings (einschließlich Haltestellennamen, Routennamen und Zielschildern) sollten gemischte Groß- und Kleinschreibung verwenden (nicht nur Großbuchstaben). Dabei sollten auf Displays, auf denen Kleinbuchstaben dargestellt werden können, die lokalen Konventionen für die Groß- und Kleinschreibung von Ortsnamen eingehalten werden.
Beispiele:
Brighton Churchill Square
Villiers-sur-Marne
Market Street
Abkürzungen Vermeiden Sie im gesamten Feed Abkürzungen für Namen und anderen Text (z. B. „Str.“ für „Straße“), es sei denn, der abgekürzte Name ist die übliche Bezeichnung eines Standorts (z. B. „ZOB“). Abkürzungen können für Bedienungshilfen wie Screenreader und sprachgesteuerte Benutzeroberflächen problematisch sein. Software für die Nutzung der Daten kann so konzipiert werden, dass vollständige Wörter zur Darstellung zuverlässig in Abkürzungen umgewandelt werden. Bei der Umwandlung von Abkürzungen in vollständige Wörter besteht jedoch ein höheres Fehlerrisiko.

agency.txt

Feldname Empfehlung
agency_id Sollte enthalten sein, auch wenn der Feed nur einen Betreiber umfasst (siehe auch die Empfehlung, agency_id in routes.txt und fare_attributes.txt aufzunehmen)
agency_lang Sollte enthalten sein
agency_phone Sollte enthalten sein, es sei denn, es gibt keine solche Telefonnummer für den Kundenservice
agency_email Sollte enthalten sein, es sei denn, es gibt keine solche E-Mail-Adresse für den Kundenservice
agency_fare_url Sollte enthalten sein, es sei denn, der Betreiber erhebt überhaupt keine Gebühr für die Nutzung

Beispiele:

  • Busverbindungen werden von mehreren kleinen Busunternehmen betrieben. Es gibt jedoch einen großen Verkehrsverbund, der für Fahrpläne und Fahrkarten zuständig ist. Aus Sicht eines Nutzers ist er auch für die Busverbindungen verantwortlich. Im Feed muss daher das große Unternehmen als Verkehrsverbund definiert werden. Auch wenn die Daten intern auf verschiedene kleine Busunternehmen aufgeteilt sind, darf im Feed nur ein Unternehmen definiert sein.
  • Der Anbieter des Feeds betreibt das Fahrkartenportal. Es gibt jedoch verschiedene Betreiber, die die Dienste an sich bereitstellen. Aus Sicht der Nutzer sind diese auch zuständig. Die Unternehmen, die die Dienste an sich bereitstellen, müssen im Feed als Betreiber definiert werden.

stops.txt

Feldname Empfehlung
stop_id Haltestellen an verschiedenen Standorten sollten eine unterschiedliche stop_id haben. Das gilt für Haltestellen, die unterschiedliche genaue Standorte haben, an denen Fahrzeuge auf bestimmten Routen halten können und die möglicherweise durch Schilder, Wartehäuschen oder andere öffentliche Informationen erkennbar sind. Damit sind auch solche gemeint, die sich an verschiedenen Straßenecken befinden oder die verschiedene Einstiegsmöglichkeiten wie Bahnsteige oder Haltebuchten für Busse haben, selbst wenn sie nah beieinander sind.
stop_id ist eine interne ID, die Fahrgästen nicht angezeigt werden soll.
Verwenden Sie bei allen Dateniterationen eine einheitliche stop_id für identische Haltestellen (siehe Veröffentlichung von und allgemeine Vorgehensweisen für Datasets).
stop_name stop_name sollte mit dem öffentlichen Namen des Betreibers für die Haltestelle, die Station oder die Einstiegsmöglichkeit übereinstimmen, z. B. der Angabe auf einem Fahrplan, online und/oder an dem Standort selbst.
Falls es keinen veröffentlichten Haltestellennamen gibt, verwenden Sie im gesamten Feed einheitliche Namenskonventionen für Haltestellen.
Vermeiden Sie die Verwendung von Abkürzungen, außer für Orte, für die in der Regel ein abgekürzter Name verwendet wird. Weitere Informationen finden Sie in „Abkürzungen“ (Nr. 2) unter Alle Dateien.
Geben Sie die Haltestellennamen gemäß den lokalen Konventionen mit gemischter Groß- und Kleinschreibung an, wie es für alle kundenseitigen Textfelder empfohlen wird.
Standardmäßig sollte stop_name keine allgemeinen oder redundanten Begriffe wie „Station“ oder „Haltestelle“ enthalten, aber einige Grenzfälle sind zulässig.
  • Wenn der Begriff tatsächlich Teil des Namens ist (z. B. „Anhalter Bahnhof“)
  • Wenn stop_name zu allgemein ist (z. B. wenn es der Name der Stadt ist). „Station“, „Terminal“ oder andere Begriffe verdeutlichen die Bedeutung.
stop_lat und stop_lon Haltestellenpositionen sollten so genau wie möglich sein. Die Position von Haltestellen sollte nicht mehr als vier Meter von der tatsächlichen Position abweichen.
Haltestellenpositionen sollten sich sehr nah an der Stelle befinden, an der Passagiere einsteigen (richtige Straßenseite).
Wenn eine Haltestelle in mehreren Datenfeeds enthalten ist (wenn zwei Betreiber dieselbe Haltestelle oder Einstiegsmöglichkeit verwenden), geben Sie für beide Haltestellen dieselben Werte für stop_lat und stop_lon an, um zu kennzeichnen, dass die Haltestelle gemeinsam genutzt wird.
stop_code stop_code sollte in GTFS enthalten sein, wenn es für Passagiere sichtbare Haltestellennummern oder IDs gibt.
parent_station und location_type Viele Stationen oder Terminals haben mehrere Einstiegsmöglichkeiten, die beispielsweise als Haltebucht, Bahnsteig, Anlegestelle oder Gate bezeichnet werden können. In solchen Fällen sollten Ersteller von Feeds die Bahnhöfe und Einstiegsmöglichkeiten (auch untergeordnete Haltestellen genannt) und ihre Beziehung beschreiben.
  • Die Station oder das Terminal muss in stops.txt als Datensatz mit location_type = 1 definiert sein.
  • Jede Einstiegsmöglichkeit sollte mit location_type = 0 als Haltestelle definiert sein. Das Feld parent_station sollte auf die stop_id der Station verweisen, in der sich die Einstiegsmöglichkeit befindet.
Geben Sie beim Benennen der Station und der untergeordneten Haltestellen Namen an, die den Fahrgästen bekannt sind und die Identifizierung der Station und der Einstiegsmöglichkeit (Haltebucht, Bahnsteig, Anlegestelle, Gate usw.) erleichtern.
Name der übergeordneten Station Name der untergeordneten Haltestelle
Chicago Union Station Chicago Union Station, Bahnsteig 19
San Francisco Ferry Building Terminal San Francisco Ferry Building Terminal, Gate E
Downtown Transit Center Downtown Transit Center, Haltebucht B

routes.txt

Feldname Empfehlung
agency_id Muss enthalten sein, wenn in der Datei agency.txt definiert.
route_short_name Geben Sie route_short_name an, wenn es eine kurze Dienstbezeichnung gibt. Dies sollte der gängige Name des Dienstes sein, der auch von Fahrgästen verwendet wird. Er sollte maximal 12 Zeichen lang sein.
route_long_name Definition in der Spezifikationsreferenz: Dieser Name ist in der Regel ausführlicher als der route_short_name und enthält häufig das Ziel oder die Haltestelle der Route. Es muss mindestens route_short_name oder route_long_name angegeben werden, potenziell auch beide. Wenn die Route keinen langen Namen hat, geben Sie einen route_short_name an und verwenden Sie einen leeren String als Wert für dieses Feld.

Beispiele für Arten von langen Namen:

Primärer Reisepfad oder Korridor
Routenname Format Betreiber
„N“/„Judah“ route_short_name/
route_long_name		 Muni, San Francisco, Kalifornien (USA)
„6“/„ML King Jr Blvd“ route_short_name/
route_long_name		 TriMet, Portland, Oregon (USA)
„6“/„Nation – Étoile“ route_short_name/
route_long_name		 RATP, Paris (Frankreich)
„U2“/„Pankow – Ruhleben“ route_short_name/
route_long_name		 BVG, Berlin (Deutschland)
Beschreibung des Dienstes
„Hartwell Area Shuttle“
route_long_name sollte nicht route_short_name enthalten.
Beim Füllen von route_long_name wird die vollständige Bezeichnung einschließlich Dienstidentität eingefügt. Beispiele:
Dienstidentität Empfehlung Beispiele
"MAX Light Rail"
TriMet, Portland, Oregon (USA)		 route_long_name sollte die Marke (MAX) und die Routenangabe enthalten. „MAX Red Line“
„MAX Blue Line“
„Rapid Ride“
ABQ Ride, Albuquerque, New Mexico (USA)		 route_long_name sollte die Marke (Rapid Ride) und die Routenangabe enthalten. „Rapid Ride Red Line“
„Rapid Ride Blue Line“
route_id Alle Fahrten auf einer bestimmten benannten Route sollten auf dieselbe route_id verweisen.
  • Verschiedene Richtungen einer Route sollten nicht in verschiedene route_id-Werte aufgeteilt werden.
  • Verschiedene Betriebsabschnitte einer Route sollten nicht in verschiedene route_id-Werte aufgeteilt werden. Erstellen Sie also in routes.txt keine unterschiedlichen Datensätze für die Dienste „Downtown AM“ und „Downtown PM“.
Wenn eine Routengruppe eindeutig benannte Zweige enthält (z. B. „1A“ und „1B“), folgen Sie den Empfehlungen unter Zweige, um route_short_name und route_long_name zu ermitteln.
route_color und route_text_color Müssen mit Beschilderungen sowie Kundeninformationen, die gedruckt oder online verfügbar sind, übereinstimmen und dürfen daher nicht angegeben werden, wenn sie an anderer Stelle nicht existieren.

trips.txt

  • Sonderfall für Rundrouten: Bei Rundrouten beginnen und enden Fahrten an derselben Haltestelle. Dies steht im Gegensatz zu linearen Routen, bei denen Start und Ende zwei unterschiedliche Stationen sind. Für die Beschreibung von Rundrouten müssen bestimmte Vorgehensweisen befolgt werden. Weitere Informationen
  • Sonderfall für Lassorouten: Lassorouten sind eine Mischung aus linearen und Rundrouten. Die Fahrzeuge legen nur einen Teil der Route auf einer Schleife zurück. Für die Beschreibung von Lassorouten müssen bestimmte Vorgehensweisen befolgt werden. Weitere Informationen
Feldname Empfehlung
trip_headsign Geben Sie in den Feldern trip_headsign und stop_headsign keine Routennamen (mit entsprechendem route_short_name und route_long_name) an.
Ziel, Fahrtrichtung und/oder sonstige Fahrtbezeichnungen, die auf dem Zielschild des Fahrzeugs zu sehen sind und anhand derer mehrere Fahrten einer Route unterschieden werden können, sollten enthalten sein. Die Übereinstimmung mit den auf dem Fahrzeug angezeigten Richtungsinformationen ist das primäre und vorrangige Ziel zum Bestimmen von Zielschildern in GTFS-Datasets. Andere Informationen sollten nur angegeben werden, wenn das primäre Ziel dadurch weiterhin klar bleibt. Wenn sich die Zielschilder während einer Fahrt ändern, überschreiben Sie trip_headsign mit stop_times.stop_headsign. Im Folgenden finden Sie Empfehlungen für einige mögliche Fälle:
Beispieltabelle:
Routenbeschreibung Empfehlung
2A. Nur Ziel Geben Sie die Endhaltestelle an, etwa „Omnibusbahnhof“, „Stadtzentrum München“ oder „Isarufer“.
2B. Ziele mit Wegpunkten „<Ziel> über <Wegpunkt>“, etwa „Hauptbahnhof über Harras“. Werden Wegpunkte vom Zielschild für Passagiere entfernt, nachdem das Fahrzeug sie passiert hat, legen Sie mithilfe von stop_times.stop_headsign ein aktualisiertes Zielschild fest.
2C. Regionaler Ortsname mit lokalen Haltestellen Gibt es innerhalb des Zielorts oder -bezirks mehrere Haltestellen, verwenden Sie stop_times.stop_headsign, sobald der Zielort erreicht ist.
2D. Nur Richtung Verwenden Sie hierfür Richtungsbegriffe wie „Stadteinwärts“ oder „Im Uhrzeigersinn“.
2E. Richtung mit Ziel „<Richtung> nach <Endhaltestelle>“, etwa „Richtung Westen nach Pasing“.
2F. Richtung mit Ziel und Wegpunkten „<Richtung> über <Wegpunkt> nach <Ziel>“, etwa „Richtung Westen über Schwanthalerhöhe nach Pasing“.
Beginnen Sie nicht mit einem Zielschild mit den Worten „Nach“ oder „In Richtung“.
direction_id Bei Fahrten auf einer Route, die entgegengesetzte Richtungen bedient, können Sie diese Gruppen von Fahrten voneinander unterscheiden, indem Sie im Feld direction_id die Werte 0 und 1 verwenden.
Verwenden Sie die Werte 0 und 1 im Dataset konsistent. Das heißt:
  • Wenn 1 = Stadtauswärts auf der roten Route, dann 1 = Stadtauswärts auf der grünen Route
  • Wenn 1 = Nördliche Richtung auf Route X, dann 1 = Nördliche Richtung auf Route Y
  • Wenn 1 = Im Uhrzeigersinn auf Route X, dann 1 = Im Uhrzeigersinn auf Route Y

stop_times.txt

Rundrouten: Für Rundrouten sind besondere stop_times-Überlegungen erforderlich. (siehe Fall Rundrouten)

Feldname Empfehlung
pickup_type und drop_off_type Leerfahrten (Fahrten ohne Passagiere) sollten mit pickup_type und dem drop_off_type-Wert 1 für alle stop_times-Zeilen gekennzeichnet werden.
Bei Beförderungsfahrten müssen interne „Zeitmesspunkte“ zum Beobachten der betrieblichen Leistung und andere Orte wie etwa Depots, an denen ein Fahrgast nicht einsteigen kann, mit pickup_type = 1 (kein Einstieg möglich) und drop_off_type = 1 (kein Ausstieg möglich) gekennzeichnet werden.
timepoint Das Feld timepoint sollte angegeben werden. Damit wird festgelegt, an welche stop_times sich der Operator genau hält (timepoint=1) und dass die anderen Haltestellenzeiten Schätzungen sind (timepoint=0).
arrival_time und departure_time In den Feldern arrival_time und departure_time sollten nach Möglichkeit Zeitwerte angegeben werden, einschließlich unverbindlicher geschätzter oder interpolierter Zeiten zwischen Zeitpunkten.
stop_headsign

stop_headsign-Werte überschreiben das trip_headsign (in trips.txt). stop_headsign-Werte sollten angegeben werden, wenn sich der auf dem Zielschild angezeigte Text während einer Fahrt ändert. stop_headsign-Werte werden nicht für nachfolgende Haltestellen übernommen. Daher müssen sie wiederholt werden, wenn das Zielschild der Haltestelle gleich bleibt. Im Allgemeinen sollten die Werte für Zielschilder auch den Schildern in den Stationen entsprechen.

In den folgenden Fällen würde „Southbound“ (Richtung Süden) Kunden täuschen, da dieser Text nicht auf den Schildern in den Stationen verwendet wird.
Wählen Sie in New York City für die Linie 2 in Richtung Süden Folgendes aus:
Für Zeilen in der Datei stop_times.txt: Wert von stop_headsign verwenden:
Bis Manhattan erreicht ist Manhattan & Brooklyn
Bis Downtown erreicht ist Downtown & Brooklyn
Bis Brooklyn erreicht ist Brooklyn
Sobald Brooklyn erreicht wurde Brooklyn (New Lots Av)
Wählen Sie in Boston für die Red Line in Richtung Süden (Braintree-Zweig) Folgendes aus:
Für Zeilen in der Datei stop_times.txt: Wert von stop_headsign verwenden:
Bis Downtown erreicht ist Inbound to Braintree
Sobald Downtown erreicht wurde Braintree
Nach Downtown Outbound to Braintree
shape_dist_traveled shape_dist_traveled muss für eine Rund- oder Inline-Route angegeben werden (Abschnitte werden während einer Fahrt mehrmals in der gleichen Richtung befahren). Weitere Informationen finden Sie in der Empfehlung zu shapes.shape_dist_traveled.

calendar.txt

Feldname Empfehlung
Alle Felder calendar_dates.txt darf nur eine begrenzte Anzahl von Ausnahmen für den Fahrplan enthalten. Der regelmäßig geplante Dienst sollte mit calendar.txt konfiguriert werden.
Durch die Angabe eines calendar.service_name-Feldes lässt sich außerdem die Verständlichkeit von GTFS verbessern, auch wenn das nicht in die Spezifikation aufgenommen wurde.

calendar_dates.txt

Feldname Empfehlung
Alle Felder calendar_dates.txt darf nur eine begrenzte Anzahl von Ausnahmen für den Fahrplan enthalten. Der regelmäßig geplante Dienst sollte mit calendar.txt konfiguriert werden.
Durch die Angabe eines calendar.service_name-Feldes lässt sich außerdem die Verständlichkeit von GTFS verbessern, auch wenn das nicht in die Spezifikation aufgenommen wurde.

fare_attributes.txt

Feldname Empfehlung
Alle Felder agency_id sollte in fare_attributes.txt enthalten sein, wenn das Feld in agency.txt enthalten ist.
Wenn ein Preissystem nicht genau modelliert werden kann, vermeiden Sie weitere Verwirrung und lassen Sie das Feld leer.
Fügen Sie Fahrpreise (fare_attributes.txt und fare_rules.txt) hinzu und modellieren Sie sie so genau wie möglich. In Grenzfällen, in denen Fahrpreise nicht genau modelliert werden können, sollte der Preis eher teurer als günstiger angegeben werden, damit Kunden auf jeden Fall genug Geld dabei haben. Wenn sich der Großteil der Fahrpreise nicht korrekt modellieren lässt, nehmen Sie keine Preisinformationen in den Feed auf.

fare_rules.txt

Feldname Empfehlung
Alle Felder agency_id sollte in fare_attributes.txt enthalten sein, wenn das Feld in agency.txt enthalten ist.
Wenn ein Preissystem nicht genau modelliert werden kann, vermeiden Sie weitere Verwirrung und lassen Sie das Feld leer.
Fügen Sie Fahrpreise (fare_attributes.txt und fare_rules.txt) hinzu und modellieren Sie sie so genau wie möglich. In Grenzfällen, in denen Fahrpreise nicht genau modelliert werden können, sollte der Preis eher teurer als günstiger angegeben werden, damit Kunden auf jeden Fall genug Geld dabei haben. Wenn sich der Großteil der Fahrpreise nicht korrekt modellieren lässt, nehmen Sie keine Preisinformationen in den Feed auf.

shapes.txt

Feldname Empfehlung
Alle Felder Idealerweise sollte bei gemeinsamen Ausrichtungen (wenn zwei Routen auf demselben Straßen- oder Gleisabschnitt verlaufen) der gemeinsame Abschnitt genau übereinstimmen. So lassen sich öffentliche Verkehrsrouten einfacher in hoher Qualität kartografieren.
Ausrichtungen sollten der Mittellinie des Fahrtwegs folgen, auf dem das Fahrzeug bewegt wird. Das kann entweder die Mittellinie der Straße (wenn es keine ausgewiesenen Fahrspuren gibt) oder die Mittellinie der Straßenseite für die Fahrtrichtung des Fahrzeugs sein.

Ausrichtungen dürfen nicht in einem scharfen Winkel zu einer Haltestelle am Straßenrand, zu einem Bahnsteig oder zu einer Einstiegsmöglichkeit verlaufen.
shape_dist_traveled

Muss sowohl in shapes.txt als auch in stop_times.txt angegeben werden, wenn eine Ausrichtung eine Rund- oder Inline-Route umfasst (Abschnitte werden während einer Fahrt mehrmals in der gleichen Richtung befahren).

Eine Inline-Route

Wenn ein Fahrzeug im Verlauf einer Fahrt einen früheren Teil der Route wiederholt oder kreuzt, ist shape_dist_traveled wichtig, um zu verdeutlichen, wie Teile der Punkte in shapes.txt den Datensätzen in stop_times.txt entsprechen.

Im Feld shape_dist_traveled kann der Betreiber genau angeben, wie die Haltestellen in der Datei stop_times.txt in die jeweilige Form passen. Ein häufiger Wert für das Feld shape_dist_traveled ist die Entfernung vom Start der Form, die das Fahrzeug zurückgelegt hat (z. B. eine Kilometeranzeige).
  • Die Routenausrichtungen (in shapes.txt) sollten sich im Umkreis von 100 m zu den Haltestellen befinden, die angefahren werden.
  • Vereinfachen Sie die Ausrichtungen so, dass shapes.txt keine überflüssigen Punkte enthält. Entfernen Sie hierzu beispielsweise überflüssige Punkte auf geraden Streckenabschnitten. Weitere Informationen hierzu finden Sie in der Diskussion zur Linienvereinfachung.

feed_info.txt

Die Datei feed_info.txt sollte mit allen unten stehenden Feldern enthalten sein.

Feldname Empfehlung
feed_start_date und feed_end_date Sollte enthalten sein
feed_version Sollte enthalten sein
feed_contact_email und feed_contact_url Machen Sie mindestens eine Angabe.

frequencies.txt

Feldname Empfehlung
Alle Felder Die tatsächlichen Haltestellenzeiten werden bei Fahrten, auf die frequencies.txt verweist, ignoriert. Für häufigkeitsbasierte Fahrten sind nur Fahrtzeitintervalle zwischen Haltestellen wichtig. Zur besseren Lesbarkeit sollte die erste Haltestelle einer in der Datei frequencies.txt referenzierten Fahrt bei null beginnen, das heißt, der erste arrival_time-Wert sollte „00:00:00“ sein.
block_id Kann für häufigkeitsbasierte Fahrten angegeben werden

transfers.txt

transfers.transfer_type kann einer von vier Werten sein, die in der GTFS-Datei definiert sind. Die folgenden transfer_type-Definitionen stammen aus der unten stehenden GTFS und enthalten zusätzliche Empfehlungen für Vorgehensweisen.

Feldname Empfehlung
transfer_type 0 oder (leer): Das ist ein empfohlener Umstiegspunkt zwischen Routen.

Wenn es mehrere Umsteigemöglichkeiten gibt, etwa einen Transitbahnhof mit zusätzlicher Ausstattung oder eine Haltestelle mit angrenzenden oder verbundenen Einstiegsmöglichkeiten, geben Sie einen empfohlenen Umstiegspunkt an.
1: Dies ist ein abgestimmter Umstiegspunkt zwischen zwei Routen. Hier soll das abfahrende Fahrzeug auf das ankommende warten. Dabei müssen Fahrgäste ausreichend Zeit zum Umsteigen haben.

Jeder Datennutzer verwendet zum Berechnen der Zeit, die er für dieses Intervall benötigt, seinen eigenen Algorithmus. Wenn dieser Wert nicht ausreicht oder es andere Bedingungen gibt, die der Nutzer nicht berücksichtigt hat, können Sie die Zeitberechnungen überschreiben, nachdem Sie den transfer_type auf 2 festgelegt haben, und die zulässige Mindestzeitspanne in Sekunden in min_transfer_time angeben.
2: Der Umstieg erfordert eine Mindestzeitspanne zwischen Ankunft und Abfahrt, damit die Fahrgäste den Anschluss schaffen. Die für den Umstieg erforderliche Zeit wird in min_transfer_time angegeben.

Geben Sie die minimale Umstiegszeit für den Fall an, dass es zwischen Haltestellen zu Verzögerungen kommt.
3: An diesem Ort sind keine Umstiege zwischen Routen möglich.

Geben Sie diesen Wert an, wenn Umstiege aufgrund von physischen Barrieren nicht möglich oder aufgrund von schwierigen Straßenübergängen oder Lücken im Fußgängernetz unsicher oder kompliziert sind.
Wenn Umstiege innerhalb eines Blocks zwischen Fahrten zulässig sind, muss die letzte Haltestelle der eingehenden Fahrt mit der ersten Haltestelle der abgehenden Fahrt übereinstimmen.

Nach Fall sortierte Empfehlungen für Vorgehensweisen

In diesem Abschnitt werden bestimmte Fälle mit Auswirkungen auf Dateien und Felder behandelt.

Rundrouten

Bei Rundrouten beginnen und enden Fahrten am selben Ort, etwa in einem Busbahnhof oder an einem Umstiegspunkt. Die Fahrzeuge fahren in der Regel fortlaufend und die Fahrgäste müssen an der letzten Haltestelle nicht aussteigen, sondern können die Runde von vorne beginnen.

Unten: Rundroute. Das Fahrzeug kehrt am Ende einer Fahrt zum Startpunkt zurück. Einige Rundrouten verlaufen in eine Richtung, während die Fahrzeuge bei anderen Rundrouten in zwei Richtungen fahren.
Eine Rundroute

Daher sollten die Empfehlungen für Zielschilder umgesetzt werden, damit die Fahrgäste erkennen können, in welche Richtung das Fahrzeug fährt.

Um auf einen Wechsel der Fahrtrichtung hinzuweisen, geben Sie stop_headsigns in der Datei stop_times.txt an. In stop_headsign ist die Richtung der Fahrten angegeben, die von der angegebenen Haltestelle abgehen, für die sie festgelegt ist. Wenn Sie stop_headsigns jeder Haltestelle einer Fahrt hinzufügen, können Sie das Zielschild während der Fahrt ändern.

Definieren Sie in der Datei stop_times.txt keine einzelne Rundfahrt für eine Route, die zwischen zwei Endhaltestellen verläuft (wenn also beispielsweise derselbe Bus hin und zurück fährt). Teilen Sie stattdessen die Fahrt in zwei getrennte Fahrtrichtungen auf.

Beispiele zur Definition einer Rundfahrt:

Rundfahrt mit wechselndem Zielschild an jeder Haltestelle:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "B"
trip_1 06:15:00 06:15:00 stop_B 2 "C"
trip_1 06:20:00 06:20:00 stop_C 3 "D"
trip_1 06:25:00 06:25:00 stop_D 4 "E"
trip_1 06:30:00 06:30:00 stop_E 5 "A"
trip_1 06:35:00 06:35:00 stop_A 6 ""

Rundfahrt mit zwei Zielschildern:

Trip_id arrival_time departure_time stop_id stop_sequence stop_headsign
trip_1 06:10:00 06:10:00 stop_A 1 "outbound"
trip_1 06:15:00 06:15:00 stop_B 2 "outbound"
trip_1 06:20:00 06:20:00 stop_C 3 "outbound"
trip_1 06:25:00 06:25:00 stop_D 4 "inbound"
trip_1 06:30:00 06:30:00 stop_E 5 "inbound"
trip_1 06:35:00 06:35:00 stop_F 6 "inbound"
trip_1 06:40:00 06:40:00 stop_A 7 ""
Feldname Empfehlung
trips.trip_id Modellieren Sie die komplette Runde mit einer einzigen Fahrt.
stop_times.stop_id Geben Sie für eine Fahrt auf einer Rundroute die erste bzw. letzte Haltestelle zweimal in stop_times.txt an. Ein Beispiel hierfür sehen Sie unten. Eine Rundroute kann oft erste und letzte Fahrten umfassen, bei denen nicht die gesamte Runde befahren wird. Schließen Sie diese Fahrten ebenfalls ein.
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id Wenn die Rundroute in entgegengesetzte Richtungen befahren wird (d. h. im und gegen den Uhrzeigersinn), legen Sie direction_id entweder auf 0 oder 1 fest.
trips.block_id Geben Sie Fahrten mit fortlaufender Rundroute mit derselben block_id an.

Lassorouten

Lassorouten sind eine Kombination aus Rundrouten und richtungsgebundenen Routen.

Unten: Lassorouten sind Rundrouten (von A nach A über B) mit drei Abschnitten:
  • Gerader Abschnitt von A nach B;
  • Rundroute von und nach B;
  • Gerader Abschnitt von B nach A
Eine Lassoroute
Beispiele:
U-Bahn-Routen (Chicago)
Busrouten von Vororten in die Innenstadt (St. Albert oder Edmonton)
Brown Line der CTA (CTA-Website und TransitFeeds)
Feldname Empfehlung
trips.trip_id Eine vollständige Rundroutenfahrt eines Fahrzeugs (siehe Abbildung oben) besteht aus Fahrt von A nach B, dann wieder nach B und schließlich zurück nach A. Eine solche Fahrt kann so ausgedrückt werden:
  • Ein einzelner trip_id-Wert/Datensatz in trips.txt
  • Mehrere Werte bzw. Datensätze für trip_id in trips.txt, wobei die fortlaufende Fahrt durch block_id angegeben wird.
    		•
    stop_times.stop_headsign Die Haltestellen entlang des A-B-Abschnitts werden in beiden Richtungen angefahren. Mithilfe von stop_headsign lassen sich die Fahrtrichtungen einfacher unterscheiden. Daher wird für diese Fahrten empfohlen, stop_headsign anzugeben.
    Beispiele:
    „A über B“
    „A“
    Purple Line der Chicago Transit Authority
    „Richtung Süden bis Rundroute“
    „Richtung Norden über Rundroute“
    „Richtung Norden nach Linden“
    Edmonton Transit Service Bus Lines, hier Linie 39
    „Rutherford“
    „Century Park“
    trip.trip_headsign Auf dem Zielschild sollte eine allgemeine Beschreibung der Fahrt angegeben sein, wie sie auch in den Fahrplänen zu sehen ist. Das könnte beispielsweise „Linden nach Linden über Rundroute“ (Beispiel aus Chicago) oder „A nach A über B“ (allgemeines Beispiel) sein.

    Zweige

    Einige Routen können Zweige haben. Ausrichtung und Haltestellen werden von diesen Zweigen gemeinsam genutzt, aber jeder Zweig hat auch seine eigenen Haltestellen und Ausrichtungsabschnitte. Die Beziehung zwischen Zweigen kann durch Routennamen, Zielschilder und Kurznamen für Fahrten angegeben werden. Beachten Sie hierfür die unten aufgeführten Richtlinien.

    Unten: drei mögliche Konfigurationen von Routenzweigen. Die primäre Ausrichtung wird schwarz dargestellt. Der Zweig ist goldfarben.
    Konfigurationen von Routenzweigen
    Feldname Empfehlung
    Alle Felder Für die Benennung von Routen von Zweigen sollten Sie sich nach anderen Informationsmaterialien für Fahrgäste richten. Im Folgenden finden Sie Beschreibungen und Beispiele für zwei Fälle:
    Wenn Fahrpläne und Schilder an der Straße zwei deutlich benannte Routen ausweisen (z. B. 1A und 1B), muss dies in der GTFS-Datei mithilfe der Felder route_short_name und/oder route_long_name entsprechend widergespiegelt werden. Beispiel: Die Routen 2, 2A und 2B von GoDurham Transit haben über den Großteil der Route hinweg eine gemeinsame Ausrichtung, sie unterscheiden sich jedoch in mehreren Aspekten.
    • Route 2 ist die Kernroute und wird die meiste Zeit befahren.
    • Nachts sowie an Sonn- und Feiertagen gibt es auf dieser Route eine Abweichung auf der Main Street.
    • Die Routen 2A und 2B fahren von Montag bis Samstag tagsüber.
    • Bei Route 2B gibt es Abweichungen von der gemeinsamen Ausrichtung, um zusätzliche Haltestellen anzufahren.
    Wenn in dem vom Betreiber bereitgestellten Informationsmaterial Zweige mit der gleich benannten Route beschrieben werden, verwenden Sie die Felder trips.trip_headsign, stop_times.stop_headsign und/oder trips.trip_short_name. Beispiel: Die GoTriangle-Route 300 bedient je nach Tageszeit verschiedene Standorte. Während der Hauptverkehrszeiten wird die Standardroute um zusätzliche Streckenabschnitte erweitert, um Pendler in die und aus der Stadt zu befördern.

    Dieses Dokument

    Zielsetzungen

    Durch die Einhaltung der Best Practices für GTFS lässt sich Folgendes erreichen:

    • Bessere Interoperabilität von Daten zu öffentlichen Verkehrsmitteln
    • Bessere Funktionen für Nutzer von Apps für öffentliche Verkehrsmittel
    • Einfachere Bereitstellung und Skalierung für Softwareentwickler Anwendungen, Produkte und Dienste
    • Vereinfachung des Einsatzes von GTFS in verschiedenen Anwendungskategorien (über den ursprünglichen Schwerpunkt der Fahrtenplanung hinaus)

    Neue Best Practices für GTFS vorschlagen oder bestehende Best Practices ändern

    GTFS-Anwendungen und -Vorgehensweisen werden weiterentwickelt, sodass dieses Dokument gelegentlich überarbeitet werden muss. Wenn Sie einen Änderungsvorschlag für dieses Dokument haben, starten Sie im GitHub-Repository zu den Best Practices für GTFS eine Pull-Anfrage und begründen Sie die gewünschte Änderung. Außerdem können Sie Kommentare per E-Mail an specifications@mobilitydata.org senden.

    Links zu diesem Dokument

    Bitte verweisen Sie auf dieses Dokument, damit Ersteller von Feeds Informationen zur korrekten Formatierung von GTFS-Daten abrufen können. Jede Empfehlung hat einen eigenen Ankerlink, dessen URL sich mit einem Klick abrufen lässt.

    Unter Umständen gibt es für eine Anwendung, die GTFS-Daten verarbeitet, Anforderungen oder Empfehlungen für die Nutzung von GTFS-Daten, die hier nicht beschrieben sind. In diesem Fall wird empfohlen, ein Dokument mit diesen Anforderungen oder Empfehlungen zu veröffentlichen, um diese gängigen Best Practices zu ergänzen.

    Arbeitsgruppe zu den Best Practices für GTFS

    Die Arbeitsgruppe zu den Best Practices für GTFS wurde in den Jahren 2016 und 2017 vom Rocky Mountain Institute mit dem Ziel einberufen, gängige Vorgehensweisen und Voraussetzungen für GTFS-Daten zu definieren. Dieser Gruppe gehörten Betreiber öffentlicher Verkehrsmittel, Entwickler von Anwendungen mit GTFS-Unterstützung, Berater und akademische Einrichtungen an. Hier eine Auswahl der Mitglieder:

    Heute wird dieses Dokument von MobilityData International Organization verwaltet.