GTFS のベスト プラクティス

コア 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_emailfeed_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_idroute_idagency_id の ID(ID フィールド)は可能な限り変えずに維持します。
1 つの GTFS データセットには、現行のサービスと今後のサービスを含めます(「結合型」データセットとも呼ばれます)。Google 乗換案内フィードツールの merge 関数を使用すると、2 つの異なる GTFS フィードを 1 つのデータセットに結合できます。
  • どのような場合でも、公開する GTFS データセットは少なくとも 7 日間は有効である必要があります。できれば、運行者がそのスケジュールを確実に継続できる範囲で有効なデータセットであれば理想的です。
  • 可能であれば、GTFS データセットはその後少なくとも 30 日間は続くサービスを対象としてください。
フィードから古いサービス(期限切れのカレンダー)を削除します。
公開から 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.txtfare_attributes.txtagency_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_name があまりに一般的で(都市名と区別がつかない場合など)、「駅」や「ターミナル」などの単語を付けることで意味が明確になる場合。
stop_latstop_lon 駅 / 停留所の場所はできるだけ正確に表します。駅 / 停留所の場所は、実際の場所との誤差が 4 m 以内になるようにします。
駅 / 停留所の場所は、乗客が使う歩行者用通路のすぐ近く(その道路の適切な側)に設置します。
1 つの駅 / 停留所が異なるデータフィードで共有されている場合(例: 2 つの交通機関がまったく同じ駅 / 停留所や乗車施設を使っている場合)は、その駅 / 停留所でまったく同じ stop_latstop_lon を使用して、共有されていることを示します。
stop_code 駅 / 停留所について乗客に表示する番号や短い識別子がある場合は、GTFS に stop_code を含めます。
parent_stationlocation_type 複数の乗車施設(モードによっては、バス停車帯、プラットホーム、ワーフ、ゲートなどとも呼ばれます)を有する駅やターミナルも少なくありません。そうした場合は、駅 / 停留所と乗車施設(付属施設とも呼ばれます)に加え、その両者の関係も説明してください。
  • 駅 / 停留所やターミナルは、location_type = 1 と指定して stops.txt のレコードとして定義してください。
  • 各乗車施設は、location_type = 0 を指定して駅 / 停留所として定義してください。parent_station フィールドでは、その乗車施設を含む駅の stop_id を参照します。
駅と付属施設の名称については、乗客によく知られており、駅 / 停留所と乗車施設(バスベイ、プラットフォーム、埠頭、ゲートなど)を乗客が識別しやすい名称を指定します。
親の駅 / 停留所の名称 付属施設の名称
シカゴ ユニオン駅 シカゴ ユニオン駅プラットフォーム 19
サンフランシスコ フェリー ビルターミナル サンフランシスコ フェリー ビルターミナル ゲート E
ダウンタウン交通センター ダウンタウン交通センターベイ B

routes.txt

フィールド名 推奨事項
agency_id agency.txt で定義されている場合は、必ず含めてください
route_short_name サービスの短い名称がある場合は、route_short_name を含めます。そのサービスの通称として乗客によく知られた、12 文字以下の名称にしてください。
route_long_name 仕様リファレンスでの定義: この名称は一般的に route_short_name よりも詳しく、多くの場合、そのルートの目的地や駅 / 停留所の名称を含みます。少なくとも route_short_nameroute_long_name の 1 つを指定し、妥当な場合は両方を指定します。ルートに長い名称がない場合は route_short_name を指定し、このフィールドの値として空の文字列を指定します。

長い名前の種類(例):

メインの経路や路線
ルート名 種類 交通機関
「N」/「Judah」 route_short_name /
route_long_name
Muni、サンフランシスコ
「6」/「ML King Jr Blvd」 route_short_name /
route_long_name
TriMet、ポートランド(オレゴン州)
「6」/「ネイション - エトワール」 route_short_name /
route_long_name
RATP、パリ(フランス)
「U2」/「パンコウ - ルーレーベン」 route_short_name /
route_long_name
BVG、ベルリン(ドイツ)
運行サービスの説明
「ハートウェル地域のシャトル便」
route_long_nameroute_short_name の名称を含めてはいけません。
route_long_name には正式名称を含め、サービス ID も含めます。例:
サービス ID 推奨事項
「MAX 路面電車」
TriMet、ポートランド(オレゴン州)
route_long_name には、ブランド名(MAX)と具体的なルート名を含めます。 「MAX レッドライン」
「MAX ブルーライン」
「Rapid Ride」
ABQ Ride、アルバカーキ(ニューメキシコ州)
route_long_name には、ブランド名(Rapid Ride)と具体的なルート名を含めます。 「Rapid Ride レッドライン」
「Rapid Ride ブルーライン」
route_id 特定の名称を持つルート上のすべての行程は、同じ route_id を参照する必要があります。
  • 同じルートで進行方向が異なる場合、route_id の値は別々にしないでください。
  • 同じルート内で運行範囲が異なる場合、route_id の値は別々にしないでください(例: 「ダウンタウン: 午前」の運行と「ダウンタウン: 午後」の運行について、routes.txt に別々のレコードを作成しないでください)。
