JP2001056823A - デジタル地図ファイルのデータ構造 - Google Patents

Abstract

(57)【要約】 【課題】 ある１つが更新された場合に、隣接ユニット
の地図ファイルを更新する必要がない地図ファイルを読
み出すための端末装置を提供することである。 【解決手段】 地図を複数の領域に分割して得られる各
ユニットを表す地図ファイルは、ノード毎に作成される
ノードレコードと、リンク毎に作成されるリンクレコー
ドとを含む。所定のノードレコードには、ユニットとそ
れに隣接するユニットとの道路の接続関係を規定する隣
接ノードの座標情報が記録される。以上の地図ファイル
は、第１の記憶装置１９に格納される。前記データ処理
部１３は、地図ファイルを利用して経路を探索する処理
を実行する。データ処理部１３は、経路探索処理の最中
に、一方のユニットおよび他方の隣接ユニットの隣接ノ
ードが有する座標情報に基づいて、当該一方のユニット
内の道路から、当該他方の隣接ユニット内の道路への接
続をたどる。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、端末装置に関し、
より特定的には、地図を複数の領域に分割して得られる
各ユニットがデジタルデータ化された地図ファイルが内
部の記憶装置に格納されており、当該記憶装置から地図
ファイルを読み出す端末装置に関する。

【０００２】

【従来の技術】「第１の従来技術」近年、ナビゲーショ
ンシステムが搭載された車両が増加してきている。ナビ
ゲーションシステムでは、当初は、画面上に地図を作成
するファイル（以下、地図ファイルと称す）だけが提供
されていた。しかし、近年は、地図ファイルに加えて、
例えば交通情報および経路案内情報も提供されるように
なった。かかる情報の多様化により、ナビゲーションシ
ステムは、より便利になり、今後も急速に普及すると期
待されている。

【０００３】当初、ナビゲーションシステムには、ＣＤ
−ＲＯＭに代表される読み出し専用の記録媒体を有する
記憶装置が搭載されていた。この記録媒体には、ユーザ
に提供されるべき地図ファイルと、その関連データとが
予め記録されている。記憶装置は、記憶媒体に記録され
た地図ファイルを、必要に応じて読み出す。読み出され
た地図ファイルは、ユーザにより参照されたり、経路探
索処理またはマップマッチング処理に利用されたりして
いた。

【０００４】一般的にディジタル地図ファイルは、互い
に縮尺の異なる地図の階層構造を効率よく管理するため
に、当該各地図を経度方向および緯度方向に等間隔に分
割した矩形領域毎に作成される。以下、「第１の従来技
術」において、かかる矩形領域を以降ではユニットと呼
ぶ。

【０００５】かかる地図ファイルは、典型的には、カー
ナビゲーションシステムにおいて、経路探索処理または
現在位置の補正処理（マップマッチング）に用いられ
る。そのために、地図ファイルには、道路ネットワーク
データが記録される。道路ネットワークデータは、少な
くとも、各ノードおよび各リンクの接続関係を示す接続
情報とから構成される。ここで、ノードとは、主とし
て、道路網に存在する交差点を表す情報であり、リンク
とは、主として、２つの交差点間に存在する道路を表す
ベクトル情報である。かかるノードおよびリンクの集合
によって、それぞれのユニット内の道路ネットワークを
表す地図が表現される。

【０００６】上記のノード、リンクおよびそれらの接続
情報で最小限の道路網を表現することができるが、これ
だけでは地図を表示する用途には不十分である。例え
ば、山岳部や臨海部の道路では交差点間の道路が屈曲し
ている場合が多い。そこで、道路ネットワークデータ
は、屈曲した道路の形状を表示するためにリンク形状を
特定するための情報をさらに含む。以上から明らかなよ
うに、リンクはベクトルデータで表現されることが多
い。また、道路には、国道および県道というように様々
な種類がある。他にも、車線数の相違または中央分離帯
の有無等により道路を分類することができる。かかる道
路の種類を区別するために、道路ネットワークデータ
は、道路の種別等を示す属性情報をさらに含んでいる。
また、交差点には、交差点名称が付けられているもの
や、付けられていないものがある。さらには、信号機が
設置されている交差点、信号機が設置されていない交差
点がある。そこで、道路ネットワークデータはさらに、
ノード毎に属性情報を有している。各属性情報には、対
応する交差点の名称および信号機の有無等の情報が記録
される。

【０００７】また、ベクトルデータ構造を有する地図フ
ァイルでは、複数のユニットに跨るような道路が存在す
る場合には、ユニットの境界に特別なノード（以降、隣
接ノードと称す）が別途作成される。かかる隣接ノード
を経由することによって、互いに隣接するユニットとの
間で道路の接続関係を辿ることができるようになる。従
来の地図ファイルでは、あるユニットの隣接ノードが、
隣接するユニットのどの隣接ノードと対応するかを特定
するために、オフセットアドレスおよびレコード番号が
記録されていた。ここで、オフセットアドレスとは、基
準アドレスからみて、隣接ノードがどのアドレス位置に
記録されているかを示す。また、レコード番号とは、隣
接ユニットの地図ファイルにおいて、先頭のノードから
起算して隣接ノードが何番目の位置に記録されているか
を示す。

【０００８】「第２の従来技術」「第１の従来技術」で
説明したように、従来のナビゲーションシステムは、当
初、読み出し専用の記録媒体に記録された地図ファイル
しか利用できなかったので、リアルタイム性の高い情報
を提供することが困難であった。かかるリアルタイム性
の高い情報としては、交通情報または気象情報が代表的
である。そのため、リアルタイム性が要求される情報、
さらには地図ファイルを提供できる地図提供システム
が、例えば、「特開平７−２６２４９３号」公報に開示
されている。この公報の地図提供システムでは、地図フ
ァイルおよびリアルタイム性の高い情報が、情報提供セ
ンターから車載用の端末装置へと通信メディアを介して
ダウンロードされる。

【０００９】また、地図提供システムは、情報をリアル
タイムに提供するために、移動体通信技術とデジタル放
送技術とに基づいて構築される。このような地図提供シ
ステムでは、センタ局は、サービスエリア内に存在する
移動体に対し、所定の放送用チャンネルを用いて情報を
配信する。センタ局としては、通信衛星（いわゆるＣ
Ｓ）、放送衛星（いわゆるＢＳ）、または地上波のディ
ジタル放送局が典型的である。この移動体通信技術とデ
ジタル放送技術が利用された地図提供システムは、例え
ば、「特開平７−１５４３５０号」公報に開示されてい
る。より具体的には、この公報には、ある情報の放送地
域を限定するための技術的内容が開示されている。つま
り、センタ局は、多重された情報を、放送メディアを介
して送信する際に、各情報に郵便番号のような地域コー
ドを付ける。端末装置は、自身の現在位置に対応する地
域コードをＩＤとして予めメモリに登録しておく。端末
装置の内部では、データ抽出回路が、放送局から放送さ
れる多重情報を分離して、各情報に付加された地域コー
ドを取り出す。さらに、端末装置の内部では、取り出さ
れた地域コードと、登録されたＩＤとが比較される。両
者が一致する場合に、端末装置は、対象となった地域コ
ードが付された情報をユーザに参照させる。

【００１０】以上のように、通信または放送により地図
を提供するような地図提供システムの開発が近年盛んで
ある。この地図提供システムにおいて、センタ局は、端
末装置に送信すべき地図ファイルをユニット単位で読み
出して、当該端末装置に送信する。端末装置は、センタ
局からの地図データを受信した後に、記憶装置に格納す
る。格納された地図ファイルは、必要に応じて、ユーザ
が参照するため、経路探索処理のため、またはマップマ
ッチング処理のために用いられる。

【００１１】

【発明が解決しようとする課題】「第１の従来技術の課
題」「第１の従来技術」から明らかなように、従来で
は、あるユニットの地図ファイルには、隣接ユニットの
地図ファイル内部のデータ構造を直接指示する情報（上
述のオフセットアドレスまたはレコード番号）が記録さ
れていた。例えば、あるユニット内の道路が新しく造成
された場合には、当然、当該ユニットの地図ファイルは
更新される。更新された地図ファイルでは、隣接ノード
が記録される位置が変わる場合が多い。そのため、従来
のような地図ファイル内部のデータ構造を直接指示する
方法と採用していれば、隣接ユニットの地図ファイルに
記録された隣接ノードから、更新された地図ファイルに
おいて対応する隣接ノードを正確にたどれなくなる。つ
まり、ある１つの地図ファイルが更新されると、隣接ユ
ニットの地図ファイルも更新しなければならない場合が
多くなるという問題点があった。

【００１２】また、上述のディジタル地図ファイルの品
質を評価する尺度として、地図の詳細度がある。しかし
ながら、地図ファイルは、リンクがベクトルデータで表
現されることから、詳細な地図を表現しようとすればす
るほど、当該地図ファイルのデータ量が大きくなるとい
う問題点があった。従来、かかる地図ファイルは、主と
して、カーナビゲーションシステムにて使用される。カ
ーナビゲーションシステムでは、ＣＤ−ＲＯＭ、ＤＶＤ
−ＲＯＭまたはハードディスク等の大容量の記憶媒体
に、地図ファイルが記録される。しかし、今後、地図フ
ァイルは、カーナビゲーションシステムだけでなく、人
が携帯できるような情報機器においても使用されること
が考えられる。かかる携帯型情報機器に、カーナビゲー
ションシステムのような大容量の記憶媒体を搭載するこ
とは難しい。かかる点から、地図ファイルのデータ量を
圧縮する必要性は高い。

【００１３】「第２の従来技術の課題」ところで、「第
２の従来技術」の欄で示した各公報は、端末装置が地図
ファイルを記憶装置にどのようにして格納するかについ
て何ら開示していない。容易に想到できるのは、端末装
置が、受信したユニット毎の地図ファイルを作成して、
作成した地図ファイルを記憶装置に格納するという方法
である。しかしながら、この方法では、記憶領域の利用
効率が悪くなるという問題点があった。今、例えば、あ
る範囲を表す地図βが、図７１のように、６４個の矩形
のユニットに区画化されると仮定する。さらに、端末装
置が、４個のユニット７１から７４を受信し格納すると
仮定する。また、周知のように、記憶装置の記憶領域
は、クラスタ単位で管理される。また、各ユニットのデ
ータサイズは、クラスタのサイズの整数倍に一致すると
は限らない。そのため、端末装置が、受信した４個のユ
ニット７１〜７４について、４個のファイル８１〜８４
を作成すると、図７２に示すように、空き領域を有する
４個のクラスタ９１〜９４が発生する場合が多い。図７
２において、ドットが付された部分は、各ファイル８１
〜８４が記録された領域を示す。また、斜線が付された
部分は、空き領域を示す。各クラスタ９１〜９４に生じ
た空き領域は使用されない。つまり、たとえ、端末装置
が、各ユニット７１〜７４以外のユニット７５（図７１
参照）を受信したとしても、このユニット７５を基に作
成されたファイルは、各クラスタ９１〜９４の空き領域
に格納されることはない。以上から明らかなように、端
末装置が受信するユニットが多くなればなるほど、空き
領域を有するクラスタが多くなる。つまり、記憶領域の
利用効率が悪くなる。

【００１４】ところで、地図が相対的に少数のユニット
に区画されれば、空き領域を有するクラスタを発生し難
くすることができる。今、図７１と同じ範囲の地図β
が、図７３のように、１６個の矩形のユニットに区画さ
れると仮定する。図７３のユニット７６が表す範囲は、
図７１のユニット７１〜７４を併せた範囲に相当する。
さらに、端末装置が１個のユニット７６を受信し格納す
ると仮定する。この仮定下では、端末装置は、受信した
１個のユニット７６について、１個のファイル８６を作
成すると、図７４に示すように、空き領域を有するクラ
スタ９６が１個しか発生しない。図７４のドット部分
は、ファイル８６が記録された領域を示す。また、斜線
部分は、空き領域を示す。

【００１５】以上から明らかなように、地図が小さいユ
ニットに区画された場合（図７１参照）、ある範囲を表
す地図ファイルが記憶装置に格納されると、相対的に多
く空き領域が発生する（図７２参照）。しかしながら、
地図が大きなユニットに区画された場合には（図７３参
照）、同じ範囲の地図データが記憶装置に格納されて
も、発生する空き領域は少ない（図７４参照）。つま
り、記憶領域の有効利用の観点からは、地図は少数のユ
ニットに区画された方がよい。

【００１６】しかしながら、地図を少数のユニットに区
画するということは、１ユニット当たりのデータ量が大
きくなることを意味する。そのため、基地局は、１度
に、大量のデータを端末装置に送信しなければならな
い。その結果、無線伝送路は輻輳状態に陥り易くなる、
つまり無線伝送路の利用効率が悪くなる、という別の問
題点が生じる。つまり、記憶領域を重視すれば、無線伝
送路の効率的な利用が難しく、無線伝送路を重視すれ
ば、記憶領域の効率的な利用が難しくなるという問題点
があった。

【００１７】それゆえに、本発明の第１の目的は、ある
１つが更新された場合に、隣接ユニットの地図ファイル
を更新する必要がない地図ファイルのデータ構造を提供
することである。また、本発明の第２の目的は、そのデ
ータ量を圧縮可能な地図ファイルのデータ構造を提供す
ることである。また、本発明の第３の目的は、端末装置
内の記憶領域を効率的に利用し、しかもセンタ局と端末
装置との間の伝送路を効率的に利用できる地図提供シス
テムを提供することである。

【００１８】

【課題を解決するための手段および発明の効果】ある１
つの発明は、地図を複数の領域に分割して得られる各ユ
ニットがデジタルデータ化された地図ファイルが記憶装
置に格納されており、当該記憶装置から地図ファイルを
読み出すための端末装置であって、各地図ファイルは、
それぞれのユニット内に含まれる道路網をノードとリン
クとで表すべく、当該ノード毎に作成されるノードレコ
ードと、当該リンク毎に作成されるリンクレコードとを
含んでおり、各ノードレコードには、道路網上の交差点
を表す非隣接ノードに関連する情報、または、ユニット
とそれに隣接するユニットとの道路の接続関係を規定す
る隣接ノードに関連する情報が記録されており、隣接ノ
ードに関連する情報とは、当該隣接ノードの座標情報で
あり、ユーザの操作に応答して、地図の範囲を指定する
情報を生成する入力装置と、入力装置により生成された
情報に基づいて、必要な地図ファイルの記録領域を特定
するデータ処理部と、データ処理部により特定された記
録領域に基づいて、記憶装置から地図ファイルを読み出
す読み出し制御部とを備え、データ処理部は、読み出し
制御部により読み出された地図ファイルに記録されたノ
ードレコードおよびリンクレコードを用いて所定の処理
を実行し、一方のユニットおよび他方の隣接ユニットの
隣接ノードが有する座標情報に基づいて、当該一方のユ
ニット内の道路から、当該他方の隣接ユニット内の道路
への接続をたどる。

【００１９】上記発明では、データ処理部は、経路探索
処理を実行している最中に、ユニットおよび隣接ユニッ
トの隣接ノードの座標情報を基に、当該ユニットおよび
当該隣接ユニットの間をまたぐような道路の接続をたど
る。このように、データ処理部は、各地図ファイル内部
のデータ構造を直接指示する情報を参照することなく、
データ処理部は、２つのユニットの間の道路の接続をた
どることができる。これによって、記憶装置内のあるユ
ニットの地図ファイルを更新する時、隣接ユニットの地
図ファイルを更新する必要がなくなる。

【００２０】また、他の発明は、地図を複数の領域に分
割して得られる各ユニットがデジタルデータ化された地
図ファイルが記憶装置に格納されており、当該記憶装置
から地図ファイルを読み出すための端末装置であって、
各地図ファイルは、自身が表す地図の範囲を一意に特定
するファイル名が付けられて記憶装置に格納されてお
り、ユーザの操作に応答して、地図の範囲を指定する情
報を生成する入力装置と、入力装置により生成された情
報に基づいて、必要な地図ファイルの記録領域を特定す
るデータ処理部と、データ処理部により特定された記録
領域に基づいて、記憶装置から地図ファイルを読み出す
読み出し制御部とを備える。

【００２１】上記発明によれば、各地図ファイルは、自
身が表す地図の範囲を一意に特定するファイル名が付け
られる。そのため、データ処理部は、それぞれ名前から
互いに隣接する地図ファイルを特定することができる。
このように、上記発明によれば、各地図ファイルには、
隣接するユニットの地図ファイルのデータ構造に関連す
る情報を記録する必要がなくなるので、複数の地図ファ
イル間の関係が薄くなる。これによって、ある１つの地
図ファイルを更新した場合であっても、それ以外の地図
ファイルを更新する必要がなくなる。

【００２２】また、他の発明は、地図を複数の領域に分
割して得られる各ユニットがデジタルデータ化された地
図ファイルが記憶装置に格納されており、当該記憶装置
から地図ファイルを読み出すための端末装置であって、
各ユニット内に含まれる各背景は、一筆書き可能なオブ
ジェクト単位で分割され、当該複数のオブジェクトは互
いに同一の属性を有するもの毎にグループ化され、地図
ファイルは、各グループ毎にオブジェクトに関連する情
報が記録される背景レコードを含んでおり、ユーザの操
作に応答して、地図の範囲を指定する情報を生成する入
力装置と、入力装置により生成された情報に基づいて、
必要な地図ファイルの記録領域を特定するデータ処理部
と、データ処理部により特定された記録領域に基づい
て、記憶装置から地図ファイルを読み出す読み出し制御
部と、出力装置とを備え、データ処理部は、読み出し制
御部により読み出された地図ファイルに含まれる背景レ
コードに基づいて、出力装置上に背景を表示させる。

【００２３】上記発明によれば、地図ファイルには、同
一属性のオブジェクトは同じ背景レコードにまとめて記
録されるため、当該属性を示す情報を冗長に記録する必
要がなくなるためは、各地図ファイルのデータ量を圧縮
することが可能となる。

【００２４】また、他の発明は、互いに縮尺が異なる複
数の地図をそれぞれ、複数の領域に分割して得られる各
ユニットがデジタルデータ化された地図ファイルが記憶
装置に格納されており、当該記憶装置から地図ファイル
を読み出すための端末装置であって、複数の地図ファイ
ルは、縮尺に応じて階層的な構造を有しており、それぞ
れのユニット内に含まれる道路網をノードとリンクとで
表すべく、当該ノード毎に作成されかつ当該ノードの座
標情報が記録されるノードレコードと、当該リンク毎に
作成されるリンクレコードとを少なくとも含んでおり、
各地図ファイルには、ノードの座標情報が昇順または降
順になるようにノードレコードが記録されており、地図
の範囲を指定する情報を生成する入力装置と、入力装置
により生成された情報に基づいて、必要な地図ファイル
の記録領域を特定するデータ処理部と、データ処理部に
より特定された記録領域に基づいて、記憶装置から地図
ファイルを読み出す読み出し制御部とを備え、データ処
理部は、読み出し制御部により読み出された地図ファイ
ルに記録された座標情報に基づいて、下位階層のユニッ
トに含まれるノードに対応する上位階層のユニットのノ
ードを検索する。

【００２５】上記発明では、データ処理部は、ノードの
座標情報を基に、読み出し制御部により読み出された地
図ファイルに記録された座標情報に基づいて、下位階層
のユニットに含まれるノードに対応する上位階層のユニ
ットのノードを検索する。このように、データ処理部
は、各地図ファイル内部のデータ構造を直接指示する情
報を参照することなく、データ処理部は、異なる階層間
において同じ座標を有するノードをたどることができ
る。これによって、記憶装置内のあるユニットの地図フ
ァイルを更新する時、隣接ユニットの地図ファイルを更
新する必要がなくなる。

【００２６】さらに、他の発明は、センタ局が端末装置
に伝送路を通じて地図ファイルを提供するシステムであ
って、センタ局は、予め定められた範囲の地図を表す地
図ファイルを記憶する第１の記憶装置と、第１の記憶装
置から、地図ファイルの一部またはすべてを、地図デー
タとして読み出す読み出し制御部と、読み出し制御部に
より読み出された地図データを用いて、伝送路にとって
適切な形式のパケットを組み立てるパケット組み立て部
と、パケット組み立て部により組み立てられたパケット
を、伝送路を通じて端末装置に送信する送信部とを備
え、端末装置は、伝送路を通じて、送信部により送信さ
れたパケットを受信する受信部と、受信部により受信さ
れたパケットを分解して、地図データを復元する処理を
実行するデータ処理部と、その内部の記憶媒体に、地図
ファイルを記憶する第２の記憶装置とを備え、データ処
理部は、今回復元した地図データに関連する地図ファイ
ルが第２の記憶装置に既に格納されている場合には、当
該第２の記憶装置から当該地図ファイルを読み出し、さ
らに、復元した地図データを、読み出された第２の地図
ファイルに追加して、第２の記憶装置に格納する処理を
実行する。

【００２７】上記発明では、データ処理部は、今回復元
した地図データと、第２の記憶装置から読み出された地
図ファイルとを一まとめにして当該第２の記憶装置に格
納し、これによって、地図ファイルを更新する。このよ
うにデータ処理部は、受信部が受信した地図データにの
み基づいて、地図ファイルを作成しない。データ処理部
は、今回受信された地図データを、今回読み出された地
図ファイルに追加する。そのため、第２の記憶装置は、
データ量が小さな地図ファイルを多数格納せずに、ある
まとまったデータ量の地図ファイルを格納するので、空
き領域を有するクラスタが発生しにくくなる。これによ
って、端末装置側の記憶領域を効率的に利用できる地図
提供システムを実現することができる。

【００２８】さらに、上記発明では、センタ局が小さい
サイズの地図データを送信しても、端末装置がセンタ局
から提供された地図データを１ファイルにまとめるの
で、空き領域を有するクラスタの発生を抑えることがで
きる。このように、第３５の発明では、センタ局が小さ
なサイズの地図データを送信できるので、伝送路が輻輳
状態に陥りにくくなる。これによって、伝送路を効率的
に利用できる地図提供システムを実現することができ
る。

【００２９】

【発明の実施の形態】「第１の実施形態」 「システム構成」図１は、本発明の一実施形態に係る地
図提供システムの構成を示すブロック図である。図１に
おいて、本地図提供システムには、端末装置１とセンタ
局２とが収容される。端末装置１とセンタ局２とは通信
網３を通じて双方向通信可能に接続される。より具体的
には、端末装置１とセンタ局２との間には、アップリン
クＵＬとダウンリンクＤＬとが張られる。アップリンク
ＵＬとは、端末装置１からセンタ局２への通信路を意味
し、ダウンリンクＤＬとは、センタ局２から端末装置１
への通信路を意味する。ここで、通信網３の典型例とし
ては、携帯電話に代表される移動体通信網、ＩＳＤＮ
（Ｉｎｔｅｇｒａｔｅｄ ＳｅｒｖｉｃｅｓＤｉｇｉｔ
ａｌ Ｎｅｔｗｏｒｋ）に代表される公衆回線、または
専用回線がある。また、通信網３は、移動体通信網、公
衆回線および専用回線の内のいずれか２つ以上により構
成される場合もある。

【００３０】次に、端末装置１の構成について説明す
る。端末装置１は、典型的には、カーナビゲーションシ
ステムにより相当し、入力装置１１と、位置検出装置１
２と、データ処理部１３と、要求生成部１４と、第１の
送受信部１５と、アンテナ１６と、パケット分解部１７
と、読み出し／書き込み制御部１８と、第１の記憶装置
１９と、出力装置１１０とを備える。入力装置１１は、
カーナビゲーションシステムを遠隔から操作するリモー
トコントローラまたはカーナビゲーションシステム本体
に配列されたキーによりハードウェア的に実現された
り、カーナビゲーションシステムのメニュー画面に表示
されたボタンによりソフトウェア的に実現されたりす
る。さらには、入力装置１１は、音声認識技術を駆使し
て実現される場合もある。端末装置１のユーザは、以上
の入力装置１１を操作して、端末装置１に対して、表示
された地図のスクロールまたは縮尺変更、経路探索、情
報検索、もしくはセンタ局２への接続等、様々な処理の
要求を行う。さらに、入力装置１１は、特徴的な動作と
して、ユーザが必要とする地図ファイルＣＦを特定する
ための情報をデータ処理部１３に出力する。

【００３１】位置検出装置１２は、速度センサ、ジャイ
ロセンサ、またはＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉ
ｏｎｉｎｇ Ｓｙｓｔｅｍ）のアンテナおよび受信機に
より実現される。また、速度センサ、ジャイロセンサ、
ならびにＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎ
ｇ Ｓｙｓｔｅｍ）のアンテナおよび受信機のいずれか
２つ以上の組み合わせにより、位置検出装置１２は実現
される場合もある。位置検出装置１２は、速度センサに
より端末装置１の移動速度を検出して、検出結果を基に
走行距離を算出したり、ジャイロセンサにより端末装置
１の進行方向を検出したり、アンテナおよび受信機によ
り人工衛星からの電波を受信して、地球上における端末
装置１の絶対的な位置を検出したりする。以上の検出結
果を基に、位置検出装置１２は端末装置１の現在位置を
検出する。データ処理部１３は、後述する各種のデータ
処理を行う。データ処理部１３の処理の一つに、入力装
置１１から入力された情報を基に、ユーザが必要とする
地図の範囲を特定する座標を求めて、要求生成部１４に
出力するという処理がある。要求生成部１４は、座標情
報が入力されると、ユーザが必要とする地図ファイルＣ
Ｆの送信をセンタ局２に要求するための制御コマンドを
生成する。以降、生成された制御コマンドを要求ＲＥＱ
と称することとする。要求ＲＥＱは、予め定められたフ
ォーマットを有しており、要求生成部１４に入力された
座標情報を少なくとも含む。以上のような要求ＲＥＱ
は、第１の送受信部１５に出力される。第１の送受信部
１５は、典型的には、携帯電話に代表される移動体通信
装置により実現される。第１の送受信部１５は、入力さ
れた要求ＲＥＱを、アンテナ１６を通じてアップリンク
ＵＬに送出する。

【００３２】要求ＲＥＱは、アップリンクＵＬを通じ
て、センタ局２により受信される。センタ局２は、要求
ＲＥＱを解析して、ユーザが必要とする地図ファイルＣ
Ｆを特定する。センタ局２は、特定した地図ファイルＣ
Ｆを第２の記憶装置２４から取り出して、複数のパケッ
トＰを組み立てる（アセンブリする）。組み立てられた
パケットＰは、通信網３（ダウンリンクＤＬ）を通じ
て、順次端末装置１に送信される。なお、センタ局２の
処理は後で詳しく説明される。端末装置１において、第
１の送受信部１５はさらに、アンテナ１６を通じてパケ
ットＰを受信して、パケット分解部１７に出力する。パ
ケット分解部１７は、入力されたパケットＰを、元の地
図ファイルＣＦに分解（デアセンブリ）して、データ処
理部１３に出力する。データ処理部１３は、地図ファイ
ルＣＦが入力されると、予め定められた処理を実行し
て、所定の条件を満たす場合、入力された地図ファイル
ＣＦを基に第１のデータベース１１１を作成して読み出
し／書き込み制御部１８に出力する。読み出し／書き込
み制御部１８は、入力された地図ファイルＣＦを第１の
記憶装置１９にそのまま書き込んだり、既存の地図ファ
イルＣＦと書き換えたりする。なお、一連の書き込み処
理については後で説明する。第１の記憶装置１９は、典
型的には、ハードディスクドライブまたはフラッシュメ
モリに代表される、データの書き換えが可能な記憶装置
からなる。第１の記憶装置１９には、第１のデータベー
ス１１１が蓄積される。第１のデータベース１１１は、
本端末装置１がナビゲーションシステムとして機能する
ために必要な少なくとも１つの地図ファイルＣＦから構
成されるデータの集合体である。また、出力装置１１０
は、典型的には、ディスプレイおよびスピーカからな
る。ディスプレイには、地図ファイルＣＦにより表され
る地図が現在位置とともに表示されたり、データ処理部
１３による経路探索処理の結果または経路案内処理の結
果が表示されたりする。スピーカは、データ処理部１３
による経路案内処理の結果が音声によりユーザに提供す
る。

【００３３】ところで、データ処理部１３は、第１のデ
ータベース１１１を構成する地図ファイルＣＦを使って
様々な処理を行う。例えば、データ処理部１３は、端末
装置１の現在位置の表示処理を実行する。この場合、デ
ータ処理部１３は、位置検出装置１２により検出された
現在位置周辺の地図が必要となるので、読み出し／書き
込み制御部１８と協働して、第１のデータベース１１１
から、当該地図を表す地図ファイルＣＦを検索して取り
出す。データ処理部１３は、取り出された地図ファイル
ＣＦを使って、マップマッチング等の位置補正処理を行
う。位置補正処理後、データ処理部１３は、取り出した
地図ファイルＣＦが表す地図上に、検出された現在位置
を視覚的に示すポインタを重ね合わせて、出力装置１１
０に出力する。また、データ処理部１３は、端末装置１
のユーザが入力装置１１を用いて経路探索処理等を要求
した場合には、出発地および目的地付近の地図を表す地
図ファイルＣＦ、ならびに探索すべき経路を含む地図を
表す地図ファイルＣＦを読み出して経路探索処理等を行
う必要がある。この場合にも、データ処理部１３は、読
み出し／書き込み制御部１８と協働して、第１のデータ
ベース１１１から、経路探索処理等に必要となる地図フ
ァイルＣＦを検索して取り出す。なお、一連の地図ファ
イルＣＦの読み出し処理については後で説明する。

【００３４】次に、センタ局２の構成について説明す
る。センタ局２は、第２の送受信部２１と、受信要求解
析部２２と、読み出し制御部２３と、第２の記憶装置２
４と、パケット組み立て部２５とを備える。上述したよ
うに、センタ局２には、端末装置１により生成された要
求ＲＥＱが通信網３（アップリンクＵＬ）を通じて送信
されてくる。第２の送受信部２１は、典型的には、モデ
ム、ターミナルアダプタ、またはゲートウェイに代表さ
れる通信装置からなる。ここで、ゲートウェイとは、異
なる通信プロトコルが使用される通信網３にセンタ局２
を接続するための装置または機能を意味するだけでな
く、他の局が当該センタ局２に不正アクセスすることを
防止するための装置または機能を意味する。第２の送受
信部２１は、通信網３と接続されており、端末装置１か
らのデータ受信および端末装置１へのデータ送信を制御
する。より具体的には、第１のデータ送受信部１５は、
その一つの機能として、アップリンクＵＬを通じて送信
されてきた要求ＲＥＱを受信して受信要求解析部２２に
出力する。

【００３５】受信要求解析部２２は、入力された要求Ｒ
ＥＱを解析して、解析結果を読み出し制御部２３に出力
する。読み出し制御部２３は、入力された解析結果を基
に、端末装置１が必要とする地図ファイルＣＦを第２の
記憶装置２４から読み出す。ここで、第２の記憶装置２
４は、典型的には、ハードディスクドライブ、ＣＤ−Ｒ
ＯＭドライブまたはＤＶＤ−ＲＯＭドライブで構成され
ており、少なくとも蓄積されたデータの読み出しが可能
な記録媒体とそのドライバとからなる。第２の記憶装置
２４は、第２のデータベース２５を格納する。第２のデ
ータベース２５は、センタ局２が本端末装置１に地図を
提供する局として機能するために必要な少なくとも１つ
の地図ファイルＣＦから構成されるデータの集合体であ
る。つまり、地図ファイルＣＦは、端末装置１に提供可
能な地図を表現したデジタルデータを意味する。端末装
置１側の第１のデータベース１１１は、センタ局２によ
り提供される地図ファイルＣＦから作成される。ここ
で、読み出し制御部２３が読み出すのは、地図ファイル
ＣＦのすべてである場合もあれば、当該地図ファイルＣ
Ｆの一部である場合もある。読み出し制御部２３は、読
み出した地図ファイルＣＦを、パケット組み立て部２５
に出力する。パケット組み立て部２５は、入力された地
図ファイルＣＦを基にパケットＰを組み立てて（アセン
ブリして）、第２の送受信部２１に出力する。第３の送
受信部２１は、ダウンリンクＤＬを通じて、入力された
パケットＰを端末装置１に送信する。

【００３６】以上、本実施形態に係る地図提供システム
の全体構成、ならびに端末装置１およびセンタ局２の構
成について説明した。次に、上述の地図ファイルＣＦの
階層構造およびファイル名について詳細に説明する。

【００３７】「階層構造およびファイル名」図２は、本
実施形態に係る地図ファイルＣＦにより表現される地図
の階層構造を説明するための図である。図２に示すよう
に、まず、互いに縮尺の異なる複数種類の地図が準備さ
れる。本実施形態では、便宜上、４段階の縮尺の地図が
準備されると仮定する。以降の説明では、最大縮尺をレ
ベル「０」、２番目に大きな縮尺をレベル「１」、３番
目に大きな縮尺をレベル「２」、最小縮尺をレベル
「３」と称する。以上から分かるように、地図データ
は、最大縮尺をレベル「０」として、レベル「０」〜
「３」の４階層から構成される。さらに、レベルが高い
ものを上位階層の地図と称し、レベルが低いものを下位
階層の地図と称する。したがって、図２に示すように、
上位階層の地図ほど、広域でかつ詳細度が低い。逆に、
下位階層の地図ほど、狭域でかつ詳細度が高い。また、
各階層の地図は、経度方向および緯度方向に沿って等間
隔に区切られる。

