JP4496323B2 - ナビゲーションシステム、ナビゲーション装置 - Google Patents

Description

本発明は、出発地から目的地までの旅行計画に従い、車両、列車、徒歩などの各種移動手段の案内を総合的に行うナビゲーションシステムに関する。

車両のみならず鉄道や徒歩を含む複数の移動形態を用いたナビゲーションシステムが知られている（特許文献１）。

特開２００１−１０８４５７号公報

特許文献１に開示されるナビゲーションシステムは、カーナビゲーション装置で用いられている地図データの一部をそのまま使って、携帯端末により徒歩移動の案内を行っている。しかし、カーナビゲーション装置の地図データは現在地の検出を前提として作成されているため、そのまま単に表示したのでは徒歩移動の案内に適さず、徒歩で移動するユーザにとっては目的地までの道順が分かりにくい。したがって、現在地を検出するための角速度センサやＧＰＳ受信機を携帯端末に搭載する必要があり、携帯端末のコストアップや大型化を招いている。

請求項１の発明は、車載ナビゲーション装置と、車載ナビゲーション装置と通信する携帯端末と、旅行計画を記憶し、携帯端末と通信する基地局サーバとを用いて、自動車と徒歩を少なくとも含む複数の移動手段による最終目的地までの総経路を案内するナビゲーションシステムにおいて、基地局サーバは、旅行計画に基づいて、総経路を構成する各経路の移動手段および目的地を表す目的地情報と公共交通機関情報とを含む旅行情報を携帯端末に送信し、携帯端末は、送信された旅行情報に基づいて目的地情報を車載ナビゲーション装置に送信し、車載ナビゲーション装置は、目的地情報と道路地図を表示するための地図データとを記憶しており、目的地情報に基づいて以降の移動手段が何であるかを判断し、以降の移動手段が徒歩を含む場合には、その地図データに基づいて道路地図を所定の範囲内について要約することにより、徒歩用地図を作成して携帯端末に送信し、携帯端末は、送信された徒歩用地図を受信し、徒歩移動時にその徒歩用地図を表示するものである。

請求項２の発明は、請求項１のナビゲーションシステムにおいて、車載ナビゲーション装置は、道路形状の直線化処理と直交化処理とを行うことによって、徒歩用地図を作成するものである。
請求項３の発明は、請求項１または２のナビゲーションシステムにおいて、車載ナビゲーション装置は、地図データに基づいて徒歩移動の出発地から目的地までの経路を探索し、その探索された経路の全体を少なくとも含むように道路地図を要約するときの所定の範囲を設定するものである。
請求項４の発明は、請求項１〜３のいずれかのナビゲーションシステムにおいて、携帯端末は、徒歩用地図を受信したら旅行情報に基づいて次の移動手段が何であるかを判断し、次の移動手段が徒歩である場合には、その徒歩移動の経路を表す徒歩用地図を直ちに表示するものである。
請求項５の発明による車載ナビゲーション装置は、請求項１〜４のいずれかのナビゲーションシステムにおいて用いられるものである。

本発明によれば、車載ナビゲーション装置は、地図データが表す通常の道路地図を所定の範囲内について要約することにより、徒歩用地図を作成して携帯端末に送信する。携帯端末は、車載ナビゲーション装置から送信された徒歩用地図を受信し、徒歩移動時にその徒歩用地図を表示することとした。このようにしたので、徒歩移動の案内に適した徒歩用地図をユーザに提供することができ、現在地を検出するための角速度センサやＧＰＳ受信機を携帯端末に搭載する必要がない。

−システム構成−
本発明の一実施形態によるナビゲーションシステムを図１に示す。図１のナビゲーションシステムは、自動車に搭載されたカーナビゲーション装置（以下、車載機という）１、携帯端末２、およびユーザの自宅に備えられたパソコン３を、情報管理センターにあるサーバ４と接続することにより、様々な移動手段に対してシームレスなナビゲーションサービスを提供するものである。車載機１と携帯端末２は無線接続によりインターネットなどの公衆通信網１００と接続され、この公衆通信網１００を介してサーバ４と接続される。またパソコン３も、公衆通信網１００を介してサーバ４と接続される。なお、車載機１の無線通信は、実際には車載機１に接続された携帯端末２を介して行われる。しかし、ここでは図の簡略化のため、車載機１から直接に無線通信を行っているように図示している。

図１に示すナビゲーションシステムは、ユーザが予め旅行計画を立ててサーバ４に登録しておくことで、車載機１と携帯端末２を用いて、その旅行計画に従ってユーザを最終的な目的地まで案内する。このとき、登録された旅行計画における自動車の経路を車載機１により案内し、それ以外の経路を携帯端末２により案内する。たとえば、車載機１を用いて自宅から旅行計画の最終目的地付近の駐車場までの自動車経路を案内し、携帯端末２を用いてその駐車場から最終目的地までの徒歩経路を案内する。このように、車載機１が案内する自動車の目的地と、旅行計画の最終目的地とは、一致しなくてよい。

車載機１は、自動車を用いた移動中において、その自動車の目的地までユーザを案内する。このとき周知の経路探索処理を実行することにより、自動車の出発地から目的地までの経路を探索して、道路地図上に経路を表示する。後述するように、車載機１が行う経路探索処理に先立ち、ユーザが予め立てた旅行計画により自動車の目的地がサーバ４から送信される。そのため、通常のナビゲーション装置のようにユーザが車載機１に目的地を入力する必要はない。

携帯端末２は、鉄道等の公共交通機関および徒歩による移動中におけるユーザの案内に用いられる。公共交通機関による移動中には、たとえば鉄道で移動中の場合は、列車の発車時刻案内や運行状況の通知などを行う。また徒歩移動中には、その徒歩目的地まで案内するための地図を表示する。さらに、携帯端末２は前述したように車載機１と接続され、車載機１とサーバ４の間の通信に用いられる。このときの接続は赤外線などによる無線接続であってもよい。携帯端末２には、こうした処理を実行するためのソフトウェアアプリケーションが組み込まれた携帯電話やＰＤＡなどが用いられ、それを起動することによって、本実施形態のナビゲーションシステムにおいて携帯端末２として使用することができる。

パソコン３は、ユーザが予め旅行計画を立てるのに用いられる。ユーザは、後で説明するようにパソコン３に最終目的地などのデータを入力することにより、自動車、鉄道、徒歩などの様々な移動手段を含んだ旅行計画を立てることができる。この旅行計画はサーバ４に送信され、サーバ４において登録される。サーバ４に登録した旅行計画はパソコン３から閲覧できるとともに、内容を変更することも可能である。

サーバ４は、パソコン３から送信された旅行計画を登録し、その旅行計画に基づいて、後で説明するようなユーザを最終目的地まで案内するための様々な情報提供を、車載機１や携帯端末２に対して行う。そのためサーバ４は、鉄道などの公共交通機関に関する各種情報のデータベースを有しているとともに、公共交通機関の運行状況や自動車の道路渋滞状況を逐次収集している。

