マップ上のポイントAからポイントBへの方向を計算するアルゴリズムは何ですか？

マッププロバイダー（GoogleやYahoo!マップなど）はどのように方向を提案しますか？

つまり、確かに距離だけでなく、車の速度、歩道の存在、列車のスケジュールなど、実際のデータが何らかの形で含まれている可能性があります。距離を反映するエッジウェイトを使用します。任意のポイントから別のポイントへの方向をすばやく計算できるようにしたいと考えています。これらのポイントは（1つの都市内で）互いに接近している場合もあれば、遠く離れている（国をまたがる）場合もあります。

ダイクストラのアルゴリズムのようなグラフアルゴリズムは、グラフが巨大であるため機能しません。幸い、A *のようなヒューリスティックアルゴリズムはおそらく機能します。しかし、私たちのデータは非常に構造化されており、おそらく何らかの階層化アプローチが機能する可能性がありますか？（たとえば、離れた特定の「キー」ポイント間の事前計算された方向といくつかのローカル方向を保存します。2つの遠く離れたポイントの方向には、キーポイントへのローカル方向、別のキーポイントへのグローバル方向、ローカル再び方向。）

実際に使用されているアルゴリズムは何ですか？

PS。この質問は、オンラインマッピングの方向に癖を見つけることによって動機付けられました。三角形の不等式とは対照的に、Googleマップでは、XZの方がXYZのように中間点を使用するよりも時間がかかり、遠いと見なされることがあります。しかし、おそらく彼らの歩行方向も別のパラメータに最適化されていますか？

PPS。ここでは、三角形の不等式に対する別の違反があり、XZとXYZのような階層型アプローチを使用していることが（私には）示唆されています。前者は少し遠く離れていますが、有名なセバストポル通りを使用しているようです。

編集：これらの例はどちらももう機能していないようですが、どちらも元の投稿の時点では機能していました。

ルーティングアルゴリズムの作業を含め、マッピング会社で18か月働いた人と言えば、はい、ダイクストラはいくつかの変更を加えて機能します。

• ソースから宛先までダイクストラを 1回実行する代わりに、両端から開始し、中央で出会うまで両側を拡張します。これにより、約半分の作業（2 * pi *（r / 2）^ 2 vs pi * r ^ 2）が排除されます。
• 出発地と目的地の間にあるすべての都市の裏通りを探索することを避けるために、マップデータのいくつかのレイヤーを作成できます：高速道路のみを含む「高速道路」レイヤー、二次道路のみを含む「二次」レイヤーなど。次に、より詳細なレイヤーの小さなセクションのみを探索し、必要に応じて拡張します。明らかに、この説明では多くの詳細が省略されていますが、あなたはそのアイデアを理解しています。

これらのラインに沿った変更により、非常に妥当な時間枠で国をまたがるルーティングを行うこともできます。

この質問は、ここ数年で活発な研究分野となっています。主なアイデアは、グラフの前処理を1回実行して、後続のすべてのクエリを高速化することです。この追加情報により、旅程を非常に高速に計算できます。それでも、ダイクストラのアルゴリズムはすべての最適化の基礎です。

Arachnidは、階層型情報に基づく双方向検索とエッジプルーニングの使用法について説明しました。これらの高速化手法は非常にうまく機能しますが、最新のアルゴリズムは、これらの手法よりも必ず優れています。現在のアルゴリズムでは、大陸の道路網では1ミリ秒よりもかなり短い時間で最短経路を計算できます。ダイクストラの変更されていないアルゴリズムを高速に実装するには、約10秒かかります。

記事高速ルート計画アルゴリズムのエンジニアリングでは、その分野における研究の進捗状況の概要を説明しています。詳細については、その論文のリファレンスを参照してください。

最速の既知のアルゴリズムは、データ内の道路の階層ステータスに関する情報を使用しません。つまり、高速道路または一般道路の場合です。代わりに、前処理ステップでルート計画を高速化するために最適化された独自の階層を計算します。次に、この事前計算を使用して検索をプルーニングできます。ダイクストラのアルゴリズムでは、出発地から遠く離れた低速道路を考慮する必要はありません。利点は、非常に優れたパフォーマンスと結果の正確性の保証です。

最初の最適化されたルートプランニングアルゴリズムは静的な道路ネットワークのみを扱いました。つまり、グラフのエッジには固定コスト値があります。交通渋滞や車両依存の制限などの動的な情報を考慮したいので、これは実際には当てはまりません。最新のアルゴリズムでもこのような問題に対処できますが、解決すべき問題がまだあり、研究は進行中です。

