GTFS Schedule参照

2022年12月8日に改訂されました。 詳しくは改訂履歴をご覧ください。

本書は、GTFSデータセットを構成するファイルのフォーマットと構造を定義するものである。

目次

1. ドキュメント規約
2. データセットファイル
3. ファイル要件
4. フィールド定義
   • agency.txt
   • stops.txt
   • routes.txt
   • trips.txt
   • stop_times.txt
   • calendar.txt
   • calendar_dates.txt
   • fare_attributes.txt
   • fare_rules.txt
   • fare_media.txt
   • fare_products.txt
   • fare_leg_rules.txt
   • fare_transfer_rules.txt
   • areas.txt
   • stop_areas.txt
   • shapes.txt
   • frequencies.txt
   • transfers.txt
   • pathways.txt
   • levels.txt
   • translations.txt
   • feed_info.txt
   • attributions.txt

ドキュメント規約

この文書におけるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" はRFC 2119 に記述されているように解釈されるものである。

用語の定義

本書で使用する用語の定義です。

• データセット- この仕様書で定義されているファイルの完全なセット。データセットを変更すると、そのデータセットの新しいバージョンが作成される。データセットは、zipファイル名を含む、公開された恒久的なURLで公開されるべきである。(例: https://www.agency.org/gtfs/gtfs.zip)。
• レコード- 1つのエンティティ（交通機関、停留所、路線など）を記述する多数の異なるフィールド値で構成される基本的なデータ構造。テーブルでは、行として表現される。
• フィールド- オブジェクトまたはエンティティのプロパティ。テーブルでは列として表現される。
• フィールド値- フィールド内の個々の項目。テーブルでは1つのセルとして表現される。
• サービスデー- サービスデーは、ルートのスケジューリングを示すために使用される期間である。サービス日の正確な定義は機関によって異なるが、サービス日は多くの場合、暦日と一致しない。ある日にサービスが開始され、翌日に終了する場合、サービス日は24:00:00を超えることがある。例えば、金曜日の8:00:00から土曜日の02:00:00まで運行しているサービスは、1つのサービス日の8:00:00から26:00:00まで運行していると表現することができます。
• 音声合成フィールド- このフィールドは、親フィールド（空の場合はその上に戻る）と同じ情報を含む必要があります。音声合成として読まれることを目的としているため、省略形は削除するか（「St」は「Street」または「Saint」と読み、「Elizabeth I」は「Elizabeth the first」とする）、そのまま読まれるようにする（「JFK Airport」は省略形とする）必要があります。
• レグ（Leg）-ライダーが旅行中に後続の2つの場所の間で乗り降りする旅行。
• ジャーニー（Journey）-出発地から目的地までの全体的な旅行で、その間にあるすべてのレグと乗り換えを含む。
• サブジャーニー- 旅程の一部を構成する2つ以上のレッグ。
• 運賃製品-購入可能な運賃製品で、旅行の支払いまたは検証に使用することができる。

プレゼンス

フィールドとファイルに適用されるプレゼンス条件。

• 必須- そのフィールドまたはファイルはデータセットに含まれ、各レコードに有効な値が含まれていなければなりません。
• 任意- データセットからフィールドまたはファイルを省略することができます。
• 条件付き必須 - フィールドまたはファイルの説明で概説された条件下で、そのフィールドまたはファイルを含める必要があります。
• 条件付きで禁止- このフィールドまたはファイルは、フィールドまたはファイルの説明で概説された条件下で含まれてはなりません。

フィールドの種類

• Color- 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は日本円。
• 通貨量- 通貨量を示す10進数値。小数点以下の桁数は、ISO 4217のCurrencyコードで指定されている。すべての金融計算は、データを消費するために使用されるプログラミングlanguage、10進数、通貨、または金融計算に適した他の同等の型として処理されるべきです。通貨を浮動小数点として処理することは、計算中の金銭の増減のために推奨されない。
• 日付- サービス日（YYYYMMDD形式）。サービス日内の時間は24:00:00を超える場合があるため、サービス日は翌日以降の情報を含む場合があります。
  例：2018 年 9 月 13 日の場合、20180913。
• Email- 電子メールアドレス。
  例:example@example.com
• Enum- "説明 "欄で定義された事前定義された定数のセットからのオプション。
  例例：route_typeフィールドは、tram を表す0、subway を表す1、...を含む。
• ID- IDフィールドの値は内部IDであり、ライダーに表示されることを意図しておらず、任意のUTF-8文字のシーケンスである。印刷可能なASCII文字のみを使用することが推奨される。IDは、ファイル内でユニークでなければならない場合、"ユニークID "とラベル付けされる。ある.txtファイルで定義されたIDは、しばしば別の.txtファイルでも参照されます。他のテーブルのIDを参照するIDは、"外部ID "と表示される。
  例stops.txt stop_idフィールドは "ユニークID "である。stops.txtxtのparent_stationフィールドは、「stops.stop_id参照する外部ID」である。
• languageコード - IETF BCP 47のlanguageコード。IETF BCP 47の紹介は、https://www.rfc-editor.org/rfc/bcp/bcp47.txtとlanguage-tags/">language を参照してください。
  例：enは英語、en-USはアメリカ英語、deはドイツ語。
• Latitude- WGS84の緯度を10進数で表したもの。値は-90.0以上、90.0以下でなければなりません。
  例ローマのコロッセオの場合、41.890169。
• 経度- WGS84経度を10進数で表したもの。値は-180.0以上、180.0以下でなければなりません。
  例：ローマのコロッセオの場合は12.492269。
• Float- 浮動小数点数。
• Integer- 整数。
• 電話番号- 電話番号。
• Time- HH:MM:SS形式(H:MM:SSも使用可能)の時間。時刻は、サービス提供日の「正午から12時間を引いた時刻」（サマータイムが適用される日を除き、実質的には午前0時）から計測される。午前0時以降に発生する時刻は、現地時間のHH:MM:SSで24:00:00より大きい時刻を入力してくださいSchedule
  例：午後2時30分の場合は14時30分00秒、翌日の午前1時35分の場合は25時35分00秒。
• Text- UTF-8文字の文字列で、表示を目的としているため、人間が読めるものでなければならない。
• Timezone- TZタイムゾーン（https://www.iana.org/time-zones）。タイムゾーン名にはスペースは含まれませんが、アンダースコアが含まれる場合があります。有効な値のリストについては、https://en.wikipedia.org/wiki/List_of_tz_zonesを参照してください。
  例例：Asia/Tokyo、America/Los_Angeles、Africa/Cairo。
• URL- http:// または https:// を含む完全修飾URL。URL内の特殊文字は正しくエスケープする必要があります。完全修飾URL値の作成方法については、次のhttps://www.w3.org/Addressing/URL/4_URI_Recommentations.htmlを参照してください。

フィールド記号

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

• 非負- 0 以上であること。
• 非ゼロ- 0 以外。
• 正- 0より大きい。

例例：非負の浮動小数点数- 0以上の浮動小数点数。

データセットの属性

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

例：trip_idとstop_sequenceフィールドがstop_times.txtの主キーを構成している場合。

データセットファイル

本仕様書では、以下のファイルを定義する。

ファイル名	プレゼンス	説明
agency.txt	必須	このデータセットで表現されるサービスを持つ交通機関
stops.txt	必須	このデータセットに含まれるサービスを持つ交通機関。また、駅や駅の入り口も定義されている。
routes.txt	必須	乗り換えのルート。ルートは、1つのサービスとしてライダーに表示されるトリップのグループである。
trips.txt	必須	各ルートのトリップ。トリップとは、特定の時間帯に発生する2つ以上の停留所の連続である。
stop_times.txt	必須	トリップごとに、車両が停留所に到着する時刻、および停留所から出発する時刻。
calendar.txt	条件付きで必要	開始日と終了日を含む週間Schedule指定されたサービス日。 条件付きで必要。 - 必須に定義されている場合を除き、すべてのサービス提供日が calendar_dates.txt. - それ以外は任意。
calendar_dates.txt	条件付きで必要	で定義されたサービスに対する例外 calendar.txt. 条件付きで必要です。 - 必須もし calendar.txtは省略される。この場合 calendar_dates.txtは、すべての運行日を含む必要がある。 - それ以外は任意。
fare_attributes.txt	オプション	交通機関の路線の運賃情報。
fare_rules.txt	オプション	旅程に応じた運賃を適用するためのルール。
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	オプション	停留所をエリアに割り当てるためのルール。
shapes.txt	オプション	車両の移動経路をマッピングするためのルール（ルートアラインメントと呼ばれることもある）。
frequencies.txt	オプション	ヘッドウェイ（運行間隔）：ヘッドウェイ方式のサービスや定時運行を圧縮して表現したもの。
transfers.txt	オプション	ルート間の乗り換えポイントでの接続ルール。
pathways.txt	オプション	駅構内を結ぶ通路。
levels.txt	条件付きで必要	駅構内の階層。 条件付きで必須である。 - 必須エレベーターのある経路を記述する場合pathway_mode=5). - それ以外の場合は任意。
translations.txt	オプション	顧客向けデータセット値の翻訳。
feed_info.txt	オプション	データセットのメタデータ（発行元、バージョン、有効期限などの情報を含む
attributions.txt	オプション	データセットの属性

ファイル要件

データセットファイルの形式と内容には、以下の要件があります。

