技術要約：公共交通機関の再帰的スケジュール：GTFSからの安定した識別と類似性分析

1. 問題提起

公共交通機関のスケジュールは、複数の暦日が同一の乗客向け時刻表（例：標準的な平日）を共有する、再帰的なサービス構造を示しますが、休日や特別イベントによってそれらが異なることもあります。しかし、世界の標準であるGTFS（General Transit Feed Specification）には、これらの再帰的な「DayType（日種別）」が明示的にエンコードされていません。その代わりに、GTFSはカレンダー、トリップ、停留所時刻、形状（shape）といった相互依存するテーブルを通じてサービスを表現しており、スケジューリング、車両割り当て、需要分析などのダウンストリーム・モデルは、断片化されたデータから再帰的な供給オブジェクトを再構築することを余儀なくされています。

核心となる課題は二重にあります：

1. 識別： 管理上の識別子（例：shape_id、stop_id）に依存することなく（これらはフィードのリリース間で変化する可能性がある）、GTFSから安定した再帰的サービス・クラス（DayType）をどのように抽出するか。
2. 比較： 抽出されたスケジュールを比較し、厳密な時刻表の違い、軽微なタイミングのずれ（例：1分の遅延）、および実質的な構造的変化（例：路線の廃止または新設）をどのように区別するか。

2. 手法

2.1. 定義の定式化

本論文では、2つの主要な概念を定式化しています：

• ルートパターン（Route Pattern）： 順序付けられた停留所のシーケンスと走行方向によって定義される、乗客向けのサービス・バリアント。管理上の識別子であるGTFSの shape_id とは異なり、ルートパターンは物理的な経路と停留所の順序によって定義されます。
• DayType（日種別）： 同じ一連のルートパターン・トリップが同じ時刻に運行されている日付のカテゴリ。これは、トリップ仕様の集合として厳密に定義されます：$DayType(d) = \{(p, dep_t, arr_t)\}$。ここで、$p$ はルートパターン、$dep_t/arr_t$ は始発出発時刻および最終到着時刻です。

2.2. H3インデックスによる安定した抽出

管理上の識別子の再ラベル付けに対する安定性を確保するため、著者らは H3階層型地理空間インデックス・システム（Uber Technologies, 2018）を用いた抽出手法を提案しています。

• ルートパターン・キー： shape_id や stop_id を使用する代わりに、この手法では、順序付けられた停留所の座標シーケンスをH3セル（解像度15）のシーケンスに変換します。このシーケンスが、ルートパターンの決定論的かつ安定したキーとして機能します。
• 抽出アルゴリズム：
  1. GTFSのカレンダーおよび例外テーブルを展開し、すべての該当日におけるアクティブなトリップのリストを生成する。
  2. 各アクティブなトリップについて、その停留所シーケンスをH3ベースのルートパターン・キーに変換する。
  3. トリップ仕様のタプル $(H3\_key, first\_departure, last\_arrival)$ を形成する。
  4. 全く同じトリップ仕様タプルの集合を共有する日付を、単一のDayTypeとしてグループ化する。
• 不変性： このアプローチにより、2つのGTFSフィードが異なる管理IDを使用していたとしても、停留所の座標と順序に変更がない限り、抽出されたDayTypeの分割は同一となります。

2.3. スケジュール比較フレームワーク

本論文は、DayType $A$ と $B$ を比較するための3層の階層的メトリクスを導入しています：

1. 厳密なメトリクス ($d_0$):

   • トリップ仕様の集合に対する ジャカード距離（Jaccard Distance） を使用します。
   • ルートパターン、出発時刻、または到着時刻のいずれかの違いを、異なるDayTypeとして扱います。
   • データ品質や意図的な時刻調整のための厳密な監査シグナルとして機能します。

2. 時間許容メトリクス ($d_\epsilon$):

   • 許容パラメータ $\epsilon$（例：1、3、または5分）を導入します。
   • 2つのトリップは、同じルートパターン・キーを共有し、かつ出発/到着時刻の差が $\le \epsilon$ である場合に、$\epsilon$-等価であるとみなされます。
   • 最大の $\epsilon$-等価ペア数に基づいた、時間許容型のジャカード距離を計算します。
   • このレイヤーは、厳密な違いが単なる小さなタイミングのずれであるかどうかを判断します。