TSPのソリューションを計算するために最短パス距離が必要な場合は、送信元と宛先の間のすべての距離を含む行列におそらく関心があります。このために、ハイウェイ階層を使用して多対多の最短経路を計算することを検討できます。これは、過去2年間の新しいアプローチによって改善されていることに注意してください。

三角形の不平等違反に対処するだけで、うまくいけば、それらが最適化する余分な要素は常識です。カオス や 破壊につながる可能性があるため、必ずしも最短または最速のルートを希望するわけではありません。トラックに適した主要ルートを優先し、衛星ナビゲーションをフォローしているすべての運転手にそれらを送信することに対処できるルートを希望する場合は、三角形の不等式をすばやく破棄します[1]。

YがXとZの間の狭い住宅街である場合、ユーザーがXYZを明示的に要求した場合にのみ、Yを介したショートカットを使用する必要があります。彼らがXZを要求する場合、少し遠く、少し長くても主要道路に固執する必要があります。それはブレスのパラドックスに似ています -誰もが最短で最速のルートをとろうとすると、結果として生じる輻輳はそれがもはや誰にとっても最速のルートではないことを意味します。ここから、グラフ理論からゲーム理論へと逸脱します。

[1]実際、生成された距離が数学的な意味で距離関数になるという希望は、一方通行の道路を許可して対称性の要件を失うと死にます。三角形の不平等を失うことも、傷の塩をこするだけです。

以下は、比較のために正確性が証明された世界最速のルーティングアルゴリズムです。

http://algo2.iti.uka.de/schultes/hwy/schultes_diss.pdf

これは主題についてのグーグル技術話です：

http://www.youtube.com/watch?v=-0ErpE8tQbw

これは、シュルテスによって議論されたハイウェイ階層アルゴリズムの実装です（現在ベルリンのみで、私はインターフェイスを作成しており、モバイルバージョンも開発されています）。

http://tom.mapsforge.org/

私はこれまでにGoogle、Microsoft、Yahooマップに取り組んだことがないので、どのように機能するのかはわかりません。

ただし、私は、エネルギー会社向けに、トラック群用のスケジューリングおよびルーティングアプリケーションを含むカスタムサプライチェーン最適化システムを設計しました。ただし、ルーティングに関する私たちの基準は、建設や交通の遅れ、車線の閉鎖の場所よりもはるかにビジネス固有のものでした。

トラックのスケジュールと配線には、ACO（Antコロニー最適化）と呼ばれる手法を採用しました。このテクニックは、ルーティングの問題を解決するために巡回セールスマン問題に適用されたAIテクニックです。ACOの秘訣は、ルーティングの既知の事実に基づいてエラー計算を作成し、グラフ解決モデルがいつ終了するか（エラーが十分小さい場合）を認識できるようにすることです。

ACOまたはTSPをグーグルして、この手法の詳細を見つけることができます。ただし、私はこれにオープンソースAIツールを使用していません。そのため、提案することはできません（SWARMはかなり包括的であると聞きましたが）。

ダイクストラのアルゴリズムのようなグラフアルゴリズムは、グラフが巨大であるため機能しません。

ダイクストラは通常、完全なグラフではなく、非常に小さなサブセットのみを見るので、この議論は必ずしも成り立ちません（グラフの相互接続が良好であるほど、このサブセットは小さくなります）。

Dijkstraは実際には、行儀の良いグラフに対してかなりうまく機能する場合があります。一方、注意深くパラメーター化すると、A *は常に同じかそれ以上のパフォーマンスを発揮します。あなたはすでにあなたのデータでそれがどのように機能するかを試しましたか？

とはいえ、他の人の経験についても聞いてみたいと思います。もちろん、Googleマップの検索のような著名な例は特に興味深いものです。指示された最近傍のヒューリスティックのようなものを想像できます。

静的道路ネットワークのクエリ時間に関する現在の最新技術は、Abrahamらによって提案されたハブラベル付けアルゴリズムです。http://link.springer.com/chapter/10.1007/978-3-642-20662-7_20。この分野に関する徹底的で優れた調査が最近、Microsoftテクニカルレポートhttp://research.microsoft.com/pubs/207102/MSR-TR-2014-4.pdfとして公開されました。

ショートバージョンは...

ハブのラベル付けアルゴリズムは、静的道路ネットワークに対して最速のクエリを提供しますが、実行するには大量のRAM（18 GiB）を必要とします。

