【ITニュース解説】I Built a Real-Time Public Transport Map for the Netherlands — Here’s What I Learned

オランダで公共交通機関のリアルタイム地図「OVspot」を開発した経験は、単に「車両を地図に表示する」というシンプルなアイデアが、いかに複雑なエンジニアリングプロジェクトに発展するかを教えてくれた。このプロジェクトの目的は、従来の経路検索アプリとは異なり、電車、バス、トラム、フェリーといった公共交通機関が今現在、オランダのどこを走っているのかを、遅延情報や目的地、運行状況まで含めて一目でわかるようにすることだった。

開発の最初の大きな課題は、全ての交通機関が同じようにリアルタイムの位置情報（GPSデータ）を提供しているわけではないという点だった。一部の車両は最新のGPSデータを持っているが、他の多くの車両は時刻表の情報しかない。GPSデータを持つ車両だけを表示すると、地図上から広範囲の交通機関が消えてしまう。そこでOVspotでは、GPSデータがない車両のために、時刻表の情報からそのおおよその位置を計算して表示する仕組みを導入した。これはGTFSという公共交通機関の運行スケジュールや路線形状、停車駅などのデータを利用して、時刻表上の進行状況から、車両が路線上のどの位置にいるべきかを推定する技術だ。例えば、アムステルダムのフェリーやワッデン諸島のフェリーなど、GPSデータがない交通機関の位置推定にこの方法が活用されている。ただし、OVspotではGPSによる「正確な位置」と、時刻表から推定した「おおよその位置」を明確に区別して表示することで、ユーザーにデータの信頼度を正しく伝える工夫をしている。

「ライブ」とされるデータにも様々な品質レベルがあることを理解するのは非常に重要だった。データが最新のGPS情報なのか、リアルタイムの運行更新に基づくものなのか、時刻表から計算されたものなのか、あるいは一時的なシステム障害の後にキャッシュされた古いデータなのか。これらの違いは、データの信頼性に大きく影響する。OVspotでは「ライブ」「推定」「時刻表」といった状態を区別して表示することで、地図が示す情報が実際のデータの確実性を超えないようにしている。これは一見すると小さなユーザーインターフェースの工夫に見えるかもしれないが、ユーザーが地図の情報にどれくらいの確信を持ってよいかを判断するために不可欠な要素だ。

次に直面したのは、数百、数千もの車両が同時に地図上を動く際のパフォーマンス問題だった。少数のマーカーを表示するのは簡単だが、多くの動く車両をラベル付きで、インタラクション可能に、かつ継続的に更新しながら表示するのは非常に負荷が高い。通常のウェブページ要素（DOM）を使った描画方法では、車両数が増えるとすぐに動作が遅くなってしまった。この問題を解決するために、より高度な描画技術であるCanvasベースのレンダリングを採用し、ズームレベルに応じて表示するラベルの数を調整したり、詳細度を変えたり、画面に映っている範囲の車両だけを優先的に描画したりといった様々な最適化を行った。パンやズーム操作中のフレームレートを計測しながら改善を進めた結果、パフォーマンスは単に後から調整するものではなく、製品設計の段階から考慮すべき重要な要素であると強く認識するに至った。

車両をクリックしたときに表示される情報ポップアップも、予想以上に複雑な進化を遂げた。当初は簡単な情報表示だったものが、路線名、目的地、運行会社、遅延状況、データ品質、直前の停車駅、次の停車駅、全行程の進行状況、到着予定時刻など、非常に詳細な情報を含むようになった。特に、言葉遣い一つにも細心の注意を払う必要があった。例えば、車両が最後に停車した場所を示す際に「ここにいる」と表示すると、実際にはその車両がすでに数百メートル移動している可能性があり、誤解を招く。そのため、OVspotでは車両が実際に停車駅から約50メートル以内にいて、ほぼ静止している場合にのみ「ここにいる」と表示し、それ以外の場合は「通過した」と表示するように変更した。このような小さな変更が、インターフェースの正確さとユーザー体験を大きく向上させる。

公共交通機関のデータは、実に多くの「エッジケース」、つまり特殊な状況や例外を含んでいることも大きな発見だった。路線の形状データが欠損していたり、運行IDが不足していたり、データが古かったり、駅名が重複していたり、事業者の命名規則が異なったり、存在しない座標が送られてきたり、乗客に見せるべきではない回送車両のデータがあったり、運行中に時刻表が変更されたりするなど、挙げればきりがない。地図に表示する前の段階で、これらの不整合なデータを予測可能な形式に変換し、クリーンアップする作業がプロジェクトの大部分を占めていた。さらに、誤った車両データ、例えば「座標が0,0になっている」「現実離れした地域を走っている」「ありえない速度で移動している」「路線から大きく外れている」といった異常値を検出し、信頼できないデータを地図に表示しないようにする仕組みも重要だった。誤った座標一つで、バスが突然アフリカ大陸に表示される、といった事態も実際に発生したのだ。

検索機能も当初の想定よりはるかに複雑になった。車両番号、駅名、停車地、路線番号など、様々な種類の検索に対応するだけでなく、検索結果をクリックした際には、単にリストを表示するだけではなく、地図が自動的に対象の車両や駅に移動し、適切なズームレベルに調整され、関連する情報ポップアップが開くようにすることで、ユーザー体験の質が大きく向上した。

このプロジェクトを通じて学んだ重要な教訓はいくつかある。第一に、リアルタイムデータは単純に「ライブ」ではないということ。データの鮮度、出所、信頼性を常に理解する必要がある。第二に、GTFSデータは単なる時刻表情報だけでなく、路線の形状情報などと組み合わせることで、驚くほど正確な位置推定を可能にする強力なツールであること。第三に、地図のパフォーマンスはバックエンドのデータサイズ、更新頻度、レンダリング戦略、ユーザーインターフェースの複雑さなど、システム全体の問題として捉えるべきであること。第四に、「ここにいる」と「通過した」のような小さな言葉遣いが、ユーザーが情報をどう解釈するかに大きく影響するということ。そして最後に、プロジェクトの大部分は「通常」のケースではなく、「エッジケース」、つまり特殊な状況や例外への対応に費やされるということだ。一般的なケースは簡単に実現できるが、多くのエンジニアリング時間は、予期せぬ問題やデータの不整合を解決することに費やされるのだ。OVspotは現在も進化を続けており、毎日新たなエッジケースに遭遇しながら、より良いシステムを目指して改善が続けられている。