軌跡検索エンジンT-Torch 論文紹介 鳥越貴智 2021/02/26 データサイエンス共有会 #meetup_ds

T-Torch (Paper) Torch: a Search Engine for Trajectory Data (ACM SIGIR 2018) 第一著者のSheng Wangは、この後も軌跡系の論文を発表している。 ● Fast Large-Scale Trajectory Clustering (PVLDB 14) ● A Survey on Trajectory Data Management, Analytics, and Learning (SIGMOD 2021)

T-Torch (Code) tgbnhy/torch-trajectory: The World's First Search Engine for Trajectory Data Javaで書かれているが、Maven Centralなどでのパッケージ公開はしていない様 子。「git clone」すれば「mvn package」で、jarのビルドはできる。 ライセンスも宣言されていないため、あくまで論文実装という雰囲気。OSSとし て整備すれば需要はありそうだが……。

No content

Boolean Search ● Range Query: クエリの矩形内を一点でも通過した軌跡を検索。 ● Path Query: クエリのパスと一点でも重なる軌跡を検索。 ● Strict Path Query: クエリのパスを部分列として含む軌跡を検索。

Similarity Search 　クエリの軌跡に対して、類似度の高い順にK個の軌跡を取ってきたい。 　元論文では、6つの類似度を対象としている。

Similarity Measures（記号列系） ● Longest Overlapping Road Segment (LORS): 提案類似度。LCSSの亜種。 ● Longest Common Subsequence (LCSS): 最長共通部分列長。 ● Edit Distance on Real sequence (EDR): 近ければ一致とみなす編集距離。 マップマッチング済みの エッジ長を足しこむ つまり重みのあるLCSS いかにも 動的計画法な 再帰式

Similarity Measures（点の距離ベース） ● Dynamic Time Warping (DTW): 時系列データの類似度。点の数依存。 ● Hausdorff Distance: 部分空間の距離。 ● Frechet Distance: 犬のリードに例えられる距離。

Upper Bounding LORS 軌跡長nと軌跡長mのLORSの計算量はO(nm) Similarity Search時、候補の軌跡ごとにO(nm)は重いので、まず上限を抑える。 軌跡Qと軌跡Tに共通するエッジの長さを合計するだけ。順番は考慮しない。 それぞれソート済みであれば、共通集合取る計算量はO(n + m)

（所感）LORSの使い所 ● 同じ道は通ってないけれど並行する道路を走っている軌跡は類似度0になるの で、そういった軌跡も引っ掛けたい場合は適していない。 ● 代わりに、記号列系の処理のため、DTWやFreshetよりはいかにも速そう。 ● 長距離の軌跡で同じ幹線道路を通ったかどうかが重要な場合は使えそうだが、 マップマッチングでレーン分裂してないかどうかなどは気をつけたい。 ● LORSでいい場合は、LORSのUpper Boundをそのまま類似度として使っても、 実データ上はあまり問題ない気がする。そうそう折り返さないと思うので……

　 Pruning for LORS クエリ軌跡Qに含まれるマップマッチング済みエッジqごとに エッジ転置インデックスI_eを引いて エッジqを含む軌跡を候補集合canに加える。 候補軌跡ごとにLORS上限値を計算してソートする。 LORS上限値が高い軌跡から順に、実際のLORSを計算して、 Top-kのLORSが、残りのLORS上限値全てを上回ったら停止する。 ※ 最悪、全候補軌跡のLORSを計算する可能性はあるはず。

Edge Inverted Index Patched Frame of reference on Deltas (PFor-Delta) は、差分列をブロックごとに基準値から差分を取る。 Variable Byte (VByte) は、バイトごとに先頭1ビットを使って可変長数値を区切る。 どちらも転置インデックスでよく使われる圧縮方式らしい。 第11回　転置索引の圧縮：検索エンジンはいかにして動くのか？｜gihyo.jp trajectory id → edge position → 同じエッジ持つ軌跡 が近くなるように IDを振り直して 圧縮効率を上げる 赤く囲ったところを Edge Inverted Index として最終的に保存 1 2 3 4

　 Pruning for LCSS/EDR 以下、LORSと同じ。 19行、20行は、 LORSは上限値計算時の共通部分列を覚えていれば、 軌跡の全エッジを覚えてなくてもいいよね、 他の類似度だとそういうことはできないよね、 という主張のようだが、LCSSでも同様のことはできるはず。 クエリ軌跡に含まれるバーテックスqごとに、 半径τ内に含まれるセルq’についてグリッドインデックスI_vを引いて、 セルq’を通る軌跡を候補集合canに加える。 元論文では、 LCSS/EDRはマップマッチングせず、 距離τ内のバーテックスを一致とみなす。 類似度選択とマップマッチングは別軸なので ちょっとズルい比較な気がする。 空間インデックスであれば R木やkd木など グリッドでなくてもよい。

Upper Bounding DTW/Hausdorff/Frechet DTW/Hausdorff/Frechetについても、距離のマイナスを類似度として上限値、 すなわち距離の下限値を抑えていきたい。 クエリ軌跡Qのバーテックスqiごとに半径rの正方形を取り、 その中に入っていない軌跡Tのバーテックスへの距離を下からrで抑える。 DTWの足し合わせる数の上限は |Q| ではなく |Q| + |T| だと思われる。

　 Pruning for DTW/Hausdorff/Frechet Top-kの類似度が、残りの上限値全てを上回ったら停止する。 クエリ軌跡に含まれるバーテックスqごとに、 半径r_min + g*i_IRSの正方形に重なるセルq’について グリッドインデックスI_vを引いて、 セルq’を通る軌跡を候補集合canに加える。 停止するまで、セルの大きさを徐々に広げていく。

実験結果：データセット Proto (GeoLink)とT-Drive (Microsoft)はどちらもタクシーの軌跡データセット。 経路探索エンジンGraphHopper (OSS)でOpenStreetMapにマップマッチング。

実験結果：ストレージ使用量 → 類似度によって使うインデックスの使用量のみカウント マップマッチング ↓ PFor/VByteによる圧縮 ↓ 軌跡ID振り直し ↓ ↑ ↑ trajectory edge ID position → R木を使うと使用量が膨れる

実験結果：クエリ時間 Map: クエリ軌跡をマップマッチング ？ Filter: 類似度の上限値を計算しながら候補洗い出し？ Refine: 正確な類似度を計算？

実験結果：ロバスト性 LORSとLCSSの差の主因はマップマッチングっぽいので、ズルい比較な気がする。 P@k: top-k result precision NDCG@k: normalized DCG レコメンドつれづれ　～第3回 レコメンド精度の評価方法を学ぶ～

（所感）まとめ 類似軌跡検索は、類似度に応じて「マップマッチング」「転置インデックス」 「空間インデックス」「上限抑えてフィルタリング」をうまく組み合わせたアル ゴリズムを作ることで、重い類似度計算の対象をできるだけ減らすことが重要。 マップマッチングについてはGraphHopperなどのライブラリ、「転置インデック ス」「空間インデックス」についてはElasticsearchなどの検索エンジンがすでに あるため、実用的な軌跡検索を実装するのはそこまで難しくないかも？