コンテンツにスキップ

GTFS Scheduleベストプラクティス

これらは、General Transit Feed Specification(GTFSにおいて公共交通機関のサービスを記述するための推奨事項です。これらのプラクティスは、GTFS Best Practices working groupベストプラクティスワーキンググループメンバーの経験と、application-specific GTFS practice recommendationsプラクティスの推奨事項から総合的に構成されたものです。

背景については、Frequently Asked Questions（よくある質問）を参照してください。

文書構成

プラクティスは、4つの主要なセクションで構成されています。

  • データセット出版と一般的な実践 GTFSデータセットの全体的な構成と、GTFSデータセットの公開方法に関する実践事項です。
  • __ファイル__別推奨事項：推奨事項は、GTFSファイルおよびフィールドごとに整理されており、GTFS公式リファレンスへのマッピングを容易にします。
  • __ケース__別推奨事項：ケース別推奨事項。ループルートなどの特定のケースでは、複数のファイルやフィールドにまたがって実務を適用する必要がある場合があります。そのような推奨事項をこのセクションに集約した。

データセットパブリッシングと一般的な操作方法

  • データセットは、ZIPファイル名を含む公開された恒久的なURLで公開されるべきである。(例:GTFS/GTFS.zip">GTFS。理想的には，消費するソフトウェア・アプリケーションによるダウンロードを容易にするため，ファイルにアクセスするためにログインを必要とせず，直接ダウンロードできるURLであるべきである．GTFSデータセットはオープンにダウンロードできるようにすることが推奨されるが（最も一般的な方法）、データ提供者がライセンスその他の理由でGTFSアクセスを制御する必要がある場合は、APIキーを用いてGTFSデータセットへのアクセスを制御し、自動ダウンロードを容易にすることが推奨される。
  • GTFSデータは繰り返し発行されるため、安定した場所にある1つのファイルには、常に輸送機関（または複数の機関）の最新の公式サービス説明が含まれています。
  • 可能な限り、stop_id、route_id、agency_idの持続的な識別子（id フィールド）を、データのイテレーションを越えて維持する。
  • 1つのGTFSデータセットには、現在のサービスと今後のサービスを含める必要がある（「マージ」データセットと呼ばれることもある）。Google transitfeedツールのマージ機能を使えば、2つの異なるGTFSフィードからマージされたデータセットを作成することができる。
  • いつでも、公開されているGTFSデータセットは、少なくとも今後7日間、理想的には運行会社がそのSchedule継続して運行されると確信できる限り、有効であるべきです。
  • 可能であれば、GTFSデータセットは、少なくとも今後30日間のサービスをカバーするものであるべきです。
  • フィードから古いサービス（期限切れのカレンダー）を削除する。
  • サービスの変更が7日以内に実施される場合は、静的なGTFSデータセットではなく、GTFS-Realtime/">GTFSフィード（サービス勧告またはトリップアップデート）を通じてこのサービス変更を表現する。
  • GTFSデータをホストするウェブサーバーは、ファイルの修正日を正しく報告するように設定されるべきである（14.29項のHTTP/1.1 - Request for Comments 2616を参照のこと）。

ファイルごとに分類された練習のすすめ

このセクションでは、GTFSリファレンスに合わせ、ファイルおよびフィールドごとにプラクティスを整理しています。

すべてのファイル

フィールド名 おすすめ
大文字と小文字の混在 顧客向けのテキスト文字列（停留所名、路線名、ヘッドサインを含む）はすべて、小文字を表示できるディスプレイ上の地名の大文字表記に関する地域の慣例に従って、大文字小文字の混在（ALL CAPSではない）を使用する必要があります。
例
Brighton Churchill Square
Villiers-sur-Marne
Market Street
省略形 フィード全体を通して、名称やその他のテキストに略語を使用することは避けてください (例: St. は Street の略語)。省略形は、スクリーンリーダーソフトウェアや音声ユーザーインターフェイスによるアクセシビリティに問題がある場合があります。消費者向けソフトウェアは、フルワードから略語に確実に変換して表示するように設計できますが、略語からフルワードへの変換は、エラーのリスクが高くなりがちです。

agency.txt

フィールド名 おすすめ
agency_id フィードに含まれるエージェンシーが1つしかない場合でも、含める必要があります。(を含めることを推奨します。 agency_idで routes.txtと fare_attributes.txt)
agency_phone そのような顧客サービスの電話が存在しない場合を除き、含める必要があります。
agency_email そのような顧客サービスの電子メールが存在しない場合を除き、含める必要があります。
agency_fare_url 代理店が完全に運賃無料でない限り、含まれる必要があります。

例

  • バスサービスは、いくつかの小さなバス会社によって運営されています。しかし、スケジュールや発券を担当し、ユーザーの視点からバスサービスに責任を持つ、1つの大きな機関があります。たとえデータが小規模なバス事業者によって内部的に分割されていたとしても、フィードに定義される代理店は1つだけであるべきです。

  • フィードプロバイダはチケッティングポータルを運営していますが、実際にサービスを運営する代理店はさまざまで、ユーザーが責任者であることを認識しています。実際にサービスを運営している代理店を、フィード内の代理店として定義する必要があります。

stops.txt

フィールド名 おすすめ
stop_name 公開されている stop 名がない場合は、 フィード全体で一貫した stop 名の命名規則に従ってください。
デフォルトでは stop_nameには、"Station" や "Stop" といった一般的な単語や冗長な単語を含んではいけません。
  • 実際に名前の一部になっている場合（Union Station、Central Station
  • を含む場合 stop_nameが一般的すぎる場合（都市名である場合など）。"Station"、"Terminal "などで意味を明確にする。
stop_lat& stop_lon 停車位置はできるだけ正確であること。停車位置の誤差は __を超えないこと。__実際の停止位置と比較した場合、4メートル以内の誤差であること。
停止位置は、乗客が乗車する歩行者通路のすぐ近くに配置されるべきである（例：道路の正しい側）。
停留所の位置が別々のデータフィードで共有されている場合（2つの機関がまったく同じ停留所／乗降施設を使用している場合）、両方の停留所でまったく同じものを使用することによって、その停留所が共有されていることを示す。 stop_latと stop_lonを使用してください。
parent_station& location_type 多くの駅やターミナルには、複数の搭乗設備がある（モードによっては、バスベイ、プラットフォーム、埠頭、ゲート、または他の用語と呼ばれる場合がある）。このような場合、飼料生産者は駅、乗降施設（子駅とも呼ばれる）、およびそれらの関係を記述する必要があります。
  • 駅またはターミナルは、以下のレコードとして定義されなければならない。 stops.txtと location_type = 1.
  • 各乗降施設は、"stop "フィールドで定義されなければならない。 location_type = 0.その parent_stationフィールドを参照する必要がある。 stop_idを参照する必要がある。
駅や子駅の名称は、乗降客に認知され、乗降客が駅や乗り場（バスベイ、プラットフォーム、埠頭、ゲートなど）を特定するのに役立つ名称を設定すること。
親駅名子停留所名
シカゴ・ユニオン駅シカゴ・ユニオン駅 19番線
サンフランシスコ・フェリー・ビルディング・ターミナルサンフランシスコ・フェリー・ビルディング・ターミナル ゲートE
ダウンタウントランジットセンターダウンタウントランジットセンターBay B

routes.txt

フィールド名 おすすめ
agency_id フィードにエージェンシーが1つしかない場合でも、含める必要があります。(agency.txtとfare_attributes.txt にagency_idを含めることを推奨します)
route_short_name 含む route_short_nameは、簡単なサービス名がある場合に含めます。これは、一般に知られているサービスの旅客名で、12文字以内である必要があります。
route_long_name 仕様書参照による定義。 この名前は、一般に、ルート名よりも説明的である。 ルート名に比べてよりわかりやすく、ルートの目的地や停車駅を含むことが多い。少なくともどちらか一方を指定する必要があります。 ルート名または ルート名の少なくとも一方を指定する必要があり、適切であれば両方を指定することもできます。ルートが長い名前を持っていない場合は、"Specification "を指定してください。 ルート名を指定し、このフィールドの値として空文字列を使用してください。
長い名前の種類は以下の通りです。
一次交通路またはコリドー
ルート名形式機関名
"N"/"Judah"（ユダルート名/
ルート名(long_name)		Muniサンフランシスコ市内
「6」/「MLキングJrブルバードルート_ショートネーム/
ルート名(long_name)		トライメットポートランド市内
PHP?nompdf=m6">「6"/"ネイション-エトワール"ルート_short_name/
ルート名(route_long_name)		RATPフランス・パリの放送局。
「U2"-"パンコウ-ルールベン"ルート_ショートネーム-
ルート名		BVGドイツ ベルリンにて
サービス内容
"ハートウェルエリアシャトル"
route_long_nameを含んではならない。 route_short_name.
を入力する場合は、サービス名を含む完全な名称を入力します。 route_long_name.例
サービス名おすすめ例
"MAX ライトレール"
オレゴン州ポートランドのトライメット（TriMet)		る。 名前は、ブランド (MAX) と具体的な路線名称を含む必要があります。"MAX レッドライン" "MAX ブルーライン"
"ラピッドライド"
ABQライド（ニューメキシコ州アルバカーキ市		その ルート名は、ブランド（Rapid Ride）と具体的な路線指定を含む必要があります。"ラピッドライド・レッドライン"
"ラピッドライド・ブルーライン"
route_id 指定されたルート上のすべての旅行は、同じものを参照する必要があります。 route_id.
  • ルートの異なる方向は、異なる値に分離されるべきではない。 route_id値である。
  • 路線の異なる運行期間は、異なる値に分離すべきではない。 route_id例えば、"Downtown AM "と "Downtown AM "で異なるレコードを作成しないこと。 routes.txtに異なるレコードを作成しないでください。）
    		•
    ルートグループに、異なる名前のブランチ（例：1A と 1B）がある場合、ルート ブランチを決定する場合 route_short_nameと route_long_name.
    route_color& route_text_color サインや印刷物、オンラインの顧客情報と一致する必要がある（そのため、他の場所に存在しない場合は含まれない）。

    trips.txt

    • __ループルートの特例をご覧ください。__ループルートは、旅行が同じ停留所で始まり、終わる場合であり、2つの異なる終点を持つ直線ルートとは対照的である。ループルートは、特定の慣例に従って記述する必要があります。ループ経路のケースを参照。
    • __ラッソルートのケースを参照してください。__ラッソルートは、リニアルートとループルートのハイブリッドで、車両がルートの一部分のみをループで走行するものです。ラッソルートは、特定の手法に従って記述する必要がある。ラッソルートの事例を参照。
    フィールド名 推奨
    trip_headsign ルート名を提供しないこと（マッチング route_short_nameと route_long_name)を提供しない。 trip_headsignまたは stop_headsignフィールドを
    車両のヘッドサインが示す目的地、方向、その他のトリップ指定テキストを含む必要があり、ルート内のトリップを区別するために使用されます。GTFSデータセットに含まれるヘッドサインの決定にあたっては、車両に表示されている方向情報との整合性を第一の目標とし、優先的に考慮する。他の情報は、この主要な目標を損なわない場合にのみ含めるべきである。旅行中にヘッドサインが変更された場合は、オーバーライドしてください。 trip_headsignと stop_times.stop_headsign.以下は、いくつかの可能性のあるケースに対する推奨事項です。
    ルートの説明推奨
    2A.目的地のみ例："Transit Center"、"Portland City Center"、"Jantzen Beach" > 終点の目的地を記入する。
    2B.目的地とウェイポイント Highgate via Charing Cross " 経由。 車両がウェイポイントを通過した後、乗客に表示するヘッドサインが削除された場合は、次の方法でヘッドサインを更新してください。 stop_times.stop_headsignを上書きする。を使って、更新されたヘッドサインを設定してください。
    2C.ローカルな停車駅のある地域名目的地の市区町村内に複数の停留所がある場合、目的地の市区町村に到着した時点で ストップ_タイムズ.ストップ_ヘッドサインを使用することで、目的地の都市に到着します。
    2D.方面のみ北行き」、「南行き」、「時計回り」等と表記する。
    2E.目的地を含む方向例：「 南回りサンノゼ行き」>2F.
    2F.目的地とウェイポイントを含む方向 北行きチャリングクロス経由ハイゲート行き」）>。
    ヘッドサインの冒頭に「To」または「Towards」という単語を使用しないでください。
    direction_id データセット全体で一貫して 0 と 1 の値を使用する。
    • 1 = Outbound on the Red route の場合、1 = Outbound on the Green route の場合。
    • もし1 = ルートXの北行きなら、1 = ルートYの北行き
    • 1 = ルート X で時計回りの場合、1 = ルート Y で時計回りの場合

    stop_times.txt

    ループルート。ループルート：ループルートは、特別なstop_times の考慮が必要です。(参照：ループルートの場合）

    フィールド名 推奨
    pickup_type& drop_off_type 旅客サービスを提供しない非レヴェニュー（デッドヘッド）トリップは、次のようにマークする必要があります。 pickup_typeと drop_off_typeの値 1すべての stop_timesの行に表示する必要があります。
    レベニュートリップの場合、運行状況を監視するための内部的な「タイミングポイント」や、車庫など旅客が乗車できない場所には pickup_type = 1(ピックアップ不可)と drop_off_type = 1(no drop off available)と表記する。
    timepoint timepointフィールドを提供する必要がある。これは、オペレータが厳密に遵守しようとするstop_times(timepoint=1)と、その他の停止時間は推定であること(timepoint=0)を指定する。
    arrival_time& departure_time arrival_timeそして departure_timeフィールドは、可能な限り時間の値を指定する必要があり、タイムポイント間の拘束力のない推定時間や補間時間を含みます。
    stop_headsign 一般に、ヘッドサインの値は駅にある標識に対応する必要がある。

    以下のケースでは、「Southbound」は駅のサインで使用されていないため、顧客に誤解を与えることになる。
    NYCの場合、南行き2号の場合。
    について stop_times.txtの列があります。使用 stop_headsign値
    マンハッタンに到着するまでマンハッタンとブルックリン
    ダウンタウンに到達するまでダウンタウンとブルックリン
    ブルックリンに到着するまでブルックリン
    ブルックリンに到着後ブルックリン (New Lots Av)
    ボストンでは、レッドライン南行きは、Braintree分岐のため。
    について stop_times.txt行使用する stop_headsignの値です。
    ダウンタウンに到達するまでBraintree行き
    ダウンタウンに到着後Braintree
    Downtown到着後ブレーンツリー方面への往路
    shape_dist_traveled shape_dist_traveledは、ループまたはインライン（車両が一回の走行でアライメントの同じ部分を横断または走行する）のあるルートについて提供する必要があります。を参照すること。 shapes.shape_dist_traveledを推奨します。

    calendar.txt

    フィールド名 推奨
    すべてのフィールド を含む calendar.service_nameフィールドを含めることで，GTFS可読性を高めることもできるが，これは本仕様では採用されていない．

    calendar_dates.txt

    フィールド名 推奨
    すべてのフィールド フィールドを含めることで calendar.service_nameフィールドを含めることで、GTFS可読性を高めることもできますが、これは仕様では採用されていません。

    fare_attributes.txt

    フィールド名 推奨
    agency_id フィードにエージェンシーが1つしかない場合でも、含める必要があります。(agency.txtとroutes.txt にagency_idを含めることを推奨します)
    運賃システムを正確にモデル化できない場合は、さらなる混乱を避けるため、空白とする。
    運賃を含む(Include fares)fare_attributes.txtそして fare_rules.txtを含め、可能な限り正確にモデル化する。運賃を正確にモデル化できない場合、顧客が不十分な運賃で乗車しようとしないように、運賃は安価ではなく、高価に表現する必要があります。運賃の大部分を正確にモデル化できない場合は、フィードに運賃情報を含めないようにします。

    fare_rules.txt

    フィールド名 推奨
    すべてのフィールド 運賃システムを正確にモデル化できない場合は、さらなる混乱を避けるため、空白のままにしておく。
    運賃を含める (fare_attributes.txtそして fare_rules.txt)、可能な限り正確にモデル化する。運賃を正確にモデル化できない場合は、運賃を安く表示するのではなく、高く表示することで、運賃不足で乗車しようとすることがないようにします。運賃の大半を正確にモデル化できない場合は、フィードに運賃情報を含めないようにします。

    shapes.txt

    フィールド名 推奨
    すべてのフィールド 理想的には、共有されているアライメント（ルート1とルート2が同じセグメントの道路や軌道で運行されている場合など）については、アライメントの共有部分が正確に一致する必要があります。これは、高品質の輸送用地図作成を促進するのに役立つ。
    アラインメントは、車両が走行する道路の中心線に沿うべきである。これは、車線がない場合は道路の中心線、または車両の進行方向にある道路側の中心線のいずれかになる可能性があります。

    また、縁石やプラットフォーム、乗り場の位置がずれるような配置になってはならない。
    shape_dist_traveled の両方で提供されなければならない。 shapes.txtそして stop_times.txtアライメントにループやインラインがある場合（車両は一回の走行でアライメントの同じ部分を横切ったり、走行したりする）。
    車両が走行中にルート・アライメントを引き返したり横断したりする場合。 形状_dist_traveledを明確にすることが重要である。 shapes.txtの記録と対応させることが重要である。 stop_times.txt.
    は shape_dist_traveledフィールドを使用することで、代理店は、ファイル内の停留所がそれぞれの形状にどのように適合するかを正確に指定することができる。 stop_times.txtファイル内の停留所がそれぞれの形状に適合するように正確に指定することができる。フィールドに使用する一般的な値は shape_dist_traveledフィールドに使用する一般的な値は、車両によって移動された形状の先頭からの距離である（オドメーターの読みのようなものを考えてほしい）。
  • ルートアラインメント(in shapes.txtは、トリップの目的地である停留所から100m以内でなければならない。
  • 位置合わせを簡略化し shapes.txtが余計な点を含まないように整列を簡略化する（つまり、直線上の余分な点を削除する。）
    		•

    frequencies.txt

    フィールド名 推奨
    すべてのフィールド で参照されるトリップでは、実際の停車時間は無視されます。 frequencies.txt頻度ベースのトリップでは、停留所間の移動時間間隔のみが重要である。で参照されるトリップの最初の停車時間は、わかりやすさや読みやすさのために、 00:00:00:00から始まることが推奨される。 frequencies.txtで参照されるトリップの最初の停止時間は 00:00:00 で始まることを推奨する（最初の arrival_time00:00:00の値)。
    block_id 頻度ベースのトリップのために提供することができます。

    transfers.txt

    transfers.transfer_typeには、 GTFS で定義されている 4 つの値のいずれかを指定することができる。これらのtransfer_typeの定義は、以下のGTFS仕様から引用し、斜体で、追加の実践的な推奨事項を記載しています。

    フィールド名 推奨
    transfer_type 0 または（空）。ルート間の推奨乗り換えポイントである。
    より優れたオプション（例：追加の設備を持つトランジットセンター、または隣接または接続された乗降施設/プラットフォームを持つ駅）を含む複数の乗換機会がある場合、推奨の乗換ポイントを指定する。
    1: これは2つのルート間の時間指定された乗り換えポイントである。出発する車両は到着する車両を待ち、乗客がルート間を移動するのに十分な時間があることが期待される。
    この乗り換えタイプは、確実に乗り換えを行うために必要な間隔をオーバーライドします。 例として、Googleマップでは、乗客が安全に乗り換えを行うために3分必要であると想定しています。他のアプリケーションでは、他のデフォルトを想定している場合があります。
    2: この乗り換えは、到着と出発の間に、確実に接続するための最小限の時間を必要とします。乗り換えに必要な時間は、以下のように指定されます。 min_transfer_time.
    障害物などがあり、停留所間の移動時間が長くなる場合は、最小の乗り換え時間を指定する。
    3：この地点では路線間の乗り換えができない。
    物理的な障壁があり乗り換えができない場合、または道路横断が困難であったり、歩行者ネットワークのギャップにより乗り換えが危険または複雑になる場合、この値を指定する。
    トリップ間の座席内（ブロック）移動が可能な場合、到着トリップの最後の停留所は、出発トリップの最初の停留所と同じである必要がある。

    feed_info.txt

    feed_info.txttxtは、以下のすべてのフィールドを含む必要があります。

    フィールド名 推奨
    feed_start_date& feed_end_date 含めるべき
    feed_version 含める必要があります。
    feed_contact_email& feed_contact_url 少なくとも1つは用意すること。

    ケース別実践推奨事項

    このセクションでは、ファイルやフィールドに影響を与える特定のケースについて説明します。

    ループルート

    ループルートでは、車両の移動は同じ場所（時にはトランジットまたは乗換センター）で始まり、終了します。車両は通常、連続的に運行し、車両がループを続ける間、乗客は乗車したままにしておくことができます。

    したがって、車両の進行方向を乗客に示すために、ヘッドサインの推奨事項を適用する必要があります。

    進行方向が変わることを示すために、stop_stop_times.txtファイルにstop_headsignsを用意する。stop_headsignは、定義された停留所から出発するトリップの方向を記述する。トリップの各停留所にstop_headsignsを追加することで、トリップの途中でヘッドサインの情報を変更することができる。

    2つの終点間を運行するルート（同じバスが往復する場合など）には、stop_times.txt1つの循環トリップを定義しないでください。代わりに、トリップを2つの別々の旅行方向に分割してください。

    サーキュラートリップのモデル化例

    • 停留所ごとにヘッドマークを変更する周遊型トリップ
    trip_id 到着時刻 出発時刻 stop_id stop_sequence ストップサイン
    トリップ_1 06:10:00 06:10:00 ストップ_A 1 "B"
    トリップ_1 06:15:00 06:15:00 ストップ_B 2 "C"
    トリップ_1 06:20:00 06:20:00 停止_C 3 "D"
    トリップ_1 06:25:00 06:25:00 停止_D 4 "E"
    トリップ_1 06:30:00 06:30:00 ストップ_E 5 "A"
    トリップ_1 06:35:00 06:35:00 ストップ_A 6 ""
    • 2つのヘッドマークを持つ周回旅行
    trip_id 到着時刻 出発時刻 stop_id stop_sequence ストップサイン（Stop_Headsign
    トリップ_1 06:10:00 06:10:00 ストップ_A 1 "アウトバウンド"
    トリップ_1 06:15:00 06:15:00 ストップ_B 2 "アウトバウンド"
    トリップ_1 06:20:00 06:20:00 ストップ_C 3 "アウトバウンド"
    トリップ_1 06:25:00 06:25:00 ストップ_D 4 "インバウンド"
    トリップ_1 06:30:00 06:30:00 ストップ_E 5 "インバウンド"
    トリップ_1 06:35:00 06:35:00 ストップ_F 6 "インバウンド"
    トリップ_1 06:40:00 06:40:00 ストップ_A 7 ""
    フィールド名 推奨
    trips.trip_id ループの完全な往復を1回のトリップでモデル化する。
    stop_times.stop_id には、最初の停車駅と最後の停車駅を2回含める。 stop_times.txtに2回含まれる。以下の例。多くの場合、ループルートは、ループ全体を移動しない最初と最後のトリップを含むことがあります。これらのトリップも含めてください。
    trip_idstop_idstop_sequence
    90001011
    90001022
    90001033
    90001014
    trips.direction_id ループが反対方向に動作する場合（すなわち、時計回りと反時計回り）、次のように指定します。 direction_idとして 0または 1.
    trips.block_id 連続したループトリップが同じであることを示す block_id.

    ラッソルート

    ラッソルートは、ループルートとディレクショナルルートの側面を組み合わせたものです。

    例：例
    地下鉄ルート (シカゴ)
    バス 郊外から市街地へのルート(セント・アルバートまたは エドモントン)
    CTAブラウンライン (CTAウェブサイトそして トランジットフィード)
    フィールド名 推奨
    trips.trip_id 車両往復」の全容（上図参照 上図は、AからB、BからAへの往復で構成され、車両全体の往復は次のように表される。
  • A 単一 trip_idの値/記録 trips.txt
  • 複数 trip_idの値/記録 trips.txtで表し、連続走行は block_id.
    		•
    stop_times.stop_headsign A-B区間の停留所は両方向に通過することになる。 stop_headsignを設けると、進行方向の区別がつきやすくなる。そのため stop_headsignが推奨される。
    例：例：例
    "B経由のA"
    "A"
    シカゴ交通局（Chicago Transit Authority）の パープルライン
    "南行きループ経由"
    "ループ経由の北行き"
    "リンデンへの北行き"
    エドモントン・トランジット・サービスのバス路線、ここでは 39
    "ラザフォード"
    "センチュリーパーク"
    trip.trip_headsign トリップのヘッドサインは、スケジュールに表示されるような、トリップのグローバルな説明であるべきです。Linden to Linden via Loop」（シカゴの例）、「A to A via B」（一般的な例）などが考えられます。

    分岐

    路線によっては、分岐がある場合があります。路線と停留所は、これらのブランチ間で共有されますが、それぞれが個別の停留所と路線区間を提供します。分岐の関係は、ルート名、ヘッドサイン、トリップショートネームで示すことができ、以下のガイドラインに従います。

    フィールド名 レコメンデーション
    すべてのフィールド 分岐路線の名称は、他の旅客案内資料に準ずることが望ましい。以下、2つのケースについて説明・例示する。
    時刻表や路面表示で、1Aと1Bの2つのルートがある場合、GTFSその旨を route_short_nameと route_long_nameフィールドを使用して、そのように表示します。例GoDurham トランジット ルート 2、2A、および 2Bは、ルートの大部分で共通の線形を共有しているが、いくつかの異なる側面で異なっている。
    • ルート2はコアサービスで、ほとんどの時間帯に運行しています。
    • ルート2は、メインストリートの夜間、日曜日、祝日の逸脱を含む。
    • ルート2Aと2Bは月曜から土曜の日中時間帯に運行しています。
    • ルート2Bは、共有アライメントパスの逸脱で追加の停留所を提供します。
    機関提供の情報により、支店が同じ名前のルートとして記述されている場合は、以下の trips.trip_headsign, stop_times.stop_headsignとか trips.trip_short_nameフィールドを使用する。例ゴートライアングル ルート300は、時間帯によって異なる場所に移動します。通勤のピーク時には、入退社する労働者に対応するために、標準ルートに脚が追加されます。

    よくある質問（FAQ）

    なぜGTFSベストプラクティスが重要なのですか？

    GTFSベストプラクティスの目的は以下の通りです。

    • 公共交通機関アプリにおけるエンドユーザーの顧客体験を向上させること
    • 広範なデータの相互運用性をサポートし、ソフトウェア開発者によるアプリケーション、製品、およびサービスの展開と拡張を容易にする。
    • 様々なアプリケーション・カテゴリーにおけるGTFS利用を促進する（当初の旅行計画に焦点を当てたものから）。

    GTFSベストプラクティスが調整されていない場合、GTFSさまざまなアプリケーションが協調しない方法で要件と期待を確立する可能性があり、その結果、要件が発散し、アプリケーション固有のデータセットと相互運用性が低くなる可能性があります。ベストプラクティスが発表される以前は、何が正しいGTFSデータを構成するかについて、より大きな曖昧さと意見の相違がありました。

    どのように開発されたのか？誰が作成したのか?

    これらのベストプラクティスは、アプリプロバイダーやデータ消費者、交通機関プロバイダー、GTFS広く関与しているコンサルタントなど、GTFS関わる17の組織からなるワーキンググループによって作成されました。このワーキンググループは、Rocky Mountain Instituteによって召集され、進行役を務めました。

    ワーキンググループのメンバーが、それぞれのベストプラクティスについて投票を行いました。ほとんどのベストプラクティスは、全会一致で承認された。少数派ではあるが、大多数の組織でベストプラクティスが承認された。

    なぜ、GTFS参照を変更しないのですか?

    いい質問ですね。仕様書、データの使用方法、ニーズを検討する過程で、実際に仕様書にいくつかの変更が加えられました（GitHubのクローズドプルリクエストを参照）。仕様書の参照修正は、ベストプラクティスよりも高い水準で精査され、コメントされます。しかし、ベストプラクティスの明確な推奨事項を合意する必要があった。

    ワーキンググループは、いくつかのGTFSベストプラクティスが、最終的にコアGTFSリファレンスの一部になることを期待しています。

    GTFSバリデータツールは、これらのベストプラクティスへの適合性をチェックするのでしょうか?

    現在、すべてのベストプラクティスへの準拠をチェックするバリデータツールはない。さまざまなバリデータツールが、これらのベストプラクティスの一部への準拠を確認 している。GTFSバリデータツールの一覧は、GTFS-validators">GTFSバリデータを参照すること。これらのベストプラクティスを参照するGTFSバリデータツールを作成した場合は、specifications@mobilitydata.org にメールを送ってください。

    私は交通機関の代表者です。ソフトウェア・サービス・プロバイダーやベンダーがこれらのベスト・プラクティスに従うようにするには、どのようなステップを踏めばよいでしょうか?

    ベンダーまたはソフトウェアサービスプロバイダに、これらのベストプラクティスを参照してください。GTFSベストプラクティスのURLと、GTFSソフトウェアの調達におけるコア・スペック・リファレンスを参照することをお勧めします。

    GTFSデータフィードがこれらのベストプラクティスに適合していないことに気づいた場合、どうしたらよいですか?

    フィードの連絡先を特定します。feed_info.txtにfeed_contact_email や feed_contact_urlフィールドがある場合はそれを使用するか、 輸送機関またはフィード製作者のウェブサイトで連絡先情報を確認します。飼料メーカーに問題を伝える際には、議論されている特定のGTFSベストプラクティスにリンクします。(「この文書へのリンク」参照).

    ベストプラクティスに対する修正/追加を提案したい。どのようにすればよいですか？

    specifications@mobilitydata.orgにメールを送るか、GTFS-best-practices">GitHubGTFS Best Practices レポで課題またはプルリクエストを開いてください。

    どのようにすればよいですか？

    電子メールspecifications@mobilitydata.org.

    この文書について

    目的

    GTFSベストプラクティスを維持する目的は、以下のとおりです。

    • 交通データの相互運用性の向上
    • 公共交通アプリケーションにおけるエンドユーザーの顧客体験を向上させる。
    • ソフトウェア開発者によるアプリケーション、製品、およびサービスの展開と拡張を容易にする。
    • 様々なアプリケーション・カテゴリーにおけるGTFS利用を促進する(トリッププランニングに当初焦点を当てた場合を除く)

    公開されたGTFSベストプラクティスの提案または修正方法

    GTFSアプリケーションと実践は進化するため、この文書は適宜修正される必要があります。この文書の修正を提案するには、GTFS-best-practices"> GTFSベストプラクティスのGTFS-best-practices">GitHubリポジトリでプルリクエストを開き、変更を支持することです。コメントは、specifications@mobilitydata.org までメールでお送りください。

    この文書へのリンク

    GTFSデータを正しく形成するためのガイダンスをフィード・プロデューサーに提供するために、ここにリンクしてください。個々の推奨事項にはアンカーリンクがあります。推奨事項をクリックすると、ページ内アンカー・リンクのURLが表示されます。

    GTFSアプリケーションが、ここに記載されていないGTFSデータの運用に関する要件や推奨事項を作成した場合、これらの共通のベストプラクティスを補足するために、それらの要件や推奨事項を記載した文書を公開することが推奨されます。

    GTFSベストプラクティスワーキンググループ

    GTFSベストプラクティスワーキンググループは、2016-17年にロッキーマウンテン研究所によって招集され、公共交通機関プロバイダー、GTFSアプリケーションの開発者、コンサルタント、学術団体で構成され、GTFSデータに関する共通のプラクティスと期待を定義しました。このワーキンググループのメンバーは次の通りです。

    現在、このドキュメントはMobilityDataによって管理されています。