説明

経路案内システム

【課題】 経路案内システムにおいて、経路探索時の想定と異なる事情が生じた場合でも、ユーザが指定した探索条件を満たす経路を案内可能とする。
【解決手段】 経路案内システムは、道路のネットワークデータを参照して、ユーザから指定された出発地、目的地間の経路を探索し、経路案内を行うシステムである。経路探索時には、目的地への到着希望時刻、日陰優先などの探索条件も指定可能とする。経路案内システムは、ユーザの移動速度などの想定に従って、探索条件を満たす経路を探索する。経路探索時に想定した事情と異なる事情が経路案内時に生じた場合、ユーザから指定された探索条件を満たすことができないと判断される時には、経路探索を再試行して、新たな経路を案内する。こうすることで、想定と異なる事情が生じた場合でも、ユーザが指定した探索条件を満たす経路を案内することが可能となる。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ユーザからの指定に従って経路を探索し、案内する経路案内システムに関し、詳しくは経路を通行する時刻に依存した探索条件を反映して経路探索および案内を行う経路案内システムに関する。
【背景技術】
【0002】
経路案内システムとは、ユーザが指定した出発地から目的地までの経路を探索し、案内する装置であり、カーナビゲーションシステム等として知られている装置である。近年では、歩行者に対して経路を案内するための装置も提案されている。経路案内システムは、スタンドアロンで稼働するものもあれば、携帯電話などの端末とサーバとをネットワークで接続して構成されたものもある。経路案内システムにおける経路探索では、ダイクストラ法と呼ばれるアルゴリズム、即ち道路をノード、リンクで表したネットワークデータを参照し、各ノード、リンクに付されたコストの総和が最小となる経路を探索する手法が用いられることが多い。
【0003】
経路案内システムで経路探索を行うための条件は、目的地までの距離が最短となる条件、所要時間が最短となる条件など種々の指定が可能である。歩行者用の経路案内システムでは、更に、階段や上り坂を回避するなどの条件を指定可能とした経路探索も提案されている。車両を対象とした経路案内システムにおいて、直射日光を避ける経路を探索するものも提案されている(特許文献1参照)。これらの探索条件が指定された場合、経路案内システムは、探索条件に従ってノード、リンクに付されたコストを変動させることにより、所望の経路を得ることができる。
【0004】
こうして得られた経路を案内する際には、ユーザの現在位置をGPS(Global Positioning System)などで取得し、地図上に現在位置および経路を表示する方法が採られる。これらの表示と併せて、音声での案内を行うものもある。ユーザが進路を誤って、経路から逸脱した場合、経路案内システムは、リルート、即ちユーザの現在位置から目的地に至る経路を再度探索する処理を実行し、案内を継続する(特許文献2参照)。
【0005】
【特許文献1】特開2004−226199号公報
【特許文献2】特開2003−232645号公報
【発明の開示】
【発明が解決しようとする課題】
【0006】
経路を探索する際には、目的地への到着希望時刻など、時刻に依存する探索条件(以下、「時刻依存条件」という。)を指定することも可能である。このような探索条件が指定された時には、経路案内システムは、ユーザの移動速度などについて予め用意された想定値を用いて探索条件に合致する経路を探索する。
【0007】
しかし、時刻依存条件が指定された場合、探索された経路を案内通りに通行していても探索時には予測できなかった状況変化が起き、探索された経路が、結果として探索条件を満たさなくなることがある。例えば、目的地への到着希望時刻が指定された場合、探索時よりもユーザの移動速度が遅い時には、案内された経路を通行していたとしても指定された到着希望時刻に遅れてしまうことが生じ得る。また、直射日光を避ける経路を指定した場合も、ユーザの移動速度が遅ければ、案内された経路は日陰から日向に変わっていることが起こり得るし、ユーザの移動速度が速ければ、逆にまだ日陰になっていないということも起こり得る。これらの状況は、ユーザの移動速度が経路探索時の想定速度よりも速すぎたり、遅すぎたりした場合だけでなく、ユーザの出発時刻が経路探索時の想定時刻とずれたり、案内途中でユーザが寄り道をしたり、案内途中で事故その他の事情により通行に支障が生じたりした場合などにも生じ得る。経路案内時の状況が経路探索時に想定した状況に完全に適合していることは稀であるから、上述の状況は、かなりの頻度で生じ得る。従って、従来の経路案内システムでは、時刻依存条件を指定した場合、十分に実用的な経路案内を行うことはできてはいなかった。本発明は、かかる課題に鑑み、経路案内システムにおいて、時刻に依存する探索条件を満足できるようにすることを目的とする。
【課題を解決するための手段】
【0008】
本発明は、ユーザからの指定に従って経路を探索し、案内する経路案内システムとして構成することができる。本発明の経路案内システムは、通行可能な道路をノード、リンクで表したネットワークデータを参照し、指定された出発地、目的地間で経路探索を行う。出発地については、ユーザからの指定としてもよいし、ユーザの現在位置をデフォルトの指定として用いるようにしてもよい。経路探索は、ユーザからの入力、プログラムでの既定値、予め用意されたデータベースからの読込などの方法で特定された探索条件に基づいて行う。この探索条件には、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度が含まれる。時刻依存条件には、目的地への到着希望時刻、目的地に至るまでの所定の地点への到着希望時刻、および各時刻における日当たり、温度、風向き、霧の発生、気温変化に伴う凍結状態など季節や日時に応じた変化を示す気象状態に基づく条件などが含まれる。基準時刻としては、現在時刻や出発予定時刻などを用いることができる。想定移動速度は、歩行時、自転車時、車両時などユーザの移動手段に応じて予め設定された値を使い分けるようにしてもよいし、ユーザから指定するようにしてもよい。
【0009】
経路案内システムは、経路探索の他、ユーザの現在位置を入力し、現在位置に応じて探索された経路の経路案内を行う。経路案内中には、所定のタイミングで、ユーザの現在位置および現在時刻を入力し、現在位置および現在時刻が、案内すべき経路についての時刻依存条件を満たすか否かを判定する。そして、時刻依存条件が満たされないと判断される場合には、現在位置を出発地とし、現在時刻を基準時刻として経路探索を再試行する。こうすることにより、経路探索時に想定した状況と経路案内時の状況が異なる場合でも、時刻依存条件を満足する経路探索を実現することができる。従って、本発明は、時刻依存条件が指定された場合でも、実用的な経路案内を実現することができる。
【0010】
本発明の経路案内システムは、歩行者を対象とする時に、より有用性が高い。時刻に依存する探索条件は、歩行者を対象とする経路探索では、より重視される傾向にあるからである。例えば、歩行者を対象とする経路探索では、目的地への到着希望時刻は、駅や停留所を目的地とする経路探索において、交通機関のダイヤを踏まえて設定されることが多い。このような場合には、到着希望時刻に遅れてしまうとユーザが望んでいた電車、バスに乗り遅れることになってしまう。また、日当たりを避けたいなどの探索条件についても、車両では屋根で遮られたり、窓ガラス越しに日が当たったりするなど、日当たりに対する緩和要素が存在するのに対し、歩行者ではこれらの緩和要素が存在しない分、日当たりに対する探索条件は重視される。このように歩行者を対象とする経路探索では、時刻依存条件がより重視される傾向にあるため、本発明の利点がより活かされることになるのである。
【0011】
時刻依存条件は、例えば、目的地または目的地に至るまでの所定の地点への到着希望時刻とすることができる。経路案内システムは、探索された経路に沿って、想定移動速度で移動した場合の所要時間を求めることにより、目的地または所定の地点への到着予測時刻を求めることができるから、この到着予測時刻に基づいて到着希望時刻の条件が満たされているか否かを判断することができる。経路案内システムは、到着希望時刻が指定された時、該到着希望時刻までに到着するという条件として扱っても良いし、到着希望時刻の前後所定時間内に到着するという条件として扱ってもよい。到着希望時刻の指定が有用となる一例として、例えば、交通機関のダイヤを踏まえて駅や停留所への到着希望時刻を指定する場合や、時間帯に応じて一方通行その他の交通規制が変動する箇所が経路上に含まれる場合などが挙げられる。
【0012】
時刻依存条件の他の例として、日当たり、温度、風向き、霧の発生、気温変化に伴う凍結状態など季節や日時に応じた変化を示す気象状態に基づいて指定する条件(以下、「気象条件」という。)が挙げられる。これらの気象条件は日々の天候によって変動するものの、例えば、経路上の各地点、各時刻における晴天時の日当たりは十分に予測可能である。温度や風向き、霧の発生、気温変化に伴う凍結状態なども、それぞれの季節、各時刻に応じて平均的な状態を予測可能である。経路案内システムは、ノード、リンクの少なくとも一部について、各時刻における気象条件を予測するための気象データを参照可能することにより、気象条件を反映した経路探索を実現することができる。この気象データは、例えば、各ノード、リンクの属性として、時刻ごとの気象条件を対応づけるテーブル等の形で用意することができる。日当たりのように、太陽の位置、および建物の形状等から演算可能な気象条件については、これを演算で求めるためのデータを気象データとして用意してもよい。また、例えば、経路探索を行う日の天気予報データをネットワーク経由で取得し、時刻に応じた降水確率を気象条件として用いるようにしてもよい。
【0013】
経路案内システムは、経路探索を再試行する際には、ユーザの想定移動速度を所定の条件に従って変更させるようにしてもよい。例えば、一定の値または比率で初期の想定移動速度を速めたり、遅くしたりしてもよいし、従前の平均移動速度を用いるようにしてもよい。こうすることにより、経路探索時の想定移動速度と、現実の移動速度との差違を縮めることが可能となり、更に再試行を行う必要が生じる可能性を抑制することができる。
【0014】
探索条件が、複数の条件を含む場合、これらの各条件に対して優先順位を設定可能としてもよい。優先順位は、ユーザが指定してもよいし、所定の規則に従って自動的に設定してもよい。優先順位が設定されている場合には、経路案内システムは、経路探索を再試行する際には、劣後する条件を緩和してもよい。経路探索の再試行時には無条件に条件を緩和するようにしてもよいし、従前の探索条件を全て満たす経路が探索できない場合にのみ緩和するようにしてもよい。経路案内システムは、このように経路探索条件を緩和することにより、全ての探索条件を満たす経路が存在しない場合でも、経路を探索することが可能となる。これは、時刻依存条件を他の探索条件よりも優先的に扱っていることを意味している。このように時刻依存条件を優先的に扱うことにより、経路案内システムの実用性をより向上させることができる。
【0015】
経路探索の再試行を行うか否かは種々のタイミングで判断することができる。例えば、ユーザが、案内すべき経路上に予め設定されたチェックポイントに至った時点でこの判断を行うようにしてもよい。チェックポイントは、一定の間隔で設定するようにしてもよいし、交差点など経路を変更可能な地点としてもよい。また、チェックチェックポイントは、案内すべき経路に沿って、目的地までの距離が小さくなるにつれ、段階的または連続的に密となるよう設定してもよい。目的地に近づくほど密にするのは、経路探索時点から長時間を経ていることになり、経路探索時に想定していた状況からの差違が拡大していると考えられ、頻繁に再試行の要否を判断することが好ましくなると考えられるからである。再試行の判断は、これらのチェックポイントで行う他、所定の時間が経過する度に行うようにしてもよい。
【0016】
本発明において、以上で説明した種々の特徴は、必ずしも全てを備えている必要はなく、その一部を省略したり、適宜、組み合わせたりして採用することができる。また、本発明は、上述した経路案内システムとしての態様のみならず、コンピュータを用いて経路を案内する経路案内方法として構成してもよい。更に、上述した経路案内を実現するためのコンピュータプログラムや、かかるコンピュータプログラムを記録した記録媒体として構成してもよい。ここで、記録媒体としては、フレキシブルディスクやCD−ROM、光磁気ディスク、ICカード、ROMカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置(RAMやROMなどのメモリ)および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。
【発明を実施するための最良の形態】
【0017】
本発明の実施例について以下の順序で説明する。
A.システム構成:
B.データ構造:
C.経路案内例:
D.経路案内〜全体処理:
E.経路探索処理:
F.気象条件の反映:
G.リルート例:
H.変形例:
【0018】
A.システム構成:
図1は実施例としての経路案内システムの構成を示す説明図である。本実施例では、歩行者用の経路案内システムとしての構成例を示すが、車両用の経路案内システムとして構成することもできる。経路案内システムは、携帯電話を利用した端末100とサーバ200とをネットワークINTで接続して構成されている。ネットワークINTは無線通信を利用したネットワークであり、LANやイントラネットのように限定的なものであってもよいし、インターネットのように広域的なものであってもよい。端末100は、携帯電話の他、いわゆる車両用のナビゲーション装置やPDA、ネットワーク通信機能を有するパーソナルコンピュータなどを利用することができる。歩行者用の経路案内システムとして構成する場合、車両用のナビゲーション装置は、車両から取り外して携帯可能としておくことが望ましい。
【0019】
端末100は、ユーザの操作に応じて、経路探索および経路案内に必要な指示をサーバ200に送信するための機能を奏する。図中には、端末100の機能ブロックを併せて示した。端末100は、CPU、RAM、ROMを備えたマイクロコンピュータを制御装置として内蔵しており、このCPUはROMに記憶されたソフトウェアを実行することで、図示する各機能ブロックを構成する。これらの機能ブロックは、このようにソフトウェア的に構成する他、ハードウェア的に構成することも可能である。
【0020】
通信部120は、ネットワークINTを介してサーバ200と通信する機能を奏する。GPS140は、全地球測位システム(Global Positioning System)を利用して、端末100の現在位置の緯度、経度を検出する。コマンド入力部130は、スイッチ等に対するユーザ操作に基づいて、経路探索や経路案内に関するコマンドを入力する。コマンドとしては、図示した通り、経路探索の目的地の指定、探索条件の指定などが挙げられる。表示制御部150は、端末100のディスプレイに、これらのコマンド入力用のメニューを表示したり、サーバ200から受信した経路案内データに基づいて地図を表示させたりする。主制御部110は、上述した各機能ブロックを統括制御することで、端末100の全体機能を制御する。
【0021】
サーバ200は、端末100からのコマンドに基づいて、種々のデータベースを参照しながら、経路探索を行ったり、経路案内を行ったりする。図中には、これらの機能を実現するための機能ブロックおよびデータベースの例を示した。各機能ブロックは、サーバ200のCPUが実行するコンピュータプログラムによって、ソフトウェア的に構成されるが、ハードウェア的に構成することも可能である。
【0022】
サーバ200が利用するデータベースは地図DB250、時刻表DB252、ユーザDB254の3種類である。地図DB250は、通路をノード、リンクで表したネットワークデータ、および地図描画用のポリゴンや文字データからなる描画データを有している。本実施例では、ノードおよびリンクの少なくとも一部には、許容される通行態様が時刻によって変化するものが存在する。この規制条件としては、例えば、出発時刻が規定されている公共交通機関、所定時刻になると閉鎖される駅構内の通路などが挙げられる。時刻表DB252は、この規制条件を記録するデータベースである。また、本実施例では、後述する通り、日当たりなど、時刻に応じて変動する気象条件も考慮して経路探索を行うことができる。時刻表DB252は、各時刻での気象条件を推測するために要求されるデータも記録している。地図DB250および時刻表DB252のデータ構造については後述する。
【0023】
ユーザDB254は、ユーザID、氏名などの書誌的な登録情報と共に、ユーザが歩行する際の移動速度に関する設定や、距離優先/時間優先などの経路探索に関する要望事項を格納している。図中にはユーザDB254の内容として移動速度に関する登録内容を例示した。本実施例では、移動速度は、移動可能な距離と組み合わせて登録されている。図中の例では、通常利用される移動速度(以下、「通常速度」と呼ぶこともある)は「4km/h」であり、移動可能な距離には制約がないことを表している。やや早足の「5km/h」では、3kmまで移動可能であり、駆け足の「10km/h」では0.5kmまで移動可能であることを表している。これらの情報は、ユーザが端末100を操作して登録、変更可能である。図中の例では、3通りの移動速度が登録されているが、更に多くの移動速度を登録可能としてもよい。
【0024】
通信部220は、端末100とのネットワークINT経由での通信を制御する。経路探索部230は、上述の3種類のデータベースを参照して、ユーザから指定された出発地、目的地間の経路を探索する。経路探索部230は、ユーザからの指示に応じて、地図DB250および時刻表DB252を参照して、経路探索を行う。経路探索方法については後述する。
【0025】
経路案内部240は、探索された経路を地図上に表示して案内するための経路案内データを生成し、端末100に送信する。経路案内部240は、経路案内の過程で、ユーザから指定された探索条件を満たしているか否かを判定し、探索条件が満たされていないと判断する場合には、経路探索部230に経路探索を再試行するよう指示する。経路案内方法については後述する。
【0026】
B.データ構造:
図2は地図DB250および時刻表DB252のデータ構造を示す説明図である。地図DB250については、経路探索用のネットワークデータの構造のみを例示した。図の中央に例示するように、ネットワークデータは、ノードN1〜N8およびリンクL1〜L9等で構成される。リンクL1〜L9は歩行者が通行可能な通路を表しており、ノードN1〜N8はリンクL1〜L9の端点または接続点を表している。
【0027】
地図DB250は、上述のノード、リンクに関するデータを、それぞれノードデータ250N、リンクデータ250Lとして格納し、地物に関するデータを地物データ250Bとして格納している。図中に示す通り、リンクデータ250Lには、リンクID、形状、時刻表、地物、距離などの情報が記録される。形状は、リンクが通過する地点の座標(緯度、経路)を表した点列データである。座標には、高さを表す情報を含めても良い。図中の例では、リンクL9について、ノードN2、N7を含む4点が格納されている。本実施例では、ノードについてはノードIDを格納し、その位置はノードデータ250Nを参照することで得られるようにしたが、ノードについても他の通過地点と同じく座標を格納するようにしてもよい。時刻表とは、時刻表DBに格納されている情報へのリンクを表している。図中の例L9では、時刻に応じて変化する規制条件が付されていないため、時刻表の項目には「無し」が登録されている。後述するように、リンクL3、L4、L6のように時刻に応じて変化する規制条件が付されている場合には、時刻表DB252に格納されているデータのインデックスである「時刻表ID」が格納されることになる。地物とは、そのリンク周辺の地物のIDである。地物の位置、形状は、地物データ250Bを参照することで得られる。距離とは、そのリンクの区間距離である。
【0028】
リンクデータ250Lの内容は、任意に設定可能であり、これらの情報の一部を省略してもよいし、ここに例示していない種々の属性情報を格納するようにしてもよい。例えば、階段や坂道などの経路種別や、ガードレールや街灯などの設備の有無等を属性情報として格納することができる。かかる属性情報が用意されている場合には、「階段を避けたい」、「ガードレールが整備されている経路を優先したい」などの経路に対する要望事項を反映した経路探索を実行することが可能となる。例えば、「階段を避けたい」という要望が出されている場合には、「階段」という属性情報が記録されているリンクのコストを増加させることによって、階段が選択される可能性を抑制することが可能となり、要望に沿った経路を探索することが可能となる。
【0029】
ノードデータ250Nには、図示するようにノードID、位置、時刻表、通行規制などの情報が記録される。「喫茶店」、「コンビニエンスストア」、「銀行」、「郵便局」などノードの種別を表す情報を含めてもよい。ノードの位置は、緯度、経度の座標で記録される。座標には、高さを表す情報を含めても良い。時刻表は、リンクデータ250Lと同様、時刻表DB252に格納されている情報へのリンクを表している。通行規制とは、右左折禁止など、時刻に応じて変化しない固定的な通行規制である。例えば、図中のノードN4について、N3方向から来てN6方向へ左折する通行が禁止される場合には、通行規制欄には、「N3→N4→N6」という形でデータを格納すればよい。通行規制情報の記録方法は、これに限らず、種々の形式を採用することができる。
【0030】
地物データ250Bには、図示するように地物ID、形状、高さ、属性などの情報が記録される。形状は、地物の平面形状を表すポリゴンの各頂点の緯度、経度の座標で記録される。形状の他、地物の代表点の緯度、経度を記録するようにしてもよい。高さは、本実施例では、建物の階数で表すものとしたが、高さの計測値を記録するようにしてもよい。属性は、ビル、ホテル、家屋など、地物の種別を表している。
【0031】
時刻表DB252には、時刻表ID、規制、時刻、開始遅れ、終了遅れなどの情報が格納されている。時刻表IDは、登録されているそれぞれの情報を一義的に示すための識別データである。規制は、時刻表IDが示す規制情報を表している。図中には、駅の入り口G1〜G3が午前0:30〜午前4:30の間で閉鎖され、駅構内のリンクL3,L4,L6が通行不能となる場合のデータを例示した。この場合、通行不能となるため、「規制」欄には、「通行止め」が格納され、時刻欄には、通行止めとなる時刻が格納される。複数の時間帯で通行止めとなる場合には、時刻欄に、複数の時間帯を格納することもできる。開始遅れは、この時間帯の開始時刻(図中の例では0:30)が遅れる可能性を示し、終了遅れは終了時刻が遅れる可能性を示している。駅構内の通行止めについては、規定通りに閉鎖されるため、開始遅れ、終了遅れは「無し」と設定されている。「時刻表ID=1」が付されたこのデータは、リンクL3、L4、L6に適用される。従って、リンクデータ250LのこれらのリンクIDに対応するデータの「時刻表」欄に「1」が格納されることになる。リンクデータの時刻表欄には、複数の時刻表IDを格納可能としてもよい。
【0032】
時刻表DB252には、上述のような「通行止め」の規制の他、種々の規制が格納可能である。例えば、本実施例では、電車などの交通機関の出発時刻も、その路線を通行可能な時間帯が限られているという意味で規制条件の一種とみなし、時刻表DB252で管理するものとした。この場合には、「規制」欄には、例えば、「電車発着」などと格納することで交通機関であることを示し、「時刻」欄に出発時刻および到着希望時刻からなる時刻表を格納することができる。出発時刻と途中の経過駅までの所要時間という形式で格納するようにしてもよい。交通機関の場合には、出発時間や到着希望時刻が遅れる場合がある。出発時間の遅れは「開始遅れ」に記録し、到着希望時刻の遅れは「終了遅れ」に記録することができる。これらの時間は、後述する通り、経路探索時に考慮される値であり、任意に設定可能であるが、一例として、過去所定期間内の平均遅れ時間や最大遅れ時間などに基づいて設定することができる。
【0033】
時刻表DB252には、更に、各時刻における気象条件を求めるためのデータを記録させることもできる。本実施例では、日当たり状況を求めるためのデータ(以下、「日当たりデータ」という。)を記録させるものとした。日当たりデータの設定方法および構造については、後で日当たりを考慮した経路探索の方法を説明する際に、併せて説明する。
【0034】
C.経路案内例:
以下、経路案内の具体例を示した後、これを実現するための処理内容について説明する。図3は経路案内例を示す説明図である。端末100の画面例を示した。図3(a)は、ユーザが出発地Sおよび目的地Gを地図上で指定した状態を示している。出発地Sは、GPS140で検出された現在位置を用いるようにしてもよいし、ユーザが地図上でマウス等のポインティングデバイスで指定してもよい。目的地Gは、ユーザが地図上でポインティングデバイスにより指定したり、地物の名称などから検索したりする方法で指定することができる。
【0035】
図3(b)は、探索条件の入力画面例である。この例では、目的地Gへの到着希望時刻、交通機関の使用可否、屋根、空調、日陰、階段などの探索条件の指定を行う例を示した。「屋根」とは屋根が存在する経路を優先するという条件、「空調」は建物内や地下街など空調が備えられている経路を優先するという条件、「日陰」は日陰になる経路を優先するという条件、「階段」は階段のない経路を優先するという条件である。探索条件には、それぞれ優先順位を設定することができるようになっている。この例では、屋根、空調、日陰の順に優先され、階段については探索条件から外す旨の指定がなされている。
【0036】
図3(c)は、経路案内時の画面例である。ユーザの現在位置PPは黒丸で示され、案内すべき経路はハッチングを付して示される。この経路は、目的地Gに向かう最短経路ではなくやや遠回りした経路となっている。領域Aには、建物が存在しておらず、日当たりが良い地域であるため、「日陰」優先という探索条件に適合しないからである。このように本実施例では、最短経路や所要時間最短となる経路に限らず、ユーザから指定された探索条件に適合する経路を探索する。探索条件を反映した経路探索の方法は後述する。
【0037】
図3(d)は経路案内時の画面例である。案内すべき経路が、図3(c)と異なり、目的地Gへの最短経路となっている。本実施例では、経路案内の過程で、ユーザから指定された到着希望時刻の要求を満たさないと判断される状態になった場合には、再度経路探索を実行し、案内すべき経路を変更する機能を有している(以下、このように再度、経路探索を実行する機能を「リルート」と言う。)。リルート時には、ユーザから指定された探索条件のうち、優先度の低い条件、図3の例では「日陰」という条件を外して経路探索を行う。こうすることにより、到着希望時刻に間に合わないことが懸念される状況では、図3(d)に示すように、日向となる領域Aを通る経路が案内されることになる。
【0038】
リルートは、種々のタイミングで実行することができる。例えば、経路案内を開始した後、一定の時間が経過するたびに行うようにしてもよい。本実施例では、予め設定されたチェックポイントを通過する時点でリルートを行うようにした。
【0039】
図4はリルートのチェックポイント設定例を示す説明図である。チェックポイントの設定にはモードA〜モードDの4つのモードがある。モードAは均等間隔で設定するモードである。図中の黒丸がチェックポイントを表している。図示するように、モードAでは、出発地から目的地まで均等間隔でチェックポイントが設定される。例えば、予め設定された一定の間隔で出発地から順次、チェックポイントを配置するようにしてもよいし、出発地から目的地までを所定数で等分した位置にチェックポイントを配置するようにしてもよい。
【0040】
モードBは交差点にチェックポイントを設定するモードである。交差点は経路の分岐であるから、モードBは経路を変更可能な最小限の箇所でリルートの要否を判断するモードであると言える。従って、モードBによれば、リルートの要否の判断およびリルートに要する処理負担を軽減することができる利点がある。
【0041】
モードCは交通機関の乗降場所にチェックポイントを設定するモードである。図中では、バス停にチェックポイントが設定された例を示した。このモードによれば、経路案内の途中で、徒歩で移動するか、交通機関を利用するかの変更を効率的に行うことができる利点がある。
【0042】
モードDはチェックポイントを不均等間隔に設定するモードである。モードDでは、出発地Sから目的地Gに近づくにつれ、間隔が密となるようにチェックポイントが設定される。つまり、図の例では、チェックポイントCp1、Cp2の間隔L2は、出発地SとチェックポイントCp1との間隔L1よりも短い。同様に、チェックポイントCp3,Cp4,Cp5と進むにつれ、それぞれの間隔は短くなる。経路案内時の状況と、経路探索時に想定されていた状況との差違は、目的地Gに近づくほど大きくなるのが通常である。従って、目的地Gに近づくほどリルートの要否を頻繁に判断することが好ましい。モードDによるチェックポイントの設定には、こうした要請に応えることができる利点がある。
【0043】
チェックポイントは図4に例示した他、種々の方法で設定することができる。図4に示した各モードは単独で用いる必要はなく、例えば、モードBとモードCとを組み合わせるなど、適宜、複数のモードを組み合わせて用いるようにしてもよい。また、複数のモードを組み合わせた場合には、複数のチェックポイントが近接して設定される可能性もある。このような場合には、近接したチェックポイントのうち、いずれか一方のみを選択して用いるようにしてもよい。
【0044】
D.経路案内〜全体処理:
図5は経路案内システムの全体処理のフローチャートである。サーバ200が実行する処理のみを示した。図示を省略したが、この処理の過程で、サーバ200は必要に応じて端末100と通信しており、端末100では、サーバ200に情報を授受するための処理が稼働している。
【0045】
サーバ200は、まず経路探索処理を実行する(ステップS100)。この処理では、サーバ200は、ユーザから出発地、目的地、探索条件等の指定を受け付け、出発地から目的地に至る経路を探索する。経路探索処理の内容は後で詳述する。
【0046】
次に、サーバ200は、探索された経路上に、チェックポイントを設定する(ステップS130)。チェックポイントの設定方法は、図4に示した通りである。モードA〜Dのいずれか一つを固定的に用いるようにしてもよいし、ユーザの指定によってモードを使い分けるようにしてもよいし、出発地から目的地までの距離などに応じて自動的にモードを選択するようにしてもよい。
【0047】
その後、サーバ200はユーザに対して経路を案内するための処理を開始する。まず、端末100から現在位置を入力し(ステップS132)、チェックポイントにいるか否かを判断する(ステップS134)。ユーザが、チェックポイントに到達している場合には、時刻依存条件をクリアするか否か、つまり時刻依存条件を満たすか否かの判定を行う(ステップS136)。この実施例では、目的地への到着希望時刻のみを、ここで言う時刻依存条件として扱う場合を例示する。この場合、サーバ200は、ステップS136では、ユーザの現在位置から目的地までの所要時間を求め、この所要時間を現在時刻に加えることによって、目的地への到着予測時刻を算出する。この到着予測時刻が、指定された到着希望時刻と同時または到着希望時刻よりも前である場合には、サーバ200は、時刻依存条件をクリアしていると判定する。時刻依存条件をクリアしないと判断される場合には、サーバ200は、再度、経路探索処理を実行する(ステップS100)。
【0048】
時刻依存条件をクリアしている場合には、サーバ200は経路案内処理を行う(ステップS138)。ユーザがチェックポイントに至っていない場合にも(ステップS134)、同様である。経路案内処理では、端末100に地図、現在位置、および案内すべき経路を表示する。これらの表示と併せて音声でユーザが進むべき方向を案内するようにしてもよい。経路案内は、これらの表示および音声案内を伴わない方法、例えば、端末100の振動態様によって、ユーザの進行方向を知らせる方法を採ることもできる。サーバ200は、以上の処理を目的地に到達するまで(ステップS140)、繰り返し実行する。
【0049】
E.経路探索処理:
図6は経路探索処理のフローチャートである。サーバ200が実行する処理であり、図5で示した全体処理のステップS100に相当する処理である。サーバ200は、ユーザからの指定に基づき最初に経路探索をする場合には(ステップS102)、ユーザID、出発地、目的地、探索条件、出発時刻を入力する(ステップS104)。出発地、目的地、探索条件の入力には、例えば、先に図3で示したインタフェース画面を用いることができる。探索条件には、時刻依存条件として、目的地への到着希望時刻が指定される。ユーザIDは、ユーザDB254の情報を参照し、経路探索時に用いるユーザの移動速度などのデータを取得するために用いられる。
【0050】
チェックポイントにおいて時刻依存条件がクリアできないと判定された場合に行われる再探索(図5のステップ136、S100参照)の時には(図6のステップS104)、ユーザID等の条件は入力不要なので、ステップS104はスキップする。ただし、本実施例では、再探索時にはユーザの移動速度を変更することとした(ステップS106)。ここで、移動速度は、種々の方法で変更可能である。例えば、移動速度を所定値ずつ、または所定比率で増減させてもよい。また、出発地からチェックポイントに至るまでの従前の平均移動速度を用いるようにしてもよい。
【0051】
こうして、経路探索に必要なデータの入力、設定が完了すると、サーバ200は時刻依存条件を考慮して経路探索を実行する(ステップS110)。本実施例では、以下に示す通り、ダイクストラ法を用いて経路探索を行うものとした。時刻依存条件を考慮するため、ここでは所要時間をコストとして用いる。コストとしては、各リンクの距離を移動速度で除した値を用いることができる。ダイクストラ法は周知の手法であるため、詳細な説明は省略するが、本実施例に特徴的な部分についてのみ概要を説明する。
【0052】
ステップS110の処理では、サーバ200は、地図DB250に格納されたノード、リンクのデータを参照して、出発地からリンク単位で経路を延伸して経路候補を設定する(ステップS112)。そして、この経路候補について、コストの総和を求めるとともに、各ノードへの到達時刻を予測する(ステップS114)。通行規制などが付されている箇所では、待ち時間が生じる場合もある。例えば、通行止めが一定の時間帯においてのみ解除される場合には、サーバ200は、この待ち時間を次のリンクのコストへ反映した上で(ステップS116)、最小コストとなる経路を選択する(ステップS118)。
【0053】
図中に、待ち時間が生じた場合の処理例を示した。この例は、ノードB,C,Dと通行する経路を表している。BC間のコストは8、CD間のコストは20である。CD間には20:00〜6:00は通行止めとなる通行規制が設定されている。この状態で、ノードCへの到着希望時刻が5:30と想定される場合、ノードCでは、待ち時間が30分生じる。ステップS116の処理では、この待ち時間30分をノードCに続くリンク、即ちCD間のリンクに反映させ、CDのコストを50(=20+30)として処理をするのである。こうすることにより、CD間に迂回路が存在する場合には、その迂回路を通る経路を設定することも可能となる。
【0054】
ステップS114では、ユーザから指定された探索条件もコストに反映させることができる。例えば、階段を回避する探索条件が指定されている時は、階段に相当するリンクのコストを所定値または所定比率で増加させる。こうすることで、階段を通る経路が選択される可能性を抑制することができる。この他、気象条件に基づく探索条件を反映させる場合も同様である。気象条件に基づく探索条件を反映する際のコストの演算方法については、後述する。
【0055】
サーバ200は、以上の処理を到達時刻までに目的地に至る経路が探索されるまで繰り返し実行する(ステップS120)。かかる経路が得られない場合には、探索条件を変更して(ステップS122)、経路探索を再試行する(ステップS110)。図3に示したように、本実施例では、探索条件について優先順位が設定されているため、サーバは、ステップS122において、優先順位が最も低い条件を除外して経路探索を再試行するのである。この再試行でも経路が得られなかった場合には、サーバ200は、ステップS122において、残った探索条件のうち優先順位が最も低い条件を除外して経路探索を更に試行することになる。
【0056】
F.気象条件の反映:
本実施例では、図3で説明した通り、探索条件として「日陰優先」などの気象条件も設定することができる。このような探索条件が設定された場合、サーバ200は、経路探索処理(図6)に、気象条件を反映してコストを算出し(図6のステップS114)、経路を探索することになる。以下では、気象条件をコストに反映する方法について説明する。ここでは、経路の日当たりに基づいて設定される「日当たりコスト」、雨降り時に屋根付きの経路を優先的に選択するために用いられる「雨降りコスト」、および夏や冬にできるだけ空調の効いた経路を選択するために用いられる「温度コスト」の設定を例にとって説明する。
【0057】
図7は日当たり判定データの設定方法を示す説明図である。建物の平面形状および高さが既知の場合、太陽の位置が分かれば、幾何学的な解析によって建物の陰の形状を求めることが可能である。しかし、経路探索時に一つ一つの建物について陰を求めるための演算を行い、各リンクについて日陰か日向かを判定するのは処理負荷が多大となり、経路探索に長時間を要することになる。そこで、本実施例では、日陰か日向かを簡易な処理で判定するものとした。図7で示す日当たり判定データは、日陰か日向かを簡易に判定するために用いるデータである。
【0058】
図7(a)は建物および太陽の配置を横から見た状態を示している。この状態では、建物の陰は、建物の接地部分(以下、「建物の足」と呼ぶ。)から距離Lsの範囲に広がることになる。建物を横から見た状態における太陽の高さγは、時刻および季節によって図中の矢印のように変動する。これに伴い、陰の距離Lsも変動する。距離Lsは、「Ls=建物の高さ/tanγ」で求めることができる。
【0059】
図7(b)は建物および太陽の配置の平面図である。ハッチングを付した部分が建物である。説明の便宜上、図7(b)の上方を東、下方を西として示した。太陽が真南にある時(図中の位置S1)、建物の陰は、建物の足から真北にLsだけ伸びた矩形となる。建物の足の部分に対向する部分が辺Es1である。
【0060】
季節および時刻が決まると太陽の平面内での位置が決まる。一例として、太陽が位置S2にある時を考える。この時、建物の陰は、図中の破線で示すように平行四辺形状にずれ、辺Es1は辺Es2の位置にずれる。現実には太陽は平面内での位置のずれとともに高さも変化するため、陰の距離Lsも同時に変化するが、ここでは平面的なずれのみを考えるものとする。また、図中に示した破線形状は、建物の北面Snに対応する陰にすぎない。本来は建物の南北方向の厚さを考慮する必要があり、南面Ssに対応して陰となる平行四辺形の領域を求め、この領域と図中の破線領域とを包絡する領域が建物の陰となる。ただし、本実施例では、ここでも簡略化を行い、北面Snに対応する領域のみで陰を考えるものとする。この結果、平面内での太陽の位置は、陰の辺Es1を東西方向にずらす要素として評価することができ、その影響は東西方向へのずれ角αで表すことができる。
【0061】
以上より、太陽の位置および高さは季節および時間によって変動するが、その時の陰の形状は、建物の足を南北方向に距離Lsだけ平行移動し、東西方向に角度αだけずらすことで得ることができる。図7(a)、図7(b)では、建物の足が東西方向に位置する場合を例示したが、建物の足が東西方向からずれて配置されている場合でも、簡略的には同様の考え方で陰の形状を決めることができる。
【0062】
上述の方法で陰の形状を決めるためには、距離Lsと角度αを求める必要がある。この値は、建物の形状によらず一定であり、日本国内程度の範囲を考える時には、建物の接地場所に依存せず一定として扱うことができる。そこで、本実施例では、季節および時間と対応づけて距離Ls,角度αを与えるデータ(以下、「日当たり判定データ」という。)を予めテーブル形式で用意することとした。図7(c)は日当たり判定データの構造例を示す説明図である。この例は、月単位で、各時刻における距離Ls、角度αを与える二次元テーブルとして構成した例に当たる。
【0063】
図8は気象条件コスト算出処理のフローチャートである。経路探索処理(図6)のステップS114において、サーバ200が実行する処理である。図8の例では、雨降りコスト、温度コスト、日当たりコストの3種類を考慮して気象条件コストを設定する例を示すが、いずれか一部を省略してもよいし、この他の要素を考慮してもよい。
【0064】
この処理では、サーバ200は、まず雨ふりコストCrを算出する(ステップS114a)。雨ふりコストCrとは、雨天時の経路探索において、屋根ありの経路を優先的に探索可能とするためのコストである。本実施例では、屋根なしの経路については、2.0×リンク長を雨ふりコストCrとし、屋根ありの経路については1.0×リンク長を雨ふりコストCrに設定する。この結果、屋根なしのリンクのコストは、屋根ありのリンクの2倍に設定されることとなる。両者のコスト比は、2倍に限定されるものではなく、種々の値に設定可能である。
【0065】
次に、サーバ200は、温度コストCtを算出する(ステップS114b)。温度コストCtとは、夏や冬などに、建物内や地下街など空調のある経路を優先的に設定可能とするためのコストである。本実施例では、屋外、つまりエアコン無しのリンクに対しては、2.0×リンク長を温度コストCtとし、屋内、つまりエアコン有りのリンクに対しては、1.0×リンク長を温度コストCtと設定する。屋内外のコスト比は2倍に限定されるものではなく、種々の値に設定可能である。
【0066】
次に、サーバ200は、日当たりコストを算出する(ステップS114c)。日当たりコストCsは、日陰の経路優先で経路探索するために用いられる値である。日陰が多いほど日当たりコストCsが小さくなるよう設定した。季節および時刻に応じて、図7(c)で示した日当たり判定データを参照すれば陰の形状を決めるためのパラメータLsおよびαを得ることができる。リンクLLの周辺に建物B1、B2が存在する場合、これらの建物の陰は、このパラメータLs、αを用いることにより、図中のハッチングを付した領域のように簡易的に求めることができる。
【0067】
次に、こうして求められた陰のうち、建物の足に対向する辺を評価対象として用い、リンクのポリゴンPOLに含まれる部分の長さを求める。建物B2の場合、対向する辺の全体がポリゴンPOLに含まれるから、コスト算出に用いられる長さはL2である。建物B1の場合、対向する辺の一方の頂点PbはポリゴンPOLに含まれるものの、他方の頂点PaはポリゴンPOL外にある。従って、コスト算出に用いられる長さは、対向する辺の一部の長さL1である。こうして得られた長さの総和ΣLiが、ポリゴンPOL内の陰の部分の評価長さということになる。従って、日当たりコストCsは、リンク長さLLを用いて、「Cs=(LL/ΣLi)×LL」と求められる。日当たりコストCsは、上述の例に限らず種々の方法で設定可能である。例えば、陰の部分(図中のハッチング部分)とポリゴンPOLの面積比を用いてもよい。
【0068】
サーバ200は、以上で求められた雨ふりコストCr、温度コストCt、日当たりコストCsの総和によって気象条件コストを求める(ステップS114d)。ここでは、気象条件コストは、リンク長と同じ次元の値として求められることになる。経路探索時に所要時間をコストとして用いる場合には、ステップS114dの結果を、移動速度で除した値を気象条件コストとして用いればよい。
【0069】
G.リルート例:
(1)到着希望時刻を時刻依存条件とする場合:
図9はリルートを行った例を示す説明図である。出発地から目的地まで向かう経路を案内する場合を例示した。途中の地点AB間では、バスまたは電車を利用するものとする。バスは所要時間50分と短いが、3000円の運賃が必要となる。電車は、運賃は2000円と定額であるが、所要時間は70分とバスよりも長い。電車およびバスは、ダイヤに従って運行されるため、出発時刻が限られる。本実施例では、図中に実線および破線で示す通り、それぞれ9時半、10時、10時半にA地点を出発するものとする。また、B地点から目的地までは、徒歩であれば所要時間10分であり、タクシーを利用すれば運賃1000円がかかるものの所要時間3分で済む。
【0070】
上述の状況で、11時半を到着希望時刻として指定し、9時50分を出発時刻とする場合の経路探索、案内結果を示す。この例では、実施例(図5)と同様、到着希望時刻が時刻依存条件に該当する。当初は、9時50分に出発した後、実線で示すように移動し、A地点から10時発の電車を利用してB地点に到着した後、B地点から徒歩で目的地に向かう経路が探索されたとし、案内時には実際のユーザの移動速度が想定よりも遅く図中に破線で示すように移動したとする。
【0071】
サーバ200は、この状態では10時発の電車に乗ることができないと判断し、途中でスケジュール変更、即ちリルートを行う。この例では、徒歩でそのままA地点まで移動し、10時半発のバスを利用し、B地点からはタクシーで移動することにより、到着希望時刻までに目的地に到達できる経路が得られるため、サーバ200は、この経路をユーザに案内する。ユーザは当初予定されていた電車に乗れないことが分かっても、到着希望時刻に目的地に到達することができるため、経路案内に従って、安心して移動することができる。
【0072】
(2)気象条件を時刻依存条件とする場合:
実施例では、目的地への到着希望時刻を時刻依存条件とする場合を例示した。この例では、チェックポイントにおいては、到着希望時刻までに到着できるか否かが判断され、これが満たされない時に経路探索処理が再試行される(図5のステップS136)。本実施例では、通行時刻に応じて変化する種々の探索条件を時刻依存条件として扱うことができる。例えば、図7,8で説明した気象条件を時刻依存条件として扱うこともできる。また、時刻依存条件は、一つである必要はなく複数であってもよい。従って、気象条件と到着希望時刻の双方を時刻依存条件として扱ってもよい。
【0073】
図10は気象条件に基づくリルートを行った例を示す説明図である。出発地から目的地に向かう経路上にAルート、Bルートの2種類が存在する場合を考える。Aルートは、午前中は日陰となっているが、午後は日向となる経路である。Bルートは、午前中は日向だが、午後は日陰となる経路である。ユーザからは探索条件として日陰優先が指定されているものとする。
【0074】
出発時刻が11時である場合、経路探索時には分岐点に11:20に到着すると推定されたとする。この時点では、午前中なので、日陰となっているAルートが選択される。従って、Aルートを経由して、合流地点に12:10、目的地に12:30に到着するという経路が得られ、この経路の案内が開始されることになる。経路の上側に、経路探索時に得られた各地点への到着時刻を示した。
【0075】
経路の下側には、経路案内中の各地点への到着時刻を示した。11時に出発した後、ユーザの移動速度が経路探索時の想定よりも遅く、分岐点に11:45に到着したとする。サーバ200は、案内すべき経路(この例ではAルート)が時刻依存条件を満足しているか否か、つまり日陰優先という条件を満足するか否かを判断する。Aルートは午後には日向となるから、分岐点に11:45に到着した場合には、日陰優先という条件を十分に満足できないことになる。従って、サーバ200は、時刻依存条件を満足できないと判断して、経路探索を再試行し、午後には日陰となるBルートを経由する経路を選択する。この結果、ユーザは日陰となっているBルートを経由し、合流点に13:20、目的地に14:00に到着することができる。到着時刻が経路探索時の想定時刻12:30よりも大きく遅れる結果となっているのは、ユーザの移動速度が想定していたよりも遅いことが原因であり、Bルートが遠回りだからという訳ではない。
【0076】
図10の例において、到着希望時刻を併せて考慮してもよい。つまり、日陰優先および到着希望時刻の双方を時刻依存条件として扱ってもよい。例えば、図10の例において到着希望時刻が13:00であったとする。分岐点に11:45に到着した時点で時刻依存条件を判定すると、Aルートは、午後には日向になるから日陰優先という条件は満たされない。また、AルートとBルートの距離が同一であるとすれば、Aルートを経由した場合の到着時刻は14:00と推定されることになり、到着希望時刻も満たされない。つまり、Aルートは、日陰優先および到着希望時刻という2つの時刻依存条件のいずれも満たさない経路となる。 これに対し、Bルートは日陰優先という条件は満たすが、到着希望時刻は満たさない経路となる。
【0077】
図示したAルート、Bルートの他に、Cルートが存在したものとする。Cルートは、近道または交通機関を利用した経路であり、Cルートを経由すれば、ユーザは目的地に到着希望時刻13:00までに到着できるとする。Cルートが日陰優先という条件を満たす経路である場合には、A〜Cルートのうち、Cルートのみが時刻依存条件を全て満たす経路となるから、サーバ200はユーザに対してCルートを案内することになる。
【0078】
Cルートが日陰優先という条件を満たさない経路である場合には、時刻依存条件間の優先順位に応じてBルートまたはCルートが選択される。日陰優先を到着希望時刻よりも優先する場合にはBルートが選択され、到着希望時刻を日陰優先よりも優先する場合にはCルートが選択される。時刻依存条件間の優先順位は、予め固定としてもよいし、図3(b)に示した入力画面で、到着希望時刻も含めて優先順位を指定可能としてもよい。
【0079】
以上で説明した実施例の経路案内システムによれば、経路探索時の想定と実際の経路案内時の状況とが異なることにより、ユーザから指定された時刻依存条件が満たされない状況になった場合に、経路の再探索を行うことができる。この結果、時刻依存条件を満たす実用的な経路案内を実現することができる。
【0080】
H.変形例:
実施例では、ユーザの移動速度が経路探索時の想定よりも遅い場合を例にとって、リルート要否の判断方法およびリルート処理の例について説明した。経路探索時の想定と異なる状況が生じる原因としては、ユーザの移動速度に限らず、出発時刻が遅れた場合、移動中に寄り道をした場合、交通機関が遅れた場合、事故などによって移動に支障が生じた場合など種々の原因が挙げられる。ユーザの心拍数や呼吸数などを検出し、これに基づいて移動速度の変化を予測して、経路探索時の想定と異なる状況が生じるか否かを予測するようにしてもよい。
【0081】
実施例の経路案内システムは、リルートに際し、種々の外部情報を利用してもよい。例えば、渋滞情報、天候の変化、事件・事故情報、商店のタイムサービス情報などを、ネットワーク上の他のサーバから取得し、これをリルートに活用してもよい。外部情報は、第1にリルートの要否を判断するトリガとして利用することができる。例えば、車両を対象とする案内では、渋滞情報が得られた場合、これをトリガとして到着希望時刻までに目的地に到着できるか否かを判断するようにしてもよい。渋滞が生じていたとしても、渋滞情報から得られる通過時刻を考慮した上で、案内予定の経路をとれば到着希望時刻までに到着可能であれば、リルートは不要と判断することができる。
【0082】
外部情報は、第2にリルート時の経路選択に活用することもできる。例えば、曇りになるという天候情報が得られた場合、日向となる経路であったとしても、日陰優先という探索条件を満たすことになるから、経路探索時よりも柔軟に経路を選択することが可能となる。
【0083】
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。
【図面の簡単な説明】
【0084】
【図1】実施例としての経路案内システムの構成を示す説明図である。
【図2】地図DB250および時刻表DB252のデータ構造を示す説明図である。
【図3】経路案内例を示す説明図である。
【図4】リルートのチェックポイント設定例を示す説明図である。
【図5】経路案内システムの全体処理のフローチャートである。
【図6】経路探索処理のフローチャートである。
【図7】日当たり判定データの設定方法を示す説明図である。
【図8】気象条件コスト算出処理のフローチャートである。
【図9】リルートを行った例を示す説明図である。
【図10】気象条件に基づくリルートを行った例を示す説明図である。
【符号の説明】
【0085】
100…端末
110…主制御部
120…通信部
130…コマンド入力部
140…GPS
150…表示制御部
200…サーバ
220…通信部
230…経路探索部
240…経路案内部
250…地図DB
252…時刻表DB
254…ユーザDB
250L…リンクデータ
250B…地物データ
250N…ノードデータ