• すべてのファイルは、カンマ区切りのテキストとして保存されなければならない。
• 各ファイルの最初の行には、フィールド名を記述する必要があります。Field Definitions］セクションの各サブセクションは、GTFSデータセットのファイルの 1 つに対応し、そのファイルで使用される可能性のあるフィールド名をリストアップしています。
• すべてのファイル名とフィールド名は、大文字と小文字を区別する。
• フィールド値には、タブ、キャリッジリターン、改行があってはならない。
• 引用符またはカンマを含むフィールド値は、引用符で囲む必要があります。さらに、フィールド値の各引用符の前には、引用符を付けなければならない。これは、Microsoft Excelがカンマ区切り（CSV）ファイルを出力する方法と同じです。CSVファイル形式の詳細については、https://tools.ietf.org/html/rfc4180 を参照してください。

次の例は、カンマ区切りのファイルにフィールド値がどのように表示されるかを示しています。

• 元のフィールド値。 引用符」、「カンマ」、「テキスト」を含む。
• CSVファイルでのフィールド値。 "引用符""カンマ""テキスト "が含まれます。
• フィールド値には、HTMLタグ、コメント、エスケープシーケンスを含んではいけません。
• フィールド間やフィールド名の間にある余分なスペースは削除する必要があります。多くのパーサーはスペースを値の一部と見なし、エラーの原因となることがあります。
• 各行の終わりには、CRLFまたはLFの改行文字を入れなければならない。
• ファイルは、すべてのUnicode文字に対応するため、UTF-8でエンコードする必要があります。Unicode のバイトオーダーマーク（BOM）文字を含むファイルも受け付けます。BOM 文字と UTF-8 の詳細についてはhttps://unicode.org/faq/utf_bom.html#BOMを参照してください。
• すべてのデータセットファイルは、まとめて圧縮しておく必要がある。

フィールド定義

agency.txt

ファイル：必須

主キーagency_id)

フィールド名	タイプ	プレゼンス	説明
agency_id	一意なID	条件付きで必要	輸送機関と同義であることが多い輸送ブランドを識別します。ただし、一つの機関が複数のサービスを運営している場合などは、機関とブランドは別個のものである。本書では、「ブランド」の代わりに「代理店」という用語を使用する。データセットには、複数のエージェンシーのデータを含めることができる。 条件付きで要求する。 - 必須データセットが複数の交通機関のデータを含んでいる場合。 - それ以外の場合は任意。
agency_name	テキスト	必須	交通機関のフルネーム
agency_url	URL	必須	交通機関のURL
agency_timezone	タイムゾーン	必須	交通機関の所在地を示すタイムゾーン。データセットに複数の機関が含まれている場合は、各機関に同一の agency_timezone.
agency_lang	languageコード	オプション	この輸送機関が使用する主なlanguage。GTFS利用者がデータセットの大文字小文字のルールやその他のlanguage設定を選択するのに役立つよう、提供する必要がある。
agency_phone	電話番号	オプション	指定されたエージェンシーの音声電話番号。このフィールドは、代理店のサービスエリアでの典型的な電話番号を示す文字列値である。番号の桁をグループ化するための句読点を含むことができる。ダイヤル可能なテキスト(例えば、TriMetの "503-238-RIDE")は許可されているが、フィールドには他の説明テキストを含んではならない。
agency_fare_url	URL	オプション	乗車券やその他の運賃をオンラインで購入できるウェブページのURL。
agency_email	電子メール	オプション	代理店の顧客サービス部門が積極的に監視している電子メールアドレス。この電子メール・アドレスは、乗り換え客が機関の顧客サービス担当者に連絡できる直接的な接点であるべきである。

stops.txt

ファイル：必須

主キーstop_id)

フィールド名	タイプ	プレゼンス	説明
stop_id	一意のID	必須	停留所／プラットフォーム、駅、入口／出口、一般ノード、または乗車エリア（「1. location_type). 複数のルートで同じものを使用することができます。 stop_id.
stop_code	テキスト	オプション	ライダーのために場所を特定する短いテキストまたは番号。これらのコードは、しばしば電話ベースの交通情報システムで使用されるか、またはライダーが特定の場所の情報を得ることを容易にするために標識に印刷されています。このコードは stop_codeと同じであってもよい。 stop_idは、公共の場である場合、同じである。このフィールドは、ライダーに提示されるコードのない場所については、空のままにしておく必要があります。
stop_name	テキスト	条件付きで必要	場所の名前この欄は 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	テキスト	オプション	の読み替え版。 stop_name.の「音声合成フィールド」を参照。 用語の定義をご覧ください。
stop_desc	テキスト	オプション	有益で質の高い情報を提供する場所の説明。と重複してはいけません。 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は無視される。 条件付きで必要 - 必須を使用して運賃情報を提供する場合 fare_rules.txt - それ以外の場合は任意。
stop_url	URL	オプション	その場所に関するウェブページのURL。とは異なる必要があります。 agency.agency_urlと routes.route_urlフィールドの値とは異なる必要があります。
location_type	列挙	オプション	場所のタイプ。有効なオプションは 0(または空白) 停留所(または プラットフォーム).乗客が乗り物に乗ったり降りたりする場所。の中に定義される場合、プラットフォームと呼ばれる。 parent_station. 1- 駅.1つまたは複数のプラットフォームを含む物理的な構造物またはエリア。 2- 出入口.乗客が道路から駅に出入りすることができる場所。出入口が複数の駅に属する場合、両方の駅にパスウェイでリンクすることができるが、データ提供者はどちらかを親として選択しなければならない。 3- ジェネリックノード.駅内の位置で、他のどの駅とも一致しない。 location_typepathways.txt定義されたパスウェイをリンクするために使用することができる。 4- ボーディングエリア.プラットフォーム上の特定の場所で、乗客が車両に乗車または降車することができる場所。
parent_station	外部ID参照 stops.stop_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_timezoneの値が指定されている場合 stop_times.txtで指定されたタイムゾーンの午前0時からの時間を入力する必要があります。 agency.agency_timezone.これにより、トリップがどのタイムゾーンを通過しても、トリップ中の時刻の値は常に増加することになる。
wheelchair_boarding	列挙	オプション	その場所から車椅子の搭乗が可能かどうかを示す。有効なオプションは以下の通り。 親不知停留所の場合 0または空 - その停留所のアクセシビリティ情報はありません。 1- この停留所の一部の車両は、車椅子のまま乗車できます。 2- この停留所では車椅子での乗車はできません。 子停留所の場合。 0または空 - 親駅の動作を引き継ぎます。 wheelchair_boardingの挙動を継承する（親駅で指定されている場合）。 1- 駅の外から特定の停留所/プラットフォームまで、アクセス可能な経路が存在する。 2- 駅の外から特定の停留所/プラットフォームまで、アクセス可能な経路が存在しない。 駅の出入り口の場合。 0または空 - 駅の出入口は、指定された場合、親駅からその動作を継承する。 wheelchair_boarding親駅に指定されている場合、親駅の動作を継承する。 1- 駅入口は車椅子でアクセス可能です。 2- 駅入口から停留所／プラットフォームへのアクセス可能な経路がない。
level_id	外国人IDの参照 levels.level_id	オプション	場所のレベル。同じレベルをリンクしていない複数の駅が使用することがある。
platform_code	テキスト	オプション	プラットホームストップ(駅に属する停留所)のプラットホーム識別子。これはプラットフォーム識別子（例："G "または "3"）だけであるべきです。platform "や "track "などの単語（またはフィードのlanguage同等物）を含んではならない。これにより、フィードの消費者は、プラットフォーム識別子をより簡単に国際化し、他の言語にローカライズすることができます。

routes.txt

ファイル：必須

主キーroute_id

