JP2003150047A - 端末装置 - Google Patents

端末装置

Info

Publication number
JP2003150047A
JP2003150047A JP2002218846A JP2002218846A JP2003150047A JP 2003150047 A JP2003150047 A JP 2003150047A JP 2002218846 A JP2002218846 A JP 2002218846A JP 2002218846 A JP2002218846 A JP 2002218846A JP 2003150047 A JP2003150047 A JP 2003150047A
Authority
JP
Japan
Prior art keywords
unit
map
data
file
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2002218846A
Other languages
English (en)
Inventor
Nobuyuki Nakano
信之 中野
Yasuhiro Ihara
康博 井原
Yoshiki Kamiyama
芳樹 上山
Sachihiro Suzuki
祥弘 鈴木
Hisaya Fukuda
久哉 福田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Priority to JP2002218846A priority Critical patent/JP2003150047A/ja
Publication of JP2003150047A publication Critical patent/JP2003150047A/ja
Pending legal-status Critical Current

Links

Landscapes

  • Traffic Control Systems (AREA)
  • Instructional Devices (AREA)
  • Navigation (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

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

Claims (3)

    【特許請求の範囲】
  1. 【請求項１】 地図を複数の領域に分割して得られる各
    ユニットがデジタルデータ化された地図ファイルが記憶
    装置に格納されており、当該記憶装置から地図ファイル
    を読み出すための端末装置であって、 各前記地図ファイルは、自身が表す地図の範囲と一意に
    対応するファイル名が付けられており、 前記端末装置は、 ユーザの操作に応答して、地図の範囲を指定する情報を
    生成する入力装置と、 前記入力装置により生成された情報に基づいて、必要な
    地図ファイルのファイル名を特定するデータ処理部と、 前記データ処理部で特定されたファイル名に従って、前
    記記憶装置から地図ファイルを読み出す読み出し制御部
    とを備える、端末装置。
  2. 【請求項２】 各前記地図ファイルは、それぞれのユニ
    ット内に含まれる道路網をノードとリンクとで表すべ
    く、当該ノード毎に作成されるノードレコードと、当該
    リンク毎に作成されるリンクレコードとを含んでおり、 前記データ処理部は、 前記読み出し制御部により今回読み出された地図ファイ
    ルに記録されたノードレコードおよびリンクレコードを
    用いて経路を探索する処理を実行し、 今回読み出された地図ファイルが表す範囲において、経
    路の探索が終了すると、さらなる経路の探索に必要な地
    図の範囲を算出して、算出した地図の範囲に基づいて、
    次に読み出すべき地図ファイルの記録領域を特定する、
    請求項１に記載の端末装置。
  3. 【請求項３】 コンピュータ装置により読み出されるデ
    ータが記録された記録媒体であって、 地図を複数の領域に分割して得られる各ユニットがデジ
    タルデータ化された地図ファイルと、 各前記地図ファイルの名前をツリー構造で表現して、当
    該各地図ファイルの記録領域を管理する管理情報とを含
    む、地図ファイルが記録された記録媒体。
JP2002218846A 1998-11-24 2002-07-26 端末装置 Pending JP2003150047A (ja)

Priority Applications (1)

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

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP33241298 1998-11-24
JP10-332412 1999-06-11
JP16594099 1999-06-11
JP11-165940 1999-06-11
JP2002218846A JP2003150047A (ja) 1998-11-24 2002-07-26 端末装置

Related Parent Applications (1)

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

Publications (1)

Publication Number Publication Date
JP2003150047A true JP2003150047A (ja) 2003-05-21

Family

ID=27322598

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002218846A Pending JP2003150047A (ja) 1998-11-24 2002-07-26 端末装置

Country Status (1)

Country Link
JP (1) JP2003150047A (ja)

Similar Documents

Publication Publication Date Title
JP3332225B2 (ja) 地図提供システム
KR100443495B1 (ko) 디지털 지도파일의 데이터구조
JP4543637B2 (ja) 地図情報処理装置
JP4727245B2 (ja) 地図情報処理装置
US8396660B2 (en) Road map data structure, road map data storage medium, navigation device, and method of generating road map data
US7197500B1 (en) System and method for use and storage of geographic data on physical media
CA2444271A1 (en) A method and apparatus for transmitting position information
EP1783724A2 (en) Road area extracting apparatus for extracting a road area from a block map, deformed map automatic generation system for generating a deformed map from road area data obtained by the road area extracting apparatus, map information providing system, geographical information providing system and geographical information describing method
US20100287207A1 (en) Spatial indexing method and apparatus for navigation system for indexing and retrieval of XML map data
US6950100B2 (en) Map display device, a memory medium and a map display method
JP2008164732A (ja) 道路地図データ構造、道路地図データ記憶媒体、及びナビゲーション装置
JP2011158636A (ja) 地図データ作成方法及び地図データ
JPH10312452A (ja) 地理情報提供システムと地理情報記述方法
JP3649391B2 (ja) 端末装置
CN113177046B (zh) 路网拓扑图的生成方法、装置、设备及存储介质
JP2003157265A (ja) 端末装置
JP2003141121A (ja) 端末装置
JP2003150047A (ja) 端末装置
JP2010237256A (ja) 地図情報処理装置、及び地図情報記憶媒体
JP2002333828A (ja) 電子地図データ
KR101199428B1 (ko) 최단경로 탐색 휴대단말 및 방법
JP2005338032A (ja) 位置情報提供装置及び位置情報利用端末装置
JP2002267462A (ja) 地図情報端末装置および地図情報提供システム
JP2000283777A (ja) 車載用ナビゲーション装置
JP2004205994A (ja) 経路ネットワークデータ作成装置及びプログラム

Legal Events

Date Code Title Description
A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20040206