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:
- Veröffentlichung von und allgemeine Vorgehensweisen für Datasets: Diese Best Practices beziehen sich auf die Gesamtstruktur des GTFS-Datasets und auf die Veröffentlichung von GTFS-Datasets.
- Nach Datei sortierte Empfehlungen für Vorgehensweisen: Empfehlungen werden nach Datei und Feld in GTFS sortiert, um die Zuordnung von Best Practices zur offiziellen GTFS-Referenz zu vereinfachen.
- Nach Fall sortierte Empfehlungen für Vorgehensweisen: In bestimmten Fällen, etwa bei Rundrouten, müssen die Best Practices möglicherweise auf mehrere Dateien und Felder angewendet werden. Solche Empfehlungen sind in diesem Abschnitt zusammengefasst.
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.
|
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.
|
|||||||||
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.
|
||||||||
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.
|
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 Beispiele für Arten von langen Namen:
|
||||||||||||||||||||
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:
|
|||||||||||||||||||||
route_id |
Alle Fahrten auf einer bestimmten benannten Route sollten auf dieselbe route_id verweisen.
|
||||||||||||||||||||
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:
|
|||||||||||||||
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:
|
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 |
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. |
||||||||||||
|
|||||||||||||
|
|||||||||||||
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 Wenn ein Fahrzeug im Verlauf einer Fahrt einen früheren Teil der Route wiederholt oder kreuzt, ist |
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).
|
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 |
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. |
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 |
|
Geben Sie die minimale Umstiegszeit für den Fall an, dass es zwischen Haltestellen zu Verzögerungen kommt. |
|
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.
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.
|
|||||||||||||||
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.
- Gerader Abschnitt von A nach B;
- Rundroute von und nach B;
- Gerader Abschnitt von B nach A
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:
trip_id -Wert/Datensatz in trips.txt
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.
|
||||||||||
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.
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.
|
|
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:
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research an der University of South Florida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Verkehrsministerium des US-Bundesstaates Oregon
- Swiftly
- Transit
- Trillium
- TriMet
- Weltbank
Heute wird dieses Dokument von MobilityData International Organization verwaltet.