3. 構造的比較可能性の診断:

   • 小さな一致を全体のスケジュールの類似性と過剰に解釈することを防ぐため、フレームワークは以下を計算します：
     • 一致シェア ($M_\epsilon$): 許容範囲内でペアリング可能なトリップの割合。
     • トリップ数不均衡 ($Q$): 2つのDayType間における総トリップ数の相対的な差。
     • 未一致カウント ($U_\epsilon$): ペアリングできなかったトリップの数。
   • これにより、「同じスケジュールのタイミングがシフトしたもの（高い $M_\epsilon$、低い $Q$）」と「構造的なサービス変更（低い $M_\epsilon$、高い $Q$）」を区別します。

3. 主な貢献

1. 定式化： 車両や乗務員のスケジューリングとは異なる、再帰的な供給オブジェクトとしてルートパターンとDayTypeを定義した。
2. 安定した抽出： 管理上のIDの再ラベル付けに対して不変なH3ルートパターン・キーを用いたGTFS抽出手順を開発し、長期的なGTFS分析における再現性の問題を解決した。
3. 比較階層： 厳密な監査（厳密）、時間の感度（時間許容）、および構造的変化（診断）を分離するメトリクス体系を提案し、単一の類似性指標の限界に対処した。
4. ダウンストリームへの有用性： 時刻表の同期、車両スケジューリング、需要割り当て、およびミスマッチ診断モデルの入力として機能する、コンパクトな再帰的スケジュールセットを提供する。
5. 実証的検証： 日本とカナダのGTFSフィードを用いてフレームワークを検証し、異なるネットワーク規模やカレンダー符号化戦略にわたって、抽出が成功することを示した。

4. 結果と知見

本フレームワークは、日本の40機関およびカナダの38機関の公共交通機関に適用されました。

• 抽出の成功： アルゴリズムは、手動介入なしにすべての機関で再帰的なDayTypeを特定することに成功し、標準的な週次サイクル（平日/土曜日/日曜日）、休日例外、および単日例外を復元しました。
• DayTypeの数： 両国における非空のDayTypeのメディアン値は、機関あたり4でした。しかし、日本の機関はカナダの機関（最大17）と比較して高い変動性（最大39）を示しており、これは日本のサンプルにおける、より詳細な休日/季節カレンダーを反映しています。
• 非連結性分析：
  • 厳密な非連結性： 多くの機関において、トリップを共有しないDayTypeのペア（ジャカード距離 = 1.0）が存在しました。これは、カナダ（36%の機関）では日本（15%の機関）よりも一般的でした。
  • 許容の影響： 時間許容（1〜5分）を適用すると、カナダの多くの「厳密に非連結な」ペアにおいて、いくらかのマッチングが発生しました。これは、それらが類似の構造を持つタイミングのバリエーションであったことを示唆しています。一方、日本では厳密な非連結性がより持続しており、これはサービス体制間の構造的な分離がより強いことを示しています。
  • 構造的な実態： 許容範囲内で一致を獲得したとしても、メディアンの一致シェアは依然として低く（カナダで6.3%、日本で0%）、トリップ数の不均衡が高かった。これは、多くの「非連結な」DayTypeが、単なるスケジュールのシフトではなく、根本的に異なるサービス量やルートセットを表していることを裏付けています。
• ネスト（包含関係）： 日本の機関の69%、カナダの機関の58%において、完全なネスト（あるDayTypeが別のDayTypeの厳密な部分集合である状態）が観察されました。これは、段階的なサービスの削減が両地域において一般的な慣行であることを示しています。

5. 重要性と主張

本論文は、自らの貢献を新しい最適化アルゴリズムではなく、**「手法的な表現レイヤー」**として位置付けています。その重要性は以下の点にあります：

• ギャップの架け橋： 生の断片化されたGTFSデータを、ダウンストリームのモデル（例：欠損関数分析、車両スケジューリング）が必要とする再帰的な供給オブジェクトへと接続します。
• 安定性： サービスの識別を管理上のIDから切り離すことで、フィードのリリースにわたるスケジュールの進化に関する信頼性の高い長期的分析を可能にします。
• 微細な解釈： 提案されたメトリクス階層は、軽微なタイミングのノイズを構造的なサービス変更と誤分類することを防ぎつつ、厳密なスケジュールの偏差を監査する能力を維持します。
• コンパクトな表現： 大規模で日付固有の時刻表を、コンパクトな再帰的DayTypeのライブラリへと変換することで、より効率的なスケジューリング、需要割り当て、およびミスマッチ分析を促進します。

著者らは、GTFSにはDayTypeが明示的に定義されていないものの、それらは暗黙的にエンコードされており、本フレームワークを用いることで堅牢に抽出および比較が可能であり、高度な交通計画および分析のための不可欠な基礎を提供すると結論付けています。