1 つのルートグループに個別の名称を持つ支線(例: 1A と 1B)が含まれる場合は、ルートが分岐するケースの推奨事項に従って route_short_nameroute_long_name を決定してください。
route_colorroute_text_color 標識、印刷物、オンラインで顧客に知らせる情報と一貫性を持たせます(他の場所にない情報は含めません)。

trips.txt

  • 環状ルート(特殊ケース): 環状ルートは、始点と終点が同じ駅 / 停留所になるケースです。始点と終点が異なる 2 つの駅 / 停留所になる線形ルートとは対照的です。環状ルートは、次の実践策に従って記述してください。環状ルートのケースを確認
  • 投げ縄ルート(特殊ケース): 投げ縄ルートは線形と環状の混合ルートで、そのルートの一部分に限って車両が環状に運行されます。投げ縄ルートは、次の実践策に従って記述してください。投げ縄ルートのケースを確認
フィールド名 推奨事項
trip_headsign trip_headsignstop_headsign フィールドにルート名(route_short_nameroute_long_name と同じ値)は指定しないでください。
車両の行先表示(1 つのルート内の複数の行程名を区別する用途などに使われる表示)に表示される目的地や行先、行程名などのテキストを含めます。車両に表示されるルート情報との整合性が優先されます(GTFS データセットで提供される行先表示の目的地よりも優先されます)。その他の情報は、この第一目的地と矛盾しない場合に限って含めます。行程の途中で行先表示が変わる場合は、stop_times.stop_headsigntrip_headsign をオーバーライドします。次に、いくつかの考え得るケースについて推奨事項を示します。
例:
ルートの説明 推奨事項
2A. 行先のみ 終点を指定します(例: 「乗換センター」、「ポートランド シティー センター」、「ジャンセン ビーチ」)
2B. 行先と地点 <地点> 経由 <行先>(例: 「チャリングクロス経由ハイゲート」)。行先表示から地点を削除する場合は、そうした地点を車両が通過した後に、stop_times.stop_headsign を使って新たな行先表示を設定して乗客に示します。
2C. ローカルな駅 / 停留所がある地域の地名 行先の市内や特別区内に複数の駅 / 停留所がある場合は、車両がその区域に入ってから stop_times.stop_headsign を使用します。
2D. 方向のみ 方向を示す単語(例: 「北回り」、「インバウンド」、「時計回り」)を使って表します。
2E. 方向と行先 <終点の名称> - <方向>(例: サンノゼ - 南回り)
2F. 方向、目的地、地点 <waypoint> 経由 <destination> - <direction>(「チャリングクロス経由ハイゲート - 北回り」。
行先表示の先頭に「目的地」や「行き先」は使いません。
direction_id ルート上の行程が逆方向の場合は、direction_id フィールドで値 01 を使って、方向の異なる行程を区別します。
01 は、データセット内で同じ意味合いで使用します。例:
  • 1 = レッドルートのアウトバウンド」なら、「1 = グリーンルートのアウトバウンド」
  • 1 = ルート X の北回り」なら、「1 = ルート Y の北回り」
  • 1 = ルート X の時計回り」なら、「1 = ルート Y の時計回り」

stop_times.txt

ループルート: ループルートでは、stop_times について特別な配慮が必要です(ループルートのケースを参照)。

フィールド名 推奨事項
pickup_typedrop_off_type 乗車サービスのない非収益(回送)ルートは、すべての stop_times 行の pickup_typedrop_off_type に値 1 を設定します。
収益ルートにおいて、運行状況の内部モニタリング用の「計時ポイント」や、乗客が乗降できない車庫などの場所には、pickup_type = 1(乗車不可)と drop_off_type = 1(降車不可)を指定します。
timepoint timepoint フィールドを指定し、stop_times として厳守に努めるべき時刻(timepoint=1)か、それ以外の到着予定時刻(timepoint=0)かを指定します。
arrival_timedeparture_time arrival_time フィールドと departure_time フィールドでは、時刻の値(計時ポイント間の拘束力のない予定時刻や補間時刻など)をできる限り指定します
stop_headsign

stop_headsign の値は trips.txt 内の trip_headsign をオーバーライドします。stop_headsign の値は、行程中に行先表示に表示されるテキストが変わる場合に指定します。stop_headsign の値は後続の駅 / 停留所には継承されないため、その駅 / 停留所の行先表示の変更を維持する場合は、その値を繰り返し指定する必要があります。また一般に、行先表示の値はその駅 / 停留所内の標識に対応するものにします。

次のケースで、「南行き」は駅の標識で使われていないため誤解を招きます。

ニューヨーク市内で「2」が南行きの場合:
stop_times.txt 行: stop_headsign を使用:
マンハッタン到着まで Manhattan & Brooklyn
ダウンタウン到着まで Downtown & Brooklyn
ブルックリン到着まで Brooklyn
ブルックリン到着時 Brooklyn (New Lots Av)
ボストン内で、レッドライン南行き、ブレインツリー支線の場合:
stop_times.txt 行: stop_headsign を使用:
ダウンタウン到着まで Inbound to Braintree
ダウンタウン到着時 Braintree
ダウンタウン発車後 Outbound to Braintree
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_idagency.txt に含まれている場合は、そのフィールドを fare_attributes.txt にも含めます。
運賃体系を厳密にモデル化できない場合は、混乱を避けるため、このフィールドは空白にします。
運賃(fare_attributes.txtfare_rules.txt)を含め、できるだけ厳密にモデル化します。運賃を厳密にモデル化できない特殊なケースでは、相対的に安い運賃ではなく高い運賃を表示して、運賃不足での乗車が起きないようにします。運賃のほとんどを厳密にモデル化できない場合は、フィードに運賃情報を含めないでください。

fare_rules.txt

フィールド名 推奨事項
すべてのフィールド agency_idagency.txt に含まれている場合は、そのフィールドを fare_attributes.txt にも含めます。
運賃体系を厳密にモデル化できない場合は、混乱を避けるため、このフィールドは空白にします。
運賃(fare_attributes.txtfare_rules.txt)を含め、できるだけ厳密にモデル化します。運賃を厳密にモデル化できない特殊なケースでは、相対的に安い運賃ではなく高い運賃を表示して、運賃不足での乗車が起きないようにします。運賃のほとんどを厳密にモデル化できない場合は、フィードに運賃情報を含めないでください。

shapes.txt

フィールド名 推奨事項
すべてのフィールド 共通する順路(例: ルート 1 とルート 2 の行程内に同じ運行区間があるケース)については、その共通部分の順路が完全に一致しているのが理想的です。それにより、質の高い路線図を作りやすくなります。
順路は、運行する右側車線のセンターラインに合わせます。指定レーンがない場合には車道のセンターライン、指定レーンがある場合には車両が進む車道の脇のセンターラインになります。

順路は、駅 / 停留所、プラットホーム、乗車場所まで急カーブを描くものではいけません。
shape_dist_traveled

順路に循環やインライン(車両が 1 つの行程内で部分的に同じ順路を交差または重複運行)が含まれる場合は、shapes.txtstop_times.txt の両方で指定してください。

インライン ルート

車両が行程でルートの同じ順路を横断または再走行する場合は、shapes.txt で指定した一部の地点と stop_times.txt のレコードとの対応を明確にするうえで shape_dist_traveled が重要です。

shape_dist_traveled フィールドでは、stop_times.txt ファイル内の駅 / 停留所がそれぞれのシェイプにどのように適合するか正確に指定できます。shape_dist_traveled フィールドで一般的に使われる値は、シェイプの開始ポイントから車両が走行した距離(走行距離計の測定値のようなイメージ)です。
  • ルートの順路(shapes.txt で指定)には、行程内の駅 / 停留所の 100 メートル以内の地点を指定します。
  • 順路はシンプルにし、shapes.txt に余分なポイントを含めないようにします(例: 直線区間の余分なポイントは削除します。ラインの単純化の問題について説明をご覧ください)。

feed_info.txt

feed_info.txt を含め、次のフィールドをすべて指定します。

フィールド名 推奨事項
feed_start_datefeed_end_date 含めます
feed_version 含めます
feed_contact_emailfeed_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 0 または(空白): ルート間の推奨乗換地点を示します。

上位のオプション(例: 複数の施設がある乗換センター、隣接または直結する乗車施設やプラットホームがある駅 / 停留所)を含む複数の乗換手段がある場合は、おすすめの乗換地点を指定します。

1: 2 つのルート間で同期(待ち合わせ)が行われる乗換地点です。発車する車両が別の到着車両を待ち、両ルート間の乗客の乗り継ぎに十分な時間を確保します。

この乗換タイプは、確実に乗り換えるために必要な時間をオーバーライドします。たとえば、Google マップでは乗客の確実な乗り換えに必要な時間は 3 分と想定していますが、他のアプリケーションでは乗換時間のデフォルトが異なる場合があります。

2: この乗り換えには、到着から出発までの間に最小限の乗り継ぎ時間が必要です。乗り換えに必要な時間は min_transfer_time で指定します。

駅 / 停留所間の走行時間が増える障害物などの要素がある場合は、最小乗換時間を指定します。

3: この場所ではルート間の乗り換えができません。

物理的な障壁が原因で乗り換えが不可能な場合や、道路の横断が困難であったり歩行者通路が途切れていたりして安全確保ができないか困難な場合に、この値を指定します。

ルート間で座席指定(ブロック)の乗り換えが認められる場合は、到着ルートの最後の駅 / 停留所が出発ルートの最初の駅 / 停留所と同じである必要があります。

ケース別の実践的な推奨事項

このセクションでは、特殊ケースのファイルとフィールドについて説明します。

環状ルート

環状ルートでは、車両の始点と終点の場所が同じになります(交通センターや乗換センターの場合もあります)。通常、車両は継続的に運行し、車両がルートを継続的に循環している間、乗客はずっと乗車したままでいられます。

下の図は環状ルートです。車両は 1 つの行程で始点に戻ってきます。環状ルートの中には、一方向で走行するものと、両方向で走行するものがあります。
環状ルート

そのため、車両の進行方向を乗客に示すために、行先表示の推奨事項を適用してください。

進行方向の変更を示すには、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 回指定します。下の例をご覧ください。環状ルートは、その環状ルート全体を走行しない最初と最後の行程を含む場合が少なくありません。そうした行程も含めてください。
trip_id stop_id stop_sequence
9000 101 1
9000 102 2
9000 103 3
9000 101 4
trips.direction_id 環状ルートを逆方向(時計回りと反時計回り)で運行する場合は、direction_id の値を 01 に指定します。
trips.block_id 環状ルートを連続走行する行程は、同じ block_id で示します。

投げ縄ルート

投げ縄ルートは、環状ルートと方向ルートが組み合わさったルートです。

下の図は A から B を経由して A に戻る投げ縄ルートで、次の 3 つの区間があります。
  • 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 を指定することをおすすめします。
    例:
    「B 経由 A」
    「A」
    Chicago Transit Authority のパープルライン
    「サウスバウンドから循環」
    「循環経由ノースバウンド」
    「ノースバウンドからリンデン」
    エドモントン交通サービス バスライン、39
    「ラザフォード」
    「センチュリー パーク」
    trip.trip_headsign 行程の行先表示は、行程の全体的な説明(時刻表などに示されるような説明)にします。例: 「リンデンからリンデン(循環経由)」(シカゴの例)、「A から A(B 経由)」(一般的な例)

    支線

    一部のルートには支線が含まれる場合もあります。支線についても順路と駅 / 停留所の推奨項目は共通ですが、支線に特有の順路と駅 / 停留所のセクションもあります。本線と支線の関係は、ルート名、行先表示、行程の略称で示すことができます。以下のガイドラインを参考にしてください。

    下の図は、支線として考えられる 3 つの構成です。メインの順路は黒、支線の順路はゴールドです。
    支線の構成
    フィールド名 推奨事項
    すべてのフィールド 支線に名前を付ける際は、乗客用の他の情報資料の名称に即すことをおすすめします。次に 2 つのケースについて説明と例を示します。
    時刻表と道路上の看板で 2 つの異なる名称が使われているルート(例: 1A と 1B)であれば、GTFS で route_short_nameroute_long_name のフィールドを使って、これを表示します。例: GoDurham Transit のルート 2、2A、2B では、ルートの大部分で順路が共通ですが、いくつかの面では順路が異なっています。
    • ルート 2 はコアサービスで、ほとんど一日中運行しています。
    • ルート 2 はメイン ストリートに支線があり、この支線は夜間、日曜日、祝日に運行します。
    • ルート 2A と 2B は、月曜日から土曜日の日中に運行します。
    • ルート 2B は、共通の順路から外れた他の駅 / 停留所に停まります。
    交通機関からの情報で、支線の名称がルート名と同じになっている場合には、trips.trip_headsignstop_times.stop_headsigntrips.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 を利用するアプリケーションのデベロッパー、コンサルタント、学術機関からのメンバーで構成されました。具体的には、次のメンバーが含まれていました。

    現在、このドキュメントは MobilityData International Organization によって維持されています。