なおサーバ４において、パソコン３により旅行計画を登録したユーザと、車載機１や携帯端末２を使用するユーザが同一であることを認識する必要がある。そのためサーバ４には、ユーザごとに発行されるＩＤと、そのＩＤに対応する携帯端末２の電話番号とが予め登録されている。ユーザがＩＤを指定して旅行計画をサーバ４に登録すると、サーバ４はその指定されたＩＤに対応する電話番号を有する端末（すなわち、携帯端末２）からの発信を検出し、その携帯端末２を介して、登録された旅行計画に基づく様々な情報をユーザに提供する。

−車載機の構成−
図２は、車載機１の構成を表すシステムブロック図である。以下、各構成について順に説明する。自動車の現在地を検出する現在地検出装置１０１は、自動車の進行方向を検出するジャイロ１０１ａ、車速を検出する車速センサ１０１ｂ、ＧＰＳ衛星からのＧＰＳ信号を検出するＧＰＳセンサ１０１ｃ等からなる。制御回路１０２はマイクロプロセッサおよびその周辺回路からなり、ＲＡＭ１０４を作業エリアとしてＲＯＭ１０３に格納された制御プログラムを実行して、各種の制御を行う。

画像メモリ１０５は、表示モニタ１０６に表示する画像データを格納する。この画像データは、道路地図描画用データや各種の図形データ等からなり、地図データ記録部１０７に記録されている地図データに基づいて、制御回路１０２において作成される。画像メモリ１０５に格納された画像データを用いて、表示モニタ１０６に地図情報が表示される。表示モニタ１０６にはタッチパネルが用いられており、ユーザが画面上の任意の位置を指等で押して選択する操作を行うことにより、各種処理の選択などが行われる。なお、タッチパネルの代わりに、ハードウェアスイッチやジョイスティック、あるいはリモコンなどを用いて操作してもよい。

地図データ記録部１０７は、道路地図を表示するための地図データを記録する大容量記録装置であり、たとえばＤＶＤ−ＲＯＭやＨＤＤなどが用いられる。この地図データ記録部１０７から必要な地図データが読み込まれることにより、表示モニタ１０６に道路地図が表示される。さらに、制御回路１０２において経路探索処理を実行することによって、現在地から自動車の目的地まで自動車で移動するときの経路が探索され、道路地図にその経路が表される。

−ナビゲーションサービスの概要−
図３は、本実施形態のナビゲーションシステムが提供するナビゲーションサービスの概要を示す図である。ユーザは、はじめにパソコン３により情報管理センターのサーバ４へ旅行計画を登録する（図３（１））。最終目的地を指定し、さらに旅行日や出発時刻を指定することにより、その最終目的地へ至る総経路が演算され、旅行計画として登録される。この総経路は、自動車、鉄道、徒歩等の様々な移動手段による経路が繋がって構成されている。なお、総経路を演算するときに移動手段を指定するようにしてもよい。さらに、交通料金（有料道路の通行料金、駐車料金、公共交通機関の運賃など、最終目的地まで移動するために支払う料金）や、最終目的地までの所要時間などの条件を加味してもよい。このような総経路を演算する処理は、パソコン３で実行しても、あるいはパソコン３からの入力情報によりサーバ４で実行しても、どちらでもよい。

上記のようにして演算された総経路の例を図４に示す。図４において、自宅４１から最終目的地４５までの移動手段はそれぞれ次のとおりである。自宅４１から駐車場４２までは、経路４６を自動車で移動し、駐車場４２から乗車駅４３までは、経路４７を徒歩で移動する。乗車駅４３から降車駅４４まで経路４８を鉄道で移動した後に、降車駅４４から最終目的地４５までの経路４９を徒歩で移動する。このような経路４６〜４９よりなる総経路が、旅行計画としてサーバ４に登録される。以降では、この図４の旅行計画に沿って説明を進めることとする。なお、サーバ４に登録された旅行計画は、前述したようにパソコン３において閲覧することができ（図３（２）)、変更することも可能である。

サーバ４は、図４の旅行計画が登録されると、経路４６〜４９のそれぞれの予想所要時間を計算する。さらにこのとき、経路４６，４７の予想所要時間と、ユーザが指定した旅行日および出発時刻とにより、乗車駅４３および降車駅４４における列車の発着時刻および発着ホーム番号、列車名、さらには駅構内の地図など、経路４８においてユーザを案内するために必要な情報を前述のデータベースから検索する。検索したこれらの情報は旅行計画と共に管理される。なお、ここでは鉄道の例について述べているが、他の公共交通機関の場合にも同様に、それぞれに適した内容の情報をデータベースから検索する。たとえば飛行機の場合は、空港のチェックインカウンターの場所やチェックイン時刻などを検索する。以下、このような情報を公共交通機関情報という。

自宅４１を出発する際、ユーザは車載機１に携帯端末２を接続し、携帯端末２からサーバ４に案内開始の要求を発信する（図３（３））。この要求発信はサーバ４により検出され、予め登録された旅行計画に基づいて、各経路の目的地とその間の移動手段を表す情報（以下、目的地情報という）が、前述の公共交通機関情報と併せてサーバ４から携帯端末２に送信される（図３（４））。以下、サーバ４から携帯端末２へ送信される目的地情報と公共交通機関情報を、まとめて旅行情報という。これにより、各経路の目的地である駐車場４２、乗車駅４３、降車駅４４および最終目的地４５のそれぞれの位置と、その間の経路４６〜４９の各移動手段が、経路４８における鉄道の公共交通機関情報と共に携帯端末２に送信される。なお、このときサーバ４では、前述したように携帯端末２の電話番号とユーザＩＤを対応付けることで、そのユーザの旅行計画を特定する。

携帯端末２が上記の旅行情報を受信すると、そのうちの目的地情報は携帯端末２から車載機１へと送信される。車載機１は、その目的地情報における駐車場４２の位置情報、すなわち自動車の目的地に基づいて、経路４６を探索する。なお本実施例では、サーバ４から携帯端末２へと送信するデータ量を少なくするため、前述のように目的地と移動手段を表す目的地情報および公共交通機関情報のみを、旅行情報として送信している。したがって、サーバ４に登録されている旅行計画では既に経路４６は探索済みであるが、この経路４６を表す情報はサーバ４から車載機１に送信されない。このことより、車載機１において経路４６を探索する処理が必要となる。なお、このとき車載機１において探索した経路が、旅行計画時にパソコン３またはサーバ４によって探索された経路と等しくなるようにするため、車載機１とパソコン３またはサーバ４で同じ経路探索アルゴリズムを用いることが好ましい。車載機１は、探索した経路４６に基づいて自宅４１から駐車場４２までの間の案内を行う。

