JP3649391B2 - 端末装置 - Google Patents

端末装置 Download PDF

Info

Publication number
JP3649391B2
JP3649391B2 JP2001187360A JP2001187360A JP3649391B2 JP 3649391 B2 JP3649391 B2 JP 3649391B2 JP 2001187360 A JP2001187360 A JP 2001187360A JP 2001187360 A JP2001187360 A JP 2001187360A JP 3649391 B2 JP3649391 B2 JP 3649391B2
Authority
JP
Japan
Prior art keywords
unit
map
data
node
adjacent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2001187360A
Other languages
English (en)
Other versions
JP2002099207A (ja
Inventor
信之 中野
康博 井原
芳樹 上山
祥弘 鈴木
久哉 福田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Priority to JP2001187360A priority Critical patent/JP3649391B2/ja
Publication of JP2002099207A publication Critical patent/JP2002099207A/ja
Application granted granted Critical
Publication of JP3649391B2 publication Critical patent/JP3649391B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Instructional Devices (AREA)
  • Navigation (AREA)
  • Processing Or Creating Images (AREA)
  • Traffic Control Systems (AREA)

Description

【０００１】
【発明が属する技術分野】
本発明は、端末装置に関し、より特定的には、地図を複数の領域に分割して得られる各ユニットがデジタルデータ化された地図ファイルが内部の記憶装置に格納されており、当該記憶装置から地図ファイルを読み出す端末装置に関する。
【０００２】
【従来の技術】
「第１の従来技術」
近年、ナビゲーションシステムが搭載された車両が増加してきている。ナビゲーションシステムでは、当初は、画面上に地図を作成するファイル（以下、地図ファイルと称す）だけが提供されていた。しかし、近年は、地図ファイルに加えて、例えば交通情報および経路案内情報も提供されるようになった。かかる情報の多様化により、ナビゲーションシステムは、より便利になり、今後も急速に普及すると期待されている。
【０００３】
当初、ナビゲーションシステムには、ＣＤ−ＲＯＭに代表される読み出し専用の記録媒体を有する記憶装置が搭載されていた。この記録媒体には、ユーザに提供されるべき地図ファイルと、その関連データとが予め記録されている。記憶装置は、記憶媒体に記録された地図ファイルを、必要に応じて読み出す。読み出された地図ファイルは、ユーザにより参照されたり、経路探索処理またはマップマッチング処理に利用されたりしていた。
【０００４】
一般的にディジタル地図ファイルは、互いに縮尺の異なる地図の階層構造を効率よく管理するために、当該各地図を経度方向および緯度方向に等間隔に分割した矩形領域毎に作成される。以下、「第１の従来技術」において、かかる矩形領域を以降ではユニットと呼ぶ。
【０００５】
かかる地図ファイルは、典型的には、カーナビゲーションシステムにおいて、経路探索処理または現在位置の補正処理（マップマッチング）に用いられる。そのために、地図ファイルには、道路ネットワークデータが記録される。道路ネットワークデータは、少なくとも、各ノードおよび各リンクの接続関係を示す接続情報とから構成される。ここで、ノードとは、主として、道路網に存在する交差点を表す情報であり、リンクとは、主として、２つの交差点間に存在する道路を表すベクトル情報である。かかるノードおよびリンクの集合によって、それぞれのユニット内の道路ネットワークを表す地図が表現される。
【０００６】
上記のノード、リンクおよびそれらの接続情報で最小限の道路網を表現することができるが、これだけでは地図を表示する用途には不十分である。例えば、山岳部や臨海部の道路では交差点間の道路が屈曲している場合が多い。そこで、道路ネットワークデータは、屈曲した道路の形状を表示するためにリンク形状を特定するための情報をさらに含む。以上から明らかなように、リンクはベクトルデータで表現されることが多い。
また、道路には、国道および県道というように様々な種類がある。他にも、車線数の相違または中央分離帯の有無等により道路を分類することができる。かかる道路の種類を区別するために、道路ネットワークデータは、道路の種別等を示す属性情報をさらに含んでいる。
また、交差点には、交差点名称が付けられているものや、付けられていないものがある。さらには、信号機が設置されている交差点、信号機が設置されていない交差点がある。そこで、道路ネットワークデータはさらに、ノード毎に属性情報を有している。各属性情報には、対応する交差点の名称および信号機の有無等の情報が記録される。
【０００７】
また、ベクトルデータ構造を有する地図ファイルでは、複数のユニットに跨るような道路が存在する場合には、ユニットの境界に特別なノード（以降、隣接ノードと称す）が別途作成される。かかる隣接ノードを経由することによって、互いに隣接するユニットとの間で道路の接続関係を辿ることができるようになる。従来の地図ファイルでは、あるユニットの隣接ノードが、隣接するユニットのどの隣接ノードと対応するかを特定するために、オフセットアドレスおよびレコード番号が記録されていた。ここで、オフセットアドレスとは、基準アドレスからみて、隣接ノードがどのアドレス位置に記録されているかを示す。また、レコード番号とは、隣接ユニットの地図ファイルにおいて、先頭のノードから起算して隣接ノードが何番目の位置に記録されているかを示す。
【０００８】
「第２の従来技術」
「第１の従来技術」で説明したように、従来のナビゲーションシステムは、当初、読み出し専用の記録媒体に記録された地図ファイルしか利用できなかったので、リアルタイム性の高い情報を提供することが困難であった。かかるリアルタイム性の高い情報としては、交通情報または気象情報が代表的である。そのため、リアルタイム性が要求される情報、さらには地図ファイルを提供できる地図提供システムが、例えば、「特開平７−２６２４９３号」公報に開示されている。この公報の地図提供システムでは、地図ファイルおよびリアルタイム性の高い情報が、情報提供センターから車載用の端末装置へと通信メディアを介してダウンロードされる。
【０００９】
また、地図提供システムは、情報をリアルタイムに提供するために、移動体通信技術とデジタル放送技術とに基づいて構築される。このような地図提供システムでは、センタ局は、サービスエリア内に存在する移動体に対し、所定の放送用チャンネルを用いて情報を配信する。センタ局としては、通信衛星（いわゆるＣＳ）、放送衛星（いわゆるＢＳ）、または地上波のディジタル放送局が典型的である。この移動体通信技術とデジタル放送技術が利用された地図提供システムは、例えば、「特開平７−１５４３５０号」公報に開示されている。より具体的には、この公報には、ある情報の放送地域を限定するための技術的内容が開示されている。つまり、センタ局は、多重された情報を、放送メディアを介して送信する際に、各情報に郵便番号のような地域コードを付ける。端末装置は、自身の現在位置に対応する地域コードをＩＤとして予めメモリに登録しておく。端末装置の内部では、データ抽出回路が、放送局から放送される多重情報を分離して、各情報に付加された地域コードを取り出す。さらに、端末装置の内部では、取り出された地域コードと、登録されたＩＤとが比較される。両者が一致する場合に、端末装置は、対象となった地域コードが付された情報をユーザに参照させる。
【００１０】
以上のように、通信または放送により地図を提供するような地図提供システムの開発が近年盛んである。この地図提供システムにおいて、センタ局は、端末装置に送信すべき地図ファイルをユニット単位で読み出して、当該端末装置に送信する。端末装置は、センタ局からの地図データを受信した後に、記憶装置に格納する。格納された地図ファイルは、必要に応じて、ユーザが参照するため、経路探索処理のため、またはマップマッチング処理のために用いられる。
【００１１】
【発明が解決しようとする課題】
「第１の従来技術の課題」
「第１の従来技術」から明らかなように、従来では、あるユニットの地図ファイルには、隣接ユニットの地図ファイル内部のデータ構造を直接指示する情報（上述のオフセットアドレスまたはレコード番号）が記録されていた。
例えば、あるユニット内の道路が新しく造成された場合には、当然、当該ユニットの地図ファイルは更新される。更新された地図ファイルでは、隣接ノードが記録される位置が変わる場合が多い。そのため、従来のような地図ファイル内部のデータ構造を直接指示する方法と採用していれば、隣接ユニットの地図ファイルに記録された隣接ノードから、更新された地図ファイルにおいて対応する隣接ノードを正確にたどれなくなる。つまり、ある１つの地図ファイルが更新されると、隣接ユニットの地図ファイルも更新しなければならない場合が多くなるという問題点があった。
【００１２】
また、上述のディジタル地図ファイルの品質を評価する尺度として、地図の詳細度がある。しかしながら、地図ファイルは、リンクがベクトルデータで表現されることから、詳細な地図を表現しようとすればするほど、当該地図ファイルのデータ量が大きくなるという問題点があった。
従来、かかる地図ファイルは、主として、カーナビゲーションシステムにて使用される。カーナビゲーションシステムでは、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭまたはハードディスク等の大容量の記憶媒体に、地図ファイルが記録される。しかし、今後、地図ファイルは、カーナビゲーションシステムだけでなく、人が携帯できるような情報機器においても使用されることが考えられる。かかる携帯型情報機器に、カーナビゲーションシステムのような大容量の記憶媒体を搭載することは難しい。かかる点から、地図ファイルのデータ量を圧縮する必要性は高い。
【００１３】
「第２の従来技術の課題」
ところで、「第２の従来技術」の欄で示した各公報は、端末装置が地図ファイルを記憶装置にどのようにして格納するかについて何ら開示していない。容易に想到できるのは、端末装置が、受信したユニット毎の地図ファイルを作成して、作成した地図ファイルを記憶装置に格納するという方法である。しかしながら、この方法では、記憶領域の利用効率が悪くなるという問題点があった。今、例えば、ある範囲を表す地図βが、図７１のように、６４個の矩形のユニットに区画化されると仮定する。さらに、端末装置が、４個のユニット７１から７４を受信し格納すると仮定する。また、周知のように、記憶装置の記憶領域は、クラスタ単位で管理される。また、各ユニットのデータサイズは、クラスタのサイズの整数倍に一致するとは限らない。そのため、端末装置が、受信した４個のユニット７１〜７４について、４個のファイル８１〜８４を作成すると、図７２に示すように、空き領域を有する４個のクラスタ９１〜９４が発生する場合が多い。図７２において、ドットが付された部分は、各ファイル８１〜８４が記録された領域を示す。また、斜線が付された部分は、空き領域を示す。各クラスタ９１〜９４に生じた空き領域は使用されない。つまり、たとえ、端末装置が、各ユニット７１〜７４以外のユニット７５（図７１参照）を受信したとしても、このユニット７５を基に作成されたファイルは、各クラスタ９１〜９４の空き領域に格納されることはない。以上から明らかなように、端末装置が受信するユニットが多くなればなるほど、空き領域を有するクラスタが多くなる。つまり、記憶領域の利用効率が悪くなる。
【００１４】
ところで、地図が相対的に少数のユニットに区画されれば、空き領域を有するクラスタを発生し難くすることができる。今、図７１と同じ範囲の地図βが、図７３のように、１６個の矩形のユニットに区画されると仮定する。図７３のユニット７６が表す範囲は、図７１のユニット７１〜７４を併せた範囲に相当する。さらに、端末装置が１個のユニット７６を受信し格納すると仮定する。この仮定下では、端末装置は、受信した１個のユニット７６について、１個のファイル８６を作成すると、図７４に示すように、空き領域を有するクラスタ９６が１個しか発生しない。図７４のドット部分は、ファイル８６が記録された領域を示す。また、斜線部分は、空き領域を示す。
【００１５】
以上から明らかなように、地図が小さいユニットに区画された場合（図７１参照）、ある範囲を表す地図ファイルが記憶装置に格納されると、相対的に多く空き領域が発生する（図７２参照）。しかしながら、地図が大きなユニットに区画された場合には（図７３参照）、同じ範囲の地図データが記憶装置に格納されても、発生する空き領域は少ない（図７４参照）。つまり、記憶領域の有効利用の観点からは、地図は少数のユニットに区画された方がよい。
【００１６】
しかしながら、地図を少数のユニットに区画するということは、１ユニット当たりのデータ量が大きくなることを意味する。そのため、基地局は、１度に、大量のデータを端末装置に送信しなければならない。その結果、無線伝送路は輻輳状態に陥り易くなる、つまり無線伝送路の利用効率が悪くなる、という別の問題点が生じる。つまり、記憶領域を重視すれば、無線伝送路の効率的な利用が難しく、無線伝送路を重視すれば、記憶領域の効率的な利用が難しくなるという問題点があった。
【００１７】
それゆえに、本発明の第１の目的は、ある１つが更新された場合に、隣接ユニットの地図ファイルを更新する必要がない地図ファイルのデータ構造を提供することである。また、本発明の第２の目的は、そのデータ量を圧縮可能な地図ファイルのデータ構造を提供することである。また、本発明の第３の目的は、端末装置内の記憶領域を効率的に利用し、しかもセンタ局と端末装置との間の伝送路を効率的に利用できる地図提供システムを提供することである。
【００１８】
【課題を解決するための手段および発明の効果】
本発明の一局面は、地図を複数の領域に分割して得られる各ユニットがデジタルデータ化された地図ファイルが記憶装置に格納されており、当該記憶装置から地図ファイルを読み出すための端末装置であって、各地図ファイルは、それぞれのユニット内に含まれる道路網をノードとリンクとで表すべく、当該ノード毎に作成されるノードレコードと、当該リンク毎に作成されるリンクレコードとを含んでいる。各ノードレコードには、道路網上の交差点を表す非隣接ノードに関連する情報、または、ユニットとそれに隣接するユニットとの道路の接続関係を規定するための隣接ノードの座標情報が記録されている。各地図ファイルにおいて、隣接ノードの座標情報を含む各ノードレコード及び非隣接ノードに関連する情報を含む各ノードレコードの内、隣接ノードの座標情報を含むものは連続的に記録されている。ここで、端末装置は、ユーザの操作に応答して、地図の範囲を指定する情報を生成する入力装置と、入力装置により生成された情報に基づいて、必要な地図ファイルの記録領域を特定するデータ処理部と、データ処理部により特定された記録領域に基づいて、記憶装置から、地図ファイルを読み出す読み出し制御部とを備える。また、データ処理部は、読み出し制御部により読み出された地図ファイルに記録された、隣接ノードの座標情報及び非隣接ノードに関連する情報を含む各ノードレコードと、リンクレコードとを用いて、出発地及び目的地の間の最適経路を探索するための経路探索処理を実行し、経路探索処理を実行中に、一方のユニットを表す地図ファイルの隣接ノードに到達した時、隣接ユニットを表す地図ファイルにおいて、隣接ノードの座標情報を含む各ノードレコードのみを検索して、一方のユニットの隣接ノードの座標値に実質的に一致する座標値を有する隣接ユニットの隣接ノードを探し出し、これによって、当該一方のユニット内の道路から、当該隣接ユニット内の道路への接続をたどる。
【００１９】
上記発明では、データ処理部は、経路探索処理を実行している最中に、ユニットおよび隣接ユニットの隣接ノードの座標情報を基に、当該ユニットおよび当該隣接ユニットの間をまたぐような道路の接続をたどる。このように、データ処理部は、各地図ファイル内部のデータ構造を直接指示する情報を参照することなく、データ処理部は、２つのユニットの間の道路の接続をたどることができる。これによって、記憶装置内のあるユニットの地図ファイルを更新する時、隣接ユニットの地図ファイルを更新する必要がなくなる。
【００２０】
【発明の実施の形態】
「第１の実施形態」
「システム構成」
図１は、本発明の一実施形態に係る地図提供システムの構成を示すブロック図である。図１において、本地図提供システムには、端末装置１とセンタ局２とが収容される。端末装置１とセンタ局２とは通信網３を通じて双方向通信可能に接続される。より具体的には、端末装置１とセンタ局２との間には、アップリンクＵＬとダウンリンクＤＬとが張られる。アップリンクＵＬとは、端末装置１からセンタ局２への通信路を意味し、ダウンリンクＤＬとは、センタ局２から端末装置１への通信路を意味する。ここで、通信網３の典型例としては、携帯電話に代表される移動体通信網、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）に代表される公衆回線、または専用回線がある。また、通信網３は、移動体通信網、公衆回線および専用回線の内のいずれか２つ以上により構成される場合もある。
【００２１】
次に、端末装置１の構成について説明する。端末装置１は、典型的には、カーナビゲーションシステムにより相当し、入力装置１１と、位置検出装置１２と、データ処理部１３と、要求生成部１４と、第１の送受信部１５と、アンテナ１６と、パケット分解部１７と、読み出し／書き込み制御部１８と、第１の記憶装置１９と、出力装置１１０とを備える。
入力装置１１は、カーナビゲーションシステムを遠隔から操作するリモートコントローラまたはカーナビゲーションシステム本体に配列されたキーによりハードウェア的に実現されたり、カーナビゲーションシステムのメニュー画面に表示されたボタンによりソフトウェア的に実現されたりする。さらには、入力装置１１は、音声認識技術を駆使して実現される場合もある。端末装置１のユーザは、以上の入力装置１１を操作して、端末装置１に対して、表示された地図のスクロールまたは縮尺変更、経路探索、情報検索、もしくはセンタ局２への接続等、様々な処理の要求を行う。さらに、入力装置１１は、特徴的な動作として、ユーザが必要とする地図ファイルＣＦを特定するための情報をデータ処理部１３に出力する。
【００２２】
位置検出装置１２は、速度センサ、ジャイロセンサ、またはＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）のアンテナおよび受信機により実現される。また、速度センサ、ジャイロセンサ、ならびにＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）のアンテナおよび受信機のいずれか２つ以上の組み合わせにより、位置検出装置１２は実現される場合もある。位置検出装置１２は、速度センサにより端末装置１の移動速度を検出して、検出結果を基に走行距離を算出したり、ジャイロセンサにより端末装置１の進行方向を検出したり、アンテナおよび受信機により人工衛星からの電波を受信して、地球上における端末装置１の絶対的な位置を検出したりする。以上の検出結果を基に、位置検出装置１２は端末装置１の現在位置を検出する。
データ処理部１３は、後述する各種のデータ処理を行う。データ処理部１３の処理の一つに、入力装置１１から入力された情報を基に、ユーザが必要とする地図の範囲を特定する座標を求めて、要求生成部１４に出力するという処理がある。
要求生成部１４は、座標情報が入力されると、ユーザが必要とする地図ファイルＣＦの送信をセンタ局２に要求するための制御コマンドを生成する。以降、生成された制御コマンドを要求ＲＥＱと称することとする。要求ＲＥＱは、予め定められたフォーマットを有しており、要求生成部１４に入力された座標情報を少なくとも含む。以上のような要求ＲＥＱは、第１の送受信部１５に出力される。第１の送受信部１５は、典型的には、携帯電話に代表される移動体通信装置により実現される。第１の送受信部１５は、入力された要求ＲＥＱを、アンテナ１６を通じてアップリンクＵＬに送出する。
【００２３】
要求ＲＥＱは、アップリンクＵＬを通じて、センタ局２により受信される。センタ局２は、要求ＲＥＱを解析して、ユーザが必要とする地図ファイルＣＦを特定する。センタ局２は、特定した地図ファイルＣＦを第２の記憶装置２４から取り出して、複数のパケットＰを組み立てる（アセンブリする）。組み立てられたパケットＰは、通信網３（ダウンリンクＤＬ）を通じて、順次端末装置１に送信される。なお、センタ局２の処理は後で詳しく説明される。端末装置１において、第１の送受信部１５はさらに、アンテナ１６を通じてパケットＰを受信して、パケット分解部１７に出力する。パケット分解部１７は、入力されたパケットＰを、元の地図ファイルＣＦに分解（デアセンブリ）して、データ処理部１３に出力する。
データ処理部１３は、地図ファイルＣＦが入力されると、予め定められた処理を実行して、所定の条件を満たす場合、入力された地図ファイルＣＦを基に第１のデータベース１１１を作成して読み出し／書き込み制御部１８に出力する。読み出し／書き込み制御部１８は、入力された地図ファイルＣＦを第１の記憶装置１９にそのまま書き込んだり、既存の地図ファイルＣＦと書き換えたりする。
なお、一連の書き込み処理については後で説明する。
第１の記憶装置１９は、典型的には、ハードディスクドライブまたはフラッシュメモリに代表される、データの書き換えが可能な記憶装置からなる。第１の記憶装置１９には、第１のデータベース１１１が蓄積される。第１のデータベース１１１は、本端末装置１がナビゲーションシステムとして機能するために必要な少なくとも１つの地図ファイルＣＦから構成されるデータの集合体である。
また、出力装置１１０は、典型的には、ディスプレイおよびスピーカからなる。ディスプレイには、地図ファイルＣＦにより表される地図が現在位置とともに表示されたり、データ処理部１３による経路探索処理の結果または経路案内処理の結果が表示されたりする。スピーカは、データ処理部１３による経路案内処理の結果が音声によりユーザに提供する。
【００２４】
ところで、データ処理部１３は、第１のデータベース１１１を構成する地図ファイルＣＦを使って様々な処理を行う。例えば、データ処理部１３は、端末装置１の現在位置の表示処理を実行する。この場合、データ処理部１３は、位置検出装置１２により検出された現在位置周辺の地図が必要となるので、読み出し／書き込み制御部１８と協働して、第１のデータベース１１１から、当該地図を表す地図ファイルＣＦを検索して取り出す。データ処理部１３は、取り出された地図ファイルＣＦを使って、マップマッチング等の位置補正処理を行う。位置補正処理後、データ処理部１３は、取り出した地図ファイルＣＦが表す地図上に、検出された現在位置を視覚的に示すポインタを重ね合わせて、出力装置１１０に出力する。
また、データ処理部１３は、端末装置１のユーザが入力装置１１を用いて経路探索処理等を要求した場合には、出発地および目的地付近の地図を表す地図ファイルＣＦ、ならびに探索すべき経路を含む地図を表す地図ファイルＣＦを読み出して経路探索処理等を行う必要がある。この場合にも、データ処理部１３は、読み出し／書き込み制御部１８と協働して、第１のデータベース１１１から、経路探索処理等に必要となる地図ファイルＣＦを検索して取り出す。なお、一連の地図ファイルＣＦの読み出し処理については後で説明する。
【００２５】
次に、センタ局２の構成について説明する。センタ局２は、第２の送受信部２１と、受信要求解析部２２と、読み出し制御部２３と、第２の記憶装置２４と、パケット組み立て部２５とを備える。
上述したように、センタ局２には、端末装置１により生成された要求ＲＥＱが通信網３（アップリンクＵＬ）を通じて送信されてくる。第２の送受信部２１は、典型的には、モデム、ターミナルアダプタ、またはゲートウェイに代表される通信装置からなる。ここで、ゲートウェイとは、異なる通信プロトコルが使用される通信網３にセンタ局２を接続するための装置または機能を意味するだけでなく、他の局が当該センタ局２に不正アクセスすることを防止するための装置または機能を意味する。第２の送受信部２１は、通信網３と接続されており、端末装置１からのデータ受信および端末装置１へのデータ送信を制御する。より具体的には、第２の送受信部２１は、その一つの機能として、アップリンクＵＬを通じて送信されてきた要求ＲＥＱを受信して受信要求解析部２２に出力する。
【００２６】
受信要求解析部２２は、入力された要求ＲＥＱを解析して、解析結果を読み出し制御部２３に出力する。読み出し制御部２３は、入力された解析結果を基に、端末装置１が必要とする地図ファイルＣＦを第２の記憶装置２４から読み出す。ここで、第２の記憶装置２４は、典型的には、ハードディスクドライブ、ＣＤ−ＲＯＭドライブまたはＤＶＤ−ＲＯＭドライブで構成されており、少なくとも蓄積されたデータの読み出しが可能な記録媒体とそのドライバとからなる。第２の記憶装置２４は、第２のデータベース２５を格納する。第２のデータベース２５は、センタ局２が本端末装置１に地図を提供する局として機能するために必要な少なくとも１つの地図ファイルＣＦから構成されるデータの集合体である。つまり、地図ファイルＣＦは、端末装置１に提供可能な地図を表現したデジタルデータを意味する。端末装置１側の第１のデータベース１１１は、センタ局２により提供される地図ファイルＣＦから作成される。ここで、読み出し制御部２３が読み出すのは、地図ファイルＣＦのすべてである場合もあれば、当該地図ファイルＣＦの一部である場合もある。読み出し制御部２３は、読み出した地図ファイルＣＦを、パケット組み立て部２５に出力する。パケット組み立て部２５は、入力された地図ファイルＣＦを基にパケットＰを組み立てて（アセンブリして）、第２の送受信部２１に出力する。第２の送受信部２１は、ダウンリンクＤＬを通じて、入力されたパケットＰを端末装置１に送信する。
【００２７】
以上、本実施形態に係る地図提供システムの全体構成、ならびに端末装置１およびセンタ局２の構成について説明した。次に、上述の地図ファイルＣＦの階層構造およびファイル名について詳細に説明する。
【００２８】
「階層構造およびファイル名」
図２は、本実施形態に係る地図ファイルＣＦにより表現される地図の階層構造を説明するための図である。図２に示すように、まず、互いに縮尺の異なる複数種類の地図が準備される。本実施形態では、便宜上、４段階の縮尺の地図が準備されると仮定する。以降の説明では、最大縮尺をレベル「０」、２番目に大きな縮尺をレベル「１」、３番目に大きな縮尺をレベル「２」、最小縮尺をレベル「３」と称する。以上から分かるように、地図データは、最大縮尺をレベル「０」として、レベル「０」〜「３」の４階層から構成される。さらに、レベルが高いものを上位階層の地図と称し、レベルが低いものを下位階層の地図と称する。したがって、図２に示すように、上位階層の地図ほど、広域でかつ詳細度が低い。逆に、下位階層の地図ほど、狭域でかつ詳細度が高い。また、各階層の地図は、経度方向および緯度方向に沿って等間隔に区切られる。
【００２９】
ここで、図３は、最上位階層（レベル「３」）のユニットを説明するための図である。図３の世界地図は、緯度０度を基準として、当該緯度方向に沿って５度２０分毎に区切られる。さらに、この世界地図は、経度０度を基準として、当該経度方向に沿って約８度毎に区切られる。その結果、世界地図は、約６４０ｋｍ四方の矩形領域に分割される。最上位階層（レベル「３」）においては、約６４０ｋｍ四方の矩形領域をユニットと称する。レベル「３」においては、かかる約６４０ｋｍ四方のユニットがデジタルデータ化されることにより、１つの地図ファイルＣＦが作成される。以上のような、最上位階層（レベル「３」）のユニットを代表して、ユニットＵ3 （ハッチングを付した部分）について説明する。最上位階層（レベル「３」）のユニットＵ3 は、日本の関西圏を含むユニットであり、緯度０度、経度０度の位置を原点として、東経方向に数えて１６番目、北緯方向に数えて６番目に位置する（ただし、原点を含むユニットは０番目と数える）。以上のユニットＵ3 が、図２の最上段に示されている。
【００３０】
図２に示すように、ユニットＵ3 の地図は、一つの頂点を基準として、点線で示すように、緯度方向に沿って４０分毎に区切られる。さらに、ユニットＵ3 の地図は、上記と同じ頂点を基準として、点線で示すように、当該経度方向に沿って１度毎に区切られる。その結果、ユニットＵ3 の地図は、約８０ｋｍ四方の矩形領域に６４分割される。約８０ｋｍ四方の各矩形領域を詳細に表した地図が、１階層下（つまり、レベル「２」の階層）における１つのユニットとなる。レベル「２」の階層のユニットを代表して、ユニットＵ2 （ハッチングを付した部分）について説明する。かかるユニットＵ2 は、ユニットＵ3 内の１つの頂点（便宜上、左下の頂点とする）の位置を原点として、東経方向に数えて４番目、北緯方向に数えて１番目に位置する（ただし、原点を含むユニットＵは０番目と数える）。レベル「２」の階層のユニットＵ2 が、図２の２段目に示されている。
【００３１】
同様に、ユニットＵ2 の地図は、一つの頂点を基準として、緯度方向に沿って５分毎に、さらに経度方向に沿って７分３０秒毎に区切られ、その結果、約１０ｋｍ四方の矩形領域に６４分割される。約１０ｋｍ四方の各矩形領域を詳細に表した地図が、１階層下（つまり、レベル「１」の階層）における１つのユニットとなる。その内の一つであるユニットＵ1 （ハッチングを付した部分）は、ユニットＵ2 の左下の頂点を原点として、東経方向に数えて５番目、北緯方向に数えて３番目に位置する（ただし、原点を含むユニットは０番目と数える）。レベル「１」のユニットＵ1 が、図２の上から３段目に示されている。
【００３２】
同様に、ユニットＵ1 の地図は、約１．２ｋｍ毎四方の矩形領域に６４分割される。約１．２ｋｍ四方を詳細に表した各地図が、１階層下（つまり、レベル「０」の階層）における１つのユニットＵとなる。その内の一つであるユニットＵ0 （ハッチングを付した部分）は、ユニットＵ1 の左下の頂点を原点として、東経方向に２番目、北緯方向に１番目に位置する（ただし、原点を含むユニットは０番目と数える）。レベル「０」のユニットＵ0 が、図２の上から４段目に示されている。
【００３３】
図４は、レベル「３」〜「０」のそれぞれの階層間におけるユニットＵの親子関係を説明するための図である。まず、以下の説明において、子ユニットＣＵとは、ある１つのユニットＵがカバーする範囲に包含される、下位階層の全てのユニットを意味する。言い換えれば、子ユニットＣＵとは、上位階層のある１つのユニットＵが表す地図の一部分を表すユニットＵの集合である。逆に、親ユニットＰＵとは、あるユニットＵのカバーする範囲を包含する、上位階層の全てのユニットを意味する。言い換えれば、親ユニットＰＵとは、下位階層のある１つのユニットＵが表す地図を、自身が表す地図の一部として含んでいるユニットＵの集合である。
ここで、図４中のユニットＵ3 は、図２に示すユニットＵ3 に相当しており、レベル「３」のユニットの一つである。ユニットＵ3 を親ユニットＰＵ3 とするレベル「２」のユニットＵ、すなわちユニットＵ3 の子ユニットＣＵの内、レベル「２」に属するものは、ユニットＵ3 を経度および緯度方向にそれぞれ８等分してできる６４個のユニットＵとなる。
【００３４】
このように、親ユニットＰＵに対しては、１階層下に６４個の子ユニットＣＵができる。各子ユニットＣＵには位置コードが割り当てられる。位置コードとは、子ユニットＣＵが表す地図が、親ユニットＰＵのどの部分に相当するかを特定するための情報である。言い換えれば、位置コードとは、親ユニットＰＵを基準とした子ユニットＣＵの位置を特定するための情報である。
今、親ユニットＰＵが図４ユニットＵ3 であるとする。かかる場合、ユニットＵ3 の左下隅の地図を詳細に表す子ユニットＣＵには、位置コードとして「００００」が割り当てられる。この位置コード「００００」を基準値として、子ユニットＣＵ（位置コード「００００」）に対して、東経方向に沿って隣接する子ユニットＣＵには「０１００」が割り当てられる。以下同様に、子ユニットＣＵが東経方向に１つ移るたびに、位置コードは、「０１００」だけ増加する．また、位置コード「００００」を基準値として、子ユニットＣＵ（位置コード「００００」）に対して、北緯方向に沿って隣接する子ユニットＣＵには「０００１」が割り当てられる。以下同様に、子ユニットＣＵが北緯方向に１つ移るたびに、位置コードは、「０００１」だけ増加する。
以上のように割り当てられる位置コードに従えば、ユニットＵ3 の子ユニットＣＵの一つであるユニットＵ2 の位置コードは「０４０１」である。
【００３５】
次に、親ユニットＰＵがユニットＵ2 であると仮定する。このユニットＵ2 に対しても、１階層下（レベル「１」）には６４個の子ユニットＣＵができる。レベル「１」の６４個の子ユニットＣＵに対しても、図４に示すように、上述と同様の方法で位置コードが割り当てられる。例えば、ユニットＵ2 の子ユニットＣＵの一つであるユニットＵ1 の位置コードは「０５０３」である。
また、親ユニットＰＵとしてのユニットＵ1 に対しても、１階層下（レベル「０」）には、６４個の子ユニットＣＵができる。レベル「０」の各子ユニットＣＵに対しても、図４に示すように、同様に位置コードが割り当てられる。例えば、ユニットＵ1 の子ユニットＣＵの一つであるユニットＵ0 の位置コードは「０２０１」である。
【００３６】
以上のように、本実施形態に係る位置コードでは、東経方向への値の増分および北緯方向への値の増分が予め定められている。そのため、子ユニットＣＵ同士の隣接関係を簡単に把握することができる。
【００３７】
ところで、図１に示す端末装置１およびセンタ局２にはそれぞれ、ファイルシステムが搭載される。端末装置１側のファイルシステムは、データ処理部１３および読み出し／書き込み制御部１８により構成される。端末装置１側のファイルシステムは、第１の記憶装置１９内の第１のデータベース１１１を容易に管理すべく、第１の記憶装置１９が有する記録領域を「ディレクトリ」と呼ばれるいくつかの論理領域に分割する。さらに、端末装置１側のファイルシステムは、第１のデータベース１１１を構成する地図ファイルＣＦの親子関係および隣接関係を、ツリー構造に基づくディレクトリ名およびファイル名により表す。
また、センタ局２側のファイルシステムは、受信要求解析部２２および読み出し制御部２３により構成される。センタ局２側のファイルシステムは、第２の記憶装置２４内の第２のデータベース２５の記憶領域を「ディレクトリ」（論理領域）に分割し、さらに、第２のデータベース２５を構成する地図ファイルＣＦの親子関係および隣接関係を、ツリー構造に基づくディレクトリ名およびファイル名により表す。
【００３８】
以下、図５は、図２〜図４に示す地図ファイルＣＦを管理するためのツリー構造を示す図である。上述したように、各ファイルシステムの各ディレクトリは、図５に示すようなツリー構造をとり、「￥」マークにより表される。「￥」マークは、ディレクトリを識別するための識別子である。また、最上部のディレクトリは、ルートと呼ばれ、「￥ＭＡＰ」で表される。ルートディレクトリ「￥ＭＡＰ」の下のディレクトリには、地図ファイルＣＦそのものまたはサブディレクトリを格納することができる。ここで、ファイルシステムは、必要な地図ファイルＣＦを指定する際、ファイル名の前にルート「￥ＭＡＰ」から当該地図ファイルＣＦが存在するディレクトリまでに介在するディレクトリ名を「パス」として記述する必要がある。したがって、２つの「￥」マークで挟まれた文字列がディレクトリ名を表すこととなる。サブディレクトリ名の頭文字は「Ｄ」と定義される。また、ファイル名の頭文字は「Ｍ」と定義される。さらに、ファイル名の拡張子は「．ｍａｐ」と定義される。
【００３９】
さて、次に、本実施形態の一つの特徴である、ディレクトリ名およびファイル名を割り当て方法を説明する。まず、原則として、最上位階層の各ユニットがカバーする地図を表す地図ファイルＣＦは、所定の規則に従ってファイル名が付けられ、ルート（「￥ｍａｐ」）の直下のディレクトリ（論理領域）に格納される。例えば、図３に示すユニットＵ3 は、最上位の階層（レベル「３」）に属しており、原点（緯度０度、経度０度）を基準として、東経方向に数えて１６番目、北緯方向に６番目（ただし、原点を含むユニットはそれぞれ０番目と数える）のユニットに該当する。そのため、ユニットＵ3 には、ファイル名の頭文字および拡張子を含めて「Ｍ１６０６．ｍａｐ」という名前が付けられる。さらに、最上位階層のユニットＵ3 は、ルート（「￥ｍａｐ」）の直下に格納されるので、パスは、「￥ＭＡＰ￥Ｍ１６０６．ｍａｐ」となる。
以上のユニットＵ3 のファイル名から分かるように、ファイル名の頭文字および拡張子の間には、４桁の数字が並ぶ。上位２桁の数字は、ユニットＵが原点から東経方向に数えて何番目に位置するかを規定する。また、下位２桁の数字は、ユニットＵが原点から北緯方向に数えて何番目に位置するかを規定する。このように、ファイル名は、ユニットＵの位置を規定する。また、ユニットＵ3 のパスから分かるように、ルート（「￥ｍａｐ」）からファイル名に至るまでにはサブディレクトリが介在しない。このように、サブディレクトリの個数は、ユニットＵがどの階層に属しているかを規定する。ユニットＵ3 の場合には、ルートとファイル名との間に介在するサブディレクトリの個数が「０」であることにより、ユニットＵ3 （Ｍ１６０６．ｍａｐ）が最上位階層に属することが分かる。
以上の規則に従うと、他の最上位階層のユニットＵのためのパスは、「￥ＭＡＰ￥Ｍ００００．ｍａｐ」，「￥ＭＡＰ￥Ｍ０００１．ｍａｐ」，…「￥ＭＡＰ￥Ｍ１６０６．ｍａｐ」…等のように表される。
【００４０】
また、最上位階層のユニットＵを親ユニットＰＵとするユニットのグループを格納するためのサブディレクトリがルートの直下に作成される。例えば、ユニットＵ3 を親ユニットＰＵとするユニットＵのグループを格納するために、「￥Ｄ１６０６」と名付けられたサブディレクトリがルートの直下に作成される。以上のサブディレクトリ名から分かるように、サブディレクトリ名の頭文字には４桁の数字が続く。この４桁の数字は、ファイル名の場合と同様に、親ユニットＰＵが原点から東経方向および北緯方向に数えてそれぞれ何番目に位置するかを表す。そのため、ルート（「￥ＭＡＰ」）の直下には、「￥Ｄ００００」、「￥Ｄ０００１」，…，「￥Ｄ１６０６」，…が作成される。
【００４１】
次に、レベル「２」の階層に属する各ユニットＵは、位置コードに基づくファイル名が付けられ、自身の親ユニットＰＵを表すサブディレクトリの直下のディレクトリ（論理領域）に格納される。例えば、ユニットＵ3 を親ユニットＰＵとするレベル「２」のユニットＵは、図４等を参照すると６４個ある。その内の一つであるユニットＵ2 は、位置コードが「０４０１」であるため、ファイル名の頭文字および拡張子を含めて「Ｍ０４０１．ｍａｐ」という名前が付けられる。さらに、レベル「２」のユニットＵ2 は、ユニットＵ3 （親ユニットＰＵ）のサブディレクトリ（「￥ｍａｐ￥Ｄ１６０６」）の直下に格納されるので、パスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａｐ」となる。
以上のユニットＵ2 のファイル名から分かるように、レベル「２」のユニットＵのファイル名の頭文字および拡張子の間には、上述した位置コードが並ぶ。そのため、レベル「２」のユニットＵのファイル名もまた、当該ユニットＵの位置を規定することとなる。また、ユニットＵ2 のパスから分かるように、ルート（「￥ｍａｐ」）からファイル名に至るまでにはサブディレクトリが１つだけ介在する。サブディレクトリの個数は、ユニットＵがどの階層に属しているかを規定する。ユニットＵ2 の場合には、ルートとファイル名との間に介在するサブディレクトリの個数が「１」であることにより、当該ユニットＵ2 （Ｍ０４０１．ｍａｐ）がレベル「２」の階層に属することが分かる。
以上の規則に従うと、他のレベル「２」のパスは、「￥ＭＡＰ￥Ｄ００００￥Ｍ００００．ｍａｐ」，「￥ＭＡＰ￥Ｄ００００￥Ｍ０００１．ｍａｐ」，…，「￥ＭＡＰ￥Ｄ００００￥Ｍ０００７．ｍａｐ」，「￥ＭＡＰ￥Ｄ００００￥Ｍ０１００．ｍａｐ」，…「￥ＭＡＰ￥Ｄ００００￥Ｍ０７０７．ｍａｐ」，「￥ＭＡＰ￥Ｄ０００１￥Ｍ００００．ｍａｐ」，…「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０００１．ｍａｐ」，…，「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａｐ」，…「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０７０７．ｍａｐ」，…等のように表される。
【００４２】
同様に、レベル「２」のユニットＵ2 を親ユニットＰＵとするユニットのグループは、サブディレクトリ「￥Ｄ０４０１」の下のディレクトリ（論理領域）の下に格納されることになる。例えば、ユニットＵ1 は、ユニットＵ2 の子ユニットＣＵの一つであって、当該ユニットＵ2 が６４分割されたユニットＵの内、位置コード「０５０３」に該当するユニットである。そのため、ユニットＵ1 のためのパスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０５０３．ｍａｐ」と表される。同様に、ユニットＵ2 を親ユニットＰＵとするレベル「１」の各ユニットのパスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ００００．ｍａｐ」、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０００１．ｍａｐ」，…，「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０７０７．ｍａｐ」で表される。
【００４３】
さらに、ユニットＵ1 を親ユニットＰＵとするユニットＵのグループは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３」と表されるサブディレクトリの直下のディレクトリ（論理領域）に格納される。かかるグループに属するユニットＵ0 は、ユニットＵ1 が６４分割されたユニットＵの内、位置コード「０２０１」に該当するユニットである。そのため、ユニットＵ0 のパスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０２０１．ｍａｐ」と表される。同様に、ユニットＵ1 を親ユニットＰＵとするレベル「０」の各ユニットのパスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ００００．ｍａｐ」，「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０００１．ｍａｐ」，…「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０７０７．ｍａｐ」で表される。
【００４４】
以上、地図ファイルＣＦにより実現される階層構造およびファイル名について説明した。ここで、以上のユニットＵがデジタルデータ化され、必要な管理情報が付加されることにより、１つの地図ファイルＣＦが構成される（詳細は図７を参照）。以下の説明において、ユニットデータは、ユニットＵをデジタルデータ化したものを意味する。つまり、１つの地図ファイルＣＦには、１つのユニットデータが含まれる。次に、地図ファイルＣＦのデータ構造について詳細に説明する。
【００４５】
「地図ファイルＣＦのデータ構造」
図６は、１つの地図ファイルＣＦを基に描かれる地図を説明するための図である。また、図７は、１つの地図ファイルＣＦのデータ構造を示している。図７において、地図ファイルＣＦは、大略的に、ユニットヘッダとユニットデータとから構成される。まず、ユニットデータから説明する。一般的に、地図は、用途に応じて、図７に示すように、背景、道路、地図記号および文字から構成される。しかし、地図ファイルＣＦは、主として、端末装置１のディスプレイ上への表示、マップマッチングまたは経路探索処理に使用される。例えば、経路探索処理では、道路のつながりが分かればよく、背景の必要性は薄い。そこで、１つのユニットデータは、図６に示すように、文字記号データと、道路ネットワークデータと、背景データとに分けてデータ化される。これによって、文字記号データ、道路ネットワークデータおよび背景データはそれぞれ、独立的に使用することができる。文字記号データとは、ユニットＵがカバーする地図に記載されるべき文字列（地名および交差点名称等）からなるデータと、当該地図に記載されるべき地図記号からなるデータとを意味する。道路ネットワークデータとは、ユニットＵがカバーする地図に表されるべき道路そのものおよび道路同士のつながりを表す図形データを意味する。背景データとは、水系、山系、建造物等、ユニットＵがカバーする地図に表されるべき背景を表す図形データを意味する。背景の例としては、河川、湖、山、緑地帯、鉄道、建造物、橋、公園がある。以上の文字記号データ、道路ネットワークデータおよび背景データを重ねあわせて表示することにより、図６に示すように、ユニットデータは、背景、道路、地図記号および文字を表すことができる。
【００４６】
次に、背景データの詳細なデータ構造を、図７および図８を参照して説明する。図７に示すように、背景データは、基本背景テーブルおよび詳細背景テーブルから構成される。基本背景テーブルは、図８（ａ）から明らかなように、河川、鉄道および緑地帯等、地図の背景を表示する際に概略となる図形データを集合である。一方、詳細背景テーブルは、図８（ｂ）から明らかなように、橋および建造物等、地図の背景をより詳細に表示するための図形データの集合である。これら基本背景テーブルおよび詳細背景テーブルは、図７から明らかなように、ユニットデータにおいて互いに別々に記録される。さらに、基本背景テーブルおよび詳細背景テーブルには、相互に参照し合うような情報は記録されない。つまり、基本背景テーブルを構成する背景データを描いている際に、詳細背景テーブルの背景データは何一つ参照されない。逆に、詳細背景テーブルを構成する背景データを描いている際に、基本背景テーブルの背景データは何一つ参照されない。このように、基本背景テーブルおよび詳細背景テーブルは、相互に独立したデータ構造を有する。したがって、背景をディスプレイ上に表示する場合には、図８（ａ）に示すように、基本背景テーブルのみで表される背景を表示することが可能になる。これによって、端末装置１のユーザは、概略的な地図を見ることが可能になる。また、図８（ｃ）に示すように、基本背景テーブルおよび詳細背景テーブルで表される背景を表示することもできる。この場合、所定の原点を基準として、基本背景テーブルから得られる概略的な背景の上に、詳細背景テーブルから得られる詳細な背景を重ねあわせることとなる。これによって、端末装置１のユーザは、詳細な地図を見ることが可能となる。なお、本実施形態では、背景データは基本背景テーブルおよび詳細背景テーブルとから構成されるとして説明したが、第１の記憶装置１９または第２の記憶装置２４に記憶容量の制限がある場合等には、第１のデータベース１１１または第２のデータベース２５を小さいサイズにする観点から、背景データは基本背景テーブルのみから構成されてもよい。逆に、本実施形態で説明したように、背景データは基本背景テーブルおよび詳細背景テーブルとから構成される場合には、センタ局２は、詳細な地図を端末装置１に提供することが可能となり、当該端末装置１は詳細な地図をディスプレイに表示できるようになる。
【００４７】
上述の基本背景テーブルおよび詳細背景テーブルの内部のデータ構造は互いに同じである。以下には、基本背景テーブルおよび詳細背景テーブルを背景テーブルと総称して、双方のデータ構造についてより詳細に説明する。
上述したように、背景テーブルは、地図の背景をディスプレイ上に描画するために使用される図形データの集合である。各図形データによって、河川、公園、工場および鉄道等がディスプレイ上に描画される。以下、これら地図の背景の要素となる、河川、公園、工場および鉄道等を総称して「描画オブジェクト」と呼ぶこととする。ここで、図９は、描画オブジェクトの概念を示す図である。上述から明らかなように、描画オブジェクトは、公園または工場等のように、それ自体で意味のあるひとまとまりの対象物を表し、データ構造としては、対象物を折れ線で描画するための要素点の並びから構成される。例えば、図９には、矩形領域のユニットＵが示されている。ユニットＵがカバーする範囲には、２つの描画オブジェクトＤＯ１およびＤＯ２が存在する。描画オブジェクトＤＯ１は、オブジェクトＯＢＪ１とＯ２とから構成される。オブジェクトＯＢＪ１は、要素点ａ→要素点ｂ→要素点ｃ→要素点ｄ→要素点ｅ→要素点ａの順番に一筆書きした時に作成される折れ線で囲まれる領域である。また、オブジェクトＯＢＪ２は、要素点ｆ→要素点ｇ→要素点ｈ→要素点ｉ→要素点ｆの順番に一筆書きした時に描かれる折れ線で囲まれる領域である。また、描画オブジェクトＤＯ２は、オブジェクトＯＢＪ３から構成される。オブジェクトＯＢＪ３は、要素点ｊ→要素点ｋ→要素点ｌ→要素点ｍ→要素点ｎ→要素点ｊの順番に一筆書きした時に描かれる折れ線で囲まれる領域である。以上から明らかなように、本実施形態の描画オブジェクトは、複数の要素点を一筆書きして得ることができる１つ以上のオブジェクトにより表される。
【００４８】
ここで、図１０は、背景テーブル、つまり基本背景テーブルまたは詳細背景テーブルの詳細なデータ構造を示す図である。図１０において、背景テーブルには、背景レコード数Ｍと、Ｍ個の背景レコードＢＲ１〜ＢＲＭとから構成される。ここで、Ｍは、１以上の自然数である。背景レコード数Ｍは、背景テーブルに含まれる背景レコードＢＲ１〜ＢＲＭの個数を示す情報である。また、背景レコードＢＲ１は、背景属性と、オブジェクト数Ｎと、オブジェクトＯＢＪ１〜ＯＮの要素点数Ｎ１〜ＮＮと、オブジェクトレコードＯＲ１〜ＯＲＮとから構成される。
背景属性は、背景レコードＢＲ１内に含まれる各オブジェクトＯＢＪにより表される背景の属性を示す情報である。より具体的には、背景属性は、背景レコードＢＲ１内に含まれる各オブジェクトＯＢＪのカラーコードおよびテクスチャーマッピングコードである。ここで、本実施形態の一つの特徴として、背景属性には、１つのカラーコードまたはテクスチャマッピングコードのみが記述される。つまり、例えば、「青」を示すカラーコードと、「赤」を示すカラーコードとが一緒に背景属性に記述されることはない。「青」を示すカラーコードのみ、または「赤」を示すカラーコードのみが背景属性に記述される。
【００４９】
また、オブジェクト数Ｎは、背景レコードＢＲ１内に含まれるオブジェクトＯＢＪの数を示す情報である。また、要素点数Ｎ１は、オブジェクトＯＢＪ１を構成する要素点の数を示している。要素点数Ｎ２は、オブジェクトＯＢＪ２を構成する要素点の数を示している。以降、同様に、要素点数ＮＮは、オブジェクトＯＢＪＮの要素点の数を示す。このように、背景レコードＢＲ１には、そこに含まれるＮ個のオブジェクトＯを構成する要素点の数が並ぶ。ここで、Ｎは１以上の自然数である。
【００５０】
さらに、オブジェクトレコードＯＲ１は、１つのオブジェクトＯＢＪ１を構成する要素点の座標を示す情報である。ここで注意を要するのは、オブジェクトＯＢＪ１は複数の要素点を含むので、オブジェクトレコードＯＲ１には複数の座標情報が並ぶこととなる。つまり、オブジェクトレコードＯＲ１には座標列の情報が記述される。ここで、上述から明らかなように、オブジェクトレコードＯＲ１には、要素点数Ｎ１に相当する個数の座標情報が記述される。また、オブジェクトレコードＯＲ２は、オブジェクトＯＢＪ２を構成する要素点の座標列を示す情報である。オブジェクトレコードＯＲ２には、要素点数Ｎ２に相当する個数の座標情報が記述される。以降、同様に、オブジェクトレコードＯＲＮは、オブジェクトＯＢＪＮを構成するＮＮ個の要素点の座標列を示す情報である。オブジェクトレコードＯＲＮには、要素点数ＮＮに相当する個数の座標情報が記述される。
【００５１】
以上のように、各オブジェクトレコードＯＲには、オブジェクトＯＢＪを構成する要素点の座標列が記述される。座標列の表現方法としては、ユニットＵ内での絶対座標で表現する方法と、ある要素点の座標と直前の要素点の座標との差分を用いた相対座標で表現する方法とがある。絶対座標は、ユニットＵ内の所定の原点を基準とした各要素点の座標であるため、多くのビット数を必要とする。そのため、座標列の表現方法として、相対座標が使用されることが、地図ファイルＣＦのデータサイズを小型化する観点から、好ましい。以下、絶対座標と相対座標とについて、詳細に説明する。
【００５２】
図１１は絶対座標が多くのビット数を必要とすることを説明するための図である。図１１には、８個の要素点Ｐ０〜Ｐ７で構成される図形データが示されている。要素点Ｐ０の絶対座標は、予め定められた原点を基準として、（Ｘ０，Ｙ０）である。以降、同様に、要素点Ｐ１〜Ｐ７の絶対座標は、（Ｘ１，Ｙ１）〜（Ｘ７，Ｙ７）である。また、図１２は、以上のＰ０〜Ｐ７の各絶対座標情報をオブジェクトレコードＯＲに記述した時の図である。今、要素点Ｐ０〜Ｐ７の絶対座標は、東経方向（ｘ軸方向）および北緯方向（ｙ軸方向）それぞれについて、例えば２バイトで表現すると、Ｐ０〜Ｐ７の各絶対座標情報をオブジェクトレコードＯＲに記述するためには、３２バイトが必要となる。
【００５３】
一方、図１３は、図１１と同じ図形データの各要素点Ｐ０〜Ｐ７を相対座標で表現した時の図である。図１３において、図形データは、要素点Ｐ０→Ｐ１→Ｐ２→Ｐ３→Ｐ４→Ｐ５→Ｐ６→Ｐ７の順番で一筆書きされる。相対座標表現であっても、一筆書きされる最初の要素点Ｐ０は、絶対座標表現と同様に、所定の原点を基準として、（Ｘ０，Ｙ０）で表される。ただし、次の要素点Ｐ１は、絶対座標表現の場合には、（Ｘ１，Ｙ１）と表される。しかし、相対座標表現では、要素点Ｐ１は（ΔＸ１，ΔＹ１）で表される。ここで、ΔＸ１は、ΔＸ１＝Ｘ１−Ｘ０である。また、ΔＹ１は、ΔＹ１＝Ｙ１−Ｙ０である。以降の要素点Ｐ２〜Ｐ７も、それぞれの要素点の絶対座標と、直前の要素点の絶対座標との差分により表現される。
図１４は、以上の要素点Ｐ０〜Ｐ７の各相対座標情報をオブジェクトレコードＯＲに記述した時のデータ構造を示す図である。ここで注意を要するのは、相対座標表現は、それぞれの要素点の絶対座標と、直前の要素点の絶対座標との差分で表されるため、ΔＸ１≪Ｘ１，ΔＸ２≪Ｘ２，…ΔＸ７≪Ｘ７となる。同様に、ΔＹ１≪Ｙ１，ΔＹ２≪Ｙ２，…ΔＹ７≪Ｙ７となる。そのため、要素点Ｐ１〜Ｐ７の相対座標は、東経方向（ｘ軸方向）および北緯方向（ｙ軸方向）それぞれについて２バイトで表現するのではなく、それぞれ１バイトで表現する。その結果、要素点Ｐ１〜Ｐ７の各相対座標情報をオブジェクトレコードＯＲに記述するためには、１４バイトが必要となる。ただし、最初の要素点Ｐ０は、絶対座標で記述される必要があるので、要素点Ｐ０〜Ｐ７の各座標情報をオブジェクトレコードＯＲに記述するためには、差分数（「７」）の情報を含めて、１９バイトが必要となる。
【００５４】
以上、図１１〜図１４を参照して説明したように、オブジェクトＯＢＪを構成する各要素点Ｐを相対座標を使って表現すると、絶対座標表現のみを用いた場合と比較して、オブジェクトレコードＯＲのサイズが小さくなる。しかしながら、オブジェクトＯＢＪを構成する各要素点を無条件に相対座標で表現すると、データサイズの小型化を実現できない場合が生じるという問題点が想定できる。かかる問題点を、図１５を参照して説明する。図１５には、要素点Ｐ０、Ｐ１およびＰｎで構成されるオブジェクトＯＢＪが示されている。今、要素点Ｐ１は、相対座標では（ΔＸ１，ΔＹ１）で表される。ΔＸ１およびΔＹ１の双方は、１バイトで表現できるとする。同様に、要素点Ｐｎは、相対座標では（ΔＸｎ，ΔＹｎ）で表される。しかしながら、ΔＸｎおよび／またはΔＹｎは、要素点Ｐｎが直前の要素点Ｐ１から離れた位置にあるため、１バイトでは表現しきれない値であると仮定する。このような場合、図１６に示すように、要素点Ｐ１およびＰｎを結ぶ直線上に、新しい要素点Ｐ２およびＰ３を作成する必要が生じる。これによって、要素点Ｐｎの相対座標は、直前の要素点Ｐ３の絶対座標を基に、（ΔＸ４，ΔＹ４）で表すことができる。ΔＸ４およびΔＹ４は、要素点Ｐ３が要素点Ｐ１と比べて要素点Ｐｎの近くに位置するため、１バイトで表現できる。以上の要素点Ｐ０，Ｐ１，Ｐ２，Ｐ３およびＰｎの各相対座標情報をオブジェクトレコードＯＲに記述すると、図１７に示すように、１３バイト必要となる。
【００５５】
以上、図１５〜図１７を参照して説明したように、２個の要素点Ｐが離れて位置している場合には、新しい要素点Ｐを補う必要が生じる。その結果、オブジェクトレコードＯＲには、補った要素点Ｐの相対座標情報を記述しなければならない。このように、最初の要素点Ｐを除くすべての要素点Ｐを相対座標で表現しようとすると、要素点Ｐの数が不必要に多くなり、オブジェクトレコードＯＲのデータサイズが不必要に大きくなるという問題点が顕在化してくる。そこで、図１５の要素点Ｐ０およびＰｎを絶対座標で表現し、要素点Ｐ１を要素点Ｐ０を基準とした相対座標で表現することが有効となる。今、要素点Ｐｎの絶対座標は、４バイトで表現できる（Ｘｎ，Ｙｎ）であると仮定して、要素点Ｐ０，Ｐ１およびＰｎの各座標情報をオブジェクトレコードＯＲに記述すると、図１８に示すようになる。図１８において、要素点Ｐ０およびＰｎの絶対座標情報はそれぞれ４バイトであり、要素点Ｐ１の相対座標情報は２バイトである。さらに、絶対座標で表されたＰ０およびＰｎを基準として、いくつの相対座標が作成されているかを示す差分数の情報は２バイトである。以上の合計をとると、オブジェクトレコードＯＲのデータサイズは１２バイトとなる。このデータサイズは、相対座標だけで表現した場合のオブジェクトレコードＯＲのデータサイズ１３バイト（図１７参照）よりも小さい。
【００５６】
以上、図１８を参照して説明したように、その直前の要素点と離れて位置する要素点は絶対座標で表現される。このように、本実施形態では、ある要素点は、主として相対座標で表現されるが、他の要素点は絶対座標で表現される。これによって、オブジェクトレコードＯＲのデータサイズをより小さくすることが可能となる。
【００５７】
また、上述したように、本実施形態では、オブジェクトの境界にも、相対座標表現が適用される。ここで、オブジェクトの境界とは、あるオブジェクトＯＢＪを構成する１つの要素点Ｐからペンアップして、他のオブジェクトＯＢＪを構成する１つの要素点Ｐにペンダウンする部分を意味する。かかる相対座標表現の適用によって、本実施形態は、背景テーブルのデータサイズを小型化できるという技術的効果を奏する。以下には、まず、かかる技術的効果を明確にするために、オブジェクトの境界に相対座標表現が適用されない場合について、図１９および図２０を参照して説明する。図１９には、描画オブジェクトＤＯ３が示されている。描画オブジェクトＢＯ３は、オブジェクトＯＢＪ３およびＯＢＪ４から構成される。オブジェクトＯＢＪ３は、６個の要素点Ｐ０〜Ｐ５から構成される。また、オブジェクトＯＢＪ４は、４個の要素点Ｐ６〜Ｐ９から構成される。
【００５８】
以上のオブジェクトＯＢＪ３は、要素点Ｐ０→Ｐ１→Ｐ２→Ｐ３→Ｐ４→Ｐ５→Ｐ０という順番で一筆書きされる。その後、要素点Ｐ０でペンアップが行われ、要素点Ｐ６でペンダウンが行われる。そして、オブジェクトＯＢＪ４は、要素点Ｐ６→Ｐ７→Ｐ８→Ｐ９→Ｐ６という順番で一筆書きされる。この時、オブジェクトの境界で相対座標が適用されないと仮定すると、要素点Ｐ０〜Ｐ５および要素点Ｐ６〜Ｐ９を表す座標のデータ構造は、図２０に示すようになる。図２０において、最初に、オブジェクトＯＢＪ３の基準点となる要素点Ｐ０の絶対座標（Ｘ０，Ｙ０）が４バイトで記述される。オブジェクトＯＢＪ３の描画時には、要素点Ｐ０にペンダウンした後ペンアップするまでに、要素点Ｐ１〜Ｐ５を辿ることになるので、差分数（つまり相対座標の個数）は、５個となり、１バイトの情報である。今、要素点Ｐ１〜Ｐ５の相対座標は、前述と同様に２バイトで表され、（ΔＸ１，ΔＹ１）〜（ΔＸ５，ΔＹ５）である。また、オブジェクトの境界部分に相対座標が適用されないので、要素点Ｐ５の相対座標の後には、オブジェクトＯＢＪ４の基準点となる要素点Ｐ６の絶対座標（Ｘ１，Ｙ１）が４バイトで記述される。オブジェクトＯＢＪ４の描画時には、要素点Ｐ６にペンダウンした後ペンアップするまでに、要素点Ｐ７〜Ｐ９を辿ることになるので、差分数（相対座標の個数）は、３個となり、１バイトの情報である。要素点Ｐ７〜Ｐ９の相対座標は、（ΔＸ６，ΔＹ６）〜（ΔＸ８，ΔＹ８）であり、２バイトで表される。したがって、両オブジェクトの境界に相対座標を適用することなく、オブジェクトＯＢＪ３およびＯＢＪ４を相対座標列は、２６バイトで表現される。
【００５９】
次に、オブジェクトの境界に相対座標表現が適用される場合について、図２１および図２２を参照して説明する。図２１には、図１９と同様に、２個のオブジェクトＯＢＪ３およびＯＢＪ４から構成される描画オブジェクトＤＯ３が示されている。描画オブジェクトＤＯ３は、要素点Ｐ０→Ｐ１→Ｐ２→Ｐ３→Ｐ４→Ｐ５という順番で一筆書きされる。その後、要素点Ｐ５から要素点Ｐ６へのペンアップおよびペンダウンが行われた後、描画オブジェクトＤＯ３は、要素点Ｐ６→Ｐ７→Ｐ８→Ｐ９→Ｐ６という順番で一筆書きされる。ただし、描画時においては、一筆書きの開始点とペンアップした点とは必ず結ぶという原則があるので、要素点Ｐ５および要素点Ｐ０は線で結ばれる。以上の描画時において、オブジェクトの境界で相対座標が適用されると仮定すると、要素点Ｐ０〜Ｐ５および要素点Ｐ６〜Ｐ９を表す座標のデータ構造は、図２２に示すようになる。図２２において、最初に、オブジェクトＯＢＪ３の基準点となる要素点Ｐ０の絶対座標（Ｘ０，Ｙ０）が４バイトで記述される。描画オブジェクトＤＯ３の描画時には、要素点Ｐ０から一筆書きを開始から終了までに、要素点Ｐ１〜Ｐ９を辿ることになるので、相対座標の個数、つまり差分数は、１バイトのデータであって、「９個」を示す。今、要素点Ｐ１〜Ｐ９の相対座標は、前述と同様に２バイトで表され、（ΔＸ１，ΔＹ１）〜（ΔＸ９，ΔＹ９）である。したがって、両オブジェクトの境界に相対座標を適用する場合には、オブジェクトＯＢＪ３およびＯＢＪ４を相対座標列は、２３バイトで表現される。
【００６０】
以上、図１９〜図２２を参照して説明したように、オブジェクトの境界に相対座標を適用すると、それを適用しない場合と比較して、背景テーブルのデータサイズを小型化することができる。
【００６１】
ここで注意を要するのは、図２０においてはオブジェクトの境界は、オブジェクトレコードＯＲに記述された絶対座標により分かる。しかし、図２２においては、オブジェクトの境界は、絶対座標からは見つけることはできない。図２１に示すように、オブジェクトの境界を規定するペンアップする要素点Ｐおよびペンダウンする要素点Ｐはそれぞれ相対座標で示される場合があり、さらには、図１８に示したように２点間の距離が離れている場合には、要素点Ｐが絶対座標で表現される場合があるからである。しかしながら、図２２において、オブジェクトの境界は、図１０に示された要素点数Ｎ１〜要素点数ＮＮを参照すれば正確に規定できる。つまり、本実施形態では、要素点数Ｎ１〜要素点数ＮＮはそれぞれ、ペンダウンしてからペンアップするまでに一筆書きで辿る要素点の個数を意味する。したがって、実際の描画時において、オブジェクトレコードＯＲの先頭から座標の個数をカウントし、カウント値が要素点数Ｎ１と同じであれは、最初のオブジェクトの境界を正確に特定することができる。同様に、カウント値が要素点数Ｎ１およびＮ２の加算値と同じであれは、２回目のオブジェクトの境界を特定することができる。以降、同様に、カウント値が要素点数Ｎ１〜ＮＮの加算値と同じであれは、Ｎ回目のオブジェクトの境界を特定することができる。
【００６２】
「文字記号データの詳細なデータ構造」
次に、図７に示す文字記号データについて説明する。なお、文字記号データは本願発明の特徴的な事項ではないため、簡単に説明する。文字記号データとは、前述したように、ユニットＵがカバーする地図に記載されるべき文字列（地名、道路名称および交差点名称等）からなるデータと、当該地図に記載されるべき地図記号からなるデータとを意味する。さらに、文字記号データは、図７に示すように、基本文字記号テーブルと詳細文字記号テーブルとから構成される。基本文字記号テーブルは、ユニットＵがカバーする地図に記載される文字列または地図記号の内、基本的な文字列および地図記号を表すデータを集合である。より具体的には、基本文字記号テーブルには、図２３（ａ）から明らかなように、河川名称、道路名称および地図記号等、ユニットＵがカバーする地図を表示する際に概略となる文字列および地図記号とが記録される。一方、詳細文字記号テーブルは、ユニットＵがカバーする地図に記載される文字列または地図記号の内、基本文字記号テーブルには記録されない文字列および地図記号を表すデータを集合である。より具体的には、詳細文字記号テーブルには、図２３（ｂ）から明らかなように、公園、鉄道、橋および工場の名称等、ユニットＵがカバーする地図をより詳細に表示するための文字列および地図記号とが記録される。
【００６３】
ここで、本実施形態の端末装置１としては、上述したようにカーナビゲーションシステムが想定されている。かかる事情から、基本文字データテーブルには、カーナビゲーションに重要な河川名称、道路名称および地図記号等が記録されると説明した。しかし、他の用途の端末装置１も想定できる。そのため、基本文字記号テーブルにどのような文字列および地図記号が記録されるか、また、詳細文字記号テーブルにどのような文字列および地図記号が記録されるかについては、端末装置１の用途に依存する。それゆえに、本願発明の技術範囲は、基本文字記号データテーブルには、河川名称、道路名称および地図記号等が記録される、というように限定解釈されてはならない。
【００６４】
さて、以上の基本文字記号テーブルおよび詳細文字記号テーブルは、図７から明らかなように、ユニットデータにおいて互いに別々のフィールドに記録される。さらに、基本文字記号テーブルおよび詳細文字記号テーブルには、相互に参照し合うような情報は一切記録されない。つまり、基本文字記号テーブルを構成する文字列または地図記号を描いている際に、詳細文字記号テーブルの文字列または地図記号は何一つ参照されない。逆に、詳細文字記号テーブルを構成する文字列および地図記号を描いている際に、基本文字記号テーブルの文字列および地図記号は何一つ参照されない。このように、基本文字記号テーブルおよび詳細文字記号テーブルは、相互に独立したデータ構造を有する。したがって、文字列および地図記号をディスプレイ上に表示する場合には、図２３（ａ）に示すように、基本文字記号テーブルのみで表される文字列および地図記号を表示することが可能になる。これによって、端末装置１のユーザは、概略的な地図を見ることが可能になる。また、図２３（ｃ）に示すように、基本文字記号テーブルおよび詳細文字記号テーブルそれぞれを構成する文字列および地図記号を表示することもできる。この場合、所定の原点を基準として、基本文字記号テーブルから得られる概略的な文字列および地図記号に、詳細文字記号テーブルから得られる文字列および地図記号を重ねあわせることとなる。これによって、端末装置１のユーザは、詳細な地図を見ることが可能となる。なお、本実施形態では、文字記号データは基本文字記号テーブルおよび詳細文字記号テーブルとから構成されるとして説明したが、第１の記憶装置１９または第２の記憶装置２４に記憶容量の制限がある場合等には、第１のデータベース１１１または第２のデータベース２５を小さいサイズにする観点から、文字記号データは基本文字記号テーブルのみから構成されてもよい。逆に、本実施形態で説明したように、文字記号データは基本文字記号テーブルおよび詳細文字記号テーブルとから構成される場合には、センタ局２は、詳細な地図を端末装置１に提供することが可能となり、当該端末装置１は詳細な地図をディスプレイに表示できるようになる。
【００６５】
上述の基本文字記号テーブルおよび詳細文字記号テーブルの内部のデータ構造は互いに同じである。以下には、基本文字記号テーブルおよび詳細文字記号テーブルを文字記号テーブルと総称して、双方のデータ構造についてより詳細に説明する。
【００６６】
上述したように、文字記号テーブルは、ユニットＵがカバーする地図上の文字列および地図記号をディスプレイ上に表すためのデータの集合である。ここで、図２４は、文字記号テーブル、つまり基本文字記号テーブルまたは詳細文字記号テーブルの詳細なデータ構造を示す図である。図２４において、文字記号テーブルは、文字記号レコード数Ｐと、Ｐ個の文字記号レコードＴＳＲ１〜ＴＳＲＰとから構成される。文字記号レコード数Ｐは、文字記号テーブルに含まれる文字記号レコードＴＳＲ１〜ＴＳＲＰの個数を示す情報である。ここで、Ｐは、１以上の自然数であって、ユニットＵがカバーする地図上の文字列および地図記号の総数である。文字記号レコードＴＳＲ１〜ＴＳＲＰは、ユニットＵがカバーする地図上の文字列または地図記号の数だけ作成される。文字記号レコードＴＳＲ１は、文字記号属性と、ポイント座標と、文字記号コードとから構成される。
【００６７】
文字記号属性は、文字記号レコードＴＳＲ１により表されるべき文字列または地図記号の属性を示す情報である。文字記号属性には、文字列または当該地図記号のサイズと、文字列が並ぶ方向（縦／横）とを示す情報が記録される。ここで注意を要するのは、地図記号は、複数の記号により１つの対象物を表すことがほとんどなく、さらに、１つの文字で表される地名もある。かかる場合には、文字列が並ぶ方向（縦／横）を示す情報が文字記号属性に記録される必要性は特にない。ポイント座標は、文字記号レコードＴＳＲ１により表されるべき文字列または地図記号がユニットＵ上のどの位置に表示されるかを特定するための座標情報である。文字記号レコードＴＳＲ１により表されるべき文字列等は、ディスプレイ上において、ポイント座標により特定される位置に表示される。また、文字記号コードは、文字記号レコードＴＳＲ１により表されるべき文字列および地図記号のコード番号である。文字列のコード番号としては、日本国ではシフトＪＩＳコードが典型的であり、文字記号属性に記録された文字列の大小を表すサイズに該当する情報が記録される。ここで、地図記号は、シフトＪＩＳ等のように、それに関連する規格がないので、独自に作成される。さらに、作成された地図記号のコード番号としては、日本国ではシフトＪＩＳの空きコード番号が割り当てられる。割り当てられたコード番号が、文字記号コードとして記録される。
なお、他の文字記号レコードＴＳＲ２〜ＴＳＲＰは、文字記号レコードＴＳＲ１と同様のデータ構造を有するので、それぞれの説明を省略する。
【００６８】
「道路ネットワークデータの詳細なデータ構造」
次に、図７に示す道路ネットワークデータについて説明する。道路ネットワークデータは、カーナビゲーションシステムとしての端末装置１において、ディスプレイ上に道路を表示するために使用されるだけでなく、マップマッチング、経路探索処理または経路案内処理にも使用される。そのため、道路ネットワークデータは、前述したように、ユニットＵがカバーする地図に表されるべき道路そのものを表す図形データ、および道路同士のつながりを表すデータの集合を意味する。より具体的には、道路ネットワークデータはマップマッチング等に使用されるため、当該道路ネットワークデータには、単に、道路網の形状を表す図形データが記録されるだけではなく、ユニットＵがカバーする範囲の地図に表される道路同士の接続関係を示すデータも記録される。
【００６９】
以上の道路ネットワークデータは、図７に示すように、第１のネットワークデータと第２のネットワークデータとから構成される。第１のネットワークデータには、主要幹線道路の道路ネットワークデータが記録される。主要幹線道路とは、例えば、以下の３つの条件のいずれかを満たすものを意味する。まず、第１の条件は、地方自治体およびそれよりも上位の行政機関が造った道路（高速道路、国道）であることである。第２の条件は、地方自治体よりも下位の行政機関が造った道路（高速道路、国道）および私道であって、かつその幅員が５．５ｍ以上の道路であることである。第３の条件は、上記第１および第２の条件に該当する道路に接続された道路であることである。また、第２のネットワークデータには、細街路の道路ネットワークデータが記録される。細街路とは、その幅員が３．０ｍ以上であって、主要幹線道路に該当しない道路（例えば、住宅の周辺に造られた道路）を意味する。ただし、上記の主要幹線道路および細街路の定義は単なる一例であって、他の定義を採用しても構わない。それゆえに、本願発明の技術範囲は、第１および第２の道路ネットワークデータには、上記定義にのみ該当する道路ネットワークデータが記録される、というように限定解釈されてはならない。
【００７０】
次に、第１の道路ネットワークデータおよび第２の道路ネットワークデータの関係について、図２５を参照して説明する。第１の道路ネットワークデータは、主要幹線道路の道路ネットワークデータである。そのため、第１の道路ネットワークデータが端末装置１のディスプレイに表示されると、図２５（ａ）に示すように、主要幹線道路を表す図形が表示される。一方、第２の道路ネットワークデータは、細街路の道路ネットワークデータである。そのため、第２の道路ネットワークデータが端末装置１のディスプレイに表示されると、図２５（ｂ）に示すように、細街路を表す図形が表示される。これら第１および第２の道路ネットワークデータは、図７から明らかなように、ユニットデータにおいて互いに別々に記録される。したがって、図２５（ａ）に示すように、第１の道路ネットワークデータを構成する主要幹線道路のみを端末装置１のディスプレイに表示することが可能になる。これによって、端末装置１のユーザは、概略的な道路ネットワークを見ることが可能になる。また、図２５（ｃ）に示すように、第１および第２の道路ネットワークデータを構成する主要幹線道路および細街路を表示することもできる。この場合、所定の原点を基準として、第１の道路ネットワークデータから得られる主要幹線道路網の上に、第２の道路ネットワークデータから得られる細街路の道路網を重ねあわせることとなる。これによって、端末装置１のユーザは、詳細な道路網を見ることが可能となる。なお、本実施形態では、道路ネットワークデータは、第１および第２の道路ネットワークデータから構成されるとして説明したが、第１の記憶装置１９または第２の記憶装置２４に記憶容量の制限がある場合等には、第１のデータベース１１１または第２のデータベース２５を小さいサイズにする観点から、道路ネットワークデータは、第１の道路ネットワークデータのみから構成されてもよい。逆に、本実施形態で説明したように、道路ネットワークデータが第１および第２の道路ネットワークデータから構成される場合には、センタ局２は、詳細な道路網を端末装置１に提供することが可能となり、当該端末装置１は詳細な道路網をディスプレイに表示できるようになる。
【００７１】
上述の第１および第２の道路ネットワークデータのデータ構造は互いに同じである。以下には、第１および第２の道路ネットワークデータのデータ構造についてより詳細に説明する。
周知のように、道路ネットワークデータは、主として、ノードとリンクにより構成される。ノードとは、主として、交差点または道路の区切りを表現するためのデータを意味する。また、リンクとは、２個の交差点の間をつなぐ道路を表現するためのデータである。かかるノードとリンクを用いることにより、ユニットＵがカバーする地図上に表されるべき道路（主要幹線道路または細街路）の形状および道路同士の接続関係が端末装置１のディスプレイ上に表示される。そのため、図７に示すように、第１の道路ネットワークデータは、第１のノードテーブルおよび第１のリンクテーブルから構成され、第２の道路ネットワークデータは、第２のノードテーブルおよび第２のリンクテーブルから構成される。以下には、まず、第１および第２のノードテーブルのデータ構造をまず説明する。
【００７２】
ここで、図２６は、ノードおよびリンクの概念を説明するための図である。図２６には、１つのユニットＵがカバーする範囲に存在する道路網が示されている。図２６の道路網は、１１個のノードＮ０〜Ｎ１０と、１１個のリンクＬ０〜Ｌ１０とから構成される。１１個のノードＮ０〜Ｎ１０は、非隣接ノードと隣接ノードとに大別される。非隣接ノードとは、通常の交差点、もしくは道路の種別または属性が変わる点（上述の道路の区切りに相当する）に作成されるノードであり、ユニットＵ内での道路の接続関係を表す分岐点を意味する。ところで、図２６のユニットＵには、同じレベルに属しかつ隣接するユニットＵがいくつかある（図２参照）。したがって、１本の道路が、互いに隣り合う複数のユニットＵにまたがる場合がある。以下では、図２６のユニットＵに隣接するユニットＵのことを、便宜上、隣接ユニットＮＵと称する。図２６には、隣接ユニットＮＵの１つが点線にて示されている。隣接ノードは、図２６のユニットＵおよび隣接ユニットＮＵの間をまたがる道路が存在する場合に、当該ユニットＵの境界（つまり矩形領域の辺）上に作成されるノードであり、当該ユニットＵと隣接ユニットＮＵとの道路の接続関係を表す点を意味する。以上の定義に従うと、図２６のノードＮ１、Ｎ２、Ｎ５およびＮ８の４つ（○印参照）が非隣接ノードに分類される。また、ノードＮ０、Ｎ３、Ｎ４、Ｎ６、Ｎ７、Ｎ９、Ｎ１０の７つ（●印参照）が隣接ノードに分類される。ここで注意を要するのは、交差点または道路の区切りを表すノードＮがユニットＵの境界上に存在する場合には、当該ノードＮを隣接ノードと分類するか、非隣接ノードと分類するかが問題となる。かかる場合、交差点または道路の区切りを表すノードＮを境界上からずらして、新しい非隣接ノードを作成することが１つの対処方法である。他の対処方法として、ユニットＵの境界上の交差点または道路の区切りと同じ座標上に非隣接ノードを作成することがある。以上から明らかなように、ユニットＵの境界上には非隣接ノードが作成されてはならない。
【００７３】
図２７は、第１のノードテーブルの詳細なデータ構造を示す図である。ここで、予め断っておくが、第１および第２のノードテーブルは、互いに同様のデータ構造を有しており、主要幹線道路および細街路について作成される点で相違する。そのため、説明の簡素化の観点から、第２のノードテーブルの詳細な説明を省略する。さて、図２７において、第１のノードテーブルは、隣接ノード数Ｑと、非隣接ノード数Ｒと、（Ｑ＋Ｒ）個のノードレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）とから構成される。隣接ノード数Ｑは、第１のノードテーブルに含まれる隣接ノードの個数を示す情報である。ここで、Ｑは、１以上の自然数であって、ユニットＵにより表される地図上の道路網に隣接ノードがいくつ存在するかを示す。非隣接ノード数Ｒは、第１のノードテーブルに含まれる非隣接ノードの個数を示す情報である。ここで、Ｒは、１以上の自然数であって、ユニットＵにより表される地図上の道路網に非隣接ノードがいくつ存在するかを示す。
【００７４】
ノードレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）は、ユニットＵにより表される地図上の道路網に存在するノードＮの数だけ作成される。ノードレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）には、（Ｑ＋Ｒ）個のノードＮに関連する情報が記録される。
次に、本実施形態におけるノードレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）の並べ方について説明する。第１のノードテーブルにおいて、最初のＱ個のノードレコードＮＲ１〜ＮＲＱには、Ｑ個の隣接ノードに関連する情報が記録され、後のＲ個のノードレコードＮＲ（Ｑ＋１）〜ＮＲ（Ｑ＋Ｒ）には、Ｒ個の非隣接ノードに関連する情報が記録される。
また、Ｑ個のノードレコードＮＲ１〜ＮＲＱにおいて、先頭から順番に、矩形領域（ユニットＵ）の左辺上に存在する隣接ノード（図２６の▲１▼参照）に関連する情報が記録される。次に、矩形領域の上辺上に存在する隣接ノード（図２６の▲２▼参照）に関連する情報が記録される。次に、矩形領域の右辺上に存在する隣接ノード（図２６の▲３▼参照）に関連する情報が記録される。最後に、矩形領域の下辺上に存在する隣接ノード（図２６の▲４▼参照）に関連する情報が記録される。
また、上記上辺上または下辺上の隣接ノードのノードレコードＮＲは、当該隣接ノードの緯度が昇順になるよう並べられる。一方、上記右辺上または左辺上の隣接ノードのノードレコードＮＲは、当該隣接ノードの経度が昇順になるよう並べられる。
【００７５】
さらに、非隣接ノードのノードレコードＮＲは、最初に、当該非隣接ノードの緯度が昇順になるように並べられる。この時、同じ緯度の非隣接ノードが複数存在した場合には、ノードレコードＮＲは、当該非隣接ノードの経度が昇順になるように並べられる。
【００７６】
図２６のノードＮ０〜Ｎ１０に関して、上記の並べ方に従うと、図２８に示すように、先頭のノードレコードＮＲ１には、隣接ノードＮ６の情報が記録される。次のノードレコードＮＲ２には、隣接ノードＮ０の情報が記録される。ノードレコードＮＲ３、ＮＲ４、ＮＲ５、ＮＲ６およびＮＲ７には、隣接ノードＮ４、Ｎ７、Ｎ１０、Ｎ３およびＮ９の情報が記録される。ここで、図２８中の▲１▼〜▲４▼は、図２６の▲１▼〜▲４▼に対応しており、隣接ノードが並べられる順位を示している。次のノードレコードＮＲ８には、非隣接ノードＮ８の情報が記録される。ノードレコードＮＲ９、ＮＲ１０およびＮＲ１１には、非隣接ノードＮ５、Ｎ２およびＮ１の情報が記録される。以上のように、本実施形態では、ユニットＵに含まれるノードＮの情報は、ランダムにではなく、上述した規則に従った順番でノードレコードＮＲに記録されていく。ここで、以下の説明において、ノードレコード番号とは、最初のノードレコードＮＲ１を「０」として、各ノードレコードＮＲ２以降が何番目に記録されているかを特定する番号を意味する。以上のノードレコード番号を図２８のノードレコードＮＲ１〜ＮＲ１１に当てはめると、当該ノードレコードＮＲ１〜ＮＲ１１のノードレコード番号は「０」〜「１０」となる。なお、以上のような並べ方は、ユニットＵと隣接ユニットＮＵの間にまたがる道路の接続関係をたどる処理を高速に行ったり、ユニットＵの親子間におけるノードやリンクの対応づけを的確に行ったりできるという効果を生むが、これらの具体的な処理および効果については後述する。
【００７７】
さて、再度図２７を参照して、ノードレコードＮＲ１の内部データ構造を詳細に説明する。ノードレコードＮＲ１は、ノード属性と、ノード座標と、ノード接続情報とから構成される。ノード属性は、ノードレコードＮＲ１に記録されるノードの属性を表すための情報である。ノード属性の例としては、記録されたノードに交差点での交通が規制されているか否かを示す情報、当該ノードにより表される交差点に名称があるか否かを示す情報、当該ノードにより表される交差点に信号機が存在するか否か等の情報がある。なお、ノード属性に交通規制または交差点名称の有無に関する情報を記録する場合には、本実施形態では説明しない交差点規制テーブルおよび交差点名称テーブル等のテーブルを別途作成し、該当する情報を記録するようにする。
【００７８】
また、ノード座標は、ノードレコードＮＲ１に記録されるノードの経度方向の座標および緯度方向の座標を表すための情報である。ノードの経度方向の座標および緯度方向の座標としては、絶対経度緯度座標を記録しても良いが、記録されるノードを含むユニットＵ（矩形領域）の左下隅を基準点として、当該ユニットＵがカバーする範囲の経度幅および緯度幅を２バイト程度の値で正規化した座標で表すのが一般的である。例えば、図２９に示すように、ユニットＵの左下隅Ｎａの座標を（００００ｈ，００００ｈ）と表現し（ｈは１６進数の値を表す）、当該ユニットＵの座標系を経度方向および緯度方向共に８０００ｈで正規化する。この場合、ユニットの左上隅Ｎｂの座標は（００００ｈ，８０００ｈ）と表現される。また、ユニットの右下隅Ｎｃの座標は（８０００ｈ，００００ｈ）と表現される。さらに、ユニットの右上隅Ｎｄの座標は（８０００ｈ，８０００ｈ）で表現される。
また、ノード接続情報は、ノードレコードＮＲ１に記録されるノードＮと、後述するリンクレコードＬＲに記録されるリンクＬとの接続関係を表す情報である。ノード接続情報の詳細については後述する。
なお、他のノードレコードＮＲ２〜ＮＲ（Ｑ＋Ｒ）の内部データ構造については、ノードレコードＮＲ１と同様であるため説明を省略する。ただし、他のノードレコードＮＲ２〜ＮＲ（Ｑ＋Ｒ）には、互いに異なるノードＮの情報が記録される。
【００７９】
次に、図７の第１のリンクテーブルのデータ構造を説明する。ここで、予め断っておくが、第１および第２のリンクテーブルは、同様のデータ構造を有しており、主要幹線道路および細街路について作成される点で相違する。そのため、以降では、第２のリンクテーブルの詳細な説明を省略する。図３０は、第１のリンクテーブルの詳細なデータ構造を示す図である。図３０において、第１のリンクテーブルは、道路数Ｓと、Ｓ個の道路レコードＲＲ１〜ＲＲＳとから構成される。道路数Ｓは、第１のノードテーブルにより表される道路網に含まれる道路の本数を示す情報である。ここで、Ｓは、１以上の自然数であって、ユニットＵにより表される地図上の道路網に道路が何本存在するかを示す。道路レコードＲＲ１には、ある１つの道路属性が割り当てられ、当該道路属性が同じリンクＬおよびノードＮに関する情報が記録される。また、道路レコードＲＲ２には、他の１つの道路属性が割り当てられ、当該道路属性が同じリンクＬおよびノードＮに関する情報が記録される。以降、同様に、道路レコードＲＲＳには、他の道路レコードＲＲ１〜ＲＲ（Ｓ−１）には割り当てられていない１つの道路属性が割り当てられ、当該道路属性が同じリンクＬおよびノードＮに関する情報が記録される。以上から明らかなように、道路レコードＲＲ１〜ＲＲＳには、互いに異なる道路属性が割り当てられる。ここで、道路属性とは、道路の種別毎に分類するための情報である。典型的には、道路は、高速道路、国道、県道、市道、私道等といった区分で分類され、さらには、各道路の名称によってより詳細に分類される。なお、必要に応じて、道路の一方通行規制等を道路属性に採用してもよい。
【００８０】
道路レコードＲＲ１は、道路属性と、リンク数Ｔ１と、先頭ノードレコード番号と、Ｔ１個のリンクレコードＬＲ１〜ＬＲＴ１とから構成される。道路属性には、道路種別（高速道路、国道、県道等）、道路の一方通行規制等を示す情報が記録される。リンク数Ｔ１は、道路レコードＲＲ１に記録されるリンクＬの個数を示す情報である。ここで、Ｔ１は、１以上の自然数であって、ユニットＵにより表される地図上の道路網において、道路属性の情報に該当するリンクＬが何個存在するかを示す情報である。先頭ノードレコード番号は、所定のノードレコードＮＲを特定するためのノードレコード番号を意味する。このノードレコード番号は、図２８等を参照して上述したように、最初のノードレコードＮＲ１を「０」として、各ノードレコードＮＲ２以降が何番目に記録されているかを特定する番号である。さらに、所定のノードレコードＮＲとは、道路レコードＲＲ１により表される道路網の先頭に位置するノードＮが記録されたものを意味する。また、リンクレコードＬＲ１には、ユニットＵにより表される地図上の道路網において、道路属性により分類されるリンクＬの内のある１つに関する情報が記録される。そのために、リンクレコードＬＲ１は、リンク属性と、リンク接続情報とから構成される。リンク属性とは、リンクレコードＬＲ１により表されるリンクＬの属性を示す情報である。リンク属性の典型例としては、リンク種別（本線リンクであるか、側道リンクであるか等）または車線数等がある。また、リンク接続情報は、リンクレコードＬＲ１により表されるリンクＬに接続されたノードＮ、またはリンクレコードＬＲ１により表されるリンクＬとノードＮを介してつながっているリンクＬの情報である。また、リンクレコードＬＲ２には、道路属性により分類されるリンクＬの内の他の１つに関する情報が記録される。以降同様に、リンクレコードＬＲＴ１には、道路属性により分類されるリンクＬの内、他のリンクレコードＬＲ（Ｔ１−１）に記録されていない１つのリンクＬに関する情報が記録される。ここで、リンクレコードＬＲ２〜ＬＲＴは、リンクレコードＬＲ１と同様に、リンク属性と、リンク接続情報とから構成される。以上から明らかなように、リンクレコードＬＲ１〜ＬＲＴ１には、互いに異なるリンクＬに関する情報が記録される。
【００８１】
さて、次に、第１のリンクテーブルに記載される情報の具体例を、図２６の道路網の場合について具体的に説明する。上述したように、図２６の道路網は、１１個のノードＮ０〜Ｎ１０と、１１個のリンクＬ０〜Ｌ１０とから構成される。また、説明をより具体的にするために、リンクＬ０〜Ｌ２は、ノードＮ０を先頭として、Ｌ０→Ｌ１→Ｌ２の順番で接続されることにより、１本の道路（例えば、国道）を構成すると仮定する。この仮定下では、リンクＬ０〜Ｌ２は互いに同一の道路属性（国道）を有する。リンクＬ３〜Ｌ５は、ノードＮ４を先頭として、Ｌ３→Ｌ４→Ｌ５の順番で接続されることにより、１本の道路（例えば、県道）を構成すると仮定する。この仮定下では、リンクＬ３〜Ｌ５は互いに同一の道路属性（県道）を有する。リンクＬ６〜Ｌ８は、ノードＮ７を先頭として、Ｌ６→Ｌ７→Ｌ８の順番で接続されることにより、１本の道路（例えば、幅員が５．５ｍ以上の私道）を構成すると仮定する。この仮定下では、リンクＬ６〜Ｌ８は互いに同一の道路属性（私道）を有する。リンクＬ９およびＬ１０は、ノードＮ５を先頭として、Ｌ９→Ｌ１０の順番で接続されることにより、１本の道路（例えば、市道）を構成すると仮定する。この仮定下では、リンクＬ９およびＬ１０は互いに同一の道路属性（市道）を有する。
【００８２】
以上の仮定下では、道路は、国道、県道、私道および市道の４本であるから、第１のリンクテーブルの道路数Ｓとして、「４」が記録される。また、道路属性としては、国道、県道、私道および市道の４種類があるので、第１のリンクテーブルには、４個の道路レコードＲＲ１〜ＲＲ４が記録される。まず、道路レコードＲＲ１について説明する。道路属性としては「国道」を表す情報が記録される。また、リンク数Ｔ１としては、国道がリンクＬ０〜Ｌ２で構成されることから「３」を示す情報が記録される。また、リンクＬ０〜Ｌ２で表される道路の先頭は、ノードＮ０により表される。ノードＮ０のレコード番号は「１」である（図２８参照）。ゆえに、先頭ノードＮの番号としては「１」が記録される。次に、リンクレコードＬＲ１１（リンクＬ０のレコード）において、リンク属性については説明を省略する。
【００８３】
さて、ここで、各リンクレコードＬＲに記録されるリンク接続情報、および図２７に示されるノード接続情報を説明する。同時に、ノードＮとリンクＬの接続関係をたどる処理についても説明する。例えば、図２６に示すように、ノードＮ２はリンクＬ１、Ｌ２、Ｌ６、およびＬ７の４本と接続している。このように、各ノードＮ２を中心として、４本のリンクＬ１、Ｌ２、Ｌ６およびＬ７がつながっている。また、ノードレコードＮＲ１０には、ノードＮ２に関連する情報が記録される（図２７参照）。また、リンクレコードＬＲ１２、ＬＲ１３、ＬＲ３１およびＬＲ３２には、リンクＬ１、Ｌ２、Ｌ６およびＬ７に関連する情報が記録される（図３１参照）。ノードレコードＮＲ１０のノード接続情報（図２７参照）、および各リンクレコードＬＲ１２、ＬＲ１３、ＬＲ３１およびＬＲ３２のリンク接続情報（図３１参照）には、ノードＮ２に接続されたリンクＬ１、Ｌ２、Ｌ６およびＬ７をたどるための情報が記録される。まず、ノードレコードＮＲ１０には、ノード接続情報として、ノードＮ２に接続された最初のリンクＬ（今、仮にリンクＬ１とする）が記録されたリンクレコードＬＲ１２を参照するための情報が記録される。より具体的には、ノード接続情報としては、リンクテーブルの先頭からリンクレコードＬＲ１２までのオフセットアドレスを記録しても良いし、リンクレコードＬＲ１２のリンクレコード番号を記録しても良い。ここで、リンクレコード番号とは、リンクテーブルにおいて最初のリンクレコードＬＲ１１を「０」として、リンクレコードＬＲ１２以降が何番目に記録されているかを特定する番号を意味する。以上のリンクレコード番号を図３１のリンクレコードＬＲに当てはめると、リンクレコードＬＲ１１〜ＬＲ１３のリンクレコード番号は「０」〜「３」となる。また、リンクレコードＬＲ２１〜ＬＲ２３のリンクレコード番号は「４」〜「６」となる。また、リンクレコードＬＲ３１〜ＬＲ３３のリンクレコード番号は「７」〜「９」となる。さらに、リンクレコードＬＲ４１およびＬＲ４２のリンクレコード番号は「１０」および「１１」となる。
【００８４】
ここで注意を要するのは、ノード接続情報には、同じユニットＵ内の道路網の接続をたどる場合に限り、オフセットアドレスおよびリンクレコード番号が記録される。同様に、リンク接続情報には、同じユニットＵ内の道路網の接続をたどる場合に限り、オフセットアドレスおよびノードレコード番号が参照される。詳しくは図３７および図３８を参照して説明するが、あるユニットＵおよび隣接ユニットＮＵの境界をまたぐような道路網の接続をたどる場合には、オフセットアドレスおよびリンクレコード番号は参照されない。
【００８５】
図３２の例では、ノードレコードＮＲ１０のノード接続情報には、当該ノードレコードＮＲ１０から、リンクテーブルのリンクレコードＬＲ１２を参照可能なように、当該リンクレコードＬＲ１２までのオフセットアドレスまたは当該リンクレコードＬＲ１２のリンクレコード番号が記録される。また、図３２の例では、リンクレコードＬＲ１２からはリンクレコードＬＲ３１が参照されるので、リンクレコードＬＲ１２のリンク接続情報には、リンクＬ１と接続する他のリンクＬ６を参照可能なように、当該リンクレコードＬＲ３１へのオフセットアドレスまたは当該リンクレコードＬＲ３１のリンクレコード番号が記録される。かかるノードレコードＮＲ１０のノード接続情報およびリンクレコードＬＲ１２のリンク接続情報により、リンクＬ１はノードＮ２を起点として、リンクＬ６と接続していることが分かる。
【００８６】
ここで注意を要するのは、リンクレコードＬＲ１２のリンク接続情報としては、リンクレコード番号やオフセットアドレスだけでなく、当該リンク接続情報が他のリンクＬに対してであることを示すフラグを記録しておく。
さらに注意を要するのは、同一道路レコードＲＲ内で記録されるリンクＬを参照するためのリンク接続情報は、各リンクレコードＬＲには記録されない。同一道路レコードＲＲに属するリンクＬ同士は、リンク接続情報を参照しなくとも、リンクレコードＬＲの並び方によりたどることができるからである。つまり、道路レコードＲＲ１においてリンクレコードＬＲ１１とリンクレコードＬＲ１２とは、連続するアドレス領域に並べて記録されるため、リンクＬ１およびリンクＬ２は相互に接続していると判断することができる。同様に、道路レコードＲＲ３において、リンクレコードＬＲ３１およびＬＲ３２は連続アドレス領域に並べて記録されるため、リンクＬ６とリンクＬ７とは相互に接続していると判断することができる。
【００８７】
さて、リンクレコードＬＲ１２の次に参照されるリンクレコードＬＲ３１に記録されたリンクＬ６は、道路レコードＲＲ１以外に区分されたリンクＬとは接続されていない。そのため、リンクレコードＬＲ３１のリンク接続情報としては、リンクＬ１、Ｌ２、Ｌ６およびＬ７の中心に位置するノードＮ２が記録されたノードレコードＮＲ１０を参照可能な情報が記録される。リンクレコードＬＲ３１のリンク接続情報としても、ノードレコードＮＲ１０へのオフセットアドレスまたは当該ノードレコードＮＲ１０のノードレコード番号が用いられる。
ここで注意を要するのは、リンクレコードＬＲ３１のリンク接続情報としては、ノードレコードＮＲ１０のノードレコード番号またはオフセットアドレスだけでなく、当該リンク接続情報がノードテーブルＮＲに対して設定されていることを示すフラグも記録される。
【００８８】
以上のように、各ノードレコードＮＲには、最初に接続するリンクＬへのノード接続情報のみを記録し、各リンクレコードＬＲには、そこに記録されるリンクＬに接続する他の道路レコードＲＲ内のリンクＬへのリンク接続情報、もしくは起点となったノードＮが記録されるノードレコードＮＲへのリンク接続情報を記録することによって、各ノードＮを起点としたリンクＬの接続をたどることができる。
【００８９】
「ユニットヘッダのデータ構造」
さて、再度図７を参照して、ユニットヘッダのデータ構造について詳細に説明する。ユニットヘッダには、地図ファイルＣＦのユニットデータの管理情報が記録される。ユニットヘッダは、少なくともユニットＩＤ、バージョンコード、およびユニットデータを構成する８種類のテーブルのデータサイズから構成される。ユニットＩＤは、当該地図ファイルＣＦにより表されるユニットＵを一意に特定できる識別番号である。より具体的には、ユニットＩＤは、ユニットＵのレベルＬ、およびユニットＵの親子関係および隣接関係が特定できる番号であり、地図ファイルＣＦのパス名と相互に変換できるものが望ましい。例えば、ユニットＩＤを３２ビット（４バイト）のコードで表現するとし、ＭＳＢから２ビットをリザーブビットとし、順にユニットレベルＬを２ビット、レベル「３」の経度方向の分割位置Ｘ３を５ビット、レベル「３」の緯度方向の分割位置Ｙ３を５ビット、レベル「２」の経度方向の分割位置Ｘ２を３ビット、レベル「２」の緯度方向の分割位置Ｙ２を３ビット、レベル「１」の経度方向の分割位置Ｘ１を３ビット、レベル「１」の緯度方向の分割位置Ｙ１を３ビット、レベル「０」の経度方向の分割位置Ｘ０を３ビット、レベル「０」の緯度方向の分割位置Ｙ０を３ビットで表す。ここで、レベル「３」の経度方向の分割位置Ｘ３は、ユニットＵがレベル「３」に属するとした場合に東経方向に数えて何番目（起算点は経度０度）に位置するかを示す数である。レベル「３」の緯度方向の分割位置Ｙ３は、ユニットＵがレベル「３」に属するとした場合に北緯方向に数えて何番目（起算点は北緯０度）に位置するかを示す数である。レベル「２」の経度方向の分割位置Ｘ２は、ユニットＵがレベル「２」に属するとした場合に東経方向に数えて何番目（起算点はレベル「３」のユニットＵの左下）に位置するかを示す数である。レベル「２」の緯度方向の分割位置Ｙ２は、ユニットＵがレベル「２」に属するとした場合に北緯方向に数えて何番目（起算点はレベル「３」のユニットＵの左下）に位置するかを示す数である。レベル「１」の経度方向の分割位置Ｘ１は、ユニットＵがレベル「１」に属するとした場合に東経方向に数えて何番目（起算点はレベル「２」のユニットＵの左下）に位置するかを示す数である。レベル「１」の緯度方向の分割位置Ｙ１は、ユニットＵがレベル「１」に属するとした場合に北緯方向に数えて何番目（起算点はレベル「２」のユニットＵの左下）に位置するかを示す数である。レベル「０」の経度方向の分割位置Ｘ０は、ユニットＵがレベル「０」に属するとした場合に東経方向に数えて何番目（起算点はレベル「１」のユニットＵの左下）に位置するかを示す数である。レベル「０」の緯度方向の分割位置Ｙ０は、ユニットＵがレベル「０」に属するとした場合に北緯方向に数えて何番目（起算点はレベル「１」のユニットＵの左下）に位置するかを示す数である。
【００９０】
例えば、図４に示すレベル「０」のユニットＵ0 のパス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０２０１．ｍａｐ」であるため、前述のＬ＝０、Ｘ３＝１６、Ｙ３＝６、Ｘ２＝４、Ｙ２＝１、Ｘ１＝５、Ｙ１＝３、Ｘ０＝２、Ｙ０＝１となる。この場合、ユニットＵ0 のユニットＩＤは、１３５９２８５２９（１０進数表記）となる。以上から明らかなように、地図ファイルＣＦのパス名からユニットＩＤを一意に特定することができ、逆にユニットＩＤからパス名を一意に特定することができる。
【００９１】
またバージョンコードは、地図ファイルＣＦ（ユニットＵ）のバージョンを表すための識別コードであり、例えば、当該ユニットのフォーマットバージョンを表すコードを２バイト、当該ユニットのコンテンツバージョンを表すコードを２バイト等で記述した、合計４バイトのコードで表すものとする。このバージョンコードは、センタ局２からあるユニットＩＤの地図ファイルＣＦが端末装置１にダウンロードされた際に、端末装置１の第１の記憶装置１９に既に格納されている同一ユニットＩＤの地図ファイルＣＦと置き換えるか否かの判断等に使用される。なお、この際の詳細な処理については後述する。
【００９２】
また、各テーブルのデータサイズには、地図ファイルＣＦを構成する各テーブルのデータサイズが記録されており、それぞれは例えば２バイトで表される。各テーブルのデータサイズを順に加算していくことにより、各テーブルが格納されている、地図ファイルＣＦの先頭からのオフセットアドレスが算出可能となる。なお、各テーブルのデータサイズとしては、基本背景テーブルのデータサイズ、詳細背景テーブルのデータサイズ、基本文字記号テーブルのデータサイズ、詳細文字記号テーブルのデータサイズ、第１のノードテーブルのデータサイズ、第１のリンクテーブルのデータサイズ、第２のノードテーブルのデータサイズ、第２のリンクテーブルのデータサイズが並ぶ。それぞれのテーブルの内容については上述した通りである。
【００９３】
以上、地図ファイルＣＦの詳細なデータ構造について説明した。次に、第１のデータベース１１１から地図ファイルＣＦを読み出す際の端末装置１の動作について、図面を参照して説明する。
「読み出し処理」
図１を参照して説明したように、本実施形態の端末装置１は、典型的にはカーナビゲーションシステムである。周知のように、マップマッチング、経路探索、または経路案内等の処理が実行される。以下には、これらの処理の内、経路探索処理に関連して、地図ファイルＣＦを読み出す処理、あるユニットＵと隣接ユニットＮＵにまたがる道路の接続をたどる処理、および階層間でのノードＮとリンクＬとの対応づけを行う処理について詳細に説明する。なお、以下では、出発地および目的地の間の最短ルートを求める処理そのものについては本願発明のポイントではないため特に説明しない。
【００９４】
図３３は、経路探索処理の概念を示す図である。図３３に示すように、最短ルートを求める処理では、出発地ＳＰ側と目的地ＤＰ側の両方向から探索が広げられる。さらに、経路探索処理では、下位階層から上位階層までの複数階層の地図ファイルＣＦが用いられる。この時、出発地ＳＰおよび目的地ＤＰ周辺では、詳細な道路網を表す下位階層の地図ファイルＣＦを用いて、最短ルートが探索される。一方、出発地ＳＰおよび目的地ＤＰ周辺以外では、粗い道路網を表す上位階層の地図ファイルＣＦが用いられる。以上の図３３に示す経路探索処理では、いわゆる双方向階層別探索の手法が用いられる。また、地図ファイルＣＦを用いて、出発地ＳＰから目的地ＤＰへの最短ルートを求める場合には、周知のダイクストラ法等が使用される。なお、ダイクストラ法については、本願発明のポイントではなく、かつ周知の技術であるため、これ以上説明しない。
【００９５】
以下、図３４のフローチャートを参照して、端末装置１で実行される双方向階層別探索の処理手順を詳細に説明する。まず、双方向階層別探索では、端末装置１の出発地ＳＰおよび目的地ＤＰの設定が実行される（ステップＳ１０１，Ｓ１０２）。ステップＳ１０１およびＳ１０２において、出発地ＳＰおよび目的地ＤＰは、出力装置１１０のディスプレイに表示されるメニューに従って、端末装置１のユーザが入力装置１１を操作することにより設定される。ここで、最近のカーナビゲーションシステムでは、出発地ＳＰおよび目的地ＤＰは、一般的に、住所、電話番号、地名または施設名称等を使って設定される。設定された出発地ＳＰおよび目的地ＤＰを特定する情報は、入力装置１１からデータ処理部１３に送信される。
【００９６】
ステップＳ１０２が終了すると、データ処理部１３は、読み出し／書き込み制御部１８と協働して、経路探索処理に必要な地図ファイルＣＦを、第１の記憶装置１９から主記憶（図示せず）に順次読み込む（ステップＳ１０３）。前述したように、第１の記憶装置１９に格納された各地図ファイルＣＦは、図２等に示すように、地図を矩形領域に分割したユニットＵを単位としてデジタルデータ化される。さらに、各地図ファイルＣＦは、ファイルシステムにより管理される。ファイルシステムは、第１の記憶装置１９の論理領域がツリー構造をとるようにディレクトリを作成する。これによって、各地図ファイルＣＦが格納される論理領域は、ルートおよびファイル名、ならびにそれらの間に介在するサブディレクトリ名により表されるパスにより一意に特定される。また、本実施形態のツリー構造およびファイル名は、上述したように、ユニットＵ同士の親子関係および隣接関係を特定する。ファイルシステムを構成するデータ処理部１３および読み出し／書き込み制御部１８は、最初のステップＳ１０３において、入力装置１１から送信されてくる出発地ＳＰ周辺を表す地図ファイルＣＦを第１の記憶装置１９から読み出すためには、当該地図ファイルＣＦのパス名を求めなければならない。
【００９７】
ここで、図３５は、図３４のステップＳ１０３の詳細な処理手順を示すフローチャートである。図３５の処理を簡単に説明すると、データ処理部１３が読み込むべき地図ファイルＣＦのレベル（階層）および代表点となる地点の座標情報から、当該地図ファイルＣＦのパス名を求める。そして、読み出し／書き込み制御部１８は、データ処理部１３により求められたパス名を基に、第１の記憶装置１９から地図ファイルＣＦを読み出す。以下、図３５のフローチャートを参照して、図４および図５に示すレベル「０」のユニットＵ0 を表す地図ファイルＣＦ（「￥Ｍ０２０１．ｍａｐ」）を読み出す際の処理手順を説明する。
【００９８】
ここで、代表点とは、読み出すべき地図ファイルＣＦがカバーする範囲に含まれる１つの地点を意味する。以下の説明において、経度座標ＬＯＮ０ および経度座標ＬＡＴ０
は、ユニットＵ0 の代表点の経度方向の位置を示す座標および緯度方向の位置を示す座標とする。本実施形態では、経度座標ＬＯＮ０ および経度座標ＬＡＴ０は、東経１３２度３９分２０秒および北緯３２度５５分３７秒とする。
【００９９】
さらに、ステップＳ１０３の処理には、いくつかのパラメータが必要となる。以下の説明において、経度幅Ｗ３は、レベル「３」に属する各ユニットＵがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅Ｈ３は、レベル「３」に属する各ユニットＵがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。本実施形態の場合、図２および図３で説明したように、レベル「３」の矩形領域が約６４０ｋｍ四方の場合には、経度幅Ｗ３および緯度幅Ｈ３は２８８００秒（８度）および１９２００秒（５度２０分）である。経度幅Ｗ２は、レベル「２」に属する各ユニットＵがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅Ｈ２は、レベル「２」に属する各ユニットＵがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。レベル「２」の矩形領域が約８０ｋｍ四方の場合には、経度幅Ｗ２および緯度幅Ｈ２は３６００秒（１度）および２４００秒（４０分）である。経度幅Ｗ１は、レベル「１」に属する各ユニットＵがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅Ｈ１は、レベル「１」に属する各ユニットＵがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。レベル「１」の矩形領域が約１０ｋｍ毎の場合には、経度幅Ｗ１および緯度幅Ｈ１は４５０秒（７分３０秒）および３００秒（５分）である。経度幅Ｗ０は、レベル「０」に属する各ユニットＵがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅Ｈ０は、レベル「０」に属する各ユニットＵがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。レベル「０」の矩形領域が約１．２ｋｍ毎の場合には、経度幅Ｗ０および緯度幅Ｈ０は５６．２５秒および３７．５秒である。
【０１００】
さて、データ処理部１３は、まず、代表点の経度座標ＬＯＮ0 および緯度ＬＡＴ0 を特定し（ステップＳ２０１）、読み込むべき地図ファイルＣＦのレベルＬ（ユニットＵ0 の地図ファイルＣＦを読み込む場合、Ｌ＝０）を特定する（ステップＳ２０２）。ここで、ステップＳ２０１およびＳ２０２は、双方向階層別探索において一般的に実行される処理であるため、ここでは詳細に説明しない。
【０１０１】
次に、データ処理部１３は、ステップＳ２０３に進み、代表点の経度座標ＬＯＮ0 をレベル「３」の経度幅Ｗ３で除算した時の商ＤＬＯＮ３、および、当該代表点の緯度ＬＡＴ0 をレベル「３」の緯度幅Ｈ３で除算した時の商ＤＬＡＴ３を算出する。今、経度幅Ｗ３＝２８８００秒（８度）、緯度幅Ｈ３＝１９２００秒（５度２０分）、経度座標ＬＯＮ0 ＝東経１３２度３９分２０秒、経度座標ＬＡＴ０ ＝北緯３２度５５分３７秒であるから、商ＤＬＯＮ３＝１６、商ＤＬＡＴ３＝６となる。データ処理部１３は、算出された商ＤＬＯＮ３および商ＤＬＡＴ３を順番に並べて４桁の数字を作成する。今回作成される４桁の数字は、「１６０６」である。ここで、商ＤＬＯＮ３および／または商ＤＬＡＴ３が１桁となる場合は、下から２桁目に「０」を付ける。
【０１０２】
データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびファイル名の頭文字を定義する「Ｍ」を付加し、さらにその末尾にファイル名の拡張子「．ｍａｐ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ０ から、読み込むべき地図ファイルＣＦ（ユニットＵ0 のもの）のファイル名（今回の場合、「￥Ｍ１６０６．ｍａｐ」）を導き出す。
さらに、データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびサブディレクトリ名の頭文字を定義する「Ｄ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ０ から、読み込むべき地図ファイルＣＦが格納されたサブディレクトリ名（今回の場合「￥Ｄ１６０６」）を導出する（ステップＳ２０３）。
【０１０３】
次に、データ処理部１３は、ステップＳ２０２で指定されたレベルＬが「３」か否かを判断する（ステップＳ２０４）。レベルＬが「３」の場合、データ処理部１３は、ステップＳ２０５に進み、ルート（「￥ＭＡＰ」）の後に、ステップＳ２０３で導出したファイル名（「￥Ｍ１６０６．ｍａｐ」）を付加して、パス名を導出する。したがって、パス名は「￥ＭＡＰ￥Ｍ１６０６．ｍａｐ」となる。データ処理部１３は、導出したパス名を読み出し／書き込み制御部１８に出力する（ステップＳ２０５）。読み出し／書き込み制御部１８は、入力されたパス名（「￥ＭＡＰ￥Ｍ１６０６．ｍａｐ」）に従って、地図ファイルＣＦを第１の記憶装置１９内の第１のデータベース１１１から読み出す。読み出し／書き込み制御部１８は、読み出した地図ファイルＣＦをデータ処理部１３内の主記憶（図示せず）に転送する。このようにして、データ処理部１３は、地図ファイルＣＦを第１の記憶装置１９から主記憶に読み込む（ステップＳ２０６）。
【０１０４】
ところで、上述したように、ステップＳ２０２で指定されたレベルは「０」であるから、データ処理部１３は、ステップＳ２０４においてレベルＬが「３」でないと判断して、ステップＳ２０７に進む。データ処理部１３は、ステップＳ２０３で導出した商ＤＬＯＮ３の余りＲＬＯＮ３を算出した後、当該余りＲＬＯＮ３をレベル「２」の経度幅Ｗ２で除算した時の商ＤＬＯＮ２を算出する。さらに、データ処理部１３は、ステップＳ２０３で導出した商ＤＬＡＴ３の余りＲＬＡＴ３を算出した後、当該余りＲＬＡＴ３をレベル「２」の緯度幅Ｈ２で除算した時の商ＤＬＡＴ２を算出する。今、上述した数値を用いた場合、商ＤＬＯＮ２および商ＤＬＡＴ２は、ＤＬＯＮ２＝４およびＤＬＡＴ２＝１となる。データ処理部１３は、算出された商ＤＬＯＮ２および商ＤＬＡＴ２を順番に並べて４桁の数字を作成する。今回作成される４桁の数字は、「０４０１」である。ここで、商ＤＬＯＮ２および／または商ＤＬＡＴ２が１桁となる場合は、２桁目に「０」を付ける。
【０１０５】
データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびファイル名の頭文字を定義する「Ｍ」を付加し、さらにその末尾にファイル名の拡張子「．ｍａｐ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ0 から、読み込むべき地図ファイルＣＦのファイル名（今回の場合、「￥Ｍ０４０１．ｍａｐ」）を導き出す。
さらに、データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびサブディレクトリ名の頭文字を定義する「Ｄ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ0 から、読み込むべき地図ファイルＣＦ（ユニットＵ0 のもの）が格納されたサブディレクトリ名（今回の場合「￥Ｄ０４０１］）を導出する（ステップＳ２０７）。
【０１０６】
次に、データ処理部１３は、ステップＳ２０２で指定されたレベルＬが「２」か否かを判断する（ステップＳ２０８）。レベルＬが「２」の場合、データ処理部１３は、ステップＳ２０９に進み、ルート（「￥ＭＡＰ」）の後に、ステップＳ２０３で導出したサブディレクトリ名（「￥Ｄ１６０６」）およびステップＳ２０７で導出したファイル名（「￥Ｍ０４０１．ｍａｐ」）を付加して、パス名を導出する。したがって、パス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａｐ」となる。データ処理部１３は、導出したパス名を読み出し／書き込み制御部１８に出力する（ステップＳ２０９）。読み出し／書き込み制御部１８は、入力されたパス名（「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａｐ」）に従って、地図ファイルＣＦを第１の記憶装置１９内の第１のデータベース１１１から読み出す。読み出し／書き込み制御部１８は、読み出した地図ファイルＣＦをデータ処理部１３内の主記憶（図示せず）に転送する。このようにして、データ処理部１３は、地図ファイルＣＦを第１の記憶装置１９から主記憶に読み込む（ステップＳ２０６）。
【０１０７】
上述したように、ステップＳ２０２で指定されたレベルは「０」であるから、データ処理部１３は、ステップＳ２０８においてレベルＬが「２」でないと判断して、ステップＳ２１０に進む。データ処理部１３は、ステップＳ２０７で導出した商ＤＬＯＮ２の余りＲＬＯＮ２を算出した後、当該余りＲＬＯＮ２をレベル「１」の経度幅Ｗ１で除算した時の商ＤＬＯＮ１を算出する。さらに、データ処理部１３は、ステップＳ２０７で導出した商ＤＬＡＴ２の余りＲＬＡＴ２を算出した後、当該余りＲＬＡＴ２をレベル「１」の緯度幅Ｈ１で除算した時の商ＤＬＡＴ１を算出する。今、上述した数値を用いた場合、商ＤＬＯＮ１および商ＤＬＡＴ１は、ＤＬＯＮ１＝５およびＤＬＡＴ１＝３となる。データ処理部１３は、算出された商ＤＬＯＮ１および商ＤＬＡＴ１を順番に並べて４桁の数字を作成する。今回作成される４桁の数字は、「０５０３」である。ここで、商ＤＬＯＮ１および／または商ＤＬＡＴ１が１桁となる場合は、２桁目に「０」を付ける。
【０１０８】
データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびファイル名の頭文字を定義する「Ｍ」を付加し、さらにその末尾にファイル名の拡張子「．ｍａｐ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ0 から、読み込むべき地図ファイルＣＦのファイル名（「￥Ｍ０５０３．ｍａｐ」）を導き出す。
さらに、データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびサブディレクトリ名の頭文字を定義する「Ｄ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ0 から、読み込むべき地図ファイルＣＦ（ユニットＵ0 のもの）が格納されたサブディレクトリ名（今回の場合「￥Ｄ０５０３］）を導出する（ステップＳ２０１０）。
【０１０９】
次に、データ処理部１３は、ステップＳ２０２で指定されたレベルＬが「１」か否かを判断する（ステップＳ２０１１）。レベルＬが「１」の場合、データ処理部１３は、ステップＳ２０１２に進み、ルート（「￥ＭＡＰ」）の後に、ステップＳ２０３で導出したサブディレクトリ名（「￥Ｄ１６０６」）、ステップＳ２０７で導出したサブディレクトリ名（「￥Ｄ０４０１」）およびステップＳ２０１０で導出したファイル名（￥Ｍ０５０３．ｍａｐ）を付加して、パス名を導出する。したがって、パス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０５０３．ｍａｐ」となる。データ処理部１３は、導出したパス名を読み出し／書き込み制御部１８に出力する（ステップＳ２０１２）。読み出し／書き込み制御部１８は、入力されたパス名（「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０５０３．ｍａｐ」）に従って、地図ファイルＣＦを第１の記憶装置１９内の第１のデータベース１１１から読み出す。読み出し／書き込み制御部１８は、読み出した地図ファイルＣＦをデータ処理部１３内の主記憶（図示せず）に転送する。このようにして、データ処理部１３は、地図ファイルＣＦを第１の記憶装置１９から主記憶に読み込む（ステップＳ２０６）。
【０１１０】
上述したように、ステップＳ２０２で指定されたレベルＬは「０」であるから、データ処理部１３は、ステップＳ２０１１においてレベルＬが「１」でないと判断して、ステップＳ２０１３に進む。データ処理部１３は、ステップＳ２１０で導出した商ＤＬＯＮ１の余りＲＬＯＮ１を算出した後、当該余りＲＬＯＮ１をレベル「０」の経度幅Ｗ０で除算した時の商ＤＬＯＮ０を算出する。さらに、データ処理部１３は、ステップＳ２１０で導出した商ＤＬＡＴ１の余りＲＬＡＴ１を算出した後、当該余りＲＬＡＴ１をレベル「０」の緯度幅Ｈ０で除算した時の商ＤＬＡＴ０を算出する。今、上述した数値を用いた場合、商ＤＬＯＮ０および商ＤＬＡＴ０は、ＤＬＯＮ０＝２およびＤＬＡＴ０＝１となる。データ処理部１３は、算出された商ＤＬＯＮ０および商ＤＬＡＴ０を順番に並べて４桁の数字を作成する。今回作成される４桁の数字は、「０２０１」である。ここで、商ＤＬＯＮ０および／または商ＤＬＡＴ０が１桁となる場合は、２桁目に「０」を付ける。
データ処理部１３は、作成した４桁の数字の先頭に、ディレクトリの識別子「￥」およびファイル名の頭文字を定義する「Ｍ」を付加し、さらにその末尾にファイル名の拡張子「．ｍａｐ」を付加する。これによって、データ処理部１３は、代表点の経度座標ＬＯＮ0 および経度座標ＬＡＴ0 から、読み込むべき地図ファイルＣＦのファイル名（今回の場合、「￥Ｍ０２０１．ｍａｐ」）を導き出す（ステップＳ２０１３）。ここで、ステップＳ２０１３では、レベルＬが最下位層の「０」と自動的に判断できるので、データ処理部１３は、サブディレクトリ名を導出しない。
【０１１１】
次に、データ処理部１３は、ステップＳ２０１４に進み、ルート（「￥ＭＡＰ」）の後に、ステップＳ２０３、Ｓ２０７およびＳ２１０で導出したサブディレクトリ名の配列（「￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３）ならびにステップＳ２０１３で導出したファイル名（今回の場合、「￥Ｍ０２０１．ｍａｐ」）を付加して、パス名を導出する。したがって、パス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０２０１．ｍａｐ」となる。データ処理部１３は、導出したパス名を読み出し／書き込み制御部１８に出力する（ステップＳ２０１４）。読み出し／書き込み制御部１８は、入力されたパス名（「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０５０３．ｍａｐ」）に従って、地図ファイルＣＦを第１の記憶装置１９内の第１のデータベース１１１から読み出す。読み出し／書き込み制御部１８は、読み出した地図ファイルＣＦをデータ処理部１３内の主記憶（図示せず）に転送する。このようにして、データ処理部１３は、所望の地図ファイルＣＦ（ユニットＵ0 を表す地図を表示可能なデータ）を第１の記憶装置１９から主記憶に読み込む（ステップＳ２０６）。
【０１１２】
データ処理部１３は、以上のステップＳ２０６の後、図３５のフローチャートから抜けて、図３４のステップＳ１０４に進む。データ処理部１３は、主記憶上に読み込まれた地図ファイルＣＦを用いて、出発地ＳＰ側からの経路探索処理を行う（ステップＳ１０４）。ここで注意を要するのは、ダイクストラ法等の手法は周知であるため、その詳細な説明を省略する。ダイクストラ法等を簡単に説明すると、地図ファイルＣＦ内の道路ネットワークの接続をたどりながら最短ルートを求める処理が行われる。かかる地図ファイルＣＦ内でのノードＮとリンクＬの接続関係をたどる手順については、図３２を参照して前述の通りである。
【０１１３】
また、データ処理部１３は、ステップＳ１０２の後、ステップＳ１０３と並行して、ステップＳ１０５を実行する。データ処理部１３は、ステップＳ１０２で設定された目的地ＤＰ周辺の地図ファイルＣＦを第１の記憶装置１９から、自身の内部に有する主記憶（図示せず）に読み込む（ステップＳ１０５）。さらに、データ処理部１３は、ステップＳ１０５で読み込んだ地図ファイルＣＦを用いて、目的地ＤＰ側の経路探索処理を行う（ステップＳ１０６）。ここで、ステップＳ１０５およびＳ１０６の処理については、ステップＳ１０３およびステップＳ１０４と同様であるため詳細な説明は省略する。
【０１１４】
データ処理部１３は、ステップＳ１０４およびＳ１０６の処理が終了すると、当該ステップＳ１０４およびＳ１０６で使用された地図ファイルＣＦの階層での探索終了条件を満たしたか否かの判断を行う（ステップＳ１０７）。ステップＳ１０７では、一般的に、読み込んだ地図ファイルＣＦの数、または探索したノードＮの数等が所定の値に達しているか否かに基づいて、探索条件が終了したか否かが判断される。ステップＳ１０７において探索終了条件を満たしていないと判断された場合には、データ処理部１３は、ステップＳ１０３およびＳ１０５に戻って、出発地ＳＰ側および目的地ＤＰ側の双方からの探索処理で既に読み込まれている地図ファイルＣＦに隣接する地図ファイルＣＦを読み込む。ここで、既に読み込まれている地図ファイルＣＦがユニットＵの地図を表すとすると、隣接する地図ファイルＣＦは、隣接ユニットＮＵ（図２６参照）の地図を表すこととなる。データ処理部１３は、新たな代表点の経度座標ＬＯＮおよび緯度座標ＬＡＴを求めて、隣接する地図ファイルＣＦのパス名を導出し、当該パス名により特定される地図ファイルＣＦを第１の記憶装置１９から主記憶に読み込む。
【０１１５】
ここで、図３６に示すように、隣接ユニットＮＵを決定するための新しい代表点の位置は、道路網の接続をたどるリンクＬが、どのユニット境界上の隣接ノード（詳しくは図２６を参照）を経由して当該隣接ユニットＮＵ内のリンクＬと接続するかによって異なる。より具体的に説明すると、図３６のリンクＬ１１は、ユニットＵの境界（矩形）の上辺上に位置する隣接ノードＮ１２を経由して隣接ユニットＮＵ１のあるリンクＬと接続する。このため、ユニットＵの代表点Ｐの緯度座標ＬＡＴに対して、当該ユニットＵが属するレベルＬの緯度幅Ｈを加算した緯度座標ＬＡＴ１をもつ地点が新しい代表点Ｐ１と定められる。
【０１１６】
一方、図３６のリンクＬ１２は、ユニットＵの境界（矩形）の右辺上に位置する隣接ノードＮ１３を経由して隣接ユニットＮＵ２内のあるリンクＬと接続する。このため、ユニットＵの代表点Ｐの経度座標ＬＯＮに対して、当該ユニットＵが属するレベルＬの経度幅Ｗを加算した経度座標ＬＯＮ２をもつ地点が新しい代表点Ｐ２と定められる。
【０１１７】
２回目以降のステップＳ１０３およびＳ１０５では、データ処理部１３は、図３６を参照して説明したようにして求められた新しい代表点に基づいて、当該代表点を含む範囲を表す地図の地図ファイルＣＦを読み込む。なお、この際の処理手順は前述の通りである。次のステップＳ１０４およびＳ１０６では、データ処理部１３は、ステップＳ１０３およびＳ１０５で読み込んだ地図ファイルＣＦを使って探索処理を行う。かかる探索処理は、前回読み込んだ地図ファイルＣＦから今回読み込んだものへと、つまりユニットＵと隣接ユニットＮＵとの境界をまたいで道路網の接続をたどることを意味している。
【０１１８】
ところで、従来の技術では、ユニットＵおよび隣接ユニットＮＵの境界をまたいだ場合であっても、道路網の接続をたどることができるように、各地図ファイルの隣接ノードのレコードに、隣接ユニットＮＵの隣接ノードを特定する番号またはオフセットアドレス等が記録されていた。しかし、このような地図ファイルの内部データ構造に関わる情報を当該ユニットに記録してしまうと、隣接ユニットＮＵを表す地図ファイルが更新された場合、上記番号またはオフセットアドレスが変わってしまう場合がある。したがって、１つの地図ファイルが更新されることにより、その周囲のすべての隣接ユニットＮＵを表す地図ファイルが更新される必要が生じるおそれがあるという問題点があった。かかる問題点を解消すべく、本実施形態の各地図ファイルＣＦには、隣接ユニットＮＵの内部データ構造に直接関わる情報は記録されておらず、データ処理部１３は、ノードＮの座標情報および／またはリンクＬの属性情報を用いて、隣接ユニットＮＵの隣接ノードＮをたどる処理を実行する。
【０１１９】
以下、図３７および図３８の２つの図面を参照して、図３４のステップＳ１０４またはＳ１０６における、データ処理部１３がユニットＵと隣接ユニットＮＵの境界をまたいで道路網の接続をたどる処理について詳細に説明する。図３７は、互いに隣接し合う４個のユニットＵ１〜Ｕ４を並べた際に構成される道路網を示している。ユニットＵ１に含まれる道路網は、４個のノードＮ１０〜Ｎ１３と、３個のリンクＬ１０〜Ｌ１２とから構成される。ユニットＵ１では、３個のノードＮ１０、Ｎ１２およびＮ１３（●印参照）は隣接ノードであって、ユニットＵ１の境界上に位置する。また、ユニットＵ２に含まれる道路網は、５個のノードＮ２０〜Ｎ２４と、４個のリンクＬ２０〜Ｌ２３とから構成される。ユニットＵ２では、４個のノードＮ２０およびＮ２２〜２４（●印参照）は、隣接ノードであって、ユニットＵ２の境界上に位置する。また、ユニットＵ３に含まれる道路網は、４個のノードＮ３０〜Ｎ３３と、３個のリンクＬ３０〜Ｌ３２とから構成される。ユニットＵ３では、ノードＮ３０、Ｎ３２およびＮ３３（●印参照）が隣接ノードであり、ユニットＵ３の境界上に位置する。さらに、ユニットＵ４に含まれる道路網は、４個のノードＮ４０〜Ｎ４３と、３個のリンクＬ４０〜Ｌ４２とから構成される。３個のノードＮ４０〜Ｎ４３（●印参照）は、隣接ノードであって、ユニットＵ４の境界上に位置する。
さらに、図３７において、ノードＮ１３およびＮ２０が接続され、ノードＮ１２およびＮ３０が接続され、ノードＮ２４およびＮ４３が接続され、さらにノードＮ３３およびＮ４０が接続され、これによって、１つの道路網が構成される。
【０１２０】
以上の図３７の道路網において、リンクＬ１２は、隣接ノードＮ１３およびＮ２０を経由して、リンクＬ２０とつながっている。上述したように、経路探索処理において、データ処理部１３は、隣接ユニットＮＵを表す地図ファイルＣＦを順次読み込んで、目的地ＤＰまたは出発地ＳＰの方向へと探索を広げていく。そのためには、データ処理部１３は、あるユニットＵおよび隣接ユニットＮＵの境界をまたぐような２個のリンクＬの接続関係をたどる必要がある。そこで、まず、データ処理部１３は、主記憶上に読み込まれたユニットＵ（つまり、ユニットＵ１）の地図ファイルＣＦ（より具体的には、リンクレコードＲＲ（図３０および図３１参照））から、ユニットＵ１からユニットＵ２へと向かうリンクＬ１２のリンク属性を取り出す（図３８；ステップＳ３０１）。以下では、ユニットＵ１の境界へと向かうリンクＬ１２を脱出リンクＬ１２と呼ぶこととする。
【０１２１】
次に、データ処理部１３は、脱出リンクＬ１２の接続先情報（ノードレコード番号またはオフセットアドレス）を参照して、地図ファイルＣＦ（より具体的には、第１または第２のノードテーブル）から、当該脱出リンクＬ１２に接続された隣接ノードＮ１３のノードレコードＮＲ（図２７参照）を探し出す。その後、データ処理部１３は、探し出したノードレコードＮＲから、隣接ノードＮ１３のノード座標を取り出す（ステップＳ３０２）。以下では、脱出リンクＬ１２に接続された隣接ノードＮ１３を脱出ノードＮ１３と呼ぶこととする。
【０１２２】
次に、データ処理部１３は、主記憶上に読み込まれている隣接ユニットＮＵ（つまり、ユニットＵ２）の地図ファイルＣＦ（より具体的には、第１または第２のノードテーブル）から、ノード座標を１つずつ取り出す（ステップＳ３０３）。データ処理部１３は、ステップＳ３０２で取り出した脱出ノードＮ１３のノード座標と、ステップＳ３０３で取り出したノード座標との差分値を算出して、当該差分値が所定の閾値以下であるか否かを判断する（ステップＳ３０４）。ここで、図２９を参照して説明したように、本実施形態では、ノード座標は正規化された値で記録されている。上記所定の閾値としては、正規化された座標値の幅により異なるが、「１」〜「２」程度の値が好ましい。データ処理部１３は、ステップＳ３０４の条件を満たすまで、ステップＳ３０３およびＳ３０４を繰り返し実行する。ただし、データ処理部１３は、ステップＳ３０３を実行するたびに、過去に取り出したものとは異なるノード座標を取り出す。ここで、ステップＳ３０４の条件を満たすということは、ステップＳ３０３で取り出したノード座標を有するノードＮが脱出ノードＮ１３と同じ位置を示していることとなる。つまり、制御部１３は、ステップＳ３０３およびＳ３０４を繰り返し実行することにより、脱出ノードＮ１３とほぼ同じ位置を有する隣接ノードＮ２０を探し出すことができる。以下では、探し出された隣接ノードＮ２０を進入ノードと呼ぶこととする。
【０１２３】
ここで、一般的に、ステップＳ３０３においては、ノードレコード番号（図２８参照）の順番に従って、ノード座標が１つずつ順番に取り出される。本実施形態では、図２６および図２８を参照して説明したように、第１または第２のノードテーブルにおいて、隣接ノードＮのノードレコードＮＲは、非隣接レコードＮのノードレコードＮＲの前に記録されている。これによって、データ処理部１３は、非隣接ノードＮのノードレコードＮＲからノード座標を取り出すことなく、進入ノードを見つけ出すことができる。これによって、データ処理部１３が進入ノードを検索する処理の負荷を最小限に抑えることができる。すわなち、データ処理部１３は、隣接ユニットＮＵの地図ファイルＣＦに記録された第１および第２のノードテーブル内に並ぶ全てのノードレコードＮＲを検索しなくても、当該第１または第２のノードテーブルの先頭から隣接ノードの数だけノードレコードＮＲを検索すれば、必ず進入ノードを見つけ出すことができる。このように、本実施形態におけるノードレコードＮＲの並べ方は、進入ノードを検索する処理の高速化にも寄与する。
【０１２４】
また、隣接ノードのノードレコードＮＲは、図２６を参照して説明したように、ユニットＵ（矩形）の左辺→上辺→右辺→下辺という優先順位に従って並べられる。さらに、左辺および右辺上に位置する隣接ノードのノードレコードＮＲは緯度の昇順に並べられ、上辺および下辺上に位置する隣接ノードのノードレコードＮＲは経度の昇順に並べられる。また、非隣接ノードのレコードＮＲについては、まず緯度の昇順に並べられ、緯度が同一座標の複数の非隣接ノードのレコードＮＲについては経度の昇順に並べられる。かかる並べ方によって、進入ノードの検索処理をさらに高速化することができる。例えば、上記の並べ方の規則に従えば、図３９の隣接ノードＮ１０〜Ｎ２０のノードレコードＮＲは、Ｎ１０→Ｎ１１→Ｎ１２→Ｎ１３→Ｎ１４→Ｎ１５→Ｎ１６→Ｎ１７→Ｎ１８→Ｎ１９→Ｎ２０の順で、ユニットＵ１の地図ファイルＣＦ内に記録される。同様に、隣接ノードＮ２０〜Ｎ２７のノードテーブルＵ２のノードレコードＮＲは、Ｎ２０→Ｎ２１→Ｎ２２→Ｎ２３→Ｎ２４→Ｎ２５→Ｎ２６→Ｎ２７の順で、ユニットＵ２の地図ファイルＣＦ内に記録される。さらに、ユニットＵ３の地図ファイルＣＦ内には、ノードＮ３０→Ｎ３１→Ｎ３２→Ｎ３３→Ｎ３４→Ｎ３５→Ｎ３６→Ｎ３７→Ｎ３８の順にノードレコードＮＲが記録される。
【０１２５】
通常、経路探索処理では、読み込んだ地図ファイルＣＦ内で探索が広げられ、探索中のルートが隣接ノードに到達した際には、その対応する隣接ユニットＮＵが新たに読み込まれる。本実施形態では、隣接ユニットＮＵの地図ファイルＣＦが読み込まれた際に、まず前回読み込まれた地図ファイルＣＦと今回読み込まれた地図ファイルＣＦとの、ユニットの間の境界上に存在する全隣接ノードの対応付けが行われる。この際に、前述のようにノードテーブルにおいて、隣接ノードのノードレコードＮＲが、上述した順位で記録されることにより、隣接ノードの対応付けを高速化することができる。このため、例えば、ユニットＵ１の隣接ノードＮ１２と同じ位置を示すユニットＵ３の隣接ノードＮ３５が見つかれば、ユニット１の次の隣接ノードＮ１３に対応するユニット３の隣接ノードＮ３６は必ずＮ３５の次のレコードに並んでいる。また同様に、ユニット２の隣接ノードＮ２０に対応するユニット１の隣接ノードＮ１６が見つかれば、ユニット２の次の隣接ノードＮ２１に対応するユニット１の隣接ノードＮ１７は必ずＮ１６の次のレコードに並んでいる。このように、前述のような規則性に従って隣接ノードを並べることにより、隣接ユニット間における隣接ノードの検索処理を高速化することができる。
【０１２６】
さて、ステップＳ３０４で進入ノードが見つかると、データ処理部１３は、進入ノードＮ２０の接続先情報（ノードレコード番号またはオフセットアドレス）を参照して、ユニットＵ２の地図ファイルＣＦ（より具体的には、第１または第２のリンクテーブル）から、当該進入ノードＮ２０に接続されたリンクＬ２０のリンクレコードＬＲ（図３０および図３１参照）を探し出す。以下では、進入ノードＮ２０に接続されたリンクＬ２０を進入リンクＬ２０と呼ぶこととする。その後、データ処理部１３は、探し出したリンクレコードＬＲから、進入リンクＬ２０の属性情報を取り出す（ステップＳ３０５）。
【０１２７】
次に、データ処理部１３は、ステップＳ３０１で取り出した脱出リンクＬ１２の属性情報と、ステップＳ３０５から取り出した進入リンクＬ２０の属性情報が同じか否かを判断する（ステップＳ３０６）。データ処理部１３は、２つの属性情報が互いに異なると判断した場合、ステップＳ３０３に戻って、新しい進入ノードＮを探す。ここで、本実施形態では、図２を参照して説明したように、互いに異なる縮尺の地図を表すいくつかの地図ファイルＣＦが第１の記憶装置１９には格納されている。下位階層の地図ファイルＣＦは、詳細な道路網を表すことができるので、２つのノード座標の差分値が所定の閾値以下であれば、両ノードＮが同じ位置を示す確率が相対的に高くなる。しかしながら、上位階層の地図ファイルＣＦは粗い道路網しか表すことができないので、２つのノード座標の差分値が所定の閾値以下であっても、両ノードＮが同じ位置を示す確率は相対的に低くなる。本実施形態では、ステップＳ３０６において脱出リンクおよび進入リンクの属性を一致／不一致を判断することにより、データ処理部１３が、ある道路から別の道路をたどることなく、同じ１本の道路を正確にたどるようにしている。つまり、ステップＳ３０６の処理は、下位階層の地図ファイルＣＦに対して実行されなくともよい。
【０１２８】
データ処理部１３は、ステップＳ３０６で脱出リンクＬ１２および進入リンクＬ２０の属性情報が一致していると判断すると、１本の道路を正確にたどっているとみなして、図３８のフローチャートから抜けて、図３４のステップＳ１０７に進む。データ処理部１３は、今回の読み込み続けた地図ファイルＣＦの階層での探索終了条件を満たしたと判断した場合、出発地ＳＰ側の経路と目的地ＤＰ側の経路がつながったかどうかを判断する（ステップＳ１０８）。データ処理部１３は、出発地ＳＰ側と目的地ＤＰ側の経路とがつながっている場合には、両地点間の最短ルートが求まったと判断し、経路探索処理を終了する。一方、出発地ＳＰ側と目的地ＤＰ側との経路がまだつながっていない場合には、データ処理部１３は、ステップＳ１０９に進み、１つ上位の階層に移行して、広域かつ粗い道路網を表す地図ファイルＣＦを使って経路探索処理を続行する。
【０１２９】
次に、ある下位階層から上位階層への以降処理について詳細に説明する。この時、データ処理部１３は、下位階層における探索処理の終点となるノードＮ（探索中のルートの終点）から、上位階層の地図ファイルＣＦ内に存在しかつ同じ位置を示すノードＮへと移行する。したがって、データ処理部１３が上位階層への移行処理を確実に行うためには、上位階層の地図ファイルＣＦに含まれるすべてのノードＮが、その子ユニットＣＵの各ノードＮから必ず検索できる必要がある。
【０１３０】
従来では、かかる検索を実現するために、下位階層のノードＮと同じ位置を示すに上位階層のノードＮのノード番号やオフセットアドレス等がノードレコード内に記録されるという方法が採用されていた。しかし、このような上位階層の地図ファイルの内部データ構造に関わる情報が下位階層の地図ファイルに記録されると、上位階層の地図ファイルが更新された場合、下位階層の地図ファイルも更新されなければ、下位階層から上位階層への移行処理をスムーズに行えなくなるという問題点があった。そこで、本実施形態では、各地図ファイルＣＦには、上位階層の地図ファイルＣＦの内部データ構造に直接関わるような情報は記録されず、階層移行を行う際にノードの座標情報やリンクの属性情報が参照される。しかし、この場合、一般的に上位階層の地図ファイルＣＦが表す地図は、下位階層の地図ファイルＣＦが表す地図に比べて座標の分解能が低い。そのため、図４０に示すように、下位階層および上位階層の地図ファイルＣＦでは互いに異なる座標をもっていた２つのノードＮが、上位階層の地図ファイルＣＦにおける座標の丸め誤差のために、同一の座標をもってしまう可能性がある。したがって、ノード座標だけでは、下位階層のノードＮと一致する上位階層のノードＮを一意に特定することはできない。
【０１３１】
そこで、本実施形態では、ノード座標だけでなく、ノードレコードＮＲの記録順序（並び方）が利用される。すなわち、前述のように第１または第２のノードテーブルにおけるノードレコードＮＲの並びの順は、隣接ノード、非隣接ノード共に明確に規定されている。このため、座標の丸め誤差が生じるような上位階層のユニットＵにおいても、丸め誤差が生じる前の正規化経度緯度座標を利用して、座標の昇順でノードレコードＮＲが記録される。これによって、データ処理部１３は、下位階層のノードＮから、同じ位置を示しかつ上位階層の親ユニットＰＵに含まれるノードＮを検索する場合にも、下位階層ユニットＵ内に記録されているノードＮの内で、親ユニットＵにも記録されており、かつ上位階層で丸め誤差が生じた場合に同一座標になると考えられるノードＮの中から、ノードレコードＮＲの記録順序に基づいて、親ユニットＰＵ内で対応するノードＮを一意に特定することができる。
【０１３２】
より具体的には、前述のように地図ファイルＣＦでは、相対的に１階層上の親ユニットＰＵは、その子ユニットＣＵに対して、経度方向および緯度方向共に８倍のユニット幅を有する。その一方で、階層には関係なく、各ノードは、ユニットＵの経度方向および緯度方向共に８０００ｈ（１６ビット）で正規化した正規化座標をもつ。すなわち、親ユニットＰＵは子ユニットＣＵに対して、その座標分解能が、経度方向および緯度方向共に１／８であるということができる。このため、子ユニットＣＵの正規化経度および正規化緯度座標１６ビットの内、上位１３ビットが同じ値をもつノードＮは、その親ユニットＰＵにおいて同一の正規化座標をもつことになる。
【０１３３】
例えば、図４１に示すように、子ユニットＣＵに記録されている５つのノードＮａ、Ｎｂ、Ｎｃ、Ｎｄ、Ｎｅの正規化経度および正規化緯度座標１６ビットの内、その上位１３ビットが同じ値をもち、かつこの内の４つのノードＮａ、Ｎｃ、Ｎｄ、Ｎｅの親となるノードＮａ２、Ｎｃ２、Ｎｄ２およびＮｅ２が親ユニットＰＵに記録されている（各ノードレコードＮＲに、親ノードＰＵが存在することを示すフラグあるいはコードを記録している）とする。この場合、図４２に示すように、子ユニットＣＵのノードテーブルには、ノードＮａ、Ｎｂ、Ｎｃ、ＮｄおよびＮｅの５個のノードレコードＮＲは、緯度および経度の昇順に従って（前述）、Ｎａ→Ｎｂ→Ｎｃ→Ｎｄ→Ｎｅの順に記録されている。なお、この際、ノードＮａ、Ｎｂ、Ｎｃ、ＮｄおよびＮｅの５個のノードレコードＮＲは、ノードテーブル内で必ずしも連続しているわけではない。
【０１３４】
親ユニットＰＵのノードテーブルを作成する際には、上記５個のノードレコードＮＲの並びの順に基づいて、ノードＮａ、Ｎｃ、ＮｄおよびＮｅそれぞれに対応する親ノードＮａ２、Ｎｃ２、Ｎｄ２およびＮｅ２のノードレコードＮＲが、この順に記録（必ずしも連続して記録する訳ではない）される。この結果、下記のようにして、子ユニットＣＵに記録されているノードＮｄに対する、親ユニットＰＵにおける親ノードＮｄ２を特定することができる。最初に、子ユニットＣＵのノードＮｄは、ノードテーブルにおいて、その正規化座標１６ビットの内の上位１３ビットが同じノードＮで、かつ親ノードＮが存在するものの内の３番目のノードレコードＮＲに記録されている。次に、子ユニットＣＵにおけるノードＮｄの正規化座標から、親ユニットＰＵにおける正規化座標が算出される。次に、算出した正規化座標をもつノードＮが、親ユニットＰＵのノードテーブルから探し出される。その結果、図４１および図４２の例では、４つのノードＮａ２、Ｎｃ２、Ｎｄ２およびＮｅ２が検出される。次に、子ユニットＣＵのノードＮｄに対応する親ノードＮｄは、上述したように、これらノードＮａ２、Ｎｃ２、Ｎｄ２、Ｎｅ２の４つのノードの内の３番目に記録されているはずなので、ノードＮｄの親ノードはＮｄ２であることが分かる。
【０１３５】
以上のように、データ処理部１３は、上位階層に移行した後、その上位階層でステップＳ１０３からステップＳ１０８までの処理を繰り返し、出発地ＳＰ側と目的地ＤＰ側の探索がつながった時点で経路探索処理を終了する。
【０１３６】
以上のように、本願発明で用いる地図データは矩形領域で区切られたユニット単位でファイル化され、かつこれらの各ユニットには、同一階層内の隣接ユニット間においても、上下階層に存在する親子ユニット間においても、他ユニット内の内部データ構造に関係するようなレコード番号や記録アドレス等を一切記録していないため、任意の範囲、任意の階層のユニットファイルを置き換えることにより、地図データの更新を柔軟に行うことができる。
【０１３７】
「地図ファイルＣＦの送受信処理」
近年、センタ局２から端末装置１へと地図を提供するようなシステムが研究・開発がされている。かかるシステムにより、端末装置１は、必要な時に必要な地図を得ることができる。そのため、センタ局２の第２の記憶装置２４には、一般的に、端末装置１側の第１のデータベース１１１よりも大規模な第２のデータベース２５が準備されている。本実施形態では、第１のデータベース１１１および第２のデータベース２５には、上述したファイルシステムによりいくつかの地図ファイルＣＦが管理されている。そして、以下に説明するようにして、センタ局２および端末装置１とは地図ファイルＣＦの送信および受信を行う。
【０１３８】
まず、端末装置１はセンタ局２に地図ファイルＣＦの送信を要求する。図４３（ａ）は、端末装置１がある地図ファイルＣＦの送信をセンタ局２に要求する際の処理手順を示すフローチャートである。また、図４３（ｂ）は、図４３（ａ）の処理手順により送信される制御データとしての要求ＲＥＱのフォーマットを示す図である。端末装置１のユーザは、第１の記憶装置１９に、新しい地図ファイルＣＦを追加したい場合、または、古い地図ファイルＣＦを新しいものに更新したい場合、入力装置１１を操作して、地図の要求・受信機能を起動する。次に、ユーザは、出力装置１１０のディスプレイに表示されるメニュー画面に従いつつ、入力装置１１を操作して、必要な地図の範囲および階層（レベル）を入力する。入力装置１１は、ユーザの入力に応答して、地図の範囲および階層を示す情報をデータ処理部１３に出力し指定する（ステップＳ４０１）。ここで、地図の範囲の入力には、ディスプレイに表示される広域地図に対して所望の範囲をユーザが入力装置１１を用いて矩形領域で囲って指定したり、住所索引を使って地域をユーザが入力装置１１で指定したりする方法がある。
【０１３９】
データ処理部１３は、入力装置１１から出力された範囲および階層の情報が入力されると、当該範囲情報を経度・緯度座標に変換する。データ処理部１３は、経度・緯度座標および階層の情報を要求生成部１４に出力する。要求生成部１４は、入力された経度・緯度座標および階層の情報を用いて、図４３（ｂ）に示すフォーマットの要求ＲＥＱを生成する（ステップＳ４０２）。図４３（ｂ）において、要求ＲＥＱは、ユーザが必要とする地図ファイルＣＦの階層を示す情報と、当該地図ファイルＣＦが表す地図の範囲を特定する経度・緯度座標とから構成される。ここで、経度・緯度座標は、より具体的には、ユーザが広域地図を矩形領域で囲って指定する場合に、その左下経度座標、左下緯度座標、右上経度座標および右上緯度座標からなる。要求生成部１４は、生成した要求ＲＥＱを第１の送受信部１５に出力し、当該第１の送受信部１５は、アンテナ１６を通じて、入力された要求ＲＥＱをアップリンクＵＬに送出する（ステップＳ４０３）。
【０１４０】
次にセンタ局２における地図ファイルＣＦの送信処理について説明する。端末装置１から送出された要求ＲＥＱは、通信網３のアップリンクＵＬを通じて、センタ局２の第２の送受信部２１により受信される。第２の送受信部２１は、受信した要求ＲＥＱを受信要求解析部２２に出力する。ここで、図４４は、センタ局２が要求ＲＥＱの受信後に実行する処理手順を示すフローチャートである。受信要求解析部２２は、入力された要求ＲＥＱを解析して、解析結果を読み出し制御部２３に出力する。読み出し制御部２３は、解析結果により特定される地図ファイルＣＦを第２のデータベース２５から検索する（ステップＳ５０１）。ここで、要求ＲＥＱには、端末装置１が要求した地図ファイルＣＦの階層（レベル）、および当該地図ファイルＣＦが表す地図の左下経度座標、左下緯度座標、右上経度座標、および右上緯度座標が記述されている。そこで、受信要求解析部２２は、まず、要求ＲＥＱから左下経度座標および左下緯度座標を取り出し、当該左下経度座標および左下緯度座標を代表点として、図３５のフローチャートで示した処理手順に従って、要求された地図ファイルＣＦのパス名を導出する。
【０１４１】
次に、受信要求解析部２２は、導出したパス名を有する地図ファイルＣＦが第２の記憶装置２４に格納されているか否かを調べる（ステップＳ５０２）。地図ファイルＣＦが格納されていない場合、センタ局２は図４４の処理を終了する。一方、地図ファイルＣＦが格納されている場合、読み出し制御部２３は、受信要求解析部２２により導出されたパス名を受け取って、当該パス名に従って第２の記憶装置２４から、要求された地図ファイルＣＦを読み出す。読み出し制御部２３は、読み出した地図ファイルＣＦをパケット組み立て部２５のメモリに転送する。これによって、パケット組み立て部２５は、要求された地図ファイルＣＦを内部に読み込む（ステップＳ５０３）。パケット組み立て部２５は、読み込んだ地図ファイルＣＦを基にパケットＰを組み立てて（ステップＳ５０４）、第２の送受信部２１に出力する。第２の送受信部２１は、入力されたパケットＰをダウンリンクＤＬに送出する（ステップＳ５０５）。なお、ステップＳ５０４の詳細については後述される。
【０１４２】
ステップＳ５０５が終了すると、受信要求解析部２２は、要求ＲＥＱで指定される範囲の地図ファイルＣＦが第２のデータベース２５にさらに存在するか否かを調べるために、前回のステップＳ５０１で指定した代表点座標に、要求ＲＥＱで指定されるレベルの経度幅Ｗおよび緯度幅Ｈを加算して、当該加算値を、新しい代表点として設定する。さらに、受信要求解析部２２は、新しい代表点の経度座標および緯度座標が要求ＲＥＱで指定される右上経度座標および右上緯度座標を越えているか否かを判断する。新しい代表点の経度座標および緯度座標が右上経度座標および右上緯度座標を越えていなければ、センタ局２では、引き続きステップＳ５０２〜Ｓ５０５を処理が実行され、もう１つの地図ファイルＣＦを基に組み立てられたパケットＰが端末装置１に送信される。新しい代表点の経度座標および緯度座標が右上経度座標および右上緯度座標を越えていれば、要求された地図ファイルＣＦをすべて端末装置１に送信したとして、センタ局２は図４４の処理を終了する。
以上のステップＳ５０１〜Ｓ５０５を繰り返すことにより、センタ局２は、端末装置１が要求した通りのレベルおよび範囲の地図を表す地図ファイルＣＦを当該端末装置１に送信することができる。
【０１４３】
ここで、図４５は、地図ファイルＣＦからパケットＰが組み立てられるまでの過程における、各データの構造を示している。ステップＳ５０３の終了時点で、パケット組み立て部２５の内部には、図４５（ａ）に示すように、１つの地図ファイルＣＦが読み込まれている。パケット組み立て部２５は、ステップＳ５０４を実行する。ここで、図４６は、ステップＳ５０４の詳細な処理手順を示すフローチャートである。以下、図４５および図４６を参照して、パケット組み立て部２５の処理を詳細に説明する。最初に、パケット組み立て部２５は、内部に読み込んだ地図ファイルＣＦを基に、マスタデータＭＤを作成する（ステップＳ６０１）。マスタデータＭＤは、図４５（ｂ）に示すように、データヘッダＤＨとデータ部とから構成される。ここで図４７は、マスタデータＭＤの詳細な内部データ構造を示す。図４７において、データヘッダＤＨは、ユニットＩＤおよびバージョンコードから構成される。
ユニットＩＤは、このマスタデータＭＤの基礎となる地図ファイルＣＦを特定するためのコードである。バージョンコードは、このマスタデータＭＤの基礎となる地図ファイルＣＦのフォーマットバージョンおよびコンテンツバージョンを表すコードである。なおユニットＩＤ、バージョンコード共に地図ファイルＣＦのユニットヘッダ（図７参照）に格納されている情報であり、地図ファイルＣＦがパケット組み立て部２５に読み込まれた時点で、当該パケット組み立て部２５により取り出され保持される。なお、これらユニットＩＤとバージョンコードは、後述する端末装置１の処理において使用される。
【０１４４】
またマスタデータＭＤのデータ部には、地図ファイルＣＦそのものが設定される。ところで、地図ファイルＣＦは、前述したように、各種テーブルから構成される（図７参照）。これら各テーブルには互いに、他のテーブルを参照し合うような情報は記録されない。言い換えれば、端末装置１は各テーブルを独立的に使用することができる。例えば、図８（ａ）に示すように、端末装置１は、基本背景テーブルのみを出力装置１１０に表示することができる。つまり、各テーブルは、互いに分離可能なデータ構造を有する。そのため、データ部は、基本背景テーブル、基本文字記号テーブル、主要道ノードテーブル、主要道リンクテーブルの基本データ（つまり、大略的な地図を表すデータ）のみから構成されても良い。また、データ部は、詳細背景テーブル、詳細文字記号テーブル、細街路ノードテーブル、細街路リンクテーブルの詳細データのみから構成されても良い。以上のように、地図ファイルＣＦの一部分がデータ部に設定される場合がある。
【０１４５】
なお、図７に示すように、ユニットヘッダには、ユニットＩＤおよびバージョンコードが含まれる。このユニットＩＤおよびバージョンコードは、データヘッダＤＨ（図４７参照）に含まれる。したがって、マスタデータＭＤのデータ部に、ユニットＩＤおよびバージョンコードが設定されると、マスタデータＭＤ内に２個のユニットＩＤおよびバージョンコードが含まれることになる。そのため、このデータ部にはユニットＩＤとバージョンコードは含まれなくとも良い。
【０１４６】
パケット組み立て部２５は、以上のようにして生成されたマスタデータＭＤをｉ個に分割する。これによって、図４５（ｃ）のように、ｉ個のセグメントデータＳＤ１〜ＳＤｉが生成される（ステップＳ６０２）。このステップＳ６０２において、パケット組み立て部２５は、マスタデータＭＤに含まれるデータヘッダＤＨおよびデータ部（つまり地図ファイルＣＦ）を意識しない。つまり、いずれかのセグメントデータＳＤに、データヘッダＤＨの一部と、データ部の一部とが混在する場合も起こりうる。これらｉ個のセグメントデータＳＤには、番号（以降、セグメント番号と称す）が付加される。このセグメント番号は、セグメントデータ相互で重複せず、かつ連続する番号であることが好ましい。なぜなら、後述する端末装置１の処理が容易になるからである。
【０１４７】
さらに、パケット組み立て部２５は、ｉ個のセグメントデータＳＤ１〜ＳＤｉに、誤り訂正符号（または誤り検出符号）を付加する（ステップＳ６０３）。これによって、図４５（ｄ）に示すように、ｉ個のセグメントデータ（誤り訂正符号付き）ＳＤ１〜ＳＤｉが生成される。パケット組み立て部２５はさらに、各セグメントデータ（誤り訂正符号付き）ＳＤ１〜ＳＤｉをｊ個に分割する。これによって、図４５（ｅ）に示すように、１個のセグメントデータＳＤにつき、ｊ個のパケットが生成される（ステップＳ６０４）。以上の処理の結果、パケット組み立て部２５は、１つの地図ファイルＣＦを基に、全部でｉ×ｊ個のパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊを生成する。また、これらｉ×ｊ個のパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊにはそれぞれ、番号（以降、パケット番号と称す）が付加される。このパケット番号は、パケット毎で互いに重複しないようにかつ連続する番号であることが好ましい。なぜなら、後述する端末装置１の処理が容易になるからである。このパケット番号により、端末装置１は、別々に送信されるｉ×ｊ個のパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊが、すべて揃ったかどうかを容易に判断できるようになる。このステップＳ６０４が終了すると、パケット組み立て部２５は、サブルーチンである図４６の処理から抜けて、図４４の処理に戻る。そして、ステップＳ５０５の処理が行われる。以上の各パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊは、ステップＳ５０５において、第２の送受信部２１から、通信網３（ダウンリンクＤＬ）に順次送出され、端末装置１に送信される。
【０１４８】
次に、図４８のフローチャートを参照して、端末装置１における地図ファイルＣＦの受信手順について説明する。センタ局２より送信された各パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊは、通信網３を通じて、端末装置１のアンテナ１６に入力される。第１の送受信部１５は、アンテナ１６から出力されるパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊを順次受信する（ステップＳ７０１）。また、第１の送受信部１５は、図示しないバッファメモリを有する。第１の送受信部１５は、受信された各パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊを、バッファメモリに順次格納する。
パケット分解部１７は、第１の送受信部１５のバッファメモリに定期的にアクセスして、センタ局２により送信されたｉ×ｊ個のパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊがバッファメモリ内に揃っているか否かを判断する（ステップＳ７０２）。ステップＳ７０２の判断は、各パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊに付加されたパケット番号に基づいて行われる。より具体的には、パケット番号が連番であれば、パケット分解部１７は、１から（ｉ×ｊ）までのパケット番号が全て揃っているか否かを判断する。
【０１４９】
ステップＳ７０２で、パケットＰが全て揃っていない場合、パケット分解部１７はステップＳ７０３に進まず、ステップＳ７０１が再度実行される。その結果、第１の送受信部１５は、不足分のパケットＰをやがて受信する。
一方、ステップＳ７０２で、パケットＰが全て揃っている場合、パケット分解部１７は、ステップＳ７０３に進む。パケット分解部１７は、ステップＳ７０１で受信されたパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…ＰｉｊからマスタデータＭＤを分解（デアセンブリ）する（ステップＳ７０３）。ステップＳ７０３の間に、誤り訂正も必要に行われる。分解されたマスタデータＭＤはデータ処理部１３に出力される。データ処理部１３は、入力されたマスタデータＭＤを基に地図ファイルＣＦを作成して、作成した地図ファイルＣＦを読み出し／書き込み制御部１８と協働してを第１の記憶装置１９に格納する（ステップＳ７０４）。
【０１５０】
ステップＳ７０４の後、データ処理部２５は、受信すべき一連のパケットＰがまだあるか否かを判断する（ステップＳ７０５）。受信すべきパケットＰがある場合、ステップＳ７０１に戻り、パケットＰの受信処理が引き続き行われる。一方、受信すべきパケットＰがない場合には、図４８の処理を終了する。
ここで、図４９は、図４８のステップＳ７０３の詳細な処理手順を示すフローチャートである。また、図５０は、パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊから地図ファイルＣＦが作成されるまでの過程における各データの構造を示している。上述から明らかなように、図４８のステップＳ７０３が開始される時点で、第１の送受信部１５には、図５０（ａ）に示すように、一連のパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊが揃っている。パケット分解部１７は、第１の送受信部１５にバッファされているパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊから、処理すべきパケットＰを得る（ステップＳ８０１）。今、パケット分解部１７はパケットＰ１１，Ｐ１２，…，Ｐ１ｊを得ると仮定する。
【０１５１】
次に、パケット分解部１７は、ステップＳ８０１で得られた各パケットＰからパケット番号を外す。パケット分解部１７は、番号が外された各パケットＰを一まとめにして、図５０（ｂ）に示すように、１つのセグメントデータＳＤを復元する（ステップＳ８０２）。上述の仮定に従うと、パケットＰ１１，Ｐ１２，…，Ｐ１ｊが一まとめにされ、その結果、セグメントデータＳＤ１が復元される。各セグメントデータＳＤには誤り訂正符号（または誤り検出符号）が付加されている。ステップＳ８０２の次に、パケット分解部１７は、誤り訂正符号を利用して、復元されたセグメントデータ（誤り訂正符号付き）ＳＤに生じている可能性がある誤りを訂正する（ステップＳ８０３）。
次に、パケット分解部１７は、セグメントデータ（誤り訂正符号付き）ＳＤから誤り訂正符号を外し、これによって、図５０（ｃ）に示すように、セグメントデータ（誤り訂正符号なし）ＳＤが復元される（ステップＳ８０４）。復元されたセグメントデータＳＤは、パケット分解部１７の記憶領域に保持される。上述の仮定に従うと、セグメントデータＳＤ１に誤り訂正が施された後、パケット分解部１７の記憶領域に保持される。
【０１５２】
ステップＳ８０４の次に、パケット分解部１７は、第１の送受信部１５内に、処理すべきパケットＰが残っているか否かを判断する（ステップＳ８０５）。処理すべきパケットＰが残っている場合、パケット分解部１７はステップＳ８０１に戻って、ステップＳ８０１〜Ｓ８０４を行って、図５０（ａ）〜（ｃ）に示すように、パケットＰからセグメントデータＳＤを復元する。本説明では、図４９の処理の開始時点で、第１の送受信部１５には、（ｉ×ｊ）個のパケットＰがある。したがって、ステップＳ７０１〜Ｓ７０５で構成されるループはｉ回繰り返される。その結果、ｉ個のセグメントデータＳＤ１〜ＳＤｉが復元される。
このループが必要回数だけ繰り返されると、第１の送受信部１５内には、処理すべきパケットＰがなくなる。この状態で、ステップＳ８０５の判断が行われると、パケット分解部１７は、ステップＳ８０６に進む。処理すべきパケットＰがなくなった時点で、ｉ個のセグメントデータＳＤ１〜ＳＤｉがパケット分解部１７に保持される。また、上述したように、各セグメントデータＳＤ１〜ＳＤｉには、セグメント番号が付されている。パケット分解部１７は、このセグメント番号に従って、つまりセグメント番号が連続するように、セグメントデータＳＤ１〜ＳＤｉを順番に並べる。その後、セグメント番号は、各セグメントデータＳＤ１〜ＳＤｉから取り外される。パケット分解部１７は、セグメント番号が取り外されたセグメントデータＳＤ１〜ＳＤｉを一まとめにする。その結果、図５０（ｄ）に示すように、マスタデータＭＤが復元される（ステップＳ８０６）。復元されたマスタデータＭＤは、データ処理部１３に出力される（ステップＳ８０７）。
【０１５３】
なお、本地図提供システムに限らず、通信システムでは通信障害が起こりうる。したがって、端末装置１は、全てのセグメントデータＳＤを正しく復元できるとは限らない。ここで、正しく復元されたセグメントデータＳＤとは、センタ局２が生成したものと同じセグメントデータＳＤを意味する。例えば、セグメントデータＳＤ２が正しく復元されなかった場合であって、他のセグメントデータＳＤ１、ＳＤ３〜ＳＤｉが正しく復号された場合を想定する。かかる場合、パケット分解部１７は、セグメントデータＳＤ１、ＳＤ３〜ＳＤｉに付加された誤り訂正符号を利用して、セグメントデータＳＤ２を正しいものに復元することもできる。
【０１５４】
データ処理部１３は、マスタデータＭＤの入力に起因して、ステップＳ７０４を開始する。このステップＳ７０４は、上述したように、マスタデータＭＤから地図ファイルＣＦを作成する処理と、作成された地図ファイルＣＦを第１の記憶装置１９に格納するための処理である。ここで、図５１は、図４８のステップＳ７０４の詳細な処理の手順を示すフローチャートである。
まず、データ処理部１３は、入力されたマスタデータＭＤのデータヘッダＤＨから、ユニットＩＤを取り出す（ステップＳ９０１）。前述のようにユニットＩＤは、当該ユニットのパス名と相互に変換できるように付与されている。データ処理部１３は、取り出したユニットＩＤから、マスタデータＭＤ内の地図ファイルＣＦのパス名を導出する。
【０１５５】
データ処理部１３は、ステップＳ９０２で導出したパス名をもつ地図ファイルＣＦが既に、第１の記憶装置１９内に格納されているかどうかを判断する（ステップＳ９０３）。もし格納されていなければ、データ処理部１３は、マスタデータＭＤからデータヘッダＤＨを取り外して、地図ファイルＣＦを得る。そして、データ処理部１３は、導出したパス名および今回受信した地図ファイルＣＦとを読み出し／書き込み制御部１８に転送する。読み出し／書き込み制御部１８は、転送されてきたパス名に従って、今回受信した地図ファイルＣＦを第１の記憶装置１９に格納する。これによって、第１のデータベース１１１には、新しい地図ファイルＣＦが追加されることとなる。
【０１５６】
一方、ステップＳ９０３において、ステップＳ９０２で導出したパス名をもつ地図ファイルＣＦが、第１の記憶装置１９内に既に存在すると判断された場合の処理について説明する。この場合、データ処理部１３は、ステップＳ９０４に進んで、マスタデータＭＤのデータヘッダＤＨ内に格納されているバージョンコードを取り出す。さらに、データ処理部１３は、読み出し／書き込み制御部１８と協働して、ステップＳ９０２で導出したパス名を持つ地図ファイルＣＦを第１の記憶装置１９から読み込む。データ処理部１３は、第１の記憶装置１９から読み込んだ地図ファイルＣＦのユニットヘッダ内に記録されたバージョンコードを取り出し、ステップＳ９０４で取り出したバージョンコードと比較する。データ処理部１３は、マスタデータＭＤから取り出したバージョンコードの方が新しいと判断された場合には、ステップＳ９０６に進み、マスタデータＭＤのデータ部のみを取り出して、新しいバージョンの地図ファイルＣＦを第１の記憶装置１９に格納する。これによって、第１のデータベース１１１において、古い地図ファイルＣＦは、新しいものに更新される。
【０１５７】
逆に、データ処理部１３は、第１の記憶装置１９から読み込んだ地図ファイルＣＦの方が新しいと判断した場合には、受信したマスタデータＭＤを破棄する。つまり、今回受信した地図ファイルＣＦは第１の記憶装置１９には格納されない。
以上のように、本実施形態に係る地図ファイルＣＦは、複数の縮尺の地図をユニット単位で区切ってデジタルデータ化されることにより生成される。各地図ファイルＣＦの記録領域（論理領域）は、その親子関係および隣接関係を表すツリー構造で特定されるパス名で表現される。これによって、各地図ファイルＣＦは効率的に管理される。これによって、１つのユニットＵには、他のユニットのデータ構造に関連する情報が記録されないので、複数のユニットＵの間の関係が薄くなる。これによって、ある１つの地図ファイルＣＦを更新した場合であっても、それ以外の地図ファイルＣＦを更新する必要がなくなる。このように、本実施形態に係る地図ファイルＣＦによれば、第１の記憶装置１９における地図ファイルＣＦの新規格納処理および更新処理が非常に簡単になる。
【０１５８】
また、このような各地図ファイルＣＦにおいて、互いに隣接するユニットＵの境界をまたがる道路網の接続をたどる際に、データ処理部１３は、脱出ノードおよび進入ノードの座標情報、ならびに／もしくは脱出リンクおよび進入リンクの属性情報を参照する。つまり、データ処理部１３は、隣接ユニットＮＵに記録されたノードＮまたはリンクＬのレコード番号またはオフセットアドレスのような、隣接ユニットＮＵの内部データ構造に関わる情報を参照しない。そのため、第１の記憶装置１９内のある１つの地図ファイルＣＦが更新された場合においても、隣接ユニットＮＵの地図ファイルＣＦを更新することなく、互いに隣接し合う地図ファイルＣＦの道路網の接続を正確にたどることができる。
【０１５９】
また、本実施形態では、あるユニットＵおよび隣接ユニットＮＵの境界をまたがる道路網の接続をたどる際に、隣接ユニットＮＵ側の進入ノードおよび進入リンクを検索する必要が出てくる。しかしながら、各ユニットＵにおいて、ノードレコードＮＲおよびリンクレコードＬＲの並び方は予め規定されている。これによって、進入ノードおよび進入リンクの検索処理を高速化することができる。
【０１６０】
また、本実施形態では、経路探索処理において、データ処理部１３は、下位階層のあるノードＮから、それと同じ位置を示すノードＮを上位階層の地図ファイルＣＦから探し出す場合がある。この場合においても、上下階層のユニットＵの間においても、子ユニットＣＵ側に親ユニットＰＵの内部データ構造に関わる情報が記録されず、親ユニットＰＵ側に子ユニットＣＵの内部データ構造に関わるような情報が記録されないので、上位の階層の地図ファイルＣＦだけが更新されたような場合においても、その子ユニットＣＵを表す地図ファイルＣＦを全て更新するような必要性は生じない。
【０１６１】
また以上のように、ユニットＵのように部分的な領域の地図だけが新しいものに更新されたような場合においても、隣接ユニット間および上下階層間でのデータの整合性は保持されるため、センタ局２が端末装置１などに有線あるいは無線で地図ファイルＣＦを提供する場合においても、端末装置１が必要とする地図ファイルＣＦのみを送信することができる。これによって、データ送信時間および通信コストの低減につながる。
【０１６２】
なお、以上の実施形態は、端末装置１の一例としてカーナビゲーションシステムを想定して説明した。しかし、パーソナルコンピュータ内に地図ファイルＣＦのデータベースを作成して、当該パーソナルコンピュータが地図を表示したり、経路探索を行ったりするような用途にも、本実施形態は適用することができる。つまり、本実施形態は、移動可能な端末装置に限らず、据え置き型の端末装置にも適用することができる。
また、据え置き型の端末装置に対しては、通信網３は無線伝送路である必要性はなく、有線であってもよい。
【０１６３】
なお、本実施形態では、端末装置１は、センタ局２と通信網３を通して双方向通信を行って、ユーザが必要とする地図の範囲をセンタ局２に通知し、当該範囲に対応する地図ファイルＣＦを受信していた。しかし、センタ局２は、放送形式で、地図ファイルＣＦを端末装置１に送信してもよい。
【０１６４】
なお、本実施形態では、第１のデータベース１１１および第２のデータベース２５は、レベル「０」〜「３」までの４段階の階層構造を有する地図ファイルＣＦから構成されていた。しかし、第１のデータベース１１１および第２のデータベース２５は、４階層に限らず、何階層の地図ファイルＣＦから構成されても構わない。
また、本実施形態では、各階層地図は経度方向および緯度方向に等間隔に分割され、これによって矩形領域（ユニットＵ）が形成されていた。しかし、各階層の地図ファイルＣＦのデータ量がほぼ一定になるように、各階層地図は、経度方向および緯度方向に様々な間隔で分割されてもよい。ただし、この場合、各地図ファイルＣＦには、経度方向および緯度方向に沿う分割サイズを特定する情報を付加する必要がある。
【０１６５】
また、本実施形態では、地図ファイルＣＦは、ユニットＵ単位で作成されていた。しかし、地図ファイルＣＦは、複数のユニットＵと、当該複数のユニットＵを管理するための管理情報とから構成されてもよい。この場合、地図ファイルＣＦの更新の容易さを確保するために、１つの地図ファイルＣＦにまとめるユニットＵの個数は最大６４個程度で、かつまとめられたユニットＵを管理するための管理情報は複雑にならないようにすることが望ましい。
【０１６６】
また、１つの地図ファイルＣＦにおいて、隣接ノードのノードレコードＮＲは、当該ユニットＵの境界を一周するような順序で記録されてもよい。今、記録順序の一例として、隣接ノードのノードレコードＮＲは、ユニットＵの左下隅から時計周りの順序に従って記録されると仮定する。この仮定下では、図３９に示すユニットＵ１に含まれる隣接ノードのノードレコードＮＲは、「Ｎ１０」→「Ｎ１１」→「Ｎ１２」→「Ｎ１３」→「Ｎ１４」→「Ｎ１５」→「Ｎ１８」→「Ｎ１７」→「Ｎ１６」→「Ｎ２０」→「Ｎ１９」という順序で記録される。また、ユニットＵ３に含まれる隣接ノードのノードレコードＮＲは、「Ｎ３０」→「Ｎ３１」→「Ｎ３２」→「Ｎ３４」→「Ｎ３３」→「Ｎ３８」→「Ｎ３７」→「Ｎ３６」→「Ｎ３５」という順序で記録される。さらに、ユニットＵ２に含まれる隣接ノードのノードレコードＮＲは、「Ｎ２０」→「Ｎ２１」→「Ｎ２２」→「Ｎ２３」→「Ｎ２４」→「Ｎ２５」→「Ｎ２７」→「Ｎ２６」という順序で記録される。今、具体例として、データ処理部１３が、隣接ノードＮ１４およびＮ１５に対応する隣接ノードＮ３７およびＮ３８を検索する場合について説明する。上述したように、ユニットＵ１の地図ファイルＣＦでは隣接ノードＮ１４→Ｎ１５の順序でノードレコードＮＲは記録される。一方、ユニットＵ３の地図ファイルＣＦでは隣接ノードＮ３８→Ｎ３７の順序でノードレコードＮＲは記録される。したがって、データ処理部１３が隣接ノードＮ１４に対応する隣接ノードＮ３７を探し出せれば、隣接ノードＮ１５に対応する隣接ノードは、隣接ノードＮ３７のノードレコードＮＲの一つ手前に記録されている。そのため、データ処理部１３は、隣接ノードＮ１５に対応する隣接ノードをいち早く探し出すことができる。このように、隣接ノードのノードレコードＮＲがユニットＵの境界を一周するような順序で記録されることにより、あるユニットＮとその隣接ユニットとの境界上に並ぶ隣接ノードは、それぞれの地図ファイルＣＦにおいて互いに逆順に連続して並ぶこととなるので、データ処理部１３は、あるユニットの隣接ノートに対応する隣接ユニットの隣接ノードを高速に見つけることができる。
【０１６７】
「第２の実施形態」
図５２は、本発明の第２の実施形態に係る地図提供システムの構成を示す。本地図提供システムには、センタ局１０１と端末装置１０２とが収容される。センタ局１０１と端末装置１０２とは無線伝送路１０３により接続される。無線伝送路１０３には、センタ局１０１から端末装置１０２へのダウンリンクが少なくとも形成される。センタ局１０１は、地図サーバ１０１１と、アンテナ１０１２とを備える。地図サーバ１０１１には、第１の記憶装置１０１３と、読み出し制御部１０１４と、パケット組み立て部１０１５と、送信部１０１６とを含む。端末装置１０２は、典型的には、カーナビゲーションシステムであって、アンテナ１０２１と、受信部１０２２と、パケット分解部１０２４およびファイル管理部１０２５を含むデータ処理部１０２３と、第２の記憶装置１０２６とを備える。
【０１６８】
次に、センタ局１０１の構成を説明する。第１の記憶装置１０１３には、端末装置１０２に提供可能な地図ファイルＣＦが１つ以上蓄積される。地図ファイルＣＦの詳細は後述される。第１の記憶装置１０１３は、典型的には、ハードディスクドライブ、ＣＤ−ＲＯＭドライブまたはＤＶＤ−ＲＯＭドライブから構成される。
読み出し制御部１０１４は、必要に応じて第１の記憶装置１０１３から、地図ファイルＣＦの一部分を、端末装置１０２に提供すべき地図データＣＤとして読み出す。この地図データＣＤの詳細は後述される。読み出された地図データＣＤは、パケット組み立て部１０１５に出力される。
【０１６９】
パケット組み立て部１０１５は、入力された地図データＣＤを基にパケットＰを組み立てる（アセンブリする）。パケット組み立て部１０１５の詳細な処理およびパケットＰの形式は、後述される。組み立てられたパケットＰは送信部１０１６に出力される。
送信部１０１６は、入力されたパケットＰを、アンテナ１０１２を通じて無線伝送路１０３に送り出し、これによって、地図データＣＤはパケットＰとして端末装置１０２に送信される。送信部１０１６およびアンテナ１０１２は、典型的には、携帯電話等の移動体通信装置、もしくは、地上波デジタル放送または衛星デジタル放送等の放送装置により実現される。
【０１７０】
次に、端末装置１０２の構成について説明する。受信部１０２２は、センタ局１０１により送信されたパケットＰを、無線伝送路１０３を通じて受信する。アンテナ１０２１および受信部１０２２は、典型的には、携帯電話等の移動体通信装置、もしくは、地上波デジタル放送または衛星デジタル放送等の受信装置を用いて実現される。受信部１０２２は、受信したパケットＰをパケット分解部１０２４に出力する。
パケット分解部１０２４は、入力されたパケットＰを分解（デアセンブリ）して、地図データＣＤを復元する。復元された地図データＣＤはファイル管理部１０２５に出力される。
ファイル管理部１０２５は、入力された地図データＣＤを、予め定められた手順に従って処理する。この処理の手順は後述される。この処理により、地図ファイルＣＦが作成される。地図ファイルＣＦは、センタ局１０１側の地図ファイルＣＦ地図データと同様の構造を有する。地図ファイルＣＦの詳細は後述される。第２の記憶装置１０２６は、読み出しおよび書き込みが可能で、大容量の記憶媒体を有する。第２の記憶装置１０２６は、典型的には、ＨＤＤ、ＤＶＤ−ＲＡＭ駆動装置により構成される。この記憶媒体上に、ファイル管理部１０２５により生成された地図ファイルＣＦが書き込まれる。また、周知のように、第２の記憶装置１０２６はクラスタ単位で記憶領域を管理する。
【０１７１】
なお、データ処理部１０２３は、上記復号やファイル管理以外にも、様々な処理（例えば、経路探索、マップマッチングまたは経路案内）を行う。さらに、データ処理部１０２３は、必要に応じて、第２の記憶装置１０２６内の地図ファイルＣＦを部分的に取り出して、後述する出力装置に出力する。また、端末装置１０２は、図示された構成以外にも、入力装置および出力装置を備える。しかし、これらの処理、入力装置および出力装置は、本願発明のポイントではなく詳説されず、さらに図示もされない。
入力装置および出力装置を簡単に説明する。入力装置は、端末装置１０２のユーザにより操作される。ユーザは、入力装置を通じて、地図のスクロールまたは縮尺変更等を、端末装置１０２に対して要求する。また、出力装置は、主として、ディスプレイおよびスピーカから構成される。ディスプレイには、必要に応じて地図が表示される。さらに、ディスプレイには、データ処理部１０２３が行った経路探索処理または経路案内処理の結果も表示する場合がある。スピーカは、データ処理部１０２３が行った経路案内処理の結果を音声によりユーザに提供する。
【０１７２】
次に、図５３を参照して、各地図ファイルＣＦの構造を説明する。まず、図５３（ａ）のように、ある範囲の地図αは、予め定めされた形状（本実施形態では便宜上、矩形形状とされる）のＭ×Ｎ個（ＭおよびＮは任意の自然数）の領域に区画され、ユニットＵ0,0 〜ＵM-1,N-1 が作成される。ユニットＵ0,0 〜ＵM-1,N-1 はそれぞれデータ化され、ユニットデータＵＤ0,0 〜ＵＤM-1,N-1 が生成される。ユニットデータＵＤ0,0 〜ＵＤM-1,N-1 は、後述するユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 の一部を構成する。地図ファイルＣＦは、各ユニットＵ0,0 〜ＵM-1,N-1 を基に作成され、第１の記憶装置１０１３の所定アドレス領域に格納される。
【０１７３】
各地図ファイルＣＦは、図５３（ｂ）のように、ファイルヘッダＦＨと、ユニット管理情報ＭＩUNITと、Ｍ×Ｎ個のユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 とから構成される。ファイルヘッダＦＨには、地図ファイルＣＦ（地図α）がカバーする範囲を特定するための情報が記述される。より具体的には、ファイルヘッダＦＨは、最小の緯度ＬＡＴMIN および経度ＬＯＮMIN 、最大の緯度ＬＡＴMAX および経度ＬＯＮMAX 、緯度方向の実距離ＤLAT 、および経度方向の実距離ＤLON とを含む。ここで、ＬＡＴMIN 、ＬＯＮMIN 、ＬＡＴMAX およびＬＯＮMAX は、図５３（ａ）に示すように、地図αの最小緯度、最小経度、最大緯度および最大経度を示す。また、ＤLAT およびＤLON は、図５３（ａ）に示すように、地図αの緯度方向および経度方向の実際の距離を示す。このように、ＬＡＴMIN 、ＬＯＮMIN 、ＬＡＴMAX 、ＬＯＮMAX 、ＤLAT 、およびＤLON は、地図ファイルＣＦ（つまり地図α）がカバーする範囲を規定する。
ユニット管理情報ＭＩUNITには、各ユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 を管理するための情報が記述される。より具体的には、ユニット管理情報ＭＩUNITは、地図ファイルＣＦに含まれるユニットレコードの数ＮＯＵと、各ユニットレコードのオフセット値Ｘ0,0 〜ＸM-1,N-1 とを含む。ここで、ＮＯＵは、Ｍ×Ｎの値である。このオフセット値Ｘ0,0 〜ＸM-1,N-1 は、この地図ファイルＣＦが格納されている先頭のアドレス（第１の記憶装置１０１３における格納位置）から、各ユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 が格納される先頭アドレスまでのオフセットである。図５３（ｂ）には、ユニットレコードＵＲ0,0 のオフセット値Ｘ0,0 が例示されている。
【０１７４】
各ユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 は、ユニット管理情報ＭＩUNITのオフセット値Ｘ0 〜ＸN-1 により特定されるアドレスを基準にして、第１の記憶装置１０１３の記憶媒体に格納される。また、ユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 は、図５４のように、ユニットデータＵＤ0,0 〜ＵＤM-1,N-1 を含む。また、各ユニットデータＵＤ0,0 〜ＵＤM-1,N-1 には、ユニットヘッダＵＨ0,0 〜ＵＨM-1,N-1 が付加される。これによって、各ユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 が構成される。
以下、各ユニットレコードＵＲを具体的に説明するために、ユニットレコードＵＲ0,0 を例に採り上げる。まず、ユニットデータＵＤ0,0 は、図５３に示すように、地図αが区画された領域の一つをデータ化したものであり、対応するユニットＵ0,0 が表す領域の地図を構成する実データである。なお、以下、説明を明確にするため、ユニットＵ0,0 が表す領域の地図を地図β0,0 と記す。ユニットデータＵＤ0,0 は、より具体的には、地図β0,0 について、背景データＢＤ0,0 、文字記号データＣＤ0,0 、および道路ネットワークデータＮＤ0,0 から構成される。
【０１７５】
背景データＢＤ0,0 は、地図β0,0 上の河川、鉄道、緑地帯、建造物、橋等を表示するための図形データである。背景データＢＤ0,0 は、図５４に示すように、基本背景データテーブルＢＢＤ0,0 と、詳細背景データテーブルＤＢＤ0,0 とから構成される。基本背景データテーブルＢＢＤ0,0 には、図５５（ａ）に示すように、河川、鉄道および緑地帯等、地図β0,0 上の基本的な要素（つまり背景）を表示するための図形データが記録される。詳細背景データテーブルＤＢＤ0,0 には、地図β0,0 の基本的な背景をより詳細に表示するために、図５５（ｂ）のように、建造物、橋等の図形データが記録される。
【０１７６】
また、基本背景データテーブルＢＢＤ0,0 および詳細背景データテーブルＤＢＤ0,0 は、図５４に示すように互いに独立した構造を有する。これによって、センタ局１０１と端末装置１０２とは、基本背景データテーブルＢＢＤ0,0 および詳細背景データテーブルＤＢＤ0,0 を分離して、独立的に用いることが可能となる。つまり、端末装置１０２は、図５５（ａ）のように、基本背景データテーブルＢＢＤ0,0 を単体で表示することができる。さらに、端末装置１０２は、図５５（ｃ）のように、基本背景データテーブルＢＢＤ0,0 に詳細背景データテーブルＤＢＤ0,0 を重畳して表示することもできる。
また、地図β0,0 の背景は、基本背景データテーブルＢＢＤ0,0 が表示するものと、詳細背景データテーブルＤＢＤ0,0 が表示するものとが重畳されることにより構成される。つまり、見方を変えれば、詳細背景データテーブルＤＢＤ0,0 は、背景データＢＤ0,0 と、基本背景データテーブルＢＢＤ0,0 との差分データである。
【０１７７】
また、文字記号データＣＤ0,0 は、地図β0,0 上の文字列および／または地図記号を表すデータである。この文字記号データＣＤ0,0 により、地名、道路名称、施設名称、地図記号等が地図β0,0 上に表示される。文字記号データＣＤ0,0 は、図５４に示すように、基本文字記号データテーブルＢＣＤ0,0 と、詳細文字記号データテーブルＤＣＤ0,0 とから構成される。基本文字記号データテーブルＢＣＤ0,0 には、図５６（ａ）に示すように、地名、道路名称、地図記号等、地図β0,0 を構成するための基本的なデータが記録される。詳細文字記号データテーブルＤＣＤ0,0 には、図５６（ｂ）のように、公園、鉄道、橋および工場の名称等、地図β0,0 を詳細に表示するために必要なデータが記録される。
【０１７８】
また、基本文字記号データテーブルＢＣＤ0,0 および詳細文字記号データテーブルＤＣＤ0,0 は、図５４に示すように互いに独立した構造を有する。これによって、基本文字記号データテーブルＢＣＤ0,0 および詳細文字記号データテーブルＤＣＤ0,0 は独立的に用いられることが可能となる。つまり、端末装置１０２が、図５６（ａ）のように、基本文字記号データテーブルＢＣＤ0,0 を単体で表示したり、図５６（ｃ）のように、基本文字記号データテーブルＢＣＤ0,0 に詳細文字記号データテーブルＤＣＤ0,0 を重畳して表示したりできる。
また、詳細文字記号データテーブルＤＣＤ0,0 は、文字記号データＣＤ0,0 と、基本文字記号データテーブルＢＣＤ0,0 との差分データである。
【０１７９】
さらに、道路ネットワークデータＮＤ０，０ は、背景データＢＤ0,0 および文字記号データＣＤ0,0 と共に用いられ、地図β0,0 上に道路を表示するためのデータである。この道路ネットワークデータＮＤ0,0 はさらに、マップマッチング、経路探索または経路案内の各処理に使用される場合もある。道路ネットワークデータＮＤ0,0 は、主要幹線ネットワークデータテーブルＭＮＤ0,0 と細街路ネットワークデータテーブルＳＮＤ0,0 とから構成される。主要幹線ネットワークデータテーブルＭＮＤ0,0 には、図５７（ａ）に示すように、幅員が相対的に広い（例えば５．５ｍ以上）道路、つまり主要道路用の道路ネットワークデータが記録される。さらに、主要幹線ネットワークデータテーブルＭＮＤ0,0 には、道路ネットワークデータが、高速道路、一般国道および都道府県道等の道路種別毎に記録されることが好ましい。細街路ネットワークデータテーブルＳＮＤ0,0 には、図５７（ｂ）に示すように、幅員が相対的に狭い（例えば、３．０ｍ以上かつ５．５ｍ未満）道路、つまり細街路用の道路ネットワークデータが記録される。
【０１８０】
また、主要幹線ネットワークデータテーブルＭＮＤ0,0 および細街路ネットワークデータテーブルＳＮＤ0,0 もまた、基本背景データテーブルＢＢＤ0,0 および詳細背景データテーブルＤＢＤ0,0 と同様の独立的な構造を有している。そのため、端末装置１０２は、図５７（ａ）のように、主要幹線ネットワークデータテーブルＭＮＤ0,0 を単体で用いて、主要道路のみを表示させることができる。また、端末装置１０２は、図５７（ｂ）のように、細街路ネットワークデータテーブルＳＮＤ0,0 を単体で用いて、細街路のみを表示させることもできる。さらに、端末装置１０２は、図５７（ｃ）のように、主要幹線ネットワークデータテーブルＭＮＤ0,0 に細街路ネットワークデータテーブルＳＮＤ0,0 を重畳して用いて、主要道路および細街路を表示させたりすることができる。
また、細街路ネットワークデータテーブルＳＮＤ0,0 は、道路ネットワークデータＮＤ0,0 と、主要幹線ネットワークデータテーブルＭＮＤ0,0 との差分データである。
【０１８１】
なお、端末装置１０２は、マップマッチング処理等の際に、主要幹線ネットワークデータテーブルＭＮＤ0,0 を単独で用いたり、主要幹線ネットワークデータテーブルおよび細街路ネットワークデータテーブルＳＮＤ0,0 の両方を用いたりすることもできる。
また、主要道路と細街路との接続関係を辿る場合にも、主要幹線ネットワークデータテーブルＭＮＤ0,0 および細街路ネットワークデータテーブルＳＮＤ0,0 が用いられる。かかる接続関係を辿る場合、主要道路と細街路との交差点を示すノードが用いられる。
【０１８２】
また、図５８（ａ）のように、基本背景データテーブルＢＢＤ0,0 と、基本文字記号データテーブルＢＣＤ0,0 と、主要幹線ネットワークデータテーブルＭＮＤ0,0 とが重畳され、これによって、端末装置１０２は、相対的に粗い地図β0,0 を作成することができる。一方、詳細背景データテーブルＤＢＤ0,0 、詳細文字記号データテーブルＤＣＤ0,0 、および細街路ネットワークデータテーブルＳＮＤ0,0 が、図５８（ａ）のように構成された粗い地図β0,0 に重ね合わされることにより、図５８（ｂ）のような、より詳細な地図β0,0 を構成することができる。
【０１８３】
以上、ユニットデータＵＤ0,0 の詳細な構造について説明した。他のユニットデータＵＤ0,1 、…ＵＤ0,N-1 、ＵＤ1,0 、…ＵＤM-1,N-1 もまた、ユニットデータＵＤ0,0 と同様に、対応する範囲について、図５４〜図５８を参照して説明したような構造を有する。
【０１８４】
また、ユニットレコードＵＲ0,0 〜ＵＲM-1,N-1 は、上述したように、ユニットヘッダＵＨ0,0 〜ＵＨM-1,N-1 を含む。ユニットヘッダＵＨ0,0 〜ＵＨM-1,N-1 には、ユニットデータＵＤ0,0 〜ＵＤM-1,N-1 の属性情報が記述される。より具体的には、例えばユニットヘッダＵＨ0,0 には、ユニットデータＵＤ0,0 を特定するためユニットＩＤと、基本背景データテーブルＢＢＤ0,0 、詳細背景データテーブルＤＢＤ0,0 、基本文字記号データテーブルＢＣＤ0,0 、詳細文字記号データテーブルＤＣＤ0,0 、主要幹線ネットワークデータテーブルＭＮＤ0,0 および細街路ネットワークデータテーブルＳＮＤ0,0 のサイズとが記述される。他のユニットヘッダＵＨ0,1 〜ＵＨM-1,N-1 もまた、ユニットヘッダＵＨ0,0 と同様に、対応するユニットデータＵＤ0,1 〜ＵＤM-1,N-1 の属性情報が記述される。ユニットヘッダＵＨ0,0 〜ＵＨM-1,N-1 内の各ユニットＩＤは、対応するユニットデータＵＤ0,0 〜ＵＤM-1,N-1 を特定さえできれば、どのような情報でもよいが、連続番号または、経度および緯度等によりこれらを特定することが典型的である。
【０１８５】
次に、図５９のフローチャートを参照して、センタ局１０１における地図データの送信手順について説明する。上述したように、第１の記憶装置１０１３には、１つ以上の地図ファイルＣＦ（図５３および図５４参照）が予め格納されている。読み出し制御部１０１４は、必要に応じて、第１の記憶装置１０１３から、予め定められたいくつかの地図ファイルＣＦの一部またはすべてを読み出す（ステップＳ１００１）。ここで、地図ファイルＣＦの一部とは、本実施形態では、地図ファイルＣＦを構成するファイルヘッダＦＨ、ユニット管理情報ＭＩUNITおよびいくつかのユニットレコードＵＲを意味する。一方、地図ファイルＣＦのすべてとは、本実施形態では、地図ファイルＣＦを構成するファイルヘッダＦＨ、ユニット管理情報ＭＩUNITおよびすべてのユニットレコードＵＲを意味する。以下では、読み出し制御部１０１４により読み出された一部またはすべての地図ファイルＣＦを地図データＣＤと称する。読み出された地図データＣＤは、パケット組み立て部１０１５内の記憶領域（典型的にはＲＡＭ）に展開される。
【０１８６】
パケット組み立て部１０１５は、ステップＳ１００１の後、内部の記憶領域に展開された地図データＣＤから、端末装置１０２に送信するために必要なファイルヘッダＦＨ、ユニット管理情報ＭＩUNIT（図５３（ｂ）参照）および１つのユニットレコードＵＲ（図５３（ｂ）参照）を取り出す（ステップＳ１００２）。
【０１８７】
パケット組み立て部１０１５は、ステップＳ１００２で得られたユニットレコードＵＲ、ファイルヘッダＦＨ、およびユニット管理情報ＭＩUNITを基に、パケットＰを組み立てる（ステップＳ１００３）。なお、ステップＳ１００３の詳細な処理は後述される。組み立てられたパケットＰは、送信部１０１６に出力される。送信部１０１６は、入力されたパケットＰを、アンテナ１０１２を通じて無線伝送路１０３に送出して、パケットＰを端末装置１０２に送信する（ステップＳ１００４）。
【０１８８】
パケット組み立て部１０１５は、ステップＳ１００４の次に、内部の記憶領域に展開された地図データＣＤに、送信すべきユニットデータＵＤがさらに存在するか否かを判断する（ステップＳ１００５）。送信すべきユニットデータＵＤがまだ存在する場合には、パケット組み立て部１０１５は、必要なデータを得るために、ステップＳ１００２に戻る。一方、送信すべきユニットデータＵＤが存在しない場合には、パケット組み立て部１０１５は読み出し制御部１０１４にその旨を通知する。
【０１８９】
読み出し制御部１０１４は、パケット組み立て部１０１５の通知に応答して、ステップＳ１００１で読み出された地図データＣＤを閉じる（ステップＳ１００６）。次に、読み出し制御部１０１４は、端末装置１０２に送信すべきユニットデータＵＤを含む地図データＣＤ（ステップＳ１００６で閉じられたものとは別のもの）が存在するか否かを判断する（ステップＳ１００７）。別の地図データＣＤが存在する場合、読み出し制御部１０１４は、当該地図データＣＤを読み出すべく、ステップＳ１００１に戻る。一方、別の地図データＣＤがない場合には、センタ局１０１は、図５９のフローチャートに示された一連の処理を終了する。
【０１９０】
ここで、図６０は、地図データＣＤからパケットＰが生成されるまでの過程における、各データの構造を示している。
ステップＳ１００１（図５９参照）の終了時点で、読み出し制御部１０１４は、図６０（ａ）に示すように、地図データＣＤを読み出している。また、ステップＳ１００２の終了時点で、パケット組み立て部１０１５は、ファイルヘッダＦＨおよびいくつかのユニットレコードＵＲを保持している。図６０（ａ）では、ユニットレコードＵＲ0,0 が保持される例が示されている。そして、パケット組み立て部１０１５は、ステップＳ１００３を実行する。ここで、図６１は、ステップＳ１００３の詳細な処理の手順を示すフローチャートである。以下、図６１を参照して、パケット組み立て部１０１５の処理を詳細に説明する。最初に、マスタデータＭＤが、パケット組み立て部１０１５により保持されているファイルヘッダＦＨ、ユニット管理情報ＭＩUNIT、および１つのユニットレコードＵＲに基づいて生成される（ステップＳ１１０１）。なお、マスタデータＭＤは、地図ファイルＣＦから直接的に生成されるのではなく、パケット組み立て部１０１５が保持する１つのユニットレコードＵＲに基づいて生成される。かかる生成方法が採用されることにより、たとえ、図５９のステップＳ１００１〜Ｓ１００７において、外部的あるいは内部的要因によってエラーが発生しても、そのエラーの影響は、１個のユニットレコードＵＲにしか及ばないからである。つまり、エラーの影響が地図データＣＤ全体に及ぶことを避けるためである。
【０１９１】
マスタデータＭＤは、図６０（ｂ）に示すように、データヘッダＤＨとデータ部とから構成される。ここで、図６２は、マスタデータＭＤの詳細な構造を示す。図６２において、データヘッダＤＨは、ファイルＩＤ、ユニットＩＤおよびユニットサイズから構成される。
ファイルＩＤは、このマスタデータＭＤの基礎となる地図データＣＤ（つまり、現在、パケット組み立て部１０１５に展開されているもの）を特定するためのコードである。このファイルＩＤの生成方法の一例を説明する。パケット組み立て部１０１５は、ファイルヘッダＦＨを保持している。前述したように、ファイルヘッダＦＨには、地図ファイルＣＦ（地図α）がカバーする範囲を特定するための情報が記述される（図５３（ｂ）参照）。したがって、ファイルヘッダＦＨは、地図ファイルＣＦを特定することも可能である。パケット組み立て部１０１５は、このファイルヘッダＦＨを用いて、ファイルＩＤを生成する。
ユニットＩＤは、このマスタデータＭＤの基礎となるユニットレコードＵＲ（つまり、ステップＳ１００２で抜き出されたもの）を特定するためのコードである。パケット組み立て部１０１５は、ステップＳ１００２の終了以降、送信すべきユニットレコードＵＲ（図５４参照）を保持している。パケット組み立て部１０１５は、保持されたユニットレコードＵＲから、ユニットＩＤを取り出す。取り出されたユニットＩＤが、データヘッダＤＨに設定される。
なお、以上の２つのＩＤおよびユニットサイズは、後述する端末装置１０２の処理において使用される。
【０１９２】
また、マスタデータＭＤのデータ部には、ファイルヘッダＦＨと、ユニットレコードＵＲが有する全データまたは一部のデータが設定される。設定されるファイルヘッダＦＨおよびユニットレコードＵＲは、パケット組み立て部１０１５が保持しているものである。ところで、ユニットレコードＵＲには、前述したように、各種テーブルが保持される（図５４参照）。これら各テーブルは、互いに分離可能な構造を有する。そのため、データ部は、基本背景データテーブルＢＢＤ、基本文字記号データテーブルＢＣＤ、主要幹線ネットワークデータテーブルＭＮＤの基本データ（つまり、大略的な地図を表すデータ）のみから構成されても良い。また、データ部は、詳細背景データテーブルＤＢＤ、詳細文字記号データテーブルＤＣＤ、細街路ネットワークデータテーブルＳＮＤの詳細データのみから構成されても良い。以上のように、ユニットレコードＵＲの一部分がデータ部に設定される場合がある。
なお、図５４に示すように、ユニットヘッダＵＨには、ユニットＩＤが含まれる。このユニットＩＤは、データヘッダＤＨ（図６２参照）に含まれる。したがって、マスタデータＭＤのデータ部に、ユニットＩＤが設定されると、マスタデータＭＤ内に２個のユニットＩＤが含まれることになる。そのため、このデータ部にはユニットＩＤが含まれなくとも良い。
【０１９３】
ところで、データヘッダＤＨのデータサイズは、データ部のサイズである。ファイルヘッダＦＨと、ユニットレコードＵＲの全体とのサイズは、第１の記憶装置１０１３に地図ファイルＣＦが生成された時点で決まるので、容易に求められる。また、データ部に、部分的なユニットレコードＵＲが設定される場合には、対応するユニットヘッダＵＨに設定されている各サイズに基づいて、当該部分的なユニットレコードＵＲのサイズは求められる。
【０１９４】
パケット組み立て部１０１５は、生成されたマスタデータＭＤをｉ個に分割する。これによって、図６０（ｃ）のように、ｉ個のセグメントデータＳＤ1 〜ＳＤi が生成される（ステップＳ１１０２）。このステップＳ１１０２において、パケット組み立て部１０１５は、マスタデータＭＤに含まれるデータヘッダＤＨおよびデータ部（つまりユニットレコードＵＲ）を意識しない。つまり、いずれかのセグメントデータＳＤに、データヘッダＤＨの一部と、データ部の一部とが混在する場合も起こりうる。これらｉ個のセグメントデータＳＤには、番号（以降、セグメント番号と称す）が付加される。このセグメント番号は、セグメントデータ相互で重複せず、かつ連続する番号であることが好ましい。なぜなら、後述する端末装置１０２の処理が容易になるからである。
【０１９５】
さらに、パケット組み立て部１０１５は、ｉ個の各セグメントデータＳＤ1 〜ＳＤi に、誤り訂正符号（または誤り検出符号）を付加する（ステップＳ１１０３）。これによって、図６０（ｄ）に示すように、ｉ個のセグメントデータ（誤り訂正符号付き）ＳＤ1 〜ＳＤi が生成される。パケット組み立て部１０１５はさらに、各セグメントデータ（誤り訂正符号付き）ＳＤ1 〜ＳＤi をｊ個に分割する。これによって、図６０（ｅ）に示すように、１個のセグメントデータＳＤにつき、ｊ個のパケットが生成される（ステップＳ１１０４）。以上の処理の結果、パケット組み立て部１０１５は、ステップＳ１００２で抜き出された１つのユニットレコードＵＲを基に、全部でｉ×ｊ個のパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijを生成する。また、これらｉ×ｊ個のパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijにはそれぞれ、番号（以降、パケット番号と称す）が付加される。このパケット番号は、パケット毎で互いに重複しないようにかつ連続する番号であることが好ましい。なぜなら、後述する端末装置１０２の処理が容易になるからである。このパケット番号により、端末装置１０２は、別々に送信されるｉ×ｊ個のパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijが、すべて揃ったかどうかを容易に判断できるようになる。このステップＳ１１０４が終了すると、パケット組み立て部１０１５は、サブルーチンである図６１の処理から抜けて、図５９の処理に戻る。そしてステップＳ１００４が行われる。以上の各パケットＰ11、Ｐ12、…Ｐ1j、…Ｐijは、ステップＳ１００４において、送信部１０１６から、アンテナ１０１２を通じて無線伝送路１０３に順次送出され、端末装置１０２に送信される。
【０１９６】
次に、図６３のフローチャートを参照して、端末装置１０２における地図データの受信手順について説明する。センタ局により送信された各パケットＰ11、Ｐ12、…Ｐ1j、…Ｐijは、無線伝送路１０３を通じて、端末装置１０２のアンテナ１０２１に入力される。受信部１０２２は、アンテナ１０２１から出力されるパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijを順次受信する（ステップＳ１２０１）。また、受信部１０２２は、図示しないバッファメモリを有する。受信部１０２２は、受信された各パケットＰ11、Ｐ12、…Ｐ1j、…Ｐijを、バッファメモリに順次格納する。
【０１９７】
パケット分解部１０２４は、受信部１０２２のバッファメモリに定期的にアクセスして、センタ局１０１により送信されたｉ×ｊ個のパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijがバッファメモリ内に揃っているか否かを判断する（ステップＳ１２０２）。ステップＳ１２０２の判断は、各パケットＰ11、Ｐ12、…Ｐ1j、…Ｐijに付加されたパケット番号に基づいて行われる。より具体的には、パケット番号が連番であれば、パケット分解部１０２４は、１から（ｉ×ｊ）までのパケット番号が全て揃っているか否かを判断する。
【０１９８】
ステップＳ１２０２で、パケットＰが全て揃っていない場合、パケット分解部１０２４はステップＳ１２０３に進まず、ステップＳ１２０１が再度実行される。その結果、受信部１０２２は、不足分のパケットＰを受信する。
一方、ステップＳ１２０２で、パケットＰが全て揃っている場合、パケット分解部１０２４は、ステップＳ１２０３に進む。パケット分解部１０２４は、ステップＳ１２０１で受信されたパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijを分解して、マスタデータＭＤを復元する（ステップＳ１２０３）。復元されたマスタデータＭＤはファイル管理部１０２５に出力される。ファイル管理部１０２５は、入力されたマスタデータＭＤを基に地図ファイルＣＦを生成する。生成された地図ファイルＣＦは第２の記憶装置１０２６に格納される（ステップＳ１２０４）。
【０１９９】
ステップＳ１２０４の後、データ処理部１０２３は、受信すべき一連のパケットＰがまだあるか否かを判断する（ステップＳ１２０５）。受信すべきパケットＰがある場合、ステップＳ１２０１に戻り、パケットＰの受信処理が引き続き行われる。一方、受信すべきパケットＰがない場合には、図６３の処理を終了する。
【０２００】
ここで、図６４は、図６３のステップＳ１２０３の詳細な処理の手順を示すフローチャートである。また、図６５は、パケットＰ11、Ｐ12、…Ｐ1j、…Ｐijから地図ファイルＣＦが生成されるまでの過程における各データの構造を示している。上述から明らかなように、図６３のステップＳ１２０３が開始される時点で、受信部１０２２には、図６５（ａ）に示すように、一連のパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijが揃っている。パケット分解部１０２４は、受信部１０２２に保持されているパケットＰ11、Ｐ12、…Ｐ1j、…Ｐijから、処理すべきパケットＰを得る（ステップＳ１３０１）。今、パケット分解部１０２４はパケットＰ11、Ｐ12、…Ｐ1jを得ると仮定する。
【０２０１】
次に、パケット分解部１０２４は、ステップＳ１３０１で得られた各パケットＰからパケット番号を外す。パケット分解部１０２４は、番号が外された各パケットＰを分解して、図６５（ｂ）に示すように、１つのセグメントデータＳＤを復元する（ステップＳ１３０２）。上述の仮定に従うと、パケットＰ11、Ｐ12、…Ｐ1jが一まとめにされ、その結果、セグメントデータＳＤ１
が復元される。
各セグメントデータＳＤには誤り訂正符号（または誤り検出符号）が付加されている。ステップＳ１３０２の次に、パケット分解部１０２４は、誤り訂正符号を利用して、復元されたセグメントデータ（誤り訂正符号付き）ＳＤに生じている可能性がある誤りを訂正する（ステップＳ１３０３）。
次に、パケット分解部１０２４は、セグメントデータ（誤り訂正符号付き）ＳＤから誤り訂正符号を外し、これによって、図６５（ｃ）に示すように、セグメントデータ（誤り訂正符号なし）ＳＤが復元される（ステップＳ１３０４）。復元されたセグメントデータＳＤは、パケット分解部１０２４の記憶領域に保持される。上述の仮定に従うと、セグメントデータＳＤ1 に誤り訂正が施された後、パケット分解部１０２４の記憶領域に保持される。
【０２０２】
ステップＳ１３０４の次に、パケット分解部１０２４は、受信部１０２２内に、処理すべきパケットＰが残っているか否かを判断する（ステップＳ１３０５）。処理すべきパケットＰが残っている場合、パケット分解部１０２４はステップＳ１３０１に戻って、ステップＳ１３０１〜Ｓ１３０４を行って、図６５（ａ）〜（ｃ）に示すように、パケットＰからセグメントデータＳＤを復元する。本説明では、図６４の処理の開始時点で、受信部１０２２には、（ｉ×ｊ）個のパケットＰがある。したがって、ステップＳ１２０１〜Ｓ１２０５で構成されるループはｉ回繰り返される。その結果、ｉ個のセグメントデータＳＤ1 〜ＳＤi が復元される。
【０２０３】
このループが必要回数だけ繰り返されると、受信部１０２２内には、処理すべきパケットＰがなくなる。この状態で、ステップＳ１３０５の判断が行われると、パケット分解部１０２４は、ステップＳ１３０６に進む。処理すべきパケットＰがなくなった時点で、ｉ個のセグメントデータＳＤ1 〜ＳＤi がパケット分解部１０２４に保持される。また、上述したように、各セグメントデータＳＤ１ 〜ＳＤｉ
には、セグメント番号が付されている。パケット分解部１０２４は、このセグメント番号に従って、つまりセグメント番号が連続するように、セグメントデータＳＤ１ 〜ＳＤｉ
を順番に並べる。その後、セグメント番号は、各セグメントデータＳＤ１ 〜ＳＤｉ
から取り外される。パケット分解部１０２４は、セグメント番号が取り外されたセグメントデータＳＤ１ 〜ＳＤｉ
を一まとめにする。その結果、図６５（ｄ）に示すように、マスタデータＭＤが復元される（ステップＳ１３０６）。復元されたマスタデータＭＤは、ファイル管理部１０２５に出力される（ステップＳ１３０７）。
【０２０４】
なお、本地図提供システムに限らず、通信システムでは通信障害が起こりうる。したがって、端末装置１０２は、全てのセグメントデータＳＤを正しく復元できるとは限らない。ここで、正しく復元されたセグメントデータＳＤとは、センタ局１０１が生成したものと同じセグメントデータＳＤを意味する。例えば、セグメントデータＳＤ2 が正しく復元されなかった場合であって、他のセグメントデータＳＤ1 、ＳＤ3 〜ＳＤi が正しく復号された場合を想定する。かかる場合、パケット分解部１０２４は、セグメントデータＳＤ1 、ＳＤ3 〜ＳＤi
に付加された誤り訂正符号を利用して、セグメントデータＳＤ2 を正しいものに復元することもできる。
【０２０５】
ファイル管理部１０２５は、マスタデータＭＤの入力に起因して、ステップＳ１２０４を開始する。このステップＳ１１０４は、上述したように、マスタデータＭＤから地図ファイルＣＦを生成する処理と、生成された地図ファイルＣＦを第２の記憶装置１０２６に格納するための処理である。ここで、図６６は、図６３のステップＳ１２０４の詳細な処理の手順を示すフローチャートである。
【０２０６】
ところで、第２の記憶装置１０２６は、ステップＳ１２０４の開始時点で、以前に生成された地図ファイルＣＦを既に記憶していることがある。また、地図ファイルＣＦが記憶されていない場合もある。ファイル管理部１０２５は、マスタデータＭＤの入力後、第２の記憶装置１０２６内に地図ファイルＣＦが格納されているか否かを判断する（ステップＳ１４０１）。ファイル管理部１０２５は、地図ファイルＣＦがある場合、後述するステップＳ１４０４に進む。一方、ファイル管理部１０２５は、地図ファイルＣＦが無い場合、今回のマスタデータＭＤを基に、完全に新規な地図ファイルＣＦを作成する（ステップＳ１４０２）。なお、この地図ファイルＣＦは、地図ファイルＣＦと同様のデータ構造を有する（図５３（ｂ）および図５４参照）。
【０２０７】
ここで、地図ファイルＣＦの作成方法を説明する。マスタデータＭＤは、図６２に示したように、地図ファイルＩＤ、ユニットＩＤおよびデータサイズをデータヘッダＤＨに有する。さらに、このマスタデータＭＤは、ファイルヘッダＦＨと、全部または一部のユニットレコードＵＲをデータ部に有する。ファイル管理部１０２５は、マスタデータＭＤから、ファイルヘッダＦＨを取り出す。
【０２０８】
前述したように、マスタデータＭＤには１個のユニットレコードＵＲしか含まれない。また、ファイル管理部１０２５は、今回、完全に新規な地図ファイルＣＦを生成する。そのため、ファイル管理部１０２５は、初期値「１」のユニット数ＮＯＵを生成する。さらに、ファイル管理部１０２５は、ファイルヘッダＦＨおよびユニット数ＮＯＵのデータサイズとから、今回得られたユニットレコードＵＲまでのオフセット値Ｘ0,0 を求める。これによって、ユニット管理情報ＭＩUNITが生成される。
【０２０９】
これによって、ファイル管理部１０２５は、完全に新規な地図ファイルＣＦを生成するために必要な情報を全て得たこととなる。ファイル管理部１０２５は、今回得られたファイルヘッダＦＨ、ユニット管理情報ＭＩUNITおよびユニットレコードＵＲを一まとめにして、地図ファイルＣＦを生成する。この地図ファイルＣＦのデータ構造は、図６７に示す通りである。以上のようにして生成された地図ファイルＣＦは、第２の記憶装置１０２６内に格納される（ステップＳ１４０３）。
【０２１０】
次に、ステップＳ１４０１で、地図ファイルＣＦが見つけられた場合の処理について説明する。この場合、ステップＳ１４０４が行われる。ファイル管理部１０２５は、今回入力されたマスタデータＭＤから、ファイルＩＤを取り出す。ファイルＩＤは、前述したように、マスタデータＭＤ内のユニットレコードＵＲがどの地図ファイルＣＦに属していたかを特定する。このファイルＩＤは、図６１を参照して前述したように、パケット組み立て部１０１５により、地図ファイルＣＦのファイルヘッダＦＨを用いて生成されている。
また、ファイル管理部１０２５は、第２の記憶装置１０２６内の各地図ファイルＣＦのファイルヘッダＦＨを取り出す。ファイルヘッダＦＨは、地図ファイルＣＦがカバーする範囲を特定するものである。地図ファイルＣＦのファイルヘッダＦＨは、ステップＳ１４０２で説明したように、センタ局１０１側で管理される地図ファイルＣＦを基に作成されている。
したがって、ファイルＩＤとファイルヘッダＦＨとに同一性があれば、今回入力されたユニットレコードＵＲは、地図ファイルＣＦの一部を構成することとなる。そのため、ファイル管理部１０２５は、両者の同一性を判断する（ステップＳ１４０４）。
【０２１１】
ステップＳ１４０４で、同一性が無いと判断されると、入力されたユニットレコードＵＲを構成要素とする地図ファイルＣＦがまだ作成されていないことを意味する。この場合、ファイル管理部１０２５は、上述のステップＳ１４０２およびＳ１４０３を実行する。つまり、全く新規な地図ファイルＣＦが生成された後に、第２の記憶装置１０２６に格納される。
【０２１２】
一方、ステップＳ１４０４で、ファイルＩＤおよびファイルヘッダＦＨに同一性があると判断されると、入力されたユニットレコードＵＲを構成要素とする地図ファイルＣＦが既に生成されていることを意味する。この場合、ファイル管理部１０２５は、この地図ファイルＣＦを処理対象として選択する。ファイル管理部１０２５は、この処理対象の地図ファイルＣＦを開き（ステップＳ１４０５）、入力されたユニットレコードＵＲを、処理対象として選択された地図ファイルＣＦに追加する（ステップＳ１４０６）。つまり、ステップＳ１４０６では、入力されたユニットレコードＵＲと、地図ファイルＣＦとが一まとめにされ、更新された地図ファイルＣＦが生成される。
【０２１３】
ステップＳ１４０６について、より詳細に説明する。ファイル管理部１０２５は、今回のマスタデータＭＤから、ユニットＩＤを取り出す。以降、入力されたマスタデータＭＤから取り出されたユニットＩＤを、第１のユニットＩＤと称す。第１のユニットＩＤは、図６２を参照して説明したように、今回入力されたマスタデータＭＤの基礎となったユニットレコードＵＲを特定する。また、ファイル管理部１０２５は、ステップＳ１４０５で開かれた地図ファイルＣＦから、全てのユニットＩＤを取り出す。以降、地図ファイルＣＦから取り出された各ユニットＩＤを、第２のユニットＩＤと称す。第２のユニットＩＤの中には、第１のユニットＩＤと一致するものが含まれていない場合と、一致するものが含まれている場合がある。
【０２１４】
第１および第２のユニットＩＤが一致しない場合、ファイル管理部１０２５は、今回入力されたマスタデータＭＤから、ユニットレコードＵＲを取り出して、図６８に示すように、現在開かれている地図ファイルＣＦに追加して、当該地図ファイルＣＦを更新する。
第１および第２のユニットＩＤが一致する場合、今回入力されたユニットレコードＵＲは、過去に、センタ局１０１により、端末装置１０２に提供されていることとなる。例えば、図５４に示す構造をもつユニットレコードＵＲにおいて、基本背景データテーブルＢＢＤ、基本文字記号データテーブルＢＣＤ、主要幹線ネットワークデータテーブルＭＮＤ等の基本データ（概略データ）のみが、ステップＳ１２０４の時点で、端末装置１０２に既に提供されているような場合がある。この場合、現在開かれている地図ファイルＣＦは、図６９のような構造を有する。ファイル管理部１０２５は、この場合、図７０に示すように、今回入力されたマスタデータから取り出されたユニットレコードＵＲを、現在開かれている地図ファイルＣＦにおいて、同じユニットＩＤが付されているユニットレコードＵＲに追加する。これによって、地図ファイルＣＦが更新される。
【０２１５】
ファイル管理部１０２５は、さらに、今回入力されたマスタデータＭＤのデータサイズに従って、ユニット管理情報ＭＩUNITを更新する（ステップＳ１４０７）。次に、ファイル管理部１０２５は、更新された地図ファイルＣＦを、第２の記憶装置１０２６に格納する（ステップＳ１４０８）。
【０２１６】
以上のように、本地図提供システムでは、第１の記憶装置１０１３には、地図ファイルＣＦが格納される。パケット組み立て部１０１５は、端末装置１０２に送信すべき部分的な地図のみを読み出し制御部１０１４から受け取り、当該地図を表す一連のパケットＰを生成する。この一連のパケットＰが、無線伝送路１０３上を伝送される。この無線伝送路１０３上には、部分的な地図を表すデータしか送信されない。そのため、本地図提供システムは、たとえ、地図ファイルＣＦ自体が大きなサイズであっても、無線伝送路１０３に送出するデータの量を抑えることができる。これによって、無線伝送路１０３は輻輳しにくくなる。
【０２１７】
また、端末装置１０２は、部分的な地図を表すデータを順次受信することになる。しかし、端末装置１０２は、初期的には、部分的な地図データを個別にファイル化することになる。しかし、端末装置１０２は、所定条件を満たす地図ファイルＣＦが存在する場合には、受信された部分的な地図データを、当該地図ファイルＣＦに追加して、一まとめにする。そのため、本地図提供システムは、端末装置１０２において、大量のファイルが発生することを抑えることができる。そのため、第２の記憶装置１０２６内には、空き領域を有するクラスタが生じにくくなる。その結果、本地図提供システムは、第２の記憶装置１０２６の記憶領域を有効的に利用することができる。
【０２１８】
また、地図ファイルＣＦは、図５３に示すように、予め定められた範囲の地図αが複数の領域に区画されることにより、つまり、ユニットＵ単位で構成される。このような地図αのユニット化により、読み出し制御部１０１４は、必要な部分の地図を容易に第１の記憶装置１０１３から読み出すことができる。さらに、このユニット化により、センタ局１０１は、無線伝送路１０３が輻輳しない最適量のデータを容易に当該無線伝送路１０３に送出することができる。
さらに、センタ局１０１が複数のユニットレコードＵＲを送信した場合であっても、通信エラーにより、端末装置１０２は、いずれかのユニットレコードＵＲを受信できない場合がある。このような場合、端末装置１０２は、受信できたユニットレコードＵＲを用いて地図ファイルＣＦを作成する。端末装置１０２は、作成された地図ファイルＣＦに基づいて各種処理を行える。つまり、センタ局１０１から送信されたユニットレコードＵＲの一部が抜けても、その抜けによる影響は、端末装置１０２が受信した他のユニットレコードには及ばない。かかる効果も、地図のユニット化により生まれる。
【０２１９】
また、ユニットレコードＵＲ内において、地図の基本的なデータ（概略データ）と、当該地図の詳細なデータとは、互いに独立した複数のテーブルに記述される。これによって、各テーブルは、たとえ、１ユニットレコードＵＲ内に格納されていても、独立的に使用されることが可能となる。つまり、例えば、センタ局１０１は、端末装置１０２に地図を提供する際に、基本データ（概略データ）を単独で送信したり、詳細データを単独で送信したり、双方を組み合わせて送信したりすることが可能となる。これによって、センタ局１０１は、端末装置１０２の状況や用途に適した地図を提供することが可能になる。
【０２２０】
例えば、端末装置１０２側が、詳細な地図よりも、広範囲の地図を速く受信したい場合には、センタ局１０１は、基本データ（概略データ）だけを優先的に送信することができる。さらに、端末装置１０２が基本データ（概略データ）を完全に受信した後に、センタ局２が詳細データを送信することもできる。これによって、端末装置１０２は、基本データ（概略データ）と詳細データとを混在させて使用することも可能になる。
【０２２１】
なお、前述したように、送信部１０１６および受信部１０２２として、前述したように、移動体通信装置を用いることも可能である。この場合、センタ局１０１と端末装置１０２との双方向通信を容易に実現できるので、端末装置１０２は、提供を希望する地図の種別（概略データか詳細データかを示す情報）を、センタ局１０１に対してリアルタイムに要求することができる。
また、送信部１０１６および受信部１０２２として、地上波ディジタル放送等の放送装置および、この放送を受信する装置を用いることも可能である。この場合、センタ局１０１は、互いに異なるチャンネルを用いて、基本データ（概略データ）と詳細データとに異なるチャンネルを割り当てることにより、基本データ（概略データ）と詳細データとの受信時間、および受信可能な地図の範囲を調節することができる。
【０２２２】
なお、以上の実施形態では、第２の記憶装置１０２６側の地図ファイルＣＦのファイルヘッダＦＨは、第１の記憶装置１０１３側の地図ファイルＣＦ内のそれをそのまま用いられていた。つまり、双方地図ファイルＣＦは、互いに同範囲をカバーする。しかしながら、センタ局１０１と端末装置１０２との処理能力は違う場合が多い。例えば、第２の記憶装置１０２６の記憶容量は、第１の記憶装置１０１３のそれよりも小さい場合が多い。したがって、端末装置１０２は、地図ファイルＣＦが表す地図の範囲よりも、狭い範囲をカバーする地図ファイルＣＦを生成してもよい。つまり、端末装置１０２は、独自の範囲をカバーする地図ファイルＣＦを生成しても良い。
【０２２３】
なお、第２の実施形態は、端末装置１０２の一例としてカーナビゲーションシステムを想定して説明した。しかし、パーソナルコンピュータ内に地図ファイルＣＦのデータベースを作成して、当該パーソナルコンピュータが地図を表示したり、経路探索を行ったりするような用途にも、本実施形態は適用することができる。つまり、本発明の技術分野は、移動可能な端末装置に限らず、据え置き型の端末装置にも適用することができる。
また、据え置き型の端末装置に対しては、通信網１０３は無線伝送路である必要性はなく、有線であってもよい。
【図面の簡単な説明】
【図１】本発明の第１の実施形態に係る地図提供システムの構成を示すブロック図である。
【図２】図１に示す第１の地図ファイル１１１および第２の地図ファイル２５により表現される地図の階層構造を説明するための図である。
【図３】図２に示す最上位階層（レベル「３」）のユニットＵ3 を説明するための図である。
【図４】レベル「３」からレベル「０」までのそれぞれの階層間における親子関係を説明するための図である。
【図５】第１の地図ファイル１１１および第２の地図ファイル２５を管理するためのツリー構造を示す図である。
【図６】あるレベルに属する１つのユニットＵのデータ構造を示す図である。
【図７】地図ファイルＣＦのデータ構造を示す図である。
【図８】背景データにより表現される地図の模式図である。
【図９】描画オブジェクトＢＯ１およびＢＯ２を用いて、描画オブジェクトの概念を説明するための図である。
【図１０】背景データテーブルの詳細なデータ構造を示す図である。
【図１１】８個の要素点Ｐ０〜Ｐ７で構成される図形データを示す図である。
【図１２】図１１のＰ０〜Ｐ７の各絶対座標をオブジェクトレコードＯＲに記述した時のデータ構造を示す図である。
【図１３】図１１と同じ図形データの各要素点Ｐ０〜Ｐ７を相対座標で表現した時の図である。
【図１４】図１３の要素点Ｐ０〜Ｐ７の各相対座標をオブジェクトレコードＯＲに記述した時のデータ構造を示す図である。
【図１５】要素点Ｐ０、Ｐ１およびＰｎで構成されるオブジェクトＯＢＪを示す図である。
【図１６】図１５の要素点Ｐ１およびＰｎを結ぶ直線上に補われる要素点Ｐ２およびＰ３を示す図である。
【図１７】図１６の要素点Ｐ０，Ｐ１，Ｐ２，Ｐ３およびＰｎの各相対座標情報をオブジェクトレコードＯＲに記述した時のデータ構造を示す図である。
【図１８】図１５の要素点Ｐ０およびＰｎを絶対座標で表現し、要素点Ｐ１を相対座標で表した時のオブジェクトレコードＯＲのデータ構造を示す図である。
【図１９】描画オブジェクトＤＯ３を用いて、オブジェクトの境界に相対座標が適用されない場合を説明するための図である。
【図２０】そのオブジェクトの境界に相対座標が適用されない描画オブジェクトＤＯ３の座標列のデータ構造を示す図である。
【図２１】描画オブジェクトＤＯ３を用いて、オブジェクトの境界に適用される相対座標を説明するための図である。
【図２２】そのオブジェクトの境界に相対座標が適用された描画オブジェクトＤＯ３の座標列のデータ構造を示す図である。
【図２３】基本文字記号テーブルおよび詳細文字記号テーブルとの関係を説明するための図である。
【図２４】文字記号テーブルの詳細なデータ構造を示す図である。
【図２５】第１の道路ネットワークデータおよび第２の道路ネットワークデータの関係を説明するための図である。
【図２６】ノードおよびリンクの概念を説明するための図である。
【図２７】第１のノードテーブルの詳細なデータ構造を示す図である。
【図２８】図２６のノードＮ０〜Ｎ１０に関して作成されたノードレコードＮＲ１〜ＮＲ１１の並び方を示す図である。
【図２９】ノードの経度方向および緯度方向の座標の表現方法の一つである正規化座標を説明するための図である。
【図３０】第１のリンクテーブルの詳細なデータ構造を示す図である。
【図３１】各リンクレコードＬＲに記録されるリンク接続情報を説明するための図である。
【図３２】ノード接続情報およびリンク接続情報により、道路網の接続をたどる時の処理を説明するための図である。
【図３３】端末装置１における経路探索処理の概念を示す図である。
【図３４】端末装置１で実行される双方向階層別探索の処理手順を示すフローチャートである。
【図３５】図３４の地図ファイルＣＦの読み込み処理（ステップＳ１０３）の詳細な処理手順を示すフローチャートである。
【図３６】隣接ユニットＮＵを決定するための新しい代表点の位置を説明するための図である。
【図３７】互いに隣接し合う４個のユニットＵ１〜Ｕ４を並べた際に構成される道路網を示す図である。
【図３８】２個のユニットＵの境界をまたいで道路網の接続をたどる時のデータ処理部１３の処理手順を示すフローチャートである。
【図３９】隣接ノードのノードレコードＮＲが記録される順番を示す図である。
【図４０】下位階層および上位階層の地図ファイルＣＦのノードＮ同士の対応づけに関する問題点を説明するための図である。
【図４１】下位階層および上位階層の地図ファイルＣＦのノードＮ同士の対応関係を説明するための図である。
【図４２】正規化座標およびノードレコードＮＲの記録順序から、子ユニットＣＵのノードＮｄと対応する座標を有する親ユニットＰＵ内のノードを探し出す方法を説明するための図である。
【図４３】地図ファイルＣＦの送信要求時における端末装置１の処理を説明するための図である。
【図４４】センタ局２が要求ＲＥＱの受信後に実行する処理手順を示すフローチャートである。
【図４５】地図ファイルＣＦからパケットＰが組み立てられるまでの過程における、各データの構造を示す図である。
【図４６】ステップＳ５０４の詳細な処理手順を示すフローチャートである。
【図４７】マスタデータＭＤの詳細な内部データ構造を示す図である。
【図４８】端末装置１における地図ファイルＣＦの受信処理の手順を示すフローチャートである。
【図４９】図４８のステップＳ７０３の詳細な処理手順を示すフローチャートである。
【図５０】パケットＰ11，Ｐ12，…，Ｐ1j，…Ｐijから地図ファイルＣＦが作成されるまでの過程における各データの構造を示す図である。
【図５１】図４８のステップＳ７０４の詳細な処理の手順を示すフローチャートである。
【図５２】本発明の第２の実施形態に係る地図提供システムの構成を示すブロック図である。
【図５３】図５２に示された第１の記憶装置１０１３に格納された各地図ファイルＣＦの構造を示す図である。
【図５４】図５３（ｂ）に示された各ユニットレコードＵＲの詳細な構造を示す図である。
【図５５】図５４に示された背景データＢＤを説明するための図である。
【図５６】図５４に示された文字記号データＣＤを説明するための図である。
【図５７】図５４に示された道路ネットワークデータＮＤを説明するための図である。
【図５８】図５４に示された基本背景テーブルデータＢＢＤ、基本文字記号データテーブルＢＣＤおよび主要幹線ネットワークデータテーブルＭＮＤを重畳したときに表示される地図、ならびに、図５４に示された詳細背景テーブルデータＤＢＤ、詳細文字記号データテーブルＤＣＤおよび細街路ネットワークデータテーブルＳＮＤを重畳したときに表示される地図を示している。
【図５９】図５２に示されるセンタ局１０１において実行される処理の手順を示すフローチャートである。
【図６０】図５２に示されるセンタ局１０１が地図ファイルＣＦからパケットＰを生成するまでの過程における、各データの構造を示している。
【図６１】図５９に示されるステップＳ１００３が含む、詳細な処理手順を示すフローチャートである。
【図６２】図６０（ｂ）に示されるマスタデータＭＤの詳細な構造を示している。
【図６３】図５２に示される端末装置１０２において実行される処理の手順を示すフローチャートである。
【図６４】図６３に示されるステップＳ１２０３の詳細な処理手順を示すフローチャートである。
【図６５】図５２に示される端末装置１０２がパケットＰから地図ファイルＣＦを生成するまでの過程における、各データの構造を示している。
【図６６】図６３に示されるステップＳ１２０４が含む、詳細な処理手順を示すフローチャートである。
【図６７】図５２に示される地図ファイルＣＦの構造を示している。
【図６８】図６６に示されるステップＳ１４０６において、ファイル管理部１０２５が、第１および第２のユニットＩＤが一致しない場合に実行する処理を示している。
【図６９】図５４に示される基本背景データテーブルＢＢＤ、基本文字記号データテーブルＢＣＤ、主要幹線ネットワークデータテーブルＭＮＤが、ステップＳ１２０４の時点で端末装置１０２に既に提供されているような場合における、地図ファイルＣＦの構造を示している。
【図７０】図６６に示されるステップＳ１４０６において、ファイル管理部１０２５が、第１および第２のユニットＩＤが一致する場合に実行する処理を示している。
【図７１】ある範囲を表す地図βが、６４個の矩形のユニットに区画化された場合を示している。
【図７２】端末装置の記憶装置内において、空き領域を有する４個のクラスタ９１〜９４が発生したときの様子を示している。
【図７３】ある範囲を表す地図βが、１６個の矩形のユニットに区画化された場合を示している。
【図７４】端末装置の記憶装置内において、空き領域を有する１個のクラスタ９６が発生した場合を示しており、さらに、かかる場合には、無線伝送路の利用効率が悪くなることを説明するための図である。
【符号の説明】
１…端末装置
１１…入力装置
１２…位置検出装置
１３…データ処理部
１４…要求生成部
１５…第１の送受信部
１６…アンテナ
１７…パケット分解部
１８…読み出し／書き込み制御部
１９…第１の記憶装置
１１０…出力装置
１１１…第１の地図ファイル
２…センタ局
２１…第２の送受信部
２２…受信要求解析部
２３…読み出し制御部
２４…第２の記憶装置
２５…パケット組み立て部
３…通信網
１０１…センタ局
１０１１…地図サーバ
１０１２…アンテナ
１０１３…第１の記憶装置
１０１４…読み出し制御部
１０１５…パケット組み立て部
１０１６…送信部
１０２…端末装置
１０２１…アンテナ
１０２２…受信部
１０２３…データ処理部
１０２４…パケット分解部
１０２５…ファイル管理部
１０２６…第２の記憶装置

Claims (6)

  1. 地図を複数の領域に分割して得られる各ユニットがデジタルデータ化された地図ファイルが記憶装置に格納されており、当該記憶装置から地図ファイルを読み出すための端末装置であって、
    各前記地図ファイルは、それぞれのユニット内に含まれる道路網をノードとリンクとで表すべく、当該ノード毎に作成されるノードレコードと、当該リンク毎に作成されるリンクレコードとを含んでおり、
    各前記ノードレコードには、前記道路網上の交差点を表す非隣接ノードに関連する情報、または、ユニットとそれに隣接するユニットとの道路の接続関係を規定するための隣接ノードの座標情報が記録されており、
    各前記地図ファイルにおいて、前記隣接ノードの座標情報を含む各ノードレコード及び前記非隣接ノードに関連する情報を含む各ノードレコードの内、前記隣接ノードの座標情報を含むものは連続的に記録されており、
    前記端末装置は、
    ユーザの操作に応答して、地図の範囲を指定する情報を生成する入力装置と、
    前記入力装置により生成された情報に基づいて、必要な地図ファイルの記録領域を特定するデータ処理部と、
    前記データ処理部により特定された記録領域に基づいて、前記記憶装置から、地図ファイルを読み出す読み出し制御部とを備え、
    前記データ処理部は、
    前記読み出し制御部により読み出された地図ファイルに記録された、前記隣接ノードの座標情報及び前記非隣接ノードに関連する情報を含む各ノードレコードと、リンクレコードとを用いて、出発地及び目的地の間の最適経路を探索するための経路探索処理を実行し、
    経路探索処理を実行中に、一方のユニットを表す地図ファイルの隣接ノードに到達した時、隣接ユニットを表す地図ファイルにおいて、隣接ノードの座標情報を含む各ノードレコードのみを検索して、一方のユニットの隣接ノードの座標値に実質的に一致する座標値を有する隣接ユニットの隣接ノードを探し出し、これによって、当該一方のユニット内の道路から、当該隣接ユニット内の道路への接続をたどる、端末装置。
  2. 前記リンクレコードには、前記道路の属性を示す属性情報が記録されており、
    前記データ処理部は、一方のユニットの隣接ノードの座標値に実質的に一致する座標値を有する隣接ユニットの隣接ノードを探し出した後、一方のユニットおよび他方の隣接ユニットの隣接ノードに接続されたリンクの属性情報を比較し、両属性情報が一致する場合に、当該一方のユニット内の道路から、当該他方の隣接ユニット内の道路への接続をたどる、請求項１に記載の端末装置。
  3. 各前記地図ファイルにおいて、前記隣接ノードの座標情報を含む各ノードレコードは、当該各隣接ノードが前記ユニットの境界上を一周するような順序で記録されている、請求項１に記載の端末装置。
  4. 各前記ユニットは、地図を多角形状の領域に分割されており、
    各前記地図ファイルにおいて、前記ユニットの各辺に位置する隣接ノードの座標情報を含む各ノードレコードは連続的に記録されている、請求項１に記載の端末装置。
  5. 前記ユニットの各辺に位置する隣接ノードに関連する情報を含む各ノードレコードは、当該各隣接ノードの座標情報が昇順または降順に記録されている、請求項４に記載の端末装置。
  6. 地図を複数の領域に分割して得られる各ユニットがデジタルデータ化された地図ファイルが記憶装置に格納されており、コンピュータ装置が、当該記憶装置から地図ファイルを読み出して、経路探索を実行するための経路探索方法であって、
    各前記地図ファイルは、それぞれのユニット内に含まれる道路網をノードとリンクとで表すべく、当該ノード毎に作成されるノードレコードと、当該リンク毎に作成されるリンクレコードとを含んでおり、
    各前記ノードレコードには、前記道路網上の交差点を表す非隣接ノードに関連する情報、または、ユニットとそれに隣接するユニットとの道路の接続関係を規定するための隣接ノードの座標情報が記録されており、
    各前記地図ファイルにおいて、前記隣接ノードの座標情報を含む各ノードレコード及び前記非隣接ノードに関連する情報を含む各ノードレコードの内、前記隣接ノードの座標情報を含むものは連続的に記録されており、
    前記経路探索方法は、
    ユーザの操作に応答して、地図の範囲を指定する情報を生成する作成ステップと、
    前記作成ステップで生成された情報に基づいて、必要な地図ファイルの記録領域を特定する特定ステップと、
    前記特定ステップで特定された記録領域に基づいて、前記記憶装置から地図ファイルを読み出す読み出しステップと
    前記読み出しステップで読み出された地図ファイルに記録された、前記隣接ノードの座標情報及び前記非隣接ノードに関連する情報を含む各ノードレコードと、リンクレコードとを用いて、出発地及び目的地の間の最適経路を探索するための経路探索処理を実行し、経路探索処理を実行中に、一方のユニットを表す地図ファイルの隣接ノードに到達した時、隣接ユニットを表す地図ファイルにおいて、隣接ノードの座標情報を含む各ノードレコードのみを検索して、一方のユニットの隣接ノードの座標値に実質的に一致する座標値を有する隣接ユニットの隣接ノードを探し出し、これによって、当該一方のユニット内の道路から、当該隣接ユニット内の道路への接続をたどる探索ステップとを備える、経路探索方法。
JP2001187360A 1998-11-24 2001-06-20 端末装置 Expired - Lifetime JP3649391B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2001187360A JP3649391B2 (ja) 1998-11-24 2001-06-20 端末装置

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP33241298 1998-11-24
JP10-332412 1998-11-24
JP16594099 1999-06-11
JP11-165940 1999-06-11
JP2001187360A JP3649391B2 (ja) 1998-11-24 2001-06-20 端末装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP33188599A Division JP3332225B2 (ja) 1998-11-24 1999-11-22 地図提供システム

Related Child Applications (3)

Application Number Title Priority Date Filing Date
JP2002218846A Division JP2003150047A (ja) 1998-11-24 2002-07-26 端末装置
JP2002218848A Division JP2003157265A (ja) 1998-11-24 2002-07-26 端末装置
JP2002218847A Division JP2003141121A (ja) 1998-11-24 2002-07-26 端末装置

Publications (2)

Publication Number Publication Date
JP2002099207A JP2002099207A (ja) 2002-04-05
JP3649391B2 true JP3649391B2 (ja) 2005-05-18

Family

ID=27322597

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001187360A Expired - Lifetime JP3649391B2 (ja) 1998-11-24 2001-06-20 端末装置

Country Status (1)

Country Link
JP (1) JP3649391B2 (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004126036A (ja) 2002-09-30 2004-04-22 Xanavi Informatics Corp 配信地図データ構造、配信地図データ作成方法、配信地図データ作成装置、および端末装置
JP4271931B2 (ja) * 2002-12-06 2009-06-03 アルパイン株式会社 ナビゲーション装置及び電子地図更新方法
JP2004286524A (ja) * 2003-03-20 2004-10-14 Alpine Electronics Inc 地図情報変更方法およびナビゲーション装置
WO2008050377A1 (fr) 2006-09-29 2008-05-02 Fujitsu Limited Système de support de modèle, procédé et programme
JP5332809B2 (ja) * 2009-03-30 2013-11-06 三菱電機株式会社 地図情報処理装置
JP5440219B2 (ja) * 2010-01-29 2014-03-12 株式会社デンソー 地図データ及び地図データ作成方法

Also Published As

Publication number Publication date
JP2002099207A (ja) 2002-04-05

Similar Documents

Publication Publication Date Title
KR100443495B1 (ko) 디지털 지도파일의 데이터구조
JP3332225B2 (ja) 地図提供システム
US6430499B1 (en) Information terminal and cartographic information providing system
US6487305B2 (en) Deformed map automatic generation system including automatic extraction of road area from a block map and shape deformation of at least one road area drawn in the map
US8396660B2 (en) Road map data structure, road map data storage medium, navigation device, and method of generating road map data
US7197500B1 (en) System and method for use and storage of geographic data on physical media
JP4727245B2 (ja) 地図情報処理装置
CN105758412B (zh) 使用具有路线搜索加速数据的地图数据的导航装置
JP5093562B2 (ja) ナビゲーション装置
CA2444271A1 (en) A method and apparatus for transmitting position information
CN101308487A (zh) 一种自然语言表达动态交通信息的时空融合方法
JPH10312452A (ja) 地理情報提供システムと地理情報記述方法
JP3649391B2 (ja) 端末装置
CN109316781B (zh) 一种气泡层次可视化中气泡分离方法
CN110532464A (zh) 一种基于多旅游上下文建模的旅游推荐方法
JPWO2005039058A1 (ja) 符号化データ生成方法と装置
JP5332809B2 (ja) 地図情報処理装置
JP2003157265A (ja) 端末装置
CN102192748A (zh) 地图数据、存储介质和导航设备
JP2003141121A (ja) 端末装置
JP2003150047A (ja) 端末装置
JP3399779B2 (ja) 道路地図情報の読み出し装置および記録媒体並びに伝送方法
TW201211509A (en) Navigation devices
JP2002333828A (ja) 電子地図データ
KR102668821B1 (ko) 회전기반 최적경로 탐색 방법 및 시스템

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050119

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20050210

R150 Certificate of patent or registration of utility model

Ref document number: 3649391

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20080225

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090225

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100225

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100225

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110225

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120225

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130225

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130225

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140225

Year of fee payment: 9

EXPY Cancellation because of completion of term