公共交通機関のみを経由して最適なルートを見つけるための戦略は？
車のルートを見つけるのは非常に簡単です。すべての道路の加重グラフを保存し、 ダイクストラのアルゴリズム [1]を使用できます。バス路線はあまり明白ではありません。バスでは、「次のバスを10分間待つ」、「1つのブロックを別のバス停まで歩く」などの表現をして、それらを経路探索アルゴリズムに入力する必要があります。
車にとっては必ずしも簡単ではありません。一部の都市では、一部の道路は、朝は片道のみで市内に入り、夕方は片道のみで市内から出ます。一部の高度なGPSは、ラッシュアワーの混雑したルートを回避する方法を知っています。
このような時間依存のグラフを効率的に表現し、ルートを見つけるにはどうすればよいでしょうか。確かに最適なソリューションは必要ありません。旅行者が時間通りに行きたいのなら、彼らは車を買うでしょう。 ;-)
[1] A *がこのアプリケーションに適しているとはいえ、誰もがそれを聞いているので、例で言及する素晴らしいアルゴリズム。
私はスウェーデンのストックホルム公共交通機関向けの1つのジャーニープランナーシステムの開発に携わってきました。これはダイクストラのアルゴリズムに基づいていましたが、システム内のすべてのノードにアクセスする前に終了しました。今日、各停車地で利用できる信頼できる座標がある場合、A *アルゴリズムが選択されると思います。
今後のトラフィックに関するデータは、いくつかのデータベースから定期的に抽出され、検索サーバークラスターのメモリに読み込まれる大きなテーブルにコンパイルされました。
アルゴリズムを成功させるための1つの鍵は、移動時間と待機時間に異なる重みを掛けたものに基づくパスコスト関数を使用することでした。スウェーデン語では「kresu」時間として知られています。これらの加重時間は、たとえば、1分の待機時間は通常「不便」で2分の移動時間に相当するという事実を反映しています。
KRESUウェイトテーブル
- x1-移動時間
- x2-停車地間を歩く
- x2-旅行中に停車するのを待っています。屋根の下の停車場やお店などでは、アルゴリズムを調整するために、重量をわずかに減らし、混雑した駅を高くすることができます。
- 最初の停車地での待機時間の重みは、トラヒック密度の関数であり、0.5〜3の間で指定できます。
データ構造
エリア旅を開始または終了できる名前付きエリア。バス停は、2つの停留所があるエリアである可能性があります。複数のプラットフォームがある大規模な駅は、プラットフォームごとに1つの停車地がある1つのエリアにすることができます。データ：名前、エリアで停止
停留所すべてのバス停、電車、地下鉄の駅が並ぶ配列。通りを渡ったり、他のプラットフォームまで歩いたりするのに時間がかかるため、通常は各方向に1つずつ、合計2つの停車地が必要です。データ：名前、リンク、ノード
リンクこの停留所から歩いて行くことができる他の停留所のリスト。データ：他の停車地、他の停車地まで歩く時間
Lines/Toursバスと目的地に番号があります。バスは1つの停留所から出発し、目的地に向かう途中で複数の停留所を通過します。データ：番号、名前、宛先
ノード通常、ツアーの最初と最後の停車地にあるべき時間は最短です。バス/電車が停車駅を通過するたびに、アレイに新しいノードを追加します。このテーブルには、1日あたり数百万の値が含まれる可能性があります。データ：ライン/ツアー、停車地、到着時間、出発時間、許容誤差、次のNode in Tour
検索到達方法とパスコストを格納するために使用されるNodes配列と同じサイズの配列。データ：前のバックリンクNode（Nodeが未訪問の場合は設定されません）、パスコスト（未訪問の場合はinfinit）
あなたが話していることは、グラフのような単純なデータ構造やダイクストラのような「単純な」アルゴリズムで記述できる数学モデルのようなものよりも複雑です。あなたが求めているのは、自動化されたロジスティクス管理の世界で遭遇するような、より複雑な問題です。
それについて考える1つの方法は、多次元の問題を求めているということです。次のことを計算できる必要があります。
- 距離の最適化
- 時間の最適化
- ルートの最適化
- 「タイムホライズン」の最適化（5:25で、バスが7:00にしか表示されない場合は、別のルートを選択してください）。
これらすべての状況を考えると、複雑な多層データ構造を使用して決定論的モデリングを試みることができます。たとえば、加重有向グラフを使用して既存の潜在的なルートを表すこともできます。各ノードには、時間値に応じてルートに加重バイアスを追加する有限状態オートマトンも含まれています（5:25にノードを通過することにより）シミュレーションが7:00に交差した場合とは異なる値を取得します。）
ただし、この時点で、シミュレーションがますます複雑になり、アドバイスが現実の世界に転送されたときに最適なルートの「優れた」近似が得られない可能性が高いと思います。ソフトウェアと数学的モデリングとシミュレーションは、現実世界の混沌とした振る舞いとダイナミズムに遭遇したとき、せいぜい弱いツールであることがわかります。
私の提案は、別の戦略を使用することです。個人のDNAが潜在的なルートを計算する遺伝的アルゴリズムを使用しようとし、次に、より「保守が容易な」ルックアップテーブル方式でコストと重みをエンコードする適応度関数を作成します。次に、遺伝的アルゴリズムに、公共交通機関のルートファインダーのほぼ最適なソリューションに収束させようとします。最近のコンピューターでは、このようなGAはおそらくかなりうまく機能し、現実世界のダイナミズムに対して少なくとも比較的堅牢であるはずです。
この種のことを行うほとんどのシステムは、「簡単な方法」を取り、A *検索アルゴリズムのようなもの、または貪欲なコストの重み付き有向グラフウォークに似たものを実行すると思います。覚えておくべきことは、公共交通機関のユーザー自身が最適なルートが何であるかを知らないということですだろうしたがって、90％の最適なソリューションは平均的なケースの優れたソリューションになるでしょう。
公共交通機関の分野で知っておくべきいくつかのデータポイント：
- 転送ごとに、ライダーの心に10分のペナルティが発生します（時間指定の転送でない限り）。つまり、精神的には、1本のバスで40分かかる旅行は、乗り換えが必要な30分の旅行とほぼ同じです。
- ほとんどの人がバス停まで歩いても構わないと思っている最大距離は1/4マイルです。駅/ライトレール約1/2マイル。
- 距離は公共交通機関のライダーとは無関係です。 （時間だけが重要です）
- 頻度が重要です（接続が失われた場合、次のバスまでの時間）。代替手段が次の急行のために1時間立ち往生している場合、ライダーはより頻繁なサービスオプションを好むでしょう。
- 鉄道はバスよりも優先度が高い（電車が正しい方向に行き来するという確信が強い）
- 新しい運賃を払わなければならないことは大ヒットです。 （約15〜20分のペナルティを追加します）
- 合計旅行時間も重要です（上記のペナルティ付き）
- 接続はどの程度シームレスですか？ライダーはにぎやかな通りを横切る駅が存在する必要がありますか？それとも、電車を降りてバスまで4歩歩くだけですか。
- 混雑した通りを横断する-転送のもう1つの大きなペナルティ-は、十分な速さで通りを横断できないため、接続を逃す可能性があります。
車のルートを見つけるのは非常に簡単です。すべての道路の加重グラフを保存し、ダイクストラのアルゴリズムを使用できます。バス路線はあまり明白ではありません。
あまり明白ではないかもしれませんが、現実には、無限のコスト計算が追加された、自動車の問題に対する単なる別の側面です。
たとえば、過去のバスに無限のコストがあるとマークすると、それらは計算に含まれません。
次に、各側面の重み付け方法を決定します。
通過時間は1倍に重み付けされる可能性があります待機時間は1倍に重み付けされる可能性があります転送は0.5倍に重み付けされる可能性があります（もっと早く到着して追加の転送が必要なため）
次に、無限のコストを追加した通常のコストアルゴリズムを使用して、グラフ内のすべてのルートを計算します。
エッジに沿って移動するたびに、「現在の」時間を追跡する必要があり（通過時間を合計）、ベクトルに到達した場合は、現在の時間より前のバスに無限のコストを割り当てる必要があります。現在の時間は、次のバスが出発するまでそのベクトルでの待機時間によって増分されます。その後、別のエッジに沿って自由に移動し、新しいコストを見つけることができます。
つまり、最初のバスの発車時刻である「現在時刻」という新しい制約があり、バスと停車地のすべての通過時間と待機時間を合計したものです。
アルゴリズムは少しだけ複雑になりますが、アルゴリズムは同じです。ほとんどのアルゴリズムをこれに適用でき、複数のパスが必要な場合もあれば、時間を追加できないために機能しないものもあります->無限のコスト計算をインラインで。しかし、ほとんどは問題なく動作するはずです。
バスがスケジュールどおりであり、常に別のバスがあると仮定するだけで、さらに単純化できますが、待機時間が長くなります。アルゴリズムは通過コストのみを合計してから、ツリーを再度通過し、次のバスがいつ来るかに応じて待機コストを追加します。効率の悪いバージョンになることもありますが、大都市でさえ全体のグラフは実際にはかなり小さいので、実際には問題ではありません。ほとんどの場合、1つまたは2つのルートが明らかに勝者になります。
Googleにはこれがありますが、あるバス停から別のバス停まで歩くための追加のエッジも含まれているため、大規模なバスシステムのある都市を歩く場合は、もう少し最適なルートを見つけることができます。
-アダム
旅行の各区間のコストが時間内に測定される場合、唯一の複雑さはスケジュールを考慮に入れることです-これは、各ノードのコストを現在の時間tの関数に変更するだけです。ここで、tは単なる合計旅行時間です。 far（スケジュールがt = 0で開始するように正規化されていると仮定）。
したがって、10分のコストを持つNode Aの代わりに、次のように定義されるf(t)のコストがあります。
- t1 = nextScheduledStop（t）; //時刻t以降の次の停止時刻を取得する
- 脚のbaseTime = 10 //たとえば、10分の旅行
- 戻り値（t1-t）+ baseTime
したがって、待機時間は各区間のコストに動的に含まれ、バス停間の歩行は一定の時間コストを持つ単なる弧です。
この表現を使用すると、A *またはダイクストラのアルゴリズムを直接適用できるはずです。
この問題について私が考える方法は、最終的には、開始点から終了点までの平均速度を最適化しようとしているということです。特に、邪魔にならないようにすれば時間を節約できるのであれば、総移動距離はまったく気にしません。したがって、ソリューションスペースの基本的な部分は、開始と終了の間の比較的高速で、合計距離の重要な部分をカバーする利用可能な効率的なルートを特定する必要があります。
元々、GPSナビゲーションユニットが車で旅行するために使用する典型的な自動車ルートアルゴリズムは、目標の最適な合計時間と最適なルート評価に適しています。言い換えれば、あなたのバスベースの旅行は、車ベースのソリューションにアプローチするのに本当に良いことです。明らかに、バスルートベースのシステムには、自動車ベースのソリューションよりもはるかに多くの制約がありますが、自動車ソリューションを参照（時間と距離）として持つことで、バスアルゴリズムに最適化するためのフレームワークが提供されます*。したがって、大まかに言えば、車のソリューションを可能なバスソリューションのセットに向けて反復的にモーフィングするか、おそらく可能なバスソリューションを採用して、車ベースのソリューションに対してスコアを付け、「良い」かどうかを判断します。 。
これをもう少し具体的にすると、特定の出発時間に対して、総距離のかなりの割合をカバーできる合理的な期間内に利用できるバスの数は限られています。ストレート自動車分析合理的な期間および距離のかなりの割合に基づく）いくつかのやや主観的な指標を使用して定量化できるようになります。確かに、より絶対的な意味で、他の可能性と比較してそれぞれの可能性をスコアリングすることがより簡単になります。
ソリューション内で可能な回答として利用可能な主要なセグメントのセットを取得したら、それらを他の可能なウォーキングパスおよび待機パスとフックする必要があります....または十分に離れている場合は、追加の短いバスの実行を再帰的に選択します。直感的には、制約パラドックスのために、ここで法外な選択肢のセットが実際に存在することはないようです（以下の脚注を参照）。そこからすべての可能な組み合わせをブルートフォースすることができない場合でも、残っているものは シミュレーテッドアニーリング （SA）タイプのアルゴリズムを使用して最適化できるはずです。 モンテカルロ法 は別のオプションです。
この時点まで問題を分解した方法は、SAアルゴリズムがASICの自動レイアウトとルーティングに適用される方法に非常に類似したものを残します=チップ、FPGA、およびそのタイプの問題フォームの最適化に関してかなりの量の 公開された作業 プリント回路基板の配置とルーティング。
*注：私は通常、これを「制約のパラドックス」と呼んでいます-私の用語です。人々は当然、より制約された問題を解決するのが難しいと考えることができますが、制約は選択肢を減らし、選択肢が少ないほどブルートフォース攻撃が容易になります。総当たり攻撃が可能な場合は、最適なソリューションも利用できます。
あなたの問題はあなたが予想するよりも複雑だと思います。最近のCOSTアクションは、この問題の解決に焦点を当てています。 http://www.cost.esf.org/domains_actions/tud/Actions/TU1004 ： "高度道路交通システムの時代における公共交通機関の乗客の流れのモデル化"。
私の見解では、通常のSPSアルゴリズムはこれには適していません。動的なネットワーク状態があり、前進するための特定のオプションが無意味です（ルートは常に車、自転車、歩行者用に「開かれ」ていますが、トランジット接続は特定の滞留時間にのみ利用可能です）。
ここでは、新しいポリクリテリアル（時間、信頼性、コスト、快適さ、その他の基準）アプローチが望まれていると思います。 1）情報をエンドユーザーに短時間で公開する2）リアルタイムでパスを調整できるようにするためにリアルタイムで計算する必要があります（リアルタイムの交通状況に基づいて-ITSから）。
私は今後数ヶ月間（おそらく博士論文を通してさえ）この問題について考えようとしています。
よろしくラファル
基本的に、グラフ内のノードは、場所を表すだけでなく、そこに到達できる最も早い時間を表す必要があります。あなたはそれを（場所、時間）空間でのグラフ探索と考えることができます。さらに、（place、t1）と（place、t2）があり、t1 <t2の場合、（place、t2）を破棄します。
理論的には、これにより、開始ノードからすべての可能な宛先の最も早い到着時刻が取得されます。実際には、目的地から離れすぎている道路を剪定するためのヒューリスティックが必要です。
また、有望なルートを目的地から遠ざける前に、有望なルートを検討するためのヒューリスティックが必要です。
この問題に取り組んでいるとしたら、おそらく注釈付きのグラフから始めます。グラフの各ノードは、公共交通機関がそこで停止するかどうかに関係なく、市内のすべての交差点を表します。これは、歩く必要性などを説明するのに役立ちます。交通機関のある交差点では、これらに停止ラベルを付けます。停止のサービススケジュールを検索します。
次に、選択することができます。可能な限り最良のルートが必要ですか、それとも単にルートが必要ですか？ルートをリアルタイムで表示していますか、それともソリューションを計算してキャッシュできますか？
「リアルタイム」計算が必要な場合は、ある種の欲張りアルゴリズムを使用することをお勧めします。 A *アルゴリズム はおそらくこの問題領域にかなりうまく適合すると思います。
最適なソリューションが必要な場合は、 動的計画法 グラフのソリューションを確認する必要があります...最適なソリューションの計算にはかなり時間がかかる可能性がありますが、見つける必要があるのは1回だけで、キャッシュできます。 。おそらく、A *アルゴリズムは、事前に計算された最適パスを使用して、「類似した」ルートに関する決定を通知することができます。
あなたは自分で質問に答えています。 A *またはダイクストラのアルゴリズムを使用して、あなたがする必要があるのは、各ルートの部分ごとの適切なコストを決定することだけです。
バスルートの場合、最短ルートではなく最速ルートが必要であることを意味します。したがって、ルートの各部分のコストには、その部分のバスの平均移動速度と、バス停での待機が含まれている必要があります。
その場合、最適なルートを見つけるためのアルゴリズムは以前と同じです。 A *を使用すると、すべての魔法はコスト関数で発生します...
これらの特定のニーズに対応する特別なデータ構造は他にないと思いますが、リンクリストなどの通常のデータ構造を使用して、特定の要素ごとにルート計算を行うことができます-何らかの入力が必要になります結果に影響を与える変数のアプリを作成し、それに応じて、つまり入力に応じて計算を行います。
待機などに関しては、これらは特定のノードに関連する要因ですよね？この係数を、ノードに接続されている各ブランチのルートノードに変換できます。たとえば、Node Xからのすべてのブランチについて、Node Xでm分待つ場合は、の重みをスケールアップします。 [m/Some base value * 100]％で分岐します（単なる例）。このようにして、他の要因を均一に考慮し、同時に解決したい問題の単純な表現を維持します。
脚の重さを変える必要があります。たとえば、雨の日は、雨の中を歩くよりも車で長く移動する方がいいと思います。さらに、歩くことを嫌う人や歩くことができない人は、歩くことを気にしない人とは異なる/長い旅行をする可能性があります。
これらのエッジはコストですが、コストの概念/概念を拡張することができ、それらは異なる相対値を持つことができると思います。
アルゴリズムは同じままで、さまざまなシナリオ（バスのスケジュールなど）に従って各グラフエッジの重みを増やすだけです。
少し前にグラフパス検索の演習として地下鉄ルートファインダーをまとめました。
恐ろしく非効率的な方法は、市内の各交差点のコピーを1日の1分ごとに保存することです。 ElmSt。と2ndからMainSt。と25thへのバス路線は、たとえば、
Elm_st_and_2nd[12][30].edges :
Elm_st_and_1st[12][35] # 5 minute walk to the next intersection
time = 5 minutes
transport = foot
main_st_and_25th[1][15] # 40 minute bus ride
time = 40 minutes
transport = bus
Elm_st_and_1st[12][36] # stay in one place for one minute
time = 1 minute
transport = stand still
このグラフでお気に入りのパスファインディングアルゴリズムを実行し、適切な仮想メモリの実装を祈ってください。