駐車場４２に到着したら、ユーザは自動車を降車するための次の二つの処理を車載機１に実行するように要求する。このときの車載機１の操作方法については、後で説明する。１つ目の処理では、地図データに基づいて、駐車場４２（徒歩移動の出発地）から乗車駅４３（徒歩移動の目的地）までの経路４７を探索し、さらに探索された経路４７を徒歩移動するための地図を作成する。このとき、前述の目的地情報における駐車場４２と乗車駅４３の位置情報が用いられる。この地図は、経路４７の全体を含むように設定される所定の範囲内について、通常の道路地図を徒歩移動に適するように要約（ディフォルメ）したものであり、後で説明するような方法で作成される。

さらに、降車駅４４と最終目的地４５の位置情報を用いて、経路４９の地図も上記と同様の方法で通常の道路地図をディフォルメすることにより作成する。作成された経路４７および４９の地図は車載機１から携帯端末２へ送信され、携帯端末２において受信されて記憶される。以下、これらの地図を徒歩用地図という。なお、携帯端末２において徒歩用地図を受信したら、目的地情報における各経路の移動手段から次の移動手段が何であるかを判断し、本実施例のように次の移動手段が徒歩である場合には、自動車を降車した後に備えて、その経路４７を表す徒歩用地図を直ちに表示しておくことが好ましい。

車載機１は、２つ目の処理として、自動車を降車する旨を携帯端末２を介してサーバ４に通知する（図３（５））。サーバ４は、この通知を受信すると、自動車から次の移動手段に切り替わったことを認識する。なお、以上説明した二つの処理は、自動車のエンジンを止める前に行ってもよいし、エンジンを止めた後にも車載機１が動作できるようにして行ってもよい。

自動車を降車した後、ユーザは携帯端末２に表示される経路４７の徒歩用地図に従って経路４７を乗車駅４３まで移動する。なお、前述のように降車時には既に経路４７の徒歩用地図が表示されていることが望ましいが、ユーザの携帯端末２の操作に応じて表示してもよい。さらに、前述したようにサーバ４から携帯端末２に送信済みの公共交通機関情報により、乗車駅４３における列車の発車時刻や発車ホーム番号、列車名、駅構内地図などの乗車駅の情報も表示する。この乗車駅の情報は、ユーザが携帯端末２を操作することにより経路４７の徒歩用地図と切り替えて表示してもよい。あるいは、自動的に表示が切り替わるようにしてもよい。たとえば、列車の発車時刻が所定時間内に近づいたときや、自動車の降車後から所定時間経過したときなどに、経路４７の徒歩用地図に切り替えて乗車駅の情報を表示するようにする。

乗車駅４３に到着して列車に乗車したら、ユーザは携帯端末２を操作して鉄道への乗車をサーバ４に通知する（図３（６））。そのまま経路４８を移動して降車駅４４に着き、列車を降車したら、ユーザは携帯端末２を操作することにより、鉄道からの降車をサーバ４に通知する（図３（７））。その間、携帯端末２では降車駅４４の駅名や列車の到着時刻、到着ホーム番号、駅構内地図などの降車駅の情報を表示する。

なお、ここでは列車の乗換えがない場合について説明しているが、途中で列車を乗換える場合には、その乗換えに必要となる情報も併せて、鉄道による移動中の携帯端末２に表示する。たとえば、乗換駅名、乗換駅への到着時刻と到着ホーム番号、乗換え後の列車の列車名、発車時刻、発車ホーム番号などを表示する。これらの情報は、前述の公共交通機関情報によってサーバ４から送信される。途中に複数の乗換駅がある場合には、全ての乗換駅について上記のような乗換え情報を表示する。

降車駅４４への到着後は、前述のようにして車載機１から送信され携帯端末２に記憶された経路４９の徒歩用地図を携帯端末２に表示する。このときの表示タイミングは、前述した鉄道からの降車通知のタイミングと連動させてもよいし、ユーザの操作に応じて表示してもよい。ユーザは、この経路４９の徒歩用地図に従って、経路４９を最終目的地４５まで徒歩により移動する。最終目的地４５に到着したら、ユーザは携帯端末２を操作して目的地へ到着したことをサーバ４に通知する（図３（８））。この通知をサーバ４が受けると、サーバ４の処理が終了し、上記のようなナビゲーションサービスが完了する。

以上説明したようにして、図３に示す一連の処理が終了し、本実施形態によるナビゲーションサービスが完了する。なお、上記に説明した鉄道列車の発車時刻や到着時刻など、時刻に関する案内を携帯端末２で行うときには、現在からその時刻までの残り時間も併せて案内する。この残り時間の案内では、正確な現在時刻を得るために車載機１からのＧＰＳによる時刻情報を用いるが、その具体的な方法については後で説明する。

−旅行計画の変更−
次に、自宅４１から最終目的地４５への移動途中で旅行計画を変更する場合について説明する。サーバ４は、前述のように公共交通機関の運行状況や自動車の道路渋滞状況を逐次収集しており、その収集した情報に基づいて、必要に応じて旅行計画を変更する。たとえば、道路が渋滞や通行止めである場合や、公共交通機関の運行が中断または中止されている場合など、登録されている旅行計画の遂行に支障があると認められるとき、サーバ４は旅行計画を変更する。旅行計画を変更した場合、サーバ４は車載機１または携帯端末２に対して、次に図５を用いて説明するような情報を送信する。

図５は、旅行計画を変更したときにサーバ４から送信される情報を、図３に書き加えて示した図である。そのときの旅行計画の変更内容や移動手段に応じて、図中に破線で示す（Ａ）自動車目的地の変更情報、（Ｂ）乗車列車の変更情報、および（Ｃ）乗換え列車の変更情報、のうちいずれかがサーバ４から送信される。変更の内容によっては、移動手段が変わるたびに（Ａ）〜（Ｃ）のいずれかが送信される場合もあるし、同じ移動手段で複数回送信される場合もある。以下、（Ａ）〜（Ｃ）の内容を順に説明していく。

（Ａ）自動車目的地の変更情報は、道路が渋滞や通行止めであるため、自動車の目的地（図４の駐車場４２）まで辿り着けないか大幅に時間が遅れることが予想される場合に送信される。あるいは、鉄道運行が中断・中止されているため、乗車駅４３から降車駅４４まで辿り着けない等の事態が予想される場合に送信される。このような場合、サーバ４は自動車の目的地を駐車場４２から別の場所へ変更して、旅行計画全体に支障が出ないようにする。自動車の目的地を変更したら、サーバ４はその情報を自動車目的地の変更情報として車載機１に対して送信する。

ユーザが既に自宅４１を出発して自動車に乗っている間にその自動車の目的地を変更する必要が生じた場合には、前述のように自動車目的地の変更情報を送る。この情報を受信した車載機１では、変更後の自動車の目的地を用いて再度経路探索を実行し、ユーザをその目的地まで案内する。しかし、ユーザが自宅４１を出発する前であれば、出発時に（４）で送信する旅行情報において変更後の自動車の目的地を送信すればよいため、自動車目的地の変更情報を送る必要はない。