【００３８】ここで、図３は、最上位階層（レベル
「３」）のユニットを説明するための図である。図３の
世界地図は、緯度０度を基準として、当該緯度方向に沿
って５度２０分毎に区切られる。さらに、この世界地図
は、経度０度を基準として、当該経度方向に沿って約８
度毎に区切られる。その結果、世界地図は、約６４０ｋ
ｍ四方の矩形領域に分割される。最上位階層（レベル
「３」）においては、約６４０ｋｍ四方の矩形領域をユ
ニットと称する。レベル「３」においては、かかる約６
４０ｋｍ四方のユニットがデジタルデータ化されること
により、１つの地図ファイルＣＦが作成される。以上の
ような、最上位階層（レベル「３」）のユニットを代表
して、ユニットＵ₃ （ハッチングを付した部分）につい
て説明する。最上位階層（レベル「３」）のユニットＵ
₃ は、日本の関西圏を含むユニットであり、緯度０度、
経度０度の位置を原点として、東経方向に数えて１６番
目、北緯方向に数えて６番目に位置する（ただし、原点
を含むユニットは０番目と数える）。以上のユニットＵ
₃ が、図２の最上段に示されている。

【００３９】図２に示すように、ユニットＵ₃ の地図
は、一つの頂点を基準として、点線で示すように、緯度
方向に沿って４０分毎に区切られる。さらに、ユニット
Ｕ₃ の地図は、上記と同じ頂点を基準として、点線で示
すように、当該経度方向に沿って１度毎に区切られる。
その結果、ユニットＵ₃ の地図は、約８０ｋｍ四方の矩
形領域に６４分割される。約８０ｋｍ四方の各矩形領域
を詳細に表した地図が、１階層下（つまり、レベル
「２」の階層）における１つのユニットとなる。レベル
「２」の階層のユニットを代表して、ユニットＵ₂ （ハ
ッチングを付した部分）について説明する。かかるユニ
ットＵ₂ は、ユニットＵ₃ 内の１つの頂点（便宜上、左
下の頂点とする）の位置を原点として、東経方向に数え
て４番目、北緯方向に数えて１番目に位置する（ただ
し、原点を含むユニットＵは０番目と数える）。レベル
「２」の階層のユニットＵ₂ が、図２の２段目に示され
ている。

【００４０】同様に、ユニットＵ₂ の地図は、一つの頂
点を基準として、緯度方向に沿って５分毎に、さらに経
度方向に沿って７分３０秒毎に区切られ、その結果、約
１０ｋｍ四方の矩形領域に６４分割される。約１０ｋｍ
四方の各矩形領域を詳細に表した地図が、１階層下（つ
まり、レベル「１」の階層）における１つのユニットと
なる。その内の一つであるユニットＵ₁ （ハッチングを
付した部分）は、ユニットＵ₂ の左下の頂点を原点とし
て、東経方向に数えて５番目、北緯方向に数えて３番目
に位置する（ただし、原点を含むユニットは０番目と数
える）。レベル「１」のユニットＵ₁ が、図２の上から
３段目に示されている。

【００４１】同様に、ユニットＵ₁ の地図は、約１．２
ｋｍ毎四方の矩形領域に６４分割される。約１．２ｋｍ
四方を詳細に表した各地図が、１階層下（つまり、レベ
ル「１」の階層）における１つのユニットＵとなる。そ
の内の一つであるユニットＵ ₀ （ハッチングを付した部
分）は、ユニットＵ₁ の左下の頂点を原点として、東経
方向に２番目、北緯方向に１番目に位置する（ただし、
原点を含むユニットは０番目と数える）。レベル「０」
のユニットＵ₀ が、図２の上から４段目に示されてい
る。

【００４２】図４は、レベル「３」〜「０」のそれぞれ
の階層間におけるユニットＵの親子関係を説明するため
の図である。まず、以下の説明において、子ユニットＣ
Ｕとは、ある１つのユニットＵがカバーする範囲に包含
される、下位階層の全てのユニットを意味する。言い換
えれば、子ユニットＣＵとは、上位階層のある１つのユ
ニットＵが表す地図の一部分を表すユニットＵの集合で
ある。逆に、親ユニットＰＵとは、あるユニットＵのカ
バーする範囲を包含する、上位階層の全てのユニットを
意味する。言い換えれば、親ユニットＰＵとは、下位階
層のある１つのユニットＵが表す地図を、自身が表す地
図の一部として含んでいるユニットＵの集合である。こ
こで、図４中のユニットＵ₃ は、図２に示すユニットＵ
₃ に相当しており、レベル「３」のユニットの一つであ
る。ユニットＵ₃ を親ユニットＰＵ₃ とするレベル
「２」のユニットＵ、すなわちユニットＵ₃ の子ユニッ
トＣＵの内、レベル「２」に属するものは、ユニットＵ
₃ を経度および緯度方向にそれぞれ８等分してできる６
４個のユニットＵとなる。

【００４３】このように、親ユニットＰＵに対しては、
１階層下に６４個の子ユニットＣＵができる。各子ユニ
ットＣＵには位置コードが割り当てられる。位置コード
とは、子ユニットＣＵが表す地図が、親ユニットＰＵの
どの部分に相当するかを特定するための情報である。言
い換えれば、位置コードとは、親ユニットＰＵを基準と
した子ユニットＣＵの位置を特定するための情報であ
る。今、親ユニットＰＵが図４ユニットＵ₃ であるとす
る。かかる場合、ユニットＵ₃ の左下隅の地図を詳細に
表す子ユニットＣＵには、位置コードとして「０００
０」が割り当てられる。この位置コード「００００」を
基準値として、子ユニットＣＵ（位置コード「０００
０」）に対して、東経方向に沿って隣接する子ユニット
ＣＵには「０１００」が割り当てられる。以下同様に、
子ユニットＣＵが東経方向に１つ移るたびに、位置コー
ドは、「０１００」だけ増加する．また、位置コード
「００００」を基準値として、子ユニットＣＵ（位置コ
ード「００００」）に対して、北緯方向に沿って隣接す
る子ユニットＣＵには「０００１」が割り当てられる。
以下同様に、子ユニットＣＵが北緯方向に１つ移るたび
に、位置コードは、「０００１」だけ増加する。以上の
ように割り当てられる位置コードに従えば、ユニットＵ
₃ の子ユニットＣＵの一つであるユニットＵ₂ の位置コ
ードは「０４０１」である。

【００４４】次に、親ユニットＰＵがユニットＵ₂ であ
ると仮定する。このユニットＵ₂ に対しても、１階層下
（レベル「１」）には６４個の子ユニットＣＵができ
る。レベル「１」の６４個の子ユニットＣＵに対して
も、図４に示すように、上述と同様の方法で位置コード
が割り当てられる。例えば、ユニットＵ₂ の子ユニット
ＣＵの一つであるユニットＵ₁ の位置コードは「０５０
３」である。また、親ユニットＰＵとしてのユニットＵ
₁ に対しても、１階層下（レベル「０」）には、６４個
の子ユニットＣＵができる。レベル「０」の各子ユニッ
トＣＵに対しても、図４に示すように、同様に位置コー
ドが割り当てられる。例えば、ユニットＵ₁ の子ユニッ
トＣＵの一つであるユニットＵ₀ の位置コードは「０２
０１」である。

【００４５】以上のように、本実施形態に係る位置コー
ドでは、東経方向への値の増分および北緯方向への値の
増分が予め定められている。そのため、子ユニットＣＵ
同士の隣接関係を簡単に把握することができる。

【００４６】ところで、図１に示す端末装置１およびセ
ンタ局２にはそれぞれ、ファイルシステムが搭載され
る。端末装置１側のファイルシステムは、データ処理部
１３および読み出し／書き込み制御部１８により構成さ
れる。端末装置１側のファイルシステムは、第１の記憶
装置１９内の第１のデータベース１１１を容易に管理す
べく、第１の記憶装置１９が有する記録領域を「ディレ
クトリ」と呼ばれるいくつかの論理領域に分割する。さ
らに、端末装置１側のファイルシステムは、第１のデー
タベース１１１を構成する地図ファイルＣＦの親子関係
および隣接関係を、ツリー構造に基づくディレクトリ名
およびファイル名により表す。また、センタ局２側のフ
ァイルシステムは、受信要求解析部２２および読み出し
制御部２３により構成される。センタ局２側のファイル
システムは、第２の記憶装置２４内の第２の地図ファイ
ル２４の記憶領域を「ディレクトリ」（論理領域）に分
割し、さらに、第２のデータベース２５を構成する地図
ファイルＣＦの親子関係および隣接関係を、ツリー構造
に基づくディレクトリ名およびファイル名により表す。

【００４７】以下、図５は、図２〜図４に示す地図ファ
イルＣＦを管理するためのツリー構造を示す図である。
上述したように、各ファイルシステムの各ディレクトリ
は、図５に示すようなツリー構造をとり、「￥」マーク
により表される。「￥」マークは、ディレクトリを識別
するための識別子である。また、最上部のディレクトリ
は、ルートと呼ばれ、「￥ＭＡＰ」で表される。ルート
ディレクトリ「￥ＭＡＰ」の下のディレクトリには、地
図ファイルＣＦそのものまたはサブディレクトリを格納
することができる。ここで、ファイルシステムは、必要
な地図ファイルＣＦを指定する際、ファイル名の前にル
ート「￥ＭＡＰ」から当該地図ファイルＣＦが存在する
ディレクトリまでに介在するディレクトリ名を「パス」
として記述する必要がある。したがって、２つの「￥」
マークで挟まれた文字列がディレクトリ名を表すことと
なる。サブディレクトリ名の頭文字は「Ｄ」と定義され
る。また、ファイル名の頭文字は「Ｍ」と定義される。
さらに、ファイル名の拡張子は「．ｍａｐ」と定義され
る。

【００４８】さて、次に、本実施形態の一つの特徴であ
る、ディレクトリ名およびファイル名を割り当て方法を
説明する。まず、原則として、最上位階層の各ユニット
がカバーする地図を表す地図ファイルＣＦは、所定の規
則に従ってファイル名が付けられ、ルート（「￥ｍａ
ｐ」）の直下のディレクトリ（論理領域）に格納され
る。例えば、図３に示すユニットＵ₃ は、最上位の階層
（レベル「３」）に属しており、原点（緯度０度、経度
０度）を基準として、東経方向に数えて１６番目、北緯
方向に６番目（ただし、原点を含むユニットはそれぞれ
０番目と数える）のユニットに該当する。そのため、ユ
ニットＵ₃ には、ファイル名の頭文字および拡張子を含
めて「Ｍ１６０６．ｍａｐ」という名前が付けられる。
さらに、最上位階層のユニットＵ₃ は、ルート（「￥ｍ
ａｐ」）の直下に格納されるので、パスは、「￥ＭＡＰ
￥Ｍ１６０６．ｍａｐ」となる。以上のユニットＵ₃ の
ファイル名から分かるように、ファイル名の頭文字およ
び拡張子の間には、４桁の数字が並ぶ。上位２桁の数字
は、ユニットＵが原点から東経方向に数えて何番目に位
置するかを規定する。また、下位２桁の数字は、ユニッ
トＵが原点から北緯方向に数えて何番目に位置するかを
規定する。このように、ファイル名は、ユニットＵの位
置を規定する。また、ユニットＵ₃ のパスから分かるよ
うに、ルート（「￥ｍａｐ」）からファイル名に至るま
でにはサブディレクトリが介在しない。このように、サ
ブディレクトリの個数は、ユニットＵがどの階層に属し
ているかを規定する。ユニットＵ₃ の場合には、ルート
とファイル名との間に介在するサブディレクトリの個数
が「０」であることにより、ユニットＵ₃ （Ｍ１６０
６．ｍａｐ）が最上位階層に属することが分かる。以上
の規則に従うと、他の最上位階層のユニットＵのための
パスは、「￥ＭＡＰ￥Ｍ００００．ｍａｐ」，「￥ＭＡ
Ｐ￥Ｍ０００１．ｍａｐ」，…「￥ＭＡＰ￥Ｍ１６０
６．ｍａｐ」…等のように表される。

【００４９】また、最上位階層のユニットＵを親ユニッ
トＰＵとするユニットのグループを格納するためのサブ
ディレクトリがルートの直下に作成される。例えば、ユ
ニットＵ₃ を親ユニットＰＵとするユニットＵのグルー
プを格納するために、「￥Ｄ１６０６」と名付けられた
サブディレクトリがルートの直下に作成される。以上の
サブディレクトリ名から分かるように、サブディレクト
リ名の頭文字には４桁の数字が続く。この４桁の数字
は、ファイル名の場合と同様に、親ユニットＰＵが原点
から東経方向および北緯方向に数えてそれぞれ何番目に
位置するかを表す。そのため、ルート（「￥ＭＡＰ」）
の直下には、「￥Ｄ００００」、「￥Ｄ０００１．ｍａ
ｐ」，…，「￥１６０６」，…が作成される。

【００５０】次に、レベル「２」の階層に属する各ユニ
ットＵは、位置コードに基づくファイル名が付けられ、
自身の親ユニットＰＵを表すサブディレクトリの直下の
ディレクトリ（論理領域）に格納される。例えば、ユニ
ットＵ₃ を親ユニットＰＵとするレベル「２」のユニッ
トＵは、図４等を参照すると６４個ある。その内の一つ
であるユニットＵ₂ は、位置コードが「０４０１」であ
るため、ファイル名の頭文字および拡張子を含めて「Ｍ
０４０１．ｍａｐ」という名前が付けられる。さらに、
レベル「２」のユニットＵ₂ は、ユニットＵ₃ （親ユニ
ットＰＵ）のサブディレクトリ（「￥ｍａｐ￥Ｄ１６０
６」）の直下に格納されるので、パスは、「￥ＭＡＰ￥
Ｄ１６０６￥Ｍ０４０１．ｍａｐ」となる。以上のユニ
ットＵ₂ のファイル名から分かるように、レベル「２」
のユニットＵのファイル名の頭文字および拡張子の間に
は、上述した位置コードが並ぶ。そのため、レベル
「２」のユニットＵのファイル名もまた、当該ユニット
Ｕの位置を規定することとなる。また、ユニットＵ₂ の
パスから分かるように、ルート（「￥ｍａｐ」）からフ
ァイル名に至るまでにはサブディレクトリが１つだけ介
在する。サブディレクトリの個数は、ユニットＵがどの
階層に属しているかを規定する。ユニットＵ₂ の場合に
は、ルートとファイル名との間に介在するサブディレク
トリの個数が「１」であることにより、当該ユニットＵ
₂ （Ｍ０４０１．ｍａｐ）がレベル「２」の階層に属す
ることが分かる。以上の規則に従うと、他のレベル
「２」のパスは、「￥ＭＡＰ￥Ｄ００００￥Ｍ０００
０．ｍａｐ」，「￥ＭＡＰ￥Ｄ００００￥Ｍ０００１．
ｍａｐ」，…，「￥ＭＡＰ￥Ｄ００００￥Ｍ０００７．
ｍａｐ」，「￥ＭＡＰ￥Ｄ００００￥Ｍ０１００．ｍａ
ｐ」，…「￥ＭＡＰ￥Ｄ００００￥Ｍ０７０７．ｍａ
ｐ」，「￥ＭＡＰ￥Ｄ０００１￥Ｍ００００．ｍａ
ｐ」，…「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０００１．ｍａ
ｐ」，…，「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａ
ｐ」，…「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０７０７．ｍａ
ｐ」，…等のように表される。

【００５１】同様に、レベル「２」のユニットＵ₂ を親
ユニットＰＵとするユニットのグループは、サブディレ
クトリ「￥Ｄ０４０１」の下のディレクトリ（論理領
域）の下に格納されることになる。例えば、ユニットＵ
₁ は、ユニットＵ₂ の子ユニットＣＵの一つであって、
当該ユニットＵ₂ が６４分割されたユニットＵの内、位
置コード「０５０３」に該当するユニットである。その
ため、ユニットＵ₁ のためのパスは、「￥ＭＡＰ￥Ｄ１
６０６￥Ｄ０４０１￥Ｍ０５０３．ｍａｐ」と表され
る。同様に、ユニットＵ₂ を親ユニットＰＵとするレベ
ル「１」の各ユニットのパスは、「￥ＭＡＰ￥Ｄ１６０
６￥Ｄ０４０１￥Ｍ００００．ｍａｐ」、「￥ＭＡＰ￥
Ｄ１６０６￥Ｄ０４０１￥Ｍ０００１．ｍａｐ」，…，
「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｍ０７０７．ｍ
ａｐ」で表される。

【００５２】さらに、ユニットＵ₁ を親ユニットＰＵと
するユニットＵのグループは、「￥ＭＡＰ￥Ｄ１６０６
￥Ｄ０４０１￥Ｄ０５０３」と表されるサブディレクト
リの直下のディレクトリ（論理領域）に格納される。か
かるグループに属するユニットＵ₀ は、ユニットＵ₁ が
６４分割されたユニットＵの内、位置コード「０２０
１」に該当するユニットである。そのため、ユニットＵ
₀ のパスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ
０５０３￥Ｍ０２０１．ｍａｐ」と表される。同様に、
ユニットＵ₁ を親ユニットＰＵとするレベル「０」の各
ユニットのパスは、「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０
１￥Ｄ０５０３￥Ｍ００００．ｍａｐ」，「￥ＭＡＰ￥
Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０００１．ｍ
ａｐ」，…「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０
５０３￥Ｍ０７０７．ｍａｐ」で表される。

【００５３】以上、地図ファイルＣＦにより実現される
階層構造およびファイル名について説明した。ここで、
以上のユニットＵがデジタルデータ化され、必要な管理
情報が付加されることにより、１つの地図ファイルＣＦ
が構成される（詳細は図７を参照）。以下の説明におい
て、ユニットデータは、ユニットＵをデジタルデータ化
したものを意味する。つまり、１つの地図ファイルＣＦ
には、１つのユニットデータが含まれる。次に、地図フ
ァイルＣＦのデータ構造について詳細に説明する。

【００５４】「地図ファイルＣＦのデータ構造」図６
は、１つの地図ファイルＣＦを基に描かれる地図を説明
するための図である。また、図７は、１つの地図ファイ
ルＣＦのデータ構造を示している。図７において、地図
ファイルＣＦは、大略的に、ユニットヘッダとユニット
データとから構成される。まず、ユニットデータから説
明する。一般的に、地図は、用途に応じて、図７に示す
ように、背景、道路、地図記号および文字から構成され
る。しかし、地図ファイルＣＦは、主として、端末装置
１のディスプレイ上への表示、マップマッチングまたは
経路探索処理に使用される。例えば、経路探索処理で
は、道路のつながりが分かればよく、背景の必要性は薄
い。そこで、１つのユニットデータは、図６に示すよう
に、文字記号データと、道路ネットワークデータと、背
景データとに分けてデータ化される。これによって、文
字記号データ、道路ネットワークデータおよび背景デー
タはそれぞれ、独立的に使用することができる。文字記
号データとは、ユニットＵがカバーする地図に記載され
るべき文字列（地名および交差点名称等）からなるデー
タと、当該地図に記載されるべき地図記号からなるデー
タとを意味する。道路ネットワークデータとは、ユニッ
トＵがカバーする地図に表されるべき道路そのものおよ
び道路同士のつながりを表す図形データを意味する。背
景データとは、水系、山系、建造物等、ユニットＵがカ
バーする地図に表されるべき背景を表す図形データを意
味する。背景の例としては、河川、湖、山、緑地帯、鉄
道、建造物、橋、公園がある。以上の文字記号データ、
道路ネットワークデータおよび背景データを重ねあわせ
て表示することにより、図６に示すように、ユニットデ
ータは、背景、道路、地図記号および文字を表すことが
できる。

【００５５】次に、背景データの詳細なデータ構造を、
図７および図８を参照して説明する。図７に示すよう
に、背景データは、基本背景テーブルおよび詳細背景テ
ーブルから構成される。基本背景テーブルは、図８
（ａ）から明らかなように、河川、鉄道および緑地帯
等、地図の背景を表示する際に概略となる図形データを
集合である。一方、詳細背景テーブルは、図８（ｂ）か
ら明らかなように、橋および建造物等、地図の背景をよ
り詳細に表示するための図形データの集合である。これ
ら基本背景テーブルおよび詳細背景テーブルは、図７か
ら明らかなように、ユニットデータにおいて互いに別々
に記録される。さらに、基本背景テーブルおよび詳細背
景テーブルには、相互に参照し合うような情報は記録さ
れない。つまり、基本背景テーブルを構成する背景デー
タを描いている際に、詳細背景テーブルの背景データは
何一つ参照されない。逆に、詳細背景テーブルを構成す
る背景データを描いている際に、基本背景テーブルの背
景データは何一つ参照されない。このように、基本背景
テーブルおよび詳細背景テーブルは、相互に独立したデ
ータ構造を有する。したがって、背景をディスプレイ上
に表示する場合には、図８（ａ）に示すように、基本背
景テーブルのみで表される背景を表示することが可能に
なる。これによって、端末装置１のユーザは、概略的な
地図を見ることが可能になる。また、図８（ｃ）に示す
ように、基本背景テーブルおよび詳細背景テーブルで表
される背景を表示することもできる。この場合、所定の
原点を基準として、基本背景テーブルから得られる概略
的な背景の上に、詳細背景テーブルから得られる詳細な
背景を重ねあわせることとなる。これによって、端末装
置１のユーザは、詳細な地図を見ることが可能となる。
なお、本実施形態では、背景データは基本背景テーブル
および詳細背景テーブルとから構成されるとして説明し
たが、第１の記憶装置１９または第２の記憶装置２４に
記憶容量の制限がある場合等には、第１のデータベース
１１１または第２のデータベース２５を小さいサイズに
する観点から、背景データは基本背景テーブルのみから
構成されてもよい。逆に、本実施形態で説明したよう
に、背景データは基本背景テーブルおよび詳細背景テー
ブルとから構成される場合には、センタ局２は、詳細な
地図を端末装置１に提供することが可能となり、当該端
末装置１は詳細な地図をディスプレイに表示できるよう
になる。

【００５６】上述の基本背景テーブルおよび詳細背景テ
ーブルの内部のデータ構造は互いに同じである。以下に
は、基本背景テーブルおよび詳細背景テーブルを背景テ
ーブルと総称して、双方のデータ構造についてより詳細
に説明する。上述したように、背景テーブルは、地図の
背景をディスプレイ上に描画するために使用される図形
データの集合である。各図形データによって、河川、公
園、工場および鉄道等がディスプレイ上に描画される。
以下、これら地図の背景の要素となる、河川、公園、工
場および鉄道等を総称して「描画オブジェクト」と呼ぶ
こととする。ここで、図９は、描画オブジェクトの概念
を示す図である。上述から明らかなように、描画オブジ
ェクトは、公園または工場等のように、それ自体で意味
のあるひとまとまりの対象物のを表し、データ構造とし
ては、対象物を折れ線で描画するための要素点の並びか
ら構成される。例えば、図９には、矩形領域のユニット
Ｕが示されている。ユニットＵがカバーする範囲には、
２つの描画オブジェクトＤＯ１およびＤＯ２が存在す
る。描画オブジェクトＤＯ１は、オブジェクトＯＢＪ１
とＯ２とから構成される。オブジェクトＯＢＪ１は、要
素点ａ→要素点ｂ→要素点ｃ→要素点ｄ→要素点ｅ→要
素点ａの順番に一筆書きした時に作成される折れ線で囲
まれる領域である。また、オブジェクトＯＢＪ２は、要
素点ｆ→要素点ｇ→要素点ｈ→要素点ｉ→要素点ｆの順
番に一筆書きした時に描かれる折れ線で囲まれる領域で
ある。また、描画オブジェクトＤＯ２は、オブジェクト
ＯＢＪ３から構成される。オブジェクトＯＢＪ３は、要
素点ｊ→要素点ｋ→要素点ｌ→要素点ｍ→要素点ｎ→要
素点ｊの順番に一筆書きした時に描かれる折れ線で囲ま
れる領域である。以上から明らかなように、本実施形態
の描画オブジェクトは、複数の要素点を一筆書きして得
ることができる１つ以上のオブジェクトにより表され
る。

【００５７】ここで、図１０は、背景テーブル、つまり
基本背景テーブルまたは詳細背景テーブルの詳細なデー
タ構造を示す図である。図１０において、背景テーブル
には、背景レコード数Ｍと、Ｍ個の背景レコードＢＲ１
〜ＢＲＭとから構成される。ここで、Ｍは、１以上の自
然数である。背景レコード数Ｍは、背景テーブルに含ま
れる背景レコードＢＲ１〜ＢＲＭの個数を示す情報であ
る。また、背景レコードＢＲ１は、背景属性と、オブジ
ェクト数Ｎと、オブジェクトＯＢＪ１〜ＯＮの要素点数
Ｎ１〜ＮＮと、オブジェクトレコードＯＲ１〜ＯＲＮと
から構成される。背景属性は、背景レコードＢＲ１内に
含まれる各オブジェクトＯＢＪにより表される背景の属
性を示す情報である。より具体的には、背景属性は、背
景レコードＢＲ１内に含まれる各オブジェクトＯＢＪの
カラーコードおよびテクスチャーマッピングコードであ
る。ここで、本実施形態の一つの特徴として、背景属性
には、１つのカラーコードまたはテクスチャマッピング
コードのみが記述される。つまり、例えば、「青」を示
すカラーコードと、「赤」を示すカラーコードとが一緒
に背景属性に記述されることはない。「青」を示すカラ
ーコードのみ、または「赤」を示すカラーコードのみが
背景属性に記述される。

【００５８】また、オブジェクト数Ｎは、背景レコード
ＢＲ１内に含まれるオブジェクトＯＢＪの数を示す情報
である。また、要素点数Ｎ１は、オブジェクトＯＢＪ１
を構成する要素点の数を示している。要素点数Ｎ２は、
オブジェクトＯＢＪ２を構成する要素点の数を示してい
る。以降、同様に、要素点数ＮＮは、オブジェクトＯＢ
ＪＮの要素点の数を示す。このように、背景レコードＢ
Ｒ１には、そこに含まれるＮ個のオブジェクトＯを構成
する要素点の数が並ぶ。ここで、Ｎは１以上の自然数で
ある。

【００５９】さらに、オブジェクトレコードＯＲ１は、
１つのオブジェクトＯＢＪ１を構成する要素点の座標を
示す情報である。ここで注意を要するのは、オブジェク
トＯＢＪ１は複数の要素点を含むので、オブジェクトレ
コードＯＲ１には複数の座標情報が並ぶこととなる。つ
まり、オブジェクトレコードＯＲ１には座標列の情報が
記述される。ここで、上述から明らかなように、オブジ
ェクトレコードＯＲ１には、要素点数Ｎ１に相当する個
数の座標情報が記述される。また、オブジェクトレコー
ドＯＲ２は、オブジェクトＯＢＪ２を構成する要素点の
座標列を示す情報である。オブジェクトレコードＯＲ２
には、要素点数Ｎ２に相当する個数の座標情報が記述さ
れる。以降、同様に、オブジェクトレコードＯＲＮは、
オブジェクトＯＢＪＮを構成するＮＮ個の要素点の座標
列を示す情報である。オブジェクトレコードＯＲＮに
は、要素点数ＮＮに相当する個数の座標情報が記述され
る。

【００６０】以上のように、各オブジェクトレコードＯ
Ｒには、オブジェクトＯＢＪを構成する要素点の座標列
が記述される。座標列の表現方法としては、ユニットＵ
内での絶対座標で表現する方法と、ある要素点の座標と
直前の要素点の座標との差分を用いた相対座標で表現す
る方法とがある。絶対座標は、ユニットＵ内の所定の原
点を基準とした各要素点の座標であるため、多くのビッ
ト数を必要とする。そのため、座標列の表現方法とし
て、相対座標が使用されることが、地図ファイルＣＦの
データサイズを小型化する観点から、好ましい。以下、
絶対座標と相対座標とについて、詳細に説明する。

【００６１】図１１は絶対座標が多くのビット数を必要
とすることを説明するための図である。図１１には、８
個の要素点Ｐ０〜Ｐ７で構成される図形データが示され
ている。要素点Ｐ０の絶対座標は、予め定められた原点
を基準として、（Ｘ０，Ｙ０）である。以降、同様に、
要素点Ｐ１〜Ｐ７の絶対座標は、（Ｘ１，Ｙ１）〜（Ｘ
７，Ｙ７）である。また、図１２は、以上のＰ０〜Ｐ７
の各絶対座標情報をオブジェクトレコードＯＲに記述し
た時の図である。今、要素点Ｐ０〜Ｐ７の絶対座標は、
東経方向（ｘ軸方向）および北緯方向（ｙ軸方向）それ
ぞれについて、例えば２バイトで表現すると、Ｐ０〜Ｐ
７の各絶対座標情報をオブジェクトレコードＯＲに記述
するためには、３２バイトが必要となる。

【００６２】一方、図１３は、図１１と同じ図形データ
の各要素点Ｐ０〜Ｐ７を相対座標で表現した時の図であ
る。図１２において、図形データは、要素点Ｐ０→Ｐ１
→Ｐ２→Ｐ３→Ｐ４→Ｐ５→Ｐ６→Ｐ７の順番で一筆書
きされる。相対座標表現であっても、一筆書きされる最
初の要素点Ｐ０は、絶対座標表現と同様に、所定の原点
を基準として、（Ｘ０，Ｙ０）で表される。ただし、次
の要素点Ｐ１は、絶対座標表現の場合には、（Ｘ１，Ｙ
１）と表される。しかし、相対座標表現では、要素点Ｐ
１は（ΔＸ１，ΔＹ１）で表される。ここで、ΔＸ１
は、ΔＸ１＝Ｘ１−Ｘ０である。また、ΔＹ１は、ΔＹ
１＝Ｙ１−Ｙ０である。以降の要素点Ｐ２〜Ｐ７も、そ
れぞれの要素点の絶対座標と、直前の要素点の絶対座標
との差分により表現される。図１４は、以上の要素点Ｐ
０〜Ｐ７の各相対座標情報をオブジェクトレコードＯＲ
に記述した時のデータ構造を示す図である。ここで注意
を要するのは、相対座標表現は、それぞれの要素点の絶
対座標と、直前の要素点の絶対座標との差分で表される
ため、ΔＸ１≪Ｘ１，ΔＸ２≪Ｘ２，…ΔＸ７≪Ｘ７と
なる。同様に、ΔＹ１≪Ｙ１，ΔＹ２≪Ｙ２，…ΔＹ７
≪Ｙ７となる。そのため、要素点Ｐ１〜Ｐ７の相対座標
は、東経方向（ｘ軸方向）および北緯方向（ｙ軸方向）
それぞれについて２バイトで表現するのではなく、それ
ぞれ１バイトで表現する。その結果、要素点Ｐ１〜Ｐ７
の各相対座標情報をオブジェクトレコードＯＲに記述す
るためには、１４バイトが必要となる。ただし、最初の
要素点Ｐ０は、絶対座標で記述される必要があるので、
要素点Ｐ０〜Ｐ７の各座標情報をオブジェクトレコード
ＯＲに記述するためには、差分数（「７」）の情報を含
めて、１９バイトが必要となる。

【００６３】以上、図１１〜図１４を参照して説明した
ように、オブジェクトＯＢＪを構成する各要素点Ｐを相
対座標を使って表現すると、絶対座標表現のみを用いた
場合と比較して、オブジェクトレコードＯＲのサイズが
小さくなる。しかしながら、オブジェクトＯＢＪを構成
する各要素点を無条件に相対座標で表現すると、データ
サイズの小型化を実現できない場合が生じるという問題
点が想定できる。かかる問題点を、図１５を参照して説
明する。図１５には、要素点Ｐ０、Ｐ１およびＰｎで構
成されるオブジェクトＯＢＪが示されている。今、要素
点Ｐ１は、相対座標では（ΔＸ１，ΔＹ１）で表され
る。ΔＸ１およびΔＹ１の双方は、１バイトで表現でき
るとする。同様に、要素点Ｐｎは、相対座標では（ΔＸ
ｎ，デルタＹｎ）で表される。しかしながら、ΔＸｎお
よび／またはΔＹｎは、要素点Ｐｎが直前の要素点Ｐ１
から離れた位置にあるため、１バイトでは表現しきれな
い値であると仮定する。このような場合、図１６に示す
ように、要素点Ｐ１およびＰｎを結ぶ直線上に、新しい
要素点Ｐ２およびＰ３を作成する必要が生じる。これに
よって、要素点Ｐｎの相対座標は、直前の要素点Ｐ３の
絶対座標を基に、（ΔＸ４，ΔＹ４）で表すことができ
る。ΔＸ４およびΔＹ４は、要素点Ｐ３が要素点Ｐ１と
比べて要素点Ｐｎの近くに位置するため、１バイトで表
現できる。以上の要素点Ｐ０，Ｐ１，Ｐ２，Ｐ３および
Ｐｎの各相対座標情報をオブジェクトレコードＯＲに記
述すると、図１７に示すように、１３バイト必要とな
る。