フィールド名	タイプ	プレゼンス	説明
route_id	一意のID	必須	経路を特定する。
agency_id	外国人ID照会 agency.agency_id	条件付きで必要	指定された経路の代理店。 条件付きで必要 - 必須に複数の代理店が定義されている場合、その代理店を示す。 agency.txt. - そうでない場合はオプション
route_short_name	テキスト	条件付きで必要	経路の短い名前。多くの場合、ライダーがルートを識別するために使用する短い抽象的な識別子（たとえば、「32」、「100X」、「Green」）です。両方 route_short_nameそして route_long_nameが定義されている可能性がある。 条件付きで必要 - 必須もし routes.route_long_nameは空です。 - そうでない場合はオプション
route_long_name	テキスト	条件付きで必要	ルートのフルネームです。この名前は、通常 route_short_nameよりも説明的で、多くの場合、ルートの目的地または停留所が含まれます。両方 route_short_nameそして route_long_nameが定義されている可能性があります。 条件付きで必要 - 必須もし routes.route_short_nameは空です。 - そうでない場合はオプション
route_desc	テキスト	オプション	有用で質の高い情報を提供するルートの説明です。と重複してはならない。 route_short_nameまたは route_long_name. 例「A」列車は、マンハッタンのInwood-207 StとクイーンズのFar Rockaway-Mott Avenueの間を常時運行しています。また、午前6時頃から午前0時頃まで、追加の「A」列車がInwood-207 StとLefferts Boulevardの間で運行しています（列車は通常、Lefferts BlvdとFar Rockawayの間で交互に運行されます）。
route_type	電子メール	必須	ルートで使用される交通機関の種類を示します。有効なオプションは以下の通りです。 0- 路面電車、路面電車、ライトレール。メトロポリタンエリア内のライトレールまたは路面システム。 1- 地下鉄（Subway）、メトロ（Metro）。メトロポリタンエリア内の地下鉄道システム。 2- Rail（鉄道）。都市間または長距離の移動に使用される。 3- バス。短距離および長距離のバス路線に使用される。 4- フェリー。短距離および長距離の船便に使用される。 5- ケーブルトラム。ケーブルが車両の下を走っている路面電車に使用される（例：サンフランシスコのケーブルカー）。 6- 空中リフト、吊り下げ式ケーブルカー（例：ゴンドラリフト、空中路面電車）。キャビン、車、ゴンドラ、オープンチェアが1本以上のケーブルで吊り下げられているケーブル輸送。 7- フニクラ。急傾斜のために設計されたあらゆる鉄道システム。 11- トロリーバス。電柱を利用した架線から電力を供給する電気バス。 12- モノレール。線路が1本のレールや梁で構成されている鉄道。
route_url	URL	オプション	その路線に関するウェブページのURL。とは異なる必要があります。 agency.agency_url値。
route_color	色	オプション	公開資料と一致する路線の色指定。省略時または空白の場合、デフォルトは白 (FFFFFF) になります。との色の差は route_colorそして route_text_colorは、白黒の画面で見たときに十分なコントラストを提供するはずです。
route_text_color	カラー	オプション	の背景で描かれた文字に使用する読みやすい色。 route_color.デフォルトは黒 (000000省略時または未入力時は、白（ ）となります。との色の差は route_colorそして route_text_colorは、白黒の画面で見たときに十分なコントラストが得られるはずです。
route_sort_order	非負の整数	オプション	お客様へのプレゼンテーションに最適な形でルートを発注します。値の小さい経路から順に表示します。 route_sort_orderの値が小さいものから表示されます。
continuous_pickup	Enum	オプション	の通り、乗り物の走行経路上の任意の地点で乗車できることを示す。 shapes.txtを示す。有効なオプションは以下の通り。 0- 連続停車ピックアップ。 1or empty - 連続して停止するピックアップはありません。 2- 代理店に電話して連続停止ピックアップを手配する必要があります。 3- 運転手と調整し、連続停止集荷の手配をする必要があります。 の値 routes.continuous_pickupの値を上書きすることができる。 stop_times.continuous_pickup具体的には stop_timeルート上の
continuous_drop_off	Enum	オプション	によって記述されるように、ライダーが車両の走行経路上の任意の地点で乗り継ぎ車両から降りることができることを示す。 shapes.txt有効なオプションは： , 路線の各旅程で。有効なオプションは以下の通りです。 0- 連続停止式降車装置。 1または空 - 連続した停止による降車はできない。 2- 代理店に電話し、連続停止ドロップオフを手配してもらう必要があります。 3- 運転手と調整し、連続停止降車の手配をする必要があります。 の値は routes.continuous_drop_offの値を定義することによって上書きされる場合がある。 stop_times.continuous_drop_off具体的な stop_timeの値を上書きすることができる。
network_id	ID	オプション	ルートグループを特定する。の複数の列が同じである場合もある。 routes.txtが同じである場合がある。 network_id.

trips.txt

ファイル：必須

主キーtrip_id)

フィールド名	タイプ	プレゼンス	説明
route_id	外国人ID照会 routes.route_id	必須	経路を特定する。
service_id	外国人ID照会 calendar.service_idまたは calendar_dates.service_id	必須	1つ以上の経路でサービスが利用可能な日付の集合を識別します。
trip_id	固有ID	必須	トリップを特定します。
trip_headsign	テキスト	オプション	トリップの行き先を示すサインに表示されるテキストです。同じルートで異なるパターンのサービスを区別するために使用する必要があります。 トリップ中にヘッドサインが変更された場合、そのトリップの値。 trip_headsignの値を定義することによって上書きされる場合がある。 stop_times.stop_headsign特定の stop_timeの値は、トリップに沿ったものである。
trip_short_name	テキスト	オプション	例えば、通勤鉄道の旅で列車番号を識別するために、ライダーに旅を識別するために使用される公衆向けのテキスト。ライダーが一般的にトリップの名前に依存しない場合。 trip_short_nameは空であるべきである。A trip_short_name値は、提供される場合、サービス日内のトリップを一意に識別する必要がある。
direction_id	Enum	オプション	トリップの進行方向を示す。このフィールドはルーティングに使用されるべきではなく、タイムテーブルを公開する際に、トリップを方向別に分ける方法を提供する。有効なオプションは以下の通りです。 0- 一方向の旅行（例：往路）。 1- 逆方向の旅行（例：インバウンドトラベル）。 例は trip_headsignそして direction_idフィールドを一緒に使って、トリップの各方向に名前を割り当てることができます。A trips.txtファイルには、タイムテーブルで使用するためのこれらのレコードを含めることができる。 trip_id,...,trip_headsign,direction_id 1234,...,Airport,0 1505,...,Downtown,1
block_id	ID	オプション	トリップが属するブロックを識別する。ブロックは、同一車両による単一トリップまたは複数の連続したトリップから構成され、運行日を共有する。 block_id.A block_idブロックは、1つのトリップ、または同じ車両を使用した複数の連続したトリップで構成される。以下の例を参照してください。 の例を参照。
shape_id	外部ID参照 shapes.shape_id	条件付きで必要	トリップの車両走行経路を記述した地理空間形状を識別する。 条件付きで必須。 - 必須で定義された連続的なピックアップまたはドロップオフビヘイビアを持つトリップの場合。 routes.txtまたは stop_times.txt. - そうでない場合はオプション
wheelchair_accessible	Enum	オプション	車いすのアクセシビリティを示す。有効なオプションは以下の通り。 0または空 - このトリップのアクセシビリティ情報はありません。 1- このトリップで使用される車両は、少なくとも1人の車椅子のライダーを収容することができます。 2- このトリップでは、車椅子のライダーを収容することはできません。
bikes_allowed	Enum	オプション	自転車が使用可能かどうかを示します。有効な選択肢は以下の通りです。 0空車 - このトリップにはバイクの情報はありません。 1- このトリップで使用される車両は、少なくとも1台の自転車を収容することができます。 2- このトリップでは自転車は使用できません。

例ブロックと運行日

以下の例は、曜日ごとにブロックが分かれており、有効です。

route_id	trip_id	service_id	ブロックID	(始発駅)	(終点時刻)
赤	トリップ_1	月火水木金土日	赤ループ	22:00:00	22:55:00
赤	トリップ_2	金土日	赤色ループ	23:00:00	23:55:00
赤色	トリップ_3	金土日	赤色ループ	24:00:00	24:55:00
赤色	トリップ_4	月火水木	赤色ループ	20:00:00	20:50:00
赤色	トリップ_5	月火水木	レッド・ループ	21:00:00	21:50:00

上表の注意事項

• 例えば、金曜日から土曜日の朝にかけて、1台の車両でトリップ_1、トリップ_2、トリップ_3（午後10時～午前12時55分）を運行します。最後のトリップは土曜日の午前12:00から午前12:55に発生しますが、時間は24:00:00から24:55:00なので金曜日の「サービスデイ」の一部であることに注意してください。
• 月、火、水、木曜日は、1台の車両がtrip_1、trip_4、trip_5を午後8時から午後10時55分までブロック運行する。

stop_times.txt

ファイル：必須

主キーtrip_id,stop_sequence)