（Ｂ）乗車列車の変更情報は、上記で説明したように、自動車目的地の変更によって乗車駅４３が変更された場合に送信される。あるいは、乗車駅４３は変わらないが、乗車駅４３への到着予定時刻や鉄道運行状況等により、出発時の予定とは異なる列車に変更する必要が生じた場合にも送信される。このような場合、サーバ４は旅行計画全体に支障が出ないように、乗車する列車を変更して降車駅４４へ到着できるようにする。あるいは、他の降車駅であっても最終目的地４５へ到着できればよい。こうして乗車する列車を変更したら、サーバ４はその情報を乗車列車の変更情報として携帯端末２へ送信する。なお、新たに列車の乗換えが生じる場合には、その乗換え情報も併せて送信する。

以上説明した乗車列車の変更情報を送るのは、ユーザが自動車を降りてから鉄道に乗車するまでの間か、または自動車に乗っている間である。この情報を受信した携帯端末２は自身の画面か、あるいは自動車に乗車中であれば車載機１の画面に、変更後の乗車列車の案内を表示する。これにより、ユーザは変更後の乗車列車を確認してそれに乗車することができる。

（Ｃ）乗換え列車の変更情報は、列車に乗車した後の鉄道の運行状況等により、乗車時の予定とは違う鉄道経路を通る必要が生じた場合に送信される。この場合、サーバ４は降車駅４４、あるいは他の降車駅へ到着できるような鉄道経路を検索し、その鉄道経路を通るための乗換え情報を乗換え列車の変更情報として携帯端末２へ送信する。この乗換え列車の変更情報を送るのは、ユーザが鉄道に乗車している間である。携帯端末２は受信した乗換え情報の変更情報を画面に表示する。これによってユーザは変更後の鉄道経路に従って降車駅まで到着することができるようになる。

以上説明したようにして、サーバ４において旅行計画が変更され、その変更内容に従ってユーザへの案内が行われる。なお、ここでは移動手段に変更がない場合の例について説明しているが、最終目的地までの移動手段を変更してもよい。たとえば、鉄道をやめて自動車で最終目的地付近まで移動するようにしてもよいし、あるいは他の公共交通機関を用いるようにしてもよい。さらに、旅行計画に変更があった場合の移動手段をユーザが決定できるようにしてもよい。

−徒歩用地図の作成方法−
ここで徒歩用地図の作成方法について説明する。前述した図４の経路４７および４９の徒歩用地図は、車載機１に記憶されている地図データによって表される通常の道路地図を要約することにより作成される。このとき、その地図データに基づいて、設定された地図範囲内に対してディフォルメ処理と呼ばれる処理を実行することで、道路地図の要約を行う。ディフォルメ処理の内容について以下に説明する。

図６および図７は、それぞれ本発明で徒歩用地図を作成するときに利用されるディフォルメ処理の内容を説明するための詳細説明図である。図６では、ディフォルメ化処理（１）として、道路形状の直線化（構成点の間引き処理）について説明する。ここで、地図データにおいて道路形状は、それぞれに位置情報（座標情報）を有する、ノードと呼ばれる構成点の集合によって決定されている。

図６（ａ）に示す原図形が元の道路形状であるとすると、これに対して、（ｂ）に示すように、その両端点（第１端点、第２端点とする）を結んだ線（破線）に対する各点の垂線距離を計測し、そのうち最長の垂線距離ｄｍａｘを求める。そして、ｄｍａｘがあらかじめ設定された規定値ε以上ならば、対応する構成点を残す。つまり、（ｃ）に示すように、そのｄｍａｘに対応する点を新たな端点（第３端点とする）として追加して、第１端点と第３端点、および第３端点と第２端点とをそれぞれ結ぶ、破線で示す線を引く。

このように、最長垂線距離ｄｍａｘがεよりも小さくなるまで、同様の処理を繰り返していく。そして、（ｄ）に示す状態でｄｍａｘ＜εとなったとする。このときに、隣接する端点相互を結んだ直線を引き、その直線の形状によって道路形状を表す。その結果、（ｅ）に示すような道路形状となる。このようにして、道路形状の直線化処理を行う。

図７では、ディフォルメ処理（２）として、道路形状の直交化について説明する。図７（ａ）に示す図形が元の道路形状であるとすると、これに対して、最初の折れ線の最初の点（Ｐ１）を通り、ｘ軸（地図の横方向）と平行な直線を求める。この直線を、破線で示す基準線とする。次に、（ｂ）に示すように、点Ｐ１と次の点Ｐ２を結ぶベクトルＰ１Ｐ２について、基準線となす角θを求める。

次に、（ｃ）に示すように、ベクトル長を固定した状態で、θ’＝ｎ・Δθ（ｎは整数）となるように、ベクトルＰ１Ｐ２を、始点Ｐ１を中心に回転させる。これにより、終点Ｐ２を移動する。なお、角度Δθは、ベクトルＰ１Ｐ２を回転させるときの単位角度であり、たとえば４５°とする。この処理により、ベクトルＰ１Ｐ２と基準線とのなす角が、単位角度Δθ刻みで補正される。

次に、（ｄ）に示すように、点Ｐ２が移動した分（ｄｘ，ｄｙ）を、点Ｐ２の次の点に順次伝搬させていく。交差点の場合には、分岐させて伝搬させていく。これにより、他の点の位置が次々に移動する。

その後は、以上で説明したのと同様の処理を繰り返す。すなわち、（ｅ）に示すように、点Ｐ２を通るｘ軸と平行な直線を基準線とし、次のベクトルＰ２Ｐ３と基準線とのなす角θを求める。そして、（ｆ）に示すように、θ’＝ｎ・Δθとなるよう、始点Ｐ２を中心にベクトルＰ２Ｐ３を回転させ、終点Ｐ３を移動する。その後、（ｇ）に示すように、点Ｐ３が移動した移動分（ｄｘ、ｄｙ）を、Ｐ３の次の点に伝搬させていく。交差点の場合には分岐させて伝搬させていく。

このような処理を、全ての点に対して順次行うことにより、最終的に（ｈ）に示すような道路形状となる。このようにして、道路形状の直交化処理を行う。以上説明したようにして、道路形状の直線化および直交化処理を行うことにより、ディフォルメ処理が終了する。このディフォルメ処理を、設定した地図範囲内に対して行うことで、徒歩用地図を作成することができる。

以上説明したようにして作成された徒歩用地図上には、ディフォルメ処理を行う前の元の地図と同様に、各種施設などの位置を示すランドマークが表示される。しかし、ディフォルメ処理によって道路形状が簡略化されることにより、徒歩用地図における道路の位置は、元の地図より変化する。そのため、徒歩用地図上に元の位置のままランドマークを表示したのでは、道路とランドマークとの位置関係を正しく表すことができない。したがって、ディフォルメ処理を行った後には、ランドマークの位置補正を行うことが必要となる。その方法について、以下に説明する。