【００６４】以上、図１５〜図１７を参照して説明した
ように、２個の要素点Ｐが離れて位置している場合に
は、新しい要素点Ｐを補う必要が生じる。その結果、オ
ブジェクトレコードＯＲには、補った要素点Ｐの相対座
標情報を記述しなければならない。このように、最初の
要素点Ｐを除くすべての要素点Ｐを相対座標で表現しよ
うとすると、要素点Ｐの数が不必要に多くなり、オブジ
ェクトレコードＯＲのデータサイズが不必要に大きくな
るという問題点が顕在化してくる。そこで、図１５の要
素点Ｐ０およびＰｎを絶対座標で表現し、要素点Ｐ１を
要素点Ｐ０を基準とした相対座標で表現することが有効
となる。今、要素点Ｐｎの絶対座標は、４バイトで表現
できる（Ｘｎ，Ｙｎ）であると仮定して、要素点Ｐ０，
Ｐ１およびＰｎの各座標情報をオブジェクトレコードＯ
Ｒに記述すると、図１８に示すようになる。図１８にお
いて、要素点Ｐ０およびＰｎの絶対座標情報はそれぞれ
４バイトであり、要素点Ｐ１の相対座標情報は２バイト
である。さらに、絶対座標で表されたＰ０およびＰｎを
基準として、いくつの相対座標が作成されているかを示
す差分数の情報は２バイトである。以上の合計をとる
と、オブジェクトレコードＯＲのデータサイズは１２バ
イトとなる。このデータサイズは、相対座標だけで表現
した場合のオブジェクトレコードＯＲのデータサイズ１
３バイト（図１７参照）よりも小さい。

【００６５】以上、図１８を参照して説明したように、
その直前の要素点と離れて位置する要素点は絶対座標で
表現される。このように、本実施形態では、ある要素点
は、主として相対座標で表現されるが、他の要素点は絶
対座標で表現される。これによって、オブジェクトレコ
ードＯＲのデータサイズをより小さくすることが可能と
なる。

【００６６】また、上述したように、本実施形態では、
オブジェクトの境界にも、相対座標表現が適用される。
ここで、オブジェクトの境界とは、あるオブジェクトＯ
ＢＪを構成する１つの要素点Ｐからペンアップして、他
のオブジェクトＯＢＪを構成する１つの要素点Ｐにペン
ダウンする部分を意味する。かかる相対座標表現の適用
によって、本実施形態は、背景テーブルのデータサイズ
を小型化できるという技術的効果を奏する。以下には、
まず、かかる技術的効果を明確にするために、オブジェ
クトの境界に相対座標表現が適用されない場合につい
て、図１９および図２０を参照して説明する。図１９に
は、描画オブジェクトＤＯ３が示されている。描画オブ
ジェクトＢＯ３は、オブジェクトＯＢＪ３およびＯＢＪ
４から構成される。オブジェクトＯＢＪ３は、６個の要
素点Ｐ０〜Ｐ５から構成される。また、オブジェクトＯ
ＢＪ４は、４個の要素点Ｐ６〜Ｐ９から構成される。

【００６７】以上のオブジェクトＯＢＪ３は、要素点Ｐ
０→Ｐ１→Ｐ２→Ｐ３→Ｐ４→Ｐ５→Ｐ０という順番で
一筆書きされる。その後、要素点Ｐ０でペンアップが行
われ、要素点Ｐ６でペンダウンが行われる。そして、オ
ブジェクトＯＢＪ４は、要素点Ｐ６→Ｐ７→Ｐ８→Ｐ９
→Ｐ６という順番で一筆書きされる。この時、オブジェ
クトの境界で相対座標が適用されないと仮定すると、要
素点Ｐ０〜Ｐ５および要素点Ｐ６〜Ｐ９を表す座標のデ
ータ構造は、図２０に示すようになる。図２０におい
て、最初に、オブジェクトＯＢＪ３の基準点となる要素
点Ｐ０の絶対座標（Ｘ０，Ｙ０）が４バイトで記述され
る。オブジェクトＯＢＪ３の描画時には、要素点Ｐ０に
ペンダウンした後ペンアップするまでに、要素点Ｐ１〜
Ｐ５を辿ることになるので、差分数（つまり相対座標の
個数）は、５個となり、１バイトの情報である。今、要
素点Ｐ１〜Ｐ５の相対座標は、前述と同様に２バイトで
表され、（ΔＸ１，ΔＹ１）〜（ΔＸ５，ΔＹ５）であ
る。また、オブジェクトの境界部分に相対座標が適用さ
れないので、要素点Ｐ５の相対座標の後には、オブジェ
クトＯＢＪ４の基準点となる要素点Ｐ６の絶対座標（Ｘ
１，Ｙ１）が４バイトで記述される。オブジェクトＯＢ
Ｊ４の描画時には、要素点Ｐ６にペンダウンした後ペン
アップするまでに、要素点Ｐ７〜Ｐ９を辿ることになる
ので、差分数（相対座標の個数）は、３個となり、１バ
イトの情報である。要素点Ｐ７〜Ｐ９の相対座標は、
（ΔＸ６，ΔＹ６）〜（ΔＸ８，ΔＹ８）であり、２バ
イトで表される。したがって、両オブジェクトの境界に
相対座標を適用することなく、オブジェクトＯＢＪ３お
よびＯＢＪ４を相対座標列は、２６バイトで表現され
る。

【００６８】次に、オブジェクトの境界に相対座標表現
が適用される場合について、図２１および図２２を参照
して説明する。図２１には、図１９と同様に、２個のオ
ブジェクトＯＢＪ３およびＯＢＪ４から構成される描画
オブジェクトＤＯ３が示されている。描画オブジェクト
ＤＯ３は、要素点Ｐ０→Ｐ１→Ｐ２→Ｐ３→Ｐ４→Ｐ５
という順番で一筆書きされる。その後、要素点Ｐ５から
要素点Ｐ６へのペンアップおよびペンダウンが行われた
後、描画オブジェクトＤＯ３は、要素点Ｐ６→Ｐ７→Ｐ
８→Ｐ９→Ｐ６という順番で一筆書きされる。ただし、
描画時においては、一筆書きの開始点とペンアップした
点とは必ず結ぶという原則があるので、要素点Ｐ５およ
び要素点Ｐ０は線で結ばれる。以上の描画時において、
オブジェクトの境界で相対座標が適用されると仮定する
と、要素点Ｐ０〜Ｐ５および要素点Ｐ６〜Ｐ９を表す座
標のデータ構造は、図２２に示すようになる。図２２に
おいて、最初に、オブジェクトＯＢＪ３の基準点となる
要素点Ｐ０の絶対座標（Ｘ０，Ｙ０）が４バイトで記述
される。描画オブジェクトＤＯ３の描画時には、要素点
Ｐ０から一筆書きを開始から終了までに、要素点Ｐ１〜
Ｐ９を辿ることになるので、相対座標の個数、つまり差
分数は、１バイトのデータであって、「９個」を示す。
今、要素点Ｐ１〜Ｐ９の相対座標は、前述と同様に２バ
イトで表され、（ΔＸ１，ΔＹ１）〜（ΔＸ９，ΔＹ
９）である。したがって、両オブジェクトの境界に相対
座標を適用する場合には、オブジェクトＯＢＪ３および
ＯＢＪ４を相対座標列は、２３バイトで表現される。

【００６９】以上、図１９〜図２２を参照して説明した
ように、オブジェクトの境界に相対座標を適用すると、
それを適用しない場合と比較して、背景テーブルのデー
タサイズを小型化することができる。

【００７０】ここで注意を要するのは、図２０において
はオブジェクトの境界は、オブジェクトレコードＯＲに
記述された絶対座標により分かる。しかし、図２２にお
いては、オブジェクトの境界は、絶対座標からは見つけ
ることはできない。図２１に示すように、オブジェクト
の境界を規定するペンアップする要素点Ｐおよびペンダ
ウンする要素点Ｐはそれぞれ相対座標で示される場合が
あり、さらには、図１８に示したように２点間の距離が
離れている場合には、要素点Ｐが絶対座標で表現される
場合があるからである。しかしながら、図２２におい
て、オブジェクトの境界は、図１０に示された要素点数
Ｎ１〜要素点数ＮＮを参照すれば正確に規定できる。つ
まり、本実施形態では、要素点数Ｎ１〜要素点数ＮＮは
それぞれ、ペンダウンしてからペンアップするまでに一
筆書きで辿る要素点の個数を意味する。したがって、実
際の描画時において、オブジェクトレコードＯＲの先頭
から座標の個数をカウントし、カウント値が要素点数Ｎ
１と同じであれは、最初のオブジェクトの境界を正確に
特定することができる。同様に、カウント値が要素点数
Ｎ１およびＮ２の加算値と同じであれは、２回目のオブ
ジェクトの境界を特定することができる。以降、同様
に、カウント値が要素点数Ｎ１〜ＮＮの加算値と同じで
あれは、Ｎ回目のオブジェクトの境界を特定することが
できる。

【００７１】「文字記号データの詳細なデータ構造」次
に、図７に示す文字記号データについて説明する。な
お、文字記号データは本願発明の特徴的な事項ではない
ため、簡単に説明する。文字記号データとは、前述した
ように、ユニットＵがカバーする地図に記載されるべき
文字列（地名、道路名称および交差点名称等）からなる
データと、当該地図に記載されるべき地図記号からなる
データとを意味する。さらに、文字記号データは、図７
に示すように、基本文字記号テーブルと詳細文字記号テ
ーブルとから構成される。基本文字記号テーブルは、ユ
ニットＵがカバーする地図に記載される文字列または地
図記号の内、基本的な文字列および地図記号を表すデー
タを集合である。より具体的には、基本文字記号テーブ
ルには、図２３（ａ）から明らかなように、河川名称、
道路名称および地図記号等、ユニットＵがカバーする地
図を表示する際に概略となる文字列および地図記号とが
記録される。一方、詳細文字記号テーブルは、ユニット
Ｕがカバーする地図に記載される文字列または地図記号
の内、基本文字記号テーブルには記録されない文字列お
よび地図記号を表すデータを集合である。より具体的に
は、詳細文字記号テーブルには、図２３（ｂ）から明ら
かなように、公園、鉄道、橋および工場の名称等、ユニ
ットＵがカバーする地図をより詳細に表示するための文
字列および地図記号とが記録される。

【００７２】ここで、本実施形態の端末装置１として
は、上述したようにカーナビゲーションシステムが想定
されている。かかる事情から、基本文字データテーブル
には、カーナビゲーションに重要な河川名称、道路名称
および地図記号等が記録されると説明した。しかし、他
の用途の端末装置１も想定できる。そのため、基本文字
記号テーブルにどのような文字列および地図記号が記録
されるか、また、詳細文字記号テーブルにどのような文
字列および地図記号が記録されるかについては、端末装
置１の用途に依存する。それゆえに、本願発明の技術範
囲は、基本文字データテーブルには、河川名称、道路名
称および地図記号等が記録される、というように限定解
釈されてはならない。

【００７３】さて、以上の基本文字記号テーブルおよび
詳細文字記号テーブルは、図７から明らかなように、ユ
ニットデータにおいて互いに別々のフィールドに記録さ
れる。さらに、基本文字記号テーブルおよび詳細文字記
号テーブルには、相互に参照し合うような情報は一切記
録されない。つまり、基本文字テーブルを構成する文字
列または地図記号を描いている際に、詳細文字記号テー
ブルの文字列または地図記号は何一つ参照されない。逆
に、詳細文字記号テーブルを構成する文字列および地図
記号を描いている際に、基本文字記号テーブルの文字列
および地図記号は何一つ参照されない。このように、基
本文字記号テーブルおよび詳細文字記号テーブルは、相
互に独立したデータ構造を有する。したがって、文字列
および地図記号をディスプレイ上に表示する場合には、
図２３（ａ）に示すように、基本文字記号テーブルのみ
で表される文字列および地図記号を表示することが可能
になる。これによって、端末装置１のユーザは、概略的
な地図を見ることが可能になる。また、図２３（ｃ）に
示すように、基本文字記号テーブルおよび詳細文字記号
テーブルそれぞれを構成する文字列および地図記号を表
示することもできる。この場合、所定の原点を基準とし
て、基本文字記号テーブルから得られる概略的な文字列
および地図記号に、詳細文字記号テーブルから得られる
文字列および地図記号を重ねあわせることとなる。これ
によって、端末装置１のユーザは、詳細な地図を見るこ
とが可能となる。なお、本実施形態では、文字記号デー
タは基本文字記号テーブルおよび詳細文字記号テーブル
とから構成されるとして説明したが、第１の記憶装置１
９または第２の記憶装置２４に記憶容量の制限がある場
合等には、第１のデータベース１１１または第２のデー
タベース２５を小さいサイズにする観点から、文字記号
データは基本文字記号テーブルのみから構成されてもよ
い。逆に、本実施形態で説明したように、文字記号デー
タは基本文字記号テーブルおよび詳細文字記号テーブル
とから構成される場合には、センタ局２は、詳細な地図
を端末装置１に提供することが可能となり、当該端末装
置１は詳細な地図をディスプレイに表示できるようにな
る。

【００７４】上述の基本文字記号テーブルおよび詳細文
字記号テーブルの内部のデータ構造は互いに同じであ
る。以下には、基本文字記号テーブルおよび詳細文字記
号テーブルを文字記号テーブルと総称して、双方のデー
タ構造についてより詳細に説明する。

【００７５】上述したように、文字記号テーブルは、ユ
ニットＵがカバーする地図上の文字列および地図記号を
ディスプレイ上に表すためのデータの集合である。ここ
で、図２４は、文字記号テーブル、つまり基本文字記号
テーブルまたは詳細文字記号テーブルの詳細なデータ構
造を示す図である。図２４において、文字記号テーブル
は、文字記号レコード数Ｐと、Ｐ個の文字記号レコード
ＴＳＲ１〜ＴＳＲＰとから構成される。文字記号レコー
ド数Ｐは、文字記号テーブルに含まれる文字記号レコー
ドＴＳＲ１〜ＴＳＲＰの個数を示す情報である。ここ
で、Ｐは、１以上の自然数であって、ユニットＵがカバ
ーする地図上の文字列および地図記号の総数である。文
字記号レコードＴＳＲ１〜ＴＳＲＰは、ユニットＵがカ
バーする地図上の文字列または地図記号の数だけ作成さ
れる。文字記号レコードＴＳＲ１は、文字記号属性と、
ポイント座標と、文字記号コードとから構成される。

【００７６】文字記号属性は、文字記号レコードＴＳＲ
１により表されるべき文字列または地図記号の属性を示
す情報である。文字記号属性には、文字列または当該地
図記号のサイズと、文字列が並ぶ方向（縦／横）とを示
す情報が記録される。ここで注意を要するのは、地図記
号は、複数の記号により１つの対象物を表すことがほと
んどなく、さらに、１つの文字で表される地名もある。
かかる場合には、文字列が並ぶ方向（縦／横）を示す情
報が文字記号属性に記録される必要性は特にない。ポイ
ント座標は、文字記号レコードＴＳＲ１により表される
べき文字列または地図記号がユニットＵ上のどの位置に
表示されるかを特定するための座標情報である。文字記
号レコードＴＳＲ１により表されるべき文字列等は、デ
ィスプレイ上において、ポイント座標により特定される
位置に表示される。また、文字記号コードは、文字記号
レコードＴＳＲ１により表されるべき文字列および地図
記号のコード番号である。文字列のコード番号として
は、日本国ではシフトＪＩＳコードが典型的であり、文
字記号属性に記録された文字列の大小を表すサイズに該
当する情報が記録される。ここで、地図記号は、シフト
ＪＩＳ等のように、それに関連する規格がないので、独
自に作成される。さらに、作成された地図記号のコード
番号としては、日本国ではシフトＪＩＳの空きコード番
号が割り当てられる。割り当てられたコード番号が、文
字記号コードとして記録される。なお、他の文字記号レ
コードＴＳＲ２〜ＴＳＲＰは、文字記号レコードＴＳＲ
１と同様のデータ構造を有するので、それぞれの説明を
省略する。

【００７７】「道路ネットワークデータの詳細なデータ
構造」次に、図７に示す道路ネットワークデータについ
て説明する。道路ネットワークデータは、カーナビゲー
ションシステムとしての端末装置１において、ディスプ
レイ上に道路を表示するために使用されるだけでなく、
マップマッチング、経路探索処理または経路案内処理に
も使用される。そのため、道路ネットワークデータは、
前述したように、ユニットＵがカバーする地図に表され
るべき道路そのものを表す図形データ、および道路同士
のつながりを表すデータの集合を意味する。より具体的
には、道路ネットワークデータはマップマッチング等に
使用されるため、当該道路ネットワークデータには、単
に、道路網の形状を表す図形データが記録されるだけで
はなく、ユニットＵがカバーする範囲の地図に表される
道路同士の接続関係を示すデータも記録される。

【００７８】以上の道路ネットワークデータは、図７に
示すように、第１のネットワークデータと第２のネット
ワークデータとから構成される。第１のネットワークデ
ータには、主要幹線道路の道路ネットワークデータが記
録される。主要幹線道路とは、例えば、以下の３つの条
件のいずれかを満たすものを意味する。まず、第１の条
件は、地方自治体およびそれよりも上位の行政機関が造
った道路（高速道路、国道）であることである。第２の
条件は、地方自治体よりも下位の行政機関が造った道路
（高速道路、国道）および私道であって、かつその幅員
が５．５ｍ以上の道路であることである。第３の条件
は、上記第１および第２の条件に該当する道路に接続さ
れた道路であることである。また、第２のネットワーク
データには、細街路の道路ネットワークデータが記録さ
れる。細街路とは、その幅員が３．０ｍ以上であって、
主要幹線道路に該当しない道路（例えば、住宅の周辺に
造られた道路）を意味する。ただし、上記の主要幹線道
路および細街路の定義は単なる一例であって、他の定義
を採用しても構わない。それゆえに、本願発明の技術範
囲は、第１および第２の道路ネットワークデータには、
上記定義にのみ該当する道路ネットワークデータが記録
される、というように限定解釈されてはならない。

【００７９】次に、第１の道路ネットワークデータおよ
び第２の道路ネットワークデータの関係について、図２
５を参照して説明する。第１の道路ネットワークデータ
は、主要幹線道路の道路ネットワークデータである。そ
のため、第１の道路ネットワークデータが端末装置１の
ディスプレイに表示されると、図２５（ａ）に示すよう
に、主要幹線道路を表す図形が表示される。一方、第２
の道路ネットワークデータは、細街路の道路ネットワー
クデータである。そのため、第２の道路ネットワークデ
ータが端末装置１のディスプレイに表示されると、図２
５（ｂ）に示すように、細街路を表す図形が表示され
る。これら第１および第２の道路ネットワークデータ
は、図７から明らかなように、ユニットデータにおいて
互いに別々に記録される。したがって、図２５（ａ）に
示すように、第１の道路ネットワークデータを構成する
主要幹線道路のみを端末装置１のディスプレイに表示す
ることが可能になる。これによって、端末装置１のユー
ザは、概略的な道路ネットワークを見ることが可能にな
る。また、図２５（ｃ）に示すように、第１および第２
の道路ネットワークデータを構成する主要幹線道路およ
び細街路を表示することもできる。この場合、所定の原
点を基準として、第１の道路ネットワークデータから得
られる主要幹線道路網の上に、第２の道路ネットワーク
データから得られる細街路の道路網を重ねあわせること
となる。これによって、端末装置１のユーザは、詳細な
道路網を見ることが可能となる。なお、本実施形態で
は、道路ネットワークデータは、第１および第２の道路
ネットワークデータから構成されるとして説明したが、
第１の記憶装置１９または第２の記憶装置２４に記憶容
量の制限がある場合等には、第１のデータベース１１１
または第２のデータベース２５を小さいサイズにする観
点から、道路ネットワークデータは、第１の道路ネット
ワークデータのみから構成されてもよい。逆に、本実施
形態で説明したように、道路ネットワークデータが第１
および第２の道路ネットワークデータから構成される場
合には、センタ局２は、詳細な道路網を端末装置１に提
供することが可能となり、当該端末装置１は詳細な道路
網をディスプレイに表示できるようになる。

【００８０】上述の第１および第２の道路ネットワーク
データのデータ構造は互いに同じである。以下には、第
１および第２の道路ネットワークデータのデータ構造に
ついてより詳細に説明する。周知のように、道路ネット
ワークデータは、主として、ノードとリンクにより構成
される。ノードとは、主として、交差点または道路の区
切りを表現するためのデータを意味する。また、リンク
とは、２個の交差点の間をつなぐ道路を表現するための
データである。かかるノードとリンクを用いることによ
り、ユニットＵがカバーする地図上に表されるべき道路
（主要幹線道路または細街路）の形状および道路同士の
接続関係が端末装置１のディスプレイ上に表示される。
そのため、図７に示すように、第１の道路ネットワーク
データは、第１のノードテーブルおよび第１のリンクテ
ーブルから構成され、第２の道路ネットワークデータ
は、第２のノードテーブルおよび第２のリンクテーブル
から構成される。以下には、まず、第１および第２のノ
ードテーブルのデータ構造をまず説明する。

【００８１】ここで、図２６は、ノードおよびリンクの
概念を説明するための図である。図２６には、１つのユ
ニットＵがカバーする範囲に存在する道路網が示されて
いる。図２６の道路網は、１１個のノードＮ０〜Ｎ１０
と、１１個のリンクＬ０〜Ｌ１０とから構成される。１
１個のノードＮ０〜Ｎ１０は、非隣接ノードと隣接ノー
ドとに大別される。非隣接ノードとは、通常の交差点、
もしくは道路の種別または属性が変わる点（上述の道路
の区切りに相当する）に作成されるノードであり、ユニ
ットＵ内での道路の接続関係を表す分岐点を意味する。
ところで、図２６のユニットＵには、同じレベルに属し
かつ隣接するユニットＵがいくつかある（図２参照）。
したがって、１本の道路が、互いに隣り合う複数のユニ
ットＵにまたがる場合がある。以下では、図２６のユニ
ットＵに隣接するユニットＵのことを、便宜上、隣接ユ
ニットＮＵと称する。図２６には、隣接ユニットＮＵの
１つが点線にて示されている。隣接ノードは、図２６の
ユニットＵおよび隣接ユニットＮＵの間をまたがる道路
が存在する場合に、当該ユニットＵの境界（つまり矩形
領域の辺）上に作成されるノードであり、当該ユニット
Ｕと隣接ユニットＮＵとの道路の接続関係を表す点を意
味する。以上の定義に従うと、図２６のノードＮ１、Ｎ
２、Ｎ５およびＮ８の４つ（○印参照）が非隣接ノード
に分類される。また、ノードＮ０、Ｎ３、Ｎ４、Ｎ６、
Ｎ７、Ｎ９、Ｎ１０の７つ（●印参照）が隣接ノードに
分類される。ここで注意を要するのは、交差点または道
路の区切りを表すノードＮがユニットＵの境界上に存在
する場合には、当該ノードＮを隣接ノードと分類する
か、非隣接ノードと分類するかが問題となる。かかる場
合、交差点または道路の区切りを表すノードＮを境界上
からずらして、新しい非隣接ノードを作成することが１
つの対処方法である。他の対処方法として、ユニットＵ
の境界上の交差点または道路の区切りと同じ座標上に非
隣接ノードを作成することがある。以上から明らかなよ
うに、ユニットＵの境界上には隣接ノードが作成されて
はならない。

【００８２】図２７は、第１のノードテーブルの詳細な
データ構造を示す図である。ここで、予め断っておく
が、第１および第２のノードテーブルは、互いに同様の
データ構造を有しており、主要幹線道路および細街路に
ついて作成される点で相違する。そのため、説明の簡素
化の観点から、第２のノードテーブルの詳細な説明を省
略する。さて、図２７において、第１のノードテーブル
は、隣接ノード数Ｑと、非隣接ノード数Ｒと、（Ｑ＋
Ｒ）個のノードレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）とから
構成される。隣接ノード数Ｑは、第１のノードテーブル
に含まれる隣接ノードの個数を示す情報である。ここ
で、Ｑは、１以上の自然数であって、ユニットＵにより
表される地図上の道路網に隣接ノードがいくつ存在する
かを示す。非隣接ノード数Ｒは、第１のノードテーブル
に含まれる非隣接ノードの個数を示す情報である。ここ
で、Ｒは、１以上の自然数であって、ユニットＵにより
表される地図上の道路網に非隣接ノードがいくつ存在す
るかを示す。

【００８３】ノードレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）
は、ユニットＵにより表される地図上の道路網に存在す
るノードＮの数だけ作成される。ノードレコードＮＲ１
〜ＮＲ（Ｑ＋Ｒ）には、（Ｑ＋Ｒ）個のノードＮに関連
する情報が記録される。次に、本実施形態におけるノー
ドレコードＮＲ１〜ＮＲ（Ｑ＋Ｒ）の並べ方について説
明する。第１のノードテーブルにおいて、最初のＱ個の
ノードレコードＮＲ１〜ＮＲＱには、Ｑ個の隣接ノード
に関連する情報が記録され、後のＲ個のノードレコード
ＮＲ（Ｑ＋１）〜ＮＲＲには、Ｒ個の非隣接ノードに関
連する情報が記録される。また、Ｑ個のノードレコード
ＮＲ１〜ＮＲＱにおいて、先頭から順番に、矩形領域
（ユニットＵ）の左辺上に存在する隣接ノード（図２６
の参照）に関連する情報が記録される。次に、矩形領
域の上辺上に存在する隣接ノード（図２６の参照）に
関連する情報が記録される。次に、矩形領域の右辺上に
存在する隣接ノード（図２６の参照）に関連する情報
が記録される。最後に、矩形領域の下辺上に存在する隣
接ノード（図２６の参照）に関連する情報が記録され
る。また、上記右辺上または左辺上の隣接ノードのノー
ドレコードＮＲは、当該隣接ノードの緯度が昇順になる
よう並べられる。一方、上記右辺上または左辺上の隣接
ノードのノードレコードＮＲは、当該隣接ノードの経度
が昇順になるよう並べられる。

【００８４】さらに、非隣接ノードのノードレコードＮ
Ｒは、最初に、当該非隣接ノードの緯度が昇順になるよ
うに並べられる。この時、同じ緯度の非隣接ノードが複
数存在した場合には、ノードレコードＮＲは、当該非隣
接ノードの経度が昇順になるように並べられる。

【００８５】図２６のノードＮ０〜Ｎ１０に関して、上
記の並べ方に従うと、図２８に示すように、先頭のノー
ドレコードＮＲ１には、隣接ノードＮ６の情報が記録さ
れる。次のノードレコードＮＲ２には、隣接ノードＮ０
の情報が記録される。ノードレコードＮＲ３、ＮＲ４、
ＮＲ５、ＮＲ６およびＮＲ７には、隣接ノードＮ４、Ｎ
７、Ｎ１０、Ｎ３およびＮ９の情報が記録される。ここ
で、図２８中の〜は、図２６の〜に対応してお
り、隣接ノードが並べられる順位を示している。次のノ
ードレコードＮＲ８には、非隣接ノードＮ８の情報が記
録される。ノードレコードＮＲ９、ＮＲ１０およびＮＲ
１１には、非隣接ノードＮ５、Ｎ２およびＮ１の情報が
記録される。以上のように、本実施形態では、ユニット
Ｕに含まれるノードＮの情報は、ランダムにではなく、
上述した規則に従った順番でノードレコードＮＲに記録
されていく。ここで、以下の説明において、ノードレコ
ード番号とは、最初のノードレコードＮＲ１を「０」と
して、各ノードレコードＮＲ２以降が何番目に記録され
ているかを特定する番号を意味する。以上のノードレコ
ード番号を図２８のノードレコードＮＲ１〜ＮＲ１１に
当てはめると、当該ノードレコードＮＲ１〜ＮＲ１１の
ノードレコード番号は「０」〜「１０」となる。なお、
以上のような並べ方は、ユニットＵと隣接ユニットＮＵ
の間にまたがる道路の接続関係をたどる処理を高速に行
ったり、ユニットＵの親子間におけるノードやリンクの
対応づけを的確に行ったりできるという効果を生むが、
これらの具体的な処理および効果については後述する。

【００８６】さて、再度図２７を参照して、ノードレコ
ードＮＲ１の内部データ構造を詳細に説明する。ノード
レコードＮＲ１は、ノード属性と、ノード座標と、ノー
ド接続情報とから構成される。ノード属性は、ノードレ
コードＮＲ１に記録されるノードの属性を表すための情
報である。ノード属性の例としては、記録されたノード
に交差点での交通が規制されているか否かを示す情報、
当該ノードにより表される交差点に名称があるか否かを
示す情報、当該ノードにより表される交差点に信号機が
存在するか否か等の情報がある。なお、ノード属性に交
通規制または交差点名称の有無に関する情報を記録する
場合には、本実施形態では説明しない交差点規制テーブ
ルおよび交差点名称テーブル等のテーブルを別途作成
し、該当する情報を記録するようにする。

【００８７】また、ノード座標は、ノードレコードＮＲ
１に記録されるノードの経度方向の座標および緯度方向
の座標を表すための情報である。ノードの経度方向の座
標および緯度方向の座標としては、絶対経度緯度座標を
記録しても良いが、記録されるノードを含むユニットＵ
（矩形領域）の左下隅を基準点として、当該ユニットＵ
がカバーする範囲の経度幅および緯度幅を２バイト程度
の値で正規化した座標で表すのが一般的である。例え
ば、図２９に示すように、ユニットＵの左下隅Ｎａの座
標を（００００ｈ，００００ｈ）と表現し（ｈは１６進
数の値を表す）、当該ユニットＵの座標系を経度方向お
よび緯度方向共に８０００ｈで正規化する。この場合、
ユニットの左上隅Ｎｂの座標は（００００ｈ，８０００
ｈ）と表現される。また、ユニットの右下隅Ｎｃの座標
は（８０００ｈ，００００ｈ）と表現される。さらに、
ユニットの右上隅Ｎｄの座標は（８０００ｈ，８０００
ｈ）で表現される。また、ノード接続情報は、ノードレ
コードＮＲ１に記録されるノードＮと、後述するリンク
レコードＬＲに記録されるリンクＬとの接続関係を表す
情報である。ノード接続情報の詳細については後述す
る。なお、他のノードレコードＮＲ２〜ＮＲ（Ｑ＋Ｒ）
の内部データ構造については、ノードレコードＮＲ１と
同様であるため説明を省略する。ただし、他のノードレ
コードＮＲ２〜ＮＲ（Ｑ＋Ｒ）には、互いに異なるノー
ドＮの情報が記録される。

【００８８】次に、図７の第１のリンクテーブルのデー
タ構造を説明する。ここで、予め断っておくが、第１お
よび第２のリンクテーブルは、同様のデータ構造を有し
ており、主要幹線道路および細街路について作成される
点で相違する。そのため、以降では、第２のリンクテー
ブルの詳細な説明を省略する。図３０は、第１のリンク
テーブルの詳細なデータ構造を示す図である。図３０に
おいて、第１のリンクテーブルは、道路数Ｓと、Ｍ個の
道路レコードＲＲ１〜ＲＲＭとから構成される。道路数
Ｓは、第１のノードテーブルにより表される道路網に含
まれる道路の本数を示す情報である。ここで、Ｓは、１
以上の自然数であって、ユニットＵにより表される地図
上の道路網に道路が何本存在するかを示す。道路レコー
ドＲＲ１には、ある１つの道路属性が割り当てられ、当
該道路属性が同じリンクＬおよびノードＮに関する情報
が記録される。また、道路レコードＲＲ２には、他の１
つの道路属性が割り当てられ、当該道路属性が同じリン
クＬおよびノードＮに関する情報が記録される。以降、
同様に、道路レコードＲＲＳには、他の道路レコードＲ
Ｒ１〜ＲＲ（Ｓ−１）には割り当てられていない１つの
道路属性が割り当てられ、当該道路属性が同じリンクＬ
およびノードＮに関する情報が記録される。以上から明
らかなように、道路レコードＲＲ１〜ＲＲＳには、互い
に異なる道路属性が割り当てられる。ここで、道路属性
とは、道路の種別毎に分類するための情報である。典型
的には、道路は、高速道路、国道、県道、市道、私道等
といった区分で分類され、さらには、各道路の名称によ
ってより詳細に分類される。なお、必要に応じて、道路
の一方通行規制等を道路属性に採用してもよい。