フィールド名	タイプ	プレゼンス	商品説明
trip_id	外部ID参照 trips.trip_id	必須	トリップを特定する。
arrival_time	時間	条件付きで必要	特定のトリップの停車駅(stop)への到着時刻(defined by stop_times.stop_idで定義される）停留所への到着時刻。 stop_times.trip_id). 停留所への到着時刻と出発時刻が別々でない場合。 arrival_timeそして departure_timeは同じであるべきである。 運行日の午前0時以降の時刻はSchedule旅行開始日の現地時間HH:MM:SSで24:00:00より大きい値を入力すること。 正確な発着時刻(timepoint=1または空白)が利用できない場合、推定または補間された到着時刻と出発時刻(timepoint=0を提供する必要があります。 条件付きで必要 - 必須最初の停車駅と最後の停車駅の時刻（以下のように定義される。 stop_times.stop_sequence). - 必須のために timepoint=1. - そうでない場合はオプション
departure_time	時間	条件付きで必要	その停留所からの出発時刻(define by)。 stop_times.stop_idで定義される）。 stop_times.trip_id). もし、ある停留所での到着と出発の時間が別々でなければ arrival_timeそして departure_timeは同じにする。 運行日の午前0時以降に発生する時刻は、旅行開始日の現地時間HH:MM:SSで24:00:00より大きい時刻を入力してください。 正確な到着時刻と出発時刻(timepoint=1または空欄)がない場合は、推定または補間された到着時刻と出発時刻(timepoint=0を提供する必要があります。 条件付きで必要 - 必須のために timepoint=1. - そうでない場合はオプション
stop_id	外部ID参照 stops.stop_id	必須	サービスされた停留所を特定する。旅行中にサービスを受けたすべての停留所には、その記録がなければならない。 stop_times.txt.参照される場所は、停留所/プラットフォームでなければならない。 stops.location_typeの値は必ず入力してください。 0または空でなければならない。また、複数のトリップやルートが同じ停留所でサービスを受けることができる。
stop_sequence	非負の整数	必須	特定のトリップのための停留所の順序。値はトリップに沿って増加しなければならないが、連続である必要はない。 例例：トリップの最初の場所には stop_sequence=1を持つことができ、トリップの2番目の場所には stop_sequence=23を、3番目の場所には stop_sequence=40などとすることができる。
stop_headsign	テキスト	オプション	ライダーにトリップの目的地を示す看板に表示されるテキスト。このフィールドは、停留所間でヘッドサインが変更されたときに、デフォルトの trips.trip_headsignこのフィールドは、停留所間でヘッドサインが変更された場合、デフォルトをオーバーライドします。ヘッドサインが旅行全体にわたって表示される場合、このフィールドはデフォルトを上書きします。 trips.trip_headsignを代わりに使用する必要があります。 A stop_headsignに指定された値は stop_timeに指定した値は、同じ旅行中の後続の stop_timeには適用されません。を上書きしたい場合は trip_headsign複数の場合 stop_timeを上書きしたい場合は、各トリップにおいて stop_headsignを繰り返す必要があります。 stop_time行。
pickup_type	Enum	オプション	ピックアップの方法を示します。有効なオプションは以下の通りです。 0または空 - 定期的なピックアップを行います。 1- ピックアップはありません。 2- 代理店に電話連絡し、集荷を依頼する。 3- ドライバーと調整し、ピックアップを手配する必要があります。
drop_off_type	Enum	オプション	ドロップオフの方法を示します。有効なオプションは以下の通りです。 0または空 - 定期的なドロップオフ。 1- ドロップオフなし。 2- ドロップオフを手配するために代理店に電話する必要があります。 3- ドライバーと調整し、ドロップオフを手配する必要があります。
continuous_pickup	Enum	オプション	によって記述された車両の走行経路上の任意の地点で、乗り手が乗り込むことができることを示す。 shapes.txtここから stop_time次へ stop_time旅行中の stop_sequence.有効なオプションは以下の通り。 0- 連続停止ピックアップ。 1or empty - 連続停止ピックアップなし。 2- 代理店に電話し、連続停止する集荷を手配する必要があります。 3- 運転手と調整し、連続停止集荷の手配をする必要があります。 このフィールドが入力されている場合、で定義された連続ピックアップの動作が上書きされます。 routes.txt.このフィールドが空である場合、. stop_timeで定義された連続的なピックアップの動作はすべて継承されます。 routes.txt.
continuous_drop_off	Enum	オプション	乗り手が、以下の説明に従って、車両の走行経路のどの地点でも乗り継ぎ車両から降りることができることを示す。 shapes.txtここから stop_timeから次へ stop_timeトリップの stop_sequence.有効なオプションは以下の通りです。 0- 連続停止式降車装置。 1または空車 - 連続停止式降車装置なし。 2- 連続停止降車の手配をするため、代理店に電話する必要があります。 3- 運転手と調整し、連続降車の手配をしなければならない。 このフィールドが入力されている場合、 で定義された連続ドロップオフビヘイビアを上書きします。 routes.txt.このフィールドが空の場合、. stop_timeで定義された任意の連続ドロップオフビヘイビアを継承します。 routes.txt.
shape_dist_traveled	非負浮動小数点数	オプション	最初の停止位置からこのレコードで指定された停止位置まで、関連する形状に沿って移動した実際の距離。このフィールドは、トリップ中の任意の2つの停留所間で描画するシェイプの量を指定する。で使用されるのと同じ単位でなければならない。 shapes.txt.に使用される値。 shape_dist_traveledに使用される値は、一緒に増加しなければならない。 stop_sequenceルート上の逆走を示すために使用してはならない。 例例：バスの始点から停留所までの走行距離が5.25kmの場合。shape_dist_traveled=5.25.
timepoint	Enum	オプション	停留所への到着時刻と出発時刻が、車両によって厳密に守られているのか、あるいはその代わりに概算や補間された時刻であるのかを示す。このフィールドにより、GTFS制作者は、おおよその時間であることを示しながら、補間された停車時間を提供することができる。有効なオプションは以下の通り。 0- 有効なオプションは以下の通りです：時刻はおおよそのものであるとみなす。 1または空 - 時刻は正確であると見なされます。

calendar.txt

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

主キーservice_id

フィールド名	タイプ	プレゼンス	商品説明
service_id	一意のID	必須	1 つまたは複数の路線のサービス提供可能な日付のセットを識別する。各 service_idの中で一意でなければならない。 calendar.txtファイルを作成します。
monday	Enum	必須	フィールドで指定された日付範囲のすべての月曜日に運行されるかどうかを示す。 start_dateそして end_dateフィールドで指定された日付範囲のすべての月曜日にサービスを行うかどうかを示す。には、特定の日付の例外を記載することができることに注意する。 calendar_dates.txt.有効なオプションは以下の通りです。 1- 日付範囲内のすべての月曜日にサービスを利用できます。 0- 日付範囲内の全ての月曜日はサービス対象外です。
tuesday	Enum	必須	と同じ働きをします。 mondayただし、火曜日は除く
wednesday	Enum	必須	と同じ働きをする機能 mondayexceptは水曜日に適用されます
thursday	Enum	必須	と同じ働きをする mondayただし、木曜日は除く
friday	Enum	必須	と同様の機能 mondayただし、金曜日は除く
saturday	Enum	必須	と同様の機能 mondayは土曜日に適用されます。
sunday	Enum	必須	と同じように機能する mondayexcept は日曜日に適用されます。
start_date	日付	必須	サービス開始日
end_date	日付	必須	サービス間隔の終了サービス日。このサービス日はサービス間隔に含まれる。

calendar_dates.txt

File:Conditionally Required（ファイル：条件付きで必要

主キーservice_id,date)

calendar_dates.txtテーブルは、日付によるサービスの有効・無効を明示的に示します。これは、2つの方法で使用することができます。

• 推奨。calendar_dates.txt calendar.txt併用し、calendar.txt定義されたデフォルトのサービスパターンに対する例外を定義する。もし、サービスが通常通りであり、明確な日付に若干の変更がある場合（例えば、特別なイベントサービスや学校のSchedule対応するため）、この方法は良い方法である。この場合、calendar_dates.service_id、calendar.service_id参照する外部IDである。
• 代替案です。代替案：calendar.txt省略し、calendar_dates.txt各サービス提供日を指定する。これは、かなりのサービスのバリエーションを許容し、通常の週次スケジュールのないサービスに対応する。この場合、sservice_idは ID となる。

フィールド名	タイプ	プレゼンス	商品説明
service_id	外部ID参照 calendar.service_idまたはID	必須	1つ以上の経路でサービス例外が発生した日付のセットを識別します。各(service_id, dateのペアは1回しか出現しません。 calendar_dates.txtを使用する場合 calendar.txtそして calendar_dates.txtを併用する場合は、一度だけ表示できます。と service_idの両方に出現する場合は calendar.txtそして calendar_dates.txtの情報は calendar_dates.txtで指定されたサービス情報を変更する。 calendar.txt.
date	日付	必須	サービス例外発生日。
exception_type	Enum	必須	日付フィールドで指定された日付にサービスが利用可能であるかどうかを示す。有効な選択肢は以下の通り。 1- 指定された日付にサービスが追加された。 2- 指定された日付のサービスが削除されました。 例例：あるルートで、休日に利用できるトリップのセットと、それ以外の日に利用できるトリップのセットがあるとします。1つは service_id通常運行Schedule休日運行ダイヤがあるとします。 service_idは休日Schedule相当します。特定の休日には calendar_dates.txtファイルを使って、休日をホリデーに追加したり service_idに追加し、通常サービスからその祝日を削除するために使用されます。 service_idSchedule

fare_attributes.txt

ファイル:オプション

主キーfare_id)

バージョン
運賃を記述するためのモデリングオプションは2つあります。GTFS V1 は、最小限の運賃情報を記述するためのレガシーオプションです。GTFS V2 は、代理店の運賃体系をより詳細に記述できるように更新された方法です。1つのデータセットには両方の方式が存在してもよいが、データ利用者は1つのデータセットに対して1つの方式のみを使用する必要がある。GTFS V2はGTFS V1よりも優先されることが推奨されています。

GTFS V1に関連するファイルは以下のとおりです。
-fare_attributes.txt
-fare_rules.txt

GTFS V2 に関連するファイルは、以下のとおりです。
-fare_media.txt
-fare_products.txt
-fare_leg_rules.txt
-fare_transfer_rules.txt

フィールド名	タイプ	プレゼンス	商品説明
fare_id	ユニークなID	必須	運賃クラスを特定します。
price	非負浮動小数点数	必須	運賃の価格（単位：円 currency_type.
currency_type	通貨コード	必須	運賃の支払いに使用される通貨
payment_method	Enum	必須	運賃の支払時期を示す。有効なオプションは次のとおりです。 0- 運賃は搭乗時に支払われます。 1- 運賃は搭乗前に支払わなければなりません。
transfers	Enum	必須	この運賃で可能な乗り換えの回数を示します。有効なオプションは以下の通りです。 0- この運賃では、乗り換えはできません。 1- 乗り換えは1回です。 2- 乗り換えは2回まで可能です。 空 - 乗り換えは無制限に許可されています。
agency_id	外部ID参照 agency.agency_id	条件付きで必要	運賃に関連する代理店を特定します。 条件付きで必要 - 必須に複数の機関が定義されている場合は agency.txt. - そうでない場合はオプションで
transfer_duration	非負の整数	オプション	乗り換えが終了するまでの時間（秒）。いつ transfers=0このフィールドは、チケットの有効期限を示すために使用されるか、または空のままにしておくことができます。

fare_rules.txt

ファイル: オプション

主キー(*)

fare_rules.txtテーブルは、fare_attributes.txt運賃が旅程にどのように適用されるかを指定します。ほとんどの運賃構成では、以下の規則をいくつか組み合わせて使用します。

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