図８では、ランドマークの位置補正の概要について説明する。図８（ａ）に示すように、ディフォルメ処理を行う前の地図では、ランドマークの位置と道路との微妙な位置関係が記述されている。この元の地図に対して、上記で説明したようなディフォルメ処理を行い、さらにランドマークの位置をそのままにして表示すると、たとえば（ｂ）に示すような徒歩用地図となる。

（ｂ）に示す徒歩用地図では、道路の位置のみが（ａ）に示す元の地図に対して変化しているため、元のランドマークと道路との位置関係が保たれていない。たとえば、地図の中央付近にある郵便局に着目すると、この郵便局は、（ａ）に示す元の地図と、（ｂ）に示す地図とで、互いに道路の反対側に位置している。そこで、このような不都合を是正するためにランドマークの位置補正を行い、その結果、（ｃ）に示すように、道路とランドマークとの位置関係が、元の地図上での位置関係と近似するようにする。

次に、図９を用いて、ランドマークの位置補正の詳細アルゴリズムについて説明する。ランドマークの位置補正では、はじめに、図９（ａ）に示すように、要約前後での形状ベクトル間のペアリストの作成を行う。ここで、上記に説明したようなディフォルメ処理を行うことによって、道路の形状を表す形状ベクトルの構成点数が元のものから変化する。従って、ペアリストを作成するときには、このペアリストで関係付けられた形状ベクトル間の分岐点間の方向性が合致する必要がある。すなわち、ディフォルメ処理の前後で、それぞれの分岐点の位置に対して、１対１に対応関係が成立するようにする。

このようにしてペアリストを作成したら、その次に（ｂ）に示すように、各形状ベクトルのノルムと、対応する分岐点間の距離の割合を等価にする補正処理を行う。すなわち、要約する前の元の地図において、ランドマークが最近接する形状ベクトルのノルム値と、その形状ベクトルを含む道路経路における、そのランドマークから各分岐点までの距離の割合を測定する。この測定値により、ディフォルメ処理後の要約地図においても、上記のペアリストによって対応付けられる形状ベクトルに対して、そのノルム値と、ランドマークから分岐点間までの距離の割合が等価となるように、ランドマークの位置を計算する。そして、計算した位置にランドマークを表示する。

以上説明したランドマークの位置補正では、ディフォルメ処理によって徒歩用地図に変換することにより道路の形状や距離が変わるので、対応するランドマーク（道沿いにある店等）も道路に合わせて座標を変換する必要がある。そのため、変換前のランドマークの位置についてのパラメータとして、そのランドマークが変換前の道路（リンク）の一方の端から全体の何％のところにあるか、道路のどちら側にあるか、道路から何メートル離れたところにあるかを求める。そして、変換後の対応する道路データに対して、これら３つのパラメータを用いて、変換後のランドマークの位置を決定する。これを、図１０に示す具体例を用いて説明する。

図１０（ａ）は、ディフォルメ処理する前の通常の地図におけるランドマーク位置の例を示す。地点Ａと地点Ｂとをつなぐ道路は、地点ＡとＡ_１の間のリンク５１、地点Ａ_１とＡ_２の間のリンク５２、地点Ａ_２とＡ_３の間のリンク５３、および地点Ａ_３とＢの間のリンク５４によって構成されており、その道路沿いにランドマーク６１が存在している。リンク５１〜５４のそれぞれの長さは、１５０ｍ、２００ｍ、３５０ｍおよび５００ｍであり、これらのリンクによって構成される地点ＡとＢをつなぐ道路は、その合計、すなわち１２００ｍの長さを有している。ランドマーク６１は、地点Ａ３から地点Ｂに向かって２００ｍ、すなわち地点Ａから９００ｍ地点の、道路の左側に位置している。また、ランドマーク６１の位置は道路から１０ｍ離れている。

このような変換前のランドマーク位置について、上記に説明した３つのパラメータを求める。１つ目のパラメータ、すなわち、道路の一方の端（地点Ａ）からの距離の全体距離に対する割合は、９００／１２００＝０．７５（７５％）と求められる。２つ目のパラメータ、すなわち道路のどちら側にあるかは、地点ＡからＢに向かって道路の左側にあると求められる。３つ目のパラメータ、すなわち道路からの距離は、１０ｍと求められる。

図１０（ｂ）は、ディフォルメ処理が実行された後の徒歩用地図におけるランドマーク位置の例を示す。この徒歩用地図では、地点Ａと地点Ｂとをつなぐ道路は１つのリンク５５によって表されており、その長さは１０００ｍである。この徒歩用地図上にランドマーク６１を表示するとき、先に求めた３つのパラメータを用いて、変換後の位置を決定する。すなわち、地点Ａからの距離は、１つ目のパラメータを用いて、１０００×０．７５＝７５０ｍと求められる。また、２つ目のパラメータと３つ目のパラメータにより、地点Ａから見て道路（リンク５５）の左側であり、その道路から１０ｍ離れた位置が決定される。これらの条件を満たす位置にランドマーク６１を表示することにより、ランドマーク６１の位置補正が行われる。

上記に説明したような処理を行うことにより、ランドマークの位置が補正され、道路とランドマークとの位置関係を元の通常の地図に近似させることができる。その結果、図８（ａ）に示す元の地図のランドマーク位置に対して、ディフォルメ処理後の地図におけるランドマーク位置を図８（ｃ）のようにすることができる。こうしてディフォルメ処理された地図上にランドマーク位置を表して、徒歩用地図が作成される。

−車載機と携帯端末間の移行時の操作方法−
ここでは、車載機１と携帯端末２の間でナビゲーションサービスを移行するときの操作方法について説明する。はじめに、車載機１から携帯端末２への移行について述べる。前述したように、自動車を降車する際にユーザは車載機１に対して、移動用地図の作成とサーバ４への通知を実行するように要求する。このときの車載機１の操作は、図１１に示すような表示画面を用いて行われる。自動車の目的地である駐車場４２に到着したときにユーザが画面上の降車ボタン６０を選択すると、前述したような処理が車載機１において行われ、その後のナビゲーションサービスが車載機１から携帯端末２へと移行する。

車載機１は、予め設定された自動車の目的地である駐車場４２から所定距離内に自動車が近づいたときに、降車ボタン６０を画面に表示する。さらにこのときユーザに対して、音声や画面表示により降車時には降車ボタン６０を選択するように促すことが好ましい。なお、前述したように降車ボタン６０を押すのは自動車のエンジンを止める前でも止めた後でもよいが、自動車のエンジンが止められた時点でまだ降車ボタン６０が押されていない場合には、その確認をユーザに求めるようにすることが好ましい。