【００８９】道路レコードＲＲ１は、道路属性と、リン
ク数Ｔ１と、先頭ノードレコード番号と、Ｔ１個のリン
クレコードＬＲ１〜ＬＲＴ１とから構成される。道路属
性には、道路種別（高速道路、国道、県道等）、道路の
一方通行規制等を示す情報が記録される。リンク数Ｔ１
は、道路レコードＲＲ１に記録されるリンクＬの個数を
示す情報である。ここで、Ｔ１は、１以上の自然数であ
って、ユニットＵにより表される地図上の道路網におい
て、道路属性の情報に該当するリンクＬが何個存在する
かを示す情報である。先頭ノードレコード番号は、所定
のノードレコードＮＲを特定するためのノードレコード
番号を意味する。このノードレコード番号は、図２８等
を参照して上述したように、最初のノードレコードＮＲ
１を「０」として、各ノードレコードＮＲ２以降が何番
目に記録されているかを特定する番号である。さらに、
所定のノードレコードＮＲとは、道路レコードＲＲ１に
より表される道路網の先頭に位置するノードＮが記録さ
れたものを意味する。また、リンクレコードＬＲ１に
は、ユニットＵにより表される地図上の道路網におい
て、道路属性により分類されるリンクＬの内のある１つ
に関する情報が記録される。そのために、リンクレコー
ドＬＲ１は、リンク属性と、リンク接続情報とから構成
される。リンク属性とは、リンクレコードＬＲ１により
表されるリンクＬの属性を示す情報である。リンク属性
の典型例としては、リンク種別（本線リンクであるか、
側道リンクであるか等）または車線数等がある。また、
リンク接続情報は、リンクレコードＬＲ１により表され
るリンクＬに接続されたノードＮ、またはリンクレコー
ドＬＲ１により表されるリンクＬとノードＮを介してつ
ながっているリンクＬの情報である。また、リンクレコ
ードＬＲ２には、道路属性により分類されるリンクＬの
内の他の１つに関する情報が記録される。以降同様に、
リンクレコードＬＲＴ１には、道路属性により分類され
るリンクＬの内、他のリンクレコードＬＲ（Ｔ１−１）
に記録されていない１つのリンクＬに関する情報が記録
される。ここで、リンクレコードＬＲ２〜ＬＲＴは、リ
ンクレコードＬＲ１と同様に、リンク属性と、リンク接
続情報とから構成される。以上から明らかなように、リ
ンクレコードＬＲ１〜ＬＲＴ１には、互いに異なるリン
クＬに関する情報が記録される。

【００９０】さて、次に、第１のリンクテーブルに記載
される情報の具体例を、図２６の道路網の場合について
具体的に説明する。上述したように、図２６の道路網
は、１１個のノードＮ０〜Ｎ１０と、１１個のリンクＬ
０〜Ｌ１０とから構成される。また、説明をより具体的
にするために、リンクＬ０〜Ｌ２は、ノードＮ０を先頭
として、Ｌ０→Ｌ１→Ｌ２の順番で接続されることによ
り、１本の道路（例えば、国道）を構成すると仮定す
る。この仮定下では、リンクＬ０〜Ｌ２は互いに同一の
道路属性（国道）を有する。リンクＬ３〜Ｌ５は、ノー
ドＮ４を先頭として、Ｌ３→Ｌ４→Ｌ５の順番で接続さ
れることにより、１本の道路（例えば、県道）を構成す
ると仮定する。この仮定下では、リンクＬ３〜Ｌ５は互
いに同一の道路属性（県道）を有する。リンクＬ６〜Ｌ
８は、ノードＮ７を先頭として、Ｌ６→Ｌ７→Ｌ８の順
番で接続されることにより、１本の道路（例えば、幅員
が５．５ｍ以上の私道）を構成すると仮定する。この仮
定下では、リンクＬ６〜Ｌ８は互いに同一の道路属性
（私道）を有する。リンクＬ９およびＬ１０は、ノード
Ｎ５を先頭として、Ｌ９→Ｌ１０の順番で接続されるこ
とにより、１本の道路（例えば、市道）を構成すると仮
定する。この仮定下では、リンクＬ９およびＬ１０は互
いに同一の道路属性（市道）を有する。

【００９１】以上の仮定下では、道路は、国道、県道、
私道および市道の４本であるから、第１のリンクテーブ
ルの道路数Ｓとして、「４」が記録される。また、道路
属性としては、国道、県道、私道および市道の４種類が
あるので、第１のリンクテーブルには、４個の道路レコ
ードＲＲ１〜ＲＲ４が記録される。まず、道路レコード
ＲＲ１について説明する。道路属性としては「国道」を
表す情報が記録される。また、リンク数Ｔ１としては、
国道がリンクＬ０〜Ｌ２で構成されることから「３」を
示す情報が記録される。また、リンクＬ０〜Ｌ２で表さ
れる道路の先頭は、ノードＮ０により表される。ノード
Ｎ０のレコード番号は「１」である（図２８参照）。ゆ
えに、先頭ノードＮの番号としては「１」が記録され
る。次に、リンクレコードＬＲ１１（リンクＬ０のレコ
ード）において、リンク属性については説明を省略す
る。

【００９２】さて、ここで、各リンクレコードＬＲに記
録されるリンク接続情報、および図２７に示されるノー
ド接続情報を説明する。同時に、ノードＮとリンクＬの
接続関係をたどる処理についても説明する。例えば、図
２６に示すように、ノードＮ２はリンクＬ１、Ｌ２、Ｌ
６、およびＬ７の４本と接続している。このように、各
ノードＮ２を中心として、４本のリンクＬ１、Ｌ２、Ｌ
６およびＬ７がつながっている。また、ノードレコード
ＮＲ１０には、ノードＮ２に関連する情報が記録される
（図２７参照）。また、リンクレコードＬＲ１２、ＬＲ
１３、ＬＲ３１およびＬＲ３２には、リンクＬ１、Ｌ
２、Ｌ６およびＬ７に関連する情報が記録される（図３
１参照）。ノードレコードＮＲ１０のノード接続情報
（図２７参照）、および各リンクレコードＬＲ１２、Ｌ
Ｒ１３、ＬＲ３１およびＬＲ３２のリンク接続情報（図
３１参照）には、ノードＮ２に接続されたリンクＬ１、
Ｌ２、Ｌ６およびＬ７をたどるための情報が記録され
る。まず、ノードレコードＮＲ１０には、ノード接続情
報として、ノードＮ２に接続された最初のリンクＬ
（今、仮にリンクＬ１とする）が記録されたリンクレコ
ードＬＲ１２を参照するための情報が記録される。より
具体的には、ノード接続情報としては、リンクテーブル
の先頭からリンクレコードＬＲ１２までのオフセットア
ドレスを記録しても良いし、リンクレコードＬＲ１２の
リンクレコード番号を記録しても良い。ここで、リンク
レコード番号とは、リンクテーブルにおいて最初のリン
クレコードＬＲ１１を「０」として、リンクレコードＬ
Ｒ１２以降が何番目に記録されているかを特定する番号
を意味する。以上のリンクレコード番号を図３１のリン
クレコードＬＲに当てはめると、リンクレコードＬＲ１
１〜ＬＲ１３のリンクレコード番号は「０」〜「３」と
なる。また、リンクレコードＬＲ２１〜ＬＲ２３のリン
クレコード番号は「４」〜「６」となる。また、リンク
レコードＬＲ３１〜ＬＲ３３のリンクレコード番号は
「７」〜「９」となる。さらに、リンクレコードＬＲ４
１およびＬＲ４２のリンクレコード番号は「１０」およ
び「１１」となる。

【００９３】ここで注意を要するのは、ノード接続情報
には、同じユニットＵ内の道路網の接続をたどる場合に
限り、オフセットアドレスおよびリンクレコード番号が
記録される。同様に、リンク接続情報には、同じユニッ
トＵ内の道路網の接続をたどる場合に限り、オフセット
アドレスおよびノードレコード番号が参照される。詳し
くは図３７および図３８を参照して説明するが、あるユ
ニットＵおよび隣接ユニットＮＵの境界をまたぐような
道路網の接続をたどる場合には、オフセットアドレスお
よびリンクレコードは参照されない。

【００９４】図３２の例では、ノードレコードＮＲ１０
のノード接続情報には、当該ノードレコードＮＲ１０か
ら、リンクテーブルのリンクレコードＬＲ１２を参照可
能なように、当該リンクレコードＬＲ１２までのオフセ
ットアドレスまたは当該リンクレコードＬＲ１２のリン
クレコード番号が記録される。また、図３２の例では、
リンクレコードＬＲ１２からはリンクレコードＬＲ３２
が参照されるので、リンクレコードＬＲ１２のリンク接
続情報には、リンクＬ１と接続する他のリンクＬ６を参
照可能なように、当該リンクレコードＬＲ３２へのオフ
セットアドレスまたは当該リンクレコードＬＲ３２のリ
ンクレコード番号が記録される。かかるノードレコード
ＮＲ１０のノード接続情報およびリンクレコードＬＲ１
２のリンク接続情報により、リンクＬ１はノードＮ２を
起点として、リンクＬ６と接続していることが分かる。

【００９５】ここで注意を要するのは、リンクレコード
ＬＲ１２のリンク接続情報としては、リンクレコード番
号やオフセットアドレスだけでなく、当該リンク接続情
報が他のリンクＬに対してであることを示すフラグを記
録しておく。さらに注意を要するのは、同一道路レコー
ドＲＲ内で記録されるリンクＬを参照するためのリンク
接続情報は、各リンクレコードＬＲには記録されない。
同一道路レコードＲＲに属するリンクＬ同士は、リンク
接続情報を参照しなくとも、リンクレコードＬＲの並び
方によりたどることができるからである。つまり、道路
レコードＲＲ１においてリンクレコードＬＲ１１とリン
クレコードＬＲ１２とは、連続するアドレス領域に並べ
て記録されるため、リンクＬ１およびリンクＬ２は相互
に接続していると判断することができる。同様に、道路
レコードＲＲ３において、リンクレコードＬＲ３１およ
びＬＲ３２は連続アドレス領域に並べて記録されるた
め、リンクＬ６とリンクＬ７とは相互に接続していると
判断することができる。

【００９６】さて、リンクレコードＬＲ１２の次に参照
されるリンクレコードＬＲ３１に記録されたリンクＬ６
は、道路レコードＲＲ１以外に区分されたリンクＬとは
接続されていない。そのため、リンクレコードＬＲ３２
のリンク接続情報としては、リンクＬ１、Ｌ２、Ｌ６お
よびＬ７の中心に位置するノードＮ２が記録されたノー
ドレコードＮＲ１０を参照可能な情報が記録される。リ
ンクレコードＬＲ３２のリンク接続情報としても、ノー
ドレコードＮＲ１０へのオフセットアドレスまたは当該
ノードレコードＮＲ１０のノードレコード番号が用いら
れる。ここで注意を要するのは、リンクレコードＬＲ３
２のリンク接続情報としては、ノードレコードＮＲ１０
のノードレコード番号またはオフセットアドレスだけで
なく、当該リンク接続情報がノードテーブルＮＲに対し
て設定されていることを示すフラグも記録される。

【００９７】以上のように、各ノードレコードＮＲに
は、最初に接続するリンクＬへのノード接続情報のみを
記録し、各リンクレコードＬＲには、そこに記録される
リンクＬに接続する他の道路レコードＲＲ内のリンクＬ
へのリンク接続情報、もしくは起点となったノードＮが
記録されるノードレコードＮＲへのリンク接続情報を記
録することによって、各ノードＮを起点としたリンクＬ
の接続をたどることができる。

【００９８】「ユニットヘッダのデータ構造」さて、再
度図７を参照して、ユニットヘッダのデータ構造につい
て詳細に説明する。ユニットヘッダには、地図ファイル
ＣＦのユニットデータの管理情報が記録される。ユニッ
トヘッダは、少なくともユニットＩＤ、バージョンコー
ド、およびユニットデータを構成する８種類のテーブル
のデータサイズから構成される。ユニットＩＤは、当該
地図ファイルＣＦにより表されるユニットＵを一意に特
定できる識別番号である。より具体的には、ユニットＩ
Ｄは、ユニットＵのレベルＬ、およびユニットＵの親子
関係および隣接関係が特定できる番号であり、地図ファ
イルＣＦのパス名と相互に変換できるものが望ましい。
例えば、ユニットＩＤを３２ビット（４バイト）のコー
ドで表現するとし、ＭＳＢから２ビットをリザーブビッ
トとし、順にユニットレベルＬを２ビット、レベル
「３」の経度方向の分割位置Ｘ３を５ビット、レベル
「３」の緯度方向の分割位置Ｙ３を５ビット、レベル
「２」の経度方向の分割位置Ｘ２を３ビット、レベル
「２」の緯度方向の分割位置Ｙ２を３ビット、レベル
「１」の経度方向の分割位置Ｘ１を３ビット、レベル
「１」の緯度方向の分割位置Ｙ１を３ビット、レベル
「０」の経度方向の分割位置Ｘ０を３ビット、レベル
「０」の緯度方向の分割位置Ｙ０を３ビットで表す。こ
こで、レベル「３」の経度方向の分割位置Ｘ３は、ユニ
ットＵがレベル「３」に属するとした場合に東経方向に
数えて何番目（起算点は経度０度）に位置するかを示す
数である。レベル「３」の緯度方向の分割位置Ｙ３は、
ユニットＵがレベル「３」に属するとした場合に北緯方
向に数えて何番目（起算点は北緯０度）に位置するかを
示す数である。レベル「２」の経度方向の分割位置Ｘ２
は、ユニットＵがレベル「２」に属するとした場合に東
経方向に数えて何番目（起算点はレベル「３」のユニッ
トＵの左下）に位置するかを示す数である。レベル
「２」の緯度方向の分割位置Ｙ２は、ユニットＵがレベ
ル「２」に属するとした場合に北緯方向に数えて何番目
（起算点はレベル「３」のユニットＵの左下）に位置す
るかを示す数である。レベル「１」の経度方向の分割位
置Ｘ１は、ユニットＵがレベル「１」に属するとした場
合に東経方向に数えて何番目（起算点はレベル「２」の
ユニットＵの左下）に位置するかを示す数である。レベ
ル「１」の緯度方向の分割位置Ｙ１は、ユニットＵがレ
ベル「１」に属するとした場合に北緯方向に数えて何番
目（起算点はレベル「２」のユニットＵの左下）に位置
するかを示す数である。レベル「０」の経度方向の分割
位置Ｘ０は、ユニットＵがレベル「０」に属するとした
場合に東経方向に数えて何番目（起算点はレベル「１」
のユニットＵの左下）に位置するかを示す数である。レ
ベル「０」の緯度方向の分割位置Ｙ０は、ユニットＵが
レベル「０」に属するとした場合に北緯方向に数えて何
番目（起算点はレベル「１」のユニットＵの左下）に位
置するかを示す数である。

【００９９】例えば、図４に示すレベル「０」のユニッ
トＵ₀ のパス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１
￥Ｄ０５０３￥Ｍ０２０１．ｍａｐ」であるため、前述
のＬ＝０、Ｘ３＝１６、Ｙ３＝６、Ｘ２＝４、Ｙ２＝
１、Ｘ１＝５、Ｙ１＝３、Ｘ０＝２、Ｙ０＝１となる。
この場合、ユニットＵ₀ のユニットＩＤは、１３５９２
８５２９（１０進数表記）となる。以上から明らかなよ
うに、地図ファイルＣＦのパス名からユニットＩＤを一
意に特定することができ、逆にユニットＩＤからパス名
を一意に特定することができる。

【０１００】またバージョンコードは、地図ファイルＣ
Ｆ（ユニットＵ）のバージョンを表すための識別コード
であり、例えば、当該ユニットのフォーマットバージョ
ンを表すコードを２バイト、当該ユニットのコンテンツ
バージョンを表すコードを２バイト等で記述した、合計
４バイトのコードで表すものとする。このバージョンコ
ードは、センタ局２からあるユニットＩＤの地図ファイ
ルＣＦが端末装置１にダウンロードされた際に、端末装
置１の第１の記憶装置１９に既に格納されている同一ユ
ニットＩＤの地図ファイルＣＦと置き換えるか否かの判
断等に使用される。なお、この際の詳細な処理について
は後述する。

【０１０１】また、各テーブルのデータサイズには、地
図ファイルＣＦを構成する各テーブルのデータサイズが
記録されており、それぞれは例えば２バイトで表され
る。各テーブルのデータサイズを順に加算していくこと
により、各テーブルが格納されている、地図ファイルＣ
Ｆの先頭からのオフセットアドレスが算出可能となる。
なお、各テーブルのデータサイズとしては、基本背景テ
ーブルのデータサイズ、詳細背景テーブルのデータサイ
ズ、基本文字記号テーブルのデータサイズ、詳細文字記
号テーブルのデータサイズ、第１のノードテーブルのデ
ータサイズ、第１のリンクテーブルのデータサイズ、第
２のノードテーブルのデータサイズ、第２のリンクテー
ブルのデータサイズが並ぶ。それぞれのテーブルの内容
については上述した通りである。

【０１０２】以上、地図ファイルＣＦの詳細なデータ構
造について説明した。次に、第１のデータベース１１１
から地図ファイルＣＦを読み出す際の端末装置１の動作
について、図面を参照して説明する。 「読み出し処理」図１を参照して説明したように、本実
施形態の端末装置１は、典型的にはカーナビゲーション
システムである。周知のように、マップマッチング、経
路探索、または経路案内等の処理が実行される。以下に
は、これらの処理の内、経路探索処理に関連して、地図
ファイルＣＦを読み出す処理、あるユニットＵと隣接ユ
ニットＮＵにまたがる道路の接続をたどる処理、および
階層間でのノードＮとリンクＬとの対応づけを行う処理
について詳細に説明する。なお、以下では、出発地およ
び目的地の間の最短ルートを求める処理そのものについ
ては本願発明のポイントではないため特に説明しない。

【０１０３】図３３は、経路探索処理の概念を示す図で
ある。図３３に示すように、最短ルートを求める処理で
は、出発地ＳＰ側と目的地ＤＰ側の両方向から探索が広
げられる。さらに、経路探索処理では、下位階層から上
位階層までの複数階層の地図ファイルＣＦが用いられ
る。この時、出発地ＳＰおよび目的地ＤＰ周辺では、詳
細な道路網を表す下位階層の地図ファイルＣＦを用い
て、最短ルートが探索される。一方、出発地ＳＰおよび
目的地ＤＰ周辺以外では、粗い道路網を表す上位階層の
地図ファイルＣＦが用いられる。以上の図３３に示す経
路探索処理では、いわゆる双方向階層別探索の手法が用
いられる。また、地図ファイルＣＦを用いて、出発地Ｓ
Ｐから目的地ＤＰへの最短ルートを求める場合には、周
知のダイクストラ法等が使用される。なお、ダイクスト
ラ法については、本願発明のポイントではなく、かつ周
知の技術であるため、これ以上説明しない。

【０１０４】以下、図３４のフローチャートを参照し
て、端末装置１で実行される双方向階層別探索の処理手
順を詳細に説明する。まず、双方向階層別探索では、端
末装置１の出発地ＳＰおよび目的地ＤＰの設定が実行さ
れる（ステップＳ１０１，Ｓ１０２）。ステップＳ１０
１およびＳ１０２において、出発地ＳＰおよび目的地Ｄ
Ｐは、出力装置１１０のディスプレイに表示されるメニ
ューに従って、端末装置１のユーザが入力装置１１を操
作することにより設定される。ここで、最近のカーナビ
ゲーションシステムでは、出発地ＳＰおよび目的地ＤＰ
は、一般的に、住所、電話番号、地名または施設名称等
を使って設定される。設定された出発地ＳＰおよび目的
地ＤＰを特定する情報は、入力装置１１からデータ処理
部１３に送信される。

【０１０５】ステップＳ１０２が終了すると、データ処
理部１３は、読み出し／書き込み制御部１８と協働し
て、経路探索処理に必要な地図ファイルＣＦを、第１の
記憶装置１９から主記憶（図示せず）に順次読み込む
（ステップＳ１０３）。前述したように、第１の記憶装
置１９に格納された各地図ファイルＣＦは、図２等に示
すように、地図を矩形領域に分割したユニットＵを単位
としてデジタルデータ化される。さらに、各地図ファイ
ルＣＦは、ファイルシステムにより管理される。ファイ
ルシステムは、第１の記憶装置１９の論理領域がツリー
構造をとるようにディレクトリを作成する。これによっ
て、各地図ファイルＣＦが格納される論理領域は、ルー
トおよびファイル名、ならびにそれらの間に介在するサ
ブディレクトリ名により表されるパスにより一意に特定
される。また、本実施形態のツリー構造およびファイル
名は、上述したように、ユニットＵ同士の親子関係およ
び隣接関係を特定する。ファイルシステムを構成するデ
ータ処理部１３および読み出し／書き込み制御部１８
は、最初のステップＳ１０３において、入力装置１１か
ら送信されてくる出発地ＳＰ周辺を表す地図ファイルＣ
Ｆを第１の記憶装置１９から読み出すためには、当該地
図ファイルＣＦのパス名を求めなければならない。

【０１０６】ここで、図３５は、図３４のステップＳ１
０３の詳細な処理手順を示すフローチャートである。図
３５の処理を簡単に説明すると、データ処理部１３が読
み込むべき地図ファイルＣＦのレベル（階層）および代
表点となる地点の座標情報から、当該地図ファイルＣＦ
のパス名を求める。そして、読み出し／書き込み制御部
１８は、データ処理部１３により求められたパス名を基
に、第１の記憶装置１９から地図ファイルＣＦを読み出
す。以下、図３５のフローチャートを参照して、図４お
よび図５に示すレベル「０」のユニットＵ₀ を表す地図
ファイルＣＦ（「￥Ｍ０２０１．ｍａｐ」）を読み出す
際の処理手順を説明する。

【０１０７】ここで、代表点とは、読み出すべき地図フ
ァイルＣＦがカバーする範囲に含まれる１つの地点を意
味する。以下の説明において、経度座標ＬＯＮ₀ および
緯度座標ＬＡＴ₀ は、ユニットＵ₀ の代表点の経度方向
の位置を示す座標および緯度方向の位置を示す座標とす
る。本実施形態では、経度座標ＬＯＮ₀ および緯度座標
ＬＡＴ₀ は、東経１３２度３９分２０秒および北緯３２
度５５分３７秒とする。

【０１０８】さらに、ステップＳ１０３の処理には、い
くつかのパラメータが必要となる。以下の説明におい
て、経度幅Ｗ３は、レベル「３」に属する各ユニットＵ
がカバーする矩形領域の経度方向に沿う辺の長さを意味
する。緯度幅Ｈ３は、レベル「３」に属する各ユニット
Ｕがカバーする矩形領域の緯度方向に沿う辺の長さを意
味する。本実施形態の場合、図２および図３で説明した
ように、レベル「３」の矩形領域が約６４０ｋｍ四方の
場合には、経度幅Ｗ３および緯度幅Ｈ３は２８８００秒
（８度）および１９２００秒（５度２０分）である。経
度幅Ｗ２は、レベル「２」に属する各ユニットＵがカバ
ーする矩形領域の経度方向に沿う辺の長さを意味する。
緯度幅Ｈ２は、レベル「２」に属する各ユニットＵがカ
バーする矩形領域の緯度方向に沿う辺の長さを意味す
る。レベル「２」の矩形領域が約８０ｋｍ四方の場合に
は、経度幅Ｗ２および緯度幅Ｈ２は３６００秒（１度）
および２４００秒（４０分）である。経度幅Ｗ１は、レ
ベル「１」に属する各ユニットＵがカバーする矩形領域
の経度方向に沿う辺の長さを意味する。緯度幅Ｈ１は、
レベル「１」に属する各ユニットＵがカバーする矩形領
域の緯度方向に沿う辺の長さを意味する。レベル「１」
の矩形領域が約１０ｋｍ毎の場合には、経度幅Ｗ１およ
び緯度幅Ｈ１は４５０秒（７分３０秒）および３００秒
（５分）である。経度幅Ｗ０は、レベル「０」に属する
各ユニットＵがカバーする矩形領域の経度方向に沿う辺
の長さを意味する。緯度幅Ｈ０は、レベル「０」に属す
る各ユニットＵがカバーする矩形領域の緯度方向に沿う
辺の長さを意味する。レベル「０」の矩形領域が約１．
２ｋｍ毎の場合には、経度幅Ｗ０および緯度幅Ｈ０は５
６．２５秒および３７．５秒である。

【０１０９】さて、データ処理部１３は、まず、代表点
の経度座標ＬＯＮ₀ および緯度ＬＡＴ₀ を特定し（ステ
ップＳ２０１）、読み込むべき地図ファイルＣＦのレベ
ルＬ（ユニットＵ₀ の地図ファイルＣＦを読み込む場
合、Ｌ＝０）を特定する（ステップＳ２０２）。ここ
で、ステップＳ２０１およびＳ２０２は、双方向階層別
探索において一般的に実行される処理であるため、ここ
では詳細に説明しない。

【０１１０】次に、データ処理部１３は、ステップＳ２
０３に進み、代表点の経度座標ＬＯＮ₀ をレベル「３」
の経度幅Ｗ３で除算した時の商ＤＬＯＮ３、および、当
該代表点の緯度ＬＡＴ₀ をレベル「３」の経度幅Ｗ３で
除算した時の商ＤＬＯＮ３を算出する。今、経度幅Ｗ３
＝２８８００秒（８度）、緯度幅Ｈ３＝１９２００秒
（５度２０分）、経度座標ＬＯＮ₀ ＝東経１３２度３９
分２０秒、緯度座標ＬＡＴ₀ ＝北緯３２度５５分３７秒
であるから、商ＤＬＯＮ３＝１６、商ＤＬＡＴ３＝６と
なる。データ処理部１３は、算出された商ＤＬＯＮ３お
よび商ＤＬＡＴ３を順番に並べて４桁の数字を作成す
る。今回作成される４桁の数字は、「１６０６」であ
る。ここで、商ＤＬＯＮ３および／または商ＤＬＡＴ３
が１桁となる場合は、下から２桁目に「０」を付ける。

【０１１１】データ処理部１３は、作成した４桁の数字
の先頭に、ディレクトリの識別子「￥」およびファイル
名の頭文字を定義する「Ｍ」を付加し、さらにその末尾
にファイル名の拡張子「．ｍａｐ」を付加する。これに
よって、データ処理部１３は、代表点の経度座標ＬＯＮ
₀ および緯度座標ＬＡＴ₀ から、読み込むべき地図ファ
イルＣＦ（ユニットＵ₀ のもの）のファイル名（今回の
場合、「￥Ｍ１６０６．ｍａｐ」）を導き出す。さら
に、データ処理部１３は、作成した４桁の数字の先頭
に、ディレクトリの識別子「￥」およびサブディレクト
リ名の頭文字を定義する「Ｄ」を付加する。これによっ
て、データ処理部１３は、代表点の経度座標ＬＯＮ₀ お
よび緯度座標ＬＡＴ₀ から、読み込むべき地図ファイル
ＣＦが格納されたサブディレクトリ名（今回の場合「￥
Ｄ１６０６」）を導出する（ステップＳ２０３）。

【０１１２】次に、データ処理部１３は、ステップＳ２
０２で指定されたレベルＬが「３」か否かを判断する
（ステップＳ２０４）。レベルＬが「３」の場合、デー
タ処理部１３は、ステップＳ２０５に進み、ルート
（「￥ＭＡＰ」）の後に、ステップＳ２０３で導出した
ファイル名（「￥Ｍ１６０６．ｍａｐ」）を付加して、
パス名を導出する。したがって、パス名は「￥ＭＡＰ￥
Ｍ１６０６．ｍａｐ」となる。データ処理部１３は、導
出したパス名を読み出し／書き込み制御部１８に出力す
る（ステップＳ２０５）。読み出し／書き込み制御部１
８は、入力されたパス名（「￥ＭＡＰ￥Ｍ１６０６．ｍ
ａｐ」）に従って、地図ファイルＣＦを第１の記憶装置
１９内の第１のデータベース１１１から読み出す。読み
出し／書き込み制御部１８は、読み出した地図ファイル
ＣＦをデータ処理部１３内の主記憶（図示せず）に転送
する。このようにして、データ処理部１３は、地図ファ
イルＣＦを第１の記憶装置１９から主記憶に読み込む
（ステップＳ２０６）。

【０１１３】ところで、上述したように、ステップＳ２
０２で指定されたレベルは「０」であるから、データ処
理部１３は、ステップＳ２０４においてレベルＬが
「３」でないと判断して、ステップＳ２０７に進む。デ
ータ処理部１３は、ステップＳ２０３で導出した商ＤＬ
ＯＮ３の余りＲＬＯＮ３を算出した後、当該余りＲＬＯ
Ｎ３をレベル「２」の経度幅Ｗ２で除算した時の商ＤＬ
ＯＮ２を算出する。さらに、データ処理部１３は、ステ
ップＳ２０３で導出した商ＤＬＡＴ３の余りＲＬＡＴ３
を算出した後、当該余りＲＬＡＴ３をレベル「２」の緯
度幅Ｈ２で除算した時の商ＤＬＡＴ２を算出する。今、
上述した数値を用いた場合、商ＤＬＯＮ２および商ＤＬ
ＡＴ２は、ＤＬＯＮ２＝４およびＤＬＡＴ２＝１とな
る。データ処理部１３は、算出された商ＤＬＯＮ２およ
び商ＤＬＡＴ２を順番に並べて４桁の数字を作成する。
今回作成される４桁の数字は、「０４０１」である。こ
こで、商ＤＬＯＮ２および／または商ＤＬＡＴ２が１桁
となる場合は、２桁目に「０」を付ける。

【０１１４】データ処理部１３は、作成した４桁の数字
の先頭に、ディレクトリの識別子「￥」およびファイル
名の頭文字を定義する「Ｍ」を付加し、さらにその末尾
にファイル名の拡張子「．ｍａｐ」を付加する。これに
よって、データ処理部１３は、代表点の経度座標ＬＯＮ
₀ および緯度座標ＬＡＴ₀ から、読み込むべき地図ファ
イルＣＦのファイル名（今回の場合、「￥Ｍ０４０１．
ｍａｐ」）を導き出す。さらに、データ処理部１３は、
作成した４桁の数字の先頭に、ディレクトリの識別子
「￥」およびサブディレクトリ名の頭文字を定義する
「Ｄ」を付加する。これによって、データ処理部１３
は、代表点の経度座標ＬＯＮ₀ および緯度座標ＬＡＴ₀
から、読み込むべき地図ファイルＣＦ（ユニットＵ₀ の
もの）が格納されたサブディレクトリ名（今回の場合
「￥Ｄ０４０１］）を導出する（ステップＳ２０７）。

【０１１５】次に、データ処理部１３は、ステップＳ２
０２で指定されたレベルＬが「２」か否かを判断する
（ステップＳ２０８）。レベルＬが「２」の場合、デー
タ処理部１３は、ステップＳ２０５に進み、ルート
（「￥ＭＡＰ」）の後に、ステップＳ２０３で導出した
サブディレクトリ名（「￥Ｄ１６０６」）およびステッ
プＳ２０７で導出したファイル名（「￥Ｍ０４０１．ｍ
ａｐ」）を付加して、パス名を導出する。したがって、
パス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａ
ｐ」となる。データ処理部１３は、導出したパス名を読
み出し／書き込み制御部１８に出力する（ステップＳ２
０９）。読み出し／書き込み制御部１８は、入力された
パス名（「￥ＭＡＰ￥Ｄ１６０６￥Ｍ０４０１．ｍａ
ｐ」）に従って、地図ファイルＣＦを第１の記憶装置１
９内の第１のデータベース１１１から読み出す。読み出
し／書き込み制御部１８は、読み出した地図ファイルＣ
Ｆをデータ処理部１３内の主記憶（図示せず）に転送す
る。このようにして、データ処理部１３は、地図ファイ
ルＣＦを第１の記憶装置１９から主記憶に読み込む（ス
テップＳ２０６）。

【０１１６】上述したように、ステップＳ２０２で指定
されたレベルは「０」であるから、データ処理部１３
は、ステップＳ２０８においてレベルＬが「２」でない
と判断して、ステップＳ２０１０に進む。データ処理部
１３は、ステップＳ２０７で導出した商ＤＬＯＮ２の余
りＲＬＯＮ２を算出した後、当該余りＲＬＯＮ２をレベ
ル「１」の経度幅Ｗ１で除算した時の商ＤＬＯＮ１を算
出する。さらに、データ処理部１３は、ステップＳ２０
７で導出した商ＤＬＡＴ２の余りＲＬＡＴ２を算出した
後、当該余りＲＬＡＴ２をレベル「１」の緯度幅Ｈ１で
除算した時の商ＤＬＡＴ１を算出する。今、上述した数
値を用いた場合、商ＤＬＯＮ１および商ＤＬＡＴ１は、
ＤＬＯＮ１＝５およびＤＬＡＴ１＝３となる。データ処
理部１３は、算出された商ＤＬＯＮ１および商ＤＬＡＴ
１を順番に並べて４桁の数字を作成する。今回作成され
る４桁の数字は、「０５０３」である。ここで、商ＤＬ
ＯＮ１および／または商ＤＬＡＴ１が１桁となる場合
は、２桁目に「０」を付ける。