トランジットノードのルーティングはわずかに遅くなりますが、必要なメモリは約2 GiBであり、前処理時間が短縮されます。

縮約階層は、前処理時間の短縮、必要な領域が少ない（0.4 GiB）、クエリ時間の高速化をうまく両立させます。

完全に支配的なアルゴリズムはありません...

ピーターサンダースによるこのGoogleテックトークは興味深いかもしれません

https://www.youtube.com/watch?v=-0ErpE8tQbw

Andrew Goldbergによるこの講演も

https://www.youtube.com/watch?v=WPrkc78XLhw

収縮階層のオープンソース実装は、KITのPeter Sanders研究グループのWebサイトから入手できます。http://algo2.iti.kit.edu/english/routeplanning.php

また、CRPアルゴリズムの使用方法についてマイクロソフトが書いた簡単にアクセスできるブログ投稿... http://blogs.bing.com/maps/2012/01/05/bing-maps-new-routing-engine/

ここで言及されているフロイドウォーシャルのアルゴリズムが表示されないことに少し驚いています。このアルゴリズムは、ダイクストラのアルゴリズムと非常によく似ています。また、非常に優れた機能が1つあります。これにより、より多くの中間頂点を許可し続けたい限り、計算を行うことができます。そのため、州間高速道路や高速道路をかなり迅速に使用するルートが自然に見つかります。

私はこれを何度も行ってきましたが、実際には、いくつかの異なる方法を試しました。マップのサイズ（地理的）によっては、haversine関数をヒューリスティックとして使用することを検討できます。

私が作成した最良の解決策は、ヒューリスティック関数として直線距離でA *を使用することでした。ただし、マップ上の各ポイント（交差または頂点）に何らかの座標が必要です。また、ヒューリスティック関数に異なる重み付けを試すこともできます。

f(n) = k*h(n) + g(n)

ここで、kは0より大きい定数です。

おそらく、主要な場所とレイヤードマップの間の事前に計算されたルートに関する回答に似ていますが、私の理解では、ゲームでは、A *を高速化するために、マクロナビゲーションには非常に粗いマップがあり、マクロ方向の境界へのナビゲーション。したがって、計算する2つの小さなパスがあるため、検索スペースは、目的地への単一のパスを実行するよりもはるかに小さくなります。そして、これを頻繁に行うビジネスの場合、そのデータの多くは事前に計算されているため、検索の少なくとも一部は、パスの検索ではなく、事前計算されたデータの検索です。

これは私の側の純粋な推測ですが、検索ドメインを絞り込むために、有向マップをオーバーレイするインフルエンスマップデータ構造を使用している可能性があります。これにより、目的の旅行が長い場合に、検索アルゴリズムが主要ルートにパスを送ることができます。

これがGoogleアプリであることを考えると、多くの魔法が大規模なキャッシュを介して行われると想定することも合理的です。:)上位5％の最も一般的なGoogleマップルートリクエストをキャッシュして、リクエストの大きなチャンク（20％？50％？）が単純なルックアップで応答できるようになっていても驚くことはありません。

私はこれについてもう少し考えました：

1）地図は物理的な組織を表すことを忘れないでください。すべての交差点の緯度/経度を保存します。ターゲットの方向にあるポイントをはるかに超えてチェックする必要はありません。自分がブロックされている場合にのみ、これを超える必要があります。上位の接続のオーバーレイを保存する場合は、さらに制限することができます。通常、最終的な宛先から離れるような方法でそれらのいずれかを通過することはありません。

2）制限された接続によって定義される一連のゾーン全体に世界を分割し、ゾーン間のすべての接続ポイントを定義します。位置から各接続ポイントへの開始および終了ゾーンルートについて、接続ポイント間の単純なマップ間のゾーンについて、ソースとターゲットがどのゾーンにあるかを見つけます。（後者の多くはすでに事前に計算されていると思います。）

ゾーンは大都市圏よりも小さい場合があることに注意してください。それを分割する地形フィーチャ（たとえば、川）がある都市は、複数のゾーンになります。

使用されているヒューリスティックに非常に興味がありました。しばらく前に、サンタローザ近くの同じ出発点からヨセミテ国立公園の2つの異なるキャンプ場までのルートを取得しました。これらの異なる目的地は、両方のルートが最後の数マイルで再び分岐する前に最後の100マイル（CA-120に沿って）に収束したという事実にもかかわらず、（I-580またはCA-12を介して）まったく異なるルートを生成しました。これはかなり繰り返しました。2つのルートは約100マイルで最大50マイル離れていましたが、距離/時間は予想通り互いにかなり近かったです。