fare_rules.txtとfare_attributes.txt を使用して運賃構造を指定する方法を示す例については、GoogleTransitDataFeed オープンソースプロジェクトの wiki にあるFareExamplesを参照してください。

フィールド名	タイプ	プレゼンス	商品説明
fare_id	外部ID参照 fare_attributes.fare_id	必須	運賃クラスを特定する。
route_id	外部ID参照 routes.route_id	オプション	運賃種別に関連する経路を特定します。同じ運賃属性の経路が複数存在する場合は、運賃種別のレコードを作成します。 fare_rules.txt各ルートの 例運賃種別「b」が路線「TSW」「TSE」で有効な場合 fare_rules.txtファイルには、運賃クラスに関するこれらのレコードが含まれます。 fare_id,route_id b,TSW b,TSE
origin_id	外部ID参照 stops.zone_id	オプション	起点ゾーンを特定する。運賃クラスに複数の出発地ゾーンがある場合、以下のレコードを作成します。 fare_rules.txtそれぞれについて origin_id. 例例：運賃クラス「b」がゾーン「2」またはゾーン「8」を起点とするすべての旅行で有効である場合 fare_rules.txtファイルには、運賃クラスに関するこれらのレコードが含まれます。 fare_id,...,origin_id b,...,2 b,...,8
destination_id	外部ID参照 stops.zone_id	オプション	目的地ゾーンを特定します。運賃クラスに複数の目的地ゾーンがある場合、「目的地ゾーンの特定」にレコードを作成する。 fare_rules.txtそれぞれについて destination_id. 例の origin_idそして destination_idフィールドを併用することで、ゾーン3と4の間の移動には運賃クラス "b "が有効であること、ゾーン3と5の間の移動には fare_rules.txtファイルには、運賃クラスに関するこれらのレコードが含まれる。 fare_id,...,origin_id,destination_id b,...,3,4 b,...,3,5
contains_id	外部ID参照 stops.zone_id	オプション	特定された運賃クラスを使用している間、ライダーが進入するゾーンを識別する。正しい運賃クラスを計算するために、一部のシステムで使用されます。 例例：ゾーン 5、6、7 を通過する GRT ルートのすべての移動に運賃クラス「c」が関連する場合、ゾー fare_rules.txtには、これらのレコードが含まれます。 fare_id,route_id,...,contains_id c,GRT,...,5 c,GRT,...,6 c,GRT,...,7 なぜなら、すべての contains_idゾーン5と6を通過し、ゾーン7を通過しない旅程は、運賃クラス「c」が適用されません。詳細は以下をご参照ください。 https://code.google.com/p/googletransitdatafeed/wiki/FareExamplesは、GoogleTransitDataFeedプロジェクトのwikiに記載されています。

fare_media.txt

ファイル: オプション

主キー (fare_media_id)

運賃商品を使用するために採用できるさまざまな運賃メディアを説明する。運賃メディアとは、運賃商品の表現及び／又は検証に使用される物理的又は仮想的なホルダーのことです。

フィールド名	タイプ	プレゼンス	説明
fare_media_id	一意のid	必須	運賃メディアを特定する。
fare_media_name	テキスト	オプション	運賃媒体の名称。 交通系カードである運賃媒体の場合(fare_media_type =2)やモバイルアプリ(fare_media_type =4)、その fare_media_nameを含める必要があり、配信する組織が使用するライダー向けの名称と一致する必要があります。
fare_media_type	enum	必須	運賃メディアの種類。有効なオプションは以下の通りです。 0- なし。 運転手や車掌に現金を支払い、物理的なチケットを提供しないなど、運賃商品の購入や検証に関わる運賃媒体がない場合に使用します。 2- チケット、パス、または金銭的価値が保存されている物理的な交通カード。 3- アカウントベースのチケットのためのオープンループのトークンコンテナとしてのcEMV（非接触型Europay、Mastercard、Visa）。 4- 仮想交通カード、チケット、パス、または金銭的価値を保存しているモバイルアプリ。

fare_products.txt

ファイル：オプション

主キー(fare_product_id, fare_media_id)

ライダーが購入できる様々なタイプのチケットや運賃を説明する。

フィールド名	タイプ	プレゼンス	商品説明
fare_product_id	ID	必須	運賃商品を識別します。
fare_product_name	テキスト	オプション	ライダーに表示される運賃商品の名称です。
fare_media_id	外部ID参照 fare_media.fare_media_id	Optional	Identifies a fare media that can be employed to use the fare product during the trip. When fare_media_id is empty, it is considered that the fare media is unknown.
amount	通貨量	必須	運賃商品の価格。乗り換え割引を表すため、負にすることができます。無料運賃商品の場合は、0となります。
currency	通貨コード	必須	運賃商品のコストを表す通貨。

fare_leg_rules.txt

ファイル：オプション

主キーnetwork_id,from_area_id,to_area_id,fare_product_idid）。

個々のレッグの運賃ルール。

fare_leg_rules.txt運賃は、ファイル内のすべてのレコードをフィルタリングして、ライダーが移動するレグに一致する規則を見つけることによって照会する必要があります。

レッグのコストを処理するため

1. ファイルfare_leg_rules.txtは、旅行の特性を定義するフィールドによってフィルタリングされる必要があり、これらのフィールドは次のとおりです。
2. fare_leg_rules.network_id。
3. 運賃のfrom_area_id
4. 運賃のto_area_id番号（fare_leg_rules.
   

1. もしレッグがcharacteristics of travelに基づくfare_leg_rules.txtレコードと完全に一致する場合、そのレコードはレッグのコストを決定するために処理されなければなりません。
2. network_id、fare_leg_rules.from_area_id、fare_leg_rules.to_area_idある空のエントリは、レグのコストを処理するために確認されなければなりません。
3. network_id空の場合、fare_leg_rules.network_id記載されているネットワークを除く、routes.txt定義されている全てのネットワークに対応します。
4. from_area_id from_area_id from_area_id、fare_leg_rulesに記載されているものを除き、area.area_id定義されているすべてのエリアに対応します。
5. fare_ leg _rulesの空欄です。to_area_id to_area_id to_area_id to_area_id area_id area_id、areaで定義された全ての領域に対応します。
   

1. 脚が上記の規則のいずれにも一致しない場合、運賃は不明である。

フィールド名	タイプ	プレゼンス	商品説明
leg_group_id	ID	オプション	のエントリーのグループを識別する。 fare_leg_rules.txt. の間で運賃の移行規則を記述するために使用される。 fare_transfer_rules.from_leg_group_idそして fare_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	外部ID参照 routes.network_id	オプション	運賃レグルールに適用する経路網を特定する。 一致するものがない場合 fare_leg_rules.network_idの値を network_idフィルタリング中, 空 fare_leg_rules.network_idはデフォルトでマッチングされます。 にある空のエントリは fare_leg_rules.network_idで定義されたすべてのネットワークに対応します。 routes.txtの下にリストされているものを除く。 fare_leg_rules.network_id
from_area_id	外部ID参照 areas.area_id	オプション	は，出発地を指定します。 一致するものがない場合 fare_leg_rules.from_area_idの値を area_idフィルタリング中, 空 fare_leg_rules.from_area_idはデフォルトでマッチします。 に含まれる空の項目。 fare_leg_rules.from_area_idで定義されたすべての領域に対応する。 areas.area_idの下にリストされたものを除く。 fare_leg_rules.from_area_id
to_area_id	外部ID参照 areas.area_id	オプション	到着地を指定します。 該当するものがない場合 fare_leg_rules.to_area_idの値を area_idフィルタリング中, 空 fare_leg_rules.to_area_idはデフォルトでマッチします。 にある空のエントリは fare_leg_rules.to_area_idで定義されたすべての地域に対応します。 areas.area_idの下にリストされたものを除く fare_leg_rules.to_area_id
fare_product_id	外部ID参照 fare_products.fare_product_id	必須	そのレグを利用するために必要な運賃商品です。

fare_transfer_rules.txt

ファイル：オプション

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

farefare_leg_rules.txt定義されているレグ間の乗り換えの運賃ルール。

複数レグの旅程のコストを処理するため。

1. fare_leg_rules.txt定義された適用可能な運賃レッググループは、ライダーの旅程に基づき、個々のレッグ全てに対して決定される必要があります。

2. fare_transfer_rules.txtファイルは、乗り換えの特性を定義するフィールドによってフィルタリングされる必要があり、これらのフィールドは次のとおりです。

3. fare_transfer_rules.from_leg_group_id。

4. 運賃転送ルール(to_leg_group_id_transfer_rules).
   
   

5. 転送の特性に基づいて、転送がfare_transfer_rules.txt内のレコードと完全に一致する場合、そのレコードは転送コストを決定するために処理されなければなりません。

6. 完全に一致するものがない場合、from_leg_group_idまたはto_leg_group_id空のエントリをチェックして、転送コストを処理する必要があります。

7. from_leg_group_id空のエントリがある場合、fare_ transfer_rules.leg_group_idで定義されたレッググループのうち、from_leg_group_id_transfer_rules.

8. fare_transfer_rulesの空欄。to_leg_group_id to_leg_group_id to_leg_group_id to_leg_group_id、fare_leg_rules.leg_group_idで定義された全てのレッググループに対応し、fare_transfer_rulesに記載されているものは除外されます。
   
   

9. 転送が上記の規則のいずれにも一致しない場合、転送の手配は行われず、レッグは別々であるとみなされます。