【０１１７】データ処理部１３は、作成した４桁の数字
の先頭に、ディレクトリの識別子「￥」およびファイル
名の頭文字を定義する「Ｍ」を付加し、さらにその末尾
にファイル名の拡張子「．ｍａｐ」を付加する。これに
よって、データ処理部１３は、代表点の経度座標ＬＯＮ
₀ および緯度座標ＬＡＴ₀ から、読み込むべき地図ファ
イルＣＦのファイル名（「￥Ｍ０５０３．ｍａｐ」）を
導き出す。さらに、データ処理部１３は、作成した４桁
の数字の先頭に、ディレクトリの識別子「￥」およびサ
ブディレクトリ名の頭文字を定義する「Ｄ」を付加す
る。これによって、データ処理部１３は、代表点の経度
座標ＬＯＮ₀ および緯度座標ＬＡＴ₀ から、読み込むべ
き地図ファイルＣＦ（ユニットＵ₀ のもの）が格納され
たサブディレクトリ名（今回の場合「￥Ｄ０５０３］）
を導出する（ステップＳ２０１０）。

【０１１８】次に、データ処理部１３は、ステップＳ２
０２で指定されたレベルＬが「１」か否かを判断する
（ステップＳ２０１１）。レベルＬが「１」の場合、デ
ータ処理部１３は、ステップＳ２０１２に進み、ルート
（「￥ＭＡＰ」）の後に、ステップＳ２０３で導出した
サブディレクトリ名（「￥Ｄ１６０６」）、ステップＳ
２０７で導出したサブディレクトリ名（「￥Ｄ４０
１」）およびステップＳ２０１０で導出したファイル名
（￥Ｍ０５０３．ｍａｐ）を付加して、パス名を導出す
る。したがって、パス名は「￥ＭＡＰ￥Ｄ１６０６￥Ｄ
０４０１￥Ｍ０５０３．ｍａｐ」となる。データ処理部
１３は、導出したパス名を読み出し／書き込み制御部１
８に出力する（ステップＳ２０１２）。読み出し／書き
込み制御部１８は、入力されたパス名（「￥ＭＡＰ￥Ｄ
１６０６￥Ｄ０４０１￥Ｍ０５０３．ｍａｐ」）に従っ
て、地図ファイルＣＦを第１の記憶装置１９内の第１の
データベース１１１から読み出す。読み出し／書き込み
制御部１８は、読み出した地図ファイルＣＦをデータ処
理部１３内の主記憶（図示せず）に転送する。このよう
にして、データ処理部１３は、地図ファイルＣＦを第１
の記憶装置１９から主記憶に読み込む（ステップＳ２０
６）。

【０１１９】上述したように、ステップＳ２０２で指定
されたレベルＬは「０」であるから、データ処理部１３
は、ステップＳ２０１１においてレベルＬが「１」でな
いと判断して、ステップＳ２０１０に進む。データ処理
部１３は、ステップＳ２０１０で導出した商ＤＬＯＮ１
の余りＲＬＯＮ１を算出した後、当該余りＲＬＯＮ１を
レベル「０」の経度幅Ｗ０で除算した時の商ＤＬＯＮ０
を算出する。さらに、データ処理部１３は、ステップＳ
２０１０で導出した商ＤＬＡＴ１の余りＲＬＡＴ１を算
出した後、当該余りＲＬＡＴ１をレベル「０」の緯度幅
Ｈ０で除算した時の商ＤＬＡＴ０を算出する。今、上述
した数値を用いた場合、商ＤＬＯＮ０および商ＤＬＡＴ
０は、ＤＬＯＮ０＝２およびＤＬＡＴ０＝１となる。デ
ータ処理部１３は、算出された商ＤＬＯＮ０および商Ｄ
ＬＡＴ０を順番に並べて４桁の数字を作成する。今回作
成される４桁の数字は、「０２０１」である。ここで、
商ＤＬＯＮ０および／または商ＤＬＡＴ０が１桁となる
場合は、２桁目に「０」を付ける。データ処理部１３
は、作成した４桁の数字の先頭に、ディレクトリの識別
子「￥」およびファイル名の頭文字を定義する「Ｍ」を
付加し、さらにその末尾にファイル名の拡張子「．ｍａ
ｐ」を付加する。これによって、データ処理部１３は、
代表点の経度座標ＬＯＮ₀ および緯度座標ＬＡＴ₀ か
ら、読み込むべき地図ファイルＣＦのファイル名（今回
の場合、「￥Ｍ０２０１．ｍａｐ」）を導き出す（ステ
ップＳ２０１３）。ここで、ステップＳ２０１３では、
レベルＬが最下位層の「０」と自動的に判断できるの
で、データ処理部１３は、サブディレクトリ名を導出し
ない。

【０１２０】次に、データ処理部１３は、ステップＳ２
０１４に進み、ルート（「￥ＭＡＰ」）の後に、ステッ
プＳ２０３、Ｓ２０７およびＳ２０１０で導出したサブ
ディレクトリ名の配列（「￥Ｄ１６０６￥Ｄ４０１￥Ｄ
０５０３）ならびにステップＳ２０１３で導出したファ
イル名（今回の場合、「￥Ｍ０２０１．ｍａｐ」）を付
加して、パス名を導出する。したがって、パス名は「￥
ＭＡＰ￥Ｄ１６０６￥Ｄ０４０１￥Ｄ０５０３￥Ｍ０２
０１．ｍａｐ」となる。データ処理部１３は、導出した
パス名を読み出し／書き込み制御部１８に出力する（ス
テップＳ２０１４）。読み出し／書き込み制御部１８
は、入力されたパス名（「￥ＭＡＰ￥Ｄ１６０６￥Ｄ０
４０１￥Ｍ０５０３．ｍａｐ」）に従って、地図ファイ
ルＣＦを第１の記憶装置１９内の第１のデータベース１
１１から読み出す。読み出し／書き込み制御部１８は、
読み出した地図ファイルＣＦをデータ処理部１３内の主
記憶（図示せず）に転送する。このようにして、データ
処理部１３は、所望の地図ファイルＣＦ（ユニットＵ₀
を表す地図を表示可能なデータ）を第１の記憶装置１９
から主記憶に読み込む（ステップＳ２０６）。

【０１２１】データ処理部１３は、以上のステップＳ２
０６の後、図３５のフローチャートから抜けて、図３４
のステップＳ１０４に進む。データ処理部１３は、主記
憶上に読み込まれた地図ファイルＣＦを用いて、出発地
ＳＰ側からの経路探索処理を行う（ステップＳ１０
４）。ここで注意を要するのは、ダイクストラ法等の手
法は周知であるため、その詳細な説明を省略する。ダイ
クストラ法等を簡単に説明すると、地図ファイルＣＦ内
の道路ネットワークの接続をたどりながら最短ルートを
求める処理が行われる。かかる地図ファイルＣＦ内での
ノードＮとリンクＬの接続関係をたどる手順について
は、図３２を参照して前述の通りである。

【０１２２】また、データ処理部１３は、ステップＳ１
０２の後、ステップＳ１０３と並行して、ステップＳ１
０５を実行する。データ処理部１３は、ステップＳ１０
２で設定された目的地ＤＰ周辺の地図ファイルＣＦを第
１の記憶装置１９から、自身の内部に有する主記憶（図
示せず）に読み込む（ステップＳ１０５）。さらに、デ
ータ処理部１３は、ステップＳ１０５で読み込んだ地図
ファイルＣＦを用いて、目的地ＤＰ側の経路探索処理を
行う（ステップＳ１０６）。ここで、ステップＳ１０５
およびＳ１０６の処理については、ステップＳ１０３お
よびステップＳ１０４と同様であるため詳細な説明は省
略する。

【０１２３】データ処理部１３は、ステップＳ１０４お
よびＳ１０６の処理が終了すると、当該ステップＳ１０
４およびＳ１０６で使用された地図ファイルＣＦの階層
での探索終了条件を満たしたか否かの判断を行う（ステ
ップＳ１０７）。ステップＳ１０７では、一般的に、読
み込んだ地図ファイルＣＦの数、または探索したノード
Ｎの数等が所定の値に達しているか否かに基づいて、探
索条件が終了したか否かが判断される。ステップＳ１０
７において探索終了条件を満たしていないと判断された
場合には、データ処理部１３は、ステップＳ１０３およ
びＳ１０５に戻って、出発地ＳＰ側および目的地ＤＰ側
の双方からの探索処理で既に読み込まれている地図ファ
イルＣＦに隣接する地図ファイルＣＦを読み込む。ここ
で、既に読み込まれている地図ファイルＣＦがユニット
Ｕの地図を表すとすると、隣接する地図ファイルＣＦ
は、隣接ユニットＮＵ（図２６参照）の地図を表すこと
となる。データ処理部１３は、新たな代表点の経度座標
ＬＯＮおよび緯度座標ＬＡＴを求めて、隣接する地図フ
ァイルＣＦのパス名を導出し、当該パス名により特定さ
れる地図ファイルＣＦを第１の記憶装置１９から主記憶
に読み込む。

【０１２４】ここで、図３６に示すように、隣接ユニッ
トＮＵを決定するための新しい代表点の位置は、道路網
の接続をたどるリンクＬが、どのユニット境界上の隣接
ノード（詳しくは図２６を参照）を経由して当該隣接ユ
ニットＮＵ内のリンクＬと接続するかによって異なる。
より具体的に説明すると、図３６のリンクＬ１１は、ユ
ニットＵの境界（矩形）の上辺上に位置する隣接ノード
Ｎ１２を経由して隣接ユニットＮＵ１のあるリンクＬと
接続する。このため、ユニットＵの代表点Ｐの緯度座標
ＬＡＴに対して、当該ユニットＵが属するレベルＬの緯
度幅Ｈを加算した緯度座標ＬＡＴ１をもつ地点が新しい
代表点Ｐ１と定められる。

【０１２５】一方、図３６のリンクＬ１２は、ユニット
Ｕの境界（矩形）の右辺上に位置する隣接ノードＮ１３
を経由して隣接ユニットＮＵ２内のあるリンクＬと接続
する。このため、ユニットＵの代表点Ｐの経度座標ＬＯ
Ｎに対して、当該ユニットＵが属するレベルＬの経度幅
Ｗを加算した経度座標ＬＯＮ２をもつ地点が新しい代表
点Ｐ２と定められる。

【０１２６】２回目以降のステップＳ１０３およびＳ１
０５では、データ処理部１３は、図３６を参照して説明
したようにして求められた新しい代表点に基づいて、当
該代表点を含む範囲を表す地図の地図ファイルＣＦを読
み込む。なお、この際の処理手順は前述の通りである。
次のステップＳ１０４およびＳ１０６では、データ処理
部１３は、ステップＳ１０３およびＳ１０５で読み込ん
だ地図ファイルＣＦを使って探索処理を行う。かかる探
索処理は、前回読み込んだ地図ファイルＣＦから今回読
み込んだものへと、つまりユニットＵと隣接ユニットＮ
Ｕとの境界をまたいで道路網の接続をたどることを意味
している。

【０１２７】ところで、従来の技術では、ユニットＵお
よび隣接ユニットＮＵの境界をまたいだ場合であって
も、道路網の接続をたどることができるように、各地図
ファイルの隣接ノードのレコードに、隣接ユニットＮＵ
の隣接ノードを特定する番号またはオフセットアドレス
等が記録されていた。しかし、このような地図ファイル
の内部データ構造に関わる情報を当該ユニットに記録し
てしまうと、隣接ユニットＮＵを表す地図ファイルが更
新された場合、上記番号またはオフセットアドレスが変
わってしまう場合がある。したがって、１つの地図ファ
イルが更新されることにより、その周囲のすべての隣接
ユニットＮＵを表す地図ファイルが更新される必要が生
じるおそれがあるという問題点があった。かかる問題点
を解消すべく、本実施形態の各地図ファイルＣＦには、
隣接ユニットＮＵの内部データ構造に直接関わる情報は
記録されておらず、データ処理部１３は、ノードＮの座
標情報および／またはリンクＬの属性情報を用いて、隣
接ユニットＮＵの隣接ノードＮをたどる処理を実行す
る。

【０１２８】以下、図３７および図３８の２つの図面を
参照して、図３４のステップＳ１０４またはＳ１０６に
おける、データ処理部１３がユニットＵと隣接ユニット
ＮＵの境界をまたいで道路網の接続をたどる処理につい
て詳細に説明する。図３７は、互いに隣接し合う４個の
ユニットＵ１〜Ｕ４を並べた際に構成される道路網を示
している。ユニットＵ１に含まれる道路網は、４個のノ
ードＮ１０〜Ｎ１３と、３個のリンクＬ１０〜Ｌ１２と
から構成される。ユニットＵ１では、３個のノードＮ１
０、Ｎ１２およびＮ１３（●印参照）は隣接ノードであ
って、ユニットＵ１の境界上に位置する。また、ユニッ
トＵ２に含まれる道路網は、５個のノードＮ２０〜Ｎ２
４と、４個のリンクＬ２０〜Ｌ２３とから構成される。
ユニットＵ２では、４個のノードＮ２０およびＮ２２〜
２４（●印参照）は、隣接ノードであって、ユニットＵ
２の境界上に位置する。また、ユニットＵ３に含まれる
道路網は、４個のノードＮ３０〜Ｎ３３と、３個のリン
クＬ３０〜Ｌ３２とから構成される。ユニットＵ３で
は、ノードＮ３０、Ｎ３２およびＮ３３（●印参照）が
隣接ノードであり、ユニットＵ３の境界上に位置する。
さらに、ユニットＵ４に含まれる道路網は、４個のノー
ドＮ４０〜Ｎ４３と、３個のリンクＬ４０〜Ｌ４２とか
ら構成される。３個のノードＮ４０〜Ｎ４３（●印参
照）は、隣接ノードであって、ユニットＵ４の境界上に
位置する。さらに、図３７において、ノードＮ１３およ
びＮ２０が接続され、ノードＮ１２およびＮ３０が接続
され、ノードＮ２４およびＮ４３が接続され、さらにノ
ードＮ３３およびＮ４０が接続され、これによって、１
つの道路網が構成される。

【０１２９】以上の図３７の道路網において、リンクＬ
１２は、隣接ノードＮ１３およびＮ２０を経由して、リ
ンクＬ２０とつながっている。上述したように、経路探
索処理において、データ処理部１３は、隣接ユニットＮ
Ｕを表す地図ファイルＣＦを順次読み込んで、目的地Ｄ
Ｐまたは出発地ＳＰの方向へと探索を広げていく。その
ためには、データ処理部１３は、あるユニットＵおよび
隣接ユニットＮＵの境界をまたぐような２個のリンクＬ
の接続関係をたどる必要がある。そこで、まず、データ
処理部１３は、主記憶上に読み込まれたユニットＵ（つ
まり、ユニットＵ１）の地図ファイルＣＦ（より具体的
には、リンクレコードＲＲ（図３０および図３１参
照））から、ユニットＵ１からユニットＵ２へと向かう
リンクＬ１２のリンク属性を取り出す（図３８；ステッ
プＳ３０１）。以下では、ユニットＵ１の境界へと向か
うリンクＬ１２を脱出リンクＬ１２と呼ぶこととする。

【０１３０】次に、データ処理部１３は、脱出リンクＬ
１２の接続先情報（ノードレコード番号またはオフセッ
トアドレス）を参照して、地図ファイルＣＦ（より具体
的には、第１または第２のノードテーブル）から、当該
脱出リンクＬ１２に接続された隣接ノードＮ１３のノー
ドレコードＮＲ（図２７参照）を探し出す。その後、デ
ータ処理部１３は、探し出したノードレコードＮＲか
ら、隣接ノードＮ１３のノード座標を取り出す（ステッ
プＳ３０２）。以下では、脱出リンクＬ１２に接続され
た隣接ノードＮ１３を脱出ノードＮ１３と呼ぶこととす
る。

【０１３１】次に、データ処理部１３は、主記憶上に読
み込まれている隣接ユニットＮＵ（つまり、ユニットＮ
２）の地図ファイルＣＦ（より具体的には、第１または
第２のノードテーブル）から、ノード座標を１つずつ取
り出す（ステップＳ３０３）。データ処理部１３は、ス
テップＳ３０２で取り出した脱出ノードＮ１３のノード
座標と、ステップＳ３０３で取り出したノード座標との
差分値を算出して、当該差分値が所定の閾値以下である
か否かを判断する（ステップＳ３０４）。ここで、図２
９を参照して説明したように、本実施形態では、ノード
座標は正規化された値で記録されている。上記所定の閾
値としては、正規化された座標値の幅により異なるが、
「１」〜「２」程度の値が好ましい。データ処理部１３
は、ステップＳ３０４の条件を満たすまで、ステップＳ
３０３およびＳ３０４を繰り返し実行する。ただし、デ
ータ処理部１３は、ステップＳ３０３を実行するたび
に、過去に取り出したものとは異なるノード座標を取り
出す。ここで、ステップＳ３０４の条件を満たすという
ことは、ステップＳ３０３で取り出したノード座標を有
するノードＮが脱出ノードＮ１３と同じ位置を示してい
ることとなる。つまり、制御部１３は、ステップＳ３０
３およびＳ３０４を繰り返し実行することにより、脱出
ノードＮ１３とほぼ同じ位置を有する隣接ノードＮ２０
を探し出すことができる。以下では、探し出された隣接
ノードＮ２０を進入ノードと呼ぶこととする。

【０１３２】ここで、一般的に、ステップＳ３０３にお
いては、ノードレコード番号（図２８参照）の順番に従
って、ノード座標が１つずつ順番に取り出される。本実
施形態では、図２６および図２８を参照して説明したよ
うに、第１または第２のノードレコードにおいて、隣接
ノードＮのノードレコードＮＲは、非隣接レコードＮの
ノードレコードＮＲの前に記録されている。これによっ
て、データ処理部１３は、非隣接ノードＮのノードレコ
ードＮＲからノード座標を取り出すことなく、進入ノー
ドを見つけ出すことができる。これによって、データ処
理部１３が進入ノードを検索する処理の負荷を最小限に
抑えることができる。すわなち、データ処理部１３は、
隣接ユニットＮＵの地図ファイルＣＦに記録された第１
および第２のノードテーブル内に並ぶ全てのノードレコ
ードＮＲを検索しなくても、当該第１または第２のノー
ドテーブルの先頭から隣接ノードの数だけノードレコー
ドＮＲを検索すれば、必ず進入ノードを見つけ出すこと
ができる。このように、本実施形態におけるノードレコ
ードＮＲの並べ方は、進入ノードを検索する処理の高速
化にも寄与する。

【０１３３】また、隣接ノードのノードレコードＮＲ
は、図２６を参照して説明したように、ユニットＵ（矩
形）の左辺→上辺→右辺→下辺という優先順位に従って
並べられる。さらに、左辺および右辺上に位置する隣接
ノードのノードレコードＮＲは緯度の昇順に並べられ、
上辺および下辺上に位置する隣接ノードのノードレコー
ドＮＲは経度の昇順に並べられる。また、非隣接ノード
のレコードＮＲについては、まず緯度の昇順に並べら
れ、緯度が同一座標の複数の非隣接ノードのレコードＮ
Ｒについては経度の昇順に並べられる。かかる並べ方に
よって、進入ノードの検索処理をさらに高速化すること
ができる。例えば、上記の並べ方の規則に従えば、図３
９の隣接ノードＮ１０〜Ｎ２０のノードレコードＮＲ
は、Ｎ１０→Ｎ１１→Ｎ１２→Ｎ１３→Ｎ１４→Ｎ１５
→Ｎ１６→Ｎ１７→Ｎ１８→Ｎ１９→Ｎ２０の順で、ユ
ニットＵ１の地図ファイルＣＦ内に記録される。同様
に、隣接ノードＮ２０〜Ｎ２７のノードテーブルＵ２の
ノードレコードＮＲは、Ｎ２０→Ｎ２１→Ｎ２２→Ｎ２
３→Ｎ２４→Ｎ２５→Ｎ２６→Ｎ２７の順で、ユニット
Ｕ２の地図ファイルＣＦ内に記録される。さらに、ユニ
ットＵ３の地図ファイルＣＦ内には、ノードＮ３０→Ｎ
３１→Ｎ３２→Ｎ３３→Ｎ３４→Ｎ３５→Ｎ３６→Ｎ３
７→Ｎ３８の順にノードレコードＮＲが記録される。

【０１３４】通常、経路探索処理では、読み込んだ地図
ファイルＣＦ内で探索が広げられ、探索中のルートが隣
接ノードに到達した際には、その対応する隣接ユニット
ＮＵが新たに読み込まれる。本実施形態では、隣接ユニ
ットＮＵの地図ファイルＣＦが読み込まれた際に、まず
前回読み込まれた地図ファイルＣＦと今回読み込まれた
地図ファイルＣＦとの、ユニットの間の境界上に存在す
る全隣接ノードの対応付けが行われる。この際に、前述
のようにノードテーブルにおいて、隣接ノードのノード
レコードＮＲが、上述した順位で記録されることによ
り、隣接ノードの対応付けを高速化することができる。
このため、例えば、ユニットＵ１の隣接ノードＮ１２と
同じ位置を示すユニットＵ３の隣接ノードＮ３５が見つ
かれば、ユニット１の次の隣接ノードＮ１３に対応する
ユニット３の隣接ノードＮ３６は必ずＮ３５の次のレコ
ードに並んでいる。また同様に、ユニット２の隣接ノー
ドＮ２０に対応するユニット１の隣接ノードＮ１６が見
つかれば、ユニット２の次の隣接ノードＮ２１に対応す
るユニット１の隣接ノードＮ１７は必ずＮ１６の次のレ
コードに並んでいる。このように、前述のような規則性
に従って隣接ノードを並べることにより、隣接ユニット
間における隣接ノードの検索処理を高速化することがで
きる。

【０１３５】さて、ステップＳ３０４で進入ノードが見
つかると、データ処理部１３は、進入ノードＮ２０の接
続先情報（ノードレコード番号またはオフセットアドレ
ス）を参照して、ユニットＵ２の地図ファイルＣＦ（よ
り具体的には、第１または第２のリンクテーブル）か
ら、当該進入ノードＮ２０に接続されたリンクＬ２０の
リンクレコードＬＲ（図３０および図３１参照）を探し
出す。以下では、進入ノードＮ２０に接続されたリンク
Ｌ２０を進入リンクＬ２０と呼ぶこととする。その後、
データ処理部１３は、探し出したリンクレコードＬＲか
ら、進入リンクＬ２０の属性情報を取り出す（ステップ
Ｓ３０５）。

【０１３６】次に、データ処理部１３は、ステップＳ３
０１で取り出した脱出リンクＬ１２の属性情報と、ステ
ップＳ３０５から取り出した進入リンクＬ２０の属性情
報が同じか否かを判断する（ステップＳ３０６）。デー
タ処理部１３は、２つの属性情報が互いに異なると判断
した場合、ステップＳ３０３に戻って、新しい進入ノー
ドＮを探す。ここで、本実施形態では、図２を参照して
説明したように、互いに異なる縮尺の地図を表すいくつ
かの地図ファイルＣＦが第１の記憶装置１９には格納さ
れている。下位階層の地図ファイルＣＦは、詳細な道路
網を表すことができるので、２つのノード座標の差分値
が所定の閾値以下であれば、両ノードＮが同じ位置を示
す確率が相対的に高くなる。しかしながら、上位階層の
地図ファイルＣＦは粗い道路網しか表すことができない
ので、２つのノード座標の差分値が所定の閾値以下であ
っても、両ノードＮが同じ位置を示す確率は相対的に低
くなる。本実施形態では、ステップＳ３０６において脱
出リンクおよび進入リンクの属性を一致／不一致を判断
することにより、データ処理部１３が、ある道路から別
の道路をたどることなく、同じ１本の道路を正確にたど
るようにしている。つまり、ステップＳ３０６の処理
は、下位階層の地図ファイルＣＦに対して実行されなく
ともよい。

【０１３７】データ処理部１３は、ステップＳ３０６で
脱出リンクＬ１２および進入リンクＬ２０の属性情報が
一致していると判断すると、１本の道路を正確にたどっ
ているとみなして、図３８のフローチャートから抜け
て、図３４のステップＳ１０７に進む。データ処理部１
３は、今回の読み込み続けた地図ファイルＣＦの階層で
の探索終了条件を満たしたと判断した場合、出発地ＳＰ
側の経路と目的地ＤＰ側の経路がつながったかどうかを
判断する（ステップＳ１０８）。データ処理部１３は、
出発地ＳＰ側と目的地ＤＰ側の経路とがつながっている
場合には、両地点間の最短ルートが求まったと判断し、
経路探索処理を終了する。一方、出発地ＳＰ側と目的地
ＤＰ側との経路がまだつながっていない場合には、デー
タ処理部１３は、ステップＳ１０９に進み、１つ上位の
階層に移行して、広域かつ粗い道路網を表す地図ファイ
ルＣＦを使って経路探索処理を続行する。

【０１３８】次に、ある下位階層から上位階層への以降
処理について詳細に説明する。この時、データ処理部１
３は、下位階層における探索処理の終点となるノードＮ
（探索中のルートの終点）から、上位階層の地図ファイ
ルＣＦ内に存在しかつ同じ位置を示すノードＮへと移行
する。したがって、データ処理部１３が上位階層への移
行処理を確実に行うためには、上位階層の地図ファイル
ＣＦに含まれるすべてのノードＮが、その子ユニットＣ
Ｕの各ノードＮから必ず検索できる必要がある。

【０１３９】従来では、かかる検索を実現するために、
下位階層のノードＮと同じ位置を示すに上位階層のノー
ドＮのノード番号やオフセットアドレス等がノードレコ
ード内に記録されるという方法が採用されていた。しか
し、このような上位階層の地図ファイルの内部データ構
造に関わる情報が下位階層の地図ファイルに記録される
と、上位階層の地図ファイルが更新された場合、下位階
層の地図ファイルも更新されなければ、下位階層から上
位階層への移行処理をスムーズに行えなくなるという問
題点があった。そこで、本実施形態では、各地図ファイ
ルＣＦには、上位階層の地図ファイルＣＦの内部データ
構造に直接関わるような情報は記録されず、階層移行を
行う際にノードの座標情報やリンクの属性情報が参照さ
れる。しかし、この場合、一般的に上位階層の地図ファ
イルＣＦが表す地図は、下位階層の地図ファイルＣＦが
表す地図に比べて座標の分解能が低い。そのため、図４
０に示すように、下位階層および上位階層の地図ファイ
ルＣＦでは互いに異なる座標をもっていた２つのノード
Ｎが、上位階層の地図ファイルＣＦにおける座標の丸め
誤差のために、同一の座標をもってしまう可能性があ
る。したがって、ノード座標だけでは、下位階層のノー
ドＮと一致する上位階層のノードＮを一意に特定するこ
とはできない。

【０１４０】そこで、本実施形態では、ノード座標だけ
でなく、ノードレコードＮＲの記録順序（並び方）が利
用される。すなわち、前述のように第１または第２のノ
ードテーブルにおけるノードレコードＮＲの並びの順
は、隣接ノード、非隣接ノード共に明確に規定されてい
る。このため、座標の丸め誤差が生じるような上位階層
のユニットＵにおいても、丸め誤差が生じる前の正規化
経度緯度座標を利用して、座標の昇順でノードレコード
ＮＲが記録される。これによって、データ処理部１３
は、下位階層のノードＮから、同じ位置を示しかつ上位
階層の親ユニットＰＵに含まれるノードＮを検索する場
合にも、下位階層ユニットＵ内に記録されているノード
Ｎの内で、親ユニットＵにも記録されており、かつ上位
階層で丸め誤差が生じた場合に同一座標になると考えら
れるノードＮの中から、ノードレコードＮＲの記録順序
に基づいて、親ユニットＰＵ内で対応するノードＮを一
意に特定することができる。

【０１４１】より具体的には、前述のように地図ファイ
ルＣＦでは、相対的に１階層上の親ユニットＰＵは、そ
の子ユニットＣＵに対して、経度方向および緯度方向共
に８倍のユニット幅を有する。その一方で、階層には関
係なく、各ノードは、ユニットＵの経度方向および緯度
方向共に８０００ｈ（１６ビット）で正規化した正規化
座標をもつ。すなわち、親ユニットＰＵは子ユニットＣ
Ｕに対して、その座標分解能が、経度方向および緯度方
向共に１／８であるということができる。このため、子
ユニットＣＵの正規化経度および正規化緯度座標１６ビ
ットの内、上位１３ビットが同じ値をもつノードＮは、
その親ユニットＰＵにおいて同一の正規化座標をもつこ
とになる。

【０１４２】例えば、図４１に示すように、子ユニット
ＣＵに記録されている５つのノードＮａ、Ｎｂ、Ｎｃ、
Ｎｄ、Ｎｅの正規化経度および正規化緯度座標１６ビッ
トの内、その上位１３ビットが同じ値をもち、かつこの
内の４つのノードＮａ、Ｎｃ、Ｎｄ、Ｎｅの親となるノ
ードＮａ２、Ｎｃ２、Ｎｄ２およびＮｅ２が親ユニット
ＰＵに記録されている（各ノードレコードＮＲに、親ノ
ードＰＵが存在することを示すフラグあるいはコードを
記録している）とする。この場合、図４２に示すよう
に、子ユニットＣＵのノードテーブルには、ノードＮ
ａ、Ｎｂ、Ｎｃ、ＮｄおよびＮｅの５個のノードレコー
ドＮＲは、緯度および経度の昇順に従って（前述）、Ｎ
ａ→Ｎｂ→Ｎｃ→Ｎｄ→Ｎｅの順に記録されている。な
お、この際、ノードＮａ、Ｎｂ、Ｎｃ、ＮｄおよびＮｅ
の５個のノードレコードＮＲは、ノードテーブル内で必
ずしも連続しているわけではない。

【０１４３】親ユニットＰＵのノードテーブルを作成す
る際には、上記５個のノードレコードＮＲの並びの順に
基づいて、ノードＮａ、Ｎｃ、ＮｄおよびＮｅそれぞれ
に対応する親ノードＮａ２、Ｎｃ２、Ｎｄ２およびＮｅ
２のノードレコードＮＲが、この順に記録（必ずしも連
続して記録する訳ではない）される。この結果、下記の
ようにして、子ユニットＣＵに記録されているノードＮ
ｄに対する、親ユニットＰＵにおける親ノードＮｄ２を
特定することができる。最初に、子ユニットＣＵのノー
ドＮｄは、ノードテーブルにおいて、その正規化座標１
６ビットの内の上位１３ビットが同じノードＮで、かつ
親ノードＮが存在するものの内の３番目のノードレコー
ドＮＲに記録されている。次に、子ユニットＣＵにおけ
るノードＮｄの正規化座標から、親ユニットＰＵにおけ
る正規化座標が算出される。次に、算出した正規化座標
をもつノードＮが、親ユニットＰＵのノードテーブルか
ら探し出される。その結果、図４１および図４２の例で
は、４つのノードＮａ２、Ｎｃ２、Ｎｄ２およびＮｅ２
が検出される。次に、子ユニットＣＵのノードＮｄに対
応する親ノードＮｄは、上述したように、これらノード
Ｎａ２、Ｎｃ２、Ｎｄ２、Ｎｅ２の４つのノードの内の
３番目に記録されているはずなので、ノードＮｄの親ノ
ードはＮｄ２であることが分かる。

【０１４４】以上のように、データ処理部１３は、上位
階層に移行した後、その上位階層でステップＳ１０３か
らステップＳ１０８までの処理を繰り返し、出発地ＳＰ
側と目的地ＤＰ側の探索がつながった時点で経路探索処
理を終了する。

【０１４５】以上のように、本願発明で用いる地図デー
タは矩形領域で区切られたユニット単位でファイル化さ
れ、かつこれらの各ユニットには、同一階層内の隣接ユ
ニット間においても、上下階層に存在する親子ユニット
間においても、他ユニット内の内部データ構造に関係す
るようなレコード番号や記録アドレス等を一切記録して
いないため、任意の範囲、任意の階層のユニットファイ
ルを置き換えることにより、地図データの更新を柔軟に
行うことができる。

【０１４６】「地図ファイルＣＦの送受信処理」近年、
センタ局２から端末装置１へと地図を提供するようなシ
ステムが研究・開発がされている。かかるシステムによ
り、端末装置１は、必要な時に必要な地図を得ることが
できる。そのため、センタ局２の第２の記憶装置２４に
は、一般的に、端末装置１側の第１のデータベース１１
１よりも大規模な第２のデータベース２５が準備されて
いる。本実施形態では、第１のデータベース１１１およ
び第２のデータベース２５には、上述したファイルシス
テムによりいくつかの地図ファイルＣＦが管理されてい
る。そして、以下に説明するようにして、センタ局２お
よび端末装置１とは地図ファイルＣＦの送信および受信
を行う。