次に、携帯端末２から車載機１への移行について述べる。移動手段が徒歩や公共交通機関から自動車に切り替わる場合、携帯端末２から車載機１へナビゲーションサービスが移行される。このときユーザは携帯端末２を操作することにより、サーバ４に対して携帯端末２から車載機１へ移行することを通知する。たとえば、駅から駐車場までの徒歩移動時に図１２に示すような徒歩用地図が表示されていたとすると、その徒歩用地図と共に画面上に表示されている乗車ボタン６１をユーザが自動車への乗車時に選択することにより、携帯端末２から車載機１への移行がサーバ４へ通知される。

携帯端末２は、旅行開始時にサーバ４から送信された前述の旅行情報により、現在の移動手段の次に利用する移動手段が何であるかを判断し、次の移動手段が自動車である場合には、乗車ボタン６１を画面上に表示する。乗車ボタン６１がユーザに選択されると、携帯端末２からサーバ４に対して自動車に乗車する旨を通知する。なお、乗車ボタン６１が押される前に携帯端末２が車載機１に接続された場合は、自動車に乗車して車載機１へ移行することをサーバ４に通知するか否かをユーザに選択させる。あるいは自動的にサーバ４へ通知するようにしてもよい。

−残り時間の案内方法−
次に、携帯端末２において残り時間の案内を行う方法について説明する。前述したように、携帯端末２は鉄道列車の発着時刻などと合わせて、現在時刻からその発着時刻までの残り時間の案内を行う。しかし、携帯端末２に設定されている時刻は必ずしも正確ではなく、携帯端末２の現在時刻を用いて残り時間を計算すると、その結果に誤差が生じる場合がある。そのため、正確な時刻情報として、車載機１において受信されるＧＰＳ信号に含まれているＧＰＳ時間を利用して、残り時間に誤差が生じないようにしている。

具体的には、携帯端末２が車載機１と接続されると、携帯端末２はユーザの操作に関わらず車載機１からＧＰＳ時間を取得する処理を実行し、その時点において、自身に予め設定されている時刻に基づく現在時刻（第１の現在時刻）と、ＧＰＳ時間による現在時刻（第２の現在時刻）との差分を算出して、その内容を記憶する。その後は、記憶された差分をその時点における自身に予め設定されている時刻に基づく現在時刻（第３の現在時刻）から差し引くことで、正確な現在時刻（第４の現在時刻）を求める。

たとえば、携帯端末２に設定されている時刻に基づく現在時刻が１３：００であり、車載機１から取得したＧＰＳ時間による現在時刻が１２：５０であったとする。この場合の両者の差分は１０分と算出される。列車の発車時刻が１３：１５であれば、この時点において携帯端末２は図１３（ａ）に示すような鉄道案内画面を表示する。現在時刻表示６２には携帯端末２に設定されている現在時刻を表示する。案内表示６３は次に乗車する列車の案内表示であり、ここには、現在時刻表示６２における現在時刻１３：００より上記の差分１０分を差し引いて計算された現在時刻１２：５０から、発車時刻の１３：１５までの残り時間２５分を表示する。

図１３（ａ）の状態から２５分経過後の鉄道案内画面を図１３（ｂ）に示す。この場合、現在時刻表示６２には、その時点の携帯端末２に設定されている時刻に基づく現在時刻、すなわち１３：２５が表示される。この現在時刻１３：２５から前述の差分１０分を差し引いた現在時刻は１３：１５であり、列車の発車時刻と同じである。そのため、案内表示６２には発車時刻であることが表示される。なお、以上説明した図１３（ａ），（ｂ）は携帯端末２に表示される画面の一例であって、表示画面がこの内容に限定されるものではないことは言うまでもない。

−サーバのフローチャート−
サーバ４において実行される処理のフローチャートを図１４に示す。ここで、サーバ４には予めパソコン３によって旅行計画が登録されているものとする。したがって、図１４では旅行計画を登録する処理を省略している。ステップＳ１００では、携帯端末２から案内開始要求の発信があったか否かを判定する。発信があった場合はステップＳ１０１へ進み、ない場合はステップＳ１００を繰り返す。なお、携帯端末２からの案内開始要求の発信は、後で説明する図１６のステップＳ３０１が実行されることにより行われる。

ステップＳ１０１では、ステップＳ１００で発信を検出した携帯端末２に対応する旅行計画が登録済みであるか否かを判定する。この判定は、前述したように携帯端末２の電話番号によりユーザＩＤを判別することにより行う。登録済みである場合はステップＳ１０２へ進み、登録されていない場合は図１４の処理を終了する。ステップＳ１０３では、現在の移動手段が何であるかを判別する。自動車である場合はステップＳ１０４へ進み、鉄道である場合はステップＳ１０７へ、徒歩である場合はステップＳ１１２へ進む。

以下の処理は、移動手段が自動車である場合に行われる。ステップＳ１０４では、車載機１から携帯端末２を介して自動車降車通知が行われたか否かを判定する。自動車降車通知が行われた場合はステップＳ１１３へ進み、最終目的地へ到達したか否かを判定する。最終目的地へ到達した場合は図１４の処理フローを終了し、最終目的地でない場合はステップＳ１０３へ戻る。一方、ステップＳ１０４において自動車降車通知が行われていなかった場合はステップＳ１０５へ進み、自動車目的地を変更するか否かを判定する。前述したような理由によって自動車の目的地を変更する必要がある場合はステップＳ１０６へ進んで、変更後の自動車目的地の情報を車載機１に送信した後、ステップＳ１０４へ戻る。ステップＳ１０５において自動車の目的地を変更しない場合は、ステップＳ１０６を実行せずにそのままステップＳ１０４へ戻る。

以下の処理は、移動手段が鉄道である場合に行われる。ステップＳ１０７では、携帯端末２から鉄道降車通知が行われたか否かを判定する。鉄道降車通知が行われた場合はステップＳ１１３へ進み、上記の移動手段が自動車である場合と同様にしてステップＳ１１３の処理を実行する。ステップＳ１０７において鉄道降車通知が行われていない場合はステップＳ１０８へ進み、乗車する列車を変更するか否かを判定する。前述したような理由によって乗車する列車を変更する必要がある場合はステップＳ１０９へ進んで、変更後の乗車列車の情報を携帯端末２に送信した後、ステップＳ１１０へ進む。ステップＳ１０８において乗車する列車を変更しない場合は、ステップＳ１０９を実行せずにステップＳ１１０へ進む。

ステップＳ１１０では、乗換え列車を変更するか否かを判定する。前述したように乗車時の予定とは違う鉄道経路を通る必要が生じた場合は、ステップＳ１１１へ進んで変更後の乗換え列車の情報を携帯端末２に送信した後、ステップＳ１０７へ戻る。一方、ステップＳ１１０において乗換え列車を変更しない場合は、ステップＳ１１１を実行せずにステップＳ１０７へ戻る。