フィールド名	タイプ	プレゼンス	商品説明
from_leg_group_id	外部ID参照 fare_leg_rules.leg_group_id	オプション	譲渡前運賃レッグルールのグループを特定する。 一致しない場合 fare_transfer_rules.from_leg_group_idの値に 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	外部ID参照 fare_leg_rules.leg_group_id	オプション	乗り換え後の運賃レッグルールのグループを識別する。 一致するものがない場合 fare_transfer_rules.to_leg_group_idの値に一致する値がない場合 leg_group_idフィルタリングされている, 空 fare_transfer_rules.to_leg_group_idはデフォルトでマッチします。 にある空のエントリは fare_transfer_rules.to_leg_group_idの下に定義された全てのレッググループに対応します。 fare_leg_rules.leg_group_idに記載されているものを除く。 fare_transfer_rules.to_leg_group_id
transfer_count	ゼロでない整数	条件付きで禁止	乗り換え規則が適用される連続乗り換え回数を定義する。 有効なオプションは次のとおりです。 -1- 制限なし。 1or more - 乗り換え規則が何回の乗り換えに適用されるかを定義する。 サブジャーニーが異なる複数のレコードに一致する場合、最小のルールが適用される。 transfer_countの異なる複数のレコードに一致する場合、最小のルールが適用されます。 transfer_count以上であるルールが選択されます。 条件付きで禁じられる - 禁止もし fare_transfer_rules.from_leg_group_idとは等しくない fare_transfer_rules.to_leg_group_id. - 必須もし fare_transfer_rules.from_leg_group_id等しい fare_transfer_rules.to_leg_group_id.
duration_limit	正の整数	オプション	転送の制限時間を定義します。 秒単位の整数で表現する必要があります。 継続時間の制限がない場合。 fare_transfer_rules.duration_limitは空でなければなりません。
duration_limit_type	Enum	条件付きで必要	の相対的な開始と終了を定義する。 fare_transfer_rules.duration_limit. 有効なオプションは次のとおりです。 0- 現在のレグの出発運賃の確認と、次のレグの到着運賃の確認との間。 1- 現在の旅程の出発運賃の確認と、次の旅程の出発運賃の確認の間。 2- 現在のフライトの到着運賃の確認と次のフライトの出発運賃の確認の間。 3- 当便の到着運賃確認後、次の便の到着運賃確認までの間。 条件付きで必要 - 必須もし fare_transfer_rules.duration_limitは定義されています。 - 禁止もし fare_transfer_rules.duration_limitは空です。
fare_transfer_type	Enum	必須	旅程の中で脚と脚の間を移動する際のコスト処理方法を示す。 有効なオプションは次のとおりです。 0- 往路 fare_leg_rules.fare_product_idプラス fare_transfer_rules.fare_product_id; A + AB. 1- 往路 fare_leg_rules.fare_product_idプラス fare_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 + AB S + BC 1 A + AB +B S＋BC＋C 2 AB S + BC ここで、Sは直前のレグと乗り換えの合計処理費用を示す。
fare_product_id	外部ID参照 fare_products.fare_product_id	オプション	2つの運賃レグ間で乗り換えるために必要な運賃製品です。空の場合、乗り換えルールのコストは0となる。

areas.txt

ファイル：任意

プライマリーキーarea_id)

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

フィールド名	タイプ	プレゼンス	商品説明
area_id	ユニークなID	必須	エリアを識別する。で一意でなければならない。 areas.txt.
area_name	テキスト	オプション	ライダーに表示されるエリア名です。

stop_areas.txt

ファイル：任意

プライマリーキー(*)

stops.txtある停留所をエリアに割り当てる。

フィールド名	タイプ	プレゼンス	商品説明
area_id	外部ID参照 areas.area_id	必須	ライダーが所属するエリアを特定する。 stop_idが属するエリアを識別する。同じ stop_idは多数で定義されてもよい。 area_ids.
stop_id	外部ID参照 stops.stop_id	必須	停留所を識別する。もし駅(すなわち stops.location_type=1がこのフィールドに定義されている場合、そのプラットフォームのすべて(すなわち、この駅が定義されている stops.location_type=0と定義されている全ての駅)は同じエリアに属しているとみなされます。 stops.parent_stationを持つすべての駅）は、同じエリアに属しているとみなされます。この動作は、他のエリアにプラットフォームを割り当てることで上書きすることができる。

shapes.txt

ファイル：任意

主キーshape_id,shape_pt_sequence)

シェイプは、車両が経路に沿って移動する経路を記述したもので、shapes.txt に定義されています。シェイプはトリップに関連付けられ、車両が順番に通過する地点のシーケンスで構成される。ShapeはStopの位置を正確に捉える必要はないが、Trip上のすべてのStopはそのTripのShapeからわずかな距離、すなわちShapeのポイントを結ぶ直線セグメントに近い位置にあるべきである。

フィールド名	タイプ	プレゼンス	商品説明
shape_id	ID	必須	形状を特定する。
shape_pt_lat	緯度	必須	形状点の緯度の各レコードは shapes.txtの各レコードは、形状を定義するために使用される形状点を表す。
shape_pt_lon	経度	必須	形状点の経度(Longitude)
shape_pt_sequence	非負の整数	必須	形状を形成するために形状点を接続する順序。値は移動に伴って増加しなければならないが、連続である必要はない。 例形状 "A_shp "の定義に3つのポイントがある場合 shapes.txtファイルには、形状を定義するためにこれらのレコードが含まれている場合がある。 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	非負のfloat	オプション	最初のシェイプ点からこのレコードで指定された点まで、シェイプに沿って移動した実際の距離。トリッププランナーが地図上に形状の正しい部分を表示するために使用される。数値は、(1)と共に増加しなければならない。 shape_pt_sequenceルート上の逆走を示すために使用してはならない。距離の単位は、"A "で使用されている単位と一致していなければならない。 stop_times.txt. 例例：バスが上記のA_shpで定義された3つのポイントに沿って走行する場合、追加された値（ここではキロメートルで表示）は shape_dist_traveledの追加値（ここではキロメートルで表示）は、次のようになります。 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

ファイル：任意

主キーtrip_id,start_time)

frequencies.txt、通常のヘッドウェイ(運行間隔)で運行されるトリップを表す。このファイルは、2つの異なるタイプのサービスを表現するために使用することができます。

• 頻度ベースのサービス（exact_times=0） 一日を通して固定されたSchedule従わないサービスです。その代わり、オペレータはあらかじめ設定されたヘッドウェイを厳密に維持しようとします。
• Schedule型サービス(exact_times=1)の圧縮表現。スケジュールScheduleサービスでは、オペレータはSchedule厳密に守ろうとする。

フィールド名	タイプ	プレゼンス	商品説明
trip_id	外部ID参照 trips.trip_id	必須	指定されたヘッドウェイが適用されるトリップを識別する。
start_time	時刻	必須	最初の車両が最初の停留所から出発する時刻。
end_time	時間	必須	最初の停留所で異なるヘッドウェイに変更された（または停止された）時刻。
headway_secs	正の整数	必須	で指定された時間間隔において、そのトリップの同じ停留所（ヘッドウェイ）から出発する間の時間（秒）。 start_timeそして end_time.同じトリップに複数のヘッドウェイを定義することができるが、重なってはならない。新しいヘッドウェイは、前のヘッドウェイが終了した時刻に開始することができる。
exact_times	Enum	オプション	トリップのサービスの種類を示す。詳細については、ファイルの説明を参照してください。有効なオプションは以下の通り。 0または空 - 頻度ベースのトリップ。 1Scheduleトリップで、一日中全く同じヘッドウェイを持つ。この場合 end_timeこの場合、値は最後に希望したトリップよりも大きくなければならない。 start_timeよりも大きく、かつ最後に希望したトリップのstart_time小さい値でなければならない。 headway_secs.

transfers.txt

ファイル：任意

主キーfrom_stop_id,to_stop_id,from_trip_id,to_trip_id,from_route_id,to_route_id)

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

from_trip_id、to_trip_id、from_route_id、toto_route_id、乗り換えルールをより細かく指定することができます。from_stop_id、to_stop_ididと合わせて、特定性の順位は以下の通りである。

1. fromfrom_trip_ididとto_trip_id_idの両方のtrip_id定義されている。
2. trip_idIDとroute_idセットが1つ定義されている：from_trip_idandto_route_id) またはfrom_route_idandto_trip_id).
3. 片方のtrip_id定義されている：from_trip_idまたはto_trip_idid。
4. route_id2つとも定義されている：from_route_id to_route_idid。
5. route_idIDが1つだけ定義されている：from_route_idまたはto_route_idid。
6. from_stop_id to_stop_ididのみ定義されている：ルートやトリップに関連するフィールドが設定されていない。

到着トリップと出発トリップの順序付きペアに対して、これら2つのトリップ間に適用される最も特異性の高い転送が選択される。任意のトリップのペアに対して、適用されうる最大特異性が等しい2つの乗り換えが存在してはならない。