【０１４７】まず、端末装置１はセンタ局２に地図ファ
イルＣＦの送信を要求する。図４３（ａ）は、端末装置
１がある地図ファイルＣＦの送信をセンタ局２に要求す
る際の処理手順を示すフローチャートである。また、図
４３（ｂ）は、図４３（ａ）の処理手順により送信され
る制御データとしての要求ＲＥＱのフォーマットを示す
図である。端末装置１のユーザは、第１の記憶装置１９
に、新しい地図ファイルＣＦを追加したい場合、また
は、古い地図ファイルＣＦを新しいものに更新したい場
合、入力装置１１を操作して、地図の要求・受信機能を
起動する。次に、ユーザは、出力装置１１０のディスプ
レイに表示されるメニュー画面に従いつつ、入力装置１
１を操作して、必要な地図の範囲および階層（レベル）
を入力する。入力装置１１は、ユーザの入力に応答し
て、地図の範囲および階層を示す情報をデータ処理部１
３に出力し指定する（ステップＳ４０１）。ここで、地
図の範囲の入力には、ディスプレイに表示される広域地
図に対して所望の範囲をユーザが入力装置１１を用いて
矩形領域で囲って指定したり、住所索引を使って地域を
ユーザが入力装置１１で指定したりする方法がある。

【０１４８】データ処理部１３は、入力装置１１から出
力された範囲および階層の情報が入力されると、当該範
囲情報を経度・緯度座標に変換する。データ処理部１３
は、経度・緯度座標および階層の情報を要求生成部１４
に出力する。要求生成部１４は、入力された経度・緯度
座標および階層の情報を用いて、図４３（ｂ）に示すフ
ォーマットの要求ＲＥＱを生成する（ステップＳ４０
２）。図４３（ｂ）において、要求ＲＥＱは、ユーザが
必要とする地図ファイルＣＦの階層を示す情報と、当該
地図ファイルＣＦが表す地図の範囲を特定する経度・緯
度座標とから構成される。ここで、経度・緯度座標は、
より具体的には、ユーザが広域地図を矩形領域で囲って
指定する場合に、その左下経度座標、左下緯度座標、右
上経度座標および右上緯度座標からなる。要求生成部１
４は、生成した要求ＲＥＱを第１の送受信部１５に出力
し、当該第１の送受信部１５は、アンテナ１６を通じ
て、入力された要求ＲＥＱをアップリンクＵＬに送出す
る（ステップＳ４０３）。

【０１４９】次にセンタ局２における地図ファイルＣＦ
の送信処理について説明する。端末装置１から送出され
た要求ＲＥＱは、通信網３のアップリンクＵＬを通じ
て、センタ局２の第２の送受信部２１により受信され
る。第２の送受信部２１は、受信した要求ＲＥＱを受信
要求解析部２２に出力する。ここで、図４４は、センタ
局２が要求ＲＥＱの受信後に実行する処理手順を示すフ
ローチャートである。受信要求解析部２２は、入力され
た要求ＲＥＱを解析して、解析結果を読み出し制御部２
３に出力する。読み出し制御部２３は、解析結果により
特定される地図ファイルＣＦを第２のデータベース２５
から検索する（ステップＳ５０１）。ここで、要求ＲＥ
Ｑには、端末装置１が要求した地図ファイルＣＦの階層
（レベル）、および当該地図ファイルＣＦが表す地図の
左下経度座標、左下緯度座標、右上経度座標、および右
上緯度座標が記述されている。そこで、受信要求解析部
２２は、まず、要求ＲＥＱから左下経度座標および左下
緯度座標を取り出し、当該左下経度座標および左下緯度
座標を代表点として、図３５のフローチャートで示した
処理手順に従って、要求された地図ファイルＣＦのパス
名を導出する。

【０１５０】次に、受信要求解析部２２は、導出したパ
ス名を有する地図ファイルＣＦが第２の記憶装置２４に
格納されているか否かを調べる（ステップＳ５０２）。
地図ファイルＣＦが格納されていない場合、センタ局２
は図４４の処理を終了する。一方、地図ファイルＣＦが
格納されている場合、読み出し制御部２３は、受信要求
解析部２２により導出されたパス名を受け取って、当該
パス名に従って第２の記憶装置２４から、要求された地
図ファイルＣＦを読み出す。読み出し制御部２３は、読
み出した地図ファイルＣＦをパケット組み立て部２５の
メモリに転送する。これによって、パケット組み立て部
２５は、要求された地図ファイルＣＦを内部に読み込む
（ステップＳ５０３）。パケット組み立て部２５は、読
み込んだ地図ファイルＣＦを基にパケットＰを組み立て
て（ステップＳ５０４）、第２の送受信部２１に出力す
る。第２の送受信部２１は、入力されたパケットＰをダ
ウンリンクＤＬに送出する（ステップＳ５０５）。な
お、ステップＳ５０４の詳細については後述される。

【０１５１】ステップＳ５０５が終了すると、受信要求
解析部２２は、要求ＲＥＱで指定される範囲の地図ファ
イルＣＦが第２のデータベース２５にさらに存在するか
否かを調べるために、前回のステップＳ５０１で指定し
た代表点座標に、要求ＲＥＱで指定されるレベルの経度
幅Ｗおよび緯度幅Ｈを加算して、当該加算値を、新しい
代表点として設定する。さらに、受信要求解析部２２
は、新しい代表点の経度座標および緯度座標が要求ＲＥ
Ｑで指定される右上経度座標および右上緯度座標を越え
ているか否かを判断する。新しい代表点の経度座標およ
び緯度座標が右上経度座標および右上緯度座標を越えて
いなければ、センタ局２では、引き続きステップＳ５０
２〜Ｓ５０５を処理が実行され、もう１つの地図ファイ
ルＣＦを基に組み立てられたパケットＰが端末装置１に
送信される。新しい代表点の経度座標および緯度座標が
右上経度座標および右上緯度座標を越えていれば、要求
された地図ファイルＣＦをすべて端末装置１に送信した
として、センタ局２は図４４の処理を終了する。以上の
ステップＳ５０１〜Ｓ５０５を繰り返すことにより、セ
ンタ局２は、端末装置１が要求した通りのレベルおよび
範囲の地図を表す地図ファイルＣＦを当該端末装置１に
送信することができる。

【０１５２】ここで、図４５は、地図ファイルＣＦから
パケットＰが組み立てられるまでの過程における、各デ
ータの構造を示している。ステップＳ５０３の終了時点
で、パケット組み立て部２５の内部には、図４５（ａ）
に示すように、１つの地図ファイルＣＦが読み込まれて
いる。パケット組み立て部２５は、ステップＳ５０４を
実行する。ここで、図４６は、ステップＳ５０４の詳細
な処理手順を示すフローチャートである。以下、図４５
および図４６を参照して、パケット組み立て部２５の処
理を詳細に説明する。最初に、パケット組み立て部２５
は、内部に読み込んだ地図ファイルＣＦを基に、マスタ
データＭＤを作成する（ステップＳ６０１）。マスタデ
ータＭＤは、図４５（ｂ）に示すように、データヘッダ
ＤＨとデータ部とから構成される。ここで図４７は、マ
スタデータＭＤの詳細な内部データ構造を示す。図４７
において、データヘッダＤＨは、ユニットＩＤおよびバ
ージョンコードから構成される。ユニットＩＤは、この
マスタデータＭＤの基礎となる地図ファイルＣＦを特定
するためのコードである。バージョンコードは、このマ
スタデータＭＤの基礎となる地図ファイルＣＦのフォー
マットバージョンおよびコンテンツバージョンを表すコ
ードである。なおユニットＩＤ、バージョンコード共に
地図ファイルＣＦのユニットヘッダ（図７参照）に格納
されている情報であり、地図ファイルＣＦがパケット組
み立て部２５に読み込まれた時点で、当該パケット組み
立て部２５により取り出され保持される。なお、これら
ユニットＩＤとバージョンコードは、後述する端末装置
１の処理において使用される。

【０１５３】またマスタデータＭＤのデータ部には、地
図ファイルＣＦそのものが設定される。ところで、地図
ファイルＣＦは、前述したように、各種テーブルから構
成される（図７参照）。これら各テーブルには互いに、
他のテーブルを参照し合うような情報は記録されない。
言い換えれば、端末装置１は各テーブルを独立的に使用
することができる。例えば、図８（ａ）に示すように、
端末装置１は、基本背景テーブルのみを出力装置１１０
に表示することができる。つまり、各テーブルは、互い
に分離可能なデータ構造を有する。そのため、データ部
は、基本背景テーブル、基本文字記号テーブル、主要道
ノードテーブル、主要道リンクテーブルの基本データ
（つまり、大略的な地図を表すデータ）のみから構成さ
れても良い。また、データ部は、詳細背景テーブル、詳
細文字記号テーブル、細街路ノードテーブル、細街路リ
ンクテーブルの詳細データのみから構成されても良い。
以上のように、地図ファイルＣＦの一部分がデータ部に
設定される場合がある。

【０１５４】なお、図７に示すように、ユニットヘッダ
には、ユニットＩＤおよびバージョンコードが含まれ
る。このユニットＩＤおよびバージョンコードは、デー
タヘッダＤＨ（図４７参照）に含まれる。したがって、
マスタデータＭＤのデータ部に、ユニットＩＤおよびバ
ージョンコードが設定されると、マスタデータＭＤ内に
２個のユニットＩＤおよびバージョンコードが含まれる
ことになる。そのため、このデータ部にはユニットＩＤ
とバージョンコードは含まれなくとも良い。

【０１５５】パケット組み立て部２５は、以上のように
して生成されたマスタデータＭＤをｉ個に分割する。こ
れによって、図４５（ｃ）のように、ｉ個のセグメント
データＳＤ１〜ＳＤｉが生成される（ステップＳ６０
２）。このステップＳ６０２において、パケット組み立
て部２５は、マスタデータＭＤに含まれるデータヘッダ
ＤＨおよびデータ部（つまり地図ファイルＣＦ）を意識
しない。つまり、いずれかのセグメントデータＳＤに、
データヘッダＤＨの一部と、データ部の一部とが混在す
る場合も起こりうる。これらｉ個のセグメントデータＳ
Ｄには、番号（以降、セグメント番号と称す）が付加さ
れる。このセグメント番号は、セグメントデータ相互で
重複せず、かつ連続する番号であることが好ましい。な
ぜなら、後述する端末装置１の処理が容易になるからで
ある。

【０１５６】さらに、パケット組み立て部２５は、ｉ個
のセグメントデータＳＤ１〜ＳＤｉに、誤り訂正符号
（または誤り検出符号）を付加する（ステップＳ６０
３）。これによって、図４５（ｄ）に示すように、ｉ個
のセグメントデータ（誤り訂正符号付き）ＳＤ１〜ＳＤ
ｉが生成される。パケット組み立て部２５はさらに、各
セグメントデータ（誤り訂正符号付き）ＳＤ１〜ＳＤｉ
をｊ個に分割する。これによって、図４５（ｅ）に示す
ように、１個のセグメントデータＳＤにつき、ｊ個のパ
ケットが生成される（ステップＳ６０４）。以上の処理
の結果、パケット組み立て部２５は、１つの地図ファイ
ルＣＦを基に、全部でｉ×ｊ個のパケットＰ１１，Ｐ１
２，…，Ｐ１ｊ，…Ｐｉｊを生成する。また、これらｉ
×ｊ個のパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉ
ｊにはそれぞれ、番号（以降、パケット番号と称す）が
付加される。このパケット番号は、パケット毎で互いに
重複しないようにかつ連続する番号であることが好まし
い。なぜなら、後述する端末装置１の処理が容易になる
からである。このパケット番号により、端末装置１は、
別々に送信されるｉ×ｊ個のパケットＰ１１，Ｐ１２，
…，Ｐ１ｊ，…Ｐｉｊが、すべて揃ったかどうかを容易
に判断できるようになる。このステップＳ６０４が終了
すると、パケット組み立て部２５は、サブルーチンであ
る図４６の処理から抜けて、図４４の処理に戻る。そし
て、ステップＳ５０５の処理が行われる。以上の各パケ
ットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊは、ステッ
プＳ５０５において、第２の送受信部２１から、通信網
３（ダウンリンクＤＬ）に順次送出され、端末装置１に
送信される。

【０１５７】次に、図４８のフローチャートを参照し
て、端末装置１における地図ファイルＣＦの受信手順に
ついて説明する。センタ局２より送信された各パケット
Ｐ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊは、通信網３
を通じて、端末装置１のアンテナ１６に入力される。第
１の送受信部１５は、アンテナ１６から出力されるパケ
ットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊを順次受信
する（ステップＳ７０１）。また、第１の送受信部１５
は、図示しないバッファメモリを有する。第１の送受信
部１５は、受信された各パケットＰ１１，Ｐ１２，…，
Ｐ１ｊ，…Ｐｉｊを、バッファメモリに順次格納する。
パケット分解部１７は、第１の送受信部１５のバッファ
メモリに定期的にアクセスして、センタ局２により送信
されたｉ×ｊ個のパケットＰ１１，Ｐ１２，…，Ｐ１
ｊ，…，Ｐｉｊがバッファメモリ内に揃っているか否か
を判断する（ステップＳ７０２）。ステップＳ７０２の
判断は、各パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，
Ｐｉｊに付加されたパケット番号に基づいて行われる。
より具体的には、パケット番号が連番であれば、パケッ
ト分解部１７は、１から（ｉ×ｊ）までのパケット番号
が全て揃っているか否かを判断する。

【０１５８】ステップＳ７０２で、パケットＰが全て揃
っていない場合、パケット分解部１７はステップＳ７０
３に進まず、ステップＳ７０１が再度実行される。その
結果、第１の送受信部１５は、不足分のパケットＰをや
がて受信する。一方、ステップＳ７０２で、パケットＰ
が全て揃っている場合、パケット組み立て部２５は、ス
テップＳ７０３に進む。パケット分解部１７は、ステッ
プＳ７０１で受信されたパケットＰ１１，Ｐ１２，…，
Ｐ１ｊ，…ＰｉｊからマスタデータＭＤを分解（デアセ
ンブリ）する（ステップＳ７０３）。ステップＳ７０３
の間に、誤り訂正も必要に行われる。分解されたマスタ
データＭＤはデータ処理部１３に出力される。データ処
理部１３は、入力されたマスタデータＭＤを基に地図フ
ァイルＣＦを作成して、作成した地図ファイルＣＦを読
み出し／書き込み制御部１８と協働してを第１の記憶装
置１９に格納する（ステップＳ７０４）。

【０１５９】ステップＳ７０４の後、データ処理部２５
は、受信すべき一連のパケットＰがまだあるか否かを判
断する（ステップＳ７０５）。受信すべきパケットＰが
ある場合、ステップＳ７０１に戻り、パケットＰの受信
処理が引き続き行われる。一方、受信すべきパケットＰ
がない場合には、図４８の処理を終了する。ここで、図
４９は、図４８のステップＳ７０３の詳細な処理手順を
示すフローチャートである。また、図５０は、パケット
Ｐ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐｉｊから地図ファイ
ルＣＦが作成されるまでの過程における各データの構造
を示している。上述から明らかなように、図４８のステ
ップＳ７０３が開始される時点で、第１の送受信部１５
には、図５０（ａ）に示すように、一連のパケットＰ１
１，Ｐ１２，…，Ｐ１ｊ，…，Ｐｉｊが揃っている。パ
ケット分解部１７は、第１の送受信部１５にバッファさ
れているパケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…，Ｐ
ｉｊから、処理すべきパケットＰを得る（ステップＳ８
０１）。今、パケット分解部１７はパケットＰ１１，Ｐ
１２，…，Ｐ１ｊを得ると仮定する。

【０１６０】次に、パケット分解部１７は、ステップＳ
８０１で得られた各パケットＰからパケット番号を外
す。パケット分解部１７は、番号が外された各パケット
Ｐを一まとめにして、図５０（ｂ）に示すように、１つ
のセグメントデータＳＤを復元する（ステップＳ８０
２）。上述の仮定に従うと、パケットＰ１１，Ｐ１２，
…，Ｐ１ｊが一まとめにされ、その結果、セグメントデ
ータＳＤ１が復元される。各セグメントデータＳＤには
誤り訂正符号（または誤り検出符号）が付加されてい
る。ステップＳ８０２の次に、パケット分解部１７は、
誤り訂正符号を利用して、復元されたセグメントデータ
（誤り訂正符号付き）ＳＤに生じている可能性がある誤
りを訂正する（ステップＳ８０３）。次に、パケット分
解部１７は、セグメントデータ（誤り訂正符号付き）Ｓ
Ｄから誤り訂正符号を外し、これによって、図５０
（ｃ）に示すように、セグメントデータ（誤り訂正符号
なし）ＳＤが復元される（ステップＳ８０４）。復元さ
れたセグメントデータＳＤは、パケット分解部１７の記
憶領域に保持される。上述の仮定に従うと、セグメント
データＳＤ１に誤り訂正が施された後、パケット分解部
１７の記憶領域に保持される。

【０１６１】ステップＳ８０４の次に、パケット分解部
１７は、第１の送受信部１５内に、処理すべきパケット
Ｐが残っているか否かを判断する（ステップＳ８０
５）。処理すべきパケットＰが残っている場合、パケッ
ト分解部１７はステップＳ８０１に戻って、ステップＳ
８０１〜Ｓ８０４を行って、図５０（ａ）〜（ｃ）に示
すように、パケットＰからセグメントデータＳＤを復元
する。本説明では、図４９の処理の開始時点で、第１の
送受信部１５には、（ｉ×ｊ）個のパケットＰがある。
したがって、ステップＳ７０１〜Ｓ７０５で構成される
ループはｉ回繰り返される。その結果、ｉ個のセグメン
トデータＳＤ１〜ＳＤｉが復元される。このループが必
要回数だけ繰り返されると、第１の送受信部１５内に
は、処理すべきパケットＰがなくなる。この状態で、ス
テップＳ８０５の判断が行われると、パケット分解部１
７は、ステップＳ８０６に進む。処理すべきパケットＰ
がなくなった時点で、ｉ個のセグメントデータＳＤ１〜
ＳＤｉがパケット分解部１７に保持される。また、上述
したように、各セグメントデータＳＤ１〜ＳＤｉには、
セグメント番号が付されている。パケット分解部１７
は、このセグメント番号に従って、つまりセグメント番
号が連続するように、セグメントデータＳＤ１〜ＳＤｉ
を順番に並べる。その後、セグメント番号は、各セグメ
ントデータＳＤ１〜ＳＤｉから取り外される。パケット
分解部１７は、セグメント番号が取り外されたセグメン
トデータＳＤ１〜ＳＤｉを一まとめにする。その結果、
図５０（ｄ）に示すように、マスタデータＭＤが復元さ
れる（ステップＳ８０６）。復元されたマスタデータＭ
Ｄは、データ処理部１３に出力される（ステップＳ８０
７）。

【０１６２】なお、本地図提供システムに限らず、通信
システムでは通信障害が起こりうる。したがって、端末
装置１は、全てのセグメントデータＳＤを正しく復元で
きるとは限らない。ここで、正しく復元されたセグメン
トデータＳＤとは、センタ局２が生成したものと同じセ
グメントデータＳＤを意味する。例えば、セグメントデ
ータＳＤ２が正しく復元されなかった場合であって、他
のセグメントデータＳＤ１、ＳＤ３〜ＳＤｉが正しく復
号された場合を想定する。かかる場合、パケット分解部
１７は、セグメントデータＳＤ１、ＳＤ３〜ＳＤｉに付
加された誤り訂正符号を利用して、セグメントデータＳ
Ｄ２を正しいものに復元することもできる。

【０１６３】データ処理部１３は、マスタデータＭＤの
入力に起因して、ステップＳ７０４を開始する。このス
テップＳ７０４は、上述したように、マスタデータＭＤ
から地図ファイルＣＦを作成する処理と、作成された地
図ファイルＣＦを第１の記憶装置１９に格納するための
処理である。ここで、図５１は、図４８のステップＳ７
０４の詳細な処理の手順を示すフローチャートである。
まず、データ処理部１３は、入力されたマスタデータＭ
ＤのデータヘッダＤＨから、ユニットＩＤを取り出す
（ステップＳ９０１）。前述のようにユニットＩＤは、
当該ユニットのパス名と相互に変換できるように付与さ
れている。データ処理部１３は、取り出したユニットＩ
Ｄから、マスタデータＭＤ内の地図ファイルＣＦのパス
名を導出する。

【０１６４】データ処理部１３は、ステップＳ９０２で
導出したパス名をもつ地図ファイルＣＦが既に、第１の
記憶装置１９内に格納されているかどうかを判断する
（ステップＳ９０３）。もし格納されていなければ、デ
ータ処理部１３は、マスタデータＭＤからデータヘッダ
ＤＨを取り外して、地図ファイルＣＦを得る。そして、
データ処理部１３は、導出したパス名および今回受信し
た地図ファイルＣＦとを読み出し／書き込み制御部１８
に転送する。読み出し／書き込み制御部１８は、転送さ
れてきたパス名に従って、今回受信した地図ファイルＣ
Ｆを第１の記憶装置１９に格納する。これによって、第
１のデータベース１１１には、新しい地図ファイルＣＦ
が追加されることとなる。

【０１６５】一方、ステップＳ９０３において、ステッ
プＳ９０２で導出したパス名をもつ地図ファイルＣＦ
が、第１の記憶装置１９内に既に存在すると判断された
場合の処理について説明する。この場合、データ処理部
１３は、ステップＳ９０４に進んで、マスタデータＭＤ
のデータヘッダＤＨ内に格納されているバージョンコー
ドを取り出す。さらに、データ処理部１３は、読み出し
／書き込み制御部１８と協働して、ステップＳ９０２で
導出したパス名を持つ地図ファイルＣＦを第１の記憶装
置１９から読み込む。データ処理部１３は、第１の記憶
装置１９から読み込んだ地図ファイルＣＦのユニットヘ
ッダ内に記録されたバージョンコードを取り出し、ステ
ップＳ９０４で取り出したバージョンコードと比較す
る。データ処理部１３は、マスタデータＭＤから取り出
したバージョンコードの方が新しいと判断された場合に
は、ステップＳ９０６に進み、マスタデータＭＤのデー
タ部のみを取り出して、新しいバージョンの地図ファイ
ルＣＦを第２の記憶装置３０に格納する。これによっ
て、第１のデータベース１１１において、古い地図ファ
イルＣＦは、新しいものに更新される。

【０１６６】逆に、データ処理部１３は、第１の記憶装
置１９から読み込んだ地図ファイルＣＦの方が新しいと
判断した場合には、受信したマスタデータＭＤを破棄す
る。つまり、今回受信した地図ファイルＣＦは第１の記
憶装置１９には格納されない。以上のように、本実施形
態に係る地図ファイルＣＦは、複数の縮尺の地図をユニ
ット単位で区切ってデジタルデータ化されることにより
生成される。各地図ファイルＣＦの記録領域（論理領
域）は、その親子関係および隣接関係を表すツリー構造
で特定されるパス名で表現される。これによって、各地
図ファイルＣＦは効率的に管理される。これによって、
１つのユニットＵには、他のユニットのデータ構造に関
連する情報が記録されないので、複数のユニットＵの間
の関係が薄くなる。これによって、ある１つの地図ファ
イルＣＦを更新した場合であっても、それ以外の地図フ
ァイルＣＦを更新する必要がなくなる。このように、本
実施形態に係る地図ファイルＣＦによれば、第１の記憶
装置１９における地図ファイルＣＦの新規格納処理およ
び更新処理が非常に簡単になる。

【０１６７】また、このような各地図ファイルＣＦにお
いて、互いに隣接するユニットＵの境界をまたがる道路
網の接続をたどる際に、データ処理部１３は、脱出ノー
ドおよび進入ノードの座標情報、ならびに／もしくは脱
出リンクおよび進入リンクの属性情報を参照する。つま
り、データ処理部１３は、隣接ユニットＮＵに記録され
たノードＮまたはリンクＬのレコード番号またはオフセ
ットアドレスのような、隣接ユニットＮＵの内部データ
構造に関わる情報を参照しない。そのため、第１の記憶
装置１９内のある１つの地図ファイルＣＦが更新された
場合においても、隣接ユニットＮＵの地図ファイルＣＦ
を更新することなく、互いに隣接し合う地図ファイルＣ
Ｆの道路網の接続を正確にたどることができる。

【０１６８】また、本実施形態では、あるユニットＵお
よび隣接ユニットＮＵの境界をまたがる道路網の接続を
たどる際に、隣接ユニットＮＵ側の進入ノードおよび進
入リンクを検索する必要が出てくる。しかしながら、各
ユニットＵにおいて、ノードレコードＮＲおよびリンク
レコードＬＲの並び方は予め規定されている。これによ
って、進入ノードおよび進入リンクの検索処理を高速化
することができる。

【０１６９】また、本実施形態では、経路探索処理にお
いて、データ処理部１３は、下位階層のあるノードＮか
ら、それと同じ位置を示すノードＮを上位階層の地図フ
ァイルＣＦから探し出す場合がある。この場合において
も、上下階層のユニットＵの間においても、子ユニット
ＣＵ側に親ユニットＰＵの内部データ構造に関わる情報
が記録されず、親ユニットＰＵ側に子ユニットＣＵの内
部データ構造に関わるような情報が記録されないので、
上位の階層の地図ファイルＣＦだけが更新されたような
場合においても、その子ユニットＣＵを表す地図ファイ
ルＣＦを全て更新するような必要性は生じない。

【０１７０】また以上のように、ユニットＵのように部
分的な領域の地図だけが新しいものに更新されたような
場合においても、隣接ユニット間および上下階層間での
データの整合性は保持されるため、センタ局２が端末装
置１などに有線あるいは無線で地図ファイルＣＦを提供
する場合においても、端末装置１が必要とする地図ファ
イルＣＦのみを送信することができる。これによって、
データ送信時間および通信コストの低減につながる。

【０１７１】なお、以上の実施形態は、端末装置１の一
例としてカーナビゲーションシステムを想定して説明し
た。しかし、パーソナルコンピュータ内に地図ファイル
ＣＦのデータベースを作成して、当該パーソナルコンピ
ュータが地図を表示したり、経路探索を行ったりするよ
うな用途にも、本実施形態は適用することができる。つ
まり、本実施形態は、移動可能な端末装置に限らず、据
え置き型の端末装置にも適用することができる。また、
据え置き型の端末装置に対しては、通信網３は無線伝送
路である必要性はなく、有線であってもよい。

【０１７２】なお、本実施形態では、端末装置１は、セ
ンタ局２と通信網３を通して双方向通信を行って、ユー
ザが必要とする地図の範囲をセンタ局２に通知し、当該
範囲に対応する地図ファイルＣＦを受信していた。しか
し、センタ局２は、放送形式で、地図ファイルＣＦを端
末装置１に送信してもよい。

【０１７３】なお、本実施形態では、第１のデータベー
ス１１１および第２のデータベース２５は、レベル
「０」〜「３」までの４段階の階層構造を有する地図フ
ァイルＣＦから構成されていた。しかし、第１のデータ
ベース１１１および第２のデータベース２５は、４階層
に限らず、何階層の地図ファイルＣＦから構成されても
構わない。また、本実施形態では、各階層地図は経度方
向および緯度方向に等間隔に分割され、これによって矩
形領域（ユニットＵ）が形成されていた。しかし、各階
層の地図ファイルＣＦのデータ量がほぼ一定になるよう
に、各階層地図は、経度方向および緯度方向に様々な間
隔で分割されてもよい。ただし、この場合、各地図ファ
イルＣＦには、経度方向および緯度方向に沿う分割サイ
ズを特定する情報を付加する必要がある。

【０１７４】また、本実施形態では、地図ファイルＣＦ
は、ユニットＵ単位で作成されていた。しかし、地図フ
ァイルＣＦは、複数のユニットＵと、当該複数のユニッ
トＵを管理するための管理情報とから構成されてもよ
い。この場合、地図ファイルＣＦの更新の容易さを確保
するために、１つの地図ファイルＣＦにまとめるユニッ
トＵの個数は最大６４個程度で、かつまとめられたユニ
ットＵを管理するための管理情報は複雑にならないよう
にすることが望ましい。

【０１７５】また、１つの地図ファイルＣＦにおいて、
隣接ノードのノードレコードＮＲは、当該ユニットＵの
境界を一周するような順序で記録されてもよい。今、記
録順序の一例として、隣接ノードのノードレコードＮＲ
は、ユニットＵの左下隅から時計周りの順序に従って記
録されると仮定する。この仮定下では、図３９に示すユ
ニットＵ１に含まれる隣接ノードのノードレコードＮＲ
は、「Ｎ１０」→「Ｎ１１」→「Ｎ１２」→「Ｎ１３」
→「Ｎ１４」→「Ｎ１５」→「Ｎ１８」→「Ｎ１７」→
「Ｎ１６」→「Ｎ２０」→「Ｎ１９」という順序で記録
される。また、ユニットＵ３に含まれる隣接ノードのノ
ードレコードＮＲは、「Ｎ３０」→「Ｎ３１」→「Ｎ３
２」→「Ｎ３４」→「Ｎ３３」→「Ｎ３８」→「Ｎ３
７」→「Ｎ３６」→「Ｎ３５」という順序で記録され
る。さらに、ユニットＵ２に含まれる隣接ノードのノー
ドレコードＮＲは、「Ｎ２０」→「Ｎ２１」→「Ｎ２
２」→「Ｎ２３」→「Ｎ２４」→「Ｎ２５」→「Ｎ２
７」→「Ｎ２６」という順序で記録される。今、具体例
として、データ処理部１３が、隣接ノードＮ１４および
Ｎ１５に対応する隣接ノードＮ３７およびＮ３８を検索
する場合について説明する。上述したように、ユニット
Ｕ１の地図ファイルＣＦでは隣接ノードＮ１４→Ｎ１５
の順序でノードレコードＮＲは記録される。一方、ユニ
ットＵ３の地図ファイルＣＦでは隣接ノードＮ３８→Ｎ
３７の順序でノードレコードＮＲは記録される。したが
って、データ処理部１３が隣接ノードＮ１４に対応する
隣接ノードＮ３７を探し出せれば、隣接ノードＮ１５に
対応する隣接ノードは、隣接ノードＮ３７のノードレコ
ードＮＲの一つ手前に記録されている。そのため、デー
タ処理部１３は、隣接ノードＮ１５に対応する隣接ノー
ドをいち早く探し出すことができる。このように、隣接
ノードのノードレコードＮＲがユニットＵの境界を一周
するような順序で記録されることにより、あるユニット
Ｎとその隣接ユニットとの境界上に並ぶ隣接ノードは、
それぞれの地図ファイルＣＦにおいて互いに逆順に連続
して並ぶこととなるので、データ処理部１３は、あるユ
ニットの隣接ノートに対応する隣接ユニットの隣接ノー
ドを高速に見つけることができる。

【０１７６】「第２の実施形態」図５２は、本発明の第
２の実施形態に係る地図提供システムの構成を示す。本
地図提供システムには、センタ局１０１と端末装置１０
２とが収容される。センタ局１０１と端末装置１０２と
は無線伝送路１０３により接続される。無線伝送路１０
３には、センタ局１０１から端末装置１０２へのダウン
リンクが少なくとも形成される。センタ局１０１は、地
図サーバ１０１１と、アンテナ１０１２とを備える。地
図サーバ１０１１には、第１の記憶装置１０１３と、読
み出し制御部１０１４と、パケット組み立て部１０１５
と、送信部１０１６とを含む。端末装置１０２は、典型
的には、カーナビゲーションシステムであって、アンテ
ナ１０２１と、受信部１０２２と、パケット分解部１０
２４およびファイル管理部１０２５を含むデータ処理部
１０２３と、第２の記憶装置１０２６とを備える。

【０１７７】次に、センタ局１０１の構成を説明する。
第１の記憶装置１０１３には、端末装置１０２に提供可
能な地図ファイルＣＦが１つ以上蓄積される。地図ファ
イルＣＦの詳細は後述される。第１の記憶装置１０１３
は、典型的には、ハードディスクドライブ、ＣＤ−ＲＯ
ＭドライブまたはＤＶＤ−ＲＯＭドライブから構成され
る。読み出し制御部１０１４は、必要に応じて第１の記
憶装置１０１３から、地図ファイルＣＦの一部分を、端
末装置１０２に提供すべき地図データＣＤとして読み出
す。この地図データＣＤの詳細は後述される。読み出さ
れた地図データＣＤは、パケット組み立て部１０１５に
出力される。

