GTFS の要件

パートナーは、すべての標準仕様に加えて、以下の仕様を満たす GTFS フィードを提供する必要があります。このフィードは、パートナーが表示するすべての宿泊プランに対応している必要があります。この情報を提供することで、運行スケジュールとルートの情報が Google に表示されます。パートナーは、指定されたフィードに含まれる旅行プランの一部またはすべてについて、料金と空室状況に関する追加情報を公開することを選択できます。

デフォルトの要件

静的 GTFS リファレンス - すべてのデフォルト要件が適用されます。

GTFS のベスト プラクティス - 必要と思われるベスト プラクティスに従ってください。

GTFS フィードのアップロード - 以下の手順に沿って GTFS フィードをアップロードしてください。

更新: フィードをアップロードしたら、こちらで説明する手順で更新できます。通常、これらのフィードの更新が完全に反映されるまでに 2 ～ 3 日かかることがあります。

追加の要件

範囲

  • 1 つの GTFS フィードで 1 つの国または国の一部を対象にする必要があります。国境を越えるルートは、大陸全体の個別のフィードで指定する必要があります。GTFS フィードの対象が国以外の地域の場合は、Travel Transport Team にお問い合わせください。
    • GTFS の zip ファイル内のファイルは 4 GB 未満にする必要があります。通常、このサイズより大きいファイルは不適切な方法の兆候です。たとえば、frequencies.txt や同様の機能が提供する圧縮オプションを無視していることが考えられます。これにより、処理中に問題が発生する可能性があります。4 GB を超えるファイルが必要な場合は、Travel Transport チーム（ Transport-help@google.com）までご連絡ください。
    • GTFS フィード内で運行される今後の運行期間全体のデータは、GTFS データが更新されるたびに提供する必要があります。異なる期間でサービスをセグメント化することはできません。
  • 1 つの演算子のすべての日付を 1 つのフィードに含める必要があります。

翻訳

  • 翻訳は translations.txt で提供できますが、以下の国で必要となります。
    • ユーザーへの情報は、ラテン文字以外のさまざまな文字や文字で提供される場合があります。
    • ユーザーへの情報は、複数の言語で提供される場合や、エンティティがこれらの言語で異なる名前を使用する場合（例: ブリュッセル/ブリュッセル/ブリュッセル）
  • 翻訳対象のエンティティ
    • 交通機関、停車地、経路の名前
    • ルート/停車地の行先表示

経路名、ルートの略称、行先表示

  • すべてのルートで、trips.txt（ルート全体で行先案内が一定の場合）または stop_times.txt（ルートの途中で行先案内が変わる場合）のいずれかで行先案内を指定する必要があります。
  • 行先案内は、ユーザーが現場で確認できる情報と一致している必要があります。 たとえば、車両や看板に表示される行先表示。
  • 経路に名前がある場合は、routes.txt で long_name として指定する必要があります。
  • 経路と両方向のすべてのルートに適用される特定の番号または英数字の ID を持つ経路は、routes.txt で short_name として指定する必要があります。
  • 経路内のルートに個別の識別子（列車番号など）がある場合、そのような識別子はルートの略称として指定する必要があります。
  • ルート番号や名前のない長距離サービスの場合、ルート名の選択が問題になります。このような状況の一般的なガイドラインでは、ルート名と行先案内を組み合わせることで、ユーザーが車両を一義的に識別できるようにすることをおすすめします。たとえば、運行会社の名前を経路名として使用し、ルートの目的地（車両に表示されている場合）をルートの行先表示として使用できます。

例

  • ムンバイ発バラナシ行きのインド鉄道カマヤニ急行列車 11071。注: 11071 の番号は、ムンバイからワーラーナシを結ぶ特定の列車の旅程であり、ルートそのものではありません。
    • routes.txt:
      • short_name: <空白>
      • long_name: Kamayani Express
    • routes.txt:
      • trip_short_name: 11071
      • 行先表示: バラナシ
  • ブエノスアイレス発コルドバ行きのシュバリエ バスのバス。注: このサービスを運行しているバスには、特定の経路名は表示されません。代わりに、交通機関の名称と行き先が目立つように表示されます。このルートには、同じ交通機関や同じ経路で運行される他のルートと区別する個別の番号や ID がありません。その場合、交通機関名（agencies.txt 内）とルートの long_name（routes.txt 内）の両方に「Chevallier」を使用できます。目的地は行先案内に使用し、trip_short_name は空のままにしてください。
    • routes.txt:
      • short_name: <空白>
      • long_name: Chevallier
    • routes.txt:
      • trip_short_name: <空白>
      • 行先表示: コルドバ

停車時刻

arrival_time と departure_time はどちらも stop_times.txt で指定する必要があります。

ルート構成

  • 複数の都市や地域をカバーする長距離ルートは、セグメンテーションなしでエンドツーエンドで提供する必要があります（[A->B,A->C,B->C] ではなく A->B->C）。ここで A、B、C は都市エリアです。たとえば、ブエノスアイレスからコルドバへの長距離バスの場合は、「ブエノスアイレス - ロサリオ」、「ブエノスアイレス - コルドバ」、「ロザリオ - コルドバ」という 3 つの旅程ではなく、これら 3 つの都市を経由する便となります。
  • データ提供者が正しいルート構成に関する情報を取得できない場合は、状況に応じて分割された都市から都市へのルートが提供されます。このような都市から都市へのルートに、都市（都市地域）内に複数の乗車地点または降車地点がある場合、停車地間の分割は許可されません。すべての乗車地点とすべての降車地点を 1 つのルートに含めてください。

駅の構造

複数のプラットホームまたは区画がある大規模な駅の場合、駅とホームの関係をフィードで指定し、stops.txt の platform_code フィールドで特定する必要があります。特定の湾やプラットフォームを一貫して発着する車両は、GTFS フィードでその湾またはプラットフォームにリンクする必要があります。出発の日時や出発時刻に出発プラットホームや発着バスのプラットフォームが変わる場合は、その情報を GTFS リアルタイム フィードで提供できます。

駅または停留所の場所

  • 複数のプラットホームまたは入口がある大規模な駅の場合、駅の場所は最も目立つ歩行者の入口の場所（駅に建物や構造物がある場合）または乗客の待機エリアの場所（屋外ステーションの場合）に設定する必要があります。
  • 道路脇の小さな停車地の場合、特定できる場合は、停車地の位置をバスポールの場所に設定する必要があります。特定のバスのポールが特定できない場合は、道路の正しい側に、車両が停車する道路沿いの実際の場所（理想的には 10 m 以内）の近くに配置してください。

その他の GTFS 拡張機能

パートナー API を実装して価格や在庫状況の情報を表示するパートナーにのみ必要です。

Google 乗換案内の乗車券販売の拡張機能

  • パートナーは、GTFS-Ticketing 拡張機能のサブセットである Google 乗換案内の乗車券販売の拡張機能の仕様を実装する必要があります。
  • チケット ID には以下の要件が適用されます。
    • チケット販売 ID は不変である（適切な理由から頻繁には変更できない）必要があります。チケット発行 ID が変更される場合は、下位互換性が必要です（少なくとも 1 週間）。
    • API リクエストで SegmentKey のパラメータを決定するには、ticketing_trip_id（trips.txt 内）と ticketing_stop_id（ticketing_identifiers.txt 内）が必須です。stop_sequence のフォールバックは安定していないため、サポートされていません。

GTFS-Fares v1

静的 GTFS リファレンスでは、オプションの fare_attributes.txt ファイルと fare_rules.txt ファイルを指定しています。パートナーがパートナー API と統合している場合は、これらのファイルを提供しないでください。