以下の処理は、移動手段が徒歩である場合に行われる。ステップＳ１１２では、携帯端末２からの通知が行われたか否かを判定する。ここでいう携帯端末２からの通知とは、移動手段が徒歩から自動車または鉄道に変わったことを表す通知、すなわち自動車または鉄道への乗車通知と、最終目的地への到達通知のいずれかである。携帯端末２からの通知があった場合はステップＳ１１３へ進み、その通知が最終目的地への到達通知であるか否かを、前述した自動車や鉄道の場合と同様にしてステップＳ１１３において判定する。一方、ステップＳ１１２において携帯端末２からの通知がなかった場合は、ステップＳ１１２の処理を繰り返す。

サーバ４では、以上説明した処理を実行することにより、これまでに説明したようなナビゲーションサービスを車載機１または携帯端末２を介してユーザに提供する。

−車載機のフローチャート−
車載機１において実行される処理のフローチャートを図１５に示す。ここでは、車載機１と携帯端末２が予め接続されているものとする。ステップＳ２００では、携帯端末２より送信される目的地情報を受信する。この目的地情報は、前述したように図１４のステップＳ１０２においてサーバ４から送信される旅行情報に含まれているものであって、後で説明する図１６のステップ３０３において、その旅行情報を受信した携帯端末２から送信される。ステップＳ２０１では、ステップＳ２００で受信した目的地情報の中から自動車の目的地の情報を抽出し、これによって自動車の目的地を設定して経路探索を実行する。ステップＳ２０２では、ステップＳ２０１で探索された経路に従って自動車の経路誘導を行う。

ステップＳ２０３では、自動車の現在地がステップＳ２０１で設定した自動車の目的地から所定距離以内であるか否かを判定する。所定距離内である場合はステップＳ２０４へ進み、所定距離よりも離れている場合はステップＳ２０２へ戻る。ステップＳ２０４では、画面上に前述した図１１の降車ボタン６０を表示する。ステップＳ２０５では、ステップＳ２０４で表示した降車ボタン６０がユーザに押されたか否かを判定する。押された場合はステップＳ２０６へ進み、押されていなかった場合はステップＳ２０２へ戻る。

ステップＳ２０６では、ステップＳ２００で受信した目的地情報により、自動車の目的地から最終目的地までの間に徒歩の経路があるか否かを判定する。徒歩の経路がある場合はステップＳ２０７へ進み、ない場合は、この後に説明するステップＳ２０７，２０８を実行せずにステップＳ２０９へ進む。ステップＳ２０７では、徒歩経路について徒歩用地図を前述したような方法により作成し、次のステップＳ２０８では、作成した徒歩用地図を携帯端末２へ送信する。ステップＳ２０９では、携帯端末２を介して、自動車降車通知をサーバ４へ送信する。ステップＳ２０９を実行した後には、図１５の処理フローを終了する。

車載機１では、以上説明した処理を実行することにより、自動車目的地までの案内、および徒歩用地図の作成を行う。

−携帯端末のフローチャート−
携帯端末２において実行される処理のフローチャートを図１６に示す。ここでは、図１５を説明したときと同様に、車載機１と携帯端末２が予め接続されているものとする。ステップＳ３００では、ユーザから案内開始要求の操作が行われたか否かを判定する。操作が行われた場合はステップＳ３０１へ進む。操作がない場合は、ユーザからの操作があるまでステップＳ３００を繰り返し実行する。ステップＳ３０１では、サーバ４に対して案内開始要求を発信する。この案内開始要求は、前述したように図１４のステップＳ１００においてサーバ４により検出され、それに応答して旅行情報がサーバ４から送信されてくる。ステップＳ３０２では、この旅行情報を受信する。

ステップＳ３０３では、ステップＳ３０２で受信した旅行情報により、目的地情報を前述したように車載機１へ送信する。送信した目的地情報は、前述のように図１５のステップＳ２００において車載機１により受信される。ステップＳ３０４では、車載機１において図１５のステップＳ２０７が実行されることにより徒歩用地図が送信されたか否かを判定する。送信された場合はステップＳ３０５へ進んで、その徒歩用地図の画像データを記憶した後、ステップＳ３０６へ進む。ステップＳ３０４において徒歩用地図が車載機１から送信されていない場合は、ステップＳ３０５を実行せずにステップＳ３０６へ進む。

ステップＳ３０６では、まだ携帯端末２が車載機１に接続されているか否かを判定する。接続されている場合は、後で説明するステップＳ３１４へ進むことにより最終目的地に到着したか否かを判定し、最終目的地でない場合は、ステップＳ３１４からこのステップＳ３０６に戻ってくる。一方、ステップＳ３０６において車載機１との接続が既に外されている場合にはステップＳ３０７へ進み、ステップＳ３０７において、徒歩用地図と公共交通情報（ここでは鉄道案内情報）のどちらを表示するか判定する。前述したように、ユーザの操作に応じて切り替える場合にはその操作状態により、また自動的に切り替える場合にはその切替条件に該当するか否かを判断することにより、ステップＳ３０７における判定を行う。徒歩用地図を表示する場合にはステップＳ３０８へ進み、ステップＳ３０８において徒歩用地図を表示した後にステップＳ３１０へ進む。一方、公共用交通情報を表示する場合にはステップＳ３０９へ進み、ステップＳ３０９において公共用交通情報を表示した後にステップＳ３１０へ進む。なお、ステップＳ３０５を実行していない場合には、ステップＳ３０８は実行されない。

ステップＳ３１０では、次の経路における移動手段が自動車であるか否かを判定する。自動車である場合はステップＳ３１１において、図１２の乗車ボタン６１を表示した後にステップＳ３１２へ進む。一方、自動車でない場合はステップＳ３１１を実行せずにステップＳ３１２へ進む。ステップＳ３１２では、ユーザの操作によってサーバ４への通知が選択されたか否かを判定する。この通知は、移動手段が徒歩から自動車または鉄道に変わったことを表す通知、すなわち自動車または鉄道への乗車通知と、最終目的地への到達通知のいずれかである。これらの通知のいずれかが選択された場合はステップＳ３１３へ進んで、サーバ４への通知を行った後にステップＳ３１４へ進み、選択されなかった場合はステップＳ３０６へ戻る。ステップＳ３１４では、ステップＳ３１３において行ったサーバ４への通知が最終目的地への到達通知であったか否かを判定する。最終目的地への到達通知であった場合は、図１６の処理フローを終了する。しかし最終目的地への到達通知でなかった場合は、ステップＳ３０６へ戻る。

携帯端末２では、以上説明した処理を実行することにより、鉄道等の公共交通機関および徒歩による移動中におけるユーザの案内を行う。