【０１７８】パケット組み立て部１０１５は、入力され
た地図データＣＤを基にパケットＰを組み立てる（アセ
ンブリする）。パケット組み立て部１０１５の詳細な処
理およびパケットＰの形式は、後述される。組み立てら
れたパケットＰは送信部１０１６に出力される。送信部
１０１６は、入力されたパケットＰを、アンテナ１０１
２を通じて無線伝送路１０３に送り出し、これによっ
て、地図データＣＤはパケットＰとして端末装置１０２
に送信される。送信部１０１６およびアンテナ１０１２
は、典型的には、携帯電話等の移動体通信装置、もしく
は、地上波デジタル放送または衛星デジタル放送等の放
送装置により実現される。

【０１７９】次に、端末装置１０２の構成について説明
する。受信部１０２２は、センタ局１０１により送信さ
れたパケットＰを、無線伝送路１０３を通じて受信す
る。アンテナ１０２１および受信部１０２２は、典型的
には、携帯電話等の移動体通信装置、もしくは、地上波
デジタル放送または衛星デジタル放送等の受信装置を用
いて実現される。受信部１０２２は、受信したパケット
Ｐをパケット分解部１０２４に出力する。パケット分解
部１０２４は、入力されたパケットＰを分解（デアセン
ブリ）して、地図データＣＤを復元する。復元された地
図データＣＤはファイル管理部１０２５に出力される。
ファイル管理部１０２５は、入力された地図データＣＤ
を、予め定められた手順に従って処理する。この処理の
手順は後述される。この処理により、地図ファイルＣＦ
が作成される。地図ファイルＣＦは、センタ局１０１側
の地図ファイルＣＦ地図データと同様の構造を有する。
地図ファイルＣＦの詳細は後述される。第２の記憶装置
１０２６は、読み出しおよび書き込みが可能で、大容量
の記憶媒体を有する。第２の記憶装置１０２６は、典型
的には、ＨＤＤ、ＤＶＤ−ＲＡＭ駆動装置により構成さ
れる。この記憶媒体上に、ファイル管理部１０２５によ
り生成された地図ファイルＣＦが書き込まれる。また、
周知のように、第２の記憶装置１０２６はクラスタ単位
で記憶領域を管理する。

【０１８０】なお、データ処理部１０２３は、上記復号
やファイル管理以外にも、様々な処理（例えば、経路探
索、マップマッチングまたは経路案内）を行う。さら
に、データ処理部１０２３は、必要に応じて、第２の記
憶装置１０２６内の地図ファイルＣＦを部分的に取り出
して、後述する出力装置に出力する。また、端末装置１
０２は、図示された構成以外にも、入力装置および出力
装置を備える。しかし、これらの処理、入力装置および
出力装置は、本願発明のポイントではなく詳説されず、
さらに図示もされない。入力装置および出力装置を簡単
に説明する。入力装置は、端末装置１０２のユーザによ
り操作される。ユーザは、入力装置を通じて、地図のス
クロールまたは縮尺変更等を、端末装置１０２に対して
要求する。また、出力装置は、主として、ディスプレイ
およびスピーカから構成される。ディスプレイには、必
要に応じて地図が表示される。さらに、ディスプレイに
は、データ処理部１０２３が行った経路探索処理または
経路案内処理の結果も表示する場合がある。スピーカ
は、データ処理部１０２３が行った経路案内処理の結果
を音声によりユーザに提供する。

【０１８１】次に、図５３を参照して、各地図ファイル
ＣＦの構造を説明する。まず、図５３（ａ）のように、
ある範囲の地図αは、予め定めされた形状（本実施形態
では便宜上、矩形形状とされる）のＭ×Ｎ個（Ｍおよび
Ｎは任意の自然数）の領域に区画され、ユニットＵ_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 、最大の経度ＬＡＴ_{MA X} および緯度ＬＯＮ_MAX 、経
度方向の実距離Ｄ_LAT 、および緯度方向の実距離Ｄ _LON
とを含む。ここで、ＬＡＴ_MIN 、ＬＯＮ_MIN 、ＬＡＴ
_MAX およびＬＯＮ_MAXは、図５３（ａ）に示すように、
地図αの最小経度、最小緯度、最大経度および最大緯度
を示す。また、Ｄ_LAT およびＤ_LON は、図５３（ａ）に
示すように、地図αの経度方向および緯度方向の実際の
距離を示す。このように、ＬＡＴ_MIN 、ＬＯＮ_MIN 、Ｌ
ＡＴ_MAX 、ＬＯＮ_MAX 、Ｄ_LAT 、およびＤ_LON は、地図
ファイルＣＦ（つまり地図α）がカバーする範囲を規定
する。ユニット管理情報ＭＩ_UNITには、各ユニットレコ
ードＵＲ_0,0 〜ＵＲ_M-1,N-1を管理するための情報が記
述される。より具体的には、ユニット管理情報ＭＩ_{UN IT}
は、地図ファイルＣＦに含まれるユニットレコードの数
ＮＯＵと、各ユニットレコードのオフセット値Ｘ_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のオフセット値
Ｘ₀ 〜Ｘ_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、および１つのユニットレコードＵＲに基づ
いて生成される（ステップＳ１１０１）。なお、マスタ
データＭＤは、地図ファイルＣＦから直接的に生成され
るのではなく、パケット組み立て部１０１５が保持する
１つのユニットレコードＵＲに基づいて生成される。か
かる生成方法が採用されることにより、たとえ、図５９
のステップＳ１００１〜Ｓ１００７において、外部的あ
るいは内部的要因によってエラーが発生しても、そのエ
ラーの影響は、１個のユニットレコードＵＲにしか及ば
ないからである。つまり、エラーの影響が地図データＣ
Ｄ全体に及ぶことを避けるためである。

【０２００】マスタデータＭＤは、図６０（ｂ）に示す
ように、データヘッダＤＨとデータ部とから構成され
る。ここで、図６２は、マスタデータＭＤの詳細な構造
を示す。図６１において、データヘッダＤＨは、ファイ
ルＩＤ、ユニットＩＤおよびユニットサイズから構成さ
れる。ファイルＩＤは、このマスタデータＭＤの基礎と
なる地図データＣＤ（つまり、現在、パケット組み立て
部１０１５に展開されているもの）を特定するためのコ
ードである。このファイルＩＤの生成方法の一例を説明
する。パケット組み立て部１０１５は、ファイルヘッダ
ＦＨを保持している。前述したように、ファイルヘッダ
ＦＨには、地図ファイルＣＦ（地図α）がカバーする範
囲を特定するための情報が記述される（図５３（ｂ）参
照）。したがって、ファイルヘッダＦＨは、地図ファイ
ルＣＦを特定することも可能である。パケット組み立て
部１０１５は、このファイルヘッダＦＨを用いて、ファ
イルＩＤを生成する。ユニットＩＤは、このマスタデー
タＭＤの基礎となるユニットレコードＵＲ（つまり、ス
テップＳ１００２で抜き出されたもの）を特定するため
のコードである。パケット組み立て部１０１５は、ステ
ップＳ１００２の終了以降、送信すべきユニットレコー
ドＵＲ（図５４参照）を保持している。パケット組み立
て部１０１５は、保持されたユニットレコードＵＲか
ら、ユニットＩＤを取り出す。取り出されたユニットＩ
Ｄが、データヘッダＤＨに設定される。なお、以上の２
つのＩＤおよびユニットサイズは、後述する端末装置１
０２の処理において使用される。

【０２０１】また、マスタデータＭＤのデータ部には、
ファイルヘッダＦＨと、ユニットレコードＵＲが有する
全データまたは一部のデータが設定される。設定される
ファイルヘッダＦＨおよびユニットレコードＵＲは、パ
ケット組み立て部１０１５が保持しているものである。
ところで、ユニットレコードＵＲには、前述したよう
に、各種テーブルが保持される（図５４参照）。これら
各テーブルは、互いに分離可能な構造を有する。そのた
め、データ部は、基本背景データテーブルＢＢＤ、基本
文字記号データテーブルＢＣＤ、主要幹線ネットワーク
データテーブルＭＮＤの基本データ（つまり、大略的な
地図を表すデータ）のみから構成されても良い。また、
データ部は、詳細背景データテーブルＤＢＤ、詳細文字
記号データテーブルＤＣＤ、細街路ネットワークデータ
テーブルＳＮＤの詳細データのみから構成されても良
い。以上のように、ユニットレコードＵＲの一部分がデ
ータ部に設定される場合がある。なお、図５４に示すよ
うに、ユニットヘッダＵＨには、ユニットＩＤが含まれ
る。このユニットＩＤは、データヘッダＤＨ（図６２参
照）に含まれる。したがって、マスタデータＭＤのデー
タ部に、ユニットＩＤが設定されると、マスタデータＭ
Ｄ内に２個のユニットＩＤが含まれることになる。その
ため、このデータ部にはユニットＩＤが含まれなくとも
良い。

【０２０２】ところで、データヘッダＤＨのデータサイ
ズは、データ部のサイズである。ファイルヘッダＦＨ
と、ユニットレコードＵＲの全体とのサイズは、第１の
記憶装置１０１３に地図ファイルＣＦが生成された時点
で決まるので、容易に求められる。また、データ部に、
部分的なユニットレコードＵＲが設定される場合には、
対応するユニットヘッダＵＨに設定されている各サイズ
に基づいて、当該部分的なユニットレコードＵＲのサイ
ズは求められる。

【０２０３】パケット組み立て部１０１５は、生成され
たマスタデータＭＤをｉ個に分割する。これによって、
図６０（ｃ）のように、ｉ個のセグメントデータＳＤ₁
〜ＳＤ_i が生成される（ステップＳ１１０２）。このス
テップＳ１１０２において、パケット組み立て部１０１
５は、マスタデータＭＤに含まれるデータヘッダＤＨお
よびデータ部（つまりユニットレコードＵＲ）を意識し
ない。つまり、いずれかのセグメントデータＳＤに、デ
ータヘッダＤＨの一部と、データ部の一部とが混在する
場合も起こりうる。これらｉ個のセグメントデータＳＤ
には、番号（以降、セグメント番号と称す）が付加され
る。このセグメント番号は、セグメントデータ相互で重
複せず、かつ連続する番号であることが好ましい。なぜ
なら、後述する端末装置１０２の処理が容易になるから
である。

【０２０４】さらに、パケット組み立て部１０１５は、
ｉ個の各セグメントデータＳＤ₁ 〜ＳＤ_i に、誤り訂正
符号（または誤り検出符号）を付加する（ステップＳ１
１０３）。これによって、図６０（ｄ）に示すように、
ｉ個のセグメントデータ（誤り訂正符号付き）ＳＤ₁ 〜
ＳＤ_i が生成される。パケット組み立て部１０１５はさ
らに、各セグメントデータ（誤り訂正符号付き）ＳＤ₁
〜ＳＤ_i をｊ個に分割する。これによって、図６０
（ｅ）に示すように、１個のセグメントデータＳＤにつ
き、ｊ個のパケットが生成される（ステップＳ１１０
４）。以上の処理の結果、パケット組み立て部１０１５
は、ステップＳ１００２で抜き出された１つのユニット
レコードＵＲを基に、全部でｉ×ｊ個のパケットＰ₁₁、
Ｐ₁₂、…Ｐ_1j、…Ｐ_ijを生成する。また、これらｉ×ｊ
個のパケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…Ｐ _ijにはそれぞ
れ、番号（以降、パケット番号と称す）が付加される。
このパケット番号は、パケット毎で互いに重複しないよ
うにかつ連続する番号であることが好ましい。なぜな
ら、後述する端末装置１０２の処理が容易になるからで
ある。このパケット番号により、端末装置１０２は、別
々に送信されるｉ×ｊ個のパケットＰ₁₁、Ｐ₁₂、…
Ｐ_1j、…Ｐ_ijが、すべて揃ったかどうかを容易に判断で
きるようになる。このステップＳ１１０４が終了する
と、パケット組み立て部１０１５は、サブルーチンであ
る図６１の処理から抜けて、図５９の処理に戻る。そし
てステップＳ１００４が行われる。以上の各パケットＰ
₁₁、Ｐ₁₂、…Ｐ_1j、…Ｐ _ijは、ステップＳ１００４にお
いて、送信部１０１６から、アンテナ１０１２を通じて
無線伝送路１０３に順次送出され、端末装置１０２に送
信される。

【０２０５】次に、図６３のフローチャートを参照し
て、端末装置１０２における地図データの受信手順につ
いて説明する。センタ局により送信された各パケットＰ
₁₁、Ｐ ₁₂、…Ｐ_1j、…Ｐ_ijは、無線伝送路１０３を通じ
て、端末装置１０２のアンテナ１０２１に入力される。
受信部１０２２は、アンテナ１０２１から出力されるパ
ケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…Ｐ_ijを順次受信する（ス
テップＳ１２０１）。また、受信部１０２２は、図示し
ないバッファメモリを有する。受信部１０２２は、受信
された各パケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…Ｐ_ijを、バッ
ファメモリに順次格納する。

【０２０６】パケット分解部１０２４は、受信部１０２
２のバッファメモリに定期的にアクセスして、センタ局
１０１により送信されたｉ×ｊ個のパケットＰ₁₁、
Ｐ₁₂、…Ｐ_1j、…Ｐ_ijがバッファメモリ内に揃っている
か否かを判断する（ステップＳ１２０２）。ステップＳ
１２０２の判断は、各パケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…
Ｐ _ijに付加されたパケット番号に基づいて行われる。よ
り具体的には、パケット番号が連番であれば、パケット
分解部１０２４は、１から（ｉ×ｊ）までのパケット番
号が全て揃っているか否かを判断する。

【０２０７】ステップＳ１２０２で、パケットＰが全て
揃っていない場合、パケット分解部１０２４はステップ
Ｓ１２０３に進まず、ステップＳ１２０１が再度実行さ
れる。その結果、受信部１０２２は、不足分のパケット
Ｐを受信する。一方、ステップＳ１２０２で、パケット
Ｐが全て揃っている場合、パケット分解部１０２４は、
ステップＳ１２０３に進む。パケット分解部１０２４
は、ステップＳ１２０１で受信されたパケットＰ₁₁、Ｐ
₁₂、…Ｐ_1j、…Ｐ_ijを分解して、マスタデータＭＤを復
元する（ステップＳ１２０３）。復元されたマスタデー
タＭＤはファイル管理部１０２５に出力される。ファイ
ル管理部１０２５は、入力されたマスタデータＭＤを基
に地図ファイルＣＦを生成する。生成された地図ファイ
ルＣＦは第２の記憶装置１０２６に格納される（ステッ
プＳ１２０４）。

【０２０８】ステップＳ１２０４の後、データ処理部１
０２３は、受信すべき一連のパケットＰがまだあるか否
かを判断する（ステップＳ１２０５）。受信すべきパケ
ットＰがある場合、ステップＳ１２０１に戻り、パケッ
トＰの受信処理が引き続き行われる。一方、受信すべき
パケットＰがない場合には、図６３の処理を終了する。

【０２０９】ここで、図６４は、図６３のステップＳ１
２０３の詳細な処理の手順を示すフローチャートであ
る。また、図６５は、パケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…
Ｐ_ijから地図ファイルＣＦが生成されるまでの過程にお
ける各データの構造を示している。上述から明らかなよ
うに、図６３のステップＳ１２０３が開始される時点
で、受信部１０２２には、図６５（ａ）に示すように、
一連のパケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…Ｐ_ijが揃ってい
る。パケット分解部１０２４は、受信部１０２２に保持
されているパケットＰ₁₁、Ｐ₁₂、…Ｐ_1j、…Ｐ_ijから、
処理すべきパケットＰを得る（ステップＳ１３０１）。
今、パケット分解部１０２４はパケットＰ₁₁、Ｐ₁₂、…
Ｐ_1jを得ると仮定する。

【０２１０】次に、パケット分解部１０２４は、ステッ
プＳ１３０１で得られた各パケットＰからパケット番号
を外す。パケット分解部１０２４は、番号が外された各
パケットＰを分解して、図６５（ｂ）に示すように、１
つのセグメントデータＳＤを復元する（ステップＳ１３
０２）。上述の仮定に従うと、パケットＰ₁₁、Ｐ₁₂、…
Ｐ_1jが一まとめにされ、その結果、セグメントデータＳ
Ｄ₁ が復元される。各セグメントデータＳＤには誤り訂
正符号（または誤り検出符号）が付加されている。ステ
ップＳ１３０２の次に、パケット分解部１０２４は、誤
り訂正符号を利用して、復元されたセグメントデータ
（誤り訂正符号付き）ＳＤに生じている可能性がある誤
りを訂正する（ステップＳ１３０３）。次に、パケット
分解部１０２４は、セグメントデータ（誤り訂正符号付
き）ＳＤから誤り訂正符号を外し、これによって、図６
５（ｃ）に示すように、セグメントデータ（誤り訂正符
号なし）ＳＤが復元される（ステップＳ１３０４）。復
元されたセグメントデータＳＤは、パケット分解部１０
２４の記憶領域に保持される。上述の仮定に従うと、セ
グメントデータＳＤ₁ に誤り訂正が施された後、パケッ
ト分解部１０２４の記憶領域に保持される。

【０２１１】ステップＳ１３０４の次に、パケット分解
部１０２４は、受信部１０２２内に、処理すべきパケッ
トＰが残っているか否かを判断する（ステップＳ１３０
５）。処理すべきパケットＰが残っている場合、パケッ
ト分解部１０２４はステップＳ１３０１に戻って、ステ
ップＳ１３０１〜Ｓ１３０４を行って、図６５（ａ）〜
（ｃ）に示すように、パケットＰからセグメントデータ
ＳＤを復元する。本説明では、図６４の処理の開始時点
で、受信部１０２２には、（ｉ×ｊ）個のパケットＰが
ある。したがって、ステップＳ１２０１〜Ｓ１２０５で
構成されるループはｉ回繰り返される。その結果、ｉ個
のセグメントデータＳＤ₁ 〜ＳＤｉ が復元される。

【０２１２】このループが必要回数だけ繰り返される
と、受信部１０２２内には、処理すべきパケットＰがな
くなる。この状態で、ステップＳ１３０５の判断が行わ
れると、パケット分解部１０２４は、ステップＳ１３０
６に進む。処理すべきパケットＰがなくなった時点で、
ｉ個のセグメントデータＳＤ₁ 〜ＳＤ_i がパケット分解
部１０２４に保持される。また、上述したように、各セ
グメントデータＳＤ₁ 〜ＳＤ_i には、セグメント番号が
付されている。パケット分解部１０２４は、このセグメ
ント番号に従って、つまりセグメント番号が連続するよ
うに、セグメントデータＳＤ₁ 〜ＳＤ_i を順番に並べ
る。その後、セグメント番号は、各セグメントデータＳ
Ｄ₁ 〜ＳＤ_i から取り外される。パケット分解部１０２
４は、セグメント番号が取り外されたセグメントデータ
ＳＤ₁ 〜ＳＤ_i を一まとめにする。その結果、図６５
（ｄ）に示すように、マスタデータＭＤが復元される
（ステップＳ１３０６）。復元されたマスタデータＭＤ
は、ファイル管理部１０２５に出力される（ステップＳ
１３０７）。

【０２１３】なお、本地図提供システムに限らず、通信
システムでは通信障害が起こりうる。したがって、端末
装置１０２は、全てのセグメントデータＳＤを正しく復
元できるとは限らない。ここで、正しく復元されたセグ
メントデータＳＤとは、センタ局１０１が生成したもの
と同じセグメントデータＳＤを意味する。例えば、セグ
メントデータＳＤ２が正しく復元されなかった場合であ
って、他のセグメントデータＳＤ₁ 、ＳＤ₃〜ＳＤ_i が
正しく復号された場合を想定する。かかる場合、パケッ
ト分解部１０２４は、セグメントデータＳＤ₁ 、ＳＤ₃
〜ＳＤ_i に付加された誤り訂正符号を利用して、セグメ
ントデータＳＤ２ を正しいものに復元することもでき
る。

【０２１４】ファイル管理部１０２５は、マスタデータ
ＭＤの入力に起因して、ステップＳ１２０４を開始す
る。このステップＳ１１０４は、上述したように、マス
タデータＭＤから地図ファイルＣＦを生成する処理と、
生成された地図ファイルＣＦを第２の記憶装置１０２６
に格納するための処理である。ここで、図６６は、図６
３のステップＳ１２０４の詳細な処理の手順を示すフロ
ーチャートである。

【０２１５】ところで、第２の記憶装置１０２６は、ス
テップＳ１２０４の開始時点で、以前に生成された地図
ファイルＣＦを既に記憶していることがある。また、地
図ファイルＣＦが記憶されていない場合もある。ファイ
ル管理部１０２５は、マスタデータＭＤの入力後、第２
の記憶装置１０２６内に地図ファイルＣＦが格納されて
いるか否かを判断する（ステップＳ１４０１）。ファイ
ル管理部１０２５は、地図ファイルＣＦがある場合、後
述するステップＳ１４０４に進む。一方、ファイル管理
部１０２５は、地図ファイルＣＦが無い場合、今回のマ
スタデータＭＤを基に、完全に新規な地図ファイルＣＦ
を作成する（ステップＳ１４０２）。なお、この地図フ
ァイルＣＦは、地図ファイルＣＦと同様のデータ構造を
有する（図５３（ｂ）および図５４参照）。

【０２１６】ここで、地図ファイルＣＦの作成方法を説
明する。マスタデータＭＤは、図６２に示したように、
地図ファイルＩＤ、ユニットＩＤおよびデータサイズを
データヘッダＤＨに有する。さらに、このマスタデータ
ＭＤは、ファイルヘッダＦＨと、全部または一部のユニ
ットレコードＵＲをデータ部に有する。ファイル管理部
１０２５は、マスタデータＭＤから、ファイルヘッダＦ
Ｈを取り出す。

【０２１７】前述したように、マスタデータＭＤには１
個のユニットレコードＵＲしか含まれない。また、ファ
イル管理部１０２５は、今回、完全に新規な地図ファイ
ルＣＦを生成する。そのため、ファイル管理部１０２５
は、初期値「１」のユニット数ＮＯＵを生成する。さら
に、ファイル管理部１０２５は、ファイルヘッダＦＨお
よびユニット数ＮＯＵのデータサイズとから、今回得ら
れたユニットレコードＵＲまでのオフセット値Ｘ_0,0 を
求める。これによって、ユニット管理情報ＭＩ _UNITが生
成される。

【０２１８】これによって、ファイル管理部１０２５
は、完全に新規な地図ファイルＣＦを生成するために必
要な情報を全て得たこととなる。ファイル管理部１０２
５は、今回得られたファイルヘッダＦＨ、ユニット管理
情報ＭＩ_UNITおよびユニットレコードＵＲを一まとめに
して、地図ファイルＣＦを生成する。この地図ファイル
ＣＦのデータ構造は、図６７に示す通りである。以上の
ようにして生成された地図ファイルＣＦは、第２の記憶
装置１０２６内に格納される（ステップＳ１４０３）。

【０２１９】次に、ステップＳ１４０１で、地図ファイ
ルＣＦが見つけられた場合の処理について説明する。こ
の場合、ステップＳ１４０４が行われる。ファイル管理
部１０２５は、今回入力されたマスタデータＭＤから、
ファイルＩＤを取り出す。ファイルＩＤは、前述したよ
うに、マスタデータＭＤ内のユニットレコードＵＲがど
の地図ファイルＣＦに属していたかを特定する。このフ
ァイルＩＤは、図６１を参照して前述したように、パケ
ット組み立て部１０１５により、地図ファイルＣＦのフ
ァイルヘッダＦＨを用いて生成されている。また、ファ
イル管理部１０２５は、第２の記憶装置１０２６内の各
地図ファイルＣＦのファイルヘッダＦＨを取り出す。フ
ァイルヘッダＦＨは、地図ファイルＣＦがカバーする範
囲を特定するものである。地図ファイルＣＦのファイル
ヘッダＦＨは、ステップＳ１４０２で説明したように、
センタ局１０１側で管理される地図ファイルＣＦを基に
作成されている。したがって、ファイルＩＤとファイル
ヘッダＦＨとに同一性があれば、今回入力されたユニッ
トレコードＵＲは、地図ファイルＣＦの一部を構成する
こととなる。そのため、ファイル管理部１０２５は、両
者の同一性を判断する（ステップＳ１４０４）。

【０２２０】ステップＳ１４０４で、同一性が無いと判
断されると、入力されたユニットレコードＵＲを構成要
素とする地図ファイルＣＦがまだ作成されていないこと
を意味する。この場合、ファイル管理部１０２５は、上
述のステップＳ１４０２およびＳ１４０３を実行する。
つまり、全く新規な地図ファイルＣＦが生成された後
に、第２の記憶装置１０２６に格納される。

【０２２１】一方、ステップＳ１４０４で、ファイルＩ
ＤおよびファイルヘッダＦＨに同一性があると判断され
ると、入力されたユニットレコードＵＲを構成要素とす
る地図ファイルＣＦが既に生成されていることを意味す
る。この場合、ファイル管理部１０２５は、この地図フ
ァイルＣＦを処理対象として選択する。ファイル管理部
１０２５は、この処理対象の地図ファイルＣＦを開き
（ステップＳ１４０５）、入力されたユニットレコード
ＵＲを、処理対象として選択された地図ファイルＣＦに
追加する（ステップＳ１４０６）。つまり、ステップＳ
１４０６では、入力されたユニットレコードＵＲと、地
図ファイルＣＦとが一まとめにされ、更新された地図フ
ァイルＣＦが生成される。

【０２２２】ステップＳ１４０６について、より詳細に
説明する。ファイル管理部１０２５は、今回のマスタデ
ータＭＤから、ユニットＩＤを取り出す。以降、入力さ
れたマスタデータＭＤから取り出されたユニットＩＤ
を、第１のユニットＩＤと称す。第１のユニットＩＤ
は、図６２を参照して説明したように、今回入力された
マスタデータＭＤの基礎となったユニットレコードＵＲ
を特定する。また、ファイル管理部１０２５は、ステッ
プＳ１４０５で開かれた地図ファイルＣＦから、全ての
ユニットＩＤを取り出す。以降、地図ファイルＣＦから
取り出された各ユニットＩＤを、第２のユニットＩＤと
称す。第２のユニットＩＤの中には、第１のユニットＩ
Ｄと一致するものが含まれていない場合と、一致するも
のが含まれている場合がある。

【０２２３】第１および第２のユニットＩＤが一致しな
い場合、ファイル管理部１０２５は、今回入力されたマ
スタデータＭＤから、ユニットレコードＵＲを取り出し
て、図６８に示すように、現在開かれている地図ファイ
ルＣＦに追加して、当該地図ファイルＣＦを更新する。
第１および第２のユニットＩＤが一致する場合、今回入
力されたユニットレコードＵＲは、過去に、センタ局１
０１により、端末装置１０２に提供されていることとな
る。例えば、図５４に示す構造をもつユニットレコード
ＵＲにおいて、基本背景データテーブルＢＢＤ、基本文
字記号データテーブルＢＣＤ、主要幹線ネットワークデ
ータテーブルＭＮＤ等の基本データ（概略データ）のみ
が、ステップＳ１２０４の時点で、端末装置１０２に既
に提供されているような場合がある。この場合、現在開
かれている地図ファイルＣＦは、図６９のような構造を
有する。ファイル管理部１０２５は、この場合、図７０
に示すように、今回入力されたマスタデータから取り出
されたユニットレコードＵＲを、現在開かれている地図
ファイルＣＦにおいて、同じユニットＩＤが付されてい
るユニットレコードＵＲに追加する。これによって、地
図ファイルＣＦが更新される。

【０２２４】ファイル管理部１０２５は、さらに、今回
入力されたマスタデータＭＤのデータサイズに従って、
ユニット管理情報ＭＩ_UNITを更新する（ステップＳ１４
０７）。次に、ファイル管理部１０２５は、更新された
地図ファイルＣＦを、第２の記憶装置１０２６に格納す
る（ステップＳ１４０８）。

【０２２５】以上のように、本地図提供システムでは、
第１の記憶装置１０１３には、地図ファイルＣＦが格納
される。パケット組み立て部１０１５は、端末装置１０
２に送信すべき部分的な地図のみを読み出し制御部１０
１４から受け取り、当該地図を表す一連のパケットＰを
生成する。この一連のパケットＰが、無線伝送路１０３
上を伝送される。この無線伝送路１０３上には、部分的
な地図を表すデータしか送信されない。そのため、本地
図提供システムは、たとえ、地図ファイルＣＦ自体が大
きなサイズであっても、無線伝送路１０３に送出するデ
ータの量を抑えることができる。これによって、無線伝
送路１０３は輻輳しにくくなる。

【０２２６】また、端末装置１０２は、部分的な地図を
表すデータを順次受信することになる。しかし、端末装
置１０２は、初期的には、部分的な地図データを個別に
ファイル化することになる。しかし、端末装置１０２
は、所定条件を満たす地図ファイルＣＦが存在する場合
には、受信された部分的な地図データを、当該地図ファ
イルＣＦに追加して、一まとめにする。そのため、本地
図提供システムは、端末装置１０２において、大量のフ
ァイルが発生することを抑えることができる。そのた
め、第２の記憶装置１０２６内には、空き領域を有する
クラスタが生じにくくなる。その結果、本地図提供シス
テムは、第２の記憶装置１０２６の記憶領域を有効的に
利用することができる。

【０２２７】また、地図ファイルＣＦは、図５２に示す
ように、予め定められた範囲の地図αが複数の領域に区
画されることにより、つまり、ユニットＵ単位で構成さ
れる。このような地図αのユニット化により、読み出し
制御部１０１４は、必要な部分の地図を容易に第１の記
憶装置１０１３から読み出すことができる。さらに、こ
のユニット化により、センタ局１０１は、無線伝送路１
０３が輻輳しない最適量のデータを容易に当該無線伝送
路１０３に送出することができる。さらに、センタ局１
０１が複数のユニットレコードＵＲを送信した場合であ
っても、通信エラーにより、端末装置１０２は、いずれ
かのユニットレコードＵＲを受信できない場合がある。
このような場合、端末装置１０２は、受信できたユニッ
トレコードＵＲを用いて地図ファイルＣＦを作成する。
端末装置１０２は、作成された地図ファイルＣＦに基づ
いて各種処理を行える。つまり、センタ局１０１から送
信されたユニットレコードＵＲの一部が抜けても、その
抜けによる影響は、端末装置１０２が受信した他のユニ
ットレコードには及ばない。かかる効果も、地図のユニ
ット化により生まれる。

【０２２８】また、ユニットレコードＵＲ内において、
地図の基本的なデータ（概略データ）と、当該地図の詳
細なデータとは、互いに独立した複数のテーブルに記述
される。これによって、各テーブルは、たとえ、１ユニ
ットレコードＵＲ内に格納されていても、独立的に使用
されることが可能となる。つまり、例えば、センタ局１
０１は、端末装置１０２に地図を提供する際に、基本デ
ータ（概略データ）を単独で送信したり、詳細データを
単独で送信したり、双方を組み合わせて送信したりする
ことが可能となる。これによって、センタ局１０１は、
端末装置１０２の状況や用途に適した地図を提供するこ
とが可能になる。

【０２２９】例えば、端末装置１０２側が、詳細な地図
よりも、広範囲の地図を速く受信したい場合には、セン
タ局１０１は、基本データ（概略データ）だけを優先的
に送信することができる。さらに、端末装置１０２が基
本データ（概略データ）を完全に受信した後に、センタ
局２が詳細データを送信することもできる。これによっ
て、端末装置１０２は、基本データ（概略データ）と詳
細データとを混在させて使用することも可能になる。

【０２３０】なお、前述したように、送信部１０１６お
よび受信部１０２２として、前述したように、移動体通
信装置を用いることも可能である。この場合、センタ局
１０１と端末装置１０２との双方向通信を容易に実現で
きるので、端末装置１０２は、提供を希望する地図の種
別（概略データか詳細データかを示す情報）を、センタ
局１０１に対してリアルタイムに要求することができ
る。また、送信部１０１６および受信部１０２２とし
て、地上波ディジタル放送等の放送装置および、この放
送を受信する装置を用いることも可能である。この場
合、センタ局１０１は、互いに異なるチャンネルを用い
て、基本データ（概略データ）と詳細データとに異なる
チャンネルを割り当てることにより、基本データ（概略
データ）と詳細データとの受信時間、および受信可能な
地図の範囲を調節することができる。

【０２３１】なお、以上の実施形態では、第２の記憶装
置１０２６側の地図ファイルＣＦのファイルヘッダＦＨ
は、第１の記憶装置１０１３側の地図ファイルＣＦ内の
それをそのまま用いられていた。つまり、双方地図ファ
イルＣＦは、互いに同範囲をカバーする。しかしなが
ら、センタ局１０１と端末装置１０２との処理能力は違
う場合が多い。例えば、第２の記憶装置１０２６の記憶
容量は、第１の記憶装置１０１３のそれよりも小さい場
合が多い。したがって、端末装置１０２は、地図ファイ
ルＣＦが表す地図の範囲よりも、狭い範囲をカバーする
地図ファイルＣＦを生成してもよい。つまり、端末装置
１０２は、独自の範囲をカバーする地図ファイルＣＦを
生成しても良い。

