パートナーは、すべての標準仕様と以下の仕様を満たす GTFS フィードを提供する必要があります。このフィードには、パートナーが表示するすべての旅行プランを含める必要があります。この情報を提供することで、スケジュールとルートの情報が Google に表示されるようになります。なお、パートナーは、提供するフィードに含まれる一部またはすべての旅行プランについて、追加の料金と在庫の情報を公開することもできます。
デフォルトの要件
静的な GTFS のリファレンス \- すべてのデフォルトの要件が 適用されます。
GTFS のベスト プラクティス \- ベスト プラクティスは必須であるものとして遵守してください。
GTFS フィードのアップロード - こちらの手順に沿って GTFS フィードをアップロードしてください。
更新: フィードをアップロードした後、 こちらの手順に沿って 更新できます。通常、フィードの更新が完全に反映されるまで 2 ～ 3 日かかります。
その他の要件
スコープ
- 1 つの GTFS フィードで、1 つの国またはその一部をカバーする必要があります。
国境を越えるルートは、大陸全体のフィードで個別に提供する必要があります。GTFS フィードで 1 つの国よりも広い範囲をカバーする場合は、
Travel Transport チームにお問い合わせください。
- GTFS ZIP ファイル内のファイルのサイズは 4 GB 未満にする必要があります。
これを超えるサイズのファイルは、通常、
frequencies.txtで提供される圧縮オプションや同様の機能を無視するなど、不適切な方法で作成されていることを示しています。このようなファイルは、処理中に問題を引き起こす可能性があります。4 GB を超えるファイルが必要と思われる場合は、Travel Transport チーム（transport-help@google.com）にお問い合わせください。 - GTFS フィード内のサービスの今後の運行期間全体のデータは、GTFS データの更新ごとに提供する必要があります。サービスを期間ごとに分割することはできません。
- GTFS ZIP ファイル内のファイルのサイズは 4 GB 未満にする必要があります。
これを超えるサイズのファイルは、通常、
- 特定の事業者のすべての日付は、1 つのフィードに含める必要があります。
翻訳
- 翻訳は
translations.txtを使用して提供できます。翻訳が必要となるのは、次のような国です。- ユーザーに提供する情報が、ラテン文字以外の文字や異なる文字で提供される場合
- ユーザーに提供する情報が複数の言語で提供される場合、またはエンティティが言語によって異なる名前を使用する場合（例: ブリュッセル/ブリュッセル/ブリュッセル）
- 翻訳するエンティティ
- 交通機関 / 駅 / 停留所 / ルートの名前
- ルート / 駅 / 停留所の行先表示
ルートの名前、ルートの省略名、行先表示
- すべてのルートの行先表示を
trips.txt（ルート全体で一貫している場合）またはstop_times.txt（ルートの段階によって変わる場合）で指定する必要があります。 - 行先表示は、ユーザーが現地で確認できる情報と一致している必要があります。 たとえば、車両や案内板に表示されている行先表示などです。
- ルートに名前がある場合は、
routes.txtで long_name として指定する必要があります。 - ルートに、そのルートのすべてのルートと両方向に適用される特定の番号または英数字の識別子がある場合は、
routes.txtで short_name として指定する必要があります。 - ルート内のトリップに個別の識別子（列車の番号など）がある場合は、その識別子をトリップの省略名として指定する必要があります。
- ルート番号や名前がない長距離サービスの場合、ルート名の選択が問題になります。このような状況では、ルート名と行先表示の組み合わせによって、ユーザーが車両を明確に識別できるようにすることが一般的なガイドラインです。たとえば、運行事業者の名前をルート名として使用し、ルートの目的地（車両に表示されている場合）をルートの行先表示として使用します。
例
- インド鉄道のムンバイ発ヴァーラーナシー行きのカマヤニ エクスプレス 11071。注: 11071 は、ルート自体ではなく、ムンバイからヴァーラーナシーまでの特定の列車ルートを識別します。
- routes.txt:
- short_name: <空>
- long_name: Kamayani Express
- trips.txt:
- trip_short_name: 11071
- headsign: Varanasi
- routes.txt:
- Chevallier Bus が運行するブエノスアイレス発コルドバ行きのバス。注: このサービスを運行するバスには、特定のルート名が表示されていません。代わりに、運行事業者の名前と目的地が大きく表示されています。この特定のルートには、同じ事業者によって運行される他のルートや、同じルートを運行する他のルートと区別するための個別の番号や識別子はありません。この場合、「Chevallier」を交通機関の名前（
agencies.txt）とルートの long_name（routes.txt）の両方として使用できます。行先表示には目的地を使用する必要があります。trip_short_name は空のままにします。- routes.txt:
- short_name: <空>
- long_name: Chevallier
- trips.txt:
- trip_short_name: <空>
- headsign: Córdoba
- routes.txt:
停車時刻
stop_times.txt に arrival_time と departure_time の両方を指定する必要があります。
ルートの構造
- 複数の都市や地域を運行する長距離ルートは、分割せずにエンドツーエンドで提供する必要があります（例: A->B->C は [A->B,A->C,B->C] ではありません）。ここで、A、B、C は都市の地域です。たとえば、ブエノスアイレスからコルドバまで運行し、ロサリオに停車する長距離バスは、「ブエノスアイレス - ロサリオ」、「ブエノスアイレス - コルドバ」、「ロサリオ - コルドバ」の 3 つのルートではなく、これらの 3 つの都市に停車する 1 つのルートとして表す必要があります。
- データ プロバイダが正しいルート構造に関する情報を取得できない場合は、都市間のルートを分割して提供することがあります。このような都市間のルートに、都市（都市圏）内に複数の迎車地点または降車地点がある場合、停車地ごとの分割は許可されません。すべての迎車地点とすべての降車地点を 1 つのルートに含める必要があります。
駅の構造
複数のプラットフォームや乗り場がある大規模な駅の場合は、駅とプラットフォームの関係をフィードで指定し、stops.txt の platform_code フィールドで特定の乗り場やプラットフォームを識別する必要があります。特定の乗り場やプラットフォームから常に出発または到着する車両は、GTFS フィードでその乗り場やプラットフォームにリンクする必要があります。出発日や出発時刻によって出発または到着するプラットフォームや乗り場が変わる場合は、GTFS リアルタイムでこの情報を提供できます。
駅/停留所の場所
- 複数のプラットフォームや乗り場がある大規模な駅の場合は、駅の場所を、最も目立つ歩行者用の入り口（駅に建物や構造物がある場合）または乗客の待合室（屋外の駅の場合）の場所に設定する必要があります。
- 道路脇にある小さな停留所の場合は、バスのポールが特定できる場合は、停留所の場所をバスのポールの場所に設定する必要があります。 特定のバスのポールを特定できない場合は、道路の正しい側に、車両が停車する道路沿いの実際の場所の近く（理想的には 10 m 以内）に設定する必要があります。
GTFS の追加拡張機能
パートナー API を実装して料金/在庫情報を表示する場合にのみ必要です。
Google 乗換案内の乗車券販売の拡張機能
- パートナーは、GTFS 乗車券販売の拡張機能のサブセットである 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 と統合する場合は、これらのファイルを提供しないでください。