フィールド名	タイプ	プレゼンス	商品説明
from_stop_id	外部ID参照 stops.stop_id	必須	ルート間の接続を開始する停留所または駅を特定する。このフィールドが駅を参照する場合、乗り換えルールはその子駅すべてに適用される。
to_stop_id	外部ID参照 stops.stop_id	必須	経路の接続が終了する停留所または駅を示す。このフィールドが駅を参照する場合、転送ルールはすべての子駅に適用される。
from_route_id	外部ID参照 routes.route_id	オプション	接続を開始する経路を指定します。 の場合 from_route_idが定義されている場合、転送は、指定された経路の到着トリップに適用されます。 from_stop_id. 両方が指定された場合 from_trip_idそして from_route_idが定義されている場合、その trip_idに属さなければならない。 route_idと from_trip_idが優先されます。
to_route_id	外部ID参照 routes.route_id	オプション	接続が終了する経路を指定します。 もし to_route_idが定義されている場合、転送は、指定された経路の出発するトリップに適用されます。 to_stop_id. 両方の場合 to_trip_idそして to_route_idが定義されている場合、その trip_idに属していなければなりません。 route_idと to_trip_idが優先されます。
from_trip_id	外部ID参照 trips.trip_id	オプション	経路間の接続が開始されるトリップを特定する。 もし from_trip_idが定義されている場合、転送は、指定された経路の到着したトリップに適用されます。 from_stop_id. 両方の場合 from_trip_idそして from_route_idが定義されている場合 trip_idに属していなければなりません。 route_idと from_trip_idが優先されます。
to_trip_id	外部ID参照 trips.trip_id	オプション	経路間の接続が終了するトリップを特定する。 もし to_trip_idが定義されている場合、転送は指定されたトリップの出発するトリップに適用されます。 to_stop_id. 両方が定義されている場合 to_trip_idそして to_route_idが定義されている場合、その trip_idに属していなければならない。 route_idと to_trip_idが優先されます。
transfer_type	Enum	必須	指定された ( )内の接続の種類を表します。from_stop_id, to_stop_idのペアの接続の種類を示します。有効な選択肢は以下のとおりです。 0経路間の推奨乗り換えポイントです。 1- 2 つのルート間の時間指定された乗り換えポイント。出発する車両は到着する車両を待ち、ライダーが路線間を乗り継ぐのに十分な時間を確保することが期待されます。 2- 乗り換えには、到着と出発の間に最低限必要な時間があり、確実に接続することができる。乗り換えに必要な時間は、以下のように規定されています。 min_transfer_time. 3- その場所では、路線間の乗り換えはできません。
min_transfer_time	非負の整数	オプション	指定された停留所で路線間の乗り換えを可能にするために必要な時間（秒）。を指定する。 min_transfer_timeは、典型的なライダーが 2 つの停留所間を移動するのに十分な時間でなければならず、各路線のSchedule乱れを許容するバッファー時間を含む。

pathways.txt

ファイル：任意

主キーpathway_id)

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

駅の出入口（location_type=2のノード）からホーム（location_type=0または空のノード）へ移動するために、歩道、改札、階段など、経路として表される端の部分を移動することになる。汎用ノード（location_type=3 で表されるノード）は、駅全体の経路をつなぐために使用される。

パスウェイは駅構内で網羅的に定義されなければならない。パスウェイが定義されている場合、駅全体のパスウェイが表現されているものとする。したがって、以下のガイドラインが適用される。

• ダングリング・ロケーション（dangling location）は禁止する。ただし、乗り場のあるプラットフォーム（location_type=4、下記ガイドライン参照）は例外とする。
• 乗り場があるプラットフォームは通路を設けない。乗り場（location_type=4）を持つプラットフォーム（location_type=0または空）は、点ではなく、親オブジェクトとして扱われる。このような場合、プラットフォームにはパスウェイを割り当ててはいけません。すべてのパスウェイは、プラットフォームの各搭乗エリアに対して割り当てる必要があります。
• ロックされたプラットフォームは不可。プラットフォーム（location_type=0または空）または乗り場（location_type=4）は、少なくとも一つの出入口（location_type=2）に、何らかの経路の連鎖でつながっていなければならない。プラットフォームから駅の外側に出ることができない駅は稀である。

フィールド名	タイプ	プレゼンス	商品説明
pathway_id	ユニークなID	必須	経路を識別する。システムでレコードの内部識別子として使用される。データセット内で一意でなければならない。 には、異なる経路が同じ値を持つことがあります。 from_stop_idそして to_stop_id. 例2つのエスカレーターが反対方向に並んでいる場合、または階段セットとエレベーターが同じ場所から同じ場所に行く場合、異なる pathway_idを持つ可能性がある。 from_stop_idそして to_stop_id値である。
from_stop_id	外部ID参照 stops.stop_id	必須	経路が開始する場所。 を含んでいなければならない。 stop_idプラットフォーム(location_type=0または空）、出入口(location_type=2)、汎用ノード(location_type=3)または乗降場(location_type=4). の値 stop_id駅を特定するための値(location_type=1は禁止されています。
to_stop_id	外部ID参照 stops.stop_id	必須	経路の終点となる場所。 を含まなければならない。 stop_idプラットフォーム(location_type=0または空)、出入口(location_type=2)、汎用ノード(location_type=3)または乗降場(location_type=4). の値 stop_idを指定することはできません。location_type=1は禁止されています。
pathway_mode	Enum	必須	指定された( )ペア間の経路の種類。from_stop_id, to_stop_idのペアの間の経路のタイプです。有効なオプションは次のとおりです。 1- Walkway（歩道）。 2- 階段。 3- 動く歩道/トラベラー。 4- エスカレーター。 5- エレベーター。 6- 運賃ゲート（または支払ゲート）。横断するために支払証明が必要な駅の区域に横断する通路。運賃ゲートは、駅の有料エリアと未払いエリアを分けたり、同じ駅内の異なる支払いエリアを互いに分けたりすることができる。この情報を利用し、例えばバス路に行くために地下鉄のホームを通るように指示するなど、乗客に不必要な支払いを要求するような近道を使って駅を通過させることを避けることができる。 7- Exit Gate（イグジットゲート）。有料エリアから無賃エリアへ出るための通路で、通過する際に支払いの証明が不要なもの。
is_bidirectional	Enum	必須	通路の方向を示す。 0- からしか利用できない単方向の通路。 from_stop_idまで to_stop_id. 1- 双方向に利用できる通路。 出口ゲート(pathway_mode=7)は双方向であってはならない。
length	非負の浮動小数点数	オプション	起点位置（で定義）から終点位置（で定義）までの経路の水平方向の長さ（メートル）。 from_stop_idから目的地（「3． 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	フロート	オプション	通路の最大傾斜率。有効なオプションは以下の通りです。 0または空 - 勾配なし Float- 通路の勾配比、正は上向き、負は下向き。 このフィールドは、歩道 (pathway_mode=1) と動く歩道 (pathway_mode=3). 例米国では、0.083 (8.3%) が手押し車椅子の最大傾斜率で、1mごとに 0.083m (つまり 8.3cm) の増加を意味する。
min_width	ポジティブフロート	オプション	通路の最小幅をメートルで表す。 このフィールドは、最小幅が1メートル未満である場合に推奨される。
signposted_as	テキスト	オプション	Public facing text ライダーが見ることができる物理的な標識からのテキスト。 ライダーにテキストで指示を与えるために使用することができます。のテキストは singposted_asのテキストは、標識に印刷されているのと同じように表示される必要があります。 物理的な標識が多言語であるとき、このフィールドは、以下の例に従って入力され、翻訳されるかもしれない。 stops.stop_nameのフィールド定義にある feed_info.feed_lang.
reversed_signposted_as	テキスト	オプション	と同じである。 signposted_asから使用される場合、このフィールドは入力および翻訳されます。 to_stop_idになります。 from_stop_id.

levels.txt

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

プライマリキーlevel_id)

駅構内のレベルを記述する。pathways.txt と併せて使用すると便利で、エレベータ付きのパスウェイ（pathway_mode=5）をナビゲートする際に必要である。

フィールド名	タイプ	プレゼンス	商品説明
level_id	ユニークなID	必須	ステーション内のレベルを識別する。
level_index	Float - 浮動小数点数。	必須	相対的な位置を示すレベルの数値的なインデックス。 地上階はインデックス 0地上のレベルは正のインデックスで、地上のレベルは負のインデックスで示される。
level_name	テキスト	オプション	建物または駅の内部でライダーから見たレベルの名前。 例エレベーターで「Mezzanine」または「Platform」または「-1」まで行く。

translations.txt

ファイル：任意

主キーtable_name、field_name、language、record_id、record_sub_id、field_value)

複数の公用語を持つ地域では、交通機関/オペレーターは通常、language名称とウェブページを持っています。そのような地域の利用者に最適なサービスを提供するためには、データセットにこれらのlanguage値を含めることが有効である。

