コンテンツにスキップ

参照

General Transit Feed Specificationリファレンス

2024 年 8 月 16 日に改訂されました。詳細については、改訂履歴を参照してください。

このドキュメントでは、GTFS データセットを構成するファイルの形式と構造を定義します。

目次

  1. ドキュメントの規則
  2. データセット ファイル
  3. ファイル要件
  4. データセットの公開と一般的な慣行
  5. フィールド定義

ドキュメントの規則

このドキュメント内のキーワードしなければならないしてはいけない必須しなければならないしてはならないするべきであるするべきではない推奨されるしてもよい、および任意は、RFC 2119で説明されているとおりに解釈されます。

用語の定義

このセクションでは、このドキュメント全体で使用される用語を定義します。

  • データセット - この仕様リファレンスによって定義されるファイルの完全なセット。データセットを変更すると、データセットの新しいバージョンが作成されます。データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります (例: https://www.agency.org/gtfs/gtfs.zip)。
  • レコード - 単一のエンティティ (交通機関、停留所、ルートなど) を説明するさまざまなフィールド値で構成される基本データ構造。テーブルでは行として表されます。
  • フィールド - オブジェクトまたはエンティティのプロパティ。テーブルでは列として表されます。フィールドは、ファイルにヘッダーとして追加された場合に存在します。フィールド値が定義されている場合と、定義されていない場合があります。
  • フィールド値 - フィールド内の個々のエントリ。テーブルでは 1つのセルとして表されます。
  • サービス日 - サービス日は、ルートのスケジュールを示すために使用される期間です。サービス日の正確な定義は機関によって異なりますが、サービス日は多くの場合、暦日と一致しません。サービスが 1 日に開始され、翌日に終了する場合、サービス日は 24:00:00 を超えることがあります。たとえば、金曜日の 08:00:00 から土曜日の 02:00:00 まで実行されるサービスは、1つのサービス日に 08:00:00 から 26:00:00 まで実行されると示される場合があります。
  • 音声合成フィールド - フィールドには、親フィールド (空の場合はフォールバックされるフィールド) と同じ情報が含まれている必要があります。これは音声合成で読み上げられることを目的としているため、省略形は削除するか (StStreetまたはSaintと読み上げ、h Ihthe firstと読み上げます)、そのまま読み上げます (K Airport`は省略されているとされています)。
  • 区間 - 乗客が旅行中の 2つの連続する場所の間で乗り降りする旅行。
  • 旅程 - 出発地から目的地までの全体的な旅行。途中のすべての区間と乗り換えを含みます。
  • サブ旅程 - 旅程のサブセットを構成する 2つ以上の区間。
  • 運賃商品 - 旅行の支払いや検証に使用できる購入可能な運賃商品。

存在

フィールドとファイルに適用される存在条件:

  • 必須 - フィールドまたはファイルはデータセットに含まれ、各レコードに有効な値が含まれている必要があります。
  • 任意 - フィールドまたはファイルは、データセットから省略できます。
  • 条件付きで必須 - フィールドまたはファイルは、フィールドまたはファイルの説明に記載されている条件に従って含める必要があります。
  • 条件付きで禁止 - フィールドまたはファイルは、フィールドまたはファイルの説明に記載されている条件に従って含めないでください。
  • 推奨 - フィールドまたはファイルはデータセットから省略できますが、含めることがベストプラクティスです。このフィールドまたはファイルを省略する前に、ベストプラクティスを慎重に評価し、省略による影響を完全に理解する必要があります。

フィールドタイプ

  • - 6桁の16進数としてエンコードされた色。有効な値を生成するには、https://htmlcolorcodes.com を参照してください (先頭の#を含めることはできません)。
    例: 白の場合はFFFFFF、黒の場合は 000000、NYMTA の A、C、E ラインの場合は 0039A6
  • 通貨コード - ISO 4217 アルファベット順の通貨コード。現在の通貨のリストについては、https://en.wikipedia.org/wiki/ISO_4217#Active_codes を参照してください。
    例: カナダドルの場合はCAD、ユーロの場合はEUR、日本円の場合はJPY
  • 通貨金額 - 通貨金額を示す小数値。小数点以下の桁数は、付随する通貨コードの ISO 4217 で指定されています。すべての財務計算は、データの使用に使用するプログラミング言語に応じて、小数点、通貨、または財務計算に適した同等の型として処理する必要があります。計算中に金銭の損益が発生する可能性があるため、通貨金額をfloatとして処理することは推奨されません。
  • 日付 - YYYYMMDD 形式のサービス日。サービス日内の時刻は 24:00:00 を超える場合があるため、サービス日には後続の日の情報が含まれることがあります。
    例: 2018 年 9 月 13 日の場合は20180913
  • 電子メール - 電子メール アドレス。
    例: example@example.com
  • Enum - 説明列で定義された定義済み定数のセットからのオプション。
    例: route_typeフィールドには、路面電車の場合は 0、地下鉄の場合は1 が含まれます...
  • ID - IDフィールドの値は内部IDであり、乗客に表示されるものではなく、UTF-8 文字のシーケンスです。印刷可能な ASCII 文字のみを使用することをお勧めします。ファイル内で一意である必要がある ID には、一意のIDというラベルが付けられます。1つの.txtファイルで定義されたIDは、別の.txtファイルで参照されることがよくあります。別のテーブルのIDを参照する ID には、外部IDというラベルが付けられます。
    例: stops.txtstop_idフィールドは一意のIDです。stops.txtparent_stationフィールドはstops.stop_idを参照する外部ID `です。
  • 言語コード - IETF BCP 47 言語コード。IETF BCP 47 の概要については、http://www.rfc-editor.org/rfc/bcp/bcp47.txt および http://www.w3.org/International/articles/language-tags/ を参照してください。
    例: 英語の場合はen、アメリカ英語の場合はen-US、ドイツ語の場合は de
  • 緯度 - 10 進度での WGS84 緯度。値は -90.0 以上 90.0 以下である必要があります。
    例: ローマのコロッセオの場合は 41.890169
  • 経度 - 10 進度での WGS84 経度。値は -180.0 以上 180.0 以下である必要があります。
    例: ローマのコロッセオの場合は 12.492269
  • Float - 浮動小数点数。
  • Integer - 整数。
  • Phone number - 電話番号。
  • Time - HH:MM:SS 形式の時間 (H:MM:SS も使用可能)。時間は、サービス日の 12 時間を引いた時間から測定されます (夏時間の変更が行われる日を除いて、実質的には真夜中)。サービス日の真夜中以降に発生する時間については、HH:MM:SS で 24:00:00 より大きい値として時間を入力します。<br>*例: 午後 2:30 の場合は14:30:00、翌日の午前 1:35 の場合は25:35:00`。*
  • Text - UTF-8 文字のstring。表示を目的としているため、人間が判読できる必要があります。
  • タイムゾーン - https://www.iana.org/time-zones の TZ タイムゾーン。タイムゾーン名にはスペース文字は含まれませんが、アンダースコアは含めることができます。有効な値の一覧については、http://en.wikipedia.org/wiki/List_of_tz_zones を参照してください。
    例: Asia/TokyoAmerica/Los_AngelesAfrica/Cairo
  • URL - http:// または https:// を含む完全修飾 URL。URL 内の特殊文字は正しくエスケープする必要があります。完全修飾 URL 値の作成方法については、次の http://www.w3.org/Addressing/URL/4_URI_Recommentations.html を参照してください。

フィールド記号

Float または Integer フィールド タイプに適用される記号:

  • 非負 - 0 以上。
  • 非ゼロ - 0 と等しくない。
  • - 0 より大きい。

例: 非負float - 0 以上の浮動小数点数。_

データセット属性

データセットの 主キー は、行を一意に識別するフィールドまたはフィールドの組み合わせです。主キー (*) は、ファイルに提供されたすべてのフィールドを使用して行を一意に識別するときに使用されます。 主キー (none) は、ファイルで 1 行のみが許可されることを意味します。

例: trip_id フィールドと stop_sequence フィールドは stop_times.txt の主キーになります。_

データセット ファイル

この仕様では、次のファイルを定義します:

ファイル名 存在 説明
agency.txt 必須 このデータセットで表されるサービスを提供する交通機関。
stops.txt 条件付きで必須 車両が乗客を乗降させる停留所等。駅と駅の入口も定義します。

条件付きで必須:
- locations.geojson で需要対応ゾーンが定義されている場合は任意。
- それ以外の場合は必須
routes.txt 必須 交通機関のルート。ルートは、乗客に単一のサービスとして表示される旅行のグループです。
trips.txt 必須 各ルートの便。旅行とは、特定の期間内に発生する 2つ以上の停留所のシーケンスです。
stop_times.txt 必須 各旅行で車両が停留所に到着および出発する時刻。
calendar.txt 条件付きで必須 開始日と終了日を含む週次スケジュールを使用して指定された運行日。

条件付きで必須:
- calendar_dates.txt ですべてのサービス日付が定義されていない限り、必須 です。
- それ以外の場合は任意。
calendar_dates.txt 条件付きで必須 calendar.txt で定義されたサービスの例外。

条件付きで必須:
- ** calendar.txt が省略されている場合は必須。その場合、calendar_dates.txt にはサービスの日付がすべて含まれている必要があります。
- それ以外の場合は任意。
fare_attributes.txt 任意 交通機関のルートの運賃情報。
fare_rules.txt 任意 旅程に運賃を適用するルール。
timeframes.txt 任意 dateと時間の要因に依存する運賃の運賃ルールで使用する日付と時間の期間。
fare_media.txt 任意 運賃製品を使用するために使用できる運賃メディアを説明します。

ファイル fare_media.txt は、fare_attributes.txt および fare_rules.txt に示されていない概念について説明します。そのため、fare_media.txt の使用は、ファイル fare_attributes.txt および fare_rules.txt とは完全に独立しています。
fare_products.txt 任意 乗客が購入できるさまざまな種類のチケットまたは運賃について説明します。

ファイル fare_products.txt には、fare_attributes.txt および fare_rules.txt に示されていない運賃商品が記載されています。そのため、fare_products.txt の使用は、ファイル fare_attributes.txt および fare_rules.txt とは完全に独立しています。
fare_leg_rules.txt 任意 個々の旅行区間の運賃規則。

ファイル fare_leg_rules.txt は、運賃構造をモデル化するためのより詳細な方法を提供します。そのため、fare_leg_rules.txt の使用は、ファイル fare_attributes.txt および fare_rules.txt とは完全に別です。
fare_transfer_rules.txt 任意 旅行区間間の乗り継ぎに関する運賃規則。

fare_leg_rules.txt とともに、ファイル fare_transfer_rules.txt は、運賃構造をモデル化するより詳細な方法を提供します。そのため、fare_transfer_rules.txt の使用は、ファイル fare_attributes.txt および fare_rules.txt とは完全に別です。
areas.txt 任意 場所のエリアグループ化。
stop_areas.txt 任意 停留所をエリアに割り当てるルール。
networks.txt 条件付きで禁止 ルートのネットワークグループ化。

条件付きで禁止:
- routes.txtnetwork_idが存在する場合は禁止です。
- それ以外の場合は任意。
route_networks.txt 条件付きで禁止 ネットワークにルートを割り当てるルール。

条件付きで禁止:
- routes.txtnetwork_idが存在する場合は禁止です。
- それ以外の場合は任意。
shapes.txt 任意 車両の移動経路をマッピングするためのルール。ルート配置と呼ばれることもあります。
frequencies.txt 任意 ヘッドウェイベースのサービスのヘッドウェイ (旅行間の時間)、または固定スケジュールサービスの圧縮表現。
transfers.txt 任意 ルート間の乗り換えポイントでの接続を確立するためのルール。
pathways.txt 任意 駅内の場所をリンクする構内通路。
levels.txt 条件付きで必須 駅内の階・フロア。

条件付きで必須:
- エレベーター付きの経路を記述する場合 (pathway_mode=5) 必須
- それ以外の場合は任意。
location_groups.txt 任意 乗客が乗車または降車をリクエストできる場所を示す停車地のグループ。
location_group_stops.txt 任意 停車地を場所グループに割り当てるルール。
locations.geojson 任意 オンデマンド サービスによる乗客の乗車または降車リクエストのゾーン。GeoJSON ポリゴンとして表されます。
booking_rules.txt 任意 乗客がリクエストしたサービスの予約情報。
translations.txt 任意 顧客向けのデータセット値の翻訳。
feed_info.txt 条件付きで必須 発行者、バージョン、有効期限情報を含むデータセットのメタデータ。

条件付きで必須:
- translations.txt が提供されている場合は必須です。
- それ以外の場合は推奨。
attributions.txt 任意 データセットの帰属表示。

ファイル要件

データセット ファイルの形式と内容には、次の要件が適用されます。

  • すべてのファイルは、カンマ区切りのテキストとして保存する必要があります。
  • 各ファイルの最初の行には、フィールド名が含まれている必要があります。フィールド定義 セクションの各サブセクションは、GTFS データセット内のファイルの 1つに対応し、そのファイルで使用できるフィールド名をリストします。
  • すべてのファイル名とフィールド名は、大文字と小文字が区別されます。
  • フィールド値には、タブ、復帰改行、または改行を含めることはできません。
  • 引用符またはカンマを含むフィールド値は、引用符で囲む必要があります。また、フィールド値内の各引用符の前には引用符を付ける必要があります。これは、Microsoft Excel がカンマ区切り (CSV) ファイルを出力する方法と一致しています。 CSV ファイル形式の詳細については、http://tools.ietf.org/html/rfc4180 を参照してください。 次の例は、フィールド値がコンマ区切りファイルでどのように表示されるかを示しています。
  • 元のフィールド値: Contains "quotes", commas and text
  • CSV ファイル内のフィールド値: "Contains ""quotes"", commas and text"
  • フィールド値には、HTML タグ、コメント、またはエスケープ シーケンスを含めることはできません。
  • フィールド間またはフィールド名間の余分なスペースは削除する必要があります。多くのパーサーは、スペースを値の一部と見なすため、エラーが発生する可能性があります。
  • 各行は、CRLF または LF 改行文字で終了する必要があります。
  • すべての Unicode 文字をサポートするには、ファイルを UTF-8 でエンコードする必要があります。Unicode バイト オーダー マーク (BOM) 文字を含むファイルは許容されます。 BOM 文字と UTF-8 の詳細については、http://unicode.org/faq/utf_bom.html#BOM を参照してください。
  • すべてのデータセット ファイルは、まとめて zip 圧縮する必要があります。ファイルは、サブフォルダーではなく、ルート レベルに直接配置する必要があります。
  • 顧客向けのすべてのテキスト文字列 (停留所名、ルート名、行先標識を含む) では、小文字を表示できるディスプレイで地名を大文字にするローカル規則に従い、大文字と小文字を混在させる必要があります (例: “Brighton Churchill Square”、“Villiers-sur-Marne”、“Market Street”)。
  • フィード全体で、名前やその他のテキストの略語の使用は避けてください (例: Street の代わりに St.)。ただし、場所が略称で呼ばれる場合は除きます (例: “JFK Airport”)。略語は、スクリーン リーダー ソフトウェアや音声ユーザー インターフェイスによるアクセシビリティに問題が生じる可能性があります。使用ソフトウェアは、完全な単語を略語に確実に変換して表示するように設計できますが、略語から完全な単語に変換すると、エラーが発生するリスクが高くなります。

データセットの公開と一般的な方法

  • データセットは、zip ファイル名を含むパブリックの永続的な URL で公開する必要があります。(例: www.agency.org/gtfs/gtfs.zip) 理想的には、使用ソフトウェア アプリケーションによるダウンロードを容易にするために、ファイルにアクセスするためにログインする必要なく、URL を直接ダウンロードできる必要があります。 GTFS データセットはオープンにダウンロードできるようにすることが推奨されています(そして最も一般的な方法です)が、データ プロバイダーがライセンスやその他の理由で GTFS へのアクセスを制御する必要がある場合は、自動ダウンロードを容易にする API キーを使用して GTFS データセットへのアクセスを制御することが推奨されます。
  • GTFS データは、安定した場所にある 1つのファイルに、交通機関(または機関群)のサービスの最新の公式説明が常に含まれるように、反復して公開する必要があります。
  • データセットは、可能な限り、データの反復をまたいでstop_idroute_id、およびagency_idの永続的な識別子(id フィールド)を維持する必要があります。
  • 1つの GTFS データセットには、現在のサービスと今後のサービスを含める必要があります(統合データセットと呼ばれることもあります)。 2つの異なる GTFS フィードから結合されたデータセットを作成するために使用できる マージ ツール が複数あります。
    • 公開された GTFS データセットは、いつでも少なくとも今後 7 日間は有効である必要があります。理想的には、運行会社がスケジュールが継続して運用されると確信している限り有効です。
    • 可能であれば、GTFS データセットは少なくとも今後 30 日間のサービスをカバーする必要があります。
  • 古いサービス (期限切れのカレンダー) はフィードから削除する必要があります。
  • サービスの変更が 7 日以内に有効になる場合は、このサービスの変更は、静的な GTFS データセットではなく、GTFS リアルタイム フィード (サービス アドバイザリまたは旅行更新) を通じて表現する必要があります。
  • GTFS データをホストする Web サーバーは、ファイル変更dateを正しく報告するように構成する必要があります (HTTP/1.1 - Request for Comments 2616, under Section 14.29).

フィールド定義

agency.txt

ファイル: 必須

主キー(agency_id)

フィールド名 タイプ 存在 説明
agency_id ユニークID 条件付きで必須 多くの場合、交通機関と同義である交通ブランドを識別します。1つの機関が複数の個別のサービスを運営している場合など、機関とブランドは異なる場合があることに注意してください。 このドキュメントでは、「ブランド」の代わりに「機関」という用語を使用します。 データセットには、複数の機関のデータが含まれる場合があります。

条件付きで必須:
- データセットに複数の交通機関のデータが含まれている場合は必須です。
- それ以外の場合は推奨。
agency_name Text 必須 交通機関の正式名称。
agency_url URL 必須 交通機関の URL。
agency_timezone タイムゾーン 必須 交通機関が所在するタイムゾーン。データセットで複数の機関が指定されている場合、それぞれに同じagency_timezoneが必要です。
agency_lang 言語コード 任意 この交通機関が使用する主な言語。GTFS のユーザーがデータセットの大文字と小文字の規則やその他の言語固有の設定を選択できるようにするために提供する必要があります。
agency_phone 電話番号 任意 指定された機関の音声電話番号。このフィールドは、機関のサービスエリアの一般的な電話番号を表すstring値です。数字をグループ化するために句読点を含めることができます。ダイヤル可能なテキスト (TriMet の503-238-RIDEなど) は許可されていますが、フィールドにはその他の説明テキストを含めることはできません。
agency_fare_url URL 任意 乗客がその機関のチケットやその他の運賃手段をオンラインで購入できる Web ページの URL。
agency_email 電子メール 任意 機関のカスタマー サービス部門によってアクティブに監視されている電子メール アドレス。この電子メール アドレスは、交通機関の乗客が機関のカスタマー サービス担当者に連絡できる直接の連絡先である必要があります。

stops.txt

ファイル: 条件付きで必須

主キー(stop_id)

フィールド名 タイプ 存在 説明
stop_id ユニークID 必須 場所を識別します: 停留所/プラットフォーム、駅、入口/出口、汎用ノード、または乗車エリア (location_typeを参照)。

ID は、すべてのstops.stop_id、locations.geojson id、およびlocation_groups.location_group_id値にわたって一意である必要があります。

複数のルートで同じstop_idが使用される場合があります。
stop_code Text 任意 乗客に対して場所を識別する短いテキストまたは番号。これらのコードは、多くの場合、電話ベースの交通情報システムで使用され、または乗客が特定の場所の情報を入手しやすくするために標識に印刷されます。 stop_code は、一般向けである場合はstop_idと同じになることがあります。乗客にコードが提示されない場所では、このフィールドは空白のままにしてください。
stop_name Text 条件付きで必須 場所の名前。 stop_name は、時刻表に印刷されているか、オンラインで公開されているか、標識に表示されている、機関の乗客向けの場所の名前と一致する必要があります。他の言語に翻訳するには、translations.txt を使用します。

場所が乗車エリアの場合 (location_type=4)、stop_name には、機関が表示する乗車エリアの名前を含める必要があります。これは、1 文字だけの場合 (一部のヨーロッパの都市間鉄道駅のように) もあれば、車椅子乗車エリア(ニューヨーク市の地下鉄) や短距離列車の先頭(パリの RER) のようなテキストの場合もあります。

条件付きで必須:
- 停留所 (location_type=0)、駅 (location_type=1)、または入口/出口 (location_type=2) の場所の場合は 必須 です。
- 汎用ノード (location_type=3) または乗車エリア (location_type=4) の場所の場合は任意。
tts_stop_name Text 任意 stop_nameの読み取り可能なバージョン。詳細については、用語の定義テキスト読み上げフィールドを参照してください。
stop_desc Text 任意 有用で質の高い情報を提供する場所の説明。stop_name と重複してはいけません。
stop_name stop_lat 緯度 条件付きで必須 場所の緯度。

停留所/プラットフォーム (location_type=0) および乗車エリア (location_type=4) の場合、座標はバスポール (存在する場合) の座標でなければならず、そうでない場合は旅行者が車両に乗車する場所 (車両が停止する道路や線路ではなく、歩道またはプラットフォーム) の座標でなければなりません。

条件付きで必須:
- 停留所 (location_type=0)、駅 (location_type=1)、または入口/出口 (location_type=2) の場所の場合は 必須 です。
- 汎用ノード (location_type=3) または乗車エリア (location_type=4) の場所の場合は任意。
stop_lon 経度 条件付きで必須 場所の経度。

停留所/プラットフォーム (location_type=0) および乗車エリア (location_type=4) の場合、座標はバスポール (存在する場合) の座標でなければならず、そうでない場合は旅行者が車両に乗車する場所 (車両が停止する道路や線路ではなく、歩道またはプラットフォーム) の座標でなければなりません。

条件付きで必須:
- 停留所 (location_type=0)、駅 (location_type=1)、または入口/出口 (location_type=2) の場所の場合は 必須 です。
- 汎用ノード (location_type=3) または乗車エリア (location_type=4) の場所の場合は任意。
zone_id ID 任意 停車場の料金ゾーンを識別します。このレコードが駅または駅の入口を表す場合、zone_idは無視されます。
stop_url URL 任意 場所に関する Web ページの URL。これは、agency.agency_urlおよびroutes.route_urlフィールド値とは異なる必要があります。
location_type 列挙型 任意 場所の種類。有効なオプションは次のとおりです。

0 (または空白) - 停留所 (または プラットフォーム)。乗客が交通機関の車両に乗車parent_station降車する場所です。parent_station 内で定義されている場合はプラットフォームと呼ばれます。
1 - 。1つ以上のプラットフォームを含む物理的な構造またはエリア。
2 - 入口/出口。乗客が通りから駅に出入りできる場所です。入口/出口が複数の駅に属している場合、両方の駅に経路でリンクされている可能性がありますが、データ プロバイダーはそのうちの 1つを親として選択する必要があります。
3 - 汎用ノード。他のlocation_typeに一致しない駅内の場所。pathways.txt で定義された経路をリンクするために使用できます。
4 - 乗車エリア。乗客が車両に乗ったり降車したりできるプラットフォーム上の特定の場所です。
parent_station stops.stop_id部ID 条件付きで必須 stops.txt で定義されているさまざまな場所間の階層を定義します。次のように、親の場所のIDが含まれます。

- 停車駅/プラットフォーム (location_type=0): parent_stationフィールドには駅のIDが含まれます。
- (location_type=1): このフィールドは空でなければなりません。
- 入口/出口 (location_type=2) または 汎用ノード (location_type=3): parent_stationフィールドには駅のIDが含まれます (location_type=1)
- 乗車エリア (location_type=4): parent_stationフィールドにはプラットフォームのIDが含まれます。

条件付きで必須:
- 入口 (location_type=2)、汎用ノード (location_type=3)、または搭乗エリア (location_type=4) の場所の場合は 必須 です。
- 停留所/プラットフォームの場合は任意(location_type=0)。
- 駅 (location_type=1) では禁止されています。
stop_timezone タイムゾーン 任意 場所のタイムゾーン。場所に親駅がある場合は、独自のタイムゾーンを適用する代わりに、親駅のタイムゾーンを継承します。stop_timezoneが空の駅と親のない停留所は、agency.agency_timezoneで指定されたタイムゾーンを継承します。stop_times.txt で提供される時間は、stop_timezone agency.agency_timezoneで指定されたタイムゾーンです。これにより、旅行がどのタイムゾーンを通過するかに関係なく、旅行の途中で旅行の時間値が常に増加することが保証されます。
wheelchair_boarding 列挙型 任意 場所から車椅子で乗車できるかどうかを示します。有効なオプションは次のとおりです。

保護者のいない場合の停止:
0 または空 - 停留所のアクセシビリティ情報がありません。
1 - この停留所の一部の車両は車椅子に乗ったライダーが乗っています。
2 - この停留所では車椅子での乗車はできません。

チャイルドストップの場合:
0 または空 - 親ステーションで指定されている場合、停留所は親ステーションからwheelchair_boarding動作を継承します。
1 - 駅の外から特定の停留所/プラットフォームまでアクセス可能な経路が存在します。
2 - 駅の外から特定の停留所/プラットフォームまでアクセス可能な経路が存在しません。

駅の出入口について:
0 または空 - 親に指定されている場合、駅の入口は親駅のwheelchair_boarding動作を継承します。
1 - 駅の入り口は車椅子でアクセス可能です。
2 - 駅の入口から停留所/プラットフォームへのアクセス経路がありません。
level_id levels.level_id部ID 任意 場所のレベル。同じレベルが、リンクされていない複数の駅で使用される場合があります。
platform_code Text 任意 プラットフォーム停留所 (駅に属する停留所) のプラットフォーム識別子。これは、プラットフォーム識別子のみである必要があります (例: "G" または "3")。「プラットフォーム」や「トラック」などの単語 (またはフィードの言語固有の同等語) を含めないでください。これにより、フィード コンシューマーは、プラットフォーム識別子を他の言語に国際化およびローカライズしやすくなります。

routes.txt

ファイル: 必須

主キー(route_id)

フィールド名 タイプ 存在 説明
route_id ユニークID 必須 ルートを識別します。
agency_id agency.agency_id部ID 条件付きで必須 指定されたルートの事業者。

条件付きで必須:
- agency.txt に複数の代理店が定義されている場合は必須です。
- それ以外の場合は推奨。
route_short_name Text 条件付きで必須 ルートの短縮名。多くの場合、乗客がルートを識別するために使用する短い抽象的な識別子 (例: 「32」、「100X」、「緑」)。route_short_nameroute_long_nameroute_short_nameを定義できます。

条件付きで必須:
- ** routes.route_long_nameが空の場合は必須** です。
- 簡単なサービス指定がある場合に推奨。これは、サービスの一般的な乗客名である必要があり、12文字以内にする必要があります。
route_long_name Text 条件付きで必須 ルートの完全な名前。この名前は通常、route_short_nameよりも説明的で、ルートの目的地または停車地が含まれることがよくあります。route_short_nameroute_long_nameの両方を定義できます。

条件付きで必須:
- routes.route_short_nameが空の場合は必須です
- それ以外の場合は任意。
route_desc Text 任意 有用で質の高い情報を提供するルートの説明。route_short_nameまたはroute_long_nameと重複してはいけません。
例: A列車は、マンハッタンの Inwood-207 St とクイーンズの Far Rockaway-Mott Avenue の間を常時運行しています。また、午前6時頃から深夜頃まで、追加のAが`Inwood-207 St と Lefferts Boulevard の間を運行しています (列車は通常、Lefferts Blvd と Far Rockaway の間を交互に運行します)。
route_type Enum 必須 ルートで使用される交通機関の種類を示します。有効なオプションは次のとおりです。

0 - 路面電車、路面電車、ライトレール。大都市圏内のライトレールまたはストリートレベルのシステム。
1 - 地下鉄。大都市圏内のあらゆる地下鉄システム。
2 - 鉄道。都市間または長距離の移動に使用されます。
3 - バス。短距離および長距離のバス路線に使用されます。
4 - フェリー。短距離および長距離の船舶サービスに使用されます。
5 - ケーブル トラム。ケーブルが車両の下を走る路面電車に使用されます (例: サンフランシスコのケーブルカー)。
6 - 空中リフト、吊り下げ式ケーブルカー(例:ゴンドラリフト、空中ケーブルウェイ)。キャビン、車両、ゴンドラ、またはオープンチェアが 1 本以上のケーブルによって吊り下げられているケーブル輸送。
7 - ケーブルカー。急勾配向けに設計された鉄道システム。
11 - トロリーバス。ポールを使用して架空線から電力を供給する電気バス。
12 - モノレール。線路が単一のレールまたはビームで構成される鉄道。
route_url URL 任意 特定のルートに関する Web ページの URL。agency.agency_url 値とは異なる必要があります。
route_color 任意 公開資料に一致するルートの色の指定。省略または空のままにした場合、デフォルトで白 (FFFFFF) になります。 route_colorroute_text_colorの色の違いは、白黒agency.agency_urlで表示したときに十分なコントラストを提供する必要があります。
route_text_color 任意 route_colorの背景に描画されるテキストに使用する判読可能な色。省略または空のままにした場合、デフォルトで黒 (000000) になります。 route_colorroute_text_colorの色の違いは、白黒画面で表示したときに十分なコントラストを提供する必要があります。
route_sort_order 負でない整数 任意 顧客への提示に最適な方法でルートを並べ替えます。route_sort_order 値が小さいルート・路線系統が最初に表示されます。
continuous_pickup 列挙型 条件付きで禁止 ルートのすべての旅行で、shapes.txt で説明されているように、乗客が車両の移動経路に沿った任意の地点で交通機関の車両に乗車できることを示します。有効なオプションは次のとおりです。

0 - 連続停止ピックアップ。
1または空 - 連続停止ピックアップなし。
2 - 継続的な停車ピックアップを手配するには代理店に電話するしなければならない。
3 - 連続停止ピックアップを手配するにはドライバーと調整するしなければならない。

routes.continuous_pickupの値は、ルート沿いの特定のstop_timeに対してstop_times.continuous_pickupの値を定義することによって上書きできます。

条件付きで禁止:
- このルートのいずれかの旅行にstop_times.start_pickup_drop_off_windowまたはstop_times.end_pickup_drop_off_windowが定義されている場合は禁止です。
- それ以外の場合は任意。
continuous_drop_off 列挙型 条件付きで禁止 乗客がルートのすべての旅行で、shapes.txt で説明されているように、車両の移動経路に沿った任意の地点で交通機関の車両から降車できることを示します。有効なオプションは次のとおりです。

0 - 連続停止ドロップオフ。
1または空 - 連続停止ドロップオフなし。
2 - 連続停車降車を手配するには代理店に電話するしなければならない。
3 - 連続停車降車を手配するには、ドライバーと調整するしなければならない。

routes.continuous_drop_offの値は、ルート沿いの特定のstop_timeに対してstop_times.continuous_drop_offの値を定義することによって上書きできます。

条件付きで禁止:
- このルートのいずれかの旅行に stop_times.start_pickup_drop_off_window または stop_times.end_pickup_drop_off_window が定義されている場合は禁止です。
- それ以外の場合は任意。
network_id ID 条件付きで禁止 ルートのグループを識別します。routes.txt 内の複数の行に同じnetwork_idが含まれる場合があります。

条件付きで禁止:
- route_networks.txt ファイルが存在する場合は禁止です。
- それ以外の場合は任意。

trips.txt

ファイル: 必須

主キー(trip_id)

フィールド名 タイプ 存在 説明
route_id routes.route_id部ID 必須 ルートを識別します。
service_id calendar.service_idまたはcalendar_dates.service_id部ID 必須 1つ以上のルートでサービスが利用可能な日付のセットを識別します。
trip_id ユニークID 必須 旅行を識別します。
trip_headsign Text 任意 乗客に旅行の目的地を示す標識に表示されるText。このフィールドは、ルート内の旅行を区別するために使用できる、車両にヘッドサイン テキストが表示されるすべてのサービスに推奨されます。

旅行中にヘッドサインが変わる場合、旅行中の特定のstop_timestop_times.stop_headsignの値を定義することで、trip_headsignの値を上書きできます。
trip_short_name Text 任意 通勤電車の列車番号を識別するなど、乗客に旅行を識別するために使用される一般向けのテキスト。乗客が旅行名をあまり使用しない場合は、trip_short_name trip_short_nameを空にする必要があります。trip_short_name 値を指定する場合、サービス日内の旅行を一意に識別する必要があります。目的地名や特急/急行の指定には使用しないでください。
direction_id 列挙型 任意 旅行の移動方向を示します。このフィールドはルーティングには使用しないでください。時刻表を公開するときに方向別に旅行を分ける方法を提供します。有効なオプションは次のとおりです。

0 - 一方向への移動(例:往路)。
1 - 反対方向に移動します(例:入線)。
例: trip_headsigndirection_idフィールドを一緒に使用して、一連の旅行の各方向への旅行に名前を割り当てることができます。trips.txt ファイルには、時刻表で使用するために次のレコードを含めることができます。
trip_id,...,旅行の見出し,方向ID
1234,...,空港,0
1505,...,Downtown,1
block_id ID 任意 旅行が属するブロックを識別します。ブロックは、共有のサービス日とblock_idによって定義される、同じ車両を使用して行われる単一の旅行または複数の連続した旅行で構成されます。block_idには、異なるサービス日の旅行が含まれる場合があり、個別のブロックが作成されます。以下の例を参照してください。座席内乗り換え情報を提供するには、代わりにtransfer_type 4transfers を指定する必要があります。
shape_id shapes.shape_id部ID 条件付きで必須 旅行の車両移動経路を説明する地理空間シェイプを識別します。

条件付きで必須:
- 旅行に routes.txt または stop_times.txt のいずれかで定義された連続的な乗車または降車動作がある場合、必須 です。
- それ以外の場合は任意です。
wheelchair_accessible 列挙型 任意 車椅子でのアクセス可能性を示します。有効なオプションは次のとおりです:

0 または空 - 旅行のアクセシビリティ情報はありません。
1 - この特定の旅行で使用される車両には、少なくとも 1 人の車椅子の乗客を収容できます。
2 - この旅行では車椅子の乗客は乗車できません。
bikes_allowed 列挙型 任意 自転車が許可されているかどうかを示します。有効なオプションは次のとおりです:

0 または空 - 旅行の自転車情報がありません。
1 - この特定の旅行で使用される車両には、少なくとも 1 台の自転車を収容できます。
2 - この旅行では自転車は許可されていません。

例: ブロックとサービス日

以下の例は有効で、曜日ごとに異なるブロックがあります。

route_id trip_id service_id block_id (最初の停止時刻) (最後の停止時刻)
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

上記表に関する注記:

  • たとえば、金曜日から土曜日の朝にかけて、1 台の車両がtrip_1trip_2、およびtrip_3を運行します (午後 10 時から午前 12 時 55 分まで)。最後の運行は土曜日の午前 12 時から午前 12 時 55 分までですが、時刻が 24:00:00 から 24:55:00 であるため、金曜日の​​運行日の一部であることに注意してください。
  • 月曜日、火曜日、水曜日、および木曜日には、1 台の車両が午後 8 時から午後 10 時 55 分までのブロックでtrip_1trip_4、およびtrip_5を運行します。

stop_times.txt

ファイル: 必須

主キー(trip_idstop_sequence)

フィールド名 タイプ 存在 説明
trip_id trips.trip_id部ID 必須 旅行を識別します。
arrival_time 時間 条件付きで必須 stops.stop_timezoneではなくagency.agency_timezoneゾーンでの、特定の旅行 (stop_times.stop_idで定義) の停留所 (stop_times.trip_idstop_times.stop_id で定義) への到着時刻。

停留所での到着時間と出発時間が別々でない場合は、arrival_timedeparture_time は同じである必要があります。

サービス日の深夜以降の時間については、HH:MM:SS 形式で 24:00:00 より大きい値を入力します。

正確な到着時刻と出発時刻 (timepoint=1) が利用できない場合は、推定または補間された到着時刻と出発時刻 (timepoint=0) を指定する必要があります。

条件付きで必須:
- 旅行の最初と最後の停車地に必須 (stop_times.stop_sequenceで定義)。
- timepoint=1の場合は必須 です。
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合は禁止です。
- それ以外の場合は任意。
departure_time 時間 条件付きで必須 stops.stop_timezoneではなくagency.agency_timezoneで指定されたタイムゾーンでの、特定の旅行 (stop_times.trip_idで定義) からの出発時刻。

停留所での到着時間と出発時間が別々でない場合は、arrival_timedeparture_time は同じである必要があります。

サービス日の深夜以降の時間については、HH:MM:SS 形式で 24:00:00 より大きい値を入力します。

正確な到着時刻と出発時刻 (timepoint=1) が利用できない場合は、推定または補間された到着時刻と出発時刻 (timepoint=0) を指定する必要があります。

条件付きで必須:
- ** timepoint=1 の場合は必須 です。
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合は
禁止**です。
- それ以外の場合は任意。
stop_id stops.stop_id部ID 条件付きで必須 サービス対象の停留所を識別します。旅行中にサービスされるすべての停留所は、stop_times.txt に記録されている必要があります。参照される場所は停留所/プラットフォームである必要があります。つまり、stops.location_type値は 0 または空である必要があります。同じ旅行で停留所が複数回サービスされる場合があり、複数の旅行とルートが同じ停留所にサービスを提供する場合があります。

停留所を使用するオンデマンド サービスは、それらの停留所でサービスが利用できる順序で参照する必要があります。データ コンシューマーは、各 stop_time のpickup/drop_off_typeと各start/end_pickup_drop_off_windowの時間制約によって禁止されていない限り、ある停留所または場所から旅行中の後の任意の停留所または場所への移動が可能であると想定する必要があります。

条件付きで必須:
- 必須 stop_times.location_group_idstop_times.location_idが定義されていない場合。
- stop_times.location_group_idまたはstop_times.location_idが定義されている場合は禁止です。
location_group_id location_groups.location_group_id部 ID 条件付きで禁止 乗客が乗車または降車をリクエストできる停留所のグループを示すサービス対象の場所グループを識別します。旅行中にサービスされるすべての場所グループは、stop_times.txt に記録されている必要があります。複数の旅行とルートが同じ場所グループにサービスを提供できます。

ロケーション グループを使用するオンデマンド サービスは、それらのロケーション グループでサービスが利用可能な順序で参照する必要があります。データ コンシューマーは、各 stop_time のpickup/drop_off_typeと各start/end_pickup_drop_off_windowの時間制約によって禁止されていない限り、ある停留所または場所から旅行中の後の任意の停留所または場所への移動が可能であると想定する必要があります。

条件付きで禁止:
- stop_times.stop_idまたはstop_times.location_idが定義されている場合は禁止です。
location_id locations.geojsonからid部ID 条件付きで禁止 乗客が乗車または降車をリクエストできるサービス提供ゾーンに対応する GeoJSON ロケーションを識別します。旅行中にサービス提供されるすべての GeoJSON ロケーションは、stop_times.txt に記録されている必要があります。複数の旅行とルートで同じ GeoJSON ロケーションにサービスを提供できます。

場所内のオンデマンド サービスは、その場所でサービスが利用できる順序で参照する必要があります。データ コンシューマーは、各 stop_time のpickup/drop_off_typeと各start/end_pickup_drop_off_windowの時間制約によって禁止されていない限り、ある停留所または場所から旅行中の後の任意の停留所または場所への移動が可能であると想定する必要があります。

条件付きで禁止:
- stop_times.stop_idまたはstop_times.location_group_idが定義されている場合は禁止です。
stop_sequence 負でない整数 必須 特定の旅行の停車地、場所グループ、または GeoJSON の場所の順序。値は旅行に沿って増加する必要がありますが、連続している必要はありません。
例: 旅行の最初の場所にはstop_sequence=1、旅行の 2 番目の場所にはstop_sequence=23、3 番目の場所にはstop_sequence=40 などとなります。

同じ場所グループまたは GeoJSON の場所内での移動には、stop_times.txt に同じlocation_group_idまたはlocation_idつ` 2つのレコードが必要です。
stop_headsign Text 任意 乗客に旅行の目的地を示す標識に表示されるText。このフィールドは、停留所間でヘッドサインが変わるときに、デフォルトのtrips.trip_headsignを上書きします。ヘッドサインが旅行全体にわたって表示される場合は、代わりにtrips.trip_headsignを使用する必要があります。

1つのstop_timeに指定されたstop_headsign値は、同じ旅行内の後続のstop_timeには適用されません。同じ旅行内の複数のstop_timetrip_headsignを上書きする場合は、各stop_time行でstop_headsign値を繰り返す必要があります。
start_pickup_drop_off_window 時間 条件付きで必須 GeoJSON の場所、場所グループ、または停留所でオンデマンド サービスが利用可能になる時間。

条件付きで必須:
- stop_times.location_group_idまたはstop_times.location_idが定義されている場合は 必須 です。
- ** end_pickup_drop_off_windowが定義されている場合は必須。
- arrival_timeまたはdeparture_timeが定義されている場合は禁止です。
- それ以外の場合は任意。
end_pickup_drop_off_window 時間 条件付きで必須 GeoJSON の場所、場所グループ、または停留所でオンデマンド サービスが終了する時間。

条件付きで必須:
- stop_times.location_group_idまたはstop_times.location_idが定義されている場合は 必須 です。
- ** start_pickup_drop_off_windowが定義されている場合は必須。
- arrival_timeまたはdeparture_timeが定義されている場合は禁止です。
- それ以外の場合は任意。
pickup_type 列挙型 条件付きで禁止 ピックアップ方法を示します。有効なオプションは次のとおりです:

0 または空 - 定期的にスケジュールされたピックアップ。
1 - ピックアップできません。
2 - 代理店に電話して集荷を手配するしなければならない。
3 - ピックアップを手配するにはドライバーと調整するしなければならない。

条件付きで禁止:
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合、pickup_type=0禁止です。
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合、pickup_type=3禁止 です。
- それ以外の場合は任意。
drop_off_type 列挙型 条件付きで禁止 ドロップオフ方法を示します。有効なオプションは次のとおりです:

0 または空 - 定期的に予定されている降車。
1 - ドロップオフは利用できません。
2 - 降車手配のため代理店に電話するしなければならない。
3 - 降車手配についてはドライバーと調整するしなければならない。

条件付きで禁止:
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合、drop_off_type=0禁止です。
- それ以外の場合は任意。
continuous_pickup 列挙型 条件付きで禁止 乗客は、shapes.txt で説明されているように、このstop_timeから旅行のstop_sequenceの次のstop_timeまで、車両の移動経路に沿った任意の時点で交通機関の車両に乗車できることを示します。有効なオプションは次のとおりです。

0 - 連続停止ピックアップ。
1または空 - 連続停止ピックアップなし。
2 - 継続的な停車ピックアップを手配するには代理店に電話するしなければならない。
3 - 連続停止ピックアップを手配するには、ドライバーと調整するしなければならない。

このフィールドに値が入力されている場合は、routes.txt で定義されている連続ピックアップ動作が上書きされます。このフィールドが空の場合、stop_timeroutes.txt で定義されている連続ピックアップ動作を継承します。

条件付きで禁止:
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合は禁止です。
- それ以外の場合は任意。
continuous_drop_off 列挙型 条件付きで禁止 乗客は、shapes.txt で説明されているように、このstop_timeから旅行のstop_sequenceの次のstop_timeまで、車両の移動経路に沿った任意の地点で交通機関の車両から降車できることを示します。有効なオプションは次のとおりです。

0 - 連続停止ドロップオフ。
1または空 - 連続停止ドロップオフなし。
2 - 連続停車降車を手配するには代理店に電話するしなければならない。
3 - 連続停車降車を手配するには、ドライバーと調整するしなければならない。

このフィールドに値が入力されている場合は、routes.txt で定義されている連続降車動作が上書きされます。このフィールドが空の場合、stop_timeroutes.txt で定義されている連続降車動作を継承します。

条件付きで禁止:
- start_pickup_drop_off_windowまたはend_pickup_drop_off_windowが定義されている場合は禁止です。
- それ以外の場合は任意。
shape_dist_traveled 非負のfloat 任意 最初の停車地からこのレコードで指定された停車地までの、関連付けられたシェイプに沿って実際に移動した距離。このフィールドは、旅行中に任意の 2つの停車地間に描画するシェイプの量を指定します。shapes.txt で使用されているのと同じ単位にするしなければならない。 shape_dist_traveledに使用する値はstop_sequenceとともに増加する必要があります。ルートに沿った逆方向の移動を示すために使用してはなりません。

ループまたはインライン(車両が 1 回の移動で同じ線形部分を横断または移動する)があるルートに推奨。shapes.shape_dist_traveled を参照してください。
例: バスがシェイプの開始から停留所まで 5.25 キロメートルの距離を移動する場合、shape_dist_traveled=5.25 となります。
timepoint 列挙型 任意 停留所の到着時間と出発時間が車両によって厳密に遵守されているか、または概算時間や補間時間であるかを示します。このフィールドにより、GTFS プロデューサーは、概算時間であることを示すとともに、補間された停留所時間を提供できます。有効なオプションは次のとおりです。

0 - 時間はおおよそのものとみなされます。
1 - 時間は正確であるとみなされます。

到着時刻または出発時刻が定義されている stop_times.txt のすべてのレコードには、タイムポイント値が入力されている必要があります。タイムポイント値が指定されていない場合は、すべての時刻が正確であるとみなされます。
pickup_booking_rule_id booking_rules.booking_rule_id を参照する外部 ID 任意 この停車時刻での搭乗予約ルールを識別します。

pickup_type =2 の場合に推奨。
drop_off_booking_rule_id booking_rules.booking_rule_id を参照する外部 ID 任意 この停車時間における降車予約ルールを識別します。

drop_off_type =2 の場合に推奨。

オンデマンド サービスのルーティング動作

  • 出発地と目的地の間のルーティングまたは移動時間を提供する場合、データ コンシューマーは、start_pickup_drop_off_windowおよびend_pickup_drop_off_windowが定義されている同じtrip_idを持つ中間のstop_times.txtレコードを無視する必要があります。無視する必要がある内容の例については、データ例のページ を参照してください。
  • 同じtrip_idつ 2つ以上のstop_times.txtレコード間で、locations.geojson idジオメトリ、start/end_pickup_drop_off_window時間、およびpickup_typeまたはdrop_off_typeが同時に重複することは禁止されています。禁止されている内容の例については、データ例ページを参照してください。

calendar.txt

ファイル: 条件付きで必須

主キー(service_id)

フィールド名 タイプ 存在 説明
service_id ユニークID 必須 1つ以上のルートでサービスが利用可能な日付のセットを識別します。
monday 列挙型 必須 start_dateフィールドとend_dateフィールドで指定されたdate範囲のすべての月曜日にサービスが実行されるかどうかを示します。特定の日付の例外は calendar_dates.txt にリストされていることに注意してください。有効なオプションは次のとおりです。

1 - サービスはdate範囲内のすべての月曜日に利用できます。
0 -date範囲内の月曜日にはサービスは利用できません。
tuesday 列挙型 必須 火曜日に適用される点を除き、mondayと同じように機能します
wednesday 列挙型 必須 水曜日に適用される点を除き、mondayと同じように機能します
thursday 列挙型 必須 木曜日に適用される点を除き、mondayと同じように機能します
friday 列挙型 必須 金曜日に適用される点を除き、mondayと同じように機能します
saturday 列挙型 必須 土曜日に適用される点を除き、mondayと同じように機能します。
sunday 列挙型 必須 日曜日に適用される点を除き、mondayと同じように機能します。
start_date 日付 必須 サービス間隔の開始サービス日。
end_date 日付 必須 サービス間隔の終了サービス日。このサービス日は間隔に含まれます。

calendar_dates.txt

ファイル: 条件付きで必須

主キー(service_iddate)

calendar_dates.txt テーブルは、dateによってサービスを明示的に有効または無効にします。2つの方法で使用できます。

  • 推奨: calendar_dates.txtcalendar.txt と組み合わせて使用​​し、calendar.txt で定義されているデフォルトのサービス パターンの例外を定義します。サービスが通常定期的で、明示的な日付にいくつかの変更がある場合 (たとえば、特別なイベント サービスや学校のスケジュールに対応するため)、これは適切なアプローチです。この場合、calendar_dates.service_idcalendar.service_idを参照する外部IDです。
  • 代替: calendar.txt を省略し、calendar_dates.txt で各サービスのdateを指定します。これにより、かなりのサービスバリエーションが可能になり、通常の週次スケジュールのないサービスに対応できます。この場合、service_idはIDです。
フィールド名 タイプ 存在 説明
service_id calendar.service_id部IDまたはID 必須 1つ以上のルートでサービス例外が発生する日付のセットを識別します。 calendar_dates.txtcalendar_dates.txt を併用する場合、各 (service_iddateservice_id) ペアは calendar.txtcalendar_dates.txt の両方に出現する場合、calendar_dates.txt の情報によって calendar.txt で指定されたサービス情報が変更されます。
date 日付 必須 サービス例外が発生した日付。
exception_type 列挙型 必須 dateフィールドで指定されたdateにサービスが利用可能かどうかを示します。有効なオプションは次のとおりです。

1 - 指定されたdateにサービスが追加されました。
2 - 指定されたdateのサービスが削除されました。
例: ルートに休日に利用できる一連の旅行と、それ以外の日に利用できる一連の旅行があるとします。1つのservice_id が通常のサービス スケジュールに対応し、別のservice_id が休日スケジュールに対応します。特定の休日については、calendar_dates.txt ファイルを使用して休日を休日service_idに追加し、通常のservice_idスケジュールから休日を削除できます。

fare_attributes.txt

ファイル: 任意

主キー(fare_id)

バージョン
運賃を記述するためのモデル化オプションは2つあります。GTFS-運賃V1は、最小限の運賃情報を記述するための従来のオプションです。GTFS-運賃V2は、機関の運賃構造をより詳細に記述できる更新された方法です。どちらも広告に表示できます。

ataset ですが、特定のデータセットに対してデータ コンシューマーが使用する方法は 1つだけです。GTFS-Fares V2 を GTFS- 運賃V1よりも優先することをお勧めします。

GTFS- 運賃V1に関連付けられているファイルは次のとおりです。
- fare_attributes.txt
- fare_rules.txt

GTFS-Fares V2 に関連付けられているファイルは次のとおりです。
- fare_media.txt
- fare_products.txt
- fare_leg_rules.txt
- fare_transfer_rules.txt

フィールド名 タイプ 存在 説明
fare_id ユニークID 必須 運賃クラスを識別します。
price 負でないfloat 必須 currency_typeで指定された単位の運賃。
currency_type 通貨コード 必須 運賃の支払いに使用する通貨。
payment_method 列挙型 必須 運賃を支払う必要がある時期を示します。有効なオプションは次のとおりです。

0 - 運賃は乗車時に支払われます。
1 - 乗車前に運賃を支払う必要があります。
transfers Enum 必須 この運賃で許可される乗り換え回数を示します。有効なオプションは次のとおりです:

0 - この運賃では乗り換えは許可されません。
1 - ライダーは 1 回乗り換えることができます。
2 - ライダーは2回乗り換えることができます。
空 - 無制限の転送が許可されます。
agency_id agency.agency_id部ID 条件付きで必須 運賃の関連代理店を識別します。

条件付きで必須:
- agency.txt に複数の代理店が定義されている場合は必須です。
- それ以外の場合は推奨。
transfer_duration 負でない整数 任意 transfersが期限切れになるまでの時間 (秒単位)。transfers=0 の場合、このフィールドはチケットの有効期間を示すために使用されるか、空のままにすることができます。

fare_rules.txt

ファイル: 任意

主キー(*)

fare_rules.txt テーブルは、fare_attributes.txt の運賃が旅程にどのように適用されるかを指定します。ほとんどの運賃体系では、次のルールの組み合わせが使用されます。

  • 運賃は出発駅または到着駅によって異なります。
  • 運賃は、旅程が通過するゾーンによって異なります。
  • 運賃は、旅程が使用するルートによって異なります。

fare_rules.txt および fare_attributes.txt を使用して運賃体系を指定する方法を示す例については、GoogleTransitDataFeed オープンソース プロジェクト wiki の FareExamples をご覧ください。

フィールド名 タイプ 存在 説明
fare_id fare_attributes.fare_id部ID 必須 運賃クラスを識別します。
route_id routes.route_id部ID 任意 運賃クラスに関連付けられたルートを識別します。同じ運賃属性を持つルートが複数存在する場合は、ルートごとに fare_rules.txt にレコードを作成します。
例: 運賃クラスbがルートTSWTSEで有効な場合、fare_rules.txt ファイルには運賃クラスに関する次のレコードが含まれます。
運賃ID、route_id
b,TSW
b,TSE
origin_id stops.zone_id部ID 任意 出発地ゾーンを識別します。運賃クラスに複数の出発地ゾーンがある場合は、fare_rules.txt に各origin_idのレコードを作成します。
例: 運賃クラスbがゾーン2またはゾーン8から出発するすべての旅行に有効な場合、fare_rules.txt ファイルには運賃クラスに関する次のレコードが含まれます。
運賃ID,...,原産地ID
b,...,2
b,...,8
destination_id stops.zone_id部ID 任意 目的地ゾーンを識別します。運賃クラスに複数の目的地ゾーンがある場合は、fare_rules.txt に各destination_idのレコードを作成します。
例: origin_idフィールドとdestination_idフィールドを一緒に使用して、運賃クラスb34 の間の旅行に有効であることを指定できます。ゾーン 3 と 5 の間の旅行の場合、fare_rules.txt ファイルには、運賃クラスに関する次のレコードが含まれます。
運賃ID、...、出発地ID、目的地ID
b,...,3,4
b,...,3,5
contains_id stops.zone_id部ID 任意 特定の運賃クラスを使用しているときに乗客が進入するゾーンを識別します。一部のシステムで正しい運賃クラスを計算するために使用されます。
例: 運賃クラスc5、6、7を通過する GRT ルートのすべての旅行に関連付けられている場合、fare_rules.txt には次のレコードが含まれます。
fare_id, route_id,...,contains_id
c,GRT,...,5
c,GRT,...,6
c,GRT,...,7
運賃を適用するには、すべてのcontains_idゾーンが一致している必要があるため、ゾーン56は通過するがゾーン7は通過しない旅程には運賃クラスcはありません。詳細については、GoogleTransitDataFeed プロジェクトwikiの https://code.google.com/p/googletransitdatafeed/wiki/FareExamplesをご覧ください。

timeframes.txt

ファイル: 任意

主キー(*)

時間帯、曜日、または特定の日に基づいて変動する運賃を記述するために使用されます。タイムフレームは、fare_leg_rules.txt で運賃商品に関連付けることができます。
同じtimeframe_group_id値とservice_id値に重複する時間間隔があってはなりません。

フィールド名 タイプ 存在 説明
timeframe_group_id ID 必須 時間枠または時間枠のセットを識別します。
start_time 時間 条件付きで必須 時間枠の開始を定義します。間隔には開始時刻が含まれます。
24:00:00 より大きい値は禁止されています。start_time の値が空のstart_time00:00:00 とみなされます。

条件付きで必須:
- ** timeframes.end_timeが定義されている場合は必須。
- それ以外の場合は禁止
end_time 時間 条件付きで必須 時間枠の終了を定義します。間隔には終了時刻は含まれません。
24:00:00 より大きい値は禁止されています。end_time の値が空のend_time24:00:00 とみなされます。

条件付きで必須:
- ** timeframes.start_timeが定義されている場合は必須。
- それ以外の場合は禁止
service_id calendar.service_idまたはcalendar_dates.service_id部ID 必須 タイムフレームが有効な日付のセットを識別します。

タイムフレームのローカル時間セマンティクス

  • 運賃イベントの時間を timeframes.txt に対して評価する場合、イベント時間は、運賃イベントの停車駅または親駅のstop_timezone(指定されている場合) によって決定されるローカル タイムゾーンを使用してローカル時間で計算されます。指定されていない場合は、フィードの代理店のタイムゾーンを代わりに使用する必要があります。
  • 現在の日は、ローカル タイムゾーンを基準に計算された運賃イベントの時間の現在のdateです。 当日は、特に深夜を過ぎる旅行の場合、運賃区間の旅行のサービス日とは異なる場合があります。
  • 運賃イベントの時刻は、GTFS 時間フィールドタイプのセマンティクスを使用して、当日を基準として計算されます。

fare_media.txt

ファイル: 任意

主キー(fare_media_id)

運賃商品の使用に使用できるさまざまな運賃メディアを説明します。運賃メディアは、運賃商品の表示や検証に使用される物理的または仮想的なホルダーです。

フィールド名 タイプ 存在 説明
fare_media_id ユニークID 必須 運賃メディアを識別します。
fare_media_name Text 任意 運賃メディアの名前。

交通カード (fare_media_type =2) またはモバイル アプリ (fare_media_type =4) などの運賃メディアの場合、fare_media_nameを含める必要があり、それを配信する組織が使用する乗客向けの名前と一致する必要があります。
fare_media_type Enum 必須 運賃メディアのタイプ。有効なオプションは次のとおりです。

0 - なし。物理的なチケットが提供されずに運転手または車掌に現金で支払うなど、運賃商品の購入または検証に運賃媒体が関与しない場合に使用されます。
1 - 乗客が一定期間内に、事前に購入した一定数の旅行、または無制限の旅行のいずれかを利用できる物理的な紙のチケット。
2 - チケット、パス、または金銭的価値が保存されている物理的な交通カード。
3 - アカウントベースのチケット発行用のオープンループ トークン コンテナとしての cEMV (非接触型 Europay、Mastercard、Visa)。
4 - 仮想交通カード、チケット、パス、または金銭的価値を保存したモバイル アプリ。

fare_products.txt

ファイル: 任意

主キー(fare_product_idfare_media_id)

乗客が購入可能な運賃の範囲を記述したり、乗り換えコストなど、複数の区間を含む旅程の合計運賃を計算するときに考慮したりするために使用されます。

フィールド名 タイプ 存在 説明
fare_product_id ID 必須 運賃商品または運賃商品のセットを識別します。

fare_products.txt 内の複数のレコードが同じfare_product_idを共有する場合があります。その場合、別のファイルから参照されたときに、そのIDを持つすべてのレコードが取得されます。

複数のレコードが同じfare_product_idを共有していても、異なるfare_media_idを持つ場合があります。これは、運賃商品を使用するために利用できるさまざまな方法 (潜在的に異なる価格) を示します。
fare_product_name Text 任意 乗客に表示される運賃商品の名前。
fare_media_id fare_media.fare_media_id部ID 任意 旅行中に運賃商品を使用するために使用できる運賃メディアを識別します。fare_media_id が空の場合、運賃メディアは不明であると見なされます。
amount 通貨金額 必須 運賃商品のコスト。乗り継ぎ割引を表す場合は負の値になる場合があります。無料の運賃商品を表す場合はゼロになる場合があります。
currency 通貨コード 必須 運賃商品のコストの通貨。

fare_leg_rules.txt

ファイル: 任意

主キー(network_id, from_area_id, to_area_id, from_timeframe_group_id, to_timeframe_group_id, fare_product_id)

旅行の各区間の運賃規則。

fare_leg_rules.txt の運賃は、乗客が移動する区間に一致する規則を見つけるために、ファイル内のすべてのレコードをフィルタリングして照会する必要があります。

区間のコストを処理するには:

  1. ファイル fare_leg_rules.txt は、旅行の特性を定義するフィールドでフィルタリングする必要があります。これらのフィールドは次のとおりです:
    • fare_leg_rules.network_id
    • fare_leg_rules.from_area_id
    • fare_leg_rules.to_area_id
    • fare_leg_rules.from_timeframe_group_id
    • fare_leg_rules.to_timeframe_group_id
  2. 旅行の特性に基づいて、区間が fare_leg_rules.txt のレコードと完全に一致する場合、そのレコードを処理して区間のコストを決定する必要があります。このファイルは、空のエントリを 2つの方法で処理します: 空のセマンティクスまたはルールの優先順位。
  3. 完全一致が見つからず、rule_priority フィールドが存在しない場合は、fare_leg_rules.network_idfare_leg_rules.from_area_id、およびfare_leg_rules.to_area_idの空のエントリをチェックして、区間のコストを処理する必要があります。
    • fare_leg_rules.network_idの空のエントリは、routes.txt または networks.txt で定義されているすべてのネットワークに対応しますが、fare_leg_rules.network_idの下にリストされているネットワークは除きます。
    • fare_leg_rules.from_area_idの空のエントリは、areas.area_idで定義されているすべてのエリアに対応しますが、fare_leg_rules.from_area_idの下にリストされているエリアは除きます。
    • 空のfare_leg_rules.to_area_idのエントリは、fare_leg_rules.to_area_idの下にリストされているものを除いて、areas.area_idで定義されているすべてのエリアに対応します
  4. rule_priority フィールドが存在する場合、
    • fare_leg_rules.network_idのエントリが空の場合、区間のネットワークはこのルールのマッチングには影響しません。
    • fare_leg_rules.from_area_idのエントリが空の場合、区間の出発エリアはこのルールのマッチングには影響しません。
    • fare_leg_rules.to_area_idのエントリが空の場合、区間の到着エリアはこのルールのマッチングには影響しません。
  5. 区間が上記の規則のいずれにも一致しない場合は、運賃は不明です。
フィールド名 タイプ 存在 説明
leg_group_id ID 任意 fare_leg_rules.txt 内のエントリのグループを識別します。

fare_transfer_rules.from_leg_group_idfare_transfer_rules.to_leg_group_id間の運賃振替ルールを記述するために使用されます。

fare_leg_rules.txt 内の複数のエントリが同じfare_leg_rules.leg_group_idに属している場合があります。

fare_leg_rules.txt 内の同じエントリ (fare_leg_rules.leg_group_idは含まない) は、複数のfare_leg_rules.leg_group_idに属してはなりません。
network_id routes.network_idまたはnetworks.network_id部ID 任意 運賃区間ルールに適用されるルート ネットワークを識別します。

rule_priority フィールドが存在せず、フィルタリングされているnetwork_idに一致するfare_leg_rules.network_id値がない場合、デフォルトで空のfare_leg_rules.network_idが一致します。

fare_leg_rules.network_idの空のエントリは、routes.txt または networks.txt で定義されているすべてのネットワークに対応しますが、fare_leg_rules.network_idの下にリストされているネットワークは除きます。

ファイルに rule_priority フィールドが存在する場合、空のfare_leg_rules.network_idは、区間のルート ネットワークがこのルールのマッチングに影響しないことを示します。
from_area_id areas.area_id部ID 任意 出発エリアを識別します。

rule_priority フィールドが存在せず、フィルタリングされているarea_idに一致するfare_leg_rules.from_area_id値がない場合、デフォルトで空のfare_leg_rules.from_area_idが一致します。

fare_leg_rules.from_area_idの空のエントリは、fare_leg_rules.from_area_idの下にリストされているものを除く、areas.area_idで定義されているすべてのエリアに対応します。

ファイルに rule_priority フィールドが存在する場合、空のfare_leg_rules.from_area_idは、区間の出発エリアがこのルールのマッチングに影響しないことを示します。
to_area_id areas.area_id部ID 任意 到着エリアを識別します。

rule_priority フィールドが存在せず、フィルタリングされているarea_idに一致するfare_leg_rules.to_area_id値がない場合、デフォルトで空のfare_leg_rules.to_area_idが一致します。

fare_leg_rules.to_area_idの空のエントリは、fare_leg_rules.to_area_idの下にリストされているものを除く、areas.area_idで定義されているすべてのエリアに対応します。

ファイルに rule_priority フィールドが存在する場合、空のfare_leg_rules.to_area_idは、区間の到着エリアがこのルールのマッチングに影響しないことを示します。
from_timeframe_group_id timeframes.timeframe_group_id部ID 任意 運賃区間の開始時に運賃検証イベントのタイムフレームを定義します。

運賃区間の開始時間は、イベントの発生が予定されている時間です。たとえば、乗客が乗車して運賃を確認する運賃区間の開始時のバスの予定出発時刻がその時間になります。以下のルール マッチング セマンティクスでは、開始時間は timeframes.txtローカル時間セマンティクス によって決定されるローカル時間で計算されます。運賃区間の出発イベントの停留所または駅は、必要に応じてタイムゾーン解決に使用する必要があります。

from_timeframe_group_idを指定する運賃区間ルールの場合、timeframes.txt に以下の条件がすべて満たされるレコードが少なくとも 1つ存在する場合、そのルールは特定の区間と一致します。
- timeframe_group_idの値はfrom_timeframe_group_idの値と同じです。
- レコードのservice_idによって識別される日のセットには、運賃区間の開始時刻の現在の日が含まれます。
- 運賃区間の開始時間の時刻は、レコードのtimeframes.start_time値以上であり、timeframes.end_time値未満です。

空のfare_leg_rules.from_timeframe_group_idは、区間の開始時刻がこのルールの一致に影響しないことを示します。
to_timeframe_group_id timeframes.timeframe_group_id部ID 任意 運賃区間の終了時の運賃検証イベントの期間を定義します。

運賃区間の終了時間は、イベントの発生が予定されている時間です。たとえば、乗客が降りて運賃を確認する運賃区間の終了時にバスが到着する予定の時刻が、その時間になります。以下のルール マッチング セマンティクスでは、終了時間は timeframes.txtローカル時間セマンティクス によって決定されるローカル時間で計算されます。運賃区間の到着イベントの停留所または駅は、必要に応じてタイムゾーン解決に使用する必要があります。

to_timeframe_group_idを指定する運賃区間ルールの場合、timeframes.txt に以下の条件がすべて満たされるレコードが少なくとも 1つ存在する場合、そのルールは特定の区間と一致します。
- timeframe_group_idの値はto_timeframe_group_idの値と同じです。
- レコードのservice_idによって識別される日のセットには、運賃区間の終了時刻の現在の日が含まれます。
- 運賃区間の終了時間の時刻は、レコードのtimeframes.start_time値以上であり、timeframes.end_time値未満です。

空のfare_leg_rules.to_timeframe_group_idは、区間の終了時刻がこのルールの一致に影響しないことを示します。
fare_product_id fare_products.fare_product_id部ID 必須 区間を旅行するために必要な運賃商品。
rule_priority 負でない整数 任意 一致ルールが区間に適用される優先順位を定義し、特定のルールが他のルールよりも優先されるようにします。 fare_leg_rules.txt内の複数のエントリが一致する場合、rule_priority の値が最も高いルールまたはルール セットが選択されます。

rule_priority の値が空の場合、ゼロとして扱われます。

fare_transfer_rules.txt

ファイル: 任意

主キー(from_leg_group_id, to_leg_group_id, fare_product_id, transfer_count, duration_limit)

fare_leg_rules.txt で定義された旅行区間間の乗り換えの運賃規則。

複数区間の旅程の費用を処理するには:

  1. fare_leg_rules.txtで定義された適用可能な運賃区間グループは、乗客の旅程に基づいて、すべての個々の旅行区間に対して決定する必要があります2.ファイル fare_transfer_rules.txt は、乗り換えの特性を定義するフィールドでフィルタリングする必要があります。これらのフィールドは次のとおりです:
    • fare_transfer_rules.from_leg_group_id
    • fare_transfer_rules.to_leg_group_id
  2. 乗り換えの特性に基づいて、乗り換えが fare_transfer_rules.txt のレコードと完全に一致する場合、そのレコードを処理して乗り換えコストを決定する必要があります。
  3. 完全に一致するものが見つからない場合は、乗り換えコストを処理するために、from_leg_group_idまたはto_leg_group_idの空のエントリを確認する必要があります。
    • fare_transfer_rules.from_leg_group_idの空のエントリは、fare_leg_rules.leg_group_idで定義されているすべての区間グループに対応しますが、fare_transfer_rules.from_leg_group_idにリストされているものを除きます。
    • fare_transfer_rules.to_leg_group_idの空のエントリは、fare_leg_rules.leg_group_id で定義されているすべての区間グループに対応しますが、fare_leg_rules.leg_group_idにリストされているものを除きます。 fare_transfer_rules.to_leg_group_id
  4. 移籍が上記のいずれの規則にも該当しない場合は、移籍の取り決めはなく、各レグは別個のものとみなされます。


フィールド名 タイプ 存在 説明
from_leg_group_id fare_leg_rules.leg_group_id部ID 任意 転送前の運賃区間ルールのグループを識別します。

フィルタリングされているleg_group_idに一致するfare_transfer_rules.from_leg_group_id値がない場合、デフォルトで空のfare_transfer_rules.from_leg_group_idが一致します。

fare_transfer_rules.from_leg_group_idの空のエントリは、fare_leg_rules.leg_group_idにリストされているものを除く、fare_transfer_rules.from_leg_group_idで定義されているすべての区間グループに対応します
to_leg_group_id fare_leg_rules.leg_group_id部ID 任意 転送後の運賃区間ルールのグループを識別します。

フィルタリングされているleg_group_idに一致するfare_transfer_rules.to_leg_group_id値がない場合、デフォルトで空のfare_transfer_rules.to_leg_group_idが一致します。

fare_transfer_rules.to_leg_group_idの空のエントリは、fare_transfer_rules.to_leg_group_id にリストされているものを除く、fare_transfer_rules.to_leg_group_idで定義されているすべての区間グループに対応します
transfer_count ゼロ以外の整数 条件付きで禁止 乗り換えルールを適用できる連続乗り換えの数を定義します。

有効なオプションは次のとおりです。
-1 - 制限なし。
1以上 - 転送ルールが適用される転送の数を定義します。

サブジャーニーが異なるtransfer_countを持つ複数のレコードと一致する場合、サブジャーニーの現在の転送カウント以上の最小transfer_countを持つルールが選択されます。

条件付きで禁止:
- fare_transfer_rules.from_leg_group_idfare_transfer_rules.to_leg_group_idと等しくない場合は禁止です。
- 必須 fare_transfer_rules.from_leg_group_idfare_transfer_rules.to_leg_group_idと等しい場合。
duration_limit 正の整数 任意 乗り換えの期間制限を定義します。

秒単位の整数増分で表現するしなければならない。

期間制限がない場合は、fare_transfer_rules.duration_limitは空にする必要があります。
duration_limit_type 列挙型 条件付きで必須 fare_transfer_rules.duration_limitの相対的な開始と終了を定義します。

有効なオプションは次のとおりです。
0 - 現在の区間の出発運賃の検証と次の区間の到着運賃の検証の間。
1 - 現在の区間の出発運賃の検証と次の区間の出発運賃の検証の間。
2 - 現在の区間の到着運賃の検証と次の区間の出発運賃の検証の間。
3 - 現在の区間の到着運賃の検証と次の区間の到着運賃の検証の間。

条件付きで必須:
- ** fare_transfer_rules.duration_limitが定義されている場合は必須。
- fare_transfer_rules.duration_limitが空の場合は禁止です。
fare_transfer_type 列挙型 必須 旅程中の区間間の乗り換えのコスト処理方法を示します。

有効なオプションは次のとおりです。
0 - 出発区間fare_leg_rules.fare_product_idfare_transfer_rules.fare_product_idを加算したもの。A + AB。
1 - 出発区間のfare_leg_rules.fare_product_idfare_transfer_rules.fare_product_idと到着区間のfare_leg_rules.fare_product_idを加算します。A + AB + B。
2 - fare_transfer_rules.fare_product_id; AB.

旅程中の複数の転送間のコスト処理のやり取り:

fare_transfer_type処理A > B処理B > C
0 A + A +B プラスS + BC
1 A + AB + B S + BC + C
2 AB S + BC
ここで、S は、前の区間と乗り換えの合計処理コストを示します。
fare_product_id fare_products.fare_product_id部ID 任意 2つの運賃区間間の乗り換えに必要な運賃商品。空の場合、乗り換えルールのコストは 0 です。

areas.txt

ファイル: 任意

主キー(area_id)

エリア識別子を定義します。

フィールド名 タイプ 存在 説明
area_id ユニークID 必須 エリアを識別します。areas.txt 内で一意であるしなければならない。
area_name Text 任意 乗客に表示されるエリアの名前。

stop_areas.txt

ファイル: 任意

主キー(*)

stops.txt からエリアに停留所を割り当てます。

フィールド名 タイプ 存在 説明
area_id areas.area_id部ID 必須 1つまたは複数のstop_idが属するエリアを識別します。同じstop_id が複数のarea_idで定義される場合があります。
stop_id stops.stop_id部ID 必須 停留所を識別します。このフィールドで駅(つまり、stops.location_type=1の停留所)が定義されている場合、そのすべてのプラットフォーム(つまり、この駅が stops.parent_station stops.location_type=0のすべての停留所)は同じエリアの一部であると見なされます。この動作は、プラットフォームを他のエリアに割り当てることで上書きできます。

networks.txt

ファイル: 条件付きで禁止

主キー(network_id)

運賃区間ルールに適用されるネットワーク識別子を定義します。

フィールド名 タイプ 存在 説明
network_id ユニークID 必須 ネットワークを識別します。networks.txt 内で一意であるしなければならない。
network_name Text 任意 運賃区間の規則に適用されるネットワークの名前。これは、地方機関とその乗客によって使用されます。

route_networks.txt

ファイル: 条件付きで禁止

主キー(route_id)

routes.txt からのルートをネットワークに割り当てます。

フィールド名 タイプ 存在 説明
network_id networks.network_id部ID 必須 1つまたは複数のroute_idが属するネットワークを識別します。route_id は、1つのnetwork_idでのみ定義できます。
route_id routes.route_id部ID 必須 ルートを識別します。

shapes.txt

ファイル: 任意

主キー(shape_idshape_pt_sequence)

ルート形状は、車両がルート線形に沿って移動するパスを説明し、ファイルshapes.txtで定義されます。ルート形状は便に関連付けられ、車両が順番に通過する一連のポイントで構成されます。ルート形状は停留所等の位置を正確にインターセプトする必要はありませんが、トリップのすべての停留所等は、そのトリップのシェイプからわずかな距離内、つまりシェイプポイントを接続する直線セグメントの近くに配置する必要があります。 shapes.txtファイルは、すべてのルートベースのサービス (ゾーンベースのデマンドレスポンシブサービスではありません) に含める必要があります。

フィールド名 タイプ 存在 説明
shape_id ID 必須 シェイプを識別します。
shape_pt_lat 緯度 必須 シェイプ ポイントの緯度。shapes.txt 内の各レコードは、シェイプを定義するために使用されるシェイプ ポイントを表します。
shape_pt_lon 経度 必須 シェイプ ポイントの経度。
shape_pt_sequence 負でない整数 必須 シェイプ ポイントが接続してシェイプを形成するシーケンス。値は移動に沿って増加する必要がありますが、連続している必要はありません。
例: 図形A_shp3つの点がある場合、shapes.txt ファイルには図形を定義する次のレコードが含まれる可能性があります。
shape_id、shape_pt_latshape_pt_lonshape_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 非負のfloat 任意 最初のシェイプ ポイントからこのレコードで指定されたポイントまでのシェイプに沿った実際の移動距離。旅行計画者がマップ上にシェイプの正しい部分を表示するために使用します。値はshape_pt_sequenceとともに増加する必要があります。ルートに沿った逆方向の移動を示すために使用してはなりません。距離の単位は stop_times.txtで使用されている単位と一致している必要があります。

ループまたはインライン (車両が1回の移動で同じ線形部分を横断または移動する) があるルートに推奨。

車両が後退したり、旅行の途中でルートの線形を横切るポイントがある場合、shape_dist_traveled は、shapes.txt 内のポイントの並び方が stop_times.txt 内のレコードとどのように対応しているかを明確にするために重要です。
例: バスが上記でA_shpに定義された3つのポイントに沿って移動する場合、追加のshape_dist_traveled値 (ここではキロメートル単位で表示) は次のようになります。
shape_idshape_pt_latshape_pt_lonshape_pt_sequenceshape_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

ファイル: 任意

主キー(trip_idstart_time)

Frequencies.txtは、一定のヘッドウェイ (旅行間の時間) で動作する旅行を表します。このファイルは、2つの異なるタイプのサービスを表すために使用できます。

  • 頻度ベースのサービス (exact_times=0)。このサービスでは、サービスは 1 日を通して固定のスケジュールに従いません。代わりに、オペレーターは旅行に対して事前に決定されたヘッドウェイを厳密に維持しようとします。
  • スケジュール ベースのサービス (exact_times=1) の圧縮表現。指定された期間の旅行に対してまったく同じヘッドウェイを持ちます。スケジュール ベースのサービスでは、オペレーターはスケジュールに厳密に従おうとします。
フィールド名 タイプ 存在 説明
trip_id trips.trip_id部ID 必須 指定されたサービス間隔が適用される旅行を識別します。
start_time 時間 必須 最初の車両が指定された間隔で旅行の最初の停車地から出発する時刻。
end_time 時間 必須 旅行の最初の停車地でサービスが別の間隔に変更される (または停止する) 時刻。
headway_secs 正の整数 必須 start_timeend_timeで指定された時間間隔中に、旅行の同じ停車地 (間隔) から出発する間隔 (秒単位)。同じ旅行に複数の間隔を定義できますが、重複することはできません。新しい運行間隔は、前の運行間隔が終了した正確な時間に開始される場合があります。
exact_times 列挙型 任意 旅行のサービスの種類を示します。詳細については、ファイルの説明を参照してください。有効なオプションは次のとおりです。

0 または空 - 頻度ベースの旅行。
1 - 一日を通してまったく同じヘッドウェイのスケジュールベースの旅行。この場合、end_time値は、最後の希望旅行start_timeより大きく、最後の希望旅行 start_time + headway_secsより小さくする必要があります。

transfers.txt

ファイル: 任意

主キー(from_stop_idto_stop_idfrom_trip_idto_trip_idfrom_route_idto_route_id)

旅程を計算する際、GTFS を使用するアプリケーションは、許容される時間と停留所の近接性に基づいて乗り換えを補間します。 Transfers.txt は、選択した乗り換えに対する追加のルールとオーバーライドを指定します。

from_trip_idto_trip_idfrom_route_id、およびto_route_idを使用すると、乗り換えルールの詳細度をさらに高めることができます。from_stop_idto_stop_idに加えて、詳細度の順位付けは次のようになります:

  1. 両方のtrip_idが定義されています: from_trip_idto_trip_id
  2. 1つのtrip_idroute_idセットが定義されています: (from_trip_idto_route_id) または (from_route_idto_trip_id) 。
  3. 1つのtrip_idが定義されています: from_trip_idまたはto_trip_id
  4. 両方のroute_idが定義されています: from_route_idto_route_id
  5. 1つのroute_idが定義されています: from_route_idまたはto_route_id
  6. from_stop_idおよびto_stop_idが定義されています: ルートまたは旅行関連のフィールドは設定されていません。

到着旅行と出発旅行の順序付けられたペアが指定されている場合、これら 2つの旅行間に適用される最も詳細度の高い乗り換えが選択されます。どの旅行のペアにも、適用可能な最大詳細度が同等の 2つの乗り換えが存在することはできません。

フィールド名 タイプ 存在 説明
from_stop_id stops.stop_id部ID 条件付きで必須 ルート間の接続が開始される停留所または駅を識別します。このフィールドが駅を参照する場合、乗り換えルールはそのすべての子停留所に適用されます。transfer_types 4および5.では駅の参照は禁止されています。
to_stop_id stops.stop_id部ID 条件付きで必須 ルート間の接続が終了する停留所または駅を識別します。このフィールドが駅を参照する場合、転送ルールはすべての子停留所に適用されます。transfer_types 4および5.では、駅の参照は禁止されています。
from_route_id routes.route_id部ID 任意 接続が始まるルートを識別します。

from_route_idが定義されている場合、乗り換えは指定されたfrom_stop_idのルート上の到着旅行に適用されます。

from_trip_idfrom_route_id の両方が定義されている場合、trip_idroute_idに属している必要があり、from_trip_idが優先されます。
to_route_id routes.route_id部ID 任意 接続が終了するルートを識別します。

to_route_idが定義されている場合、乗り換えは指定されたto_stop_idのルートの出発便に適用されます。

to_trip_idto_route_idの両方が定義されている場合、trip_idroute_idに属している必要があり、to_trip_idが優先されます。
from_trip_id trips.trip_id部ID 条件付きで必須 ルート間の接続が始まる旅行を識別します。

from_trip_idが定義されている場合、乗り換えは指定されたfrom_stop_idの到着旅行に適用されます。

from_trip_idfrom_route_idの両方が定義されている場合、trip_idroute_idに属している必要があり、from_trip_idが優先されます。 transfer_type4 または 5 の場合は必須。
to_trip_id trips.trip_id部ID 条件付きで必須 ルート間の接続が終了する旅行を識別します。

to_trip_idが定義されている場合、乗り換えは指定されたto_stop_idの出発旅行に適用されます。

to_trip_idto_route_idの両方が定義されている場合、trip_idroute_idに属している必要があり、to_trip_idが優先されます。 transfer_type4 または 5 の場合は必須。
transfer_type Enum 必須 指定された (from_stop_idto_stop_id) ペアの接続タイプを示します。有効なオプションは次のとおりです。

0 または空 - ルート間の推奨乗り換えポイント。
1 - 2つのルート間の時間指定の乗り換えポイント。出発車両は到着車両を待機し、乗客がルート間を乗り換えるのに十分な時間を残すことが求められます。
2 - 乗り継ぎを確実に行うには、到着から出発までの間に最低限の時間が必要です。乗り継ぎに必要な時間はmin_transfer_timeで指定します。
3 - その場所ではルート間の乗り換えはできません。
4 - 乗客は同じ車両に乗車したまま、ある旅行から別の旅行へ乗り換えることができます (座席内乗り換え)。このタイプの乗り換えの詳細については、以下 を参照してください。
5 - 連続する旅行間での座席内乗り換えは許可されません。乗客は車両から降りて再び乗車する必要があります。このタイプの乗り換えの詳細については、下記を参照してください。
min_transfer_time 負でない整数 任意 指定された停留所でルート間の乗り換えを許可するために必要な時間 (秒単位)。min_transfer_time は、各ルートのスケジュール変更に対応するためのバッファ時間を含め、一般的な乗客が 2つの停留所間を移動するのに十分な時間である必要があります。

リンクmin_transfer_timeれた旅行

以下は、座席内乗り換えの有無にかかわらず、旅行をリンクするために使用される transfer_type=4 および =5 に適用されます。

リンクされた旅行は、同じ車両で運行されるしなければならない。車両は、他の車両と連結することも、連結を解除することもしてもよい。

リンクされたトリップ転送と block_id の両方が提供され、矛盾する結果が生成される場合は、リンクされたトリップ転送を使用する必要があります。

from_trip_id の最後の停車地は、from_trip_id to_trip_idの最初の停車地に地理的に近いするべきであるがあり、from_trip_idの最後の到着時刻は、to_trip_idの最初の出発時刻より前であるが近いするべきである。to_trip_id トリップが次の運行日に発生する場合、from_trip_idの最後の到着時刻は、to_trip_id to_trip_idの最初の出発時刻より遅くてもかまいしてもよい。

通常の場合、便は1 対 1 でリンクできしてもよいが、より複雑なトリップの継続を表すために、1 対 n、n 対 1、または n 対 n でリンクすることもしてもよい。たとえば、2つの列車の旅程 (下の図の旅程 A と旅程 B) は、共通の駅で車両連結操作を行った後、1つの列車の旅程 (旅程 C) に統合できます。

  • 1対nの継続では、各to_trip_idtrips.service_idは同一であるしなければならないがあります。
  • n対1の継続では、各from_trip_idtrips.service_idは同一であるしなければならない。
  • n対nの継続では、両方の制約を尊重する必要があります。
  • trip.service_idがどのサービス日でも重複してはしてはいけないという条件で、便は複数の異なる継続の一部としてリンクできます。
 
旅行A
───────────────────\
                    \    旅行C
                     ──────────────
旅行B                /
───────────────────/

pathways.txt

ファイル: 任意

主キー(pathway_id)

ファイル pathways.txtlevels.txt は、グラフ表現を使用して地下鉄や電車の駅を記述します。グラフ表現では、ノードが場所を、エッジが経路を表します。

駅の出入口 (場所としてlocation_type=2で表されるノード) からプラットフォーム (場所としてlocation_type=0または空で表されるノード) に移動するには、通路、改札口、階段、および経路として表されるその他のエッジを通過します。汎用ノード (場所としてlocation_type=3で表されるノード) は、駅全体の経路を接続するために使用できます。

構内通路は、駅内で網羅的に定義する必要があります。経路が定義されている場合は、駅全体のすべての経路が表されているものとみなされます。したがって、次のガイドラインが適用されます:

  • ぶら下がっている場所はありません: 駅内のいずれかの場所に経路がある場合は、その駅内のすべての場所に経路が必要です。ただし、乗車エリア (location_type=4、以下のガイドラインを参照) があるプラットフォームは除きます。
  • 乗車エリアのあるプラットフォームには経路はありません: 乗車エリア (location_type=location_type=4) があるプラットフォーム (location_type=0`または空) は、ポイントではなく親オブジェクトとして扱われます。このような場合、プラットフォームに経路を割り当ててはなりません。すべての経路は、プラットフォームの各乗車エリアに割り当てる必要があります。
  • ロックされたプラットフォームはありません: 各プラットフォーム (location_type=0または空) または乗車エリア (location_type=4) は、経路のチェーンを介して少なくとも 1つの入口/出口 (location_type=2) に接続されている必要があります。特定のプラットフォームから駅の外への経路を許可しない駅はまれです。
フィールド名 タイプ 存在 説明
pathway_id ユニークID 必須 経路を識別します。システムによってレコードの内部識別子として使用されます。データセット内で一意であるしなければならない。

異なる経路では、from_stop_idto_stop_idの値が同一になる場合があります。
例: 2つのエスカレーターが反対方向に並んでいる場合、または階段セットとエレベーターが同じ場所から同じ場所に行く場合、異なるpathway_id が同じfrom_stop_idおよびto_stop_id値を持つことがあります。
from_stop_id stops.stop_id部ID 必須 経路が始まる場所。

プラットフォーム (location_type=0または空)、入口/出口 (location_type=2)、汎用ノード (location_type=3)、または乗車エリア (location_type=4) を識別するstop_idを含めるしなければならない。

駅を識別するstop_idの値 (location_type=1) は禁止されています。
to_stop_id stops.stop_id部ID 必須 経路が終了する場所。

プラットフォーム (location_type=0または空)、入口/出口 (location_type=2)、汎用ノード (location_type=3)、または乗車エリア (location_type=4) を識別するstop_idを含めるしなければならない。

駅を識別するstop_idの値 (location_type=1) は禁止されています。
pathway_mode 列挙型 必須 指定された (from_stop_idto_stop_id) ペア間の経路のタイプ。有効なオプションは次のとおりです。

1 - 歩道。
2 - 階段。
3 - 動く歩道/動く歩道。
4 - エスカレーター。
5 - エレベーター。
6 - 改札口 (または支払いゲート): 駅のエリアに渡る通路で、通過するには支払いの証明が必要です。改札口は、駅の有料エリアと無料エリアを分けたり、同じ駅内の異なる支払いエリアを互いに分けたりします。この情報を使用すると、乗客に不要な支払いを要求する近道を使って駅を経由するルートを回避できます。たとえば、バス専用通路に到達するために地下鉄のプラットフォームを歩くように乗客を誘導するなどです。
7- 出口ゲート: 有料エリアから、支払い証明がなくても通過できる無料エリアへの通路。
is_bidirectional 列挙型 必須 通路の方向を示します。

0 - from_stop_idからto_stop_idまでのみ使用できる一方向の経路。
1 - 両方向に使用できる双方向経路。

出口ゲート (pathway_mode=7) は双方向にすることはできません。
length 非負のfloat数 任意 出発地 (from_stop_idで定義) から目的地 (to_stop_idで定義) までの経路の水平方向の長さ (メートル単位)。

このフィールドは、歩道 (pathway_mode=1)、改札口 (pathway_mode=6)、出口ゲート (pathway_mode=7) に推奨されます。
traversal_time 正の整数 任意 出発地 (from_stop_idで定義) から目的地 (to_stop_idで定義) までの経路を歩くのに必要な平均時間 (秒単位)。

このフィールドは、動く歩道 (pathway_mode=3)、エスカレーター (pathway_mode=4)、エレベーター (pathway_mode=5) に推奨されます。
stair_count null 以外の整数 任意 通路の階段の数。

stair_countが正の場合、乗客はfrom_stop_idからto_stop_idまで歩いて上がることを意味します。また、stair_countが負の場合、乗客はfrom_stop_idからto_stop_idまで歩いて下がることを意味します。

このフィールドは階段 (pathway_mode=2) に推奨されます。

推定階段数しか提供できない場合は、1 フロアあたり 15 段と見積もることをお勧めします。
max_slope Float 任意 通路の最大傾斜率。有効なオプションは次のとおりです。

0または空 - 傾斜なし。
Float - 経路の傾斜比。上向きの場合は正、下向きの場合は負。

このフィールドは、歩道 (pathway_mode=1) および動く歩道 (pathway_mode=3) でのみ使用してください。
例: 米国では、手動車椅子の最大傾斜率は 0.083 (8.3% とも表記) で、1 メートルごとに 0.083 メートル (つまり 8.3 cm) 増加することを意味します。
min_width 正のfloat 任意 通路の最小幅 (メートル単位)。

最小幅が 1 メートル未満の場合は、このフィールドが推奨されます。
signposted_as Text 任意 乗客に見える物理的な標識からの一般向けのテキスト。

「標識に従ってください」など、乗客にテキストにsingposted_as指示を提供するために使用できます。singposted_as 内のテキストは、標識に印刷されているとおりに表示されます。

物理的な標識が多言語の場合、このフィールドは、feed_info.feed_langのフィールド定義のstops.stop_nameの例に従って入力および翻訳できます。
reversed_signposted_as Text 任意 signposted_asと同じですが、経路がto_stop_idからfrom_stop_idに使用される場合です。

levels.txt

ファイル: 条件付きで必須

主キー(level_id)

駅の階を説明します。pathways.txt と併用すると便利です。

フィールド名 タイプ 存在 説明
level_id ユニークID 必須 駅の階を識別します。
level_index Float 必須 相対的な位置を示すレベルの数値インデックス。

地上レベルのインデックスは 0 で、地上レベルは正のインデックスで示され、地下レベルは負のインデックスで示されます。
level_name Text 任意 建物または駅内の乗客から見たレベルの名前。
例: エレベーターで「中二階」または「プラットフォーム」または「-1」まで行きます。

location_groups.txt

ファイル: 任意

主キー(location_group_id)

乗客が乗車または降車をリクエストできる停留所のグループである場所グループを定義します。

フィールド名 タイプ 存在 説明
location_group_id ユニークID 必須 場所グループを識別します。IDは、すべてのstops.stop_id、locations.geojson id、およびlocation_groups.location_group_id値で一意である必要があります。

ロケーション グループとは、乗客が乗車または降車をリクエストできるロケーションを示す停留所のグループです。
location_group_name Text 任意 乗客に表示されるロケーション グループの名前。

location_group_stops.txt

ファイル: 任意

主キー(*)

stops.txt のstops.txtをロケーション グループに割り当てます。

フィールド名 タイプ 存在 説明
location_group_id location_groups.location_group_id部ID 必須 1つまたは複数のstop_idグループを識別します。同じstop_idが複数のlocation_group_id`で定義される場合があります。
stop_id stops.stop_id部ID 必須 場所グループに属する停留所を識別します。

locations.geojson

ファイル: 任意

乗客がオンデマンド サービスによる乗車または降車をリクエストできるゾーンを定義します。これらのゾーンは、GeoJSON ポリゴンとして表されます。

  • このファイルは、RFC 7946で説明されている GeoJSON 形式のサブセットを使用します。
  • locations.geojsonファイルには、FeatureCollectionが含まれている必要があります。
  • FeatureCollectionは、乗客が乗車または降車をリクエストできるさまざまな停留所の場所を定義します。
  • すべての GeoJSON Featureにはid が必要です。 id は、すべてのstops.stop_id、locations.geojson id、およびlocation_group_id値で一意である必要があります。
  • すべての GeoJSON Featureには、次の表に従ってオブジェクトと関連キーが必要です:
フィールド名 タイプ 存在 説明
- type 文字列 必須 場所の "FeatureCollection"
- features 配列 必須 場所を説明する "Feature" オブジェクトのコレクション。
- type 文字列 必須 "Feature"
- id 文字列 必須 場所を識別します。 ID は、すべてのstops.stop_id、locations.geojson id、およびlocation_groups.location_group_id値で一意である必要があります。
- properties オブジェクト 必須 場所のプロパティ キー。
- stop_name 文字列 任意 乗客に表示される場所の名前を示します。
- stop_desc 文字列 任意 乗客の方向を示すための場所のわかりやすい説明。
- geometry オブジェクト 必須 場所のジオメトリ。
- type 文字列 必須 次のタイプであるしなければならない:
- ポリゴン
- "MultiPolygon"
- coordinates 配列 必須 場所のジオメトリを定義する地理座標 (緯度と経度)。

booking_rules.txt

ファイル: 任意

主キー(booking_rule_id)

乗客が要求するサービスの予約ルールを定義します

フィールド名 タイプ 存在 説明
booking_rule_id ユニークID 必須 ルールを識別します。
booking_type 列挙型 必須 どのくらい前に予約できるかを示します。有効なオプションは次のとおりです。

0 - リアルタイム予約。
1 - 事前連絡で当日予約まで。
2 - 最大で前日の予約まで。
prior_notice_duration_min 整数 条件付きで必須 旅行前にリクエストを行う最小時間 (分)。

条件付きで必須:
- ** booking_type=1の場合は必須
-
それ以外の場合は禁止**。
prior_notice_duration_max 整数 条件付きで禁止 旅行前に予約リクエストを行う最大分数。

条件付きで禁止:
- booking_type=0およびbooking_type =2の場合は禁止です。
- booking_type =1 の場合は任意。
prior_notice_last_day 整数 条件付きで必須 予約リクエストを行う旅行前の最終日。

例:「乗車は1日前の午後5時前までに予約する必要があります」はprior_notice_last_day=1 としてエンコードされます。

条件付きで必須:
- ** booking_type=2 の場合は必須 です。
- それ以外の場合は
禁止**。
prior_notice_last_time 時間 条件付きで必須 旅行前最終日に予約リクエストを行う最終時間。

例: 「乗車は1日前の午後5時までに予約する必要があります」は prior_notice_last_time=17:00:00 としてエンコードされます。

条件付きで必須:
- ** prior_notice_last_dayが定義されている場合は必須。
- それ以外の場合は禁止
prior_notice_start_day 整数 条件付きで禁止 予約リクエストを行う旅行前の最も早い日。

例: 「乗車は最短で1週間前の深夜に予約できます」は prior_notice_start_day=7 としてエンコードされます。

条件付きで禁止:
- booking_type =0の場合は禁止です。
- prior_notice_duration_maxが定義されている場合、booking_type=1では禁止です。
- それ以外の場合は任意。
prior_notice_start_time 時間 条件付きで必須 予約リクエストを行う旅行の最も早い日の最初の時間。

例:「乗車は最短で1週間前の深夜に予約できます」は prior_notice_start_time=00:00:00 としてエンコードされます。

条件付きで必須:
- ** prior_notice_start_dayが定義されている場合は必須。
- それ以外の場合は禁止
prior_notice_service_id calendar.service_id部ID 条件付きで禁止 prior_notice_last_dayまたはprior_notice_start_dayがカウントされるサービス日を示します。

例: 空の場合、prior_notice_start_day=2 は2暦日前になります。営業日 (休日のない平日) のみを含むservice_idとして定義されている場合、prior_notice_start_day=2 は2営業日前になります。

条件付きで禁止:
- booking_type =2 の場合は任意。
- それ以外の場合は禁止
message Text 任意 オンデマンドのピックアップとドロップオフを予約するときに、stop_timeでサービスを利用する乗客へのメッセージ。ユーザーインターフェイス内で送信される、サービスを利用するために乗客が実行する必要があるアクションに関する最小限の情報を提供することを目的としています。
pickup_message Text 任意 messageと同じように機能しますが、乗客がオンデマンドのピックアップのみを利用する場合に使用されます。
drop_off_message Text 任意 messageと同じように機能しますが、乗客がオンデマンドのドロップオフのみを利用する場合に使用されます。
phone_number 電話番号 任意 予約リクエストを行うために電話する電話番号。
info_url URL 任意 予約ルールに関する情報を提供する URL。
booking_url URL 任意 予約リクエストを行うことができるオンラインインターフェイスまたはアプリへの URL。

translations.txt

ファイル: 任意

主キー(table_namefield_namelanguagerecord_idrecord_sub_idfield_value)

複数の公用語がある地域では、交通機関/運営者は通常、言語固有の名前とウェブページを持っています。それらの地域の乗客に最適なサービスを提供するために、データセットにこれらの言語に依存する値を含めることは有用です。

2つの異なる行で同じ値を翻訳するために(record_idrecord_sub_id)とfield_valueの両方の参照方法が使用されている場合、(record_idrecord_sub_id)で提供される翻訳が優先されます。

フィールド名 タイプ 存在 説明
table_name Enum 必須 翻訳するフィールドを含むテーブルを定義します。許可される値は次のとおりです:

- agency
- stops
- routes
- trips
- stop_times
- pathways
- levels
- feed_info
- attributions

GTFS に追加されたファイルには、上記のファイル名と同等のtable_name値が含まれます (つまり、.txt ファイル拡張子は含まれません)。
field_name Text 必須 翻訳するフィールドの名前。Textタイプのフィールドは翻訳できますURLEmailPhone numberタイプのフィールドも、正しい言語でリソースを提供するために「翻訳」できます。その他のタイプのフィールドは翻訳しないでください。
language 言語コード 必須 翻訳の言語。

言語がfeed_info.feed_langと同じ場合、フィールドの元の値は、特定の翻訳のない言語で使用するデフォルト値であると見なされます (default_langで別途指定されていない場合)。
例: スイスでは、公式にバイリンガルの州にある都市は正式にはビール/ビエンヌと呼ばれますが、フランス語では単にビエンヌ、ドイツ語ではビールと呼ばれます。
translation Text、URL、メール、電話番号 必須 翻訳された値。
record_id 外部ID 条件付きで必須 翻訳するフィールドにrecord_idするレコードを定義します。record_id の値は、各テーブルの主キー属性で定義されているように、テーブルの主キーの最初のフィールドまたは唯一のフィールドである必要があります。

- [agency.txt] のagency_id (#agencytxt)
- stops.txtstop_id
- routes.txtroute_id ;
- trips.txttrip_id
- stop_times.txttrip_id ;
- pathways.txtpathway_id ;
- levels.txtlevel_id ;
- attributions.txtattribution_id

上記で定義されていないテーブル内のフィールドは翻訳しないでください。ただし、プロデューサーが公式仕様外のフィールドを追加する場合があり、これらの非公式フィールドは翻訳される可能性があります。以下は、これらのテーブルでrecord_idを使用するための推奨方法です。

- calendar.txtservice_id ;
- calendar_dates.txtservice_id ;
- fare_attributes.txtfare_id ;
- fare_rules.txtfare_id ;
- shapes.txtshape_id ;
- frequencies.txttrip_id ;
- transfers.txtfrom_stop_id

条件付きで必須:
- table_namefeed_infoの場合は禁止です。
- field_valueが定義されている場合は禁止です。
- 必須 field_valueが空の場合。
record_sub_id 外部ID 条件付きで必須 テーブルに一意のIDがない場合に、フィールドを含むレコードを翻訳するのに役立ちます。したがって、record_sub_idの値は、次の表で定義されているように、テーブルのセカンダリIDです。

- agency.txt にはなし。
- stops.txt にはなし
- routes.txt にはなし。
- trips.txt にはありません。
- stop_times.txtstop_sequence ;
- pathways.txt にはなし。
- levels.txt にはなし
- attributions.txt にはありません。

上記で定義されていないテーブル内のフィールドは翻訳しないでください。ただし、プロデューサーが公式仕様外のフィールドを追加する場合があり、これらの非公式フィールドは翻訳される可能性があります。以下は、これらのテーブルでrecord_sub_idを使用するための推奨方法です。

- calendar.txt にはなし
- calendar_dates.txtdate
- fare_attributes.txt にはなし
- fare_rules.txtroute_id ;
- shapes.txt にはなし
- frequencies.txtstart_time ;
- transfers.txtto_stop_id

条件付きで必須:
- table_namefeed_infoの場合は禁止です。
- field_valueが定義されている場合は禁止です。
- 必須 table_name=stop_times の場合、record_idが定義されています。
field_value Text、URL、メール、電話番号 条件付きで必須 record_idrecord_sub_idを使用してどのレコードを翻訳するかを定義する代わりに、このフィールドを使用して翻訳する値を定義できます。これを使用すると、table_namefield_nameで識別されるフィールドに、field_valueで定義された値とまったく同じ値が含まれている場合に翻訳が適用されます。

フィールドには、field_valueで定義された値と 正確に 一致している必要があります。値のサブセットのみがfield_valueと一致する場合、翻訳は適用されません。

2つの翻訳ルールが同じレコードに一致する場合 (1つはfield_value、もう1つはrecord_id)、record_idのルールが優先されます。

条件付きで必須:
- table_namefeed_infoの場合は禁止です。
- record_idが定義されている場合は禁止です。
- 必須record_idが空の場合。

feed_info.txt

ファイル: 条件付きで必須

主キー (none)

ファイルには、データセットが記述するサービスではなく、データセット自体に関する情報が含まれます。場合によっては、データセットの発行者が機関とは異なるエンティティであることがあります。

フィールド名 タイプ 存在 説明
feed_publisher_name Text 必須 データセットを公開する組織のフルネーム。これは、agency.agency_name値のいずれかと同じである可能性があります。
feed_publisher_url URL 必須 データセットを公開する組織の Web サイトの URL。これは、agency.agency_url値のいずれかと同じである可能性があります。
feed_lang 言語コード 必須 このデータセットのテキストに使用されるデフォルトの言語。この設定は、GTFS のユーザーがデータセットの大文字化ルールやその他の言語固有の設定を選択するのに役立ちます。テキストをデフォルト以外の言語に翻訳する必要がある場合は、ファイルtranslations.txtを使用できます。

元のテキストが複数の言語であるデータセットの場合、デフォルトの言語は多言語になることがあります。このような場合、feed_langに「ISO 639-2」規格で定義されている言語コードmulを含め、データセットで使用されている各言語の翻訳をtranslations.txtで提供する必要があります。データセット内の元のテキストがすべて同じ言語である場合は、mul を使用しないでください。
例: スイスのような多言語国家のデータセットを考えてみましょう。元のstops.stop_nameフィールドに、さまざまな言語の停留所名が入力されています。各停留所名は、その停留所の地理的位置で主流の言語に従って記述されます。たとえば、フランス語圏の都市ジュネーブの場合はGenève、ドイツ語圏の都市チューリッヒの場合はZürich、バイリンガルの都市ビール/Biel/Bienneです。データセットのfeed_langmulである必要があり、翻訳はtranslations.txtで提供されます。ドイツ語の場合: GenfZürichBiel。フランス語の場合: GenèveZurichBienne。イタリア語の場合: GinevraZurigoBienna。英語では、GenevaZurichBiel/Bienne
default_lang 言語コード 任意 データ利用者が乗客の言語を知らない場合に使用する言語を定義します。多くの場合、en (英語) になります。
feed_start_date 日付 推奨 データセットは、feed_start_date日の開始からfeed_end_date日の終了までの期間のサービスの完全で信頼性の高いスケジュール情報を提供します。両方の日付が利用できない場合は空白のままにすることができます。両方が指定されている場合、feed_end_datedateはfeed_start_datedateより前にしてはなりません。データセットプロバイダーは、今後のサービスの可能性を通知するためにこの期間外のスケジュールデータを提供することが推奨されますが、データセット利用者はそれが正式なものではないことに留意して扱う必要があります。feed_start_dateまたはfeed_end_datecalendar.txt および calendar_dates.txt で定義されている有効なカレンダーの日付を超える場合、データセットは、feed_start_dateまたはfeed_end_dateの範囲内で、有効なカレンダーの日付に含まれない日付にはサービスがないことを明示的に主張しています。
feed_end_date 日付 推奨 (上記を参照)
feed_version Text 推奨 GTFS データセットの現在のバージョンを示す文字列。GTFS を使用するアプリケーションはこの値を表示して、データセットの公開者が最新のデータセットが組み込まれているかどうかを判断できるようにします。
feed_contact_email メール 任意 GTFS データセットとデータ公開方法に関する連絡用のメール アドレス。feed_contact_emailは、GTFS を使用するアプリケーションの技術担当者の連絡先です。 agency.txt を通じてカスタマー サービスの連絡先情報を提供します。feed_contact_email またはfeed_contact_urlも` 1つを指定することをお勧めします。
feed_contact_url URL 任意 GTFS データセットとデータ公開方法に関する連絡用の連絡先情報、ウェブフォーム、サポート デスク、またはその他のツールの URL。feed_contact_urlは、GTFS を利用するアプリケーションのfeed_contact_url担当者の連絡先です。 agency.txt を通じてカスタマー サービスの連絡先情報を提供します。feed_contact_urlまたはfeed_contact_emailも1つを指定することをお勧めします。

attributions.txt

ファイル: 任意

主キー(attribution_id)

このファイルは、データセットに適用される属性を定義します。

フィールド名 タイプ 存在 説明
attribution_id ユニークID 任意 データセットまたはそのサブセットの帰属を識別します。これは主に翻訳に役立ちます。
agency_id agency.agency_id部ID 任意 帰属が適用される事業者。

agency_idroute_id、またはtrip_id属性のいずれかが定義されている場合、その他は空にする必要があります。いずれも指定されていない場合、属性はデータセット全体に適用されます。
route_id routes.route_id部ID 任意 属性がルートに適用されることを除いて、agency_idと同じように機能します。同じルートに複数の属性を適用できます。
trip_id trips.trip_id部ID 任意 属性が旅行に適用されることを除いて、agency_idと同じように機能します。同じ旅行に複数の属性を適用できます。
organization_name Text 必須 データセットの帰属先となる組織の名前。
is_producer 列挙型 任意 組織の役割はプロデューサーです。有効なオプションは次のとおりです。

0 または空 - 組織にはこの役割がありません。
1 - 組織にはこの役割があります。

is_produceris_operator、またはis_authorityも1つを1に設定する必要があります。
is_operator 列挙型 任意 組織の役割がオペレータであることを除いて、is_producerと同じように機能します。
is_authority 列挙型 任意 組織の役割が権限であることを除いて、is_producerと同じように機能します。
attribution_url URL 任意 組織の URL。
attribution_email 電子メール 任意 組織の電子メール。
attribution_phone 電話番号 任意 組織の電話番号。