はじめに
不動産のスペックでは、駅や高速道路、空港や最寄の都市などまでの所要時間や距離が重要です。特に取引時の表示では、最寄駅までの徒歩分数は「道路距離80メートルにつき1分」と、直線距離ではなく道に沿った正確な数字が必要になります。
駅とインターチェンジは非常によく似た施設だと思っていました。例えば駅もインターチェンジも、乗り降り・出入りする場所です。各社のAPIを使うと、駅もインターチェンジもその座標を「代表点」で得られ、今回使った経路APIではありがたいことに、経路が「屋内」や「施設内」、「一般道」や「自動車専用道路」に判別されていました。
私には駅からの徒歩分数を求めた経験があります。駅からの経路はAPIを呼び出して少し後処理するだけで求められたため、ほとんど同じ考え方でインターチェンジまでの経路も計算できると思っていたのですが、かなり苦戦しました。同じように苦しむ人を減らしたいし、よりよい方法があれば知りたいのでブログにしました。
駅までの経路の求め方
経路APIがあれば、駅までの徒歩分数は比較的簡単かつ直感的な方法で取得できます。APIは下記の様なJSONを返してくれるので、不動産の代表点から駅の代表点までの徒歩経路をAPIで求め、屋内部分を除けばほとんど完了します*1。APIのレスポンスは経路が細かい直線（線分）の集まりで表現され、それぞれに屋内（indoor=true）かどうかなどの情報が含まれるものを想定しています。
{ "status": "ok", "response": { "total_distance": 300, "route": [ { "from": {"lat": 35.0000, "lon": 135.0000}, "to": {"lat": 35.0001, "lon": 135.0000}, "distance": 100, "indoor": false }, { "from": {"lat": 35.0001, "lon": 135.0000}, "to": {"lat": 35.0001, "lon": 135.0001}, "distance": 100, "indoor": true }, { "from": {"lat": 35.0001, "lon": 135.0001}, "to": {"lat": 35.0002, "lon": 135.0002}, "distance": 100, "indoor": true } ] } }
正確に最短経路を求めるためには、不動産の敷地内のどこから駅のどの出入口までの経路にするかなどの工夫が必要になります。住宅やオフィスなどの建物の種類（アセットタイプ）によって少し計算方法が違うなどもありますが、代表点同士の経路を求めるという直感的な方法で完結します。
インターチェンジの難しさ
駅までの経路を求めた際に比較的すぐにうまく行った経験から、インターチェンジ（IC）までの経路を考えるにあたっても"indoor"の代わりに"highway"がtrue/falseかを見る程度であまり違いはなさそうだと思っていました。しかしICや自動車には駅や歩行者にはない様々な性質がありました。
1つ目 代表点への到達が困難
まず、自動車が逆走できない性質に苦労しました。ICの代表点は料金所ではなくICの中央付近に置かれていましたが、ICの中央付近にはそのICの入口から到達できないことが多いのです*2。高速道路を逆走するわけにはいかないので、下の図で言うと入口bから入った自動車はICの代表点を通らないまま高速道路を走り始めてしまい、ICの代表点への経路では入口bまでの経路を（部分的にも）得られません。
2つ目 4種類全ての出入口を持つとは限らない
先ほどは典型的なICの構造として図を書きましたが、「ハーフIC」や「クォーターIC」という一部の出入口のみしか持たないICもあります。ICへの経路とICからの経路が少し異なるだけでなく、片方がそもそも存在しない場合もあります。
3つ目 代表点は上りか下りのどちらかの車線にある
API依存かもしれませんが、代表点から/までの経路を求めるとき、上りか下りのどちらかの車線だと判断されました。すると、図のように上側の車線だと判断された場合には出入口c, dを使った経路は出ません。
解決手法
まず、不動産から最寄ICの代表点までの経路Aを求めます。紫線で表すこの経路は大抵は最寄のICの入口を使ってくれず、その直前のICの入口を使いますがこれでOKです。直前のICの入口から不動産までの経路（赤線）を求めると、最寄のICの出口aから不動産までの経路赤太線が得られます。
入口bについても同様にして、ICの代表点から不動産までの経路（緑線）を求めることで直後のICの出口が得られ、不動産からその直後のICの出口までの経路（青太線）が候補になります。
さらに反対車線についても同様に行えば、出入口a, b, c, dの全ての候補を検索できます。ちなみに反対車線の推定には、例えば経路AからIC付近での進行方向を得て、右方向に20メートルほどズラすなどで対応できます。
このように、8回APIを使うことで出入口a, b, c, dを使った経路を求められるので、その中の欲しい経路（例えば最短経路）を求めればOKです。
その他の工夫
道路によって反対車線の位置はまちまちですが、ICがある場所での大まかな方針としては20メートルずらす手法で精度がよさそうです。SA併設などで大きく変えたり、反対車線の経路が出なければズラす量を変えて再探索したりなど、細かい工夫も可能です。
ICの出入口を判定してくれるAPIもあると思いますが、一般道と自動車専用道路が切り替わった点の座標とICの代表点の位置や距離などでも想定通りの出入口を使えたか確認できます。用途によっては料金所までの経路が必要かもしれません。
カーナビAPIなら、一般道優先検索を使うと直前や直後のICを見つけやすくなりますし、出発地/目的地が高速道路上かを指定するオプションも使えます。特に高速道路上かのオプションは有用でした。
今回はAPIを8回も呼ぶため、時間やお金がかかる方法となってしまっています。ここはコスト的にもセンス的にもよりよい方法を知りたいです。しかし全ての経路を候補としないと特に珍しい構造のICで求めたい経路とは大きく異なる経路を見つけてしまいました。途中で経路が見つかっても全通り検索するのをオススメします。さらに言えば、①の最寄のICまでの経路で求める経路が得られることもあります。高速道路の終点では特によくあるパターンです。
中継点を使った経路探索を使えば呼び出し回数やそれに応じた料金を減らせます（例えば、不動産→IC→不動産で計算すれば1つ目と3つ目の経路が同時に得られます）。
おわりに
歩行者と違って自動車が一方通行である性質や、経路を求めるという状況においては出入口の位置が代表点との相性が悪い性質を考え、このような何度もAPIを使う手法で解決しました。今回は経路APIを使う方法を紹介しましたが、道路の（有向）グラフがあれば、ダイクストラ法を使ってもいいと思いますし、API以外の解法もあると思います。
データの持ち方は建物とICの中間テーブルのように持つといいのか、それとも”到達圏”として持つといいのか……といった課題もあります。不動産の交通利便性の扱いについて、まだまだ悩みはつきません。
