GTFS Schedule Bewährte Praktiken¶

Dies sind empfohlene Praktiken für die Beschreibung von öffentlichen Verkehrsdiensten in der General Transit Feed Specification (GTFS. Diese Praktiken wurden aus den Erfahrungen der Mitglieder der GTFS Best Practices working group und anwendungsspezifischen GTFS zusammengeführt.

Weitere Hintergrundinformationen finden Sie in den Häufig gestellten Fragen.

Struktur des Dokuments¶

Die Praktiken sind in vier Hauptabschnitte unterteilt:

Veröffentlichung von Datensätzen und allgemeine Praktiken: Diese Praktiken beziehen sich auf die Gesamtstruktur des GTFS und auf die Art und Weise, in der GTFS veröffentlicht werden.
Nach Dateien geordnete Praxisempfehlungen: Die Empfehlungen sind nach Dateien und Feldern im GTFS geordnet, um die Zuordnung von Praktiken zur offiziellen GTFS zu erleichtern.
Praxisempfehlungen nach Fall gegliedert: In bestimmten Fällen, wie z. B. bei Schleifenrouten, müssen Praktiken möglicherweise in mehreren Dateien und Feldern angewendet werden. Solche Empfehlungen werden in diesem Abschnitt zusammengefasst.

Veröffentlichung von Datensätzen & Allgemeine Praktiken¶

Datensätze sollten unter einer öffentlichen, dauerhaften URL veröffentlicht werden, die auch den Namen der Zip-Datei enthält. (z. B. www.agency.org/gtfs/gtfs.zip). Im Idealfall sollte die URL direkt heruntergeladen werden können, ohne dass eine Anmeldung für den Zugriff auf die Datei erforderlich ist, um das Herunterladen durch Softwareanwendungen zu erleichtern. Es wird zwar empfohlen (und ist die gängigste Praxis), einen GTFS offen zum Herunterladen bereitzustellen, doch wenn ein Datenanbieter den Zugriff auf GTFS aus lizenzrechtlichen oder anderen Gründen kontrollieren muss, wird empfohlen, den Zugriff auf den GTFS mithilfe von API-Schlüsseln zu kontrollieren, was automatische Downloads erleichtert.
GTFS werden in Iterationen veröffentlicht, so dass eine einzige Datei an einem stabilen Ort immer die aktuellste offizielle Leistungsbeschreibung für ein Verkehrsunternehmen (oder mehrere Verkehrsunternehmen) enthält.
Beibehaltung dauerhafter Identifikatoren (id-Felder) für stop_id, route_id und agency_id über Dateniterationen hinweg, wann immer möglich.
Ein GTFS sollte den aktuellen und den kommenden Dienst enthalten (manchmal auch als "zusammengeführter" Datensatz bezeichnet). Die Merge-Funktion des Google-Transitfeed-Tools kann verwendet werden, um einen zusammengeführten Datensatz aus zwei verschiedenen GTFS zu erstellen.
- Der veröffentlichte GTFS sollte zu jedem Zeitpunkt mindestens für die nächsten 7 Tage gültig sein und idealerweise so lange, wie der Betreiber zuversichtlich ist, dass der Schedule weiterhin bedient wird.
- Wenn möglich, sollte der GTFS mindestens die nächsten 30 Tage des Betriebs abdecken.
Entfernen Sie alte Dienste (abgelaufene Kalender) aus dem Feed.
Wenn eine Serviceänderung innerhalb von 7 Tagen oder weniger in Kraft tritt, sollte diese Serviceänderung durch einen GTFS-realtime (Service Advisories oder Trip Updates) und nicht durch einen statischen GTFS dargestellt werden.
Der Web-Server, der die GTFS hostet, sollte so konfiguriert sein, dass er das Änderungsdatum der Datei korrekt meldet (siehe HTTP/1.1 - Request for Comments 2616, unter Abschnitt 14.29).

Praxisempfehlungen nach Datei geordnet¶

Dieser Abschnitt zeigt Praktiken, die nach Datei und Feld geordnet sind und sich an der GTFS orientieren.

Alle Dateien¶

Feldname	Empfehlung
Gemischte Großschreibung	Alle kundenorientierten Textstrings (einschließlich Haltestellennamen, Streckennamen und Vorwegweiser) sollten in gemischter Großschreibung (nicht in GANZ GROSSSCHREIBUNG) geschrieben werden, entsprechend den lokalen Konventionen für die Großschreibung von Ortsnamen auf Displays, die Kleinbuchstaben anzeigen können.
	Beispiele:
	Brighton Churchill-Platz
	Villiers-sur-Marne
	Marktstraße
Abkürzungen	Vermeiden Sie im gesamten Feed die Verwendung von Abkürzungen für Namen und anderen Text (z. B. St. für Straße), es sei denn, ein Ort wird mit seinem abgekürzten Namen genannt (z. B. "JFK Airport"). Abkürzungen können für die Zugänglichkeit durch Screenreader-Software und Sprachbenutzerschnittstellen problematisch sein. Verbrauchersoftware kann so entwickelt werden, dass sie ganze Wörter zuverlässig in Abkürzungen umwandelt, aber die Umwandlung von Abkürzungen in ganze Wörter ist fehleranfälliger.

agency.txt¶

Name des Feldes	Empfehlung
`agency_id`	Sollte enthalten sein, auch wenn nur eine Agentur im Feed vorhanden ist. (Siehe auch die Empfehlung zur Aufnahme von `agency_id` in `routes.txt` und `fare_attributes.txt`)
`agency_phone`	Sollte enthalten sein, es sei denn, es gibt keine Telefonnummer des Kundendienstes.
`agency_email`	Sollte enthalten sein, es sei denn, es gibt keine E-Mail an den Kundendienst.
`agency_fare_url`	Sollte enthalten sein, es sei denn, die Agentur ist vollständig tariffrei.

Beispiele:

Der Busverkehr wird von mehreren kleinen Busunternehmen betrieben. Es gibt jedoch eine große Agentur, die für die Fahrplangestaltung und das Ticketing zuständig ist und aus Sicht des Nutzers für den Busverkehr verantwortlich ist. Selbst wenn die Daten intern von verschiedenen kleinen Busunternehmen aufgeteilt werden, sollte nur eine Agentur im Feed definiert sein.
Der Feed-Anbieter betreibt das Fahrkartenportal, aber es gibt verschiedene Agenturen, die die Dienste tatsächlich betreiben und den Nutzern als verantwortlich bekannt sind. Die Agenturen, die die Dienste tatsächlich betreiben, sollten als Agenturen innerhalb des Feeds definiert werden.

stops.txt¶

Name des Feldes Empfehlung

stop_name Wenn es keinen veröffentlichten Haltestellennamen gibt, sollten Sie im gesamten Feed einheitliche Konventionen für die Benennung von Haltestellen einhalten.

Standardmäßig, stop_name keine generischen oder redundanten Wörter wie "Station" oder "Stop" enthalten, aber einige Sonderfälle sind zulässig.

Wenn es tatsächlich Teil des Namens ist (Union Station, Central Station
Wenn das stop_name zu allgemein ist (z. B. wenn es der Name der Stadt ist). "Station", "Terminal" oder andere Wörter machen die Bedeutung klar.

stop_lat & stop_lon Die Haltestellen sollten so genau wie möglich sein. Die Haltestellen sollten einen Fehler von nicht mehr als vier Meter im Vergleich zur tatsächlichen Position der Haltestelle aufweisen.

Die Haltestellen sollten in unmittelbarer Nähe der Fußgängerzone platziert werden, in die ein Fahrgast einsteigen wird (d.h. auf der richtigen Straßenseite).

Wenn ein Haltestellenstandort über verschiedene Dateneinspeisungen gemeinsam genutzt wird (d.h. zwei Agenturen nutzen genau dieselbe Haltestelle/Einstiegsmöglichkeit), zeigen Sie an, dass die Haltestelle gemeinsam genutzt wird, indem Sie für beide Haltestellen genau dieselbe stop_lat und stop_lon für beide Haltestellen.

parent_station & location_type

Viele Bahnhöfe oder Terminals verfügen über mehrere Einstiegsmöglichkeiten (je nach Verkehrsmittel können diese als Busbucht, Bahnsteig, Kai, Tor oder anders bezeichnet werden). In solchen Fällen sollten die Futtermittelhersteller die Bahnhöfe, die Einstiegsmöglichkeiten (auch als untergeordnete Haltestellen bezeichnet) und ihre Beziehung zueinander beschreiben.

Die Station oder das Terminal sollte als ein Datensatz in stops.txt mit location_type = 1.
Jede Einsteigemöglichkeit sollte als Haltestelle mit location_type = 0. Die parent_station Feld sollte sich auf die stop_id des Bahnhofs verweisen, in dem sich die Einstiegsmöglichkeit befindet.

Bei der Benennung der Haltestelle und der untergeordneten Haltestellen sollten Namen gewählt werden, die den Fahrgästen bekannt sind und ihnen helfen, die Haltestelle und die Einstiegsmöglichkeit zu identifizieren (Busbucht, Bahnsteig, Kai, Schranke, usw.).

Name der übergeordneten Haltestelle	Name der Kinderhaltestelle
Chicago Union Station	Chicago Union Station Bahnsteig 19
San Francisco Fährhaus Terminal	San Francisco Fährhaus Terminal Tor E
Downtown Transit Center	Downtown Transit Center Bucht B

routes.txt¶

Name des Feldes Empfehlung

agency_id Sollte enthalten sein, auch wenn nur eine Agentur im Feed vorhanden ist. (Siehe auch die Empfehlung, agency_id in agency.txt und fare_attributes.txt aufzunehmen)

route_short_name einschließen route_short_name wenn es eine kurze Dienstbezeichnung gibt. Dies sollte der allgemein bekannte Fahrgastname des Dienstes sein, nicht länger als 12 Zeichen.

route_long_name

Die Definition aus der Spezifikationsreferenz: Dieser Name ist im Allgemeinen aussagekräftiger als der route_kurz_name und enthält oft das Ziel oder die Haltestelle der Route. Mindestens eines von route_kurz_name oder route_long_name muss angegeben werden, möglicherweise auch beide, falls zutreffend. Wenn die Route keinen langen Namen hat, geben Sie bitte einen route_kurz_name und verwenden Sie eine leere Zeichenfolge als Wert für dieses Feld.
Beispiele für lange Namen sind unten aufgeführt:

Primärer Reiseweg oder Korridor
Name der Strecke	Formular	Agentur
"N"/"Juda"	`route_kurz_name`/ `route_long_name`	Muni, in San Francisco
"6"/"ML King Jr Blvd"	`route_kurz_name`/ `route_long_name`	TriMet, in Portland, Or.
PHP?nompdf=m6">"6"/"Nation - Étoile"	`route_kurz_name`/ `route_long_name`	RATP, in Paris Frankreich.
"U2"-"Pankow - Ruhleben"	`route_kurz_name`- `route_long_name`	BVG, in Berlin, Deutschland

Beschreibung des Dienstes
"Hartwell Area Shuttle"

route_long_name sollte nicht die route_short_name.

Fügen Sie die vollständige Bezeichnung einschließlich einer Service-Identität beim Ausfüllen ein route_long_name. Beispiele:

Dienst-Identität	Empfehlung	Beispiele
"MAX Light Rail" TriMet, in Portland, Oregon	Die `route_langer_name` sollte die Marke (MAX) und die spezifische Streckenbezeichnung enthalten	"MAX Rote Linie" "MAX Blaue Linie"
"Schnellbahn" ABQ Ride, in Albuquerque, New Mexico	Die `route_langer_name` sollte die Marke (Rapid Ride) und die spezifische Streckenbezeichnung enthalten	"Rapid Ride Rote Linie" "Rapid Ride Blue Line"

route_id Alle Fahrten auf einer bestimmten benannten Strecke sollten sich auf dieselbe beziehen. route_id.
Die verschiedenen Richtungen einer Strecke sollten nicht in verschiedene Werte aufgeteilt werden. route_id Werte unterteilt werden.
Unterschiedliche Betriebszeiträume einer Strecke sollten nicht in verschiedene Werte aufgeteilt werden. route_id Werte unterteilt werden, d.h. es sollten keine unterschiedlichen Datensätze in routes.txt für "Downtown AM" und "Downtown PM" Dienste).

Wenn eine Liniengruppe deutlich benannte Zweige umfasst (z. B. 1A und 1B), folgen Sie den Empfehlungen in den Linien Zweige Fall zu bestimmen route_short_name und route_long_name.

route_color & route_text_color Sollte mit der Beschilderung und den gedruckten und Online-Kundeninformationen übereinstimmen (und daher nicht enthalten sein, wenn es sie an anderen Stellen nicht gibt).

trips.txt¶

Siehe Sonderfall für Schleifenrouten: Schleifenrouten sind Fahrten, die an derselben Haltestelle beginnen und enden, im Gegensatz zu linearen Routen, die zwei verschiedene Endpunkte haben. Schleifenrouten müssen nach bestimmten Verfahren beschrieben werden. Siehe Sonderfall Schleifenrouten.
Siehe Sonderfall für Lasso-Routen: Lasso-Routen sind eine Mischform aus linearen und Schleifen-Routen, bei denen die Fahrzeuge nur einen Teil der Strecke in einer Schleife fahren. Lasso-Routen müssen nach bestimmten Verfahren beschrieben werden. Siehe Fall Lasso-Route.

Name des Feldes Empfehlung

trip_headsign Geben Sie keine Routennamen (passend zu route_short_name und route_long_name) in der Datei trip_headsign oder stop_headsign Felder.

Sollte Ziel-, Richtungs- und/oder anderen Fahrtbezeichnungstext enthalten, der auf dem Frontschild des Fahrzeugs angezeigt wird und zur Unterscheidung von Fahrten auf einer Strecke verwendet werden kann. Die Übereinstimmung mit den auf dem Fahrzeug angezeigten Richtungsangaben ist das primäre und vorrangige Ziel bei der Bestimmung der in GTFS gelieferten Frontschilder. Andere Informationen sollten nur dann aufgenommen werden, wenn sie dieses Hauptziel nicht beeinträchtigen. Wenn sich die Vorzeichen während einer Fahrt ändern, sind die Angaben trip_headsign mit stop_times.stop_headsign. Nachstehend finden Sie Empfehlungen für einige mögliche Fälle:

Beschreibung der Route	Empfehlung
2A. Nur Ziel	Geben Sie die Endstation an, z. B. "Transit Center", "Portland City Center" oder "Jantzen Beach">
2B. Zielorte mit Wegpunkten	über " Highgate über Charing Cross". Wenn Wegpunkte aus der Anzeige für die Fahrgäste entfernt werden, nachdem das Fahrzeug diese Wegpunkte passiert hat, verwenden Sie `stop_times.stop_headsign` um eine aktualisierte Vorankündigung einzustellen.>
2C. Regionaler Ortsname mit lokalen Haltestellen	Wenn innerhalb der Zielstadt oder des Zielbezirks mehrere Haltestellen vorgesehen sind, verwenden Sie `stop_times.stop_headsign` sobald Sie die Zielstadt erreicht haben.>
2D. Nur für die Fahrtrichtung	Geben Sie Bezeichnungen wie "Northbound", "Inbound", "Clockwise" oder ähnliche Richtungen an.>
2E. Richtung mit Zielort	z. B. "Südwärts nach San Jose">
2F. Richtung mit Ziel und Wegpunkten	via to ( "Northbound via Charing Cross to Highgate").>

Beginnen Sie ein Vorzeichen nicht mit den Worten "To" oder "Towards".

direction_id

Verwenden Sie im gesamten Datensatz einheitlich die Werte 0 und 1, d. h.

Wenn 1 = Ausgehend auf der roten Route, dann 1 = Ausgehend auf der grünen Route
Wenn 1 = Nordwärts auf Route X, dann 1 = Nordwärts auf Route Y
Wenn 1 = im Uhrzeigersinn auf der Route X, dann 1 = im Uhrzeigersinn auf der Route Y

stop_times.txt¶

Schleifenrouten: Schleifenrouten erfordern besondere Überlegungen zu den Haltestellen_Zeiten. (Siehe: Schleifenroutenfall)

Name des Feldes Empfehlung

pickup_type & drop_off_type Fahrten ohne Einnahmen (Leerfahrten), die keine Fahrgäste befördern, sollten mit pickup_type und drop_off_type Wert von 1 für alle stop_times Zeilen.

Bei Fahrten im Linienverkehr sollten interne "Zeitpunkte" zur Überwachung der betrieblichen Leistung und andere Orte wie Garagen, in die ein Fahrgast nicht einsteigen kann, mit pickup_type = 1 (keine Abholung möglich) und drop_off_type = 1 (kein Absetzen möglich).

timepoint Das Feld timepoint sollte angegeben werden. Es gibt an, welche stop_times der Betreiber strikt einzuhalten versucht(timepoint=1), und dass andere Stoppzeiten Schätzungen sind(timepoint=0).

arrival_time & departure_time arrival_time und departure_time Felder sollten, wann immer möglich, Zeitwerte angeben, einschließlich nicht verbindlicher geschätzter oder interpolierter Zeiten zwischen Zeitpunkten.

stop_headsign Im Allgemeinen sollten die Vorzeichenwerte auch den Vorzeichen an den Bahnhöfen entsprechen.

In den folgenden Fällen würde "Southbound" die Kunden in die Irre führen, da es in den Bahnhofsschildern nicht verwendet wird.

In NYC, für die 2 in Richtung Süden:
Für `stop_times.txt` rows:	verwenden `stop_headsign` Wert:
Bis Manhattan erreicht ist	`Manhattan & Brooklyn`
Bis Downtown erreicht ist	`Stadtzentrum & Brooklyn`
Bis Brooklyn erreicht ist	`Brooklyn`
Sobald Brooklyn erreicht ist	`Brooklyn (New Lots Av)`

In Boston, für die Red Line in Richtung Süden, für den Zweig Braintree:
Für `stop_times.txt` Zeilen:	Verwenden Sie `stop_headsign` Wert:
Bis Downtown erreicht ist	`Eingehend nach Braintree`
Nach Erreichen von Downtown	`Braintree`
Nach Downtown	`Ausgehend nach Braintree`

shape_dist_traveled shape_dist_traveled muss für Routen mit Schleifen oder Inlinern angegeben werden (das Fahrzeug kreuzt oder überfährt denselben Abschnitt der Strecke in einer Fahrt). Siehe die shapes.shape_dist_traveled Empfehlung.

calendar.txt¶

Name des Feldes	Empfehlung
Alle Felder	Einschließlich a `calendar.service_name` Feldes kann auch die Lesbarkeit von GTFS erhöhen, obwohl dies in der Spezifikation nicht vorgesehen ist.

calendar_dates.txt¶

Name des Feldes	Empfehlung
Alle Felder	Einschließlich eines `calendar.service_name` Die Aufnahme eines Feldes kann auch die Lesbarkeit von GTFS erhöhen, obwohl dies in der Spezifikation nicht vorgesehen ist.

fare_attributes.txt¶

Name des Feldes	Empfehlung
`agency_id`	Sollte enthalten sein, auch wenn nur eine Agentur im Feed vorhanden ist. (Siehe auch die Empfehlung, `agency_id` in `agency.txt` und `routes.txt` aufzunehmen)
	Wenn ein Tarifsystem nicht genau modelliert werden kann, vermeiden Sie weitere Verwirrung und lassen Sie das Feld leer.
	Fahrpreise einbeziehen (`fare_attributes.txt` und `fare_rules.txt`) und modellieren Sie sie so genau wie möglich. In den Randfällen, in denen Fahrpreise nicht genau modelliert werden können, sollte der Fahrpreis als teurer und nicht als billiger dargestellt werden, damit die Kunden nicht versuchen, mit einem unzureichenden Fahrpreis einzusteigen. Wenn die überwiegende Mehrheit der Fahrpreise nicht korrekt modelliert werden kann, sollten Sie keine Fahrpreisinformationen in den Feed aufnehmen.

fare_rules.txt¶

Name des Feldes Empfehlung

Alle Felder Wenn ein Tarifsystem nicht genau modelliert werden kann, vermeiden Sie weitere Verwirrung und lassen Sie es leer.

Fahrpreise einbeziehen (fare_attributes.txt und fare_rules.txt) und modellieren Sie sie so genau wie möglich. In Grenzfällen, in denen Fahrpreise nicht genau modelliert werden können, sollte der Fahrpreis als teurer und nicht als billiger dargestellt werden, damit die Kunden nicht versuchen, mit einem unzureichenden Fahrpreis einzusteigen. Wenn die überwiegende Mehrheit der Fahrpreise nicht korrekt modelliert werden kann, sollten Sie keine Fahrpreisinformationen in den Feed aufnehmen.

shapes.txt¶

Name des Feldes	Empfehlung
Alle Felder	Idealerweise sollte bei gemeinsam genutzten Strecken (z. B. wenn die Linien 1 und 2 auf demselben Straßenabschnitt oder Gleis verkehren) der gemeinsam genutzte Teil der Strecke genau übereinstimmen. Dies trägt dazu bei, eine qualitativ hochwertige Transitkartographie zu ermöglichen.
	Die Trassen sollten der Mittellinie der Vorfahrtsstraße folgen, auf der das Fahrzeug verkehrt. Dies kann entweder die Mittellinie der Straße sein, wenn es keine ausgewiesenen Fahrspuren gibt, oder die Mittellinie der Seite der Fahrbahn, die in Fahrtrichtung des Fahrzeugs verläuft. Die Ausrichtung sollte nicht zu einer Bordsteinkante, einem Bahnsteig oder einer Einstiegsstelle "zacken".
`shape_dist_traveled`	Muss in beiden Fällen vorhanden sein `shapes.txt` und `stop_times.txt` wenn eine Trasse eine Schleife oder ein Inlining beinhaltet (das Fahrzeug überquert oder überfährt denselben Teil der Trasse in einer Fahrt). Wenn ein Fahrzeug die Streckenführung an bestimmten Punkten im Verlauf einer Fahrt zurückverfolgt oder kreuzt, `shape_dist_traveled` ist es wichtig zu klären, wie Teile der Punkte in `shapes.txt` Aufreihung mit Aufzeichnungen in `stop_times.txt`.
	Die `shape_dist_traveled` Das Feld "Line Up" ermöglicht es der Agentur, genau anzugeben, wie die Haltestellen in der `stop_times.txt` Datei in ihre jeweilige Form passen. Ein üblicher Wert für das Feld `shape_dist_traveled` ist die Entfernung vom Anfang der Form, wie sie vom Fahrzeug zurückgelegt wurde (denken Sie an einen Kilometerzählerstand). Streckenausrichtungen (in `shapes.txt`) sollten innerhalb von 100 Metern von Haltestellen liegen, die eine Fahrt bedient. Vereinfachen Sie Ausrichtungen so, dass `shapes.txt` keine fremden Punkte enthält (d. h. entfernen Sie zusätzliche Punkte auf geradlinigen Segmenten; siehe Diskussion des Problems der Linienvereinfachung).

frequencies.txt¶

Name des Feldes Empfehlung

Alle Felder Tatsächliche Haltestellenzeiten werden für Fahrten ignoriert, auf die mit frequencies.txtreferenziert werden; für frequenzbasierte Fahrten sind nur die Fahrzeitintervalle zwischen den Haltestellen von Bedeutung. Aus Gründen der Übersichtlichkeit/Lesbarkeit wird empfohlen, dass die erste Haltestellenzeit einer Fahrt, die in frequencies.txt referenziert wird, um 00:00:00 beginnen sollte (erster arrival_time Wert von 00:00:00).

block_id Kann für frequenzabhängige Fahrten angegeben werden.

transfers.txt¶

transfers.transfer_type kann einer der vier im GTFS definierten Werte sein. Diese transfer_type-Definitionen werden im Folgenden aus der GTFS zitiert ( kursiv) und mit zusätzlichen Empfehlungen für die Praxis versehen.

Name des Feldes	Empfehlung
`transfer_type`	0 oder (leer): Dies ist ein empfohlener Umsteigepunkt zwischen Routen. Wenn es mehrere Umsteigemöglichkeiten gibt, die eine bessere Option beinhalten (z. B. ein Transitzentrum mit zusätzlichen Annehmlichkeiten oder ein Bahnhof mit angrenzenden oder verbundenen Einstiegsmöglichkeiten/Plattforms), geben Sie einen empfohlenen Umsteigepunkt an.
	1: Dies ist ein zeitlich festgelegter Umsteigepunkt zwischen zwei Linien. Es wird erwartet, dass das abfahrende Fahrzeug auf das ankommende Fahrzeug wartet, so dass der Fahrgast genügend Zeit hat, zwischen den Linien umzusteigen. Diese Art des Umsteigens setzt ein erforderliches Intervall für ein zuverlässiges Umsteigen außer Kraft. Google Maps geht beispielsweise davon aus, dass Fahrgäste 3 Minuten benötigen, um sicher umsteigen zu können. Andere Anwendungen können andere Standardwerte annehmen.
	2: Dieser Transfer erfordert eine Mindestzeit zwischen Ankunft und Abfahrt, um eine Verbindung zu gewährleisten. Die für den Transfer benötigte Zeit wird angegeben durch `min_transfer_time`. Geben Sie die Mindestumsteigezeit an, wenn es Hindernisse oder andere Faktoren gibt, die die Fahrtzeit zwischen den Haltestellen verlängern.
	3: Umsteigevorgänge zwischen Linien sind an dieser Stelle nicht möglich. Geben Sie diesen Wert an, wenn ein Umsteigen aufgrund physischer Hindernisse nicht möglich ist oder wenn es durch schwierige Straßenüberquerungen oder Lücken im Fußgängernetz unsicher oder kompliziert wird.
	Wenn ein Umsteigen zwischen Fahrten in einem Sitzplatz (Block) möglich ist, muss die letzte Haltestelle der ankommenden Fahrt mit der ersten Haltestelle der abfahrenden Fahrt übereinstimmen.

feed_info.txt¶

feed_info.txt sollte mit allen unten aufgeführten Feldern enthalten sein.

Name des Feldes	Empfehlung
`feed_start_date` & `feed_end_date`	Sollte enthalten sein
`feed_version`	Sollte eingeschlossen werden
`feed_contact_email` & `feed_contact_url`	Geben Sie mindestens ein

Praxisempfehlungen nach Fällen geordnet¶

In diesem Abschnitt werden besondere Fälle behandelt, die sich auf alle Dateien und Felder auswirken.

Schleifenrouten¶

Auf Schleifenrouten beginnen und enden die Fahrten der Fahrzeuge am selben Ort (manchmal ein Transit- oder Transferzentrum). Die Fahrzeuge verkehren in der Regel kontinuierlich und ermöglichen es den Fahrgästen, an Bord zu bleiben, während das Fahrzeug seine Schleife fortsetzt.

Daher sollten die Empfehlungen für die Beschilderung angewendet werden, um den Fahrgästen die Fahrtrichtung anzuzeigen.

Um die wechselnde Fahrtrichtung anzuzeigen, sind in der Datei stop_times.txt stop_headsigns anzugeben. Das stop_headsign beschreibt die Fahrtrichtung für Fahrten, die von der Haltestelle abfahren, für die es definiert ist. Durch Hinzufügen von stop_headsigns zu jeder Haltestelle einer Fahrt können Sie die Fahrtrichtungsinformationen entlang einer Fahrt ändern.

Definieren Sie in der Datei stop_times.txt txt nicht eine einzige Rundfahrt für eine Route, die zwischen zwei Endpunkten verkehrt (z. B. wenn derselbe Bus hin und zurück fährt). Teilen Sie die Fahrt stattdessen in zwei separate Fahrtrichtungen auf.

Beispiele für die Modellierung von Rundfahrten:

Rundfahrt mit wechselndem Vorzeichen für jede Haltestelle

trip_id	ankunft_zeit	Abfahrt_Zeit	stop_id	stop_sequence	stop_headsign
Fahrt_1	06:10:00	06:10:00	Haltestelle_A	1	"B"
Fahrt_1	06:15:00	06:15:00	Haltestelle_B	2	"C"
Auslösung_1	06:20:00	06:20:00	Haltestelle_C	3	"D"
Auslösung_1	06:25:00	06:25:00	Haltestelle_D	4	"E"
Auslösung_1	06:30:00	06:30:00	Haltestelle_E	5	"A"
Reise_1	06:35:00	06:35:00	Haltestelle_A	6	""

Rundfahrt mit zwei Vorfahrtsschildern

trip_id	Ankunft_Zeit	Abfahrtszeit	stop_id	stop_sequence	stop_headsign
Reise_1	06:10:00	06:10:00	Haltestelle_A	1	"ausgehend"
Reise_1	06:15:00	06:15:00	Haltestelle_B	2	"ausgehend"
Reise_1	06:20:00	06:20:00	Haltestelle_C	3	"Ausgehend"
Reise_1	06:25:00	06:25:00	Halt_D	4	"eingehend"
Reise_1	06:30:00	06:30:00	stop_E	5	"eingehend"
Reise_1	06:35:00	06:35:00	Haltestelle_F	6	"eingehend"
Reise_1	06:40:00	06:40:00	Haltestelle_A	7	""

Name des Feldes Empfehlung

trips.trip_id Modellieren Sie die komplette Rundfahrt für die Schleife mit einer einzigen Fahrt.

stop_times.stop_id

Fügen Sie den ersten/letzten Halt zweimal in stop_times.txt für die Fahrt, die eine Schleife ist. Beispiel unten. Oft enthält eine Schleifenroute erste und letzte Fahrten, die nicht die gesamte Schleife durchfahren. Diese Fahrten sind ebenfalls einzubeziehen.

`trip_id`	`stop_id`	`stop_sequence`
9000	101	1
9000	102	2
9000	103	3
9000	101	4

trips.direction_id Wenn die Schleife in entgegengesetzter Richtung betrieben wird (d. h. im und gegen den Uhrzeigersinn), ist Folgendes anzugeben direction_id als 0 oder 1.

trips.block_id Endlosschleifenfahrten mit demselben Namen angeben block_id.

Lasso-Routen¶

Lasso-Routen kombinieren Aspekte einer Schleifenroute und einer Richtungsroute.

Beispiele:
U-Bahn-Routen (Chicago)
Bus Vorort-Zentrum-Routen (St. Albert oder Edmonton)
CTA Braune Linie (CTA-Website und TransitFeeds)

Name des Feldes Empfehlung

trips.trip_id Der gesamte Umfang einer "Fahrzeugrundfahrt" (siehe Abbildung oben) besteht aus der Fahrt von A nach B nach B und zurück nach A. Eine gesamte Fahrzeugrundfahrt kann durch ausgedrückt werden:
A einzeln trip_id Wert/Datensatz in trips.txt
Mehrere trip_id Werte/Datensätze in trips.txt, wobei eine kontinuierliche Fahrt durch block_id.

stop_times.stop_headsign

Die Haltestellen entlang des Abschnitts A-B werden in beiden Richtungen durchfahren. stop_headsign erleichtert die Unterscheidung der Fahrtrichtung. Daher wird die Angabe stop_headsign wird daher für diese Fahrten empfohlen.example_table:

Beispiele:
"A über B"
"A"

Chicago Transit Authority's Purple Line
"Südwärts zur Schleife"
"Nordwärts über Schleife"
"Nordwärts nach Linden"

Edmonton Transit Service Buslinien, hier die 39
"Rutherford"
"Jahrhundert-Park"

trip.trip_headsign Das Fahrtenschild sollte eine globale Beschreibung der Fahrt sein, wie sie in den Fahrplänen angezeigt wird. Das könnte sein: "Linden nach Linden über Loop" (Beispiel Chicago) oder "A nach A über B" (allgemeines Beispiel).

Abzweigungen¶

Einige Routen können Abzweigungen enthalten. Die Linienführung und die Haltestellen werden von diesen Zweigen gemeinsam genutzt, aber jeder Zweig bedient auch eigene Haltestellen und Linienabschnitte. Die Beziehung zwischen den Zweigen kann durch den/die Routennamen, die Vorfahrtsschilder und die Kurzbezeichnung der Strecke unter Verwendung der folgenden Richtlinien angegeben werden.

Feldname	Empfehlung
Alle Felder	Es wird empfohlen, sich bei der Benennung von Zweigstrecken an anderen Fahrgastinformationsmaterialien zu orientieren. Nachstehend finden Sie Beschreibungen und Beispiele für zwei Fälle:
	Wenn Fahrpläne und Beschilderung auf der Straße zwei eindeutig benannte Strecken darstellen (z. B. 1A und 1B), dann ist dies im GTFS unter Verwendung der `route_short_name` und/oder `route_long_name` Felder. Beispiel: GoDurham Transit Die Linien 2, 2A und 2B haben über den größten Teil der Strecke eine gemeinsame Ausrichtung, unterscheiden sich aber in verschiedenen Aspekten. Die Linie 2 ist die Hauptlinie und verkehrt zu den meisten Stunden. Die Route 2 beinhaltet eine Abweichung in den Nächten auf der Main Street, an Sonn- und Feiertagen. Die Linien 2A und 2B verkehren tagsüber von Montag bis Samstag. Die Linie 2B bedient zusätzliche Haltestellen in einer Abweichung von der gemeinsamen Trasse.
	Wenn die von der Agentur zur Verfügung gestellten Informationen die Zweigstellen als die gleichnamige Route beschreiben, dann verwenden Sie die `trips.trip_headsign`, `stop_times.stop_headsign`und/oder `trips.trip_short_name` Felder. Beispiel: GoTriangle Strecke 300 fährt je nach Tageszeit zu verschiedenen Orten. Während der Hauptverkehrszeiten werden zusätzliche Streckenabschnitte zur Standardroute hinzugefügt, um den ein- und ausfahrenden Arbeitnehmern entgegenzukommen.

Häufig gestellte Fragen (FAQ)¶

Warum sind diese GTFS wichtig?¶

Die Ziele der GTFS sind:

Verbesserung der Endnutzererfahrung mit Apps für den öffentlichen Verkehr
Unterstützung einer umfassenden Dateninteroperabilität, um Softwareentwicklern die Bereitstellung und Skalierung von Anwendungen, Produkten und Dienstleistungen zu erleichtern
Erleichterung des Einsatzes von GTFS in verschiedenen Anwendungskategorien (über den ursprünglichen Fokus auf die Reiseplanung hinaus)

Ohne koordinierte GTFS Practices können verschiedene GTFS Anwendungen Anforderungen und Erwartungen auf unkoordinierte Weise festlegen, was zu divergierenden Anforderungen und anwendungsspezifischen Datensätzen und weniger Interoperabilität führt. Vor der Veröffentlichung der Best Practices herrschte größere Unklarheit und Uneinigkeit darüber, was korrekt geformte GTFS sind.

Wie wurden sie entwickelt? Wer hat sie entwickelt?¶

Diese Best Practices wurden von einer Arbeitsgruppe aus 17 Organisationen entwickelt, die an GTFS beteiligt sind, darunter App-Anbieter und Datenkonsumenten, Verkehrsbetriebe und Berater mit umfassender Beteiligung an GTFS. Die Arbeitsgruppe wurde vom Rocky Mountain Institute einberufen und moderiert.

Die Mitglieder der Arbeitsgruppe stimmten über die einzelnen Best Practices ab. Die meisten Best Practices wurden einstimmig angenommen. In einigen wenigen Fällen wurden die Best Practices von einer großen Mehrheit der Organisationen angenommen.

Warum wird nicht einfach die GTFS geändert?¶

Gute Frage! Der Prozess der Untersuchung der Spezifikation, der Datennutzung und des Bedarfs hat in der Tat einige Änderungen an der Spezifikation ausgelöst (siehe geschlossene Pull Requests in GitHub). Änderungen an der Spezifikation unterliegen einer strengeren Prüfung und Kommentierung als die Best Practices. Dennoch war es notwendig, sich auf eine klare Reihe von Best-Practice-Empfehlungen zu einigen.

Die Arbeitsgruppe geht davon aus, dass einige GTFS schließlich Teil der GTFS werden.

Überprüfen GTFS die Übereinstimmung mit diesen Best Practices?¶

Kein Validierungswerkzeug prüft derzeit die Übereinstimmung mit allen Best Practices. Verschiedene Validierungstools überprüfen die Übereinstimmung mit einigen dieser Best Practices. Eine Liste der GTFS finden Sie unter GTFS Validators. Wenn Sie ein GTFS schreiben, das auf diese Best Practices verweist, senden Sie bitte eine E-Mail an specifications@mobilitydata.org.

Ich vertrete ein Verkehrsunternehmen. Welche Maßnahmen kann ich ergreifen, damit unsere Softwaredienstleister und Anbieter diese Best Practices befolgen?¶

Verweisen Sie Ihren Anbieter oder Softwaredienstleister auf diese Best Practices. Wir empfehlen, bei der Beschaffung von GTFS auf die URL der GTFS Practices sowie auf die Core Spec Reference zu verweisen.

Was sollte ich tun, wenn ich feststelle, dass ein GTFS nicht mit diesen Best Practices übereinstimmt?¶

Identifizieren Sie den Kontakt für den Feed, indem Sie die vorgeschlagenen Felder feed_contact_email oder feed_contact_url in feed_info.txt verwenden, falls sie vorhanden sind, oder indem Sie die Kontaktinformationen auf der Website des Verkehrsunternehmens oder des Feedherstellers suchen. Wenn Sie das Problem dem Futtermittelhersteller mitteilen, verweisen Sie auf die spezifische GTFS Best Practice, die zur Diskussion steht. (Siehe "Verlinkung zu diesem Dokument").

Ich möchte eine Änderung/Ergänzung zu den Best Practices vorschlagen. Wie kann ich das tun?¶

Schicken Sie eine E-Mail an specifications@mobilitydata.org oder öffnen Sie eine Anfrage oder einen Pull Request im GitHub GTFS Best Practices repo.

Wie kann ich mich einbringen?¶

Senden Sie eine E-Mail an specifications@mobilitydata.org.

Über dieses Dokument¶

Ziele¶

Die Ziele der Beibehaltung der GTFS Best Practices sind:

Unterstützung einer größeren Interoperabilität von Verkehrsdaten
Verbesserung der Kundenerfahrung der Endnutzer bei Anwendungen für den öffentlichen Verkehr
Erleichterung der Bereitstellung und Skalierung von Anwendungen, Produkten und Dienstleistungen für Softwareentwickler
Erleichterung des Einsatzes von GTFS in verschiedenen Anwendungskategorien (über den ursprünglichen Fokus auf die Reiseplanung hinaus)

Wie man veröffentlichte GTFS vorschlägt oder ändert¶

GTFS und -Praktiken entwickeln sich weiter, so dass dieses Dokument möglicherweise von Zeit zu Zeit geändert werden muss. Um eine Änderung dieses Dokuments vorzuschlagen, öffnen Sie eine Pull-Anfrage im GitHub-Repository GTFS Best Practices und befürworten Sie die Änderung. Sie können Kommentare auch per E-Mail an specifications@mobilitydata.org senden.

Verlinkung auf dieses Dokument¶

Bitte verlinken Sie hier, um Feed-Produzenten eine Anleitung für die korrekte Erstellung von GTFS zu geben. Jede einzelne Empfehlung ist mit einem Ankerlink versehen. Klicken Sie auf die Empfehlung, um die URL für den seiteninternen Ankerlink zu erhalten.

Wenn eine GTFS Anwendung Anforderungen oder Empfehlungen für GTFS stellt, die hier nicht beschrieben sind, wird empfohlen, ein Dokument mit diesen Anforderungen oder Empfehlungen zu veröffentlichen, um diese allgemeinen bewährten Praktiken zu ergänzen.

ArbeitsgruppeGTFS¶

Die GTFS Best Practices Working Group wurde 2016-17 vom Rocky Mountain Institute einberufen und bestand aus Anbietern öffentlicher Verkehrsmittel, Entwicklern von GTFS Anwendungen, Beratern und akademischen Organisationen, um gemeinsame Praktiken und Erwartungen für GTFS zu definieren:

Heute wird dieses Dokument von MobilityData verwaltet.