悲しいかな、私はそれを再現することはできません-アルゴリズムは変更されたに違いありません。しかし、それは私がアルゴリズムに興味を持っていました。私が推測できるのは、遠方から見た場合の目的地間の小さな角度の違いに非常に敏感である方向性剪定があったか、または最終目的地の選択によって異なる事前計算されたセグメントが選択されたということです。

OpenStreetMapに基づく高速なオープンソースルートプランナーであるGraphHopperと言えば、少し文献を読んだり、いくつかのメソッドを実装したりしました。最も簡単な解決策はダイクストラであり、簡単な改善は双方向のダイクストラであり、ノードのおよそ半分のみを探索します。双方向のダイクストラでは、ドイツ全体を通るルートはすでに1秒かかります（車モードの場合）。Cでは、たった0.5秒程度です;）

ここで、双方向ダイクストラを使用した実際のパス検索のアニメーションGIFを作成しました。また、「目標指向のダイクストラ」であるA *のようにダイクストラを高速化するためのアイデアがいくつかあります。また、gifアニメーションを作成しました。

しかし、どうすれば（大幅に）速くなりますか？

問題は、パス検索の場合、ロケーション間のすべてのノードを探索する必要があることです。これは、ドイツではすでに数百万存在しているため、非常にコストがかかります。ただし、ダイクストラなどのもう1つの問題は、そのような検索で大量のRAMを使用することです。

ヒューリスティックな解決策がありますが、グラフ（道路ネットワーク）を階層的に整理する正確な解決策もあります。どちらも長所と短所があり、主に速度とRAMの問題を解決します。これらのいくつかをこの回答に記載しました。

GraphHopperの場合、実装が比較的「簡単」で、グラフの準備に時間がかかることがないため、収縮階層を使用することにしました。オンラインインスタンスのGraphHopper Mapsでテストできるように、それでも非常に高速な応答時間が得られます。たとえば、南アフリカから中国東部までの距離は23000kmで、車での走行時間は約14日で、サーバーで約0.1秒しかかかりませんでした。

私は数年間ルーティングに取り組んできましたが、最近の急増はクライアントのニーズによって引き起こされましたが、A *は十分に高速であることがわかりました。最適化やより複雑なアルゴリズムを探す必要は本当にありません。巨大なグラフ上でのルーティングは問題ではありません。

しかし、速度はルーティングネットワーク全体に依存します。これは、ルートセグメントとジャンクションをそれぞれ表すアークとノードの有向グラフをメモリに持つことを意味します。主な時間のオーバーヘッドは、このネットワークを作成するのにかかる時間です。Windowsを実行している通常のラップトップと、スペイン全土へのルーティングに基づく大まかな数値：ネットワークの作成にかかる時間：10〜15秒。ルートの計算にかかる時間：測定するには短すぎます

もう1つの重要なことは、必要なだけのルーティング計算にネットワークを再利用できるようにすることです。アルゴリズムが何らかの方法でノードにマークを付けて、最良のルート（現在のノードへの総コスト、およびノー​​ドへの最良のアーク）を記録した場合-A *の場合と同様に、この古い情報をリセットまたはクリアする必要があります。数十万のノードを通過するよりも、世代番号システムを使用する方が簡単です。各ノードにデータの世代番号を付けます。新しいルートを計算するときに世代番号を増やします。古い世代番号を持つノードは古く、その情報は無視できます。

OPのマップの状況がわかります。

中間点を指定してルートを確認します。直線ではない道路のため、ルートは少し後方に進みます。

それらのアルゴリズムがバックトラックしない場合、短いルートは表示されません。

全ペアの最短経路アルゴリズムは、グラフ内のすべての頂点間の最短経路を計算します。これにより、誰かがソースとデスティネーションの間の最短パスを見つけたいたびにパスを計算する必要がなく、パスを事前に計算できます。Floyd-Warshallアルゴリズムは、すべてのペアの最短パスアルゴリズムです。

マップはマップ全体を考慮に入れません。私の推測は：-1.あなたの場所に応じて、彼らは場所とその場所のランドマークをロードします。2.目的地を検索すると、マップの他の部分が読み込まれ、2か所からグラフが作成され、最短経路アルゴリズムが適用されます。

また、最短経路の計算に使用されていると思われる重要な手法である動的プログラミングがあります。それも参照できます。