以上説明した実施の形態によれば、次の作用効果を奏する。
（１）車載機１において、地図データ記録部１０７に記憶している地図データに基づいて、その地図データが表す通常の道路地図を所定の範囲内について要約することにより、経路４７および４９の徒歩用地図を作成して携帯端末２に送信する。携帯端末２において、車載機１から送信された徒歩用地図を受信し、その徒歩用地図を経路４７および４９を徒歩移動するときに表示することとした。このようにしたので、徒歩移動の案内に適した徒歩用地図をユーザに提供することができ、現在地を検出するための角速度センサやＧＰＳ受信機を携帯端末に搭載する必要がない。

（２）車載機１において、道路形状の直線化処理と直交化処理とを行うことによって徒歩用地図を作成することとしたので、地図データに基づいて徒歩移動の案内に適した分かりやすい徒歩用地図を作成することができる。

（３）車載機１において、地図データに基づいて徒歩移動の経路４７または４９を探索し、その探索された経路４７または４９の全体を少なくとも含むように、それぞれの徒歩用地図を作成する範囲を設定することとした。このようにしたので、作成される徒歩用地図において、徒歩移動の経路が地図範囲外にはみ出てしまうのを防ぐことができる。

（４）携帯端末２において、車載機１からの徒歩用地図を受信したら次の移動手段が何であるかを判断し、次の移動手段が徒歩である場合には、その徒歩移動の経路を表す徒歩用地図を直ちに表示することとすれば、ユーザは自動車の降車後すぐに次の徒歩移動の経路を確認することができる。

なお、上記の実施の形態では、公共交通機関の例として鉄道を用いたときの説明内容としているが、その他の公共交通機関、たとえばバス、飛行機などを用いたときにも本発明を適用でき、さらにこれらが組み合わされた場合にも適用できる。さらに、自動車を自家用車だけでなくレンタカーなどとしてもよい。

また、上記の実施の形態では、移動手段が切り替わったことや最終目的地に到着したことを、ユーザの操作により車載機１や携帯端末２からサーバ４に通知することとしていた（図５（５）〜（８））。そしてサーバ４は、この通知に基づいて、旅行計画の変更が必要であるか否かを判断して、必要である場合は旅行計画の変更情報を車載機１や携帯端末２に送信する（図５（Ａ）〜（Ｃ））。しかし、通信費用を抑えるために、このような車載機１や携帯端末２からのサーバ４への通知を行わないこととしてもよい。

上記のようにサーバ４への通知を行わない場合、たとえば次の二つのようにして、サーバ４において旅行計画の変更が必要であるか否かを判断することができる。一つ目の方法は、ユーザが旅行計画を変更したいときに、車載機１や携帯端末２を操作して旅行計画の変更要求をサーバ４に行うようにする。この変更要求を受信することにより、サーバ４において旅行計画の変更が必要であると判断する。二つ目の方法は、そのときに登録されている旅行計画に従ってユーザが移動しているものとして、サーバ４において旅行計画を変更する必要があるか否かを判断する。

上記の実施の形態では、自動車を降車する際に車載機１において道路地図を要約することにより徒歩用地図を作成し、その徒歩用地図を車載機１より携帯端末２へ送信することとした。しかし、これらの処理をサーバ４において行うようにしてもよい。

本発明は上記実施の形態に限定されるものではなく、本発明の技術的思想の範囲内で考えられるその他の態様も本発明の範囲内に含まれる。

本発明の一実施形態によるナビゲーションシステムを示す図である。 車載機の構成を示すブロック図である。 ナビゲーションサービスの概要を示す図である。 旅行計画の例を示す図である。 旅行計画を変更したときにサーバに送信される情報を示す図である。 徒歩用地図を作成するときに利用するディフォルメ化処理（１）の説明図である。 同じくディフォルメ化処理（２）の説明図である。 ランドマークの位置補正の概要の説明図である。 ランドマークの位置補正の詳細アルゴリズムの説明図である。 ランドマークの位置補正の具体例を示す図である。 車載機の表示画面と降車ボタンの例を示す図である。 携帯端末の徒歩用地図の表示画面と乗車ボタンの例を示す図である。 携帯端末の鉄道案内画面の例を示す図である。 サーバにおいて実行される処理のフローチャートを示す図である。 車載機において実行される処理のフローチャートを示す図である。 携帯端末において実行される処理のフローチャートを示す図である。

符号の説明

１ カーナビゲーション装置（車載機）
２ 携帯端末
３ パソコン
４ サーバ
４１ 自宅
４２ 駐車場
４３ 乗車駅
４４ 降車駅
４５ 最終目的地
４６〜４９ 経路
６０ 降車ボタン
６１ 乗車ボタン
１０１ 現在地検出装置
１０２ 制御回路
１０３ ＲＯＭ
１０４ ＲＡＭ
１０５ 画像メモリ
１０６ 表示モニタ
１０７ 地図データ記録部

Claims (5)

1. 車載ナビゲーション装置と、前記車載ナビゲーション装置と通信する携帯端末と、旅行計画を記憶し、前記携帯端末と通信する基地局サーバとを用いて、自動車と徒歩を少なくとも含む複数の移動手段による最終目的地までの総経路を案内するナビゲーションシステムにおいて、
   前記基地局サーバは、前記旅行計画に基づいて、前記総経路を構成する各経路の移動手段および目的地を表す目的地情報と公共交通機関情報とを含む旅行情報を前記携帯端末に送信し、
   前記携帯端末は、送信された前記旅行情報に基づいて前記目的地情報を前記車載ナビゲーション装置に送信し、
   前記車載ナビゲーション装置は、前記目的地情報と道路地図を表示するための地図データとを記憶しており、前記目的地情報に基づいて以降の移動手段が何であるかを判断し、以降の移動手段が徒歩を含む場合には、前記地図データに基づいて前記道路地図を所定の範囲内について要約することにより、徒歩用地図を作成して前記携帯端末に送信し、
   前記携帯端末は、前記送信された徒歩用地図を受信し、徒歩移動時にその徒歩用地図を表示することを特徴とするナビゲーションシステム。
2. 請求項１のナビゲーションシステムにおいて、
   前記車載ナビゲーション装置は、道路形状の直線化処理と直交化処理とを行うことによって、前記徒歩用地図を作成することを特徴とするナビゲーションシステム。
3. 請求項１または２のナビゲーションシステムにおいて、
   前記車載ナビゲーション装置は、前記地図データに基づいて徒歩移動の出発地から目的地までの経路を探索し、その探索された経路の全体を少なくとも含むように前記所定の範囲を設定することを特徴とするナビゲーションシステム。
4. 請求項１〜３のいずれかのナビゲーションシステムにおいて、
   前記携帯端末は、前記徒歩用地図を受信したら、前記旅行情報に基づいて次の移動手段が何であるかを判断し、次の移動手段が徒歩である場合には、その徒歩移動の経路を表す徒歩用地図を直ちに表示することを特徴とするナビゲーションシステム。
   
5. 請求項１〜４のいずれかのナビゲーションシステムにおいて用いられる車載ナビゲーション装置。

Images