【特許請求の範囲】
【請求項1】
ユーザからの指定に従って経路を探索し、案内する経路案内システムであって、
通行可能な道路をノード、リンクで表したネットワークデータを参照するネットワークデータ参照部と、
出発地、目的地の指定を入力する地点入力部と、
経路探索を行う際の条件として、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度を含む探索条件を特定する探索条件特定部と、
前記探索条件に従って、前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索部と、
ユーザの現在位置を入力し、該現在位置に応じて前記探索された経路の経路案内を行う経路案内部とを有し、
該経路案内部は、前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて、前記経路探索によって得られた経路が前記時刻依存条件を満たさない状態にあると判断される時には、前記現在位置を前記出発地とし、前記現在時刻を前記基準時刻として前記経路探索部に前記経路探索を再試行させる再探索制御部を備える経路案内システム。
【請求項2】
請求項1記載の経路案内システムであって、
前記時刻依存条件は、前記目的地または該目的地に至るまでの所定の地点への到着希望時刻である経路案内システム。
【請求項3】
請求項1または2記載の経路案内システムであって、
前記ネットワークデータ参照部は、更に、前記ノード、リンクの少なくとも一部について、各時刻における気象状態を予測するための気象データを参照可能であり、
前記時刻依存条件は、前記気象状態に基づいて指定される条件である経路案内システム。
【請求項4】
請求項1〜3いずれか記載の経路案内システムであって、
前記再探索制御部は、前記想定移動速度を所定の条件に従って変更して前記経路探索の再試行を行わせる経路案内システム。
【請求項5】
請求項1〜4記載の経路案内システムであって、
前記探索条件は、複数の条件を含むとともに、各条件に対して優先順位が設定されており、
前記再探索制御部は、前記優先順位が劣後する条件を緩和して前記経路探索の再試行を行わせる経路案内システム。
【請求項6】
請求項1〜5記載の経路案内システムであって、
前記再探索制御部は、ユーザが、案内すべき経路上に予め設定されたチェックポイントに至った時点で稼働する経路案内システム。
【請求項7】
請求項6記載の経路案内システムであって、
前記チェックポイントは、前記案内すべき経路に沿って、前記目的地までの距離が小さくなるにつれ、段階的または連続的に密となるよう設定される経路案内システム。
【請求項8】
ユーザからの指定に従って経路を探索し、案内する経路案内方法であって、
コンピュータが実行する工程として、
通行可能な道路をノード、リンクで表したネットワークデータを参照するネットワークデータ参照工程と、
出発地、目的地の指定を入力する地点入力工程と、
経路探索を行う際の条件として、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度を含む探索条件を特定する探索条件特定工程と、
前記探索条件に従って、前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索工程と、
ユーザの現在位置を入力し、該現在位置に応じて前記探索された経路案内を行う経路案内工程とを有し、
前記経路案内工程は、前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて、前記経路探索によって得られた経路が前記時刻依存性のある条件を満たさない状態にあると判断される時には、前記現在位置を前記出発地とし、前記現在時刻を前記基準時刻として前記経路探索を再試行する再探索制御工程を備える経路案内方法。
【請求項9】
ユーザからの指定に従って経路を探索し、案内するためのコンピュータプログラムであって、
通行可能な道路をノード、リンクで表したネットワークデータを参照するネットワークデータ参照サブプログラムと、
出発地、目的地の指定を入力する地点入力サブプログラムと、
経路探索を行う際の条件として、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度を含む探索条件を特定する探索条件特定サブプログラムと、
前記探索条件に従って、前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索サブプログラムと、
ユーザの現在位置を入力し、該現在位置に応じて前記探索された経路案内を行う経路案内サブプログラムとを有し、
前記経路案内サブプログラムは、前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて、前記経路探索によって得られた経路が前記時刻依存性のある条件を満たさない状態にあると判断される時には、前記現在位置を前記出発地とし、前記現在時刻を前記基準時刻として前記経路探索を再試行する再探索制御サブプログラムを備えるコンピュータプログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate


【公開番号】特開2007−205946(P2007−205946A)
【公開日】平成19年8月16日(2007.8.16)
【国際特許分類】
【出願番号】特願2006−26397(P2006−26397)
【出願日】平成18年2月2日(2006.2.2)
【出願人】(597151563)株式会社ゼンリン (155)
【Fターム(参考)】