(57)【要約】【課題】  経路案内システムにおいて、経路探索時の想定と異なる事情が生じた場合でも、ユーザが指定した探索条件を満たす経路を案内可能とする。【解決手段】  経路案内システムは、道路のネットワークデータを参照して、ユーザから指定された出発地、目的地間の経路を探索し、経路案内を行うシステムである。経路探索時には、目的地への到着希望時刻、日陰優先などの探索条件も指定可能とする。経路案内システムは、ユーザの移動速度などの想定に従って、探索条件を満たす経路を探索する。経路探索時に想定した事情と異なる事情が経路案内時に生じた場合、ユーザから指定された探索条件を満たすことができないと判断される時には、経路探索を再試行して、新たな経路を案内する。こうすることで、想定と異なる事情が生じた場合でも、ユーザが指定した探索条件を満たす経路を案内することが可能となる。【選択図】  図３
2007205946.tif 000002
【特許請求の範囲】
【請求項１】
ユーザからの指定に従って経路を探索し、案内する経路案内システムであって、
通行可能な道路をノード、リンクで表したネットワークデータを参照するネットワークデータ参照部と、
出発地、目的地の指定を入力する地点入力部と、
経路探索を行う際の条件として、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度を含む探索条件を特定する探索条件特定部と、
前記探索条件に従って、前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索部と、
ユーザの現在位置を入力し、該現在位置に応じて前記探索された経路の経路案内を行う経路案内部とを有し、
該経路案内部は、前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて、前記経路探索によって得られた経路が前記時刻依存条件を満たさない状態にあると判断される時には、前記現在位置を前記出発地とし、前記現在時刻を前記基準時刻として前記経路探索部に前記経路探索を再試行させる再探索制御部を備える経路案内システム。
【請求項２】
請求項１記載の経路案内システムであって、
前記時刻依存条件は、前記目的地または該目的地に至るまでの所定の地点への到着希望時刻である経路案内システム。
【請求項３】
請求項１または２記載の経路案内システムであって、
前記ネットワークデータ参照部は、更に、前記ノード、リンクの少なくとも一部について、各時刻における気象状態を予測するための気象データを参照可能であり、
前記時刻依存条件は、前記気象状態に基づいて指定される条件である経路案内システム。
【請求項４】
請求項１〜３いずれか記載の経路案内システムであって、
前記再探索制御部は、前記想定移動速度を所定の条件に従って変更して前記経路探索の再試行を行わせる経路案内システム。
【請求項５】
請求項１〜４記載の経路案内システムであって、
前記探索条件は、複数の条件を含むとともに、各条件に対して優先順位が設定されており、
前記再探索制御部は、前記優先順位が劣後する条件を緩和して前記経路探索の再試行を行わせる経路案内システム。
【請求項６】
請求項１〜５記載の経路案内システムであって、
前記再探索制御部は、ユーザが、案内すべき経路上に予め設定されたチェックポイントに至った時点で稼働する経路案内システム。
【請求項７】
請求項６記載の経路案内システムであって、
前記チェックポイントは、前記案内すべき経路に沿って、前記目的地までの距離が小さくなるにつれ、段階的または連続的に密となるよう設定される経路案内システム。
【請求項８】
ユーザからの指定に従って経路を探索し、案内する経路案内方法であって、
コンピュータが実行する工程として、
通行可能な道路をノード、リンクで表したネットワークデータを参照するネットワークデータ参照工程と、
出発地、目的地の指定を入力する地点入力工程と、
経路探索を行う際の条件として、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度を含む探索条件を特定する探索条件特定工程と、
前記探索条件に従って、前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索工程と、
ユーザの現在位置を入力し、該現在位置に応じて前記探索された経路案内を行う経路案内工程とを有し、
前記経路案内工程は、前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて、前記経路探索によって得られた経路が前記時刻依存性のある条件を満たさない状態にあると判断される時には、前記現在位置を前記出発地とし、前記現在時刻を前記基準時刻として前記経路探索を再試行する再探索制御工程を備える経路案内方法。
【請求項９】
ユーザからの指定に従って経路を探索し、案内するためのコンピュータプログラムであって、
通行可能な道路をノード、リンクで表したネットワークデータを参照するネットワークデータ参照サブプログラムと、
出発地、目的地の指定を入力する地点入力サブプログラムと、
経路探索を行う際の条件として、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度を含む探索条件を特定する探索条件特定サブプログラムと、
前記探索条件に従って、前記ネットワークデータに基づき前記出発地から目的地までの経路探索を行う経路探索サブプログラムと、
ユーザの現在位置を入力し、該現在位置に応じて前記探索された経路案内を行う経路案内サブプログラムとを有し、
前記経路案内サブプログラムは、前記経路案内中の所定のタイミングにおけるユーザの現在位置および現在時刻に基づいて、前記経路探索によって得られた経路が前記時刻依存性のある条件を満たさない状態にあると判断される時には、前記現在位置を前記出発地とし、前記現在時刻を前記基準時刻として前記経路探索を再試行する再探索制御サブプログラムを備えるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザからの指定に従って経路を探索し、案内する経路案内システムに関し、詳しくは経路を通行する時刻に依存した探索条件を反映して経路探索および案内を行う経路案内システムに関する。
【背景技術】
【０００２】
経路案内システムとは、ユーザが指定した出発地から目的地までの経路を探索し、案内する装置であり、カーナビゲーションシステム等として知られている装置である。近年では、歩行者に対して経路を案内するための装置も提案されている。経路案内システムは、スタンドアロンで稼働するものもあれば、携帯電話などの端末とサーバとをネットワークで接続して構成されたものもある。経路案内システムにおける経路探索では、ダイクストラ法と呼ばれるアルゴリズム、即ち道路をノード、リンクで表したネットワークデータを参照し、各ノード、リンクに付されたコストの総和が最小となる経路を探索する手法が用いられることが多い。
【０００３】
経路案内システムで経路探索を行うための条件は、目的地までの距離が最短となる条件、所要時間が最短となる条件など種々の指定が可能である。歩行者用の経路案内システムでは、更に、階段や上り坂を回避するなどの条件を指定可能とした経路探索も提案されている。車両を対象とした経路案内システムにおいて、直射日光を避ける経路を探索するものも提案されている（特許文献１参照）。これらの探索条件が指定された場合、経路案内システムは、探索条件に従ってノード、リンクに付されたコストを変動させることにより、所望の経路を得ることができる。
【０００４】
こうして得られた経路を案内する際には、ユーザの現在位置をＧＰＳ（Global Positioning System）などで取得し、地図上に現在位置および経路を表示する方法が採られる。これらの表示と併せて、音声での案内を行うものもある。ユーザが進路を誤って、経路から逸脱した場合、経路案内システムは、リルート、即ちユーザの現在位置から目的地に至る経路を再度探索する処理を実行し、案内を継続する（特許文献２参照）。
【０００５】
【特許文献１】特開２００４−２２６１９９号公報
【特許文献２】特開２００３−２３２６４５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
経路を探索する際には、目的地への到着希望時刻など、時刻に依存する探索条件（以下、「時刻依存条件」という。）を指定することも可能である。このような探索条件が指定された時には、経路案内システムは、ユーザの移動速度などについて予め用意された想定値を用いて探索条件に合致する経路を探索する。
【０００７】
しかし、時刻依存条件が指定された場合、探索された経路を案内通りに通行していても探索時には予測できなかった状況変化が起き、探索された経路が、結果として探索条件を満たさなくなることがある。例えば、目的地への到着希望時刻が指定された場合、探索時よりもユーザの移動速度が遅い時には、案内された経路を通行していたとしても指定された到着希望時刻に遅れてしまうことが生じ得る。また、直射日光を避ける経路を指定した場合も、ユーザの移動速度が遅ければ、案内された経路は日陰から日向に変わっていることが起こり得るし、ユーザの移動速度が速ければ、逆にまだ日陰になっていないということも起こり得る。これらの状況は、ユーザの移動速度が経路探索時の想定速度よりも速すぎたり、遅すぎたりした場合だけでなく、ユーザの出発時刻が経路探索時の想定時刻とずれたり、案内途中でユーザが寄り道をしたり、案内途中で事故その他の事情により通行に支障が生じたりした場合などにも生じ得る。経路案内時の状況が経路探索時に想定した状況に完全に適合していることは稀であるから、上述の状況は、かなりの頻度で生じ得る。従って、従来の経路案内システムでは、時刻依存条件を指定した場合、十分に実用的な経路案内を行うことはできてはいなかった。本発明は、かかる課題に鑑み、経路案内システムにおいて、時刻に依存する探索条件を満足できるようにすることを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、ユーザからの指定に従って経路を探索し、案内する経路案内システムとして構成することができる。本発明の経路案内システムは、通行可能な道路をノード、リンクで表したネットワークデータを参照し、指定された出発地、目的地間で経路探索を行う。出発地については、ユーザからの指定としてもよいし、ユーザの現在位置をデフォルトの指定として用いるようにしてもよい。経路探索は、ユーザからの入力、プログラムでの既定値、予め用意されたデータベースからの読込などの方法で特定された探索条件に基づいて行う。この探索条件には、経路を通行する時刻に応じて経路探索結果に影響を与え得る時刻依存性のある時刻依存条件、および経路探索を行う際の基準時刻、ユーザの想定移動速度が含まれる。時刻依存条件には、目的地への到着希望時刻、目的地に至るまでの所定の地点への到着希望時刻、および各時刻における日当たり、温度、風向き、霧の発生、気温変化に伴う凍結状態など季節や日時に応じた変化を示す気象状態に基づく条件などが含まれる。基準時刻としては、現在時刻や出発予定時刻などを用いることができる。想定移動速度は、歩行時、自転車時、車両時などユーザの移動手段に応じて予め設定された値を使い分けるようにしてもよいし、ユーザから指定するようにしてもよい。
【０００９】
経路案内システムは、経路探索の他、ユーザの現在位置を入力し、現在位置に応じて探索された経路の経路案内を行う。経路案内中には、所定のタイミングで、ユーザの現在位置および現在時刻を入力し、現在位置および現在時刻が、案内すべき経路についての時刻依存条件を満たすか否かを判定する。そして、時刻依存条件が満たされないと判断される場合には、現在位置を出発地とし、現在時刻を基準時刻として経路探索を再試行する。こうすることにより、経路探索時に想定した状況と経路案内時の状況が異なる場合でも、時刻依存条件を満足する経路探索を実現することができる。従って、本発明は、時刻依存条件が指定された場合でも、実用的な経路案内を実現することができる。
【００１０】
本発明の経路案内システムは、歩行者を対象とする時に、より有用性が高い。時刻に依存する探索条件は、歩行者を対象とする経路探索では、より重視される傾向にあるからである。例えば、歩行者を対象とする経路探索では、目的地への到着希望時刻は、駅や停留所を目的地とする経路探索において、交通機関のダイヤを踏まえて設定されることが多い。このような場合には、到着希望時刻に遅れてしまうとユーザが望んでいた電車、バスに乗り遅れることになってしまう。また、日当たりを避けたいなどの探索条件についても、車両では屋根で遮られたり、窓ガラス越しに日が当たったりするなど、日当たりに対する緩和要素が存在するのに対し、歩行者ではこれらの緩和要素が存在しない分、日当たりに対する探索条件は重視される。このように歩行者を対象とする経路探索では、時刻依存条件がより重視される傾向にあるため、本発明の利点がより活かされることになるのである。
【００１１】
時刻依存条件は、例えば、目的地または目的地に至るまでの所定の地点への到着希望時刻とすることができる。経路案内システムは、探索された経路に沿って、想定移動速度で移動した場合の所要時間を求めることにより、目的地または所定の地点への到着予測時刻を求めることができるから、この到着予測時刻に基づいて到着希望時刻の条件が満たされているか否かを判断することができる。経路案内システムは、到着希望時刻が指定された時、該到着希望時刻までに到着するという条件として扱っても良いし、到着希望時刻の前後所定時間内に到着するという条件として扱ってもよい。到着希望時刻の指定が有用となる一例として、例えば、交通機関のダイヤを踏まえて駅や停留所への到着希望時刻を指定する場合や、時間帯に応じて一方通行その他の交通規制が変動する箇所が経路上に含まれる場合などが挙げられる。
【００１２】
時刻依存条件の他の例として、日当たり、温度、風向き、霧の発生、気温変化に伴う凍結状態など季節や日時に応じた変化を示す気象状態に基づいて指定する条件（以下、「気象条件」という。）が挙げられる。これらの気象条件は日々の天候によって変動するものの、例えば、経路上の各地点、各時刻における晴天時の日当たりは十分に予測可能である。温度や風向き、霧の発生、気温変化に伴う凍結状態なども、それぞれの季節、各時刻に応じて平均的な状態を予測可能である。経路案内システムは、ノード、リンクの少なくとも一部について、各時刻における気象条件を予測するための気象データを参照可能することにより、気象条件を反映した経路探索を実現することができる。この気象データは、例えば、各ノード、リンクの属性として、時刻ごとの気象条件を対応づけるテーブル等の形で用意することができる。日当たりのように、太陽の位置、および建物の形状等から演算可能な気象条件については、これを演算で求めるためのデータを気象データとして用意してもよい。また、例えば、経路探索を行う日の天気予報データをネットワーク経由で取得し、時刻に応じた降水確率を気象条件として用いるようにしてもよい。
【００１３】
経路案内システムは、経路探索を再試行する際には、ユーザの想定移動速度を所定の条件に従って変更させるようにしてもよい。例えば、一定の値または比率で初期の想定移動速度を速めたり、遅くしたりしてもよいし、従前の平均移動速度を用いるようにしてもよい。こうすることにより、経路探索時の想定移動速度と、現実の移動速度との差違を縮めることが可能となり、更に再試行を行う必要が生じる可能性を抑制することができる。
【００１４】
探索条件が、複数の条件を含む場合、これらの各条件に対して優先順位を設定可能としてもよい。優先順位は、ユーザが指定してもよいし、所定の規則に従って自動的に設定してもよい。優先順位が設定されている場合には、経路案内システムは、経路探索を再試行する際には、劣後する条件を緩和してもよい。経路探索の再試行時には無条件に条件を緩和するようにしてもよいし、従前の探索条件を全て満たす経路が探索できない場合にのみ緩和するようにしてもよい。経路案内システムは、このように経路探索条件を緩和することにより、全ての探索条件を満たす経路が存在しない場合でも、経路を探索することが可能となる。これは、時刻依存条件を他の探索条件よりも優先的に扱っていることを意味している。このように時刻依存条件を優先的に扱うことにより、経路案内システムの実用性をより向上させることができる。
【００１５】
経路探索の再試行を行うか否かは種々のタイミングで判断することができる。例えば、ユーザが、案内すべき経路上に予め設定されたチェックポイントに至った時点でこの判断を行うようにしてもよい。チェックポイントは、一定の間隔で設定するようにしてもよいし、交差点など経路を変更可能な地点としてもよい。また、チェックチェックポイントは、案内すべき経路に沿って、目的地までの距離が小さくなるにつれ、段階的または連続的に密となるよう設定してもよい。目的地に近づくほど密にするのは、経路探索時点から長時間を経ていることになり、経路探索時に想定していた状況からの差違が拡大していると考えられ、頻繁に再試行の要否を判断することが好ましくなると考えられるからである。再試行の判断は、これらのチェックポイントで行う他、所定の時間が経過する度に行うようにしてもよい。
【００１６】
本発明において、以上で説明した種々の特徴は、必ずしも全てを備えている必要はなく、その一部を省略したり、適宜、組み合わせたりして採用することができる。また、本発明は、上述した経路案内システムとしての態様のみならず、コンピュータを用いて経路を案内する経路案内方法として構成してもよい。更に、上述した経路案内を実現するためのコンピュータプログラムや、かかるコンピュータプログラムを記録した記録媒体として構成してもよい。ここで、記録媒体としては、フレキシブルディスクやＣＤ−ＲＯＭ、光磁気ディスク、ＩＣカード、ＲＯＭカートリッジ、パンチカード、バーコードなどの符号が印刷された印刷物、コンピュータの内部記憶装置（ＲＡＭやＲＯＭなどのメモリ）および外部記憶装置等、コンピュータが読取り可能な種々の媒体を利用できる。
【発明を実施するための最良の形態】
【００１７】
本発明の実施例について以下の順序で説明する。
Ａ．システム構成：
Ｂ．データ構造：
Ｃ．経路案内例：
Ｄ．経路案内〜全体処理：
Ｅ．経路探索処理：
Ｆ．気象条件の反映：
Ｇ．リルート例：
Ｈ．変形例：
【００１８】
Ａ．システム構成：
図１は実施例としての経路案内システムの構成を示す説明図である。本実施例では、歩行者用の経路案内システムとしての構成例を示すが、車両用の経路案内システムとして構成することもできる。経路案内システムは、携帯電話を利用した端末１００とサーバ２００とをネットワークＩＮＴで接続して構成されている。ネットワークＩＮＴは無線通信を利用したネットワークであり、ＬＡＮやイントラネットのように限定的なものであってもよいし、インターネットのように広域的なものであってもよい。端末１００は、携帯電話の他、いわゆる車両用のナビゲーション装置やＰＤＡ、ネットワーク通信機能を有するパーソナルコンピュータなどを利用することができる。歩行者用の経路案内システムとして構成する場合、車両用のナビゲーション装置は、車両から取り外して携帯可能としておくことが望ましい。
【００１９】
端末１００は、ユーザの操作に応じて、経路探索および経路案内に必要な指示をサーバ２００に送信するための機能を奏する。図中には、端末１００の機能ブロックを併せて示した。端末１００は、ＣＰＵ、ＲＡＭ、ＲＯＭを備えたマイクロコンピュータを制御装置として内蔵しており、このＣＰＵはＲＯＭに記憶されたソフトウェアを実行することで、図示する各機能ブロックを構成する。これらの機能ブロックは、このようにソフトウェア的に構成する他、ハードウェア的に構成することも可能である。
【００２０】
通信部１２０は、ネットワークＩＮＴを介してサーバ２００と通信する機能を奏する。ＧＰＳ１４０は、全地球測位システム（Global Positioning System）を利用して、端末１００の現在位置の緯度、経度を検出する。コマンド入力部１３０は、スイッチ等に対するユーザ操作に基づいて、経路探索や経路案内に関するコマンドを入力する。コマンドとしては、図示した通り、経路探索の目的地の指定、探索条件の指定などが挙げられる。表示制御部１５０は、端末１００のディスプレイに、これらのコマンド入力用のメニューを表示したり、サーバ２００から受信した経路案内データに基づいて地図を表示させたりする。主制御部１１０は、上述した各機能ブロックを統括制御することで、端末１００の全体機能を制御する。
【００２１】
サーバ２００は、端末１００からのコマンドに基づいて、種々のデータベースを参照しながら、経路探索を行ったり、経路案内を行ったりする。図中には、これらの機能を実現するための機能ブロックおよびデータベースの例を示した。各機能ブロックは、サーバ２００のＣＰＵが実行するコンピュータプログラムによって、ソフトウェア的に構成されるが、ハードウェア的に構成することも可能である。
【００２２】
サーバ２００が利用するデータベースは地図ＤＢ２５０、時刻表ＤＢ２５２、ユーザＤＢ２５４の３種類である。地図ＤＢ２５０は、通路をノード、リンクで表したネットワークデータ、および地図描画用のポリゴンや文字データからなる描画データを有している。本実施例では、ノードおよびリンクの少なくとも一部には、許容される通行態様が時刻によって変化するものが存在する。この規制条件としては、例えば、出発時刻が規定されている公共交通機関、所定時刻になると閉鎖される駅構内の通路などが挙げられる。時刻表ＤＢ２５２は、この規制条件を記録するデータベースである。また、本実施例では、後述する通り、日当たりなど、時刻に応じて変動する気象条件も考慮して経路探索を行うことができる。時刻表ＤＢ２５２は、各時刻での気象条件を推測するために要求されるデータも記録している。地図ＤＢ２５０および時刻表ＤＢ２５２のデータ構造については後述する。
【００２３】
ユーザＤＢ２５４は、ユーザＩＤ、氏名などの書誌的な登録情報と共に、ユーザが歩行する際の移動速度に関する設定や、距離優先／時間優先などの経路探索に関する要望事項を格納している。図中にはユーザＤＢ２５４の内容として移動速度に関する登録内容を例示した。本実施例では、移動速度は、移動可能な距離と組み合わせて登録されている。図中の例では、通常利用される移動速度（以下、「通常速度」と呼ぶこともある）は「４ｋｍ／ｈ」であり、移動可能な距離には制約がないことを表している。やや早足の「５ｋｍ／ｈ」では、３ｋｍまで移動可能であり、駆け足の「１０ｋｍ／ｈ」では０．５ｋｍまで移動可能であることを表している。これらの情報は、ユーザが端末１００を操作して登録、変更可能である。図中の例では、３通りの移動速度が登録されているが、更に多くの移動速度を登録可能としてもよい。
【００２４】
通信部２２０は、端末１００とのネットワークＩＮＴ経由での通信を制御する。経路探索部２３０は、上述の３種類のデータベースを参照して、ユーザから指定された出発地、目的地間の経路を探索する。経路探索部２３０は、ユーザからの指示に応じて、地図ＤＢ２５０および時刻表ＤＢ２５２を参照して、経路探索を行う。経路探索方法については後述する。
【００２５】
経路案内部２４０は、探索された経路を地図上に表示して案内するための経路案内データを生成し、端末１００に送信する。経路案内部２４０は、経路案内の過程で、ユーザから指定された探索条件を満たしているか否かを判定し、探索条件が満たされていないと判断する場合には、経路探索部２３０に経路探索を再試行するよう指示する。経路案内方法については後述する。
【００２６】
Ｂ．データ構造：
図２は地図ＤＢ２５０および時刻表ＤＢ２５２のデータ構造を示す説明図である。地図ＤＢ２５０については、経路探索用のネットワークデータの構造のみを例示した。図の中央に例示するように、ネットワークデータは、ノードＮ１〜Ｎ８およびリンクＬ１〜Ｌ９等で構成される。リンクＬ１〜Ｌ９は歩行者が通行可能な通路を表しており、ノードＮ１〜Ｎ８はリンクＬ１〜Ｌ９の端点または接続点を表している。
【００２７】
地図ＤＢ２５０は、上述のノード、リンクに関するデータを、それぞれノードデータ２５０Ｎ、リンクデータ２５０Ｌとして格納し、地物に関するデータを地物データ２５０Ｂとして格納している。図中に示す通り、リンクデータ２５０Ｌには、リンクＩＤ、形状、時刻表、地物、距離などの情報が記録される。形状は、リンクが通過する地点の座標（緯度、経路）を表した点列データである。座標には、高さを表す情報を含めても良い。図中の例では、リンクＬ９について、ノードＮ２、Ｎ７を含む４点が格納されている。本実施例では、ノードについてはノードＩＤを格納し、その位置はノードデータ２５０Ｎを参照することで得られるようにしたが、ノードについても他の通過地点と同じく座標を格納するようにしてもよい。時刻表とは、時刻表ＤＢに格納されている情報へのリンクを表している。図中の例Ｌ９では、時刻に応じて変化する規制条件が付されていないため、時刻表の項目には「無し」が登録されている。後述するように、リンクＬ３、Ｌ４、Ｌ６のように時刻に応じて変化する規制条件が付されている場合には、時刻表ＤＢ２５２に格納されているデータのインデックスである「時刻表ＩＤ」が格納されることになる。地物とは、そのリンク周辺の地物のＩＤである。地物の位置、形状は、地物データ２５０Ｂを参照することで得られる。距離とは、そのリンクの区間距離である。
【００２８】
リンクデータ２５０Ｌの内容は、任意に設定可能であり、これらの情報の一部を省略してもよいし、ここに例示していない種々の属性情報を格納するようにしてもよい。例えば、階段や坂道などの経路種別や、ガードレールや街灯などの設備の有無等を属性情報として格納することができる。かかる属性情報が用意されている場合には、「階段を避けたい」、「ガードレールが整備されている経路を優先したい」などの経路に対する要望事項を反映した経路探索を実行することが可能となる。例えば、「階段を避けたい」という要望が出されている場合には、「階段」という属性情報が記録されているリンクのコストを増加させることによって、階段が選択される可能性を抑制することが可能となり、要望に沿った経路を探索することが可能となる。
【００２９】
ノードデータ２５０Ｎには、図示するようにノードＩＤ、位置、時刻表、通行規制などの情報が記録される。「喫茶店」、「コンビニエンスストア」、「銀行」、「郵便局」などノードの種別を表す情報を含めてもよい。ノードの位置は、緯度、経度の座標で記録される。座標には、高さを表す情報を含めても良い。時刻表は、リンクデータ２５０Ｌと同様、時刻表ＤＢ２５２に格納されている情報へのリンクを表している。通行規制とは、右左折禁止など、時刻に応じて変化しない固定的な通行規制である。例えば、図中のノードＮ４について、Ｎ３方向から来てＮ６方向へ左折する通行が禁止される場合には、通行規制欄には、「Ｎ３→Ｎ４→Ｎ６」という形でデータを格納すればよい。通行規制情報の記録方法は、これに限らず、種々の形式を採用することができる。
【００３０】
地物データ２５０Ｂには、図示するように地物ＩＤ、形状、高さ、属性などの情報が記録される。形状は、地物の平面形状を表すポリゴンの各頂点の緯度、経度の座標で記録される。形状の他、地物の代表点の緯度、経度を記録するようにしてもよい。高さは、本実施例では、建物の階数で表すものとしたが、高さの計測値を記録するようにしてもよい。属性は、ビル、ホテル、家屋など、地物の種別を表している。
【００３１】
時刻表ＤＢ２５２には、時刻表ＩＤ、規制、時刻、開始遅れ、終了遅れなどの情報が格納されている。時刻表ＩＤは、登録されているそれぞれの情報を一義的に示すための識別データである。規制は、時刻表ＩＤが示す規制情報を表している。図中には、駅の入り口Ｇ１〜Ｇ３が午前０：３０〜午前４：３０の間で閉鎖され、駅構内のリンクＬ３，Ｌ４，Ｌ６が通行不能となる場合のデータを例示した。この場合、通行不能となるため、「規制」欄には、「通行止め」が格納され、時刻欄には、通行止めとなる時刻が格納される。複数の時間帯で通行止めとなる場合には、時刻欄に、複数の時間帯を格納することもできる。開始遅れは、この時間帯の開始時刻（図中の例では０：３０）が遅れる可能性を示し、終了遅れは終了時刻が遅れる可能性を示している。駅構内の通行止めについては、規定通りに閉鎖されるため、開始遅れ、終了遅れは「無し」と設定されている。「時刻表ＩＤ＝１」が付されたこのデータは、リンクＬ３、Ｌ４、Ｌ６に適用される。従って、リンクデータ２５０ＬのこれらのリンクＩＤに対応するデータの「時刻表」欄に「１」が格納されることになる。リンクデータの時刻表欄には、複数の時刻表ＩＤを格納可能としてもよい。
【００３２】
時刻表ＤＢ２５２には、上述のような「通行止め」の規制の他、種々の規制が格納可能である。例えば、本実施例では、電車などの交通機関の出発時刻も、その路線を通行可能な時間帯が限られているという意味で規制条件の一種とみなし、時刻表ＤＢ２５２で管理するものとした。この場合には、「規制」欄には、例えば、「電車発着」などと格納することで交通機関であることを示し、「時刻」欄に出発時刻および到着希望時刻からなる時刻表を格納することができる。出発時刻と途中の経過駅までの所要時間という形式で格納するようにしてもよい。交通機関の場合には、出発時間や到着希望時刻が遅れる場合がある。出発時間の遅れは「開始遅れ」に記録し、到着希望時刻の遅れは「終了遅れ」に記録することができる。これらの時間は、後述する通り、経路探索時に考慮される値であり、任意に設定可能であるが、一例として、過去所定期間内の平均遅れ時間や最大遅れ時間などに基づいて設定することができる。
【００３３】
時刻表ＤＢ２５２には、更に、各時刻における気象条件を求めるためのデータを記録させることもできる。本実施例では、日当たり状況を求めるためのデータ（以下、「日当たりデータ」という。）を記録させるものとした。日当たりデータの設定方法および構造については、後で日当たりを考慮した経路探索の方法を説明する際に、併せて説明する。
【００３４】
Ｃ．経路案内例：
以下、経路案内の具体例を示した後、これを実現するための処理内容について説明する。図３は経路案内例を示す説明図である。端末１００の画面例を示した。図３（ａ）は、ユーザが出発地Ｓおよび目的地Ｇを地図上で指定した状態を示している。出発地Ｓは、ＧＰＳ１４０で検出された現在位置を用いるようにしてもよいし、ユーザが地図上でマウス等のポインティングデバイスで指定してもよい。目的地Ｇは、ユーザが地図上でポインティングデバイスにより指定したり、地物の名称などから検索したりする方法で指定することができる。
【００３５】
図３（ｂ）は、探索条件の入力画面例である。この例では、目的地Ｇへの到着希望時刻、交通機関の使用可否、屋根、空調、日陰、階段などの探索条件の指定を行う例を示した。「屋根」とは屋根が存在する経路を優先するという条件、「空調」は建物内や地下街など空調が備えられている経路を優先するという条件、「日陰」は日陰になる経路を優先するという条件、「階段」は階段のない経路を優先するという条件である。探索条件には、それぞれ優先順位を設定することができるようになっている。この例では、屋根、空調、日陰の順に優先され、階段については探索条件から外す旨の指定がなされている。
【００３６】
図３（ｃ）は、経路案内時の画面例である。ユーザの現在位置ＰＰは黒丸で示され、案内すべき経路はハッチングを付して示される。この経路は、目的地Ｇに向かう最短経路ではなくやや遠回りした経路となっている。領域Ａには、建物が存在しておらず、日当たりが良い地域であるため、「日陰」優先という探索条件に適合しないからである。このように本実施例では、最短経路や所要時間最短となる経路に限らず、ユーザから指定された探索条件に適合する経路を探索する。探索条件を反映した経路探索の方法は後述する。
【００３７】
図３（ｄ）は経路案内時の画面例である。案内すべき経路が、図３（ｃ）と異なり、目的地Ｇへの最短経路となっている。本実施例では、経路案内の過程で、ユーザから指定された到着希望時刻の要求を満たさないと判断される状態になった場合には、再度経路探索を実行し、案内すべき経路を変更する機能を有している（以下、このように再度、経路探索を実行する機能を「リルート」と言う。）。リルート時には、ユーザから指定された探索条件のうち、優先度の低い条件、図３の例では「日陰」という条件を外して経路探索を行う。こうすることにより、到着希望時刻に間に合わないことが懸念される状況では、図３（ｄ）に示すように、日向となる領域Ａを通る経路が案内されることになる。
【００３８】
リルートは、種々のタイミングで実行することができる。例えば、経路案内を開始した後、一定の時間が経過するたびに行うようにしてもよい。本実施例では、予め設定されたチェックポイントを通過する時点でリルートを行うようにした。
【００３９】
図４はリルートのチェックポイント設定例を示す説明図である。チェックポイントの設定にはモードＡ〜モードＤの４つのモードがある。モードＡは均等間隔で設定するモードである。図中の黒丸がチェックポイントを表している。図示するように、モードＡでは、出発地から目的地まで均等間隔でチェックポイントが設定される。例えば、予め設定された一定の間隔で出発地から順次、チェックポイントを配置するようにしてもよいし、出発地から目的地までを所定数で等分した位置にチェックポイントを配置するようにしてもよい。
【００４０】
モードＢは交差点にチェックポイントを設定するモードである。交差点は経路の分岐であるから、モードＢは経路を変更可能な最小限の箇所でリルートの要否を判断するモードであると言える。従って、モードＢによれば、リルートの要否の判断およびリルートに要する処理負担を軽減することができる利点がある。
【００４１】
モードＣは交通機関の乗降場所にチェックポイントを設定するモードである。図中では、バス停にチェックポイントが設定された例を示した。このモードによれば、経路案内の途中で、徒歩で移動するか、交通機関を利用するかの変更を効率的に行うことができる利点がある。
【００４２】
モードＤはチェックポイントを不均等間隔に設定するモードである。モードＤでは、出発地Ｓから目的地Ｇに近づくにつれ、間隔が密となるようにチェックポイントが設定される。つまり、図の例では、チェックポイントＣｐ１、Ｃｐ２の間隔Ｌ２は、出発地ＳとチェックポイントＣｐ１との間隔Ｌ１よりも短い。同様に、チェックポイントＣｐ３，Ｃｐ４，Ｃｐ５と進むにつれ、それぞれの間隔は短くなる。経路案内時の状況と、経路探索時に想定されていた状況との差違は、目的地Ｇに近づくほど大きくなるのが通常である。従って、目的地Ｇに近づくほどリルートの要否を頻繁に判断することが好ましい。モードＤによるチェックポイントの設定には、こうした要請に応えることができる利点がある。
【００４３】
チェックポイントは図４に例示した他、種々の方法で設定することができる。図４に示した各モードは単独で用いる必要はなく、例えば、モードＢとモードＣとを組み合わせるなど、適宜、複数のモードを組み合わせて用いるようにしてもよい。また、複数のモードを組み合わせた場合には、複数のチェックポイントが近接して設定される可能性もある。このような場合には、近接したチェックポイントのうち、いずれか一方のみを選択して用いるようにしてもよい。
【００４４】
Ｄ．経路案内〜全体処理：
図５は経路案内システムの全体処理のフローチャートである。サーバ２００が実行する処理のみを示した。図示を省略したが、この処理の過程で、サーバ２００は必要に応じて端末１００と通信しており、端末１００では、サーバ２００に情報を授受するための処理が稼働している。
【００４５】
サーバ２００は、まず経路探索処理を実行する（ステップＳ１００）。この処理では、サーバ２００は、ユーザから出発地、目的地、探索条件等の指定を受け付け、出発地から目的地に至る経路を探索する。経路探索処理の内容は後で詳述する。
【００４６】
次に、サーバ２００は、探索された経路上に、チェックポイントを設定する（ステップＳ１３０）。チェックポイントの設定方法は、図４に示した通りである。モードＡ〜Ｄのいずれか一つを固定的に用いるようにしてもよいし、ユーザの指定によってモードを使い分けるようにしてもよいし、出発地から目的地までの距離などに応じて自動的にモードを選択するようにしてもよい。
【００４７】
その後、サーバ２００はユーザに対して経路を案内するための処理を開始する。まず、端末１００から現在位置を入力し（ステップＳ１３２）、チェックポイントにいるか否かを判断する（ステップＳ１３４）。ユーザが、チェックポイントに到達している場合には、時刻依存条件をクリアするか否か、つまり時刻依存条件を満たすか否かの判定を行う（ステップＳ１３６）。この実施例では、目的地への到着希望時刻のみを、ここで言う時刻依存条件として扱う場合を例示する。この場合、サーバ２００は、ステップＳ１３６では、ユーザの現在位置から目的地までの所要時間を求め、この所要時間を現在時刻に加えることによって、目的地への到着予測時刻を算出する。この到着予測時刻が、指定された到着希望時刻と同時または到着希望時刻よりも前である場合には、サーバ２００は、時刻依存条件をクリアしていると判定する。時刻依存条件をクリアしないと判断される場合には、サーバ２００は、再度、経路探索処理を実行する（ステップＳ１００）。
【００４８】
時刻依存条件をクリアしている場合には、サーバ２００は経路案内処理を行う（ステップＳ１３８）。ユーザがチェックポイントに至っていない場合にも（ステップＳ１３４）、同様である。経路案内処理では、端末１００に地図、現在位置、および案内すべき経路を表示する。これらの表示と併せて音声でユーザが進むべき方向を案内するようにしてもよい。経路案内は、これらの表示および音声案内を伴わない方法、例えば、端末１００の振動態様によって、ユーザの進行方向を知らせる方法を採ることもできる。サーバ２００は、以上の処理を目的地に到達するまで（ステップＳ１４０）、繰り返し実行する。
【００４９】
Ｅ．経路探索処理：
図６は経路探索処理のフローチャートである。サーバ２００が実行する処理であり、図５で示した全体処理のステップＳ１００に相当する処理である。サーバ２００は、ユーザからの指定に基づき最初に経路探索をする場合には（ステップＳ１０２）、ユーザＩＤ、出発地、目的地、探索条件、出発時刻を入力する（ステップＳ１０４）。出発地、目的地、探索条件の入力には、例えば、先に図３で示したインタフェース画面を用いることができる。探索条件には、時刻依存条件として、目的地への到着希望時刻が指定される。ユーザＩＤは、ユーザＤＢ２５４の情報を参照し、経路探索時に用いるユーザの移動速度などのデータを取得するために用いられる。
【００５０】
チェックポイントにおいて時刻依存条件がクリアできないと判定された場合に行われる再探索（図５のステップ１３６、Ｓ１００参照）の時には（図６のステップＳ１０４）、ユーザＩＤ等の条件は入力不要なので、ステップＳ１０４はスキップする。ただし、本実施例では、再探索時にはユーザの移動速度を変更することとした（ステップＳ１０６）。ここで、移動速度は、種々の方法で変更可能である。例えば、移動速度を所定値ずつ、または所定比率で増減させてもよい。また、出発地からチェックポイントに至るまでの従前の平均移動速度を用いるようにしてもよい。
【００５１】
こうして、経路探索に必要なデータの入力、設定が完了すると、サーバ２００は時刻依存条件を考慮して経路探索を実行する（ステップＳ１１０）。本実施例では、以下に示す通り、ダイクストラ法を用いて経路探索を行うものとした。時刻依存条件を考慮するため、ここでは所要時間をコストとして用いる。コストとしては、各リンクの距離を移動速度で除した値を用いることができる。ダイクストラ法は周知の手法であるため、詳細な説明は省略するが、本実施例に特徴的な部分についてのみ概要を説明する。
【００５２】
ステップＳ１１０の処理では、サーバ２００は、地図ＤＢ２５０に格納されたノード、リンクのデータを参照して、出発地からリンク単位で経路を延伸して経路候補を設定する（ステップＳ１１２）。そして、この経路候補について、コストの総和を求めるとともに、各ノードへの到達時刻を予測する（ステップＳ１１４）。通行規制などが付されている箇所では、待ち時間が生じる場合もある。例えば、通行止めが一定の時間帯においてのみ解除される場合には、サーバ２００は、この待ち時間を次のリンクのコストへ反映した上で（ステップＳ１１６）、最小コストとなる経路を選択する（ステップＳ１１８）。
【００５３】
図中に、待ち時間が生じた場合の処理例を示した。この例は、ノードＢ，Ｃ，Ｄと通行する経路を表している。ＢＣ間のコストは８、ＣＤ間のコストは２０である。ＣＤ間には２０：００〜６：００は通行止めとなる通行規制が設定されている。この状態で、ノードＣへの到着希望時刻が５：３０と想定される場合、ノードＣでは、待ち時間が３０分生じる。ステップＳ１１６の処理では、この待ち時間３０分をノードＣに続くリンク、即ちＣＤ間のリンクに反映させ、ＣＤのコストを５０（＝２０＋３０）として処理をするのである。こうすることにより、ＣＤ間に迂回路が存在する場合には、その迂回路を通る経路を設定することも可能となる。
【００５４】
ステップＳ１１４では、ユーザから指定された探索条件もコストに反映させることができる。例えば、階段を回避する探索条件が指定されている時は、階段に相当するリンクのコストを所定値または所定比率で増加させる。こうすることで、階段を通る経路が選択される可能性を抑制することができる。この他、気象条件に基づく探索条件を反映させる場合も同様である。気象条件に基づく探索条件を反映する際のコストの演算方法については、後述する。
【００５５】
サーバ２００は、以上の処理を到達時刻までに目的地に至る経路が探索されるまで繰り返し実行する（ステップＳ１２０）。かかる経路が得られない場合には、探索条件を変更して（ステップＳ１２２）、経路探索を再試行する（ステップＳ１１０）。図３に示したように、本実施例では、探索条件について優先順位が設定されているため、サーバは、ステップＳ１２２において、優先順位が最も低い条件を除外して経路探索を再試行するのである。この再試行でも経路が得られなかった場合には、サーバ２００は、ステップＳ１２２において、残った探索条件のうち優先順位が最も低い条件を除外して経路探索を更に試行することになる。
【００５６】
Ｆ．気象条件の反映：
本実施例では、図３で説明した通り、探索条件として「日陰優先」などの気象条件も設定することができる。このような探索条件が設定された場合、サーバ２００は、経路探索処理（図６）に、気象条件を反映してコストを算出し（図６のステップＳ１１４）、経路を探索することになる。以下では、気象条件をコストに反映する方法について説明する。ここでは、経路の日当たりに基づいて設定される「日当たりコスト」、雨降り時に屋根付きの経路を優先的に選択するために用いられる「雨降りコスト」、および夏や冬にできるだけ空調の効いた経路を選択するために用いられる「温度コスト」の設定を例にとって説明する。
【００５７】
図７は日当たり判定データの設定方法を示す説明図である。建物の平面形状および高さが既知の場合、太陽の位置が分かれば、幾何学的な解析によって建物の陰の形状を求めることが可能である。しかし、経路探索時に一つ一つの建物について陰を求めるための演算を行い、各リンクについて日陰か日向かを判定するのは処理負荷が多大となり、経路探索に長時間を要することになる。そこで、本実施例では、日陰か日向かを簡易な処理で判定するものとした。図７で示す日当たり判定データは、日陰か日向かを簡易に判定するために用いるデータである。
【００５８】
図７（ａ）は建物および太陽の配置を横から見た状態を示している。この状態では、建物の陰は、建物の接地部分（以下、「建物の足」と呼ぶ。）から距離Ｌｓの範囲に広がることになる。建物を横から見た状態における太陽の高さγは、時刻および季節によって図中の矢印のように変動する。これに伴い、陰の距離Ｌｓも変動する。距離Ｌｓは、「Ｌｓ＝建物の高さ／tanγ」で求めることができる。
【００５９】
図７（ｂ）は建物および太陽の配置の平面図である。ハッチングを付した部分が建物である。説明の便宜上、図７（ｂ）の上方を東、下方を西として示した。太陽が真南にある時（図中の位置Ｓ１）、建物の陰は、建物の足から真北にＬｓだけ伸びた矩形となる。建物の足の部分に対向する部分が辺Ｅｓ１である。
【００６０】
季節および時刻が決まると太陽の平面内での位置が決まる。一例として、太陽が位置Ｓ２にある時を考える。この時、建物の陰は、図中の破線で示すように平行四辺形状にずれ、辺Ｅｓ１は辺Ｅｓ２の位置にずれる。現実には太陽は平面内での位置のずれとともに高さも変化するため、陰の距離Ｌｓも同時に変化するが、ここでは平面的なずれのみを考えるものとする。また、図中に示した破線形状は、建物の北面Ｓｎに対応する陰にすぎない。本来は建物の南北方向の厚さを考慮する必要があり、南面Ｓｓに対応して陰となる平行四辺形の領域を求め、この領域と図中の破線領域とを包絡する領域が建物の陰となる。ただし、本実施例では、ここでも簡略化を行い、北面Ｓｎに対応する領域のみで陰を考えるものとする。この結果、平面内での太陽の位置は、陰の辺Ｅｓ１を東西方向にずらす要素として評価することができ、その影響は東西方向へのずれ角αで表すことができる。
【００６１】
以上より、太陽の位置および高さは季節および時間によって変動するが、その時の陰の形状は、建物の足を南北方向に距離Ｌｓだけ平行移動し、東西方向に角度αだけずらすことで得ることができる。図７（ａ）、図７（ｂ）では、建物の足が東西方向に位置する場合を例示したが、建物の足が東西方向からずれて配置されている場合でも、簡略的には同様の考え方で陰の形状を決めることができる。
【００６２】
上述の方法で陰の形状を決めるためには、距離Ｌｓと角度αを求める必要がある。この値は、建物の形状によらず一定であり、日本国内程度の範囲を考える時には、建物の接地場所に依存せず一定として扱うことができる。そこで、本実施例では、季節および時間と対応づけて距離Ｌｓ，角度αを与えるデータ（以下、「日当たり判定データ」という。）を予めテーブル形式で用意することとした。図７（ｃ）は日当たり判定データの構造例を示す説明図である。この例は、月単位で、各時刻における距離Ｌｓ、角度αを与える二次元テーブルとして構成した例に当たる。
【００６３】
図８は気象条件コスト算出処理のフローチャートである。経路探索処理（図６）のステップＳ１１４において、サーバ２００が実行する処理である。図８の例では、雨降りコスト、温度コスト、日当たりコストの３種類を考慮して気象条件コストを設定する例を示すが、いずれか一部を省略してもよいし、この他の要素を考慮してもよい。
【００６４】
この処理では、サーバ２００は、まず雨ふりコストＣｒを算出する（ステップＳ１１４ａ）。雨ふりコストＣｒとは、雨天時の経路探索において、屋根ありの経路を優先的に探索可能とするためのコストである。本実施例では、屋根なしの経路については、２．０×リンク長を雨ふりコストＣｒとし、屋根ありの経路については１．０×リンク長を雨ふりコストＣｒに設定する。この結果、屋根なしのリンクのコストは、屋根ありのリンクの２倍に設定されることとなる。両者のコスト比は、２倍に限定されるものではなく、種々の値に設定可能である。
【００６５】
次に、サーバ２００は、温度コストＣｔを算出する（ステップＳ１１４ｂ）。温度コストＣｔとは、夏や冬などに、建物内や地下街など空調のある経路を優先的に設定可能とするためのコストである。本実施例では、屋外、つまりエアコン無しのリンクに対しては、２．０×リンク長を温度コストＣｔとし、屋内、つまりエアコン有りのリンクに対しては、１．０×リンク長を温度コストＣｔと設定する。屋内外のコスト比は２倍に限定されるものではなく、種々の値に設定可能である。
【００６６】
次に、サーバ２００は、日当たりコストを算出する（ステップＳ１１４ｃ）。日当たりコストＣｓは、日陰の経路優先で経路探索するために用いられる値である。日陰が多いほど日当たりコストＣｓが小さくなるよう設定した。季節および時刻に応じて、図７（ｃ）で示した日当たり判定データを参照すれば陰の形状を決めるためのパラメータＬｓおよびαを得ることができる。リンクＬＬの周辺に建物Ｂ１、Ｂ２が存在する場合、これらの建物の陰は、このパラメータＬｓ、αを用いることにより、図中のハッチングを付した領域のように簡易的に求めることができる。
【００６７】
次に、こうして求められた陰のうち、建物の足に対向する辺を評価対象として用い、リンクのポリゴンＰＯＬに含まれる部分の長さを求める。建物Ｂ２の場合、対向する辺の全体がポリゴンＰＯＬに含まれるから、コスト算出に用いられる長さはＬ２である。建物Ｂ１の場合、対向する辺の一方の頂点ＰｂはポリゴンＰＯＬに含まれるものの、他方の頂点ＰａはポリゴンＰＯＬ外にある。従って、コスト算出に用いられる長さは、対向する辺の一部の長さＬ１である。こうして得られた長さの総和ΣＬｉが、ポリゴンＰＯＬ内の陰の部分の評価長さということになる。従って、日当たりコストＣｓは、リンク長さＬＬを用いて、「Ｃｓ＝（ＬＬ／ΣＬｉ）×ＬＬ」と求められる。日当たりコストＣｓは、上述の例に限らず種々の方法で設定可能である。例えば、陰の部分（図中のハッチング部分）とポリゴンＰＯＬの面積比を用いてもよい。
【００６８】
サーバ２００は、以上で求められた雨ふりコストＣｒ、温度コストＣｔ、日当たりコストＣｓの総和によって気象条件コストを求める（ステップＳ１１４ｄ）。ここでは、気象条件コストは、リンク長と同じ次元の値として求められることになる。経路探索時に所要時間をコストとして用いる場合には、ステップＳ１１４ｄの結果を、移動速度で除した値を気象条件コストとして用いればよい。
【００６９】
Ｇ．リルート例：
（１）到着希望時刻を時刻依存条件とする場合：
図９はリルートを行った例を示す説明図である。出発地から目的地まで向かう経路を案内する場合を例示した。途中の地点ＡＢ間では、バスまたは電車を利用するものとする。バスは所要時間５０分と短いが、３０００円の運賃が必要となる。電車は、運賃は２０００円と定額であるが、所要時間は７０分とバスよりも長い。電車およびバスは、ダイヤに従って運行されるため、出発時刻が限られる。本実施例では、図中に実線および破線で示す通り、それぞれ９時半、１０時、１０時半にＡ地点を出発するものとする。また、Ｂ地点から目的地までは、徒歩であれば所要時間１０分であり、タクシーを利用すれば運賃１０００円がかかるものの所要時間３分で済む。
【００７０】
上述の状況で、１１時半を到着希望時刻として指定し、９時５０分を出発時刻とする場合の経路探索、案内結果を示す。この例では、実施例（図５）と同様、到着希望時刻が時刻依存条件に該当する。当初は、９時５０分に出発した後、実線で示すように移動し、Ａ地点から１０時発の電車を利用してＢ地点に到着した後、Ｂ地点から徒歩で目的地に向かう経路が探索されたとし、案内時には実際のユーザの移動速度が想定よりも遅く図中に破線で示すように移動したとする。
【００７１】
サーバ２００は、この状態では１０時発の電車に乗ることができないと判断し、途中でスケジュール変更、即ちリルートを行う。この例では、徒歩でそのままＡ地点まで移動し、１０時半発のバスを利用し、Ｂ地点からはタクシーで移動することにより、到着希望時刻までに目的地に到達できる経路が得られるため、サーバ２００は、この経路をユーザに案内する。ユーザは当初予定されていた電車に乗れないことが分かっても、到着希望時刻に目的地に到達することができるため、経路案内に従って、安心して移動することができる。
【００７２】
（２）気象条件を時刻依存条件とする場合：
実施例では、目的地への到着希望時刻を時刻依存条件とする場合を例示した。この例では、チェックポイントにおいては、到着希望時刻までに到着できるか否かが判断され、これが満たされない時に経路探索処理が再試行される（図５のステップＳ１３６）。本実施例では、通行時刻に応じて変化する種々の探索条件を時刻依存条件として扱うことができる。例えば、図７，８で説明した気象条件を時刻依存条件として扱うこともできる。また、時刻依存条件は、一つである必要はなく複数であってもよい。従って、気象条件と到着希望時刻の双方を時刻依存条件として扱ってもよい。
【００７３】
図１０は気象条件に基づくリルートを行った例を示す説明図である。出発地から目的地に向かう経路上にＡルート、Ｂルートの２種類が存在する場合を考える。Ａルートは、午前中は日陰となっているが、午後は日向となる経路である。Ｂルートは、午前中は日向だが、午後は日陰となる経路である。ユーザからは探索条件として日陰優先が指定されているものとする。
【００７４】
出発時刻が１１時である場合、経路探索時には分岐点に１１：２０に到着すると推定されたとする。この時点では、午前中なので、日陰となっているＡルートが選択される。従って、Ａルートを経由して、合流地点に１２：１０、目的地に１２：３０に到着するという経路が得られ、この経路の案内が開始されることになる。経路の上側に、経路探索時に得られた各地点への到着時刻を示した。
【００７５】
経路の下側には、経路案内中の各地点への到着時刻を示した。１１時に出発した後、ユーザの移動速度が経路探索時の想定よりも遅く、分岐点に１１：４５に到着したとする。サーバ２００は、案内すべき経路（この例ではＡルート）が時刻依存条件を満足しているか否か、つまり日陰優先という条件を満足するか否かを判断する。Ａルートは午後には日向となるから、分岐点に１１：４５に到着した場合には、日陰優先という条件を十分に満足できないことになる。従って、サーバ２００は、時刻依存条件を満足できないと判断して、経路探索を再試行し、午後には日陰となるＢルートを経由する経路を選択する。この結果、ユーザは日陰となっているＢルートを経由し、合流点に１３：２０、目的地に１４：００に到着することができる。到着時刻が経路探索時の想定時刻１２：３０よりも大きく遅れる結果となっているのは、ユーザの移動速度が想定していたよりも遅いことが原因であり、Ｂルートが遠回りだからという訳ではない。
【００７６】
図１０の例において、到着希望時刻を併せて考慮してもよい。つまり、日陰優先および到着希望時刻の双方を時刻依存条件として扱ってもよい。例えば、図１０の例において到着希望時刻が１３：００であったとする。分岐点に１１：４５に到着した時点で時刻依存条件を判定すると、Ａルートは、午後には日向になるから日陰優先という条件は満たされない。また、ＡルートとＢルートの距離が同一であるとすれば、Ａルートを経由した場合の到着時刻は１４：００と推定されることになり、到着希望時刻も満たされない。つまり、Ａルートは、日陰優先および到着希望時刻という２つの時刻依存条件のいずれも満たさない経路となる。  これに対し、Ｂルートは日陰優先という条件は満たすが、到着希望時刻は満たさない経路となる。
【００７７】
図示したＡルート、Ｂルートの他に、Ｃルートが存在したものとする。Ｃルートは、近道または交通機関を利用した経路であり、Ｃルートを経由すれば、ユーザは目的地に到着希望時刻１３：００までに到着できるとする。Ｃルートが日陰優先という条件を満たす経路である場合には、Ａ〜Ｃルートのうち、Ｃルートのみが時刻依存条件を全て満たす経路となるから、サーバ２００はユーザに対してＣルートを案内することになる。
【００７８】
Ｃルートが日陰優先という条件を満たさない経路である場合には、時刻依存条件間の優先順位に応じてＢルートまたはＣルートが選択される。日陰優先を到着希望時刻よりも優先する場合にはＢルートが選択され、到着希望時刻を日陰優先よりも優先する場合にはＣルートが選択される。時刻依存条件間の優先順位は、予め固定としてもよいし、図３（ｂ）に示した入力画面で、到着希望時刻も含めて優先順位を指定可能としてもよい。
【００７９】
以上で説明した実施例の経路案内システムによれば、経路探索時の想定と実際の経路案内時の状況とが異なることにより、ユーザから指定された時刻依存条件が満たされない状況になった場合に、経路の再探索を行うことができる。この結果、時刻依存条件を満たす実用的な経路案内を実現することができる。  
【００８０】
Ｈ．変形例：
実施例では、ユーザの移動速度が経路探索時の想定よりも遅い場合を例にとって、リルート要否の判断方法およびリルート処理の例について説明した。経路探索時の想定と異なる状況が生じる原因としては、ユーザの移動速度に限らず、出発時刻が遅れた場合、移動中に寄り道をした場合、交通機関が遅れた場合、事故などによって移動に支障が生じた場合など種々の原因が挙げられる。ユーザの心拍数や呼吸数などを検出し、これに基づいて移動速度の変化を予測して、経路探索時の想定と異なる状況が生じるか否かを予測するようにしてもよい。
【００８１】
実施例の経路案内システムは、リルートに際し、種々の外部情報を利用してもよい。例えば、渋滞情報、天候の変化、事件・事故情報、商店のタイムサービス情報などを、ネットワーク上の他のサーバから取得し、これをリルートに活用してもよい。外部情報は、第１にリルートの要否を判断するトリガとして利用することができる。例えば、車両を対象とする案内では、渋滞情報が得られた場合、これをトリガとして到着希望時刻までに目的地に到着できるか否かを判断するようにしてもよい。渋滞が生じていたとしても、渋滞情報から得られる通過時刻を考慮した上で、案内予定の経路をとれば到着希望時刻までに到着可能であれば、リルートは不要と判断することができる。
【００８２】
外部情報は、第２にリルート時の経路選択に活用することもできる。例えば、曇りになるという天候情報が得られた場合、日向となる経路であったとしても、日陰優先という探索条件を満たすことになるから、経路探索時よりも柔軟に経路を選択することが可能となる。  
【００８３】
以上、本発明の種々の実施例について説明したが、本発明はこれらの実施例に限定されず、その趣旨を逸脱しない範囲で種々の構成を採ることができることはいうまでもない。
【図面の簡単な説明】
【００８４】
【図１】実施例としての経路案内システムの構成を示す説明図である。
【図２】地図ＤＢ２５０および時刻表ＤＢ２５２のデータ構造を示す説明図である。
【図３】経路案内例を示す説明図である。
【図４】リルートのチェックポイント設定例を示す説明図である。
【図５】経路案内システムの全体処理のフローチャートである。
【図６】経路探索処理のフローチャートである。
【図７】日当たり判定データの設定方法を示す説明図である。
【図８】気象条件コスト算出処理のフローチャートである。
【図９】リルートを行った例を示す説明図である。
【図１０】気象条件に基づくリルートを行った例を示す説明図である。
【符号の説明】
【００８５】
１００…端末
１１０…主制御部
１２０…通信部
１３０…コマンド入力部
１４０…ＧＰＳ
１５０…表示制御部
２００…サーバ
２２０…通信部
２３０…経路探索部
２４０…経路案内部
２５０…地図ＤＢ
２５２…時刻表ＤＢ
２５４…ユーザＤＢ
２５０Ｌ…リンクデータ
２５０Ｂ…地物データ
２５０Ｎ…ノードデータ
【図１】
2007205946.tif 000003
【図２】
2007205946.tif 000004
【図３】
2007205946.tif 000005
【図４】
2007205946.tif 000006
【図５】
2007205946.tif 000007
【図６】
2007205946.tif 000008
【図７】
2007205946.tif 000009
【図８】
2007205946.tif 000010
【図９】
2007205946.tif 000011
【図１０】
2007205946.tif 000012