In diesem Dokument werden das Format und die Struktur der Dateien definiert, die zusammen ein GTFS-Dataset bilden.
Inhalt
Begriffsdefinitionen
Dieser Abschnitt enthält die Definitionen der in diesem Dokument verwendeten Begriffe.
- Dataset: Ein vollständiger Satz der Dateien, die durch diese Spezifikationsreferenz definiert werden. Beim Ändern des Datasets wird eine neue Version davon erstellt. Datasets sollten unter einer öffentlichen, permanenten URL mit dem Namen der ZIP-Datei veröffentlicht werden (z. B. https://www.agency.org/gtfs/gtfs.zip).
- Datensatz: Eine grundlegende Datenstruktur, die aus verschiedenen Feldwerten besteht, die eine einzelne Entität beschreiben (z. B. Betreiber, Haltestelle, Route). Entspricht einer Zeile in einer Tabelle.
- Feld: Eigenschaft eines Objekts oder einer Entität. Entspricht einer Spalte in einer Tabelle.
- Feldwert: Ein einzelner Eintrag in einem Feld. Entspricht einer Zelle in einer Tabelle.
- Erforderlich: Das Feld muss im Dataset enthalten sein und in dem Feld muss für jeden Datensatz ein Wert angegeben werden. Bei einigen Pflichtfeldern ist ein leerer String als Wert zulässig. Er wird in dieser Spezifikation als „leer“ bezeichnet. Falls Sie einen leeren String eingeben möchten, lassen Sie im entsprechenden Feld einfach den Text zwischen den Kommas weg.
- Optional: Das Feld kann im Dataset weggelassen werden. Wenn eine optionale Spalte vorhanden ist, können einige Einträge in diesem Feld leere Strings sein. Falls Sie einen leeren String eingeben möchten, lassen Sie im entsprechenden Feld einfach den Text zwischen den Kommas weg. Ein weggelassenes Feld entspricht einem, das vollständig leer ist.
- Bedingt erforderlich: Das Feld oder die Datei ist unter bestimmten Bedingungen erforderlich, die in der Feld- oder Dateibeschreibung angegeben sind. Ansonsten ist das Feld oder die Datei optional.
- Betriebstag: Ein Betriebstag ist ein Zeitraum, der in der Routenplanung verwendet wird. Die genaue Definition davon variiert von Betreiber zu Betreiber, aber Betriebstage entsprechen oft nicht Kalendertagen. Ein Betriebstag kann länger als 24:00:00 Stunden sein, wenn er an einem Tag beginnt und am folgenden endet. Wird beispielsweise von Freitag 08:00:00 bis Samstag 02:00:00 Uhr gefahren, kann das als ein einzelner Betriebstag von 08:00:00 bis 26:00:00 Uhr beschrieben werden.
Feldtypen
- Farbe: Eine als sechsstellige Hexadezimalzahl codierte Farbe. Gültige Werte finden Sie unter https://htmlcolorcodes.com (der Wert muss ohne das vorangestellte „#“ eingegeben werden).
Beispiele:FFFFFF
für Weiß,000000
für Schwarz oder0039A6
für die Linien A, C und E der NYMTA (New York Metropolitan Transit Authority). - Währungscode: Ein alphabetischer Währungscode gemäß ISO 4217. Eine Liste der aktuellen Währungen finden Sie unter https://de.wikipedia.org/wiki/ISO_4217#Active_codes.
Beispiele:CAD
für den kanadischen Dollar,EUR
für den Euro oderJPY
für den japanischen Yen. - Datum: Betriebstag im Format
YYYYMMDD
. Da ein Betriebstag länger als 24:00:00 Stunden sein kann, sind oft auch Informationen für den folgenden Tag oder die folgenden Tage enthalten.
Beispiel:20180913
steht für den 13. September 2018. - E-Mail-Adresse: Eine E-Mail-Adresse.
Beispiel:example@example.com
- Enum: Eine Option aus einer Reihe vordefinierter Konstanten, die in der Spalte „Beschreibung“ definiert ist.
Beispiel: Das Feldroute_type
enthält eine0
für Straßenbahn, eine1
für U-Bahn usw. - ID: Ein ID-Feldwert ist eine nicht für Fahrgäste bestimmte, interne ID, die aus einer Abfolge beliebiger UTF-8-Zeichen besteht. Es wird empfohlen, nur druckbare ASCII-Zeichen zu verwenden. IDs, die in einer
.txt
-Datei definiert sind, werden oft in einer anderen.txt
-Datei referenziert.
Beispiele: Das Feldstop_id
instops.txt
ist eine ID. Das Feldstop_id
instop_times.txt
ist eine ID, diestops.stop_id
referenziert. - Sprachcode: Ein Sprachcode nach IETF BCP 47. Eine Einführung zu IETF BCP 47 finden Sie unter http://www.rfc-editor.org/rfc/bcp/bcp47.txt und http://www.w3.org/International/articles/language-tags/.
Beispiele:en
für Englisch,en-US
für amerikanisches Englisch oderde
für Deutsch. - Breitengrad: WGS84-Breitengrad im Dezimalformat. Der Wert muss größer oder gleich
-90.0
und kleiner oder gleich90.0
sein.
Beispiel:41.890169
für das Kolosseum in Rom. - Längengrad: WGS84-Längengrad im Dezimalformat. Der Wert muss größer oder gleich
-180.0
und kleiner oder gleich180.0
sein.
Beispiel:12.492269
für das Kolosseum in Rom. - Nicht negative Gleitkommazahl: Ein Gleitkommawert größer oder gleich
0
. - Nicht negative Ganzzahl: Eine Ganzzahl größer oder gleich
0
. - Telefonnummer: Eine Telefonnummer.
- Zeit: Uhrzeit im Format HH:MM:SS. Ebenfalls zulässig ist H:MM:SS. Die Uhrzeit wird ab „12:00 Uhr minus 12 Stunden“ des Betriebstags gemessen, was – außer an den Tagen der Zeitumstellung – Mitternacht entspricht. Weitere Informationen finden Sie in diesem Hilfeartikel. Geben Sie für Zeiten nach Mitternacht einen Wert größer als 24:00:00 in HH:MM:SS Ortszeit für den Tag ein, an dem der Fahrplan beginnt.
Beispiele:14:30:00
für 14:30 Uhr oder25:35:00
für 01:35 Uhr am nächsten Tag. - Text: Ein String aus UTF-8-Zeichen, der angezeigt werden soll und daher menschenlesbar sein muss.
- Zeitzone: Eine Zeitzone aus der Zeitzonen-Datenbank (https://www.iana.org/time-zones). Zeitzonennamen enthalten nie ein Leerzeichen, aber eventuell einen Unterstrich. Eine Liste gültiger Werte finden Sie unter http://en.wikipedia.org/wiki/List_of_tz_zones.
Beispiele:Asia/Tokyo
,America/Los_Angeles
oderAfrica/Cairo
. - URL: Eine voll qualifizierte URL, die http:// oder https:// enthält. Alle Sonderzeichen in der URL müssen korrekt maskiert werden. Wie Sie voll qualifizierte URL-Werte erstellen, erfahren Sie unter http://www.w3.org/Addressing/URL/4_URI_Recommentations.html.
Dataset-Dateien
Diese Spezifikation definiert die folgenden Dateien:
Dateiname | Erforderlich | Definiert |
---|---|---|
agency.txt |
Erforderlich | Betreiber mit in diesem Dataset dargestelltem Fahrbetrieb. |
stops.txt |
Erforderlich | Haltestellen, an denen Fahrgäste ein- oder aussteigen können. Definiert auch Stationen und Stationseingänge. |
routes.txt |
Erforderlich | Routen mit öffentlichen Verkehrsmitteln. Eine Route ist eine Gruppe von Fahrten, die Fahrgästen als eine einzelne Strecke angezeigt werden. |
trips.txt |
Erforderlich | Fahrten auf der jeweiligen Route. Eine Fahrt ist eine Abfolge von zwei oder mehr Haltestellen innerhalb einer bestimmten Zeit. |
stop_times.txt |
Erforderlich | Ankunfts- und Abfahrtszeiten an Haltestellen für die jeweilige Fahrt. |
calendar.txt |
Bedingt erforderlich | Betriebstage, die in einem wöchentlichen Zeitplan mit Start- und Enddatum angegeben werden. Diese Datei ist erforderlich, falls nicht alle Betriebstage in calendar_dates.txt festgelegt sind. |
calendar_dates.txt |
Bedingt erforderlich | Ausnahmen für die in calendar.txt definierten Betriebstage. Wenn calendar.txt weggelassen wird, ist die Datei calendar_dates.txt erforderlich und muss alle Betriebstage enthalten. |
fare_attributes.txt |
Optional | Preisinformationen zu den Routen eines Betreibers. |
fare_rules.txt |
Optional | Regeln zur Anwendung von Preisen auf Fahrstrecken. |
shapes.txt |
Optional | Regeln zum Kartografieren der Fahrstrecke von Fahrzeugen (manchmal auch als Streckenführung bezeichnet). |
frequencies.txt |
Optional | Takt, d. h. zeitlicher Abstand zwischen Fahrten im Taktbetrieb, oder komprimierte Darstellung bei Betrieb mit festem Fahrplan. |
transfers.txt |
Optional | Regeln für Anschlüsse an Umstiegspunkten zwischen Routen. |
pathways.txt |
Optional | Verbindungswege zwischen Orten innerhalb von Stationen. |
levels.txt |
Optional | Ebenen in Stationen. |
feed_info.txt |
Bedingt erforderlich | Metadaten des Datasets, einschließlich Informationen zum Herausgeber, zur Version und zum Ablaufdatum. |
translations.txt |
Optional | Übersetzte Informationen eines Betreibers. |
attributions.txt |
Optional | Gibt die Zuordnungen an, die für das Dataset gelten. |
Anforderungen an Dateien
Für das Format und den Inhalt der Dataset-Dateien gelten folgende Anforderungen:
- Alle Dateien müssen als durch Kommas getrennter Text gespeichert werden.
- Die erste Zeile jeder Datei muss die Feldnamen enthalten. Jeder Unterabschnitt des Abschnitts Felddefinitionen entspricht einer der Dateien in einem GTFS-Dataset und enthält die Feldnamen, die in dieser Datei verwendet werden können.
- Bei allen Feldnamen ist die Groß- und Kleinschreibung zu beachten.
- Feldwerte dürfen keine Tabstopps, Zeilenumbrüche oder Zeichen für Zeilenschaltung enthalten.
- Feldwerte, die Anführungszeichen oder Kommas enthalten, müssen in Anführungszeichen gesetzt werden. Zusätzlich muss jedem Anführungszeichen im Feldwert ein weiteres Anführungszeichen vorangestellt werden. So werden in Microsoft Excel Dateien mit kommagetrennten Werten (CSV) ausgegeben. Weitere Informationen zum CSV-Dateiformat finden Sie unter http://tools.ietf.org/html/rfc4180.
Das folgende Beispiel zeigt, wie ein Feldwert in einer Datei mit kommagetrennten Werten dargestellt wird:
- Ursprünglicher Feldwert:
Contains "quotes", commas and text
- Feldwert in der CSV-Datei:
"Contains ""quotes"", commas and text"
- Ursprünglicher Feldwert:
- Feldwerte dürfen keine HTML-Tags, Kommentare oder Escape-Sequenzen enthalten.
- Alle zusätzlichen Leerzeichen zwischen Feldern oder Feldnamen müssen entfernt werden. Für viele Parser gehören Leerzeichen zum Wert, deshalb könnte dies zu Fehlern führen.
- Jede Zeile muss mit dem Zeilenumbruchzeichen „CRLF“ oder „LF“ enden.
- Dateien sollten UTF-8-codiert sein, damit alle Unicode-Zeichen unterstützt werden. Dateien mit der Unicode-Bytereihenfolgemarkierung (BOM) sind zulässig. Weitere Informationen zum BOM-Zeichen und zu UTF-8 finden Sie unter http://unicode.org/faq/utf_bom.html#BOM.
- Alle Dataset-Dateien müssen in einer Archivdatei zusammengefasst werden.
Felddefinitionen
agency.txt
Datei: erforderlich
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
agency_id |
ID | Bedingt erforderlich | Kennzeichnet eine Betreibermarke. Diese ist oft mit einem Betreiber identisch. In manchen Fällen, z. B. wenn ein Betreiber mehrere Verkehrsunternehmen unterhält, sind Betreiber und Marken unterschiedlich. In diesem Dokument wird der Begriff „Betreiber“ anstelle von „Marke“ verwendet. Ein Dataset kann Daten von mehreren Betreibern enthalten. Dieses Feld ist erforderlich, wenn das Dataset Daten für mehrere Betreiber enthält. Andernfalls ist es optional. |
agency_name |
Text | Erforderlich | Vollständiger Name des Betreibers. |
agency_url |
URL | Erforderlich | URL des Betreibers. |
agency_timezone |
Zeitzone | Erforderlich | Zeitzone am Standort des Betreibers. Wenn im Dataset mehrere Betreiber angegeben sind, müssen alle dieselbe agency_timezone haben. |
agency_lang |
Sprachcode | Optional | Primäre Sprache, die von diesem Betreiber verwendet wird. Mit diesem Feld können GTFS-Nutzer Großschreibungsregeln und andere sprachspezifische Einstellungen für das Dataset auswählen. |
agency_phone |
Telefonnummer | Optional | Eine Telefonnummer des angegebenen Betreibers. Dieses Feld ist ein Stringwert, der die Telefonnummer für das Einzugsgebiet des Betreibers angibt. Der Wert kann und sollte Satzzeichen enthalten, mit denen die Ziffern der Nummer in Gruppen gegliedert werden können. Wählbarer Text (z. B. 503-238-RIDE von TriMet) ist zulässig. Das Feld darf aber keinen sonstigen, beschreibenden Text enthalten. |
agency_fare_url |
URL | Optional | Die URL einer Webseite, über die Fahrgäste online Fahrkarten oder andere Fahrausweise für diesen Betreiber kaufen können. |
agency_email |
E-Mail-Adresse | Optional | Die vom Kundenservice des Betreibers aktiv überwachte E-Mail-Adresse. Es sollte die direkte Kontakt-E-Mail-Adresse sein, unter der Fahrgäste Kundenservicemitarbeiter erreichen. |
stops.txt
Datei: erforderlich
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
stop_id |
ID | Erforderlich | Kennzeichnet eine Haltestelle, eine Station oder einen Stationseingang. Ein „Stationseingang“ kann sowohl der Ein- als auch der Ausgang einer Station sein. Haltestellen, Stationen und Stationseingänge werden zusammen als „Orte“ bezeichnet. Über eine Haltestelle können mehrere Routen verlaufen. |
stop_code |
Text | Optional | Kurzer Text oder eine Zahl, die Fahrgästen den Ort anzeigt. Diese Codes werden häufig in smartphonebasierten Fahrgastinformationssystemen verwendet oder auf Beschilderungen gedruckt, damit Fahrgäste leichter Informationen zu einem bestimmten Ort erhalten können. Der stop_code kann bei Gebrauch gegenüber der Öffentlichkeit identisch mit einer stop_id sein. Für Orte, an denen Fahrgästen kein Code angezeigt wird, sollte dieses Feld leer bleiben. |
stop_name |
Text | Bedingt erforderlich | Name des Orts. Verwenden Sie einen Namen, den Nutzer in der Landessprache und der von Touristen normalerweise verwendeten Sprache verstehen. Wenn es sich bei dem Ort um einen Einstiegsbereich ( location_type=4 ) handelt, sollte der stop_name den Namen des Einstiegsbereichs enthalten, wie er vom Betreiber ausgewiesen wird. Das kann ein einzelner Buchstabe wie an manchen europäischen Intercity-Bahnhöfen sein, aber auch eine Angabe wie „Wheelchair boarding area“ (Einstiegsbereich für Rollstuhlfahrer) in der New Yorker U-Bahn oder die Bezeichnung für den Punkt im Pariser Schnellbahnnetz RER, an dem der Zugkopf hält.Bedingt erforderlich: • Erforderlich für Haltestellen ( location_type=0 ), Stationen (location_type=1 ) und Ein-/Ausgänge (location_type=2 ).• Optional für generische Knoten ( location_type=3 ) und Einstiegsbereiche (location_type=4 ). |
stop_desc |
Text | Optional | Beschreibung des Orts, die nützliche und relevante Informationen liefert. Hier sollte nicht einfach nur der Name des Orts eingegeben werden. |
stop_lat |
Breitengrad | Bedingt erforderlich | Breitengrad des Orts. Bedingt erforderlich: • Erforderlich für Haltestellen ( location_type=0 ), Stationen (location_type=1 ) und Ein-/Ausgänge (location_type=2 ).• Optional für generische Knoten ( location_type=3 ) und Einstiegsbereiche (location_type=4 ). |
stop_lon |
Längengrad | Bedingt erforderlich | Längengrad des Orts. Bedingt erforderlich: • Erforderlich für Haltestellen ( location_type=0 ), Stationen (location_type=1 ) und Ein-/Ausgänge (location_type=2 ).• Optional für generische Knoten ( location_type=3 ) und Einstiegsbereiche (location_type=4 ). |
zone_id |
ID | Bedingt erforderlich | Gibt die Preiszone für eine Haltestelle an. Dieses Feld ist erforderlich bei Preisinformationen mit fare_rules.txt . Andernfalls ist es optional. Wenn dieser Datensatz eine Station oder einen Stationseingang repräsentiert, wird zone_id ignoriert. |
stop_url |
URL | Optional | URL einer Webseite zu dem Ort. Sollte sich von den Feldwerten für agency.agency_url und routes.route_url unterscheiden. |
location_type |
Enum | Optional | Ortstyp: • 0 (oder leer): Haltestelle (oder Bahnsteig). Ein Ort, an dem Fahrgäste ein- oder aussteigen. Wenn er in parent_station definiert ist, wird er als Bahnsteig bezeichnet.• 1 : Station. Eine bauliche Anlage oder ein Bereich mit mindestens einem Bahnsteig.2 : Ein-/Ausgang. Ein Ort, an dem Fahrgäste eine Station von der Straße her betreten oder zur Straße hin verlassen können. Wenn mehrere Stationen denselben Ein- oder Ausgang haben, kann er über Wege mit beiden Stationen verbunden sein. Der Datenanbieter muss aber eine davon als übergeordnet auswählen.• 3 : generischer Knoten. Ein Ort innerhalb einer Station, der keinem anderen Ortstyp (location_type ) entspricht und zum Verbinden von in pathways.txt definierten Wegen verwendet werden kann.• 4 : Einstiegsbereich. Ein bestimmter Ort auf einem Bahnsteig, an dem Fahrgäste ein- bzw. aussteigen können. |
parent_station |
ID, die stops.stop_id referenziert |
Bedingt erforderlich | Legt die Hierarchie zwischen den in stops.txt definierten Orten fest. Enthält die ID des übergeordneten Orts:•Haltestelle/Bahnsteig ( location_type=0 ): Das Feld parent_station enthält die ID einer Station.• Station ( location_type=1 ): Dieses Feld muss leer sein.• Ein-/Ausgang ( location_type=2 ) oder generischer Knoten (location_type=3 ): Das Feld parent_station enthält die ID einer Station (location_type=1 ).• Einstiegsbereich ( location_type=4 ): Das Feld parent_station enthält die ID eines Bahnsteigs.Bedingt erforderlich: • Erforderlich für Ein-/Ausgänge ( location_type=2 ), generische Knoten (location_type=3 ) und Einstiegsbereiche (location_type=4 ).• Optional für Haltestellen und Bahnsteige ( location_type=0 ).• Nicht zulässig für Stationen ( location_type=1 ). |
stop_timezone |
Zeitzone | Optional | Zeitzone des Orts. Wenn der Ort eine übergeordnete Station hat, übernimmt er automatisch deren Zeitzone. Für Stationen sowie für Haltestellen ohne übergeordnetes Element, bei denen das Feld stop_timezone leer ist, wird die in agency.agency_timezone angegebene Zeitzone übernommen. Wenn Werte für stop_timezone angegeben werden, sollte in die Datei stop_times.txt die Zeit seit Mitternacht in der durch agency.agency_timezone festgelegten Zeitzone eingetragen werden. So wird sichergestellt, dass die Zeitwerte im Verlauf einer Fahrt immer ansteigen – unabhängig davon, welche Zeitzonen während der Fahrt durchlaufen werden. |
wheelchair_boarding |
Enum | Optional | Gibt an, ob an dem Ort das Zusteigen im Rollstuhl möglich ist. Gültige Optionen: Bei Haltestellen ohne übergeordnete Elemente: 0 oder leer: Keine Angaben zur Barrierefreiheit der Haltestelle.1 : An dieser Haltestelle ist das Zusteigen im Rollstuhl bei einigen Fahrzeugen möglich.2 : An dieser Haltestelle ist das Zusteigen im Rollstuhl nicht möglich. Bei untergeordneten Haltestellen: 0 oder leer: Für die Haltestelle werden die im Feld wheelchair_boarding der übergeordneten Station gemachten Angaben zur Barrierefreiheit übernommen.1 : Es gibt einen barrierefreien Weg von außerhalb der Station zur jeweiligen Haltestelle bzw. zum jeweiligen Bahnsteig.2 : Es gibt keinen barrierefreien Weg von außerhalb der Station zur jeweiligen Haltestelle bzw. zum jeweiligen Bahnsteig.Bei Stationsein- und ‑ausgängen: 0 oder leer: Für den Ein-/Ausgang werden die im Feld wheelchair_boarding der übergeordneten Station gemachten Angaben zur Barrierefreiheit übernommen.1 : Der Stationsein-/‑ausgang ist rollstuhlgerecht.2 : Kein barrierefreier Weg vom Stationseingang zu den Haltestellen bzw. Bahnsteigen. |
level_id |
ID, die levels.level_id referenziert |
Optional | Ebene des Orts. Ein und dieselbe Ebene kann von mehreren nicht verbundenen Stationen verwendet werden. |
platform_code |
Text | Optional | Kennung für einen Bahnsteig (Haltestelle, die zu einer Station gehört). Hierfür sollte nur die Bahnsteigkennung verwendet werden (z. B. G oder 3 ). Begriffe wie „Bahnsteig“ oder „Gleis“ (oder die jeweilige Entsprechung in der Sprache des Feeds) sollten nicht enthalten sein. Das erleichtert Feednutzern die Internationalisierung und Lokalisierung der Bahnsteigkennung für andere Sprachen. |
routes.txt
Datei: erforderlich
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
route_id |
ID | Erforderlich | Kennzeichnet eine Route. |
agency_id |
ID, die agency.agency_id referenziert |
Bedingt erforderlich | Betreiber für die angegebene Route. Dieses Feld ist erforderlich, wenn das Dataset in agency.txt Daten für Routen von mehreren Betreibern enthält. Andernfalls ist es optional. |
route_short_name |
Text | Bedingt erforderlich | Kurzname einer Route. Oft eine kurze, abstrakte Bezeichnung wie „32“, „100X“ oder „Grün“, um die Route für die Fahrgäste zu kennzeichnen. Welche Orte angefahren werden, geht daraus nicht hervor. Es muss entweder route_short_name oder route_long_name angegeben werden oder gegebenenfalls beides. |
route_long_name |
Text | Bedingt erforderlich | Vollständiger Name einer Route. 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 entweder route_short_name oder route_long_name angegeben werden oder gegebenenfalls beides. |
route_desc |
Text | Optional | Beschreibung einer Route, die nützliche und relevante Angaben liefert. Hier sollte nicht einfach nur der Name der Route eingegeben werden. Beispiel: Die Züge der Linie A verkehren zu jeder Zeit zwischen Neureut-Kirchfeld und Ettlingen-Stadt. Außerdem verkehren von 6:00 Uhr bis Mitternacht zusätzliche Züge der Linie A zwischen Neureut-Kirchfeld und Bad Herrenalb (die Züge fahren normalerweise abwechselnd nach Bad Herrenalb und nach Ettlingen-Stadt). |
route_type |
Enum | Erforderlich | Gibt die Art des Verkehrsmittels an, das auf einer Route verwendet wird. Gültige Optionen: 0 : Straßenbahn, Stadtbahn Jedes Straßenbahnsystem oder Bahnsystem auf Straßenniveau innerhalb einer Metropolregion.1 : U-Bahn, Metro. Jedes unterirdische Bahnsystem innerhalb einer Metropolregion.2 : Bahn. Wird für den Fernverkehr verwendet.3 : Bus. Wird für Buslinien im Nah- und Fernverkehr verwendet.4 : Fähre. Wird im öffentlichen Bootsverkehr für Kurz- und Langstrecken verwendet.5 : Kabelstraßenbahn. Auf Straßenniveau fahrendes Schienenfahrzeug, bei dem das Zugseil unterhalb des Fahrzeugs läuft (z. B. Cable Car in San Francisco).6 : Luftseilbahn, Seilschwebebahn (z. B. Gondelbahn, Pendelbahn). Seilbahnen, bei denen Kabinen, Wagen, Gondeln oder offene Sessel an einem oder mehreren Seilen aufgehängt sind.7 : Standseilbahn. Alle schienengebundenen Systeme für steile Steigungen.11 : Oberleitungsbus. Elektrische Busse, die über zweipolige Abnehmer Strom aus Oberleitungen beziehen.12 : Einschienenbahn. Bahn, bei der die Spur aus nur einer Schiene oder einem Fahrbalken besteht. |
route_url |
URL | Optional | URL einer Webseite für die jeweilige Route. Sollte sich vom Wert für agency.agency_url unterscheiden. |
route_color |
Farbe | Optional | Farbkennzeichnung der Route wie in dem für die Öffentlichkeit bestimmten Material. Wenn das Feld weggelassen wird oder leer bleibt, wird die Standardeinstellung „Weiß“ verwendet (FFFFFF ). Die für route_color und route_text_color festgelegten Farben sollten auf einem Schwarz-Weiß-Bildschirm ausreichend kontrastieren. |
route_text_color |
Farbe | Optional | Farbe für den Text für die Route. Diese sollte so gewählt werden, dass der Text vor der Hintergrundfarbe route_color gut lesbar ist. Wenn das Feld weggelassen wird oder leer bleibt, wird die Standardeinstellung „Schwarz“ verwendet (000000 ). Die für route_color und route_text_color festgelegten Farben sollten auf einem Schwarz-Weiß-Bildschirm ausreichend kontrastieren. |
route_sort_order |
Nicht negative Ganzzahl | Optional | Ordnet die Routen so an, dass sie für Nutzer ideal dargestellt werden. Routen mit kleineren route_sort_order -Werten sollten an erster Stelle angezeigt werden. |
continuous_pickup |
Enum | Optional | Gibt an, ob ein Fahrgast überall auf der Fahrstrecke zusteigen kann. Die Fahrstrecke wird für jede Fahrt auf der Route in der Datei shapes.txt beschrieben. Gültige Optionen:0 : Flexibler Zustieg.1 oder leer: Kein flexibler Zustieg.2 : Der flexible Zustieg muss mit dem Betreiber telefonisch abgesprochen werden.3 : Der flexible Zustieg muss mit dem Fahrer abgestimmt werden.Die in routes.txt festgelegten Standardeinstellungen für den flexiblen Zustieg können in stop_times.txt überschrieben werden. |
continuous_drop_off |
Enum | Optional | Gibt an, ob ein Fahrgast an jedem beliebigen Punkt auf der Fahrstrecke aussteigen kann. Die Fahrstrecke wird für jede Fahrt auf der Route in der Datei shapes.txt beschrieben. Gültige Optionen:0 : Flexibler Ausstieg.1 oder leer: Kein flexibler Ausstieg.2 : Der flexible Ausstieg muss mit dem Betreiber telefonisch abgesprochen werden.3 : Der flexible Ausstieg muss mit dem Fahrer abgestimmt werden.Die in routes.txt festgelegten Standardeinstellungen für den flexiblen Ausstieg können in stop_times.txt überschrieben werden. |
trips.txt
Datei: erforderlich
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
route_id |
ID, die routes.route_id referenziert |
Erforderlich | Kennzeichnet eine Route. |
service_id |
ID, die calendar.service_id oder calendar_dates.service_id referenziert |
Erforderlich | Gibt die Tage an, an denen eine oder mehrere Routen bedient werden. |
trip_id |
ID | Erforderlich | Kennzeichnet eine Fahrt. |
trip_headsign |
Text | Optional | Text einer Anzeige, in der den Fahrgästen das Fahrziel angezeigt wird. Sie können dieses Feld verwenden, um auf ein und derselben Route zwischen verschiedenen Fahrzielen zu unterscheiden. Wenn sich die Zielanzeige während einer Fahrt ändert, kann trip_headsign mit Werten für stop_times.stop_headsign überschrieben werden. |
trip_short_name |
Text | Optional | Öffentlicher Text, um die Fahrt für Fahrgäste zu kennzeichnen (z. B. Angabe von Zugnummern für Bahnfahrten von Pendlern). Lassen Sie dieses Feld leer, wenn Fahrtbezeichnungen für Fahrgäste normalerweise nicht relevant sind. Falls ein Wert für trip_short_name angegeben wird, sollte er nur eine Fahrt innerhalb eines Betriebstags bezeichnen und nicht für Zielnamen oder Bezeichnungen wie „Regionalexpress“ oder „Intercity“ verwendet werden. |
direction_id |
Enum | Optional | Gibt die Richtung einer Fahrt an. Dieses Feld wird nicht für die Routenplanung verwendet. Vielmehr lassen sich damit auf Fahrplänen Fahrten nach Richtung trennen. Gültige Optionen: 0 : Fahrt in eine Richtung (z. B. Hinfahrt).1 : Fahrt in die entgegengesetzte Richtung (z. B. Rückfahrt).Beispiel: Die Felder trip_headsign und direction_id könnten zusammen verwendet werden, um einer Gruppe von Fahrten in jeder Richtung einen Namen zuzuweisen. Eine Datei trips.txt könnte folgende Datensätze zur Verwendung in Fahrplänen enthalten: trip_id,...,trip_headsign,direction_id 1234,...,Airport,0 1505,...,Downtown,1 |
block_id |
ID | Optional | Kennzeichnet den Block, zu dem die Fahrt gehört. Ein Block besteht aus einer einzelnen Fahrt oder mehreren aufeinanderfolgenden Fahrten mit demselben Fahrzeug, definiert durch gemeinsame Betriebstage und eine gemeinsame block_id . Eine block_id kann Fahrten an verschiedenen Betriebstagen umfassen und unterschiedliche Blöcke bilden. Siehe dazu das Beispiel unten. |
shape_id |
ID, die shapes.shape_id referenziert |
Bedingt erforderlich | Kennzeichnet eine raumbezogene Form, die die Fahrstrecke des Fahrzeugs bei einer Fahrt beschreibt. Bedingt erforderlich: Dieses Feld ist erforderlich, wenn für die Fahrt entweder auf Routenebene oder auf Ebene der Haltestellenzeiten die Modellierung mit GTFS-ContinuousStops verwendet wird. Andernfalls ist es optional. |
wheelchair_accessible |
Enum | Optional | Informationen zur Zugänglichkeit für Rollstuhlfahrer. Gültige Optionen:0 oder leer: Für die Fahrt gibt es keine Angaben zur Zugänglichkeit.1 : Das für diese Fahrt verwendete Fahrzeug kann mindestens einen Rollstuhlfahrer aufnehmen.2 : Bei dieser Fahrt können keine Rollstuhlfahrer mitgenommen werden. |
bikes_allowed |
Enum | Optional | Gibt an, ob Fahrräder erlaubt sind. Gültige Optionen:0 oder leer: Für die Fahrt gibt es keine Angaben zu Fahrrädern.1 : Das für diese Fahrt verwendete Fahrzeug kann mindestens ein Fahrrad aufnehmen.2 : Bei dieser Fahrt sind keine Fahrräder erlaubt. |
Beispiel: Blöcke und Betriebstag
Hier ein Beispiel mit unterschiedlichen Blöcken an jedem Wochentag:
route_id |
trip_id |
service_id |
block_id |
(Zeit an der ersten Haltestelle) | (Zeit an der letzten Haltestelle) |
---|---|---|---|---|---|
red |
trip_1 |
mon-tues-wed-thurs-fri-sat-sun |
red_loop |
22:00:00 | 22:55:00 |
red |
trip_2 |
fri-sat-sun |
red_loop |
23:00:00 | 23:55:00 |
red |
trip_3 |
fri-sat |
red_loop |
24:00:00 | 24:55:00 |
red |
trip_4 |
mon-tues-wed-thurs |
red_loop |
20:00:00 | 20:50:00 |
red |
trip_5 |
mon-tues-wed-thurs |
red_loop |
21:00:00 | 21:50:00 |
Hinweise zur Tabelle oben:
- Von Freitag auf Samstagmorgen beispielsweise fährt ein einzelnes Fahrzeug
trip_1
,trip_2
undtrip_3
(22:00 Uhr bis 00:55 Uhr). Die letzte Fahrt findet am Samstag von 00:00 Uhr bis 00:55 Uhr statt, gehört aber zum Betriebstag „Freitag“, weil die Zeiten 24:00:00 bis 24:55:00 Uhr sind. - Am Montag, Dienstag, Mittwoch und Donnerstag fährt ein einzelnes Fahrzeug
trip_1
,trip_4
undtrip_5
in einem Block von 20:00 bis 22:55 Uhr.
stop_times.txt
Datei: erforderlich
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
trip_id |
ID, die trips.trip_id referenziert |
Erforderlich | Kennzeichnet eine Fahrt. |
arrival_time |
Zeit | Bedingt erforderlich | Ankunftszeit an einer bestimmten Haltestelle bei einer bestimmten Fahrt auf einer Route. Wenn die Ankunfts- und die Abfahrtszeit an einer Haltestelle identisch ist, geben Sie für arrival_time und departure_time denselben Wert ein. Geben Sie für Zeiten nach Mitternacht am Betriebstag einen Wert größer als 24:00:00 in HH:MM:SS Ortszeit für den Tag ein, an dem der Fahrplan beginnt.Geplante Haltestellenstopps, an denen das Fahrzeug die angegebenen Ankunfts- und Abfahrtszeiten genau einhält, werden „Zeitpunkte“ genannt. Wenn es sich bei dem Stopp nicht um einen Zeitpunkt handelt, empfiehlt es sich, eine geschätzte oder interpolierte Zeit anzugeben. Ist der Parameter nicht verfügbar, kann das Feld arrival_time leer bleiben. Geben Sie außerdem mit timepoint=0 an, dass interpolierte Zeiten angezeigt werden. Wenn mit timepoint=0 interpolierte Zeiten angegeben werden, müssen Zeitpunkte mit timepoint=1 angezeigt werden. Geben Sie Ankunftszeiten für alle Haltestellenstopps an, die Zeitpunkte sind. Eine Ankunftszeit muss auch für die erste und letzte Haltestelle einer Fahrt angegeben werden. |
departure_time |
Zeit | Bedingt erforderlich | Abfahrtszeit an einer bestimmten Haltestelle bei einer bestimmten Fahrt auf einer Route. Geben Sie für Zeiten nach Mitternacht am Betriebstag einen Wert größer als 24:00:00 in HH:MM:SS Ortszeit für den Tag ein, an dem der Fahrplan beginnt. Wenn die Ankunfts- und die Abfahrtszeit an einer Haltestelle identisch ist, geben Sie für arrival_time und departure_time denselben Wert ein. Näheres zur korrekten Verwendung von Zeitpunkten finden Sie in der Beschreibung zu arrival_time . Im Feld departure_time sollten nach Möglichkeit Zeitwerte angegeben werden, einschließlich unverbindlicher geschätzter oder interpolierter Zeiten zwischen Zeitpunkten. |
stop_id |
ID, die stops.stop_id referenziert |
Erforderlich | Kennzeichnet die angefahrene Haltestelle. Alle Haltestellen, die bei einer Fahrt angefahren werden, müssen einen Datensatz in stop_times.txt haben. Die referenzierten Orte müssen Haltestellen und dürfen keine Stationen oder Stationseingänge sein. Eine Haltestelle kann während einer Fahrt mehrmals angefahren werden. Außerdem kann dieselbe Haltestelle bei mehreren Fahrten und Routen angefahren werden. |
stop_sequence |
Nicht negative Ganzzahl | Erforderlich | Reihenfolge der Haltestellen bei einer bestimmten Fahrt. Die Werte müssen im Fahrtverlauf ansteigen, brauchen aber nicht aufeinanderfolgend zu sein. Beispiel: Der erste Ort auf der Fahrt kann für die Haltestellenfolge den Wert stop_sequence=1 haben, der zweite stop_sequence=23 , der dritte stop_sequence=40 und so weiter. |
stop_headsign |
Text | Optional | Text einer Anzeige, in der den Fahrgästen das Fahrziel angezeigt wird. Mit dem Text aus diesem Feld wird der standardmäßige Wert für trips.trip_headsign überschrieben, wenn sich die Zielanzeige zwischen Haltestellen ändert. Wenn für die gesamte Fahrt die gleiche Zielanzeige ausgegeben wird, verwenden Sie stattdessen trips.trip_headsign . Ein stop_headsign -Wert, der für eine stop_time (Haltestellenzeit) angegeben ist, gilt nicht für anschließende stop_time -Werte bei derselben Fahrt. Wenn Sie trip_headsign für mehrere stop_time -Werte bei derselben Fahrt überschreiben möchten, muss der stop_headsign -Wert in jeder stop_time -Zeile wiederholt werden. |
pickup_type |
Enum | Optional | Gibt die Zustiegsoption an. Gültige Optionen:0 oder leer: Regulärer Zustieg. 1 : Kein Zustieg.2 : Der Zustieg muss mit dem Betreiber telefonisch abgesprochen werden.3 : Der Zustieg muss mit dem Fahrer abgestimmt werden. |
drop_off_type |
Enum | Optional | Gibt die Ausstiegsoption an. Gültige Optionen sind:0 oder leer: Regulärer Ausstieg.1 : Kein Ausstieg.2 : Der Ausstieg muss mit dem Betreiber telefonisch abgesprochen werden.3 : Der Ausstieg muss mit dem Fahrer abgestimmt werden. |
continuous_pickup |
Enum | Optional | Gibt an, ob ein Fahrgast an jedem Punkt auf der Fahrstrecke zusteigen kann. Die Fahrstrecke wird entsprechend shapes.txt von dieser stop_time zur nächsten stop_time in der stop_sequence der Fahrt angegeben. Gültige Optionen:0 : Flexibler Zustieg.1 oder leer: Kein flexibler Zustieg.2 : Der flexible Zustieg muss mit dem Betreiber telefonisch abgesprochen werden.3 : Der flexible Zustieg muss mit dem Fahrer abgestimmt werden.Die Angaben in routes.txt werden durch die in stop_times.txt festgelegten Einstellungen für den flexiblen Zustieg überschrieben. |
continuous_drop_off |
Enum | Optional | Gibt an, ob ein Fahrgast auf der in shapes.txt beschrieben Fahrstrecke des Fahrzeugs – zwischen dieser stop_time und der nächsten stop_time in der Haltestellenfolge (stop_sequence ) der Fahrt – an jedem beliebigen Punkt aussteigen kann.0 : Flexibler Ausstieg.1 oder leer: Kein flexibler Ausstieg.2 : Der flexible Ausstieg muss mit dem Betreiber telefonisch abgesprochen werden.3 : Der flexible Ausstieg muss mit dem Fahrer abgestimmt werden.Die Angaben in routes.txt werden durch die in stop_times.txt festgelegten Einstellungen für den flexiblen Ausstieg überschrieben. |
shape_dist_traveled |
Nicht negative Gleitkommazahl | Optional | Die tatsächliche Strecke, die entlang der zugehörigen Form von der ersten Haltestelle bis zu der in diesem Datensatz angegebenen zurückgelegt wurde. Dieses Feld gibt an, wie viel von der Form zwischen zwei Haltestellen einer Fahrt jeweils darzustellen ist. Es müssen dieselben Einheiten wie in shapes.txt verwendet werden. Die Werte für shape_dist_traveled müssen zusammen mit denen für stop_sequence höher werden. Sie können nicht verwendet werden, um die umgekehrte Fahrtrichtung auf der Route darzustellen.Beispiel: Wenn ein Bus eine Strecke von 5,25 Kilometern vom Anfangspunkt der Form bis zur Haltestelle zurücklegt, gilt: shape_dist_traveled=5.25 . |
timepoint |
Enum | Optional | Gibt an, ob Ankunfts- und Abfahrtszeiten für eine Haltestelle vom Fahrzeug genau eingehalten werden oder ob es sich um ungefähre und/oder interpolierte Zeiten handelt. Mit diesem Feld kann ein Anbieter von GTFS-Daten interpolierte Haltestellenzeiten zur Verfügung stellen und angeben, dass es sich um ungefähre Zeiten handelt. Gültige Optionen:0 : Ungefähre Zeiten.1 oder leer: Genaue Zeiten. |
calendar.txt
Datei: bedingt erforderlich
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
service_id |
ID | Erforderlich | Kennzeichnet eindeutig eine Reihe von Tagen, an denen für eine oder mehrere Routen ein Fahrbetrieb stattfindet. Jeder service_id -Wert darf höchstens einmal in einer calendar.txt -Datei erscheinen. |
monday |
Enum | Erforderlich | Gibt an, ob der Fahrbetrieb in dem in den Feldern start_date und end_date angegebenen Zeitraum an jedem Montag stattfindet. Ausnahmen für bestimmte Tage können unter calendar_dates.txt aufgeführt werden. Gültige Optionen:1 : Im betreffenden Zeitraum findet an jedem Montag Fahrbetrieb statt.0 : Im betreffenden Zeitraum findet montags kein Fahrbetrieb statt. |
tuesday |
Enum | Erforderlich | Gilt für Dienstage und funktioniert im Übrigen genauso wie das Feld monday . |
wednesday |
Enum | Erforderlich | Gilt für Mittwoch und funktioniert im Übrigen genauso wie das Feld monday . |
thursday |
Enum | Erforderlich | Gilt für Donnerstage und funktioniert im Übrigen genauso wie das Feld monday . |
friday |
Enum | Erforderlich | Gilt für Freitage und funktioniert im Übrigen genauso wie das Feld monday . |
saturday |
Enum | Erforderlich | Gilt für Samstage und funktioniert im Übrigen genauso wie das Feld monday . |
sunday |
Enum | Erforderlich | Gilt für Sonntage und funktioniert im Übrigen genauso wie das Feld monday . |
start_date |
Datum | Erforderlich | Erster Betriebstag im Betriebsintervall. |
end_date |
Datum | Erforderlich | Letzter Betriebstag im Betriebsintervall. Dieser Betriebstag ist im Intervall enthalten. |
calendar_dates.txt
Datei: bedingt erforderlich
Mit der Tabelle calendar_dates.txt
kann der Betrieb explizit nach Datum aktiviert oder deaktiviert werden. Sie kann auf zwei Arten verwendet werden:
- Empfohlene Verwendung: Verwenden Sie
calendar_dates.txt
zusammen mitcalendar.txt
, um Ausnahmen zu den incalendar.txt
definierten Standardmustern für den Fahrbetrieb zu definieren. Wenn der Fahrbetrieb im Allgemeinen regelmäßig und mit nur wenigen Änderungen an bestimmten Tagen stattfindet (z. B. bei besonderen Veranstaltungen oder zu Schulzeiten), ist das eine gute Vorgehensweise. In diesem Fall istcalendar_dates.service_id
eine ID, diecalendar.service_id
referenziert. - Alternative Verwendung: Sie können
calendar.txt
weglassen und jeden Betriebstag incalendar_dates.txt
angeben. Auf diese Weise lassen sich erhebliche Schwankungen im Fahrbetrieb und ein Betrieb ohne normale wöchentliche Fahrzeiten berücksichtigen. In diesem Fall istservice_id
eine ID.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
service_id |
ID, die calendar.service_id oder ID referenziert |
Erforderlich | Bezeichnet eine Reihe von Tagen, an denen eine Betriebsausnahme für eine oder mehrere Routen auftritt. Wenn Sie calendar.txt und calendar_dates.txt zusammen verwenden, darf jedes Paar aus service_id und date nur einmal in calendar_dates.txt erscheinen. Falls der Wert service_id sowohl in calendar.txt als auch in calendar_dates.txt enthalten ist, werden durch die Angaben in calendar_dates.txt die in calendar.txt festgelegten Informationen zum Fahrbetrieb geändert. |
date |
Datum | Erforderlich | Datum, an dem die Betriebsausnahme auftritt. |
exception_type |
Enum | Erforderlich | Gibt an, ob der Fahrbetrieb an dem im Feld date angegebenen Datum stattfindet. Gültige Optionen:1 : Der Fahrbetrieb wurde für das angegebene Datum hinzugefügt.2 : Der Fahrbetrieb wurde für das angegebene Datum entfernt.Beispiel: Eine Route umfasst eine Gruppe von Fahrten für Feiertage und eine andere Gruppe für alle anderen Tage. Eine service_id könnte dabei dem regulären Fahrplan entsprechen und die andere service_id dem Feiertagsfahrplan. Dann könnte mithilfe der Datei calendar_dates.txt ein bestimmter Feiertag unter der service_id für Feiertage hinzugefügt und unter der service_id aus dem regulären Fahrplan entfernt werden. |
fare_attributes.txt
Datei: optional
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
fare_id |
ID | Erforderlich | Kennzeichnet eine Preisklasse. |
price |
Nicht negative Gleitkommazahl | Erforderlich | Fahrpreis in der in currency_type angegebenen Einheit. |
currency_type |
Währungscode | Erforderlich | Währung, in der der Fahrpreis bezahlt wird. |
payment_method |
Enum | Erforderlich | Gibt an, wann der Fahrpreis bezahlt werden muss. Gültige Optionen:0 : Der Fahrpreis wird im Fahrzeug entrichtet.1 : Der Fahrpreis muss vor dem Einsteigen entrichtet werden. |
transfers |
Enum | Erforderlich | Gibt an, wie oft der Fahrgast bei diesem Preis umsteigen kann. Dieses Feld kann leer bleiben. Das ist eine Ausnahme von der Regel, dass ein Pflichtfeld nicht leer sein darf. Gültige Optionen:0 : Bei diesem Preis ist kein Umstieg zulässig.1 : Der Fahrgast darf einmal umsteigen.2 : Der Fahrgast darf zweimal umsteigen.Leer: Es darf beliebig oft umgestiegen werden. |
agency_id |
ID, die agency.agency_id referenziert |
Bedingt erforderlich | Kennzeichnet den Betreiber, bei dem der jeweilige Preis gilt. Dieses Feld ist für Datasets mit mehreren in agency.txt definierten Betreibern erforderlich. Andernfalls ist es optional. |
transfer_duration |
Nicht negative Ganzzahl | Optional | Angabe in Sekunden, wie lange ein Umstieg möglich ist. Wenn transfers=0 , kann über dieses Feld angegeben werden, wie lange eine Fahrkarte gültig ist, oder es kann leer bleiben. |
fare_rules.txt
Datei: optional
Mit der Tabelle fare_rules.txt
wird angegeben, wie die Preise in fare_attributes.txt
auf die jeweilige Fahrstrecke anzuwenden sind. Die meisten Preisstrukturen stellen eine Kombination aus den folgenden Regeln dar:
- Der Preis ist abhängig von der Abfahrts- oder Zielstation.
- Der Preis hängt davon ab, welche Zonen durchquert werden.
- Der Preis richtet sich nach dem Routenverlauf.
Beispiele dazu, wie Sie mit fare_rules.txt
und fare_attributes.txt
eine Preisstruktur angeben können, finden Sie unter https://code.google.com/p/googletransitdatafeed/wiki/FareExamples im Open-Source-Projekt-Wiki „GoogleTransitDataFeed“.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
fare_id |
ID, die fare_attributes.fare_id referenziert |
Erforderlich | Kennzeichnet eine Preisklasse. |
route_id |
ID, die routes.route_id referenziert |
Optional | Kennzeichnet eine mit der Preisklasse verbundene Route. Wenn mehrere Routen mit denselben Preisattributen vorhanden sind, erstellen Sie in fare_rules.txt für jede Route einen Datensatz.Beispiel: Wenn die Preisklasse b für Route TSW und TSE gilt, enthält die Datei fare_rules.txt die folgenden Datensätze für die Preisklasse: fare_id,route_id b,TSW b,TSE |
origin_id |
ID, die stops.zone_id referenziert |
Optional | Kennzeichnet die Abfahrtszone. Falls eine Preisklasse mehrere Abfahrtszonen umfasst, erstellen Sie in fare_rules.txt für jede origin_id einen Datensatz.Beispiel: Wenn die Preisklasse b für alle Fahrten gilt, die in Zone 2 oder 8 beginnen, enthält die Datei fare_rules.txt die folgenden Datensätze für die Preisklasse: fare_id,...,origin_id b,...,2 b,...,8 |
destination_id |
ID, die stops.zone_id referenziert |
Optional | Kennzeichnet eine Zielzone. Wenn eine Preisklasse mehrere Zielzonen umfasst, erstellen Sie in fare_rules.txt für jede destination_id einen Datensatz.Beispiel: Die Felder origin_id und destination_id können zusammen verwendet werden, um anzugeben, dass die Preisklasse b für Fahrten zwischen den Zonen 3 und 4 gilt. Für Fahrten zwischen den Zonen 3 und 5 würde die Datei fare_rules.txt diese Datensätze für die Preisklasse enthalten: fare_id,...,origin_id,destination_id b,...,3,4 b,...,3,5 |
contains_id |
ID, die stops.zone_id referenziert |
Optional | Kennzeichnet die Zonen, in denen ein Fahrgast mit einer Fahrkarte einer bestimmten Preisklasse fahren kann. Wird in manchen Systemen verwendet, um die richtige Preisklasse zu ermitteln. Beispiel: Wenn die Preisklasse c für alle Fahrten auf der Route GRT gilt (die durch die Zonen 5, 6 und 7 geht), enthält die Datei fare_rules.txt diese Datensätze: fare_id,route_id,...,contains_id c,GRT,...,5 c,GRT,...,6 c,GRT,...,7 Da die Fahrstrecke alle Zonen im Feld contains_id umfassen muss, damit der entsprechende Preis angewendet wird, würde die Preisklasse c nicht für eine Strecke gelten, die nur durch die Zonen 5 und 6, aber nicht durch Zone 7 geht. Weitere Informationen finden Sie unter https://code.google.com/p/googletransitdatafeed/wiki/FareExamples im Projekt-Wiki „GoogleTransitDataFeed“. |
shapes.txt
Datei: optional
Formen beschreiben die Strecke, die ein Fahrzeug entlang einer Route zurücklegt. Sie werden in der Datei shapes.txt
definiert. Formen sind mit Fahrten verknüpft und bestehen aus einer Abfolge von Punkten, die das Fahrzeug nacheinander durchläuft. Formen müssen sich nicht genau mit Haltestellenpositionen decken. Aber alle Haltestellen auf einer Fahrt sollten in kurzer Entfernung von der Form für die betreffende Fahrt liegen, d. h. in der Nähe von geraden Liniensegmenten, die die Punkte der Form verbinden.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
shape_id |
ID | Erforderlich | Kennzeichnet eine Form. |
shape_pt_lat |
Breitengrad | Erforderlich | Breitengrad eines Formpunkts. Jeder Datensatz in shapes.txt stellt einen Formpunkt dar, der zur Definition der Form verwendet wird. |
shape_pt_lon |
Längengrad | Erforderlich | Längengrad eines Formpunkts. |
shape_pt_sequence |
Nicht negative Ganzzahl | Erforderlich | Reihenfolge, in der die Formpunkte zu einer Form verbunden werden. Die Werte müssen im Fahrtverlauf ansteigen, brauchen aber nicht aufeinanderfolgend zu sein. Beispiel: Wenn die Form A_shp mit drei Punkten definiert wird, könnte sie in der Datei shapes.txt durch diese Datensätze festgelegt werden: shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence A_shp,37.61956,-122.48161,0 A_shp,37.64430,-122.41070,6 A_shp,37.65863,-122.30839,11 |
shape_dist_traveled |
Nicht negative Gleitkommazahl | Optional | Die tatsächliche Strecke, die entlang der Form vom ersten Formpunkt bis zu dem in diesem Datensatz angegebenen Punkt zurückgelegt wurde. Wird von Fahrtenplanern verwendet, um auf einer Karte den genauen Teil der Form darzustellen. Die Werte müssen zusammen mit denen für shape_pt_sequence höher werden. Sie können nicht verwendet werden, um die umgekehrte Fahrtrichtung auf der Route darzustellen. Die Maßeinheiten für die Strecke müssen denen in stop_times.txt entsprechen.Beispiel: Wenn ein Bus entlang der oben für A_shp festgelegten Punkte fährt, sehen die zusätzlichen (hier in Kilometer angegebenen) Werte für shape_dist_traveled so aus: shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled A_shp,37.61956,-122.48161,0,0 A_shp,37.64430,-122.41070,6,6.8310 A_shp,37.65863,-122.30839,11,15.8765 |
frequencies.txt
Datei: optional
Die Datei frequencies.txt
repräsentiert Fahrten, die in regelmäßigen Abständen (Zeit zwischen den Fahrten) erfolgen. Diese Datei kann zur Darstellung zweier verschiedener Betriebsarten verwendet werden:
- Taktbetrieb (
exact_times=0
), der den ganzen Tag über keinem festen Fahrplan folgt. Stattdessen versuchen die Betreiber, die festgelegten Zeitabstände für Fahrten genau einzuhalten. - Komprimierte Darstellung eines Fahrplanbetriebs (
exact_times=1
) mit dem genau gleichen Zeitabstand für Fahrten in den angegebenen Zeiträumen. Bei dieser Betriebsart wird versucht, den Fahrplan genau einzuhalten.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
trip_id |
ID, die trips.trip_id referenziert |
Erforderlich | Kennzeichnet eine Fahrt, für die der angegebene Takt gilt. |
start_time |
Zeit | Erforderlich | Uhrzeit, zu der das erste Fahrzeug im angegebenen Takt von der ersten Haltestelle der Fahrt abfährt. |
end_time |
Zeit | Erforderlich | Uhrzeit, zu der an der ersten Haltestelle der Fahrt auf einen anderen Takt umgestellt wird oder zu der dort der Fahrbetrieb endet. |
headway_secs |
Nicht negative Ganzzahl | Erforderlich | Zeit in Sekunden zwischen Abfahrten von derselben Haltestelle (Takt) für diese Fahrt im durch start_time und end_time festgelegten Zeitintervall. Mehrere Takte für dieselbe Fahrt sind zulässig, dürfen sich aber nicht überschneiden. Neue Takte können genau dann beginnen, wenn der vorherige Takt endet. |
exact_times |
Enum | Optional | Gibt den Betriebstyp für eine Fahrt an. Weitere Informationen finden Sie in der Dateibeschreibung. Gültige Optionen:0 oder leer: Fahrten im Takt.1 : Fahrten nach einem festen Fahrplan mit dem genau gleichen Zeitabstand während des ganzen Tags. In diesem Fall muss der Wert für end_time größer sein als der start_time -Wert der letzten gewünschten Fahrt, aber kleiner als start_time + headway_secs für diese Fahrt. |
transfers.txt
Datei: optional
Bei der Berechnung einer Fahrstrecke werden Umstiege bei Anwendungen, die GTFS nutzen, auf Grundlage der zulässigen Zeit und der Nähe zur Haltestelle interpoliert. Mit der Datei transfers.txt
können zusätzliche Regeln und Überschreibungsregeln für ausgewählte Umstiege angegeben werden.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
from_stop_id |
ID, die stops.stop_id referenziert |
Erforderlich | Kennzeichnet eine Haltestelle oder Station, an der eine Verbindung zwischen Routen beginnt. Wenn sich dieses Feld auf eine Station bezieht, gilt die Umstiegsregel für alle untergeordneten Haltestellen. |
to_stop_id |
ID, die stops.stop_id referenziert |
Erforderlich | Kennzeichnet eine Haltestelle oder Station, an der eine Verbindung zwischen Routen endet. Wenn sich dieses Feld auf eine Station bezieht, gilt die Umstiegsregel für alle untergeordneten Haltestellen. |
transfer_type |
Enum | Erforderlich | Gibt den Verbindungstyp für das angegebene Paar aus from_stop_id und to_stop_id an. Gültige Optionen:0 oder leer: Empfohlener Umstiegspunkt zwischen Routen.1 : Abgestimmter Umstiegspunkt zwischen zwei Routen. Das abfahrende Fahrzeug soll auf das ankommende warten. Dabei müssen die Fahrgäste genügend Zeit zum Umsteigen haben.2 : Der Umstieg erfordert eine Mindestzeitspanne zwischen Ankunft und Abfahrt, um den Anschluss zu schaffen. Die für den Umstieg erforderliche Zeit wird mit min_transfer_time angegeben.3 : An diesem Ort sind Umstiege zwischen Routen nicht möglich.4 : Fahrgäste müssen das Fahrzeug nicht verlassen, auch wenn Sie die Fahrt wechseln möchten (eine sogenannte „Fahrt mit Umstiegen innerhalb eines Blocks“).5 : Fahrten mit Umstiegen innerhalb eines Blocks sind bei mehreren aufeinanderfolgenden Fahrten nicht zulässig. Der Fahrgast muss aus dem Fahrzeug aussteigen und wieder einsteigen. |
min_transfer_time |
Nicht negative Ganzzahl | Optional | Die Zeit in Sekunden, die zur Verfügung stehen muss, damit an den angegebenen Haltestellen ein Umstieg möglich ist. Der Wert für min_transfer_time sollte groß genug sein, damit ein typischer Fahrgast von der einen zur anderen Haltestelle wechseln kann. Außerdem sollte ein Puffer für Fahrplanabweichungen auf jeder Route einkalkuliert werden. |
pathways.txt
Datei: optional
Die Erweiterung „GTFS-Pathways“ verwendet eine grafische Darstellung für U-Bahn-Stationen und Bahnhöfe – mit Knoten (den Orten) und Kanten (den Wegen).
Über Fußwege, Ticketschranken, Treppen usw. (d. h. Kanten, dargestellt als Wege) gelangt der Fahrgast vom Eingang (d. h. von einem mit location_type=2
als Knoten dargestellten Ort) zu einem Bahnsteig (d. h. einem mit location_type=0
als Ort dargestellten Knoten). Außerdem gibt es den Vorschlag, als weiteren Ortstyp den allgemeinen Typ „Generischer Knoten“ hinzuzunehmen, um beispielsweise eine Fußwegkreuzung darzustellen, von der aus der Fahrgast verschiedene Fußwege einschlagen kann.
Warnung: Die Wege in einer Station müssen vollständig sein. Wenn ein Bahnsteig (Haltestelle), Eingang oder Knoten, der zu einer Station gehört, einen solchen Weg hat, wird daher davon ausgegangen, dass die Wege der Station vollständig beschrieben sind. Deshalb gelten die folgenden gut nachvollziehbaren Regeln:
- Kein Ort ohne Weg: Wenn ein Ort in einer Station einen Weg hat, müssen auch alle anderen Orte Wege haben (ausgenommen Bahnsteige mit Einstiegsbereichen).
- Keine unzugänglichen Bahnsteige: Jeder Bahnsteig muss über eine Kette von Wegen mit mindestens einem Eingang verbunden sein. Stationen ohne eine entsprechende Verbindung nach außen sind in der Praxis sehr selten.
- Keine Wege für einen Bahnsteig mit Einstiegsbereichen: Ein solcher Bahnsteig wird als übergeordnetes Objekt und nicht als Punkt behandelt. Ihm sind nicht unbedingt Wege zugeordnet. Alle Wege sind für Einstiegsbereiche bestimmt.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
pathway_id |
ID | Erforderlich | Das Feld pathway_id enthält eine ID, die den Weg eindeutig kennzeichnet. Die pathway_id wird von Systemen als interne Kennung dieses Datasets verwendet (z. B. Primärschlüssel in der Datenbank). Daher muss die pathway_id eindeutig sein. Von der from_stop_id können verschiedene Wege zur to_stop_id führen. Das ist beispielsweise der Fall, wenn zwei Rolltreppen nebeneinander in entgegengesetzter Richtung laufen oder wenn sich eine Treppe in der Nähe eines Aufzugs befindet und beide vom selben Ort aus zum gleichen Zielort führen. |
from_stop_id |
ID, die stops.stop_id referenziert |
Erforderlich | Ort, an dem der Weg beginnt. Er enthält eine stop_id , die einen Bahnsteig, einen Ein-/Ausstieg, einen generischen Knoten oder einen Einstiegsbereich aus der Datei stops.txt bezeichnet. |
to_stop_id |
ID, die stops.stop_id referenziert |
Erforderlich | Ort, an dem der Weg endet. Er enthält eine stop_id , die einen Bahnsteig, einen Ein-/Ausstieg, einen generischen Knoten oder einen Einstiegsbereich aus der Datei stops.txt bezeichnet. |
pathway_mode |
Enum | Erforderlich | Wegtyp zwischen dem angegebenen Paar aus from_stop_id und to_stop_id . Gültige Werte für dieses Feld: • 1 : Fußweg • 2 : Treppe • 3 : Fahr-/Rollsteig • 4 : Rolltreppe • 5 : Aufzug • 6 : Ticketschranke – Weg, über den man in einen Bereich der Station gelangt, wo ein Zahlungsnachweis erforderlich ist (normalerweise über eine physische Sperre).Mit Ticketschranken können entweder kostenpflichtige von nicht kostenpflichtigen Bereichen oder unterschiedliche kostenpflichtige Bereiche innerhalb einer Station voneinander getrennt werden. Mit diesen Informationen lässt sich verhindern, dass Fahrgäste über Abkürzungen, für die unnötige Zahlungen anfallen, durch Stationen geleitet werden. Beispiel: Der Fahrgast wird über den Bahnsteig in einer U-Bahnstation zu einem Busfahrstreifen geleitet. • 7 : Ausgangsschranke – Weg, der von einem zahlungspflichtigen Bereich hinaus in einen nicht zahlungspflichtigen führt. |
is_bidirectional |
Enum | Erforderlich | Gibt an, in welcher Richtung der Weg benutzt werden kann: • 0 : In einer Richtung benutzbarer Weg – nur von from_stop_id bis to_stop_id .• 1 : In beiden Richtungen benutzbarer Weg.Ticketschranken ( pathway_mode=6 ) und Ausgangsschranken (pathway_mode=7 ) dürfen nur in einer Richtung benutzbar sein. |
length |
Nicht negative Gleitkommazahl | Optional | In Meter angegebene horizontale Länge des Wegs vom Ausgangsort (definiert in from_stop_id ) zum Zielort (definiert into_stop_id ).Dieses Feld wird für Gehwege ( pathway_mode=1 ), Ticketschranken (pathway_mode=6 ) und Ausgangsschranken (pathway_mode=7 ) empfohlen. |
traversal_time |
Positive Ganzzahl | Optional | Durchschnittliche Zeit in Sekunden für den Weg vom Ausgangsort (definiert in from_stop_id ) zum Zielort (definiert in to_stop_id ).Dieses Feld wird für Fahrsteige ( pathway_mode=3 ), Rolltreppen (pathway_mode=4 ) und Fahrstühle (pathway_mode=5 ) empfohlen. |
stair_count |
Ganzzahl ungleich null | Optional | Anzahl der Treppenstufen des Wegs. Best Practices: Ausgehend von der Schätzung „1 Etage = 15 Stufen“ können Näherungswerte erstellt werden. Ein positiver Wert für stair_count bedeutet, dass der Fahrgast von from_stop_id nach to_stop_id hinaufgeht. Ein negativer Wert für stair_count bedeutet, dass der Fahrgast von from_stop_id nach to_stop_id hinuntergeht.Dieses Feld wird für Treppen empfohlen ( pathway_mode=2 ). |
max_slope |
Gleitkommazahl | Optional | Maximales Neigungsverhältnis des Wegs. Gültige Werte für dieses Feld: • 0 oder leer: Keine Neigung.• Gleitkommazahl: Neigungsverhältnis des Wegs. Positive Zahl = ansteigender Weg, negative Zahl = abfallender Weg. Dieses Feld sollte nur bei Fußwegen ( pathway_type=1 ) und Fahrsteigen (pathway_type=3 ) verwendet werden.Beispiel: In den USA ist 0,083 (auch 8,3 % geschrieben) das maximal zulässige Neigungsverhältnis für manuelle Rollstühle. Dieser Wert bedeutet, dass der Weg auf einer Strecke von 1 m um 0,083 m (8,3 cm) ansteigt. |
min_width |
Positive Gleitkommazahl | Optional | Mindestbreite des Wegs in Metern. Dieses Feld wird dringend empfohlen, wenn die Mindestbreite weniger als 1 m beträgt. |
signposted_as |
Text | Optional | Textstring auf physischer Beschilderung für Fahrgäste. Er kann verwendet werden, um Nutzern Hinweise in Textform zu geben, z. B. „Schildern folgen“. Der Text sollte genau so in dieses Feld eingetragen werden, wie er auf die Schilder gedruckt ist. Er sollte nicht übersetzt werden. |
reversed_signposted_as |
Text | Optional | Wie Feld signposted_as , aber für Wege in umgekehrter Richtung, d. h. von to_stop_id nach from_stop_id . |
levels.txt
Datei: optional
Beschreibt die verschiedenen Ebenen einer Station. Die Datei ist hauptsächlich in Kombination mit pathways.txt
nützlich und wird für den Fahrstuhl (pathway_mode=5
) benötigt, den der Nutzer benutzen soll, um auf die Halbgeschoss- oder Bahnsteigebene zu gelangen.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
level_id |
ID | Erforderlich | ID der Ebene, die von stops.txt referenziert werden kann. |
level_index |
Gleitkommazahl | Erforderlich | Numerischer Index der Ebene, der die relative Position der Ebene zu anderen Ebenen angibt. Ebenen mit höheren Indexzahlen liegen über denen mit niedrigeren Indexzahlen. Die Bodenebene sollte die Indexzahl 0 haben. Die darüberliegenden Ebenen werden durch positive Zahlen gekennzeichnet und die darunterliegenden durch negative. |
level_name |
Text | Optional | Optionaler Name der Ebene (entsprechend der im Gebäude oder in der Station verwendeten Beschriftung/Nummerierung der Ebene). Ist nützlich für die Fahrstuhlführung (z. B. „Zu Ebene ‚Halbgeschoss‘“, „Zu Ebene ‚Bahnsteige‘“ oder „Zu Ebene -1“). |
feed_info.txt
Datei: bedingt erforderlich
Diese Datei enthält Informationen über das Dataset selbst und nicht über den darin beschriebenen Betrieb. Manchmal ist der Herausgeber des Datasets nicht mit dem Betreiber identisch. Wenn translations.txt
angegeben wird, ist diese Datei erforderlich.
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
feed_publisher_name |
Text | Erforderlich | Vollständiger Name der Organisation, die das Dataset herausgibt. Er kann mit einem der Werte in agency.agency_name übereinstimmen. |
feed_publisher_url |
URL | Erforderlich | URL der Website der Organisation, die das Dataset herausgibt. Sie kann mit einem der Werte in agency.agency_url übereinstimmen. |
feed_lang |
Sprachcode | Erforderlich | Standardsprache für den Text in diesem Dataset. Mit dieser Einstellung können GTFS-Nutzer Großschreibungsregeln und andere sprachspezifische Einstellungen für das Dataset auswählen. Im Feld language in translations.txt können Sie eine andere Sprache festlegen.Mehrsprachige Datasets können den Originaltext in der Standardsprache und in mehreren anderen Sprachen enthalten. Verwenden Sie in solchen Fällen im Feld feed_lang den ISO 639-2-Sprachcode mul . Geben Sie in translations.txt für alle im Dataset verwendeten Sprachen eine Übersetzung an. Wenn der gesamte Originaltext im Dataset in derselben Sprache verfasst ist, verwenden Sie mul nicht.Bei einem Dataset in der Schweiz könnten beispielsweise für das ursprüngliche Feld stops.stop_name Haltestellennamen in verschiedenen Sprachen verwendet werden. Jeder Haltestellenname wird in der Hauptsprache des Orts geschrieben, in dem sich die Haltestelle befindet. Haltestellennamen sind etwa „Genève“ für die französischsprachige Stadt Genf, „Zürich“ für die deutschsprachige Stadt Zürich und „Biel/Bienne“ für die zweisprachige Stadt Biel/Bienne. Legen Sie feed_lang=mul fest und geben Sie in translations.txt die folgenden Übersetzungen an:
|
default_lang |
Sprachcode | Optional | Legt die Sprache fest, die verwendet werden soll, wenn der Nutzer der Daten die Sprache des Fahrgasts nicht kennt. Oft wird dafür en (Englisch) festgelegt. |
feed_start_date |
Datum | Optional | Das Dataset bietet vollständige und zuverlässige Fahrplaninformationen zum Fahrbetrieb von Beginn des Tags feed_start_date bis Ende des Tags feed_end_date . Wenn keine entsprechenden Daten verfügbar sind, können beide Felder leer bleiben. Wenn beide Angaben gemacht werden, darf das Datum feed_end_date nicht vor dem Datum feed_start_date liegen. Dataset-Anbieter können gern außerhalb dieses Zeitraums liegende Fahrplandaten angeben, um über den möglichen künftigen Fahrbetrieb zu informieren. Nutzer des Datasets sollten sich jedoch darüber im Klaren sein, dass es sich dabei um unverbindliche Angaben handelt. Wenn feed_start_date oder feed_end_date jenseits der in calendar.txt und calendar_dates.txt festgelegten Datumsangaben des aktiven Kalenders liegen, wird im Dataset ausdrücklich davon ausgegangen, dass an Tagen im Zeitraum feed_start_date bis feed_end_date kein Fahrbetrieb stattfindet. |
feed_end_date |
Datum | Optional | Siehe Zeile feed_start_date in dieser Tabelle. |
feed_version |
Text | Optional | String, der die aktuelle Version des GTFS-Datasets angibt. In Anwendungen, die GTFS nutzen, kann dieser Wert angezeigt werden, damit die Herausgeber des Datasets leichter feststellen können, ob das aktuelle Dataset berücksichtigt wurde. |
feed_contact_email |
E-Mail-Adresse | Optional | E-Mail-Adresse für die Kommunikation über das GTFS-Dataset und Praktiken der Datenveröffentlichung. feed_contact_email ist ein technischer Kontakt für Anwendungen, die GTFS nutzen. Geben Sie die Kontaktdaten des Kundenservice über agency.txt an. |
feed_contact_url |
URL | Optional | URL für Kontaktdaten, ein Webformular, den Support-Desk oder andere Tools für die Kommunikation über das GTFS-Dataset und Praktiken der Datenveröffentlichung. feed_contact_url ist ein technischer Kontakt für Anwendungen, die GTFS nutzen. Geben Sie die Kontaktdaten des Kundenservice über agency.txt an. |
translations.txt
Datei: optional
Feldname | Typ | Erforderlich | Beschreibung | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
table_name |
Enum | Erforderlich |
Legt die Dataset-Tabelle fest, die das zu übersetzende Feld enthält. Folgende Werte sind zulässig:
|
||||||||||||||||||
field_name |
Text | Erforderlich |
Gibt den Namen des Felds an, das übersetzt werden soll. Felder vom Typ „Text“ können übersetzt werden, während Felder vom Typ „URL“, „E-Mail“ und „Telefonnummer“ hier eingefügt werden können, damit diese Ressourcen in der richtigen Sprache bereitgestellt werden. |
||||||||||||||||||
language |
Sprachcode | Erforderlich |
Gibt die Sprache der Übersetzung an. Wenn die Sprache identisch ist mit der aus Beispielsweise würde in einem zweisprachigen Kanton in der Schweiz eine Stadt, die offiziell „Biel/Bienne“ heißt, auf Französisch einfach „Bienne“ und auf Deutsch „Biel“ genannt. |
||||||||||||||||||
translation |
Text, URL, E-Mail-Adresse oder Telefonnummer | Erforderlich | Gibt den übersetzten Wert für den angegebenen Feldnamen (field_name ) an. |
||||||||||||||||||
record_id |
ID | Bedingt erforderlich |
Bestimmt den Datensatz, der dem zu übersetzenden Feld entspricht. Der Wert in
Wie dieses Feld verwendet werden kann, richtet sich nach den folgenden Bedingungen:
|
||||||||||||||||||
record_sub_id |
ID | Bedingt erforderlich |
Hilft beim Übersetzen des Datensatzes, der das Feld enthält, wenn die in
Wie dieses Feld verwendet werden kann, richtet sich nach den folgenden Bedingungen:
|
||||||||||||||||||
field_value |
Text, URL, E-Mail-Adresse oder Telefonnummer | Bedingt erforderlich |
Statt mit Das Feld muss genau mit dem in Falls zwei Übersetzungsregeln mit demselben Datensatz übereinstimmen (die eine mit Wie dieses Feld verwendet werden kann, richtet sich nach den folgenden Bedingungen:
|
attributions.txt
Datei: optional
Feldname | Typ | Erforderlich | Beschreibung |
---|---|---|---|
attribution_id |
ID | Optional | Kennzeichnet eine Zuordnung für das Dataset oder einen Teil davon. Dieses Feld ist für Übersetzungen nützlich. |
agency_id |
ID-Verweis | Optional | Betreiber, für den die Zuordnung gilt. Wenn eine agency_id -, route_id - oder trip_id -Zuordnung definiert wird, müssen die anderen Felder leer sein. Wenn nichts angegeben ist, gilt die Zuordnung für das gesamte Dataset. |
route_id |
ID-Verweis | Optional | Dieses Feld funktioniert genauso wie das Feld agency_id , nur dass die Zuordnung für eine Route gilt. Für ein und dieselbe Route können mehrere Zuordnungen gelten. |
trip_id |
ID-Verweis | Optional | Dieses Feld funktioniert genauso wie das Feld agency_id , nur dass die Zuordnung für eine Fahrt gilt. Für ein und dieselbe Fahrt können mehrere Zuordnungen gelten. |
organization_name |
Text | Erforderlich | Name der Organisation, der das Dataset zugeordnet wird. |
is_producer |
Enum | Optional | Die Organisation hat die Rolle des Erstellers („producer“). Folgende Werte sind zulässig: • 0 oder leer: Die Organisation hat diese Rolle nicht.• 1 : Die Organisation hat diese Rolle.Mindestens eines der Felder is_producer , is_operator oder is_authority muss auf 1 festgelegt sein. |
is_operator |
Enum | Optional | Funktioniert genauso wie is_producer , nur dass die Organisation die Rolle des Betreibers („operator“) hat. |
is_authority |
Enum | Optional | Funktioniert genauso wie is_producer , nur dass die Organisation die Rolle der Behörde („authority“) hat. |
attribution_url |
URL | Optional | URL der Organisation. |
attribution_email |
E-Mail-Adresse | Optional | E-Mail-Adresse der Organisation. |
attribution_phone |
Telefonnummer | Optional | Telefonnummer der Organisation. |