GTFS Scheduleは計画された交通サービスを記述します。GTFS Realtime(GTFS-RTとも呼ばれます)はサービスの最新情報を伝えます。GBFSは共有モビリティサービスを記述し、ステーションや公開されるフローに基づく利用可能な車両を示します。どの形式を使うかは、アプリケーションが解決すべき課題によります。
これらの形式はデータを構成しますが、どこでも利用可能であることや各フローの質を保証するものではありません。
計画されたサービスを表現するためのGTFS
GTFS Scheduleのセットは、運営者、停留所、路線、運行、運行の時刻などを記述する表形式のファイル群で構成されます。カレンダーは該当する日付を示します。ファイル間は識別子で関連付けられています。 GTFS Scheduleリファレンス.
これにより「この停留所はどこにあるか?」「このサービスの時刻はどうなっているか?」といった質問に答えることができます。時刻表を活用するには、カレンダーとファイル間の関連を解釈する必要があります。
停留所の一覧だけを読むだけでは運行時刻を再構築できません。逆に、時刻を表示しなくても停留所の位置は有用なことがあります。
サービス情報を最新化するためのGTFS-RT
GTFS Realtimeは運行の更新情報、車両位置、アラートを提供可能です。運行の更新は時刻変更やサービス変更を含みます。フローは構造化されたシリアライズフォーマットであるProtocol Buffersを使います。 GTFS Realtime入門.
プロデューサーは全てのカテゴリを提供せず一部のみを公開できます。位置情報フローがあってもすべての停留所に対する情報があるとは限りません。
UIでは、計画された時刻と最新の推定を区別しましょう。当社のガイド 理論的な時刻とリアルタイム はユーザー視点でこの違いを説明しています。
共有モビリティのためのGBFS
GBFSはJSONフローを使い共有モビリティサービスを記述します。システムやバージョンにより、ステーション、その状態、車両やその他サービスの特徴に関する情報を含みます。ドキュメントは特にステーション情報と利用可能状態を区別しています。 GBFSドキュメント.
アプリで安定した位置情報と頻繁に変わる状態情報を分けてください。解釈時にフォーマットのバージョンやタイムスタンプも保持します。
利用可能性フローは予約や解錠のAPIではありません。提供状況の把握に役立ち、貸出操作は各サービスの機能に依存します。
ユースケースに応じた比較
| ニーズ | 検討すべきフォーマット |
|---|---|
| 計画された停留所と路線を記述する | GTFS Schedule |
| 予定された時刻や運行日を解釈する | GTFS Schedule |
| 運行の最新化やサービス情報を受信する | 公開されるフローによるGTFS-RT |
| 共有モビリティのステーションや車両の位置を特定する | 公開されるデータによるGBFS |
設計例:地図に路面電車の停留所と自転車ステーションを表示。場所は構造化データ、利用可能な自転車は最新状態データを使用。キャッシュや更新頻度は異なる層ごとに最適化が必要。
各ソースの制限を考慮
バージョン、オプションフィールド、カバレッジ、利用権を確認。識別子は文脈で意味を持つため、別プロデューサーが同じ文字列を異なるエンティティに使う可能性があります。
欠落や期限切れのデータにも対応しましょう。利用不能なフローからの空リストをサービスが存在しないと誤認しないでください。不明情報を黙ってゼロに置き換えることは避けてください。
フローを直接使うかAPI経由を選ぶ
直接統合では収集、検証、解釈の責任があります。APIは共通契約を提供できますが、カバレッジ、警告、条件の確認は必須です。
ROOTEで最初のユースケースについては、 APIを使った近隣停留所の検索方法をご覧ください。UIのニーズを起点に、実際の利用可能フィールドを確認しましょう。
抜粋を読み、アーキテクチャを選択する
GTFS Scheduleでは、stop_times.txtの抜粋が運行(トリップ)、停留所、計画された通過時刻を結びつけます。以下の簡略例は教育目的であり、完全なGTFSデータセットではなく、その識別子はtrips.txt、stops.txt、およびカレンダーと紐付ける必要があります。
GTFS Realtimeでは、役立つエンティティを探します:TripUpdateは通過時刻を更新し、VehiclePositionは位置を表し、Alertはサービス情報を伝えます。車両位置は到着予測とは限りません。フォーマットはProtocol Buffersであり、診断用JSON表現は基準となるバイナリストリームではありません。
GBFSでは、station_informationがステーションを記述し、station_statusが公開されたステータスを示します。カウンター名や利用可能なファイルはバージョンによって変わります。以下のJSON抜粋はGBFS 2.3とそのフィールドnum_bikes_available、num_docks_availableの例です。使用前にバージョンを必ず確認してください。
場所のマップは構造データから始められます。次の通過便表示には対応する更新と明示的に計画されたフォールバックが必要です。利用可能な自転車の表示はカウンター、貸出条件、時間的有効性を管理します。これら三つの画面は自動的に同じキャッシュポリシーを共有しません。
# Extrait pédagogique de stop_times.txt
trip_id,arrival_time,departure_time,stop_id,stop_sequence
trip_demo,08:10:00,08:10:00,stop_demo,1
# Extrait pédagogique de station_status en GBFS 2.3
{
"station_id": "station_demo",
"num_bikes_available": 3,
"num_docks_available": 7,
"is_installed": true,
"is_renting": true,
"is_returning": true,
"last_reported": 1720000000
}
よくある質問
GTFSは自動的にリアルタイム情報を含みますか?
いいえ。GTFS Scheduleは計画されたサービスのみに対応し、最新情報はGTFS-RTなどの別フローに含まれます。
GBFSは自転車の解錠が可能ですか?
サービスと公開情報を記述するもので、貸出操作は運営者の機能によります。
標準フォーマットは完全なカバレッジを保証しますか?
いいえ。フォーマットは構造を定めますが、カバレッジや公開内容はソース依存です。