フィールド名	タイプ	プレゼンス	商品説明
table_name	Enum	必須	翻訳されるフィールドを含むテーブルを定義する。許容される値は以下の通り。 - agency - stops - routes - trips - stop_times - pathways - levels - feed_info - attributions GTFS追加されたすべてのファイルには、ファイル名と同じ値が設定されます。 table_nameGTFSに追加されたファイルは、上記のファイル名と同等の値を持つ（つまり、ファイル拡張子は含まれない）。 .txtファイル拡張子は含まない）。
field_name	テキスト	必須	翻訳されるフィールドの名前。型を持つフィールド Textのフィールドは翻訳されるかもしれない。 URL, Emailそして Phone numberのフィールドも、正しいlanguageリソースを提供するために「翻訳」されるかもしれない。他のタイプを持つフィールドは翻訳されるべきではない。
language	languageコード	必須	翻訳されるlanguage。 のlanguage同じであれば feed_info.feed_langと同じなら、そのフィールドの元の値は、特定の翻訳がない言語で使用するためのデフォルト値であると仮定されます (もし default_langが特に指定しない場合）。 例例：スイスでは、公式にバイリンガルである州の都市は、公式には「Biel/Bienne」と呼ばれますが、単にフランス語では「Bienne」、ドイツ語では「Biel」と呼ばれることになります。
translation	テキストまたはURLまたは電子メールまたは電話番号	必須	翻訳された値。
record_id	外部ID	条件付きで必要	翻訳されるフィールドに対応するレコードを定義します。の値は record_idの値は、各テーブルの主キー属性で定義されているように、そのテーブルの主キーの最初のフィールドか唯一のフィールドでなければなりません。 - agency_idのために agency.txt - stop_idのために stops.txt; - route_idfor routes.txt; - trip_idのために trips.txt; - trip_idのために stop_times.txt; - pathway_idのために pathways.txt; - level_idのために levels.txt; - attribution_idのために attribution.txt. 上記で定義されていないテーブルのフィールドは翻訳されるべきではありません。しかし、製作者は時々公式な仕様の外にある余分なフィールドを追加し、これらの非公式なフィールドは翻訳されるかもしれません。以下は、推奨される使用方法です。 record_idを使用することをお勧めします。 - service_idのために calendar.txt; - service_idのために calendar_dates.txt; - fare_idのために fare_attributes.txt; - fare_idのために fare_rules.txt; - shape_idのために shapes.txt; - trip_idのために frequencies.txt; - from_stop_idのために transfers.txt. 条件付きで必要 - 禁止もし table_nameは feed_info. - 禁止もし field_valueは定義されている。 - 必須もし field_valueは空です。
record_sub_id	外部ID	条件付きで必要	テーブルが一意のIDを持っていないときに翻訳されるフィールドが含まれているレコードを支援します。したがって、での値は record_sub_idは、以下の表で定義されているように、テーブルのセカンダリIDです。 - のためになし agency.txt; - なし stops.txt; - なし routes.txt; - なし trips.txt; - stop_sequenceのために stop_times.txt; - なし pathways.txt; - なし levels.txt; - なし attributions.txt. 上記で定義されていないテーブルのフィールドは、翻訳されるべきではない。しかし、製作者は時々公式仕様の外にある余分なフィールドを追加し、これらの非公式なフィールドは翻訳されるかもしれません。以下は、これらのテーブルに対して record_sub_idそれらのテーブルのために。 - なし calendar.txt; - dateのために calendar_dates.txt; - なし fare_attributes.txt; - route_idのために fare_rules.txt; - なし shapes.txt; - start_timeのために frequencies.txt; - to_stop_idのために transfers.txt. 条件付きで必要 - 禁断もし table_nameは feed_info. - 禁断もし field_valueは定義されています。 - 必須もし table_name=stop_timesそして record_idは定義されています。
field_value	テキストまたはURLまたは電子メールまたは電話番号	条件付きで必須	を使用してどのレコードが翻訳されるべきかを定義する代わりに、このフィールドを使用して翻訳されるべき値を定義することができます。 record_idそして record_sub_idを使って翻訳されるべきレコードを定義する代わりに、 このフィールドは翻訳されるべき値を定義するために使われることができます。によって識別されるフィールドがfield_valueで定義された値と全く同じ値を含むとき、翻訳が適用されます。 table_nameそして field_nameで特定されるフィールドがfield_value定義された値と全く同じ値を含んでいるときに翻訳が適用されます。 このフィールドは 正確にで定義された値でなければなりません。 field_value.にマッチする値のサブセットのみが存在する場合、翻訳は適用されません。 field_valueにマッチする場合、変換は適用されません。 もし2つの翻訳ルールが同じレコードにマッチするならば(一方は field_valueを持つルールと record_idを持つルールとが同じレコードにマッチした場合、 を持つルールが優先されます。 record_idが優先されます。 条件付きで必要です。 - 禁断もし table_nameは feed_info. - 禁止もし record_idは定義されています。 - 必須もし record_idは空です。

feed_info.txt

ファイル：オプション（ translations.txt提供されている場合は必須）。

主キー(none)

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

2つの行で同じ値を翻訳するために，record_id,record_sub_id) とfield_valueの両方の参照方法を使用した場合，record_id,record_sub_id) で提供した翻訳が優先される．

フィールド名	タイプ	プレゼンス	商品説明
feed_publisher_name	テキスト	必須	データセットを公開している組織の正式名称．のいずれかと同じになる可能性がある。 agency.agency_name値である。
feed_publisher_url	URL	必須	データセットを公開している組織のウェブサイトのURL。のいずれかと同じになる可能性がある。 agency.agency_url値である。
feed_lang	languageコード	必須	このデータセットのテキストに使用されるデフォルトのlanguage。この設定は、GTFS利用者がデータセットの大文字小文字の規則やその他のlanguage設定を選択するのに役立ちます。このファイル translations.txtは、テキストをデフォルト言語以外の言語に翻訳する必要がある場合に使用できます。 原文が複数の言語で書かれているデータセットでは、デフォルトのlanguage多言語である場合があります。そのような場合は feed_langフィールドには、ISO 639-2規格で定義されたlanguageコード mulで，データセットで使われているlanguage翻訳を提供しなければならない． translations.txt.データセットの原文がすべて同じlanguageである場合は，. mulを使うべきではない． 例例：スイスのような多言語国家のデータセットで，原文が stops.stop_nameフィールドには、異なる言語の停留所名が入力されている。各停留所名は、その停留所の地理的な位置で支配的なlanguage書かれている。 Genèveフランス語圏のジュネーブの場合 Zürichドイツ語圏のチューリッヒ、そして Biel/BienneBiel/Bienneのような2ヶ国語圏の都市の場合．データセット feed_langでなければならない mulと翻訳を translations.txtドイツ語で Genf, Zürichそして Bielフランス語で Genève, Zurichそして Bienneイタリア語 Ginevra, Zurigoそして Biennaそして英語で。 Geneva, Zurichそして Biel/Bienne.
default_lang	languageコード	オプション	データ利用者がライダーのlanguage知らない場合に使用されるべきlanguage定義します。多くの場合、次のようになります。 en(英語)となります。
feed_start_date	日付	オプション	このデータセットは、1日の始まりから終わりまで、サービスに関する完全で信頼できるSchedule情報を提供します。 feed_start_date日の始まりから終わりまで feed_end_date日間です。利用できない場合は、両日とも空欄にすることができます。日付は feed_end_dateの前にあってはならない。 feed_start_date日付の両方が指定された場合、日付はその前にあってはならない。データセット提供者は、この期間外にもScheduleデータを提供して、将来的にサービスが提供される可能性があることを知らせることが推奨されるが、データセット利用者はその非オーソリティな状態に留意して扱わなければならない。もし feed_start_dateまたは feed_end_dateで定義された有効な暦日を越えている場合、データセットは明示的に calendar.txtそして calendar_dates.txtで定義された有効暦日を超える場合、データセットは、その範囲内の日付にはサービスがないことを明示的に主張していることになる。 feed_start_dateまたは feed_end_dateの範囲内だが、有効な暦日には含まれない日付については、 サービスがないことを明示的に表明している。
feed_end_date	日付	オプション	(上記参照)
feed_version	テキスト	オプション	そのGTFSデータセットの現在のバージョンを示す文字列。GTFSアプリケーションは、この値を表示することで、データセット発行者が最新のデータセットが取り込まれたかどうかを判断しやすくすることができます。
feed_contact_email	電子メール	オプション	GTFSデータセットやデータ公開に関する連絡用の電子メールアドレス。 feed_contact_emailは、GTFS利用するアプリケーションの技術的な連絡先です。を通じて、顧客サービスの連絡先情報を提供する。 agency.txt.
feed_contact_url	URL	オプション	GTFSデータセットおよびデータ公開に関する連絡先、ウェブフォーム、サポートデスク、その他のツールのURL。 feed_contact_urlは、GTFSするアプリケーションのための技術的な連絡先です。顧客サービスの連絡先情報を agency.txt.

attributions.txt

ファイル：オプション

主キーattribution_id)

データセットに適用される属性を定義するファイルである．

フィールド名	タイプ	プレゼンス	説明
attribution_id	一意のID	オプション	データセットまたはそのサブセットに対するアトリビューションを識別する。これは主に翻訳に有用である．
agency_id	外部ID参照 agency.agency_id	オプション	属性が適用される機関。 もし、1つの agency_id, route_idまたは trip_id1 つの属性が定義されている場合、他の属性は空である必要があります。どれも指定されていない場合、属性はデータセット全体に適用されます。
route_id	外部ID参照 routes.route_id	オプション	と同じように機能する agency_idただし、属性がルートに適用される場合は除きます。複数のアトリビュートを同じルートに適用することができます。
trip_id	外部ID参照 trips.trip_id	オプション	と同じように機能する agency_id属性がトリップに適用される場合を除きます。同じトリップに複数のアトリビュートを適用することができます。
organization_name	テキスト	必須	データセットが帰属する組織の名前です。
is_producer	Enum	オプション	組織の役割はプロデューサーです。有効なオプションは次のとおりです。 0または空 - 組織は、この役割を持っていません。 1- 組織は、この役割を持っています。 少なくとも1つのフィールド is_producer, is_operatorまたは is_authorityに設定する必要があります。 1.
is_operator	Enum	オプション	と同じように機能する is_producer組織の役割がオペレータである場合を除く。
is_authority	列挙型	オプション	と同じように機能する is_producer組織の役割が権限である場合を除く。
attribution_url	URL	オプション	組織の URL。
attribution_email	電子メール	オプション	組織の電子メール
attribution_phone	電話番号	任意	組織の電話番号