Google 乗換案内ユーザーに継続的なサービスと正確なデータを提供するには、GTFS（General Transit Feed Specification）モデリングが必要です。GTFS モデリングとは、静的フィードとリアルタイム（RT）フィードが連携するように設計し、現地で何が起こっているかを伝えられるようにすることです。
GTFS モデリングの基本
- GTFS 静的フィード: Google に送信した後、処理に 24～48 時間かかります。フィードに問題があると判断された場合、さらに時間がかかることがあります。
静的な GTFS は、事前に計画された時刻表と乗換案内設計のためのものです。静的フィードは少なくとも 2 日前に Google に提供してください。ただし、フィードに競合や不審な問題が検出され、人間による審査が必要となった場合に備えて、1 週間前に提出されることをおすすめします。 - GTFS リアルタイム フィード: Google に提供された更新はすぐに反映されます。
GTFS リアルタイムは、静的データのステータスをリアルタイムで提供することを目的としています。車両位置情報を通じた遅れや、静的な GTFS で事前に定義されたルートや停車地の更新情報を通知します。また、運行情報（遅延、サービスの中断）も提供します。 - GTFS でルートを有効または無効にする方法はありますが、未定義のサービス（シェイプ、駅や停留所の順序、停車時刻、経路）を 2 日以内に（リアルタイムで）追加することはできません。サービスの追加には、競合する編集や「不審な」編集に対して人間による審査が行われるため、2～7 日程度かかります。
- 静的フィードでは、feed_info.txt を使って静的な変更を公開する日付を事前（2～7 日以上前）に決定し、リアルタイム フィードとの整合性が保たれるようにすることができます。feed_start_date と feed_end_date のフィールドを使用して、静的フィードを有効にする日付を指定します。feed_start_date が将来の日付（Google が処理する日時に基づく）に開始する場合でも、そのフィードは処理されますが、現在と「将来の」バージョンの両方が保存されます。
- 静的フィードには経路、停車地、ルートの運行スケジュールに関するコアデータが含まれますが、前述したとおり、静的フィードの変更には 2～7 日かかります。運行スケジュールを変更する際のおすすめの方法は次のとおりです。
静的フィードとリアルタイム フィードの更新に関するおすすめの方法
地上交通サービスでは、異なる期間、緊急度、エンティティの種類など、乗換案内に関するさまざまな変更が発生します。一般的に、停車地、経路、ルートの追加、変更、削除など、コアデータに対する変更は、静的フィード内で行う必要があります。ただし、変更を臨機応変かつ迅速に実施しなければならない場合など、一部の変更はリアルタイム フィードで行う方法がいくつかあります。次の表では、フィードのデータを更新するためのおすすめの方法をまとめています。
全般
| 静的（2〜7 日以上） | リアルタイム（1 分前まで） | |
|---|---|---|
| フィードへのデータの追加 | ほとんどの変更は可能で、簡単に実施できます。 | 通常は、現行の頻度に schedule_relationship で追加しない限り、実施できません。 |
| フィードからのデータの削除 | 大幅な削除は不審な操作として報告され、審査に時間がかかる場合があります。 | リアルタイム フィードは、静的の削除には適していません。ただし、アラートは一時的な削除に推奨されます。 |
| フィードのデータの変更 | ほとんどの変更は可能で、簡単に実施できます。 | サポートも推奨もされていません。 |
| 静的（2〜7 日以上） | リアルタイム（1 分前まで） | |
|---|---|---|
| 追加 | 必要に応じて trips.txt から shape_id を既存のルートに追加します。 | 実施できません。shape_id が存在する必要があります。 |
| 削除 | 必要に応じて、trips.txt の既存のルートから shape_id を削除します。使用されていないシェイプがある場合があります。 | なし |
| 変更 | 必要に応じてシェイプを変更します。変更は 2 日間で反映されます。 | なし |
| 静的（2〜7 日以上） | リアルタイム（1 分前まで） | |
| 追加 |
はい。適切な stop_times とルートの変更が必要になる場合があります。 注: 審査の対象となる新しい停車地名は、Google マップで解決されるまでにある程度の時間（2 日以上）がかかる場合があります。 |
なし |
| 削除 | 実施可能です。stop_times で未定義の停車地が引き続き参照されないようにしてください。 |
NO_SERVICE が運行情報に与える影響: 停車地は、それが含まれるすべてのルート上でスキップされます。 または、StopTimeUpdate の schedule_relationship を SKIPPED にすることもできます。 |
| 変更 | 停車地の変更には集中的な審査が必要なため、解決に 2 日以上かかる場合があります。 | 実施できません。削除のみ可能です。 |
| 静的（2〜7 日以上） | リアルタイム（1 分前まで） | |
| 追加 | stop_time を追加すると、定義されたルートとともに既存の停車地を挿入するのと同じ結果が得られます。変更が反映されるまで 2 日かかります。 | 実施できません。 |
| 削除 | （ルートからそれぞれの停車地を削除するため）目的のルートから目的の stop_times を削除します。変更が反映されるまで 2 日かかります。 | StopTimeUpdate の schedule_relationship は SKIPPED にすることができます。 |
| 変更 | stop_times ファイルを必要に応じて変更します。変更は 2 日間で反映されます。 |
基本的に、車両の位置情報（VP）とルートの更新情報（TU）は、リアルタイムで変更された停車時刻です。 運行情報に及ぼす影響として SIGNIFICANT_DELAY と MODIFIED_SERVICE でも示すことができます。 |
| 静的（2〜7 日以上） | リアルタイム（1 分前まで） | |
| 追加 |
日付を指定してサービスを明示的に有効または無効にするには、calendar_dates.txt を使用します。 calendar_dates.txt を calendar.txt とともに使用して、calendar.txt で定義されたデフォルトのサービス パターンの例外を定義します。通常は定期的に運行し、特別なイベントや学校行事などのため特定の日に限定して変更が必要な場合に適しています。変更の反映には 2 日かかりますが、GTFS に大幅な変更を加える必要はありません。すでにサービスがルートに存在する場合は、1 行での編集が必要です。サービスとルートを最小の粒度にすることで、1 対 1 のマッピングにすることができます。 |
schedule_relationship の 値を使って、リアルタイムに計画外のルートを指定します。 シェイプと stop_time は、既存のルートに対して定義済みである必要があります。 親ルートにブロック乗換がない限り、「ADDED」では新しい start_time で計画されたルートがコピーされます。一貫した start_time は、ルートを区別するために不可欠です。 運行情報の ADDITIONAL_SERVICE は、既存の運行路線に導入された追加のバスを記述するために使用されます。 |
| 削除 |
ルートを削除し、すべての参照（頻度、stop_times、ルート）が削除されていることを確認してください。2 日以内に反映されます。 calendar.txt から対応するエントリを削除するか、calendar_dates.txt に例外を追加しても、同じ結果が得られます。 |
時刻表との関係を SKIPPED に設定してルートを更新すると、同じ結果が得られます。 NO_SERVICE または REDULED_SERVICE を指定した運行情報として、影響をユーザーに通知することもできます。説明文を使用してください。 |
| 変更 |
必要に応じてルートを変更できます。 calendar.txt から対応するエントリを削除するか、calendar_dates.txt に例外を追加しても、同じ結果が得られます。 |
運休の変更は許可されていませんが、定刻より早い到着や遅延は TU または VP によって示されます。 停車地や一部のルートは、運行情報からリアルタイムでブロックできます（上記参照）。 |
| 静的（2〜7 日以上） | リアルタイム（1 分前まで） | |
| 追加 | 経路を追加するには、routes.txt に 1 行追加します。ただし、ルートが作成されて trips.txt でその経路に割り当てられるまでは表示されません。 | 実施不可で、推奨もされていません。 |
| 削除 | 経路を削除し、参照するルートが削除されているか、別の経路に割り当てられていることを確認します。2 日以内に反映されます。 |
NO_SERVICE を使うと、この経路に関連付けられているすべてのルートが停止されます。他の経路またはルートと共有されている場合、この経路の停車地は影響を受けません。 注: 実際の経路の削除は、依然として静的な概念です。 |
| 変更 |
必要に応じてルートを変更できます。 ヒント: ユーザーは経路を色や名前で特定します。頻繁に変更することは推奨されません。 |
実施不可で、推奨もされていません。 |
リアルタイム フィードの詳細
重要: シェイプやパスおよび静的フィードの基本要素のリアルタイム修正は現在サポートされておらず、推奨もされていません。
リアルタイムでの追加、削除が可能: 可能にするには、パスのスケッチ、stop_sequence、stop_time（モデルとなるルートなど）が静的フィードに存在している必要があります。
calendar.txt と calendar_dates.txt をクリエイティブに使用することをおすすめします。たとえば、降雪日に備えて、普段は運行していないものの、非常事態の場合に運行される可能性のあるルートを指定します。つまり、ルートを事前に定義しておくということです。これにより、実際の場面で迅速な「RT ベースの無効化 / 有効化（デフォルト）」が可能になります。
よくある質問
Q: 停車地 X で小さな事故があり、できるだけ早く停車地 Y まで迂回案内をしたいのですが、これを行うことは可能ですか？A: 行える操作は、フェスティバル開催までの残り日数によって異なります。
フェスティバル開催までの残り日数が 2 日以上ある場合:
calendar_dates.txt を使って、既存の変更済みルートをフェスティバル期間中すべて運休にします。また、この期間用に新しくルートを追加することもできます。新しい停車地の追加は困難を伴うため、事前に計画を立てることをおすすめします（残り日数が 1 週間以上あれば実施できます）。既存の停車地を使用することも可能です。停車地を変更するには、以下の手順に従います。
- 通常のカレンダーと除外 calendar_dates を含む、影響を受ける既存のルート用に、新しいカレンダーと calendar_date エントリ（新しい service_id）を作成します。
- 影響を受けるルートをこの新しいカレンダー（service_id）に設定します。
- 新しい臨時経路と、影響を受ける変更版ルートで使用するために、イベント日付用に新しい service_id で calendar_dates エントリを作成します。
- 影響を受ける変更版ルート用にルート（とシェイプ）を作成します。また、臨時運行路線用に経路、ルート、シェイプを作成します。これらすべてを手順 3 で作成した service_id に設定してください。
- イベント終了後、前のフィード形式にロールバックします。
フェスティバル開催までの残り日数が 2 日未満の場合:
既存のルートをキャンセルし、この情報を案内するために MODIFIED_SERVICE を使用します。経路の時刻表に新しい停車地や stop_time を導入する時間はありませんが、既存の路線（時刻表または頻度ベース）に「車両を追加」して、サービスの増加に対応することはできます。
A: このルートと同じ stop_sequences を持つルートがすでに静的に含まれているかどうか確認してください。含まれていない場合、2 日以内にこのルートをインデックスに登録することはできません。
ただし、開始時間が異なるルートに対して、時刻表との関係が ADDED のルートとして、ルートの更新情報（TU）や車両の位置情報（VP）を設定することができます。この追加された時刻表では、提供された trip_id の停車地が使用されますが、ルートは新しく設定された start_time で開始されます。
重要: start_time、direction、start_date、trip_id は、追加されたルートへの参照を維持するために固定状態である必要があります。これはブロック乗換を含むルートでは許可されていません。TU フィードと VP フィードは次のようになります。
これは有効なリアルタイム コードではありません。あくまでガイドラインです。
# header information
header {
# version of speed specification. Currently "2.0"
gtfs_realtime_version: "2.0"
# determines whether dataset is incremental or full
incrementality: FULL_DATASET
# the moment where this dataset was generated on server
timestamp: 1284457468
}
# multiple entities can be included in the feed
entity {
# unique identifier for the entity
id: "add-a-trip"
# "type" of the entity
trip_update {
trip {
# selects which GTFS entity (trip) will be affected
Schedule_relationship: ADDED
trip_id: "tripid_of_trip_to_copy" #defined in Static
route_id: “routeid_of_trip_to_copy” # defined in Static.
# Must NOT contain block transfers.
start_time: “10:00:00” #the local time when this ad hoc trip starts
start_date: “20180201” #the local date when this ad hoc trip starts
}
...
}
}