コア GTFS
ここでご紹介するのは、General Transit Feed Specification（GTFS）で公共交通機関の運行サービスを記述する際の実践的な推奨事項（ベスト プラクティス）です。具体的には、GTFS ベスト プラクティス ワーキング グループのメンバーの経験と、各アプリケーションの実践的な GTFS 推奨事項をまとめたものです。作成の経緯について詳しくは、よくある質問をご覧ください。
ドキュメント構成
実践的な推奨事項は、主に次の 3 つのセクションに分かれています。
- データセットの公開と全般に関する推奨事項: これらの推奨事項は、GTFS データセットの全体構成と、GTFS データセットの公開方法に関するものです。
- ファイル別の実践的な推奨事項: 推奨事項がファイルと GTFS のフィールド別に分類されているため、GTFS の公式リファレンスと簡単に照らし合わせることができます。
- ケース別の実践的な推奨事項: 環状ルートなどの特定のケースでは、複数のファイルとフィールドで推奨事項の適用が必要になる場合があります。このセクションには、そうしたケースの推奨事項がまとめられています。
よくある質問
GTFS ベスト プラクティスはなぜ重要なのですか？
GTFS ベスト プラクティスの目的は次のとおりです。
- エンドユーザーが公共交通機関のアプリを使う際の利便性を高める
- 幅広いデータの相互運用を支援し、アプリケーション、プロダクト、サービスのデプロイとスケーリングを容易にする
- さまざまな応用分野で（当初対象としていた行程計画の分野を超えて）GTFS の利用を促進する
体系的な GTFS ベスト プラクティスがないと、GTFS を利用するさまざまなアプリケーションで要件と期待値が整合性のない状態で設定されるため、各アプリケーションごとに要件とデータセットが異なり相互運用性が低下してしまいます。ベスト プラクティスを公開する前は、GTFS の正しいデータ形式に関して、現在よりもさらに認識があいまいで整合性がありませんでした。
ベスト プラクティスができるまでの経緯は？作成したのは誰？
GTFS のベスト プラクティスは、GTFS に携わる 17 の組織で構成されるワーキング グループによって作られました。具体的には、アプリ プロバイダ、データ利用者、交通機関、GTFS に幅広く関わっているコンサルタントなどのグループです。このワーキング グループを招集、推進したのはロッキーマウンテン研究所です。
それぞれのベスト プラクティスはワーキング グループ メンバーの投票で決定されました。そのほとんどは全員一致で承認され、ごく一部は大多数の承認を得て決定されました。
GTFS リファレンスの変更だけでは不十分ですか？
的を射たご質問です。仕様やデータの使用方法、ニーズを調査するプロセスを経て、実際に仕様変更が生じました（GitHub の closed pull request 参照）。仕様リファレンスの修正については、ベスト プラクティスの場合よりも厳格な調査とコメントが必要になります。しかしながら、一連の明確なベスト プラクティス（推奨事項）に合意を求めるニーズもありました。
ワーキング グループでは、GTFS ベスト プラクティスの一部が最終的にコア GTFS リファレンスに含まれると見込んでいます。
ベスト プラクティスとの適合性は GTFS 検証ツールでチェックされますか？
現在のところ、すべてのベスト プラクティスとの適合性をチェックする検証ツールはありません。ただし一部のベスト プラクティスについては、さまざまな検証ツールを使って適合性をチェックできます。GTFS 検証ツールの一覧については、Testing Feeds をご覧ください。GTFS のベスト プラクティスを参照する GTFS 検証ツールを作成する場合は、gtfs@rmi.org までメールでご連絡ください。
交通機関の者ですが、ソフトウェア サービス プロバイダとベンダーに、ベスト プラクティスに準拠してもらうにはどうすればよいですか？
ご利用のベンダーやソフトウェア サービス プロバイダに、GTFS ベスト プラクティスを紹介してください。GTFS を使ったソフトウェアの開発を委託する際は、GTFS ベスト プラクティスに加え、コア仕様リファレンスも委託先に紹介することをおすすめします。
GTFS データフィードがベスト プラクティスに準拠していないとわかった場合はどうすべきですか？
そのフィードに関する連絡先を把握します。それには、feed_info.txt 内で示されている feed_contact_email か feed_contact_url のフィールドを参照するか（そのフィールドが存在する場合）、その交通機関やフィード制作者のウェブサイトで連絡先を調べます。フィード製作者と問題点を話し合う際は、この GTFS ベスト プラクティスへのリンクを伝えます。このドキュメントへのリンクをご確認ください。
ベスト プラクティスに修正や追加の提案がある場合は、どうすればよいですか？
gtfs@rmi.org にメールを送信するか、GitHub の GTFS ベスト プラクティス リポジトリで Issue かプルリクエストをオープンします。
ベスト プラクティスに関わるには？
gtfs@rmi.org にメールをお送りください。
データセットの公開と全般に関する推奨事項
| 一般的な推奨事項 |
|---|
| データセットは一般公開の恒久的な URL で公開し、ZIP ファイル名を含めます（例: www.agency.org/gtfs/gtfs.zip）。その URL ではなるべくログインせずにファイルを直接ダウンロードできるようにして、ソフトウェア アプリケーションによるダウンロードを促進します。GTFS データセットは誰でもダウンロードできるようにすることをおすすめします（それが最も一般的な実践策です）。ただし、ライセンスなどの関係で、データ プロバイダが GTFS へのアクセスを管理する必要がある場合は、API キーを使って GTFS データセットへのアクセスを管理することをおすすめします。この方法なら、自動ダウンロードが容易になります。 |
| GTFS データは繰り返し公開されるため、個々のファイルは一定の場所に置き、常に交通機関に関する最新の公式な説明を含めます。 |
データの反復処理において stop_id、route_id、agency_id の ID（ID フィールド）は可能な限り変えずに維持します。 |
1 つの GTFS データセットには、現行のサービスと今後のサービスを含めます（「結合型」データセットとも呼ばれます）。Google 乗換案内フィードツールの merge 関数を使用すると、2 つの異なる GTFS フィードを 1 つのデータセットに結合できます。
|
| フィードから古いサービス（期限切れのカレンダー）を削除します。 |
| 公開から 7 日以内にサービス変更が実施される場合は、静的な GTFS データセットではなく GTFS リアルタイム フィード（運行案内やルート更新情報）を通じて、そのサービス変更を発信してください。 |
| ウェブサーバーでホストしている GTFS データは、ファイルの変更日を正しく報告するように設定してください（Section 14.29: HTTP/1.1 - Request for Comments: 2616 を参照）。 |
ファイル別の実践的な推奨事項
このセクションでは、GTFS リファレンスに即し、ファイルとフィールド別に実践的手法を紹介します。
すべてのファイル
| フィールド名 | 推奨事項 |
|---|---|
| 大文字と小文字の併用 | 全ユーザーに表示するテキスト文字列（駅 / 停留所の名称、ルート名、行先表示など）では、大文字と小文字を併用します（大文字のみで記述しない）。なお、小文字の表示が可能なディスプレイに表示する地名については、大文字と小文字の使用について各地の慣習に従います。 |
| 例: | |
| Brighton Churchill Square | |
| Villiers-sur-Marne | |
| Market Street | |
| 略語 | 名前などのテキストでは、フィードのどこでも略語を使わないようにします（例: 「Street」の略語として「St.」を使わない）。ただし、略語で呼ばれている地名の場合は例外です（例: 「JFK 空港」）。略語があると、スクリーン リーダー ソフトウェアや音声によるユーザー インターフェースでのアクセスに問題が生じる可能性があります。ソフトウェアで完全な単語（正式名称）を適切な略語に換えて表示することはできても、略語から完全な単語に変換する場合には誤変換が起こりやすくなります。 |
agency.txt
| フィールド名 | 推奨事項 |
|---|---|
agency_id |
フィード内に交通機関が 1 つしかない場合でも含めます（routes.txt と fare_attributes.txt に agency_id を含める推奨事項もご覧ください）。 |
agency_lang |
含めます。 |
agency_phone |
含めます。ただし、カスタマー サービスの電話番号が存在しない場合は例外です。 |
agency_email |
含めます。ただし、カスタマー サービスのメールアドレスが存在しない場合は例外です。 |
agency_fare_url |
含めます。ただし、その交通機関の運賃が完全無料の場合は例外です。 |
例:
- 複数の小さなバス会社がバスを運行していますが、運行スケジュールの管理や乗車券の販売を担当している大きな会社が存在し、利用者からはその会社がバスの運行主体であると認識されているとします。この場合、フィードでは大きな会社の方を交通機関として設定します。実際には小さなバス運行会社ごとにデータが分かれていても、フィードでは 1 つの交通機関だけを設定します。
- フィードを作成する会社が乗車券販売のポータルを運営していますが、実際には複数の会社がバスを運行し、利用者もそれを認識しているとします。この場合は、実際にバスを運行している複数の会社を交通機関としてそれぞれフィードに設定します。
stops.txt
| フィールド名 | 推奨事項 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
stop_id |
物理的に異なる場所にある駅 / 停留所（指定のルート上で車両が停止するよう指定された正確な場所で、標識や雨風シェルター、街角に設置された公共情報などで識別されている場所か、プラットホームやバスターミナルなど（互いに隣接している場合でも）異なる乗車施設を表している場所）には、それぞれに異なる stop_id を設定します。 |
||||||||
stop_id は内部 ID であり、乗客に示すためのものではありません。 |
|||||||||
同じ駅や停車所の stop_id は、データの反復処理を通じて同一に維持します（データセットの公開と全般に関する推奨事項を参照）。 |
|||||||||
stop_name |
stop_name は、その交通機関の駅 / 停留所、乗車施設の公的名称（例: 時刻表に印刷されている名称、オンラインで公開されている名称、その場所に掲示されている名称）と一致させます。 |
||||||||
| 駅 / 停留所に公的名称がない場合は、そのフィード内で一貫した命名規則を使って名称を付けます。 | |||||||||
| 駅 / 停留所の名称では略語を使わないようにします。ただし、略称で呼ばれることが一般的な場合は例外です。詳しくは、すべてのファイルの略語（#2）をご覧ください。 | |||||||||
| 駅 / 停留所の名称では、各地の慣習に従って大文字と小文字を併用します（全ユーザーに表示するテキスト項目に関する推奨事項を踏襲）。 | |||||||||
デフォルトでは、stop_name に「駅」や「ステーション」などの一般的な単語や冗長な単語は含めません。ただし、次のような特例では使用が認められます。
|
|||||||||
stop_lat、stop_lon |
駅 / 停留所の場所はできるだけ正確に表します。駅 / 停留所の場所は、実際の場所との誤差が 4 m 以内になるようにします。 | ||||||||
| 駅 / 停留所の場所は、乗客が使う歩行者用通路のすぐ近く（その道路の適切な側）に設置します。 | |||||||||
1 つの駅 / 停留所が異なるデータフィードで共有されている場合（例: 2 つの交通機関がまったく同じ駅 / 停留所や乗車施設を使っている場合）は、その駅 / 停留所でまったく同じ stop_lat と stop_lon を使用して、共有されていることを示します。 |
|||||||||
stop_code |
駅 / 停留所について乗客に表示する番号や短い識別子がある場合は、GTFS に stop_code を含めます。 |
||||||||
parent_station、location_type |
複数の乗車施設（モードによっては、バス停車帯、プラットホーム、ワーフ、ゲートなどとも呼ばれます）を有する駅やターミナルも少なくありません。そうした場合は、駅 / 停留所と乗車施設（付属施設とも呼ばれます）に加え、その両者の関係も説明してください。
|
||||||||
駅と付属施設の名称については、乗客によく知られており、駅 / 停留所と乗車施設（バスベイ、プラットフォーム、埠頭、ゲートなど）を乗客が識別しやすい名称を指定します。
|
routes.txt
| フィールド名 | 推奨事項 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
agency_id |
agency.txt で定義されている場合は、必ず含めてください |
||||||||||||||||||||
route_short_name |
サービスの短い名称がある場合は、route_short_name を含めます。そのサービスの通称として乗客によく知られた、12 文字以下の名称にしてください。 |
||||||||||||||||||||
route_long_name |
仕様リファレンスでの定義: この名称は一般的に 長い名前の種類（例）:
|
||||||||||||||||||||
route_long_name に route_short_name の名称を含めてはいけません。 |
|||||||||||||||||||||
route_long_name には正式名称を含め、サービス ID も含めます。例:
|
|||||||||||||||||||||
route_id |
特定の名称を持つルート上のすべての行程は、同じ route_id を参照する必要があります。
|
||||||||||||||||||||
1 つのルートグループに個別の名称を持つ支線（例: 1A と 1B）が含まれる場合は、ルートが分岐するケースの推奨事項に従って route_short_name と route_long_name を決定してください。 |
|||||||||||||||||||||
route_color、route_text_color |
標識、印刷物、オンラインで顧客に知らせる情報と一貫性を持たせます（他の場所にない情報は含めません）。 | ||||||||||||||||||||
trips.txt
- 環状ルート（特殊ケース）: 環状ルートは、始点と終点が同じ駅 / 停留所になるケースです。始点と終点が異なる 2 つの駅 / 停留所になる線形ルートとは対照的です。環状ルートは、次の実践策に従って記述してください。環状ルートのケースを確認
- 投げ縄ルート（特殊ケース）: 投げ縄ルートは線形と環状の混合ルートで、そのルートの一部分に限って車両が環状に運行されます。投げ縄ルートは、次の実践策に従って記述してください。投げ縄ルートのケースを確認
| フィールド名 | 推奨事項 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trip_headsign |
trip_headsign や stop_headsign フィールドにルート名（route_short_name や route_long_name と同じ値）は指定しないでください。 |
||||||||||||||
車両の行先表示（1 つのルート内の複数の行程名を区別する用途などに使われる表示）に表示される目的地や行先、行程名などのテキストを含めます。車両に表示されるルート情報との整合性が優先されます（GTFS データセットで提供される行先表示の目的地よりも優先されます）。その他の情報は、この第一目的地と矛盾しない場合に限って含めます。行程の途中で行先表示が変わる場合は、stop_times.stop_headsign で trip_headsign をオーバーライドします。次に、いくつかの考え得るケースについて推奨事項を示します。 |
|||||||||||||||
例:
|
|||||||||||||||
| 行先表示の先頭に「目的地」や「行き先」は使いません。 | |||||||||||||||
direction_id |
ルート上の行程が逆方向の場合は、direction_id フィールドで値 0 と 1 を使って、方向の異なる行程を区別します。 |
||||||||||||||
値 0 と 1 は、データセット内で同じ意味合いで使用します。例:
|
stop_times.txt
ループルート: ループルートでは、stop_times について特別な配慮が必要です（ループルートのケースを参照）。
| フィールド名 | 推奨事項 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
pickup_type、drop_off_type |
乗車サービスのない非収益（回送）ルートは、すべての stop_times 行の pickup_type と drop_off_type に値 1 を設定します。 |
||||||||||||
収益ルートにおいて、運行状況の内部モニタリング用の「計時ポイント」や、乗客が乗降できない車庫などの場所には、pickup_type = 1（乗車不可）と drop_off_type = 1（降車不可）を指定します。 |
|||||||||||||
timepoint |
timepoint フィールドを指定し、stop_times として厳守に努めるべき時刻（timepoint=1）か、それ以外の到着予定時刻（timepoint=0）かを指定します。 |
||||||||||||
arrival_time、departure_time |
arrival_time フィールドと departure_time フィールドでは、時刻の値（計時ポイント間の拘束力のない予定時刻や補間時刻など）をできる限り指定します |
||||||||||||
stop_headsign |
次のケースで、「南行き」は駅の標識で使われていないため誤解を招きます。 |
||||||||||||
|
|||||||||||||
|
|||||||||||||
| shape_dist_traveled | shape_dist_traveled は、循環やインラインのあるルート（車両が 1 つの行程内の同じ順路の一部を横断または再走行するルート）で必ず指定します。shapes.shape_dist_traveled の推奨事項をご確認ください。 |
||||||||||||
calendar.txt
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | calendar_dates.txt には、限定数の例外的な運行スケジュールだけを含めます。通常の運行スケジュールは、calendar.txt を使って設定します。 |
calendar.service_name フィールド（GTFS 仕様にはないフィールド）も含めると、GTFS が人間の目にもわかりやすくなります。 |
calendar_dates.txt
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | calendar_dates.txt には、限定数の例外的な運行スケジュールだけを含めます。通常の運行スケジュールは、calendar.txt を使って設定します。 |
calendar.service_name フィールド（GTFS 仕様にはないフィールド）も含めると、GTFS が人間の目にもわかりやすくなります。 |
fare_attributes.txt
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | agency_id が agency.txt に含まれている場合は、そのフィールドを fare_attributes.txt にも含めます。 |
| 運賃体系を厳密にモデル化できない場合は、混乱を避けるため、このフィールドは空白にします。 | |
運賃（fare_attributes.txt と fare_rules.txt）を含め、できるだけ厳密にモデル化します。運賃を厳密にモデル化できない特殊なケースでは、相対的に安い運賃ではなく高い運賃を表示して、運賃不足での乗車が起きないようにします。運賃のほとんどを厳密にモデル化できない場合は、フィードに運賃情報を含めないでください。 |
fare_rules.txt
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | agency_id が agency.txt に含まれている場合は、そのフィールドを fare_attributes.txt にも含めます。 |
| 運賃体系を厳密にモデル化できない場合は、混乱を避けるため、このフィールドは空白にします。 | |
運賃（fare_attributes.txt と fare_rules.txt）を含め、できるだけ厳密にモデル化します。運賃を厳密にモデル化できない特殊なケースでは、相対的に安い運賃ではなく高い運賃を表示して、運賃不足での乗車が起きないようにします。運賃のほとんどを厳密にモデル化できない場合は、フィードに運賃情報を含めないでください。 |
shapes.txt
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | 共通する順路（例: ルート 1 とルート 2 の行程内に同じ運行区間があるケース）については、その共通部分の順路が完全に一致しているのが理想的です。それにより、質の高い路線図を作りやすくなります。 |
| 順路は、運行する右側車線のセンターラインに合わせます。指定レーンがない場合には車道のセンターライン、指定レーンがある場合には車両が進む車道の脇のセンターラインになります。 順路は、駅 / 停留所、プラットホーム、乗車場所まで急カーブを描くものではいけません。 |
|
shape_dist_traveled |
順路に循環やインライン（車両が 1 つの行程内で部分的に同じ順路を交差または重複運行）が含まれる場合は、 
車両が行程でルートの同じ順路を横断または再走行する場合は、 |
shape_dist_traveled フィールドでは、stop_times.txt ファイル内の駅 / 停留所がそれぞれのシェイプにどのように適合するか正確に指定できます。shape_dist_traveled フィールドで一般的に使われる値は、シェイプの開始ポイントから車両が走行した距離（走行距離計の測定値のようなイメージ）です。
|
feed_info.txt
feed_info.txt を含め、次のフィールドをすべて指定します。
| フィールド名 | 推奨事項 |
|---|---|
feed_start_date、feed_end_date |
含めます |
feed_version |
含めます |
feed_contact_email、feed_contact_url |
少なくとも 1 つ指定します |
frequencies.txt
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | frequencies.txt が参照するルートでは、実際の到着時刻は無視されます。定期運行ルートで重要なのは、駅 / 停留所間の区間走行に要する時間のみだからです。人間の目にもわかりやすくするため、frequencies.txt で参照するルート最初の到着時刻は 00:00:00（arrival_time の最初の値）にすることをおすすめします。 |
block_id |
定期運行ルートで指定可能です。 |
transfers.txt
transfers.transfer_type は、GTFS で定義された 4 つの値のいずれかになります。ここに示す transfer_type の定義は GTFS 仕様から引用したもので、実践的な推奨事項も付加しています。
| フィールド名 | 推奨事項 |
|---|---|
transfer_type |
上位のオプション（例: 複数の施設がある乗換センター、隣接または直結する乗車施設やプラットホームがある駅 / 停留所）を含む複数の乗換手段がある場合は、おすすめの乗換地点を指定します。 |
データ利用者は、それぞれ独自のアルゴリズムを使用して、この期間に必要な時間を計算します。この値が不十分な場合、またはデータ利用者が考慮しなかった条件が他にある場合は、 |
|
駅 / 停留所間の走行時間が増える障害物などの要素がある場合は、最小乗換時間を指定します。 |
|
物理的な障壁が原因で乗り換えが不可能な場合や、道路の横断が困難であったり歩行者通路が途切れていたりして安全確保ができないか困難な場合に、この値を指定します。 |
|
| ルート間で座席指定（ブロック）の乗り換えが認められる場合は、到着ルートの最後の駅 / 停留所が出発ルートの最初の駅 / 停留所と同じである必要があります。 |
ケース別の実践的な推奨事項
このセクションでは、特殊ケースのファイルとフィールドについて説明します。
環状ルート
環状ルートでは、車両の始点と終点の場所が同じになります（交通センターや乗換センターの場合もあります）。通常、車両は継続的に運行し、車両がルートを継続的に循環している間、乗客はずっと乗車したままでいられます。
そのため、車両の進行方向を乗客に示すために、行先表示の推奨事項を適用してください。
進行方向の変更を示すには、stop_times.txt ファイルで stop_headsigns を指定します。stop_headsign は、所定の駅 / 停留所から出発するルートの方向を表します。ルートの各駅 / 停留所に stop_headsigns を追加すると、行程に沿って行先表示の情報を変更できます。
2 つの終点を往復するルート（同じバスが往復するルートなど）は、stop_times.txt ファイルで循環ルートとして定義せず、進行方向が異なる 2 つのルートに分けて定義します。
循環ルートの設定例:
各駅 / 停留所で行先表示が変わる循環ルート:
Trip_id |
arrival_time |
departure_time |
stop_id |
stop_sequence |
stop_headsign |
|---|---|---|---|---|---|
trip_1 |
06:10:00 |
06:10:00 |
stop_A |
1 |
"B" |
trip_1 |
06:15:00 |
06:15:00 |
stop_B |
2 |
"C" |
trip_1 |
06:20:00 |
06:20:00 |
stop_C |
3 |
"D" |
trip_1 |
06:25:00 |
06:25:00 |
stop_D |
4 |
"E" |
trip_1 |
06:30:00 |
06:30:00 |
stop_E |
5 |
"A" |
trip_1 |
06:35:00 |
06:35:00 |
stop_A |
6 |
"" |
行先表示が 2 種類ある循環ルート:
Trip_id |
arrival_time |
departure_time |
stop_id |
stop_sequence |
stop_headsign |
|---|---|---|---|---|---|
trip_1 |
06:10:00 |
06:10:00 |
stop_A |
1 |
"outbound" |
trip_1 |
06:15:00 |
06:15:00 |
stop_B |
2 |
"outbound" |
trip_1 |
06:20:00 |
06:20:00 |
stop_C |
3 |
"outbound" |
trip_1 |
06:25:00 |
06:25:00 |
stop_D |
4 |
"inbound" |
trip_1 |
06:30:00 |
06:30:00 |
stop_E |
5 |
"inbound" |
trip_1 |
06:35:00 |
06:35:00 |
stop_F |
6 |
"inbound" |
trip_1 |
06:40:00 |
06:40:00 |
stop_A |
7 |
"" |
| フィールド名 | 推奨事項 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
環状ルートの全体を 1 つの行程でモデル化します。 | |||||||||||||||
stop_times.stop_id |
環状の行程について、最初 / 最後となる駅 / 停留所を stop_times.txt で 2 回指定します。下の例をご覧ください。環状ルートは、その環状ルート全体を走行しない最初と最後の行程を含む場合が少なくありません。そうした行程も含めてください。
|
|||||||||||||||
trips.direction_id |
環状ルートを逆方向（時計回りと反時計回り）で運行する場合は、direction_id の値を 0 か 1 に指定します。 |
|||||||||||||||
trips.block_id |
環状ルートを連続走行する行程は、同じ block_id で示します。 |
投げ縄ルート
投げ縄ルートは、環状ルートと方向ルートが組み合わさったルートです。
- A から B への直線区間
- B から B への環状区間
- B から A への直線区間
| 例: |
|---|
| 地下鉄ルート（シカゴ） |
| 郊外からダウンタウンへのバスルート（セント アルバート、エドモントン） |
| CTA ブラウンライン（CTA のウェブサイトと TransitFeeds） |
| フィールド名 | 推奨事項 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
trips.trip_id |
「車両の往復ルート」全体（上記の図を参照）は、A から B、B から B、B から A に戻る行程で構成されています。車両の往復ルート全体は次の方法で表せます。
trips.txt 内で trip_id に単一の値 / レコードを指定trips.txt 内で trip_id に複数の値 / レコードを指定し、block_id で連続走行を示唆 |
||||||||||
stop_times.stop_headsign |
AB 区間の駅 / 停留所は、どちらの進行方向でも通過します。stop_headsign は進行方向を区別するのに役立つため、これらのルートには stop_headsign を指定することをおすすめします。
|
||||||||||
trip.trip_headsign |
行程の行先表示は、行程の全体的な説明（時刻表などに示されるような説明）にします。例: 「リンデンからリンデン（循環経由）」（シカゴの例）、「A から A（B 経由）」（一般的な例） |
支線
一部のルートには支線が含まれる場合もあります。支線についても順路と駅 / 停留所の推奨項目は共通ですが、支線に特有の順路と駅 / 停留所のセクションもあります。本線と支線の関係は、ルート名、行先表示、行程の略称で示すことができます。以下のガイドラインを参考にしてください。
| フィールド名 | 推奨事項 |
|---|---|
| すべてのフィールド | 支線に名前を付ける際は、乗客用の他の情報資料の名称に即すことをおすすめします。次に 2 つのケースについて説明と例を示します。 |
時刻表と道路上の看板で 2 つの異なる名称が使われているルート（例: 1A と 1B）であれば、GTFS で route_short_name や route_long_name のフィールドを使って、これを表示します。例: GoDurham Transit のルート 2、2A、2B では、ルートの大部分で順路が共通ですが、いくつかの面では順路が異なっています。
|
|
交通機関からの情報で、支線の名称がルート名と同じになっている場合には、trips.trip_headsign や stop_times.stop_headsign、trips.trip_short_name のフィールドを使用します。たとえば、GoTriangle のルート 300 は時間帯によって走行する経路が異なります。通勤や帰宅のピーク時間帯には標準ルートに支線を追加し、都市圏での通勤や帰宅に対応しています。 |
このドキュメントについて
目的
GTFS のベスト プラクティスは次の目的で運用されています。
- 交通機関データの相互運用が進むようにサポートする
- エンドユーザーが公共交通機関のアプリを使う際の利便性を高める
- アプリケーション、プロダクト、サービスのデプロイとスケーリングをソフトウェア デベロッパーにとって容易にする
- さまざまな応用分野で（当初対象としていた行程計画の分野を超えて）GTFS の利用を促進する
公開されている GTFS ベスト プラクティスに提案や修正を行う方法
GTFS のアプリケーションとベスト プラクティスは進化するため、このドキュメントは随時修正が必要となります。このドキュメントの修正を提案するには、GTFS ベスト プラクティス GitHub リポジトリで pull リクエストを開き、修正内容を提案してください。また、コメントがございましたら specifications@mobilitydata.org までメールでお送りください。
このドキュメントへのリンク
GTFS データの正しい構成ガイダンスをフィード提供者に伝える本ドキュメントへのリンクを設定してください。個々の推奨事項ごとにアンカーリンクがあります。ページ内アンカーリンクの URL を取得するには、対象の推奨事項をクリックしてください。
GTFS を利用するアプリケーションにおいて、GTFS データの取り扱いについて、ここに記載されていない要件や推奨事項がある場合は、一般的なベスト プラクティスを補充するドキュメントとして、それらの要件や推奨事項を公開することをおすすめします。
GTFS ベスト プラクティス ワーキング グループ
GTFS ベスト プラクティス ワーキング グループは、GTFS データに関する一般的な推奨事項と期待値を定義する目的で 2016～2017 年に Rocky Mountain Institute によって招集されました。このグループは、公共交通機関、GTFS を利用するアプリケーションのデベロッパー、コンサルタント、学術機関からのメンバーで構成されました。具体的には、次のメンバーが含まれていました。
- Cambridge Systematics
- Capital Metro
- Center for Urban Transportation Research at University of South Florida
- Conveyal
- IBI Group
- Mapzen
- Microsoft
- Moovel
- Oregon Department of Transportation（オレゴン運輸省）
- Swiftly
- Transit
- Trillium
- TriMet
- World Bank
現在、このドキュメントは MobilityData International Organization によって維持されています。