【０２３２】なお、第２の実施形態は、端末装置１０２
の一例としてカーナビゲーションシステムを想定して説
明した。しかし、パーソナルコンピュータ内に地図ファ
イルＣＦのデータベースを作成して、当該パーソナルコ
ンピュータが地図を表示したり、経路探索を行ったりす
るような用途にも、本実施形態は適用することができ
る。つまり、本発明の技術分野は、移動可能な端末装置
に限らず、据え置き型の端末装置にも適用することがで
きる。また、据え置き型の端末装置に対しては、通信網
１０３は無線伝送路である必要性はなく、有線であって
もよい。

【図面の簡単な説明】

【図１】本発明の第１の実施形態に係る地図提供システ
ムの構成を示すブロック図である。

【図２】図１に示す第１の地図ファイル１１１および第
２の地図ファイル２５により表現される地図の階層構造
を説明するための図である。

【図３】図２に示す最上位階層（レベル「３」）のユニ
ットＵ₃ を説明するための図である。

【図４】レベル「３」からレベル「０」までのそれぞれ
の階層間における親子関係を説明するための図である。

【図５】第１の地図ファイル１１１および第２の地図フ
ァイル２５を管理するためのツリー構造を示す図であ
る。

【図６】あるレベルに属する１つのユニットＵのデータ
構造を示す図である。

【図７】地図ファイルＣＦのデータ構造を示す図であ
る。

【図８】背景データにより表現される地図の模式図であ
る。

【図９】描画オブジェクトＢＯ１およびＢＯ２を用い
て、描画オブジェクトの概念を説明するための図であ
る。

【図１０】背景データテーブルの詳細なデータ構造を示
す図である。

【図１１】８個の要素点Ｐ０〜Ｐ７で構成される図形デ
ータを示す図である。

【図１２】図１１のＰ０〜Ｐ７の各絶対座標をオブジェ
クトレコードＯＲに記述した時のデータ構造を示す図で
ある。

【図１３】図１１と同じ図形データの各要素点Ｐ０〜Ｐ
７を相対座標で表現した時の図である。

【図１４】図１３の要素点Ｐ０〜Ｐ７の各相対座標をオ
ブジェクトレコードＯＲに記述した時のデータ構造を示
す図である。

【図１５】要素点Ｐ０、Ｐ１およびＰｎで構成されるオ
ブジェクトＯＢＪを示す図である。

【図１６】図１５の要素点Ｐ１およびＰｎを結ぶ直線上
に補われる要素点Ｐ２およびＰ３を示す図である。

【図１７】図１６の要素点Ｐ０，Ｐ１，Ｐ２，Ｐ３およ
びＰｎの各相対座標情報をオブジェクトレコードＯＲに
記述した時のデータ構造を示す図である。

【図１８】図１５の要素点Ｐ０およびＰｎを絶対座標で
表現し、要素点Ｐ１を相対座標で表した時のオブジェク
トレコードＯＲのデータ構造を示す図である。

【図１９】描画オブジェクトＤＯ３を用いて、オブジェ
クトの境界に相対座標が適用されない場合を説明するた
めの図である。

【図２０】そのオブジェクトの境界に相対座標が適用さ
れない描画オブジェクトＤＯ３の座標列のデータ構造を
示す図である。

【図２１】描画オブジェクトＤＯ３を用いて、オブジェ
クトの境界に適用される相対座標を説明するための図で
ある。

【図２２】そのオブジェクトの境界に相対座標が適用さ
れた描画オブジェクトＤＯ３の座標列のデータ構造を示
す図である。

【図２３】基本文字記号テーブルおよび詳細文字記号テ
ーブルとの関係を説明するための図である。

【図２４】文字記号テーブルの詳細なデータ構造を示す
図である。

【図２５】第１の道路ネットワークデータおよび第２の
道路ネットワークデータの関係を説明するための図であ
る。

【図２６】ノードおよびリンクの概念を説明するための
図である。

【図２７】第１のノードテーブルの詳細なデータ構造を
示す図である。

【図２８】図２６のノードＮ０〜Ｎ１０に関して作成さ
れたノードレコードＮＲ１〜ＮＲ１１の並び方を示す図
である。

【図２９】ノードの経度方向および緯度方向の座標の表
現方法の一つである正規化座標を説明するための図であ
る。

【図３０】第１のリンクテーブルの詳細なデータ構造を
示す図である。

【図３１】各リンクレコードＬＲに記録されるリンク接
続情報を説明するための図である。

【図３２】ノード接続情報およびリンク接続情報によ
り、道路網の接続をたどる時の処理を説明するための図
である。

【図３３】端末装置１における経路探索処理の概念を示
す図である。

【図３４】端末装置１で実行される双方向階層別探索の
処理手順を示すフローチャートである。

【図３５】図３５の地図ファイルＣＦの読み込み処理
（ステップＳ１０３）の詳細な処理手順を示すフローチ
ャートである。

【図３６】隣接ユニットＮＵを決定するための新しい代
表点の位置を説明するための図である。

【図３７】互いに隣接し合う４個のユニットＵ１〜Ｕ４
を並べた際に構成される道路網を示す図である。

【図３８】２個のユニットＵの境界をまたいで道路網の
接続をたどる時のデータ処理部１３の処理手順を示すフ
ローチャートである。

【図３９】隣接ノードのノードレコードＮＲが記録され
る順番を示す図である。

【図４０】下位階層および上位階層の地図ファイルＣＦ
のノードＮ同士の対応づけに関する問題点を説明するた
めの図である。

【図４１】下位階層および上位階層の地図ファイルＣＦ
のノードＮ同士の対応関係を説明するための図である。

【図４２】正規化座標およびノードレコードＮＲの記録
順序から、子ユニットＣＵのノードＮｄと対応する座標
を有する親ユニットＰＵ内のノードを探し出す方法を説
明するための図である。

【図４３】地図ファイルＣＦの送信要求時における端末
装置１の処理を説明するための図である。

【図４４】センタ局２が要求ＲＥＱの受信後に実行する
処理手順を示すフローチャートである。

【図４５】地図ファイルＣＦからパケットＰが組み立て
られるまでの過程における、各データの構造を示す図で
ある。

【図４６】ステップＳ５０４の詳細な処理手順を示すフ
ローチャートである。

【図４７】マスタデータＭＤの詳細な内部データ構造を
示す図である。

【図４８】端末装置１における地図ファイルＣＦの受信
処理の手順を示すフローチャートである。

【図４９】図４８のステップＳ７０３の詳細な処理手順
を示すフローチャートである。

【図５０】パケットＰ１１，Ｐ１２，…，Ｐ１ｊ，…Ｐ
ｉｊから地図ファイルＣＦが作成されるまでの過程にお
ける各データの構造を示す図である。

【図５１】図４８のステップＳ７０４の詳細な処理の手
順を示すフローチャートである。

【図５２】本発明の第２の実施形態に係る地図提供シス
テムの構成を示すブロック図である。

【図５３】図５２に示された第１の記憶装置１０１３に
格納された各地図ファイルＣＦの構造を示す図である。

【図５４】図５３（ｂ）に示された各ユニットレコード
ＵＲの詳細な構造を示す図である。

【図５５】図５４に示された背景データＢＤを説明する
ための図である。

【図５６】図５４に示された文字記号データＣＤを説明
するための図である。

【図５７】図５４に示された道路ネットワークデータＮ
Ｄを説明するための図である。

【図５８】図５４に示された基本背景テーブルデータＢ
ＢＤ、基本文字記号データテーブルＢＣＤおよび主要幹
線ネットワークデータテーブルＭＮＤを重畳したときに
表示される地図、ならびに、図５４に示された詳細背景
テーブルデータＤＢＤ、詳細文字記号データテーブルＤ
ＣＤおよび細街路ネットワークデータテーブルＳＮＤを
重畳したときに表示される地図を示している。

【図５９】図５２に示されるセンタ局１０１において実
行される処理の手順を示すフローチャートである。

【図６０】図５２に示されるセンタ局１０１が地図ファ
イルＣＦからパケットＰを生成するまでの過程におけ
る、各データの構造を示している。

【図６１】図５９に示されるステップＳ１００３が含
む、詳細な処理手順を示すフローチャートである。

【図６２】図６０（ｂ）に示されるマスタデータＭＤの
詳細な構造を示している。

【図６３】図５２に示される端末装置１０２において実
行される処理の手順を示すフローチャートである。

【図６４】図６３に示されるステップＳ１２０３の詳細
な処理手順を示すフローチャートである。

【図６５】図５２に示される端末装置１０２がパケット
Ｐから地図ファイルＣＦを生成するまでの過程におけ
る、各データの構造を示している。

【図６６】図６３に示されるステップＳ１２０４が含
む、詳細な処理手順を示すフローチャートである。

【図６７】図５２に示される地図ファイルＣＦの構造を
示している。

【図６８】図６６に示されるステップＳ１４０６におい
て、ファイル管理部１０２５が、第１および第２のユニ
ットＩＤが一致しない場合に実行する処理を示してい
る。

【図６９】図５４に示される基本背景データテーブルＢ
ＢＤ、基本文字記号データテーブルＢＣＤ、主要幹線ネ
ットワークデータテーブルＭＮＤが、ステップＳ１２０
４の時点で端末装置１０２に既に提供されているような
場合における、地図ファイルＣＦの構造を示している。

【図７０】図６６に示されるステップＳ１４０６におい
て、ファイル管理部１０２５が、第１および第２のユニ
ットＩＤが一致する場合に実行する処理を示している。

【図７１】ある範囲を表す地図βが、６４個の矩形のユ
ニットに区画化された場合を示している。

【図７２】端末装置の記憶装置内において、空き領域を
有する４個のクラスタ９１〜９４が発生したときの様子
を示している。

【図７３】ある範囲を表す地図βが、１６個の矩形のユ
ニットに区画化された場合を示している。

【図７４】端末装置の記憶装置内において、空き領域を
有する１個のクラスタ９６が発生した場合を示してお
り、さらに、かかる場合には、無線伝送路の利用効率が
悪くなることを説明するための図である。

【符号の説明】

１…端末装置 １１…入力装置 １２…位置検出装置 １３…データ処理部 １４…要求生成部 １５…第１の送受信部 １６…アンテナ １７…パケット分解部 １８…読み出し／書き込み制御部 １９…第１の記憶装置 １１０…出力装置 １１１…第１の地図ファイル ２…センタ局 ２１…第２の送受信部 ２２…受信要求解析部 ２３…読み出し制御部 ２４…第２の記憶装置 ２５…パケット組み立て部 ３…通信網 １０１…センタ局 １０１１…地図サーバ １０１２…アンテナ １０１３…第１の記憶装置 １０１４…読み出し制御部 １０１５…パケット組み立て部 １０１６…送信部 １０２…端末装置 １０２１…アンテナ １０２２…受信部 １０２３…データ処理部 １０２４…パケット分解部 １０２５…ファイル管理部 １０２６…第２の記憶装置

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 15/62 ３３５ ９Ａ００１ (72)発明者 上山 芳樹 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 (72)発明者 鈴木 祥弘 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 (72)発明者 福田 久哉 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 Ｆターム(参考） 2C032 HB03 HB05 HB15 HB31 HC13 2F029 AA02 AB01 AB07 AB09 AB13 AC02 AC04 AC08 AC14 AC18 5B050 BA17 GA08 5B075 ND06 ND36 NR02 PQ02 PQ04 PQ05 UU13 5H180 AA01 BB05 BB13 FF04 FF05 FF13 FF22 FF25 FF27 FF32 9A001 CC04 CC05 DD09 FF03 JJ01 JJ11 JJ77 JJ78

Claims (46)

【特許請求の範囲】
1. 【請求項１】 地図を複数の領域に分割して得られる各
   ユニットがデジタルデータ化された地図ファイルが記憶
   装置に格納されており、当該記憶装置から地図ファイル
   を読み出すための端末装置であって、 各前記地図ファイルは、それぞれのユニット内に含まれ
   る道路網をノードとリンクとで表すべく、当該ノード毎
   に作成されるノードレコードと、当該リンク毎に作成さ
   れるリンクレコードとを含んでおり、 各前記ノードレコードには、前記道路網上の交差点を表
   す非隣接ノードに関連する情報、または、ユニットとそ
   れに隣接するユニットとの道路の接続関係を規定する隣
   接ノードに関連する情報が記録されており、 前記隣接ノードに関連する情報とは、当該隣接ノードの
   座標情報であり、 ユーザの操作に応答して、地図の範囲を指定する情報を
   生成する入力装置と、 前記入力装置により生成された情報に基づいて、必要な
   地図ファイルの記録領域を特定するデータ処理部と、 前記データ処理部により特定された記録領域に基づい
   て、前記記憶装置から地図ファイルを読み出す読み出し
   制御部とを備え、 前記データ処理部は、 前記読み出し制御部により読み出された地図ファイルに
   記録されたノードレコードおよびリンクレコードを用い
   て、所定の処理を実行し、 一方のユニットおよび他方の隣接ユニットの隣接ノード
   が有する座標情報に基づいて、当該一方のユニット内の
   道路から、当該他方の隣接ユニット内の道路への接続を
   たどる、端末装置。
2. 【請求項２】 前記リンクレコードには、前記リンクが
   表す道路の属性を示す属性情報が記録されており、 前記データ処理部は、さらに、一方のユニットおよび他
   方の隣接ユニットの隣接ノードに接続されたリンクの属
   性情報に基づいて、当該一方のユニット内の道路から、
   当該他方の隣接ユニット内の道路への接続をたどる、請
   求項１に記載の端末装置。
3. 【請求項３】 各前記地図ファイルにおいて、前記隣接
   ノードに関連する情報を含む各ノードレコードは連続的
   に記録されている、請求項１に記載の端末装置。
4. 【請求項４】 前記データ処理部は、他方の隣接ユニッ
   トを表す地図ファイルにおいて、隣接ノードに関連する
   情報を含む各ノードレコードのみを検索して、当該一方
   のユニット内の道路から、当該他方の隣接ユニット内の
   道路への接続をたどる、請求項３に記載の端末装置。
5. 【請求項５】 各前記地図ファイルにおいて、前記隣接
   ノードに関連する情報を含む各ノードレコードは、連続
   的にかつ当該隣接ノードの座標が昇順または降順になる
   ように記録されている、請求項１に記載の端末装置。
6. 【請求項６】 前記データ処理部は、他方の隣接ユニッ
   トを表す地図ファイルにおいて、隣接ノードに関連する
   情報を含む各ノードレコードのみを検索して、当該一方
   のユニット内の道路から、当該他方の隣接ユニット内の
   道路への接続をたどる、請求項５に記載の端末装置。
7. 【請求項７】 各前記地図ファイルにおいて、前記隣接
   ノードに関連する情報を含む各ノードレコードは、連続
   的にかつ当該各隣接ノードが前記ユニットの境界上を一
   周するような順序で記録されている、請求項１に記載の
   端末装置。
8. 【請求項８】 前記データ処理部は、他方の隣接ユニッ
   トを表す地図ファイルにおいて、一方のユニットとの境
   界上に位置する隣接ノードに関連する情報を含む各ノー
   ドレコードのみを、当該各ノードレコードの記録順序と
   逆方向に検索して、当該一方のユニット内の道路から、
   当該他方の隣接ユニット内の道路への接続をたどる、請
   求項７に記載の端末装置。
9. 【請求項９】 各前記ユニットは、地図を多角形状の領
   域に分割されており、 各前記地図ファイルにおいて、前記ユニットの各辺に位
   置する隣接ノードに関連する情報を含む各ノードレコー
   ドは連続的に記録されている、請求項３に記載の端末装
   置。
10. 【請求項１０】 前記データ処理部は、他方の隣接ユニ
    ットを表す地図ファイルにおいて、当該隣接ユニットの
    所定の一辺上に位置する隣接ノードに関連する情報を含
    む各ノードレコードのみを検索して、前記一方のユニッ
    ト内の道路から、当該他方の隣接ユニット内の道路への
    接続をたどり、 前記隣接ユニットの所定の一辺とは、前記一方のユニッ
    ト内の隣接ノードが属する辺と接する、請求項９に記載
    の端末装置。
11. 【請求項１１】 前記ユニットの各辺に位置する隣接ノ
    ードに関連する情報を含む各ノードレコードは、当該各
    隣接ノードの座標情報が昇順または降順に記録されてい
    る、請求項９に記載の端末装置。
12. 【請求項１２】 前記データ処理部は、他方の隣接ユニ
    ットを表す地図ファイルにおいて、当該隣接ユニットの
    所定の一辺上に位置する隣接ノードに関連する情報を含
    む各ノードレコードのみを、当該各ノードレコードの記
    録順序に従って検索して、前記一方のユニット内の道路
    から、当該他方の隣接ユニット内の道路への接続をたど
    り、 前記隣接ユニットの所定の一辺は、前記一方のユニット
    内の隣接ノードが属する辺と接する、請求項１１に記載
    の端末装置。
13. 【請求項１３】 地図を複数の領域に分割して得られる
    各ユニットがデジタルデータ化された地図ファイルが記
    憶装置に格納されており、当該記憶装置から地図ファイ
    ルを読み出すための端末装置であって、 各前記地図ファイルは、自身が表す地図の範囲を一意に
    対応するファイル名が付けられて前記記憶装置に格納さ
    れており、 ユーザの操作に応答して、地図の範囲を指定する情報を
    生成する入力装置と、前記入力装置により生成された情
    報に基づいて、必要な地図ファイルの記録領域を特定す
    るデータ処理部と、 前記データ処理部により特定された記録領域に基づい
    て、前記記憶装置から地図ファイルを読み出す読み出し
    制御部とを備える、端末装置。
14. 【請求項１４】 各前記地図ファイルは、それぞれのユ
    ニット内に含まれる道路網をノードとリンクとで表すべ
    く、当該ノード毎に作成されるノードレコードと、当該
    リンク毎に作成されるリンクレコードとを含んでおり、 前記データ処理部は、 前記読み出し制御部により今回読み出された地図ファイ
    ルに記録されたノードレコードおよびリンクレコードを
    用いて経路を探索する処理を実行し、 今回読み出された地図ファイルが表す範囲において、経
    路の探索が終了すると、さらなる経路の探索に必要な地
    図の範囲を算出して、算出した地図の範囲に基づいて、
    次に読み出すべき地図ファイルの記録領域を特定する、
    請求項１３に記載の端末装置。
15. 【請求項１５】 地図を複数の領域に分割して得られる
    各ユニットがデジタルデータ化された地図ファイルが記
    憶装置に格納されており、当該記憶装置から地図ファイ
    ルを読み出すための端末装置であって、 各前記ユニット内に含まれる各背景は、一筆書き可能な
    オブジェクト単位で分割され、当該複数のオブジェクト
    は互いに同一の属性を有するもの毎にグループ化され、 前記地図ファイルは、各前記グループ毎にオブジェクト
    に関連する情報が記録される背景レコードを含んでお
    り、 ユーザの操作に応答して、地図の範囲を指定する情報を
    生成する入力装置と、 前記入力装置により生成された情報に基づいて、必要な
    地図ファイルの記録領域を特定するデータ処理部と、 前記データ処理部により特定された記録領域に基づい
    て、前記記憶装置から地図ファイルを読み出す読み出し
    制御部と、 出力装置とを備え、 前記データ処理部は、前記読み出し制御部により読み出
    された地図ファイルに含まれる背景レコードに基づい
    て、前記出力装置上に背景を表示させる、端末装置。
16. 【請求項１６】 各前記オブジェクトは、形状を示すた
    めの要素点からなっており、 各前記背景レコードには、各前記オブジェクトの要素点
    の座標値が一筆書きされる順番に記録されており、 前記要素点の座標値は、前記ユニットにおける原点を基
    準とした絶対座標値、および他の要素点の座標値を基準
    とした相対座標値のいずれかで表現される、請求項１５
    に記載の端末装置。
17. 【請求項１７】 各前記オブジェクトにおいてペンダウ
    ン位置となる要素点は、所定の条件を満足する場合には
    相対座標値で表現される、請求項１５に記載の端末装
    置。
18. 【請求項１８】 前記所定の条件は、直前のペンアップ
    位置からペンダウン位置までの距離が所定値以下であ
    る、請求項１７に記載の端末装置。
19. 【請求項１９】 前記所定の条件は、ペンダウン位置と
    なる要素点の相対座標値が予め定められたビット数以下
    で表現されることである、請求項１７に記載の端末装
    置。
20. 【請求項２０】 各前記オブジェクトの要素点は、所定
    の条件を満足する場合には、直接座標値で表現される、
    請求項１５に記載の端末装置。
21. 【請求項２１】 前記所定の条件は、要素点からその直
    前の要素点までの距離が所定値以上である、請求項１９
    に記載の端末装置。
22. 【請求項２２】 前記所定の条件は、要素点の座標値を
    相対座標値で表現した場合に予め定められたビット数を
    超えることである、請求項１９に記載の端末装置。
23. 【請求項２３】 コンピュータ装置による処理のために
    予め定められたデータ構造を有しており、地図を複数の
    領域に分割して得られる各ユニットがデジタルデータ化
    された地図ファイルが記録された記録媒体であって、 各前記地図ファイルのユニット内に含まれる道路網を構
    成するノード毎に作成されるノードレコードと、 各前記地図ファイルのユニット内に含まれる道路網を構
    成するリンク毎に作成されるリンクレコードとを含み、 各前記ノードレコードには、前記道路網上の交差点を表
    す非隣接ノードに関連する情報、または、ユニットとそ
    れに隣接するユニットとの道路の接続関係を規定する隣
    接ノードの座標を示す座標情報が記録される、 前記コンピュータ装置が、 ユーザの操作に応答して、地図の範囲を指定する範囲情
    報を生成し、 生成された範囲情報に基づいて、必要な地図ファイルの
    記録領域を特定し、 特定された記録領域に基づいて地図ファイルを読み出
    し、さらに、 読み出された地図ファイルに記録されたノードレコード
    およびリンクレコードを用いて経路を探索する処理を実
    行中に、一方のユニットおよび他方の隣接ユニットの隣
    接ノードの座標情報に基づいて、当該一方のユニット内
    の道路から、当該他方の隣接ユニット内の道路への接続
    をたどる、という処理を実現可能にする地図ファイルが
    記録された記録媒体。
24. 【請求項２４】 前記リンクレコードには、前記リンク
    が表す道路の属性を示す属性情報が記録されており、 前記コンピュータ装置は、さらに、 前記経路を探索する処理の実行中に、一方のユニットお
    よび他方の隣接ユニットの隣接ノードに接続されたリン
    クの属性情報に基づいて、当該一方のユニット内の道路
    から、当該他方の隣接ユニット内の道路への接続をたど
    る、請求項２３に記載の地図ファイルが記録された記録
    媒体。
25. 【請求項２５】 前記隣接ノードに関連する情報を含む
    各ノードレコードは連続的に記録されている、請求項２
    ３に記載の地図ファイルが記録された記録媒体。
26. 【請求項２６】 前記隣接ノードに関連する情報を含む
    各ノードレコードは、連続的にかつ当該隣接ノードの座
    標が昇順または降順になるように記録されている、請求
    項２３に記載の地図ファイルが記録された記録媒体。
27. 【請求項２７】 前記隣接ノードに関連する情報を含む
    各ノードレコードは、連続的にかつ当該各隣接ノードが
    前記ユニットの境界上を一周するような順番で記録され
    ている、請求項２３に記載の地図ファイルが記録された
    記録媒体。
28. 【請求項２８】 コンピュータ装置による処理のために
    予め定められたデータが記録された記録媒体であって、 構造を有するしており、地図を複数の領域に分割して得
    られる各ユニットがデジタルデータ化された地図ファイ
    ルが記録された記録媒体であって、 地図を複数の領域に分割して得られる各ユニットがデジ
    タルデータ化された地図ファイルと、 各前記地図ファイルの名前をツリー構造で表現して、当
    該各地図ファイルの記録領域を管理する管理情報とを含
    み、 前記コンピュータ装置が、 外部から地図の範囲を指定する範囲情報が入力される
    と、入力された範囲情報に基づいて、必要な地図ファイ
    ルの名前を特定し、さらに、 前記管理情報を参照して、特定された地図ファイルの名
    前に一意に対応する記録領域から地図ファイルを読み出
    す、という処理を実現可能にする地図ファイルが記録さ
    れた記録媒体。
29. 【請求項２９】 コンピュータ装置による処理のために
    予め定められたデータ構造を有しており、地図を複数の
    領域に分割して得られる各ユニットがデジタルデータ化
    された地図ファイルが記録された記録媒体であって、 各前記ユニット内に含まれる各背景は、一筆書き可能な
    オブジェクト単位で分割されており、 各背景の属性を示す情報と、 各オブジェクトを描画するために必要な情報が記録され
    るオブジェクトレコードとを含み、 前記背景の属性を示す情報と、当該属性を有するオブジ
    ェクトのオブジェクトレコードとが連続して記録され、
    これによって、複数のオブジェクトは互いに同一の属性
    を有するもの毎にグループ化され、 前記コンピュータ装置が、各前記地図ファイルに含まれ
    る各背景の属性情報とオブジェクトレコードとに基づい
    て地図を描画する、という処理を実現可能にする、地図
    ファイルが記録された記録媒体。
30. 【請求項３０】 各前記オブジェクトは、自身の形状を
    示すための要素点からなっており、 各前記オブジェクトレコードには、各前記オブジェクト
    の要素点の座標値が一筆書きされる順番に記録されてお
    り、 前記要素点の座標値は、前記ユニットにおける原点を基
    準とした絶対座標値、および他の要素点の座標値を基準
    とした相対座標値のいずれかで表現される、請求項２９
    に記載の地図ファイルが記録された記録媒体。
31. 【請求項３１】 各前記オブジェクトにおいてペンダウ
    ン位置となる要素点は、所定の条件を満足する場合には
    相対座標値で表現される、請求項２９に記載の地図ファ
    イルが記録された記録媒体。
32. 【請求項３２】 各前記オブジェクトの要素点は、所定
    の条件を満足する場合には、直接座標値で表現される、
    請求項２９に記載の端末装置。
33. 【請求項３３】 互いに縮尺が異なる複数の地図をそれ
    ぞれ、複数の領域に分割して得られる各ユニットがデジ
    タルデータ化された地図ファイルが記憶装置に格納され
    ており、当該記憶装置から地図ファイルを読み出すため
    の端末装置であって、 複数の前記地図ファイルは、前記縮尺に応じて階層的な
    構造を有しており、それぞれのユニット内に含まれる道
    路網をノードとリンクとで表すべく、当該ノード毎に作
    成されかつ当該ノードの座標情報が記録されるノードレ
    コードと、当該リンク毎に作成されるリンクレコードと
    を少なくとも含んでおり、 各前記地図ファイルには、ノードの座標情報が昇順また
    は降順になるようにノードレコードが記録されており、 地図の範囲を指定する情報を生成する入力装置と、 前記入力装置により生成された情報に基づいて、必要な
    地図ファイルの記録領域を特定するデータ処理部と、 前記データ処理部により特定された記録領域に基づい
    て、前記記憶装置から地図ファイルを読み出す読み出し
    制御部とを備え、 前記データ処理部は、 前記読み出し制御部により読み出された地図ファイルに
    記録された座標情報に基づいて、下位階層のユニットに
    含まれるノードに対応する上位階層のユニットのノード
    を検索する、端末装置。
34. 【請求項３４】 データ処理部はさらに、各前記ノード
    レコードの記録順序に基づいて、下位階層のユニットに
    含まれるノードに対応する上位階層のユニットのノード
    を検索する、請求項３３に記載の端末装置。
35. 【請求項３５】 センタ局が端末装置に伝送路を通じて
    地図ファイルを提供するシステムであって、 前記センタ局は、 予め定められた範囲の地図を表す地図ファイルを記憶す
    る第１の記憶装置と、 前記第１の記憶装置から、地図ファイルの一部またはす
    べてを、地図データとして読み出す読み出し制御部と、 前記読み出し制御部により読み出された地図データを用
    いて、前記伝送路にとって適切な形式のパケットを組み
    立てるパケット組み立て部と、 前記パケット組み立て部により組み立てられたパケット
    を、前記伝送路を通じて前記端末装置に送信する送信部
    とを備え、 前記端末装置は、 前記伝送路を通じて、前記送信部により送信されたパケ
    ットを受信する受信部と、 前記受信部により受信されたパケットを分解して、地図
    データを復元する処理を実行するデータ処理部と、 その内部の記憶媒体に、地図ファイルを記憶する第２の
    記憶装置とを備え、 前記データ処理部は、 今回復元した地図データに関連する地図ファイルが前記
    第２の記憶装置に既に格納されている場合には、当該第
    ２の記憶装置から当該地図ファイルを読み出し、さら
    に、 復元した地図データを、読み出された第２の地図ファイ
    ルに追加して、前記第２の記憶装置に格納する処理を実
    行する、地図提供システム。
36. 【請求項３６】 前記データ処理部は、必要に応じて、
    地図ファイルを複数個作成する、請求項３５に記載の地
    図提供システム。
37. 【請求項３７】 前記地図ファイルは、前記予め定めら
    れた範囲の地図が複数の領域に区画された複数のユニッ
    トと、各前記ユニットを管理するための管理情報とから
    構成されており、 前記センタ局において、 前記読み出し制御部は、前記第１の記憶装置に格納され
    た地図ファイルから、ユニット単位の読み出しを実行
    し、 前記パケット組み立て部は、前記読み出し制御部が読み
    出したユニットと、地図ファイルを特定するファイルＩ
    Ｄ、当該ユニットを特定するユニットＩＤおよび当該ユ
    ニットのデータサイズとを用いて、パケットを組み立て
    る、請求項３５に記載の地図提供システム。
38. 【請求項３８】 前記データ処理部はさらに、 前記受信部により受信されたパケットから、ファイルＩ
    Ｄ、ユニットＩＤおよびデータサイズを取り出し、 取り出されたファイルＩＤ、ユニットＩＤおよびデータ
    サイズを用いて、前記受信部により受信されたパケット
    を分解して地図データを復元する、請求項３７に記載の
    地図提供システム。
39. 【請求項３９】 前記地図ファイルはさらに、前記予め
    定められた範囲を概略的に表す基本データと、当該範囲
    を詳細に表す詳細データとを含み、 前記基本データと前記詳細データとは互いに分離可能な
    データ構造を有する、請求項３５に記載の地図提供シス
    テム。
40. 【請求項４０】 前記基本データはさらに、前記地図の
    背景を表す基本背景データと、当該地図に表示すべき文
    字および記号を概略的に表す基本文字記号データと、当
    該地図内に存在する主要幹線の道路ネットワークを表す
    主要幹線ネットワークデータとを含み、 前記詳細データはさらに、前記地図の詳細な背景を表す
    詳細背景データと、当該地図に表示すべき文字および記
    号を詳細に表す詳細文字記号データと、当該地図内に存
    在する細街路の道路ネットワークを表す細街路ネットワ
    ークデータとを含み、 前記詳細背景データ、前記詳細文字記号データおよび細
    街路ネットワークデータは、前記基本背景データ、詳細
    文字記号データおよび細街路ネットワークデータの差分
    データとして構成されており、前記基本データと前記詳
    細データとが組み合わされることにより、相対的に詳細
    な地図が表される、請求項３９に記載の地図提供システ
    ム。
41. 【請求項４１】 前記読み出し制御部はさらに、前記第
    １の記憶装置に格納された地図ファイルに含まれる基本
    データのみを、地図データとして読み出す、請求項３９
    に記載の地図提供システム。
42. 【請求項４２】 前記読み出し制御部はさらに、前記記
    憶装置に格納された地図ファイルに含まれる詳細データ
    のみを、地図データとして読み出す、請求項４１に記載
    の地図提供システム。
43. 【請求項４３】 前記読み出し制御部はさらに、前記第
    １の記憶装置に格納された地図ファイルに含まれる基本
    データおよび詳細データを、地図データとして読み出
    す、請求項３９に記載の地図提供システム。
44. 【請求項４４】 前記データ処理部はさらに、前記受信
    部により受信されたパケットを分解して、基本データを
    復元する、請求項４１に記載の地図提供システム。
45. 【請求項４５】 前記センタ局の前記読み出し制御部は
    さらに、前記第１の記憶装置に格納された地図ファイル
    に含まれる詳細データのみを、地図データとして読み出
    し、 前記移動局の前記データ処理部はさらに、前記受信部に
    より受信されたパケットを組み立てて、詳細データを復
    元する、請求項４４に記載の地図提供システム。
46. 【請求項４６】 前記データ処理部はさらに、前記受信
    部により受信されたパケットを分解して、基本データお
    よび詳細データを復元する、請求項４３に記載の地図提
    供システム。