GTFS Schedule と Realtime の使い分け¶
はじめに¶
現在、GTFS作成者には、公共交通サービスの変更または運行障害に関する情報を伝達するための選択肢があります。GTFS Schedule、GTFS Realtime、またはその両方の組み合わせです。しかし、各形式をいつ使用すべきか、またそれらがどのように連携すべきかについてのガイダンスは限られています。この明確性の欠如により、実装の不整合やGTFS利用者間の混乱が生じ、最終的には公共交通の乗客が利用できる情報の品質に影響を及ぼす可能性があります。
この文書では、特別サービスおよび／またはサービスの変更や調整を伝達するために、GTFS ScheduleおよびGTFS Realtimeを効果的に使用するためのガイダンスを提供します。各フィードの想定されるユースケースを明確にし、それらの補完的な役割を概説し、実務における各標準の効果的な利用を支援することを目的としています。GTFS作成者と利用者がこれらの実践について足並みをそろえることで、解釈の曖昧さを減らし、統合を簡素化し、公共交通利用者に提供される情報の品質と正確性を向上させることを目指します。
GTFS Schedule と GTFS Realtime の概要¶
GTFS Schedule データは、あらゆる GTFS 実装の基盤となります。名称が示すとおり、このデータセットには、フィードが対象とする期間中に計画どおり運行されるすべての予定サービスが含まれます。
これに対して、GTFS Realtime は、複数の種類のフィードを通じて、予定された GTFS データに動的な更新を提供します。Trip Updates フィードは、遅延、運休、その他のダイヤ変更を表します。Vehicle Positions フィードは、運行中の車両のリアルタイム位置を提供し、Service Alerts フィードは、利用者に伝達するべき運行障害、迂回、その他の重要な状況に関する通知を伝えます。最後に、実験的な Trip Modifications フィードにより、事業者はサービス変更を反映するため、静的なダイヤを超えて便(trip)を調整することができます。
GTFS のこれら2つの構成要素は、共存して相互に補完するよう設計されており、計画上の運行状況と実際の運行状況の両方について、乗客に最も正確かつ最新の公共交通サービスの情報を提供するために連携します。
一般的な原則として、事業者はサービス情報の主要かつ権威ある情報源として、GTFS Schedule をデフォルトで使用するべきです。GTFS Realtime は非常に有用ですが、実際のサービスが計画から逸脱する場合を除き、予定データを置き換えることを意図したものではありません。
車両位置情報(vehicle position)の報告に加えて、GTFS Realtime は選択的かつ戦略的に使用するべきです。すなわち、静的フィードに反映するには遅すぎる時点で発生した遅延、運休、経路変更、または緊急事態を報告するために使用するべきです。その役割は、予定データを上書きすることではなく、更新または拡張することです。正確かつ最新のダイヤを維持せずに Realtime データへ過度に依存すると、利用者側で不整合が生じ、乗客の混乱につながる可能性があります。
以降のセクションでは、この一般原則が特定のシナリオにどのように適用されるかを説明し、各データソースを効果的に使用するタイミングと方法について、より詳細なガイダンスを提供します。
重要な考慮事項¶
GTFS Realtime より GTFS Schedule を優先する¶
何よりもまず、GTFS を使用して運行情報を公開する際には、GTFS の利用者が更新された情報を処理、検証し、各プラットフォームに配信するための十分な時間を確保できるよう、GTFS Schedule フィードを通じて更新を計画し、公開することを優先するべきです。
予期しない変更または直前の変更が発生した場合は、GTFS Realtime を使用して、運休・乱れ、遅延、または一時的な運行変更を伝達するべきです。これは静的な時刻表を動的に補完するものであり、計画が予期せず変更された際に、乗客が適時に更新情報を受け取れるようにします。
公式の GTFS Schedule Reference より:
「いかなる時点においても、公開された GTFS [Schedule] データセットは、少なくとも今後 7 日間有効であるべきです… 運行変更が 7 日以内に発効する場合、この運行変更は静的 GTFS データセットではなく、GTFS Realtime フィード（運行情報または便の更新(trip update)）を通じて表現するべきです。」
また、多くの交通事業者は、高品質な GTFS Realtime フィードを継続的に生成するための技術的能力またはインフラを欠いている可能性があることを認識することも重要です。これは、利用者と提供者の双方にとって、可能な限り GTFS Schedule を優先するべきであるもう1つの理由です。
円滑なデータ引き渡しを確保する¶
軽微なものも含め、あらゆるサービス変更や運行障害は、特に高頻度または大規模な公共交通システムにおいて、乗客に影響を与える可能性があります。したがって、正確な情報がエンドユーザーに届くことを確保するうえで、プロデューサーからコンシューマーへの GTFS データの引き渡しは重要なステップです。これを実現する鍵は、予測可能性、透明性、および定期的な保守です。
問題が発生した際にプロデューサーとコンシューマーが容易に連絡を取れるべきである一方、一貫した更新頻度と予測可能な動作を確立することで、アドホックなコミュニケーションへの依存を最小限に抑えるべきです。これにより、コンシューマーは変更を予測し、データの正確性を維持できます。
プロデューサーは、feed_info.txt など、フィードに関する明確かつ透明性の高いコミュニケーションを支援する既存の GTFS 機能も活用するべきです。さらに、可能な場合は公開変更履歴または課題トラッカーを維持することが推奨されます。これにより、コンシューマーはリリース間の変更を追跡し、取り込みプロセスをより効率的に適応させることができます。
データ伝播のための時間を確保する¶
フィードを更新する際、GTFSプロデューサーは、新しいフィードバージョンがリリースされると、GTFSコンシューマーが新しいデータを取り込み、処理するための時間を必要とすることを考慮するべきです。システムの規模と複雑さによっては、これには数時間から数日かかることがあります。
GTFSプロデューサーは、運行変更が有効になる十分前に更新済みのScheduleフィードを公開し、コンシューマーが品質チェックを実施し、潜在的な問題を特定するための十分な時間を確保することが推奨されます。このバッファ期間により、新しい運行計画が開始される前に、予期しない問題が検出された場合、コンシューマーはプロデューサーに連絡して問題を報告したり、回避策を実装したりすることもできます。
データ伝播のための時間を確保するには、更新された情報が新しい運行計画の発効少なくとも5日前までにエンドユーザーに提供されることを確実にするため、プロデューサーとコンシューマーが協力してリリースおよび取り込みプロセスを完了する必要があります。十分な時間があれば、旅行者は最も正確な情報から利益を得られます。
Schedule と Realtime のどちらを使用するべきですか？¶
サービス情報を乗客に効果的に伝えるためには、主に GTFS Schedule と GTFS Realtime のどちらに依拠するかを判断することが不可欠です。両形式は補完的な役割を果たしますが、推奨される使用方法は、サービス変更または更新の期間と性質によって異なります。
以下の表は、状況の種類に基づいて、事業者が GTFS Schedule または GTFS Realtime の使用を優先する際に役立つ一般的な指針を示しています。
| 短期間（数時間から数日） | 長期間（数週間から数か月） | |
|---|---|---|
| 計画されたサービス | 以下には GTFS Schedule を使用してください - 休日ダイヤ - 計画された大規模イベント期間中の特別サービス - 事前告知を伴う一時的な迂回 - 予定された早期閉鎖 |
以下には GTFS Schedule を使用してください - 通常サービス - 季節的なダイヤ変更 - 影響が判明している工事 - ルート・路線系統(route)の再設計 - サービスの拡大または縮小 |
| 予期しないサービス障害 | 以下には GTFS Realtime を使用してください - 車両故障による便(trip)の運休 - リアルタイムの遅延 - 緊急迂回 - 事故 - 予期しない需要の変化 |
以下には両方を組み合わせて使用してください - 長期化するストライキまたはデモ - 自然災害またはその他の事象によるインフラ損傷 - 継続的な車両不足 - 事故後の長期間にわたる駅の閉鎖 |
このマトリクスは、決定的または絶対的な指針ではないことに注意してください。サービス障害は複雑であり、微妙な差異を伴う場合があります。各状況に適切に対応するには、柔軟性が不可欠です。主な目標は、乗客が効果的に旅程(journey)を計画できるよう、正確かつタイムリーな情報を提供することです。
以降のセクションでは、計画されたサービス更新と予期しないサービス更新の両方について、推奨される実践方法を詳しく説明します。
計画されたサービス: 短期および長期¶
交通事業者は一般に、効率を最大化するために運行を慎重に計画し、規則的で予測可能なダイヤを提供することを目指しています。これらの計画の一部は一定期間安定したままである場合がありますが、運用上の制約、特別なイベント、季節的な変化など、さまざまな理由によりサービスはしばしば調整または変更されます。
公式の GTFS Schedule reference によると、「GTFS dataset should be valid for at least the next 7 days, and ideally for as long as the operator is confident that the schedule will continue to be operated.」 とされています。大規模なサービス変更が不要な場合でも、フィードに含まれる運行ダイヤが正確かつ最新の状態に保たれるよう、提供者は GTFS feeds の定期的かつ周期的なメンテナンスを実施することが期待されています。
GTFS Schedule は、ルート・路線系統(route)、便(trip)、停留所等(stop)、ダイヤを含む交通システムの不可欠な計画要素を含んでおり、あらゆる GTFS 実装の基盤となるため、これらの更新では GTFS Schedule を使用してすべての計画されたサービスを表現するべきです。計画されたサービスには、通常運行（例: 平日および週末のサービス）だけでなく、祝日ダイヤ、季節に応じて調整されたダイヤ、大規模な計画イベント（例: スポーツイベントまたはコンサート）に伴うサービス変更など、今後予定されている特別サービスも含まれます。
一時的なルート変更、駅の閉鎖、便(trip)の運休など、事前に判明している計画されたサービス中断または運用変更も、可能な限り早期に Schedule feed に組み込むべきです。最新の Schedule feed を維持することで、経路検索サービスやその他の利用者は、十分前もってユーザーに正確な情報を提供できます。
以下の表は、計画されたサービスの最も一般的なケースを要約し、いくつかの例を示しています。
| ユースケース | 説明 | 例 |
|---|---|---|
| 通常サービス | 一貫したダイヤに従う、標準的かつ繰り返し運行されるサービスです。 | - 平日の通勤サービス - 週末の減便運行 - 深夜バスサービス |
| 特別サービス | 特定の機会または期間に向けて予定され、事前に判明しているサービスです。 | - 祝日ダイヤ（例: クリスマス、元日） - 夏季または冬季ダイヤ - 大規模イベント向けの特別サービス（例: スポーツイベントまたはコンサート） |
| 計画されたサービス中断 | 保守またはその他の事前に予定されたイベントにより生じる、通常サービスへの既知の変更です。 | - 一時的な駅の閉鎖 - 工事に伴うルート迂回 - 保守に伴う予定された便(trip)の運休 |
計画されたサービスに対する定期的なフィード更新のために信頼できる環境を構築するため、以下の実践が推奨されます。
計画的な運行調整における GTFS Realtime の補完的な利用¶
GTFS Schedule は計画された運行更新を伝達するための主要な情報源であり続けるべきですが、GTFS Realtime の運行情報(alert)は、今後発生する運休や調整をユーザーに通知することでこれを補完します。
例えば、夏季ダイヤの開始前や、大規模工事に伴うルート・路線系統(route)の一時的な迂回の前に、変更の数日前に運行情報(alert)を公開できます（変更はすでに GTFS Schedule フィードに反映されています）。これにより、ユーザーに情報を提供し、適切に計画できるようにします。
ほとんどの場合、計画的な調整に関する運行情報(alert)は、変更が有効になる7日前を超えて公開するべきではありません。この機能のサポートは、コンシューマーによって異なる場合があります。
推奨プラクティス¶
プロデューサー
- Schedule feedの予測可能な更新頻度を確立してください： 適切な頻度は、各事業者の運用状況によって異なります。毎週または毎月更新する事業者もあれば、四半期ごとに更新する事業者もあります。予測可能な頻度により、コンシューマーは変更を予測し、更新に備えることができます。
- 更新されたSchedule feedを事前に公開してください： 理想的には、変更が判明した時点でfeedを公開するべきですが、運行変更が有効になる3～4週間前に更新をリリースすれば十分です。予期しない変更が発生した場合でも、プロデューサーは新しい運行計画が有効になる少なくとも7日間前に、更新されたGTFS Schedule feedをリリースすることを目指すべきです。運行変更がそれより短い期間で判明した場合、変更は対応するGTFS Realtimeを使用して反映するべきです。
- 主要なfeedの詳細を伝達するために
feed_info.txtを使用してください： 正確な連絡先情報（feed_contact_email、feed_publisher_name、feed_publisher_url）、feed_start_date、feed_end_date、およびfeed_versionを含めてください。この情報は、コンシューマーが最新のデータを使用していることを確認し、問題が発生した場合にプロデューサーへ連絡するのに役立ちます。Realtime feedとSchedule feedの両方にfeed_versionを含めることで、正しいデータが取り込まれていることについて追加の確実性が得られます。
コンシューマー
- 新しいfeedバージョンを毎日確認してください： コンシューマーは、リリースから48時間以内に新しいデータを取り込むことが期待されます。これにより、変更が有効になる少なくとも5日間前に、正確な運行情報がエンドユーザーに提供されることが保証されます。
例1: 大規模コンサートに伴うサービス調整¶
大勢の観客を集めることが予想される重要なコンサートが、5月24日に開催されることが発表されます。交通事業者はこのイベントを6か月前から把握しており、会場に接続するルート・路線系統(route)で夜間サービスの延長を提供する予定です。これは計画的な調整であるため、通常の保守更新の一環としてGTFS Schedule feedに反映しなければなりません。
| 日付 | イベント | 詳細 |
|---|---|---|
| 3月31日 | 運行計画の確定 | - 事業者は数か月前からコンサートを把握し、追加サービスの必要性を特定します。- 事業者は、3月31日に特別イベントサービスを含む5月の完全なサービス計画を確定します。 |
| 4月10日 | 更新されたGTFS Scheduleの公開 | - 事業者のGTFS保守担当チームは、特別便(trip)および調整後の時刻表を含む5月のデータセットを準備します。- 更新されたSchedule feedは、4月10日に事業者のオープンデータポータルで公開されます。- これには、現在の時刻表と将来の時刻表を組み合わせた、5月および4月の残りの期間のサービス情報が含まれます。 |
| 4月10日～14日 | 利用者側での取り込み | - 乗換案内アプリケーションは、公開された当日に更新を検出します。- これらはfeedを取り込み、品質チェックを実行し、4月14日までに更新された5月の時刻表をユーザーに表示し始めます。 |
| 5月22日 | Realtime Service Alertの追加 | - 今後の変更の視認性を高めるため、事業者はイベントの2日前である5月22日にService Alertを公開します。- 乗換案内アプリは数分以内に運行情報(alert)の表示を開始します。- この運行情報(alert)は、すでに利用可能なSchedule情報を補完します。 |
| 5月25日 | Service Alertの削除 | - イベント後、事業者はRealtime feedから運行情報(alert)を削除します。- 乗換案内アプリは直ちにその表示を停止します。 |
例2: 夏季ダイヤの開始¶
夏季シーズンを前に、ある交通事業者は、複数のバス路線の運行頻度を調整し、季節限定のビーチシャトルを復活させる季節ダイヤを計画しています。この季節計画は6月1日に開始し、ほぼ4か月間継続します。これらは計画的かつ定期的な変更であり、事業者の通常の更新サイクルの一環として、GTFS Scheduleフィードに反映しなければなりません。乗客が移行に備えられるよう、事業者は、変更が有効になる直前に予定されている変更を強調するため、GTFS Realtime Service Alertsも使用します。
| 日付 | イベント | 詳細 |
|---|---|---|
| 5月2日 | 夏季ダイヤの確定 | - 事業者は、複数のバス路線における運行頻度の調整および季節限定のビーチシャトルの再導入を含む夏季運行計画を数か月前から準備します。- 更新後のダイヤは5月2日に確定します。 |
| 5月14日 | 更新されたGTFS Scheduleの公開 | - 事業者のGTFSを維持管理する担当チームは、特別な便(trip)および調整後のダイヤを含む6月のデータセットを準備します。- 6月1日から有効となる夏季運行の変更および5月の残りの運行を含む6月のScheduleフィードは、5月14日に公開されます。 |
| 5月14日～18日 | 利用者側での取り込み | - 旅程検索アプリケーションは、更新されたScheduleが公開されるとすぐに検出します。- これらのアプリケーションはフィードを取り込み、品質チェックを実行し、5月18日までに乗客に6月の運行変更の表示を開始します。 |
| 5月25日 | Realtime Service Alertの追加 | - 視認性を高め、乗客に今後の夏季ダイヤを知らせるため、事業者は変更が有効になる1週間前の5月25日にGTFS Realtime Service Alertを公開します。- 運行情報(alert)の説明は次のとおりです。"夏季ダイヤは6月1日に開始します。一部のサービスでは通常の運行頻度が変更され、季節限定のビーチシャトルが運行されることにご注意ください。詳細については、当社のウェブサイトをご参照ください。"- 旅程検索アプリは数分以内に運行情報(alert)の表示を開始します。 |
| 6月6日 | Service Alertの削除 | - 事業者は6月6日にRealtimeフィードから運行情報(alert)を削除し、乗客が移行前と移行直後の両方で確認できるようにします。- 旅程検索アプリは直ちにその表示を停止します。 |
予期しない短期的な運行障害¶
慎重に計画していても、公共交通サービスは、短期間にわたり運行を妨げる突発的な事象の影響を受けることが頻繁にあります。例としては、車両故障、軽微な事故、一時的な迂回、緊急閉鎖、または短期的な需要の急増が挙げられます。
これらの事象はほとんど、またはまったく予告なく発生するため、事業者は迅速に対応しなければならず、GTFS データチームには Schedule feed を変更するための十分な時間が残されていないことがよくあります。これらの短期的な調整を GTFS Schedule で表現しようとすることは実用的ではなく、通常運行が再開された際に一時的な変更を削除する必要があるため、エラーを招く可能性があります。
したがって、GTFS Realtime は短期的な運行障害を伝達するための最も効果的な方法です。Schedule feed を補完することで、Realtime updates により事業者は計画された時刻表を維持したまま、運行上の変更を即座に伝達できます。場合によっては、Realtime updates が一時的に Schedule data を上書きすることもできますが、producer はそのような発生を最小限に抑えるべきです。
Realtime feeds は頻繁な更新をサポートしており、consumer applications が継続的に、または短い間隔でデータを取り込めるようにすることで、乗客が最新の情報を受け取り、リアルタイムで十分な情報に基づく判断を行えるよう支援します。
GTFS Schedule Reference に記載されているとおり、更新された GTFS Schedule feed を、サービス変更が有効になる少なくとも 7 日前に公開できない場合、その変更は代わりに GTFS Realtime を通じて伝達するべきです。この期間を満たせるかどうかを判断する際、producer は、データ準備、内部検証、公開、および consumer が更新されたデータセットを取得、処理し、アプリケーションにデプロイするために必要な時間を含む、エンドツーエンドのプロセス全体を考慮するべきです。
GTFS Realtime は、更新を提供するために使用できる 4 種類の異なるエンティティ、すなわち Service Alerts、Trip Updates、Vehicle Positions および Trip Modifications（現在 experimental feature）で構成されています。これらの feed entities は、状況に応じて単独または組み合わせて使用し、サービス更新を表現できます。各エンティティに関する詳細については、GTFS Realtime Reference を参照してください。
推奨プラクティス¶
プロデューサー:
- Realtime と Schedule データ間の識別子の一貫性を確保してください:
trip_id、route_id、stop_idなど、スケジュールされたサービスを参照する Realtime エンティティは、対応する GTFS Schedule フィードで公開されている識別子と一致しなければなりません。これにより、コンシューマーは Realtime の更新をスケジュールされたサービスに正しく関連付けることができ、データ取り込み、信頼性、およびユーザー向けの正確性が向上します。 - 正しい Schedule フィードのバージョンへの明確な参照を含めてください: プロデューサーは、Realtime フィードがどの GTFS Schedule データセットと整合しているかを示すために、GTFS Realtime（および
feed_info.txt）のfeed_versionフィールドを設定するべきです。これにより、コンシューマーは Realtime データが適切なバージョンの Schedule フィードにマッピングされていることを検証でき、頻繁な更新または運用上の変更が行われる期間における不整合の問題を軽減できます。 - GTFS Realtime で作成される New または Replacement の便(trip)への過度な依存を避けてください: GTFS Realtime における New または Replacement の便(trip)の作成は、控えめに、かつ運用上必要な場合（例: スケジュールされていない増発サービス）にのみ使用するべきです。Realtime で追加される便(trip)に過度に依存すると、コンシューマーによる取り込みが複雑になり、サービスの予測が困難になり、計画されたサービスと実際に運行されたサービスとの間に不整合が生じる可能性があります。可能な限り、GTFS Schedule および/または Realtime の Trip Modifications を優先してください。
- Realtime 情報が有効でなくなった場合は削除してください: プロデューサーは、解決済みの運行情報(alert)、期限切れの迂回、または完了した運休など、古くなった Realtime データが現在のサービスを反映しなくなった時点で、速やかに削除されるようにするべきです。適時の削除により、ユーザーの混乱を防ぎ、Schedule と Realtime の情報間で競合が発生するリスクを低減し、コンシューマーが有効なサービス状況を正確に表現し続けることに役立ちます。
コンシューマー:
- 検出したデータの問題をプロデューサーに積極的に伝達してください: カレンダーの不整合、ジオメトリの欠落、継続的な識別子の競合、または予期しない便(trip)の挙動などの問題が発生した場合、コンシューマーは確立されたコミュニケーションチャネルに従い、速やかにプロデューサーへ通知するべきです。早期のフィードバックにより、より迅速な修正が可能となり、より広範なデータエコシステムに利益をもたらします。
例3: 停電による駅の一時閉鎖¶
11月8日、予期しない停電により、当局は市内のオレンジ地下鉄線を運行する重要な駅を一時的に閉鎖せざるを得なくなります。この停電は予期しないものであり、電力が復旧するまで駅を直ちに閉鎖する必要がありますが、列車は影響を受けた駅を通過するだけで、システムの他の部分では通常どおり運行を継続できます。この混乱は約1時間続くと予想されるため、事業者は一時的な運行障害を伝達するために完全に GTFS Realtime に依存します。
| 時刻 | イベント | 詳細 |
|---|---|---|
| 11月8日（午後4時45分） | 停電を検知 | - 午後4時45分頃、Oakwood Stationは停電により直ちに閉鎖を余儀なくされます。 |
| 11月8日（午後5時15分） | GTFS Realtimeフィードの更新 | - 事業者は GTFS Realtime Service Alerts フィードを更新し、駅が一時的に閉鎖されていることを乗客に通知し、混乱の予想期間を示す運行情報(alert)を追加します。- 同時に、GTFS Realtime Trip Updates フィードを使用して、影響を受ける便(trip)において当該駅を skipped としてマークし、車両がOakwood Stationに停車しないことを効果的に伝達します。- 経路検索アプリケーションはRealtimeフィードを即座に取り込み、経路検索ツールのユーザーインターフェースに運行情報(alert)を表示するとともに、経路検索の目的でOakwood Stationを閉鎖します。- 乗客は閉鎖について通知を受け、それに応じて移動計画を調整できます。 |
| 11月8日（午後6時5分） | 電力復旧および通常運行の再開 | - 午後6時過ぎに電力が復旧し、駅が再開します。- 交通事業者は、Service Alertsフィードの運行情報(alert)と、Trip Updates内の停留所等(stop)の skipped ステータスを削除します。- 経路検索アプリは、アプリ内で更新されたフィードを反映し、経路検索のために停留所等(stop)を直ちに再有効化し、運行情報(alert)を削除します。 |
例4: 緊急道路閉鎖によるバスサービスの調整¶
6月12日の朝、大規模な水道本管の破裂により当局が Route 17 沿いの主要交差点を閉鎖し、バスサービスに予期しない混乱が生じます。修理には数日かかる見込みであるため、事業者は一時的な混乱、調整後のサービス、および通常サービスが再開される推定時期について利用者に知らせるため、完全に GTFS Realtime に依存します。
| 時刻 | イベント | 詳細 |
|---|---|---|
| 6月12日（午前9時30分） | 緊急道路閉鎖を検知 | - Route 17 を使用する便(trip)は、突然の水道本管破裂により影響を受け、バスは代替道路への迂回を余儀なくされ、3つの停留所等(stop)を通過し、遅延が発生します。 |
| 6月12日（午前10時00分） | GTFS Realtime フィードの更新 | - 事業者は GTFS Realtime Service Alert フィードを更新し、Route 17 ではその日の残りの時間に遅延が予想されることを示す運行情報(alert)を追加します。- GTFS Realtime Trip Updates フィードを使用して、影響を受ける3つの停留所等(stop)を skipped としてマークし、その日の対応する便(trip)に推定遅延を割り当てます。- 旅程検索アプリケーションは Realtime フィードを直ちに取り込み、旅程検索ツールのユーザーインターフェースに運行情報(alert)を表示し始めるとともに、旅程検索の目的で影響を受ける3つの停留所等(stop)を無効化します。- 乗客は遅延および運休となった停留所等(stop)について通知を受け、それに応じて移動計画を調整できます。 |
| 6月12日（午後4時00分） | 調整後のサービス計画を確定 | - 交通事業者は、修理が6月14日の深夜前までに完了し、交差点が6月15日の早朝に再開通することの確認を受けます。- 事業者は、翌日の運行開始時から有効となる、新たな迂回経路および移設された停留所等(stop)を含む、Route 17 を使用する便(trip)向けの一時的な調整後サービス計画を準備します。 |
| 6月12日（午後7時00分） | 2回目の GTFS Realtime フィード更新 | - 交通事業者は GTFS Realtime Service Alerts フィードを更新し、以前の運行情報(alert)を削除して、一時的な調整後サービスが次の2日間有効となることを告知する新しい運行情報(alert)に置き換えます。- 次の2日間の Route 17 の便(trip)について、変更されたサービスの詳細（例: 迂回経路、代替停留所等(stop)、遅延）を伝達するため、新しい GTFS Realtime Trip Updates フィードが準備されます。- 旅程検索アプリケーションは、新しい運行情報(alert)とともに、更新された迂回経路および移設された停留所等(stop)を直ちに表示し始めます。 |
| 6月14日（午後11時00分） | 修理完了、翌日に通常サービスを再開 | - 6月14日の午後10時30分頃、水道本管の修理作業が完了し、交差点は数時間後に再開通できる状態になります。- 交通事業者は、対応する運行情報(alert)および便の更新(trip update)を GTFS Realtime フィードから削除します。- 旅程検索アプリケーションは更新されたフィードを反映し、GTFS Schedule の通常サービス情報を再び有効にし、運行情報(alert)を削除します。 |
予期しない長期的な運行障害¶
時として、予期しない、または突発的な事象により、中期または長期の運行障害が発生し、通常運行がいつ再開されるかについて高い不確実性が生じることがあります。例としては、公共交通機関の運行を妨げる自然災害、特定のルート・路線系統(route)を遮断する長期的なストライキまたはデモ、あるいは無期限の駅閉鎖を余儀なくする構造的損傷などがあります。
このような障害が発生した場合、プロデューサーはまず GTFS Realtime を通じて影響を伝達し、ユーザーが即時かつ正確な情報を受け取れるようにするべきです。予想される期間および運行上の影響についてより明確になった時点で、プロデューサーは調整後の運行期間の残りについて、コミュニケーション戦略を策定するべきです。
適切なアプローチは、障害の性質および期間、ならびに事業者のデータ管理能力によって異なります。ただし、以下の一般的なガイダンスが適用されます。
- 事業者は、1週間を超え1か月未満続く障害について、GTFS Schedule と GTFS Realtime の使用を選択することができます。 これは、運用上の制約、更新ワークフロー、および運行パターンの変更が予想される頻度によって異なります。GTFS Schedule の更新が実現可能でない、または実用的でない場合、プロデューサーは、より安定した運行計画を策定できるまで、運休、追加便、調整されたパターン、またはその他の運行変更を伝えるために GTFS Realtime に引き続き依存することができます。
- 可能な場合、障害が1か月を超えて継続すると予想される場合は、調整後の運行を表現するために GTFS Schedule の使用を優先するべきです。GTFS Schedule は、複数週または複数月にわたる運行パターンを、より信頼性が高く永続的に表現できます。GTFS Realtime Service Alerts は、継続中の影響を強調したり、追加の文脈を提供したりするための補完的なチャネルとして引き続き使用することができます。
プロデューサーとコンシューマーは協力し、状況の変化に応じて継続的に再評価し、乗客にとっての明確性、正確性、および使いやすさを維持するため、それに応じてコミュニケーション戦略を更新するべきです。
推奨プラクティス¶
プロデューサー:
- コンシューマーとの積極的かつ継続的なコミュニケーションを維持してください: 長期的な混乱時には、運行条件の変化に伴い、サービス計画が頻繁に変更されることがあります。コンシューマーが遅延なく新しいデータを準備および取り込めるように、プロデューサーは想定されるタイムライン、計画されたデータ更新、および戦略上の変更の可能性（例: Realtime から Schedule への切り替え）を伝達することが推奨されます。
- Realtime から GTFS Schedule への構造化された移行を確保してください: 混乱が GTFS Schedule の更新を正当化する安定性の水準に達した場合、プロデューサーは、新しい Schedule feed が有効になった時点で一時的な Realtime メッセージおよび便(trip)の調整が削除または更新されるよう、移行を明確に調整するべきです。
- 非常に短い有効期間のみを対象とする Schedule feed の公開を避けてください: 調整後のサービスを表すために GTFS Schedule を使用する場合、プロデューサーは、複数の短期間の feed（例: 数週間のみを対象とするもの）を発行することを避けるべきです。代わりに、Schedule の更新は、合理的に安定した有効期間を持つサービスパターンを反映するべきです。
- Schedule の更新を補完するために Realtime Service Alerts を使用してください: 長期的な混乱に対して更新済みの Schedule feed が公開される場合でも、Realtime は引き続き有用なコンテキストを提供できます。例えば、影響を受ける駅を強調したり、安全情報を提供したり、運行における予想される変動を記載したりできます。
コンシューマー:
- 主要な更新またはコミュニケーション戦略の変更を予測するため、プロデューサーと調整してください: 特別な状況では、コンシューマーは、想定されるタイムライン、計画された公開日、および取り込みや表示に影響する可能性のある複雑性を理解するために、プロデューサーと積極的に連携するべきです。早期の調整により、不整合のリスクが低減され、乗客向けシステムが新しい情報を迅速かつ正確に取り込むことが確保されます。
例5：地震被害後の無期限の駅閉鎖¶
8月17日、中程度の地震により、地下鉄システムのRed Lineで最も利用者の多い停留所等(stop)の1つである市のCentral Stationに構造的な損傷が発生します。駅は安全検査のため直ちに閉鎖され、再開時期は明確ではありません。交通事業者は当初、閉鎖を乗客に通知し、状況の進展に応じて更新情報を提供するために、GTFS Realtime に依存します。
| 日付 | イベント | 詳細 |
|---|---|---|
| 8月17日 | 地震および初期閉鎖 | - 構造的な損傷により、駅は直ちに閉鎖されます。- Red Lineの便(trip)がCentral Stationに停車しないこと、および追って通知があるまで閉鎖が継続することを乗客に知らせるため、GTFS Realtime Service Alert が公開されます。- Trip Updates feed は、StopTimeUpdateでCentral Stationをskippedとしてマークすることにより、影響を受ける便(trip)を調整するために使用されます。 |
| 8月17日～31日 | Realtime更新のみ | - 修理に関する不確実性を踏まえ、事業者は乗客に情報を提供し続けるためにRealtimeに依存し続けます。- 新しい情報が利用可能になるとService Alertが更新され、Trip Updates feedも影響を受けるすべての便(trip)について更新され続けます。- 旅程検索アプリは、公開から数分以内に更新された運行情報(alert)を表示します。 |
| 8月21日 | 修理期間の確定 | - 事業者は、修理の完了には少なくとも2か月を要することの確認を受けます。- 事業者は、Central Stationに停車しない変更後の運行パターンの計画を開始します。 |
| 8月23日 | 更新されたGTFS Scheduleの公開 | - 変更後の運行パターンは9月～10月のGTFS Schedule feedに含まれ、Red Lineの便(trip)についてstop_timesファイルから停留所等(stop)が削除されます。- 更新されたSchedule feedは、事業者により8月23日に公開されます。 |
| 8月25日 | 更新されたGTFS Scheduleの取り込み | - 旅程検索アプリケーションは、更新されたScheduleがリリースされるとすぐに検出します。- これらはfeedを取り込み、品質チェックを実行し、有効になる5日前の8月25日までに、更新された9月の運行情報を乗客に表示し始めます。 |
| 9月1日 | 更新されたService Alert | - 事業者は、影響を受ける便(trip)を調整するためのTrip Updates feedの使用を停止し、代わりにGTFS Schedule feed内の更新された運行データに依存します。- 事業者は、駅が少なくとも10月31日まで閉鎖されたままであることを伝える新しいService Alertに、以前のService Alertを置き換えます。- 旅程検索アプリは、数分以内に更新された運行情報(alert)の表示を開始します。 |
| 10月20日 | 駅再開日が確定、更新されたGTFS Scheduleを公開 | - 事業者は、10月最終週に修理が完了した後、駅が11月1日に再開することを確認します。- 10月20日に、事業者は更新されたScheduleを事業者のオープンデータポータルで公開します。- これには11月および10月の残りの期間の運行情報が含まれ、現在のスケジュールと将来のスケジュールが統合されます。 |
| 10月22日 | 利用者向けアプリケーションによる取り込み | - 旅程検索アプリケーションは、リリース当日に更新を検出します。- これらはfeedを取り込み、品質チェックを実行し、10月22日までに更新された11月のスケジュールをユーザーに表示し始めます。 |
| 10月22日 | Realtime Service Alertの追加 | - 今後の再開について乗客に知らせるため、事業者は駅での運行再開の1週間前である10月22日にService Alertを公開します。- 旅程検索アプリは、数分以内に運行情報(alert)の表示を開始します。- この運行情報(alert)は、すでに利用可能なSchedule情報を補完します。 |
| 11月3日 | Service Alertの削除 | - 再開から2日後、事業者はRealtime feedから運行情報(alert)を削除します。- 旅程検索アプリは直ちにその表示を停止します。 |
例6: 職員ストライキによる予期しない長期的なサービス中断¶
3月3日、交通機関職員によるストライキが発表され、市内全域の地下鉄、バス、路面電車の運行が特定の時間帯に影響を受けます。事業者は当初、ストライキがどの程度続くかを把握しておらず、乗客にとって不確実性が生じるため、即時かつ継続的な情報提供が必要となります。事業者は、中期的な運行調整の可能性を評価しながら、影響を伝達するために GTFS Realtime を利用します。
| 日付 | イベント | 詳細 |
|---|---|---|
| 3月3日 | ストライキ開始 | - 最初の毎日の運休時間帯（午前10時～午後4時）に、すべての交通サービスが運休し、その後、運行が段階的に再開されます。- 予想される運休時間帯および限定的な運行を含め、乗客に中断を通知するために GTFS Realtime Service Alert が公開されます。- GTFS Realtime Trip Modifications フィードを使用して、運休時間帯内の便をキャンセルし、運行する便を調整します。 |
| 3月3日～10日 | Realtime の更新のみ | - 事業者は、各日の運休時間帯および変更された時刻表について、毎日 Realtime の更新を提供します。- ストライキの状況変化に応じて、Service Alerts が頻繁に更新されます。- Trip Modifications は、キャンセルおよび調整された運行パターンを引き続き反映します。 |
| 3月10日 | 予想されるストライキ期間を確認 | - 交渉の結果、事前に合意に達しない場合、段階的な運休は 月末まで継続する見込み であることが示されます。- 事業者は、一貫した毎日の運休時間帯や、それらの時間帯以外における調整された運行頻度を含め、運用上の不確実性を低減するための、より安定した一時的な運行計画の策定を開始します。- 状況が流動的であり、合意に達した場合にはストライキが突然終了する可能性があることから、事業者は、安定したパターンを完全に実施できるまで、調整後の運行時刻表を伝達するために GTFS Realtime への依存を継続することを決定します。 |
| 3月11日～23日 | Realtime の更新を継続 | - 事業者は、各日の運休時間帯および変更された時刻表について、毎日 Realtime の更新を引き続き提供します。- 乗客に中断を知らせ続けるため、Service Alerts の利用を継続します。- Trip Modifications は、キャンセルおよび一時的な運行調整を引き続き反映します。 |
| 3月23日 | ストライキ終了 | - 事業者と職員組合の間で合意に達し、ストライキは事実上終了し、翌日から通常運行を再開できるようになります。- 事業者は、通常運行が3月24日に再開される見込みであることを乗客に通知する、更新された Service Alert を公開します。- 経路検索アプリは数分以内に運行情報の表示を開始します。 |
| 3月24日 | 通常運行への移行 | - Trip Modifications および以前の Service Alerts を削除し、標準的な運行情報の伝達には GTFS Schedule feed を利用します。- 事業者は、通常運行が現在有効であることを確認する、更新された Service Alert を公開します。- 経路検索アプリは数分以内に運行情報を表示します。 |
| 3月26日 | Service Alert を削除 | - 事業者は、通常運行の再開から2日後に Realtime フィードから運行情報を削除します。- 経路検索アプリは直ちにその表示を停止します。 |
運行の中断や運用上の変更は予測が難しいことが多いですが、GTFS Schedule と GTFS Realtime を補完的に利用することで、乗客がこの不確実性に単独で対処することがないようにできます。
この文書では、交通事業者およびデータ利用者が日常業務で遭遇する最も一般的なシナリオの多くについて、推奨される実践方法を示しました。しかし、現実の状況はより複雑になる場合があり、追加の調整や状況に応じたアプローチが必要となることがあります。
疑問が残る場合、または状況がここで取り上げた例の範囲外である場合、事業者および利用者は、ガイダンスを求め、経験を共有するために、より広範な GTFS Community に参加することが推奨されます。仲間から学び、新たなユースケースについて議論することは、実装を強化し、データ提供者と乗客の双方にとっての成果を改善するのに役立ちます。