• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 全部申し立て 2項進歩性  G06F
管理番号 1132588
異議申立番号 異議2003-70899  
総通号数 76 
発行国 日本国特許庁(JP) 
公報種別 特許決定公報 
発行日 2001-02-27 
種別 異議の決定 
異議申立日 2003-04-07 
確定日 2006-01-10 
異議申立件数
訂正明細書 有 
事件の表示 特許第3332225号「地図提供システム」の請求項1ないし13に係る特許に対する特許異議の申立てについて、次のとおり決定する。 
結論 訂正を認める。 特許第3332225号の請求項1、2に係る特許を維持する。 
理由
第1 手続の経緯

特許第3332225号の請求項1〜13に係る発明についての出願(特願平11-331885号)は、平成11年11月22日の出願(優先権主張平成10年11月24日、平成11年6月11日)であって、平成14年7月26日にその特許の設定登録がなされ、その後、特許異議申立人小野浩一より特許異議の申立てがなされ、取消理由通知がなされ、その指定期間内である平成17年6月7日に訂正請求(後日取り下げ)がなされた後、再度取消理由通知がなされ、その指定期間内である平成17年12月2日に訂正請求がなされたものである。

第2 訂正の適否についての判断

1 訂正の内容

特許権者が求めている訂正の内容は、特許時の特許請求の範囲である
「【請求項1】 センタ局が端末装置に伝送路を通じて地図ファイルを提供するシステムであって、
前記センタ局は、
予め定められた範囲の地図を表す地図ファイルを記憶する第1の記憶装置と、
前記第1の記憶装置から、地図ファイルの一部またはすべてを、地図データとして読み出す読み出し制御部と、
前記読み出し制御部により読み出された地図データを用いて、前記伝送路にとって適切な形式のパケットを組み立てるパケット組み立て部と、
前記パケット組み立て部により組み立てられたパケットを、前記伝送路を通じて前記端末装置に送信する送信部とを備え、
前記端末装置は、
前記伝送路を通じて、前記送信部により送信されたパケットを受信する受信部と、
前記受信部により受信されたパケットを分解して、地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、地図ファイルを記憶する第2の記憶装置とを備え、前記データ処理部は、
今回復元した地図データに関連する地図ファイルが前記第2の記憶装置に既に格納されている場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する、地図提供システム。
【請求項2】 前記データ処理部は、必要に応じて、地図ファイルを複数個作成する、請求項1に記載の地図提供システム。
【請求項3】 前記地図ファイルは、前記予め定められた範囲の地図が複数の領域に区画された複数のユニットと、各前記ユニットを管理するための管理情報とから構成されており、
前記センタ局において、前記読み出し制御部は、前記第1の記憶装置に格納された地図ファイルから、ユニット単位の読み出しを実行し、
前記パケット組み立て部は、前記読み出し制御部が読み出したユニットと、地図ファイルを特定するファイルID、当該ユニットを特定するユニットIDおよび当該ユニットのデータサイズとを用いて、パケットを組み立てる、請求項1に記載の地図提供システム。
【請求項4】 前記データ処理部はさらに、
前記受信部により受信されたパケットから、ファイルID、ユニットIDおよびデータサイズを取り出し、
取り出されたファイルID、ユニットIDおよびデータサイズを用いて、前記受信部により受信されたパケットを分解して地図データを復元する、請求項3に記載の地図提供システム。
【請求項5】 前記地図ファイルはさらに、前記予め定められた範囲を概略的に表す基本データと、当該範囲を詳細に表す詳細データとを含み、
前記基本データと前記詳細データとは互いに分離可能なデータ構造を有する、請求項1に記載の地図提供システム。
【請求項6】 前記基本データはさらに、前記地図の背景を表す基本背景データと、当該地図に表示すべき文字および記号を概略的に表す基本文字記号データと、当該地図内に存在する主要幹線の道路ネットワークを表す主要幹線ネットワークデータとを含み、
前記詳細データはさらに、前記地図の詳細な背景を表す詳細背景データと、当該地図に表示すべき文字および記号を詳細に表す詳細文字記号データと、当該地図内に存在する細街路の道路ネットワークを表す細街路ネットワークデータとを含み、
前記詳細背景データ、前記詳細文字記号データおよび細街路ネットワークデータは、前記基本背景データ、基本文字記号データおよび主要幹線ネットワークデータの差分データとして構成されており、前記基本データと前記詳細データとが組み合わされることにより、相対的に詳細な地図が表される、請求項5に記載の地図提供システム。
【請求項7】 前記読み出し制御部はさらに、前記第1の記憶装置に格納された地図ファイルに含まれる基本データのみを、地図データとして読み出す、請求項5に記載の地図提供システム。
【請求項8】 前記読み出し制御部はさらに、前記第1の記憶装置に格納された地図ファイルに含まれる詳細データのみを、地図データとして読み出す、請求項7に記載の地図提供システム。
【請求項9】 前記読み出し制御部はさらに、前記第1の記憶装置に格納された地図ファイルに含まれる基本データおよび詳細データを、地図データとして読み出す、請求項5に記載の地図提供システム。
【請求項10】 前記データ処理部はさらに、前記受信部により受信されたパケットを分解して、基本データを復元する、請求項7に記載の地図提供システム。
【請求項11】 前記センタ局の前記読み出し制御部はさらに、前記第1の記憶装置に格納された地図ファイルに含まれる詳細データのみを、地図データとして読み出し、
前記端末装置の前記データ処理部はさらに、前記受信部により受信されたパケットを分解して、詳細データを復元する、請求項10に記載の地図提供システム。
【請求項12】 前記データ処理部はさらに、前記受信部により受信されたパケットを分解して、基本データおよび詳細データを復元する、請求項9に記載の地図提供システム。
【請求項13】 センタ局により送信された地図ファイルを伝送路を通じて受信する端末装置であって、
前記センタ局は、
予め定められた範囲の地図を表す地図ファイルを記憶する第1の記憶装置から、地図ファイルの一部またはすべてを、地図データとして読み出し、
読み出された地図データを用いて、前記伝送路にとって適切な形式のパケットを組み立て、組み立てられたパケットを、前記伝送路に送出し、
前記端末装置は、
前記伝送路を通じて、前記送信部により送信されたパケットを受信する受信部と、
前記受信部により受信されたパケットを分解して、地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、地図ファイルを記憶する第2の記憶装置とを備え、前記データ処理部は、
今回復元した地図データに関連する地図ファイルが前記第2の記憶装置に既に格納されている場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する、端末装置。」
を、
「【請求項1】 センタ局が端末装置に伝送路を通じて地図ファイルを提供するシステムであって、
前記センタ局は、
予め定められた範囲の地図が複数の領域に区画された複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第1の記憶装置と、
前記第1の記憶装置から、地図ファイルの一部またはすべてを、ユニット単位の地図データとして読み出す読み出し制御部と、
前記読み出し制御部により読み出されたユニット単位の地図データと、ファイルヘッダから生成した地図ファイルを特定するファイルIDとを用いて、前記伝送路にとって適切な形式のパケットを組み立てるパケット組み立て部と、
前記パケット組み立て部により組み立てられたパケットを、前記伝送路を通じて前記端末装置に送信する送信部とを備え、
前記端末装置は、
前記伝送路を通じて、前記送信部により送信されたパケットを受信する受信部と、
前記受信部により受信されたパケットを分解して地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第2の記憶装置とを備え、
前記データ処理部は、
今回復元した地図データのファイルIDと、第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する、地図提供システム。
【請求項2】 センタ局により送信された地図ファイルを伝送路を通じて受信する端末装置であって、
前記センタ局は、
予め定められた範囲の地図が複数の領域に区画された複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第1の記憶装置から、地図ファイルの一部またはすべてを、ユニット単位の地図データとして読み出し、
読み出されたユニット単位の地図データと、ファイルヘッダから生成した地図ファイルを特定するファイルIDとを用いて、前記伝送路にとって適切な形式のパケットを組み立て、組み立てられたパケットを、前記伝送路に送出し、
前記端末装置は、
前記伝送路を通じて、前記送信部により送信されたパケットを受信する受信部と、
前記受信部により受信されたパケットを分解して、地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第2の記憶装置とを備え、
前記データ処理部は、
今回復元した地図データのファイルIDと、第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する、端末装置。」
と訂正(訂正箇所に下線を付した。)するとともに、これに整合させるべく、発明の詳細な説明の対応箇所を含む不明瞭な記載を訂正するものである。

2 訂正の目的の適否、新規事項の有無及び拡張・変更の存否

上記訂正は、特許時の請求項2〜12を削除し、特許時の請求項1及び13について特許請求の範囲を減縮するとともに、明りょうでない記載の釈明をするものである。
また、上記訂正は、新規事項の追加に該当せず、実質上特許請求の範囲を拡張し、又は変更するものではない。

3 むすび

以上のとおりであるから、上記訂正は、特許法第120条の4第2項及び同条第3項で準用する同法第126条第2項及び第3項の規定に適合するので、当該訂正を認める。

第3 特許異議申立てについての判断

1 申立ての理由の概要

特許異議申立人は、請求項1〜13に係る発明は、甲第1〜4号証(後述)の刊行物に記載された発明に基づいて当業者が容易に発明をすることができたものであり、また、明細書の記載が不備であるので、請求項1〜13に係る発明の特許は、特許法第29条第2項の規定に違反してなされたものであり、また、特許法第36条第6項第2号及び第4項に規定する要件を満たしていない出願に対してなされたものであるから取り消すべき旨主張している。

2 特許法第29条第2項違反について

2-1 本件発明

本件特許第3332225号の請求項1、2に係る発明(以下それぞれ「本件発明1」、「本件発明2」という。)は,訂正明細書の特許請求の範囲の請求項1、2に記載された事項により特定されるとおりのものである(上記「第2,1」参照)。

2-2 刊行物に記載された発明

(1) 特許異議申立人が提出した甲第1〜4号証は、次のとおりである。
甲第1号証:特開平10-300499号公報(以下「刊行物1」という。)
甲第2号証:特開平7-160982号公報(以下「刊行物2」という。)
甲第3号証:特開平5-258000号公報(以下「刊行物3」という。)
甲第4号証:特開平9-145383号公報(以下「刊行物4」という。)
(2) 刊行物1には、サーバから移動端末へ地図情報を提供する地図情報システムが記載されている。
(3) 刊行物2には、地図データを所要のパケットに分割して送信し、受信したパケットを組み立てて地図データに復元することが記載されている。
(4) 刊行物3には、施設図面を複数の図形データファイルで構成することが記載されている。
(5) 刊行物4には、差分情報を用いて地図データを更新することが記載されている。

2-3 対比・判断

(1) 本件発明1について
本件発明1と刊行物1〜刊行物4に記載された発明とを対比すると、刊行物1〜刊行物4に記載された発明のいずれも、本件発明1の「(端末装置のデータ処理部が)今回復元した地図データのファイルIDと、第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する」構成を具備しておらず、刊行物1〜4には、これらを示唆する記載もない。
本件発明1は、上記構成を具備することにより、異議意見書に記載の「端末装置102において、大量のファイルが発生することを抑えることができる。そのため、第2の記憶装置1026内には、空き領域を有するクラスタが生じにくくなる。その結果、本地図提供システムは、第2の記憶装置1026の記憶領域を有効的に利用することができる。」という顕著な作用効果を奏するものと認められる。
してみると、本件発明1は、刊行物1〜刊行物4に記載された発明に基づいて、当業者が容易に発明をすることができたものとすることができない。
(2) 本件発明2について
本件発明2と刊行物1〜刊行物4に記載された発明とを対比すると、刊行物1〜刊行物4に記載された発明のいずれも、本件発明2の「(端末装置のデータ処理部が)今回復元した地図データのファイルIDと、第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する」構成を具備しておらず、刊行物1〜4には、これらを示唆する記載もない。
本件発明2は、上記構成を具備することにより、異議意見書に記載の「端末装置102において、大量のファイルが発生することを抑えることができる。そのため、第2の記憶装置1026内には、空き領域を有するクラスタが生じにくくなる。その結果、本地図提供システムは、第2の記憶装置1026の記憶領域を有効的に利用することができる。」という顕著な作用効果を奏するものと認められる。
してみると、本件発明2は、刊行物1〜刊行物4に記載された発明に基づいて、当業者が容易に発明をすることができたものとすることができない。

3 特許法第36条第6項第2号及び第4項違反について

特許異議申立人は、特許時の請求項2の「必要に応じて」との記載により発明が不明確であり、また、特許時の発明の詳細な説明における「第35の発明」との記載が何を指示するのかが不明であると主張する。
しかしながら、いずれの記載も訂正により削除されているから、本件特許の明細書の記載には、特許異議申立人の主張する不備はない。

4 むすび

以上のとおりであるから、請求項1、2に係る発明の特許は、特許異議申立ての理由及び証拠によっては取り消すことはできない。
また、他に請求項1、2に係る発明の特許を取り消すべき理由を発見しない。
よって、結論のとおり決定する。
 
発明の名称 (54)【発明の名称】
地図提供システム
(57)【特許請求の範囲】
【請求項1】センタ局が端末装置に伝送路を通じて地図ファイルを提供するシステムであって、
前記センタ局は、
予め定められた範囲の地図が複数の領域に区画された複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第1の記憶装置と、
前記第1の記憶装置から、地図ファイルの一部またはすべてを、ユニット単位の地図データとして読み出す読み出し制御部と、
前記読み出し制御部により読み出されたユニット単位の地図データと、ファイルヘッダから生成した地図ファイルを特定するファイルIDとを用いて、前記伝送路にとって適切な形式のパケットを組み立てるパケット組み立て部と、
前記パケット組み立て部により組み立てられたパケットを、前記伝送路を通じて前記端末装置に送信する送信部とを備え、
前記端末装置は、
前記伝送路を通じて、前記送信部により送信されたパケットを受信する受信部と、
前記受信部により受信されたパケットを分解して、地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第2の記憶装置とを備え、
前記データ処理部は、
今回復元した地図データのファイルIDと、第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する、地図提供システム。
【請求項2】センタ局により送信された地図ファイルを伝送路を通じて受信する端末装置であって、
前記センタ局は、
予め定められた範囲の地図が複数の領域に区画された複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第1の記憶装置から、地図ファイルの一部またはすべてを、ユニット単位の地図データとして読み出し、
読み出されたユニット単位の地図データと、ファイルヘッダから生成した地図ファイルを特定するファイルIDとを用いて、前記伝送路にとって適切な形式のパケットを組み立て、組み立てられたパケットを、前記伝送路に送出し、
前記端末装置は、
前記伝送路を通じて、前記送信部により送信されたパケットを受信する受信部と、
前記受信部により受信されたパケットを分解して、地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、複数のユニットと、各前記ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第2の記憶装置とを備え、
前記データ処理部は、
今回復元した地図データのファイルIDと、前記第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、前記第2の記憶装置に格納する、端末装置。
【発明の詳細な説明】
【0001】
【発明が属する技術分野】
本発明は、端末装置に関し、より特定的には、地図を複数の領域に分割して得られる各ユニットがデジタルデータ化された地図ファイルが内部の記憶装置に格納されており、当該記憶装置から地図ファイルを読み出す端末装置に関する。
【0002】
【従来の技術】
「第1の従来技術」
近年、ナビゲーションシステムが搭載された車両が増加してきている。ナビゲーションシステムでは、当初は、画面上に地図を作成するファイル(以下、地図ファイルと称す)だけが提供されていた。しかし、近年は、地図ファイルに加えて、例えば交通情報および経路案内情報も提供されるようになった。かかる情報の多様化により、ナビゲーションシステムは、より便利になり、今後も急速に普及すると期待されている。
【0003】
当初、ナビゲーションシステムには、CD-ROMに代表される読み出し専用の記録媒体を有する記憶装置が搭載されていた。この記録媒体には、ユーザに提供されるべき地図ファイルと、その関連データとが予め記録されている。記憶装置は、記憶媒体に記録された地図ファイルを、必要に応じて読み出す。読み出された地図ファイルは、ユーザにより参照されたり、経路探索処理またはマップマッチング処理に利用されたりしていた。
【0004】
一般的にディジタル地図ファイルは、互いに縮尺の異なる地図の階層構造を効率よく管理するために、当該各地図を経度方向および緯度方向に等間隔に分割した矩形領域毎に作成される。以下、「第1の従来技術」において、かかる矩形領域を以降ではユニットと呼ぶ。
【0005】
かかる地図ファイルは、典型的には、カーナビゲーションシステムにおいて、経路探索処理または現在位置の補正処理(マップマッチング)に用いられる。そのために、地図ファイルには、道路ネットワークデータが記録される。道路ネットワークデータは、少なくとも、各ノードおよび各リンクの接続関係を示す接続情報とから構成される。ここで、ノードとは、主として、道路網に存在する交差点を表す情報であり、リンクとは、主として、2つの交差点間に存在する道路を表すベクトル情報である。かかるノードおよびリンクの集合によって、それぞれのユニット内の道路ネットワークを表す地図が表現される。
【0006】
上記のノード、リンクおよびそれらの接続情報で最小限の道路網を表現することができるが、これだけでは地図を表示する用途には不十分である。例えば、山岳部や臨海部の道路では交差点間の道路が屈曲している場合が多い。そこで、道路ネットワークデータは、屈曲した道路の形状を表示するためにリンク形状を特定するための情報をさらに含む。以上から明らかなように、リンクはベクトルデータで表現されることが多い。
また、道路には、国道および県道というように様々な種類がある。他にも、車線数の相違または中央分離帯の有無等により道路を分類することができる。かかる道路の種類を区別するために、道路ネットワークデータは、道路の種別等を示す属性情報をさらに含んでいる。
また、交差点には、交差点名称が付けられているものや、付けられていないものがある。さらには、信号機が設置されている交差点、信号機が設置されていない交差点がある。そこで、道路ネットワークデータはさらに、ノード毎に属性情報を有している。各属性情報には、対応する交差点の名称および信号機の有無等の情報が記録される。
【0007】
また、ベクトルデータ構造を有する地図ファイルでは、複数のユニットに跨るような道路が存在する場合には、ユニットの境界に特別なノード(以降、隣接ノードと称す)が別途作成される。かかる隣接ノードを経由することによって、互いに隣接するユニットとの間で道路の接続関係を辿ることができるようになる。従来の地図ファイルでは、あるユニットの隣接ノードが、隣接するユニットのどの隣接ノードと対応するかを特定するために、オフセットアドレスおよびレコード番号が記録されていた。ここで、オフセットアドレスとは、基準アドレスからみて、隣接ノードがどのアドレス位置に記録されているかを示す。また、レコード番号とは、隣接ユニットの地図ファイルにおいて、先頭のノードから起算して隣接ノードが何番目の位置に記録されているかを示す。
【0008】
「第2の従来技術」
「第1の従来技術」で説明したように、従来のナビゲーションシステムは、当初、読み出し専用の記録媒体に記録された地図ファイルしか利用できなかったので、リアルタイム性の高い情報を提供することが困難であった。かかるリアルタイム性の高い情報としては、交通情報または気象情報が代表的である。そのため、リアルタイム性が要求される情報、さらには地図ファイルを提供できる地図提供システムが、例えば、「特開平7-262493号」公報に開示されている。この公報の地図提供システムでは、地図ファイルおよびリアルタイム性の高い情報が、情報提供センターから車載用の端末装置へと通信メディアを介してダウンロードされる。
【0009】
また、地図提供システムは、情報をリアルタイムに提供するために、移動体通信技術とデジタル放送技術とに基づいて構築される。このような地図提供システムでは、センタ局は、サービスエリア内に存在する移動体に対し、所定の放送用チャンネルを用いて情報を配信する。センタ局としては、通信衛星(いわゆるCS)、放送衛星(いわゆるBS)、または地上波のディジタル放送局が典型的である。この移動体通信技術とデジタル放送技術が利用された地図提供システムは、例えば、「特開平7-154350号」公報に開示されている。より具体的には、この公報には、ある情報の放送地域を限定するための技術的内容が開示されている。つまり、センタ局は、多重された情報を、放送メディアを介して送信する際に、各情報に郵便番号のような地域コードを付ける。端末装置は、自身の現在位置に対応する地域コードをIDとして予めメモリに登録しておく。端末装置の内部では、データ抽出回路が、放送局から放送される多重情報を分離して、各情報に付加された地域コードを取り出す。さらに、端末装置の内部では、取り出された地域コードと、登録されたIDとが比較される。両者が一致する場合に、端末装置は、対象となった地域コードが付された情報をユーザに参照させる。
【0010】
以上のように、通信または放送により地図を提供するような地図提供システムの開発が近年盛んである。この地図提供システムにおいて、センタ局は、端末装置に送信すべき地図ファイルをユニット単位で読み出して、当該端末装置に送信する。端末装置は、センタ局からの地図データを受信した後に、記憶装置に格納する。格納された地図ファイルは、必要に応じて、ユーザが参照するため、経路探索処理のため、またはマップマッチング処理のために用いられる。
【0011】
【発明が解決しようとする課題】
「第1の従来技術の課題」
「第1の従来技術」から明らかなように、従来では、あるユニットの地図ファイルには、隣接ユニットの地図ファイル内部のデータ構造を直接指示する情報(上述のオフセットアドレスまたはレコード番号)が記録されていた。
例えば、あるユニット内の道路が新しく造成された場合には、当然、当該ユニットの地図ファイルは更新される。更新された地図ファイルでは、隣接ノードが記録される位置が変わる場合が多い。そのため、従来のような地図ファイル内部のデータ構造を直接指示する方法を採用していれば、隣接ユニットの地図ファイルに記録された隣接ノードから、更新された地図ファイルにおいて対応する隣接ノードを正確にたどれなくなる。つまり、ある1つの地図ファイルが更新されると、隣接ユニットの地図ファイルも更新しなければならない場合が多くなるという問題点があった。
【0012】
また、上述のディジタル地図ファイルの品質を評価する尺度として、地図の詳細度がある。しかしながら、地図ファイルは、リンクがベクトルデータで表現されることから、詳細な地図を表現しようとすればするほど、当該地図ファイルのデータ量が大きくなるという問題点があった。
従来、かかる地図ファイルは、主として、カーナビゲーションシステムにて使用される。カーナビゲーションシステムでは、CD-ROM、DVD-ROMまたはハードディスク等の大容量の記憶媒体に、地図ファイルが記録される。しかし、今後、地図ファイルは、カーナビゲーションシステムだけでなく、人が携帯できるような情報機器においても使用されることが考えられる。かかる携帯型情報機器に、カーナビゲーションシステムのような大容量の記憶媒体を搭載することは難しい。かかる点から、地図ファイルのデータ量を圧縮する必要性は高い。
【0013】
「第2の従来技術の課題」
ところで、「第2の従来技術」の欄で示した各公報は、端末装置が地図ファイルを記憶装置にどのようにして格納するかについて何ら開示していない。容易に想到できるのは、端末装置が、受信したユニット毎の地図ファイルを作成して、作成した地図ファイルを記憶装置に格納するという方法である。しかしながら、この方法では、記憶領域の利用効率が悪くなるという問題点があった。今、例えば、ある範囲を表す地図βが、図71のように、64個の矩形のユニットに区画化されると仮定する。さらに、端末装置が、4個のユニット71から74を受信し格納すると仮定する。また、周知のように、記憶装置の記憶領域は、クラスタ単位で管理される。また、各ユニットのデータサイズは、クラスタのサイズの整数倍に一致するとは限らない。そのため、端末装置が、受信した4個のユニット71〜74について、4個のファイル81〜84を作成すると、図72に示すように、空き領域を有する4個のクラスタ91〜94が発生する場合が多い。図72において、ドットが付された部分は、各ファイル81〜84が記録された領域を示す。また、斜線が付された部分は、空き領域を示す。各クラスタ91〜94に生じた空き領域は使用されない。つまり、たとえ、端末装置が、各ユニット71〜74以外のユニット75(図71参照)を受信したとしても、このユニット75を基に作成されたファイルは、各クラスタ91〜94の空き領域に格納されることはない。以上から明らかなように、端末装置が受信するユニットが多くなればなるほど、空き領域を有するクラスタが多くなる。つまり、記憶領域の利用効率が悪くなる。
【0014】
ところで、地図が相対的に少数のユニットに区画されれば、空き領域を有するクラスタを発生し難くすることができる。今、図71と同じ範囲の地図βが、図73のように、16個の矩形のユニットに区画されると仮定する。図73のユニット76が表す範囲は、図71のユニット71〜74を併せた範囲に相当する。さらに、端末装置が1個のユニット76を受信し格納すると仮定する。この仮定下では、端末装置は、受信した1個のユニット76について、1個のファイル86を作成すると、図74に示すように、空き領域を有するクラスタ96が1個しか発生しない。図74のドット部分は、ファイル86が記録された領域を示す。また、斜線部分は、空き領域を示す。
【0015】
以上から明らかなように、地図が小さいユニットに区画された場合(図71参照)、ある範囲を表す地図ファイルが記憶装置に格納されると、相対的に多く空き領域が発生する(図72参照)。しかしながら、地図が大きなユニットに区画された場合には(図73参照)、同じ範囲の地図データが記憶装置に格納されても、発生する空き領域は少ない(図74参照)。つまり、記憶領域の有効利用の観点からは、地図は少数のユニットに区画された方がよい。
【0016】
しかしながら、地図を少数のユニットに区画するということは、1ユニット当たりのデータ量が大きくなることを意味する。そのため、基地局は、1度に、大量のデータを端末装置に送信しなければならない。その結果、無線伝送路は輻輳状態に陥り易くなる、つまり無線伝送路の利用効率が悪くなる、という別の問題点が生じる。つまり、記憶領域を重視すれば、無線伝送路の効率的な利用が難しく、無線伝送路を重視すれば、記憶領域の効率的な利用が難しくなるという問題点があった。
【0017】
それゆえに、本発明の第1の目的は、ある1つが更新された場合に、隣接ユニットの地図ファイルを更新する必要がない地図ファイルのデータ構造を提供することである。また、本発明の第2の目的は、そのデータ量を圧縮可能な地図ファイルのデータ構造を提供することである。また、本発明の第3の目的は、端末装置内の記憶領域を効率的に利用し、しかもセンタ局と端末装置との間の伝送路を効率的に利用できる地図提供システムを提供することである。
【0018】
【課題を解決するための手段および発明の効果】
本発明は、センタ局が端末装置に伝送路を通じて地図ファイルを提供するシステムであって、
センタ局は、
予め定められた範囲の地図が複数の領域に区画された複数のユニットと、各ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第1の記憶装置と、
第1の記憶装置から、地図ファイルの一部またはすべてを、ユニット単位の地図データとして読み出す読み出し制御部と、
読み出し制御部により読み出されたユニット単位の地図データと、ファイルヘッダから生成した地図ファイルを特定するファイルIDとを用いて、伝送路にとって適切な形式のパケットを組み立てるパケット組み立て部と、
パケット組み立て部により組み立てられたパケットを、伝送路を通じて端末装置に送信する送信部とを備え、
端末装置は、
伝送路を通じて、送信部により送信されたパケットを受信する受信部と、
受信部により受信されたパケットを分解して、地図データを復元する処理を実行するデータ処理部と、
その内部の記憶媒体に、複数のユニットと、各ユニットを管理するための管理情報と、地図ファイルがカバーする範囲を特定するファイルヘッダとから構成された地図ファイルを記憶する第2の記憶装置とを備え、
データ処理部は、
今回復元した地図データのファイルIDと、第2の記憶装置に既に格納されている地図ファイルのファイルヘッダとの同一性を判断し、同一性がある場合には、当該第2の記憶装置から当該地図ファイルを読み出し、さらに、
復元した地図データを、読み出された地図ファイルに追加して、第2の記憶装置に格納する。
【0019】
上記発明では、データ処理部は、今回復元した地図データと、第2の記憶装置から読み出された地図ファイルとを一まとめにして当該第2の記憶装置に格納し、これによって、地図ファイルを更新する。このようにデータ処理部は、受信部が受信した地図データにのみ基づいて、地図ファイルを作成しない。データ処理部は、今回受信された地図データを、今回読み出された地図ファイルに追加する。そのため、第2の記憶装置は、データ量が小さな地図ファイルを多数格納せずに、あるまとまったデータ量の地図ファイルを格納するので、空き領域を有するクラスタが発生しにくくなる。これによって、端末装置側の記憶領域を効率的に利用できる地図提供システムを実現することができる。
【0020】
さらに、上記発明では、センタ局が小さいサイズの地図データを送信しても、端末装置がセンタ局から提供された地図データを1ファイルにまとめるので、空き領域を有するクラスタの発生を抑えることができる。このように、上記発明では、センタ局が小さなサイズの地図データを送信できるので、伝送路が輻輳状態に陥りにくくなる。これによって、伝送路を効率的に利用できる地図提供システムを実現することができる。
【0021】
【0022】
【0023】
【0024】
【0025】
【0026】
【0027】
【0028】
【0029】
【発明の実施の形態】
「第1の実施形態」
「システム構成」
図1は、本発明の一実施形態に係る地図提供システムの構成を示すブロック図である。図1において、本地図提供システムには、端末装置1とセンタ局2とが収容される。端末装置1とセンタ局2とは通信網3を通じて双方向通信可能に接続される。より具体的には、端末装置1とセンタ局2との間には、アップリンクULとダウンリンクDLとが張られる。アップリンクULとは、端末装置1からセンタ局2への通信路を意味し、ダウンリンクDLとは、センタ局2から端末装置1への通信路を意味する。ここで、通信網3の典型例としては、携帯電話に代表される移動体通信網、ISDN(Integrated Services Digital Network)に代表される公衆回線、または専用回線がある。また、通信網3は、移動体通信網、公衆回線および専用回線の内のいずれか2つ以上により構成される場合もある。
【0030】
次に、端末装置1の構成について説明する。端末装置1は、典型的には、カーナビゲーションシステムにより相当し、入力装置11と、位置検出装置12と、データ処理部13と、要求生成部14と、第1の送受信部15と、アンテナ16と、パケット分解部17と、読み出し/書き込み制御部18と、第1の記憶装置19と、出力装置110とを備える。
入力装置11は、カーナビゲーションシステムを遠隔から操作するリモートコントローラまたはカーナビゲーションシステム本体に配列されたキーによりハードウェア的に実現されたり、カーナビゲーションシステムのメニュー画面に表示されたボタンによりソフトウェア的に実現されたりする。さらには、入力装置11は、音声認識技術を駆使して実現される場合もある。端末装置1のユーザは、以上の入力装置11を操作して、端末装置1に対して、表示された地図のスクロールまたは縮尺変更、経路探索、情報検索、もしくはセンタ局2への接続等、様々な処理の要求を行う。さらに、入力装置11は、特徴的な動作として、ユーザが必要とする地図ファイルCFを特定するための情報をデータ処理部13に出力する。
【0031】
位置検出装置12は、速度センサ、ジャイロセンサ、またはGPS(Global Positioning System)のアンテナおよび受信機により実現される。また、速度センサ、ジャイロセンサ、ならびにGPS(Global Positioning System)のアンテナおよび受信機のいずれか2つ以上の組み合わせにより、位置検出装置12は実現される場合もある。位置検出装置12は、速度センサにより端末装置1の移動速度を検出して、検出結果を基に走行距離を算出したり、ジャイロセンサにより端末装置1の進行方向を検出したり、アンテナおよび受信機により人工衛星からの電波を受信して、地球上における端末装置1の絶対的な位置を検出したりする。以上の検出結果を基に、位置検出装置12は端末装置1の現在位置を検出する。
データ処理部13は、後述する各種のデータ処理を行う。データ処理部13の処理の一つに、入力装置11から入力された情報を基に、ユーザが必要とする地図の範囲を特定する座標を求めて、要求生成部14に出力するという処理がある。
要求生成部14は、座標情報が入力されると、ユーザが必要とする地図ファイルCFの送信をセンタ局2に要求するための制御コマンドを生成する。以降、生成された制御コマンドを要求REQと称することとする。要求REQは、予め定められたフォーマットを有しており、要求生成部14に入力された座標情報を少なくとも含む。以上のような要求REQは、第1の送受信部15に出力される。
第1の送受信部15は、典型的には、携帯電話に代表される移動体通信装置により実現される。第1の送受信部15は、入力された要求REQを、アンテナ16を通じてアップリンクULに送出する。
【0032】
要求REQは、アップリンクULを通じて、センタ局2により受信される。センタ局2は、要求REQを解析して、ユーザが必要とする地図ファイルCFを特定する。センタ局2は、特定した地図ファイルCFを第2の記憶装置24から取り出して、複数のパケットPを組み立てる(アセンブリする)。組み立てられたパケットPは、通信網3(ダウンリンクDL)を通じて、順次端末装置1に送信される。なお、センタ局2の処理は後で詳しく説明される。端末装置1において、第1の送受信部15はさらに、アンテナ16を通じてパケットPを受信して、パケット分解部17に出力する。パケット分解部17は、入力されたパケットPを、元の地図ファイルCFに分解(デアセンブリ)して、データ処理部13に出力する。
データ処理部13は、地図ファイルCFが入力されると、予め定められた処理を実行して、所定の条件を満たす場合、入力された地図ファイルCFを基に第1のデータベース111を作成して読み出し/書き込み制御部18に出力する。読み出し/書き込み制御部18は、入力された地図ファイルCFを第1の記憶装置19にそのまま書き込んだり、既存の地図ファイルCFと書き換えたりする。
なお、一連の書き込み処理については後で説明する。
第1の記憶装置19は、典型的には、ハードディスクドライブまたはフラッシュメモリに代表される、データの書き換えが可能な記憶装置からなる。第1の記憶装置19には、第1のデータベース111が蓄積される。第1のデータベース111は、本端末装置1がナビゲーションシステムとして機能するために必要な少なくとも1つの地図ファイルCFから構成されるデータの集合体である。
また、出力装置110は、典型的には、ディスプレイおよびスピーカからなる。ディスプレイには、地図ファイルCFにより表される地図が現在位置とともに表示されたり、データ処理部13による経路探索処理の結果または経路案内処理の結果が表示されたりする。スピーカは、データ処理部13による経路案内処理の結果が音声によりユーザに提供する。
【0033】
ところで、データ処理部13は、第1のデータベース111を構成する地図ファイルCFを使って様々な処理を行う。例えば、データ処理部13は、端末装置1の現在位置の表示処理を実行する。この場合、データ処理部13は、位置検出装置12により検出された現在位置周辺の地図が必要となるので、読み出し/書き込み制御部18と協働して、第1のデータベース111から、当該地図を表す地図ファイルCFを検索して取り出す。データ処理部13は、取り出された地図ファイルCFを使って、マップマッチング等の位置補正処理を行う。位置補正処理後、データ処理部13は、取り出した地図ファイルCFが表す地図上に、検出された現在位置を視覚的に示すポインタを重ね合わせて、出力装置110に出力する。
また、データ処理部13は、端末装置1のユーザが入力装置11を用いて経路探索処理等を要求した場合には、出発地および目的地付近の地図を表す地図ファイルCF、ならびに探索すべき経路を含む地図を表す地図ファイルCFを読み出して経路探索処理等を行う必要がある。この場合にも、データ処理部13は、読み出し/書き込み制御部18と協働して、第1のデータベース111から、経路探索処理等に必要となる地図ファイルCFを検索して取り出す。なお、一連の地図ファイルCFの読み出し処理については後で説明する。
【0034】
次に、センタ局2の構成について説明する。センタ局2は、第2の送受信部21と、受信要求解析部22と、読み出し制御部23と、第2の記憶装置24と、パケット組み立て部25とを備える。
上述したように、センタ局2には、端末装置1により生成された要求REQが通信網3(アンプリンクUL)を通じて送信されてくる。第2の送受信部21は、典型的には、モデム、ターミナルアダプタ、またはゲートウェイに代表される通信装置からなる。ここで、ゲートウェイとは、異なる通信プロトコルが使用される通信網3にセンタ局2を接続するための装置または機能を意味するだけでなく、他の局が当該センタ局2に不正アクセスすることを防止するための装置または機能を意味する。第2の送受信部21は、通信網3と接続されており、端末装置1からのデータ受信および端末装置1へのデータ送信を制御する。より具体的には、第2の送受信部21は、その一つの機能として、アップリンクULを通じて送信されてきた要求REQを受信して受信要求解析部22に出力する。
【0035】
受信要求解析部22は、入力された要求REQを解析して、解析結果を読み出し制御部23に出力する。読み出し制御部23は、入力された解析結果を基に、端末装置1が必要とする地図ファイルCFを第2の記憶装置24から読み出す。ここで、第2の記憶装置24は、典型的には、ハードディスクドライブ、CD-ROMドライブまたはDVD-ROMドライブで構成されており、少なくとも蓄積されたデータの読み出しが可能な記録媒体とそのドライバとからなる。第2の記憶装置24は、第2のデータベース25を格納する。第2のデータベース25は、センタ局2が本端末装置1に地図を提供する局として機能するために必要な少なくとも1つの地図ファイルCFから構成されるデータの集合体である。つまり、地図ファイルCFは、端末装置1に提供可能な地図を表現したデジタルデータを意味する。端末装置1側の第1のデータベース111は、センタ局2により提供される地図ファイルCFから作成される。ここで、読み出し制御部23が読み出すのは、地図ファイルCFのすべてである場合もあれば、当該地図ファイルCFの一部である場合もある。読み出し制御部23は、読み出した地図ファイルCFを、パケット組み立て部25に出力する。パケット組み立て部25は、入力された地図ファイルCFを基にパケットPを組み立てて(アセンブリして)、第2の送受信部21に出力する。第2の送受信部21は、ダウンリンクDLを通じて、入力されたパケットPを端末装置1に送信する。
【0036】
以上、本実施形態に係る地図提供システムの全体構成、ならびに端末装置1およびセンタ局2の構成について説明した。次に、上述の地図ファイルCFの階層構造およびファイル名について詳細に説明する。
【0037】
「階層構造およびファイル名」
図2は、本実施形態に係る地図ファイルCFにより表現される地図の階層構造を説明するための図である。図2に示すように、まず、互いに縮尺の異なる複数種類の地図が準備される。本実施形態では、便宜上、4段階の縮尺の地図が準備されると仮定する。以降の説明では、最大縮尺をレベル「0」、2番目に大きな縮尺をレベル「1」、3番目に大きな縮尺をレベル「2」、最小縮尺をレベル「3」と称する。以上から分かるように、地図データは、最大縮尺をレベル「0」として、レベル「0」〜「3」の4階層から構成される。さらに、レベルが高いものを上位階層の地図と称し、レベルが低いものを下位階層の地図と称する。したがって、図2に示すように、上位階層の地図ほど、広域でかつ詳細度が低い。逆に、下位階層の地図ほど、狭域でかつ詳細度が高い。また、各階層の地図は、経度方向および緯度方向に沿って等間隔に区切られる。
【0038】
ここで、図3は、最上位階層(レベル「3」)のユニットを説明するための図である。図3の世界地図は、緯度0度を基準として、当該緯度方向に沿って5度20分毎に区切られる。さらに、この世界地図は、経度0度を基準として、当該経度方向に沿って約8度毎に区切られる。その結果、世界地図は、約640km四方の矩形領域に分割される。最上位階層(レベル「3」)においては、約640km四方の矩形領域をユニットと称する。レベル「3」においては、かかる約640km四方のユニットがデジタルデータ化されることにより、1つの地図ファイルCFが作成される。以上のような、最上位階層(レベル「3」)のユニットを代表して、ユニットU3(ハッチングを付した部分)について説明する。最上位階層(レベル「3」)のユニットU3は、日本の関西圏を含むユニットであり、緯度0度、経度0度の位置を原点として、東経方向に数えて16番目、北緯方向に数えて6番目に位置する(ただし、原点を含むユニットは0番目と数える)。以上のユニットU3が、図2の最上段に示されている。
【0039】
図2に示すように、ユニットU3の地図は、一つの頂点を基準として、点線で示すように、緯度方向に沿って40分毎に区切られる。さらに、ユニットU3の地図は、上記と同じ頂点を基準として、点線で示すように、当該経度方向に沿って1度毎に区切られる。その結果、ユニットU3の地図は、約80km四方の矩形領域に64分割される。約80km四方の各矩形領域を詳細に表した地図が、1階層下(つまり、レベル「2」の階層)における1つのユニットとなる。レベル「2」の階層のユニットを代表して、ユニットU2(ハッチングを付した部分)について説明する。かかるユニットU2は、ユニットU3内の1つの頂点(便宜上、左下の頂点とする)の位置を原点として、東経方向に数えて4番目、北緯方向に数えて1番目に位置する(ただし、原点を含むユニットUは0番目と数える)。レベル「2」の階層のユニットU2が、図2の2段目に示されている。
【0040】
同様に、ユニットU2の地図は、一つの頂点を基準として、緯度方向に沿って5分毎に、さらに経度方向に沿って7分30秒毎に区切られ、その結果、約10km四方の矩形領域に64分割される。約10km四方の各矩形領域を詳細に表した地図が、1階層下(つまり、レベル「1」の階層)における1つのユニットとなる。その内の一つであるユニットU1(ハッチングを付した部分)は、ユニットU2の左下の頂点を原点として、東経方向に数えて5番目、北緯方向に数えて3番目に位置する(ただし、原点を含むユニットは0番目と数える)。レベル「1」のユニットU1が、図2の上から3段目に示されている。
【0041】
同様に、ユニットU1の地図は、約1.2km毎四方の矩形領域に64分割される。約1.2km四方を詳細に表した各地図が、1階層下(つまり、レベル「0」の階層)における1つのユニットUとなる。その内の一つであるユニットU0(ハッチングを付した部分)は、ユニットU1の左下の頂点を原点として、東経方向に2番目、北緯方向に1番目に位置する(ただし、原点を含むユニットは0番目と数える)。レベル「0」のユニットU0が、図2の上から4段目に示されている。
【0042】
図4は、レベル「3」〜「0」のそれぞれの階層間におけるユニットUの親子関係を説明するための図である。まず、以下の説明において、子ユニットCUとは、ある1つのユニットUがカバーする範囲に包含される、下位階層の全てのユニットを意味する。言い換えれば、子ユニットCUとは、上位階層のある1つのユニットUが表す地図の一部分を表すユニットUの集合である。逆に、親ユニットPUとは、あるユニットUのカバーする範囲を包含する、上位階層の全てのユニットを意味する。言い換えれば、親ユニットPUとは、下位階層のある1つのユニットUが表す地図を、自身が表す地図の一部として含んでいるユニットUの集合である。
ここで、図4中のユニットU3は、図2に示すユニットU3に相当しており、レベル「3」のユニットの一つである。ユニットU3を親ユニットPU3とするレベル「2」のユニットU、すなわちユニットU3の子ユニットCUの内、レベル「2」に属するものは、ユニットU3を経度および緯度方向にそれぞれ8等分してできる64個のユニットUとなる。
【0043】
このように、親ユニットPUに対しては、1階層下に64個の子ユニットCUができる。各子ユニットCUには位置コードが割り当てられる。位置コードとは、子ユニットCUが表す地図が、親ユニットPUのどの部分に相当するかを特定するための情報である。言い換えれば、位置コードとは、親ユニットPUを基準とした子ユニットCUの位置を特定するための情報である。
今、親ユニットPUが図4ユニットU3であるとする。かかる場合、ユニットU3の左下隅の地図を詳細に表す子ユニットCUには、位置コードとして「0000」が割り当てられる。この位置コード「0000」を基準値として、子ユニットCU(位置コード「0000」)に対して、東経方向に沿って隣接する子ユニットCUには「0100」が割り当てられる。以下同様に、子ユニットCUが東経方向に1つ移るたびに、位置コードは、「0100」だけ増加する.また、位置コード「0000」を基準値として、子ユニットCU(位置コード「0000」)に対して、北緯方向に沿って隣接する子ユニットCUには「0001」が割り当てられる。以下同様に、子ユニットCUが北緯方向に1つ移るたびに、位置コードは、「0001」だけ増加する。
以上のように割り当てられる位置コードに従えば、ユニットU3の子ユニットCUの一つであるユニットU2の位置コードは「0401」である。
【0044】
次に、親ユニットPUがユニットU2であると仮定する。このユニットU2に対しても、1階層下(レベル「1」)には64個の子ユニットCUができる。レベル「1」の64個の子ユニットCUに対しても、図4に示すように、上述と同様の方法で位置コードが割り当てられる。例えば、ユニットU2の子ユニットCUの一つであるユニットU1の位置コードは「0503」である。
また、親ユニットPUとしてのユニットU1に対しても、1階層下(レベル「0」)には、64個の子ユニットCUができる。レベル「0」の各子ユニットCUに対しても、図4に示すように、同様に位置コードが割り当てられる。例えば、ユニットU1の子ユニットCUの一つであるユニットU0の位置コードは「0201」である。
【0045】
以上のように、本実施形態に係る位置コードでは、東経方向への値の増分および北緯方向への値の増分が予め定められている。そのため、子ユニットCU同士の隣接関係を簡単に把握することができる。
【0046】
ところで、図1に示す端末装置1およびセンタ局2にはそれぞれ、ファイルシステムが搭載される。端末装置1側のファイルシステムは、データ処理部13および読み出し/書き込み制御部18により構成される。端末装置1側のファイルシステムは、第1の記憶装置19内の第1のデータベース111を容易に管理すべく、第1の記憶装置19が有する記録領域を「ディレクトリ」と呼ばれるいくつかの論理領域に分割する。さらに、端末装置1側のファイルシステムは、第1のデータベース111を構成する地図ファイルCFの親子関係および隣接関係を、ツリー構造に基づくディレクトリ名およびファイル名により表す。
また、センタ局2側のファイルシステムは、受信要求解析部22および読み出し制御部23により構成される。センタ局2側のファイルシステムは、第2の記憶装置24内の第2のデータベース25の記憶領域を「ディレクトリ」(論理領域)に分割し、さらに、第2のデータベース25を構成する地図ファイルCFの親子関係および隣接関係を、ツリー構造に基づくディレクトリ名およびファイル名により表す。
【0047】
以下、図5は、図2〜図4に示す地図ファイルCFを管理するためのツリー構造を示す図である。上述したように、各ファイルシステムの各ディレクトリは、図5に示すようなツリー構造をとり、「¥」マークにより表される。「¥」マークは、ディレクトリを識別するための識別子である。また、最上部のディレクトリは、ルートと呼ばれ、「¥MAP」で表される。ルートディレクトリ「¥MAP」の下のディレクトリには、地図ファイルCFそのものまたはサブディレクトリを格納することができる。ここで、ファイルシステムは、必要な地図ファイルCFを指定する際、ファイル名の前にルート「¥MAP」から当該地図ファイルCFが存在するディレクトリまでに介在するディレクトリ名を「パス」として記述する必要がある。したがって、2つの「¥」マークで挟まれた文字列がディレクトリ名を表すこととなる。サブディレクトリ名の頭文字は「D」と定義される。また、ファイル名の頭文字は「M」と定義される。さらに、ファイル名の拡張子は「.map」と定義される。
【0048】
さて、次に、本実施形態の一つの特徴である、ディレクトリ名およびファイル名を割り当て方法を説明する。まず、原則として、最上位階層の各ユニットがカバーする地図を表す地図ファイルCFは、所定の規則に従ってファイル名が付けられ、ルート(「¥map」)の直下のディレクトリ(論理領域)に格納される。例えば、図3に示すユニットU3は、最上位の階層(レベル「3」)に属しており、原点(緯度0度、経度0度)を基準として、東経方向に数えて16番目、北緯方向に6番目(ただし、原点を含むユニットはそれぞれ0番目と数える)のユニットに該当する。そのため、ユニットU3には、ファイル名の頭文字および拡張子を含めて「M1606.map」という名前が付けられる。さらに、最上位階層のユニットU3は、ルート(「¥map」)の直下に格納されるので、パスは、「¥MAP¥M1606.map」となる。
以上のユニットU3のファイル名から分かるように、ファイル名の頭文字および拡張子の間には、4桁の数字が並ぶ。上位2桁の数字は、ユニットUが原点から東経方向に数えて何番目に位置するかを規定する。また、下位2桁の数字は、ユニットUが原点から北緯方向に数えて何番目に位置するかを規定する。このように、ファイル名は、ユニットUの位置を規定する。また、ユニットU3のパスから分かるように、ルート(「¥map」)からファイル名に至るまでにはサブディレクトリが介在しない。このように、サブディレクトリの個数は、ユニットUがどの階層に属しているかを規定する。ユニットU3の場合には、ルートとファイル名との間に介在するサブディレクトリの個数が「0」であることにより、ユニットU3(M1606.map)が最上位階層に属することが分かる。
以上の規則に従うと、他の最上位階層のユニットUのためのパスは、「¥MAP¥M0000.map」,「¥MAP¥M0001.map」,…「¥MAP¥M1606.map」…等のように表される。
【0049】
また、最上位階層のユニットUを親ユニットPUとするユニットのグループを格納するためのサブディレクトリがルートの直下に作成される。例えば、ユニットU3を親ユニットPUとするユニットUのグループを格納するために、「¥D1606」と名付けられたサブディレクトリがルートの直下に作成される。以上のサブディレクトリ名から分かるように、サブディレクトリ名の頭文字には4桁の数字が続く。この4桁の数字は、ファイル名の場合と同様に、親ユニットPUが原点から東経方向および北緯方向に数えてそれぞれ何番目に位置するかを表す。そのため、ルート(「¥MAP」)の直下には、「¥D0000」、「¥D0001」,…,「¥D1606」,…が作成される。
【0050】
次に、レベル「2」の階層に属する各ユニットUは、位置コードに基づくファイル名が付けられ、自身の親ユニットPUを表すサブディレクトリの直下のディレクトリ(論理領域)に格納される。例えば、ユニットU3を親ユニットPUとするレベル「2」のユニットUは、図4等を参照すると64個ある。その内の一つであるユニットU2は、位置コードが「0401」であるため、ファイル名の頭文字および拡張子を含めて「M0401.map」という名前が付けられる。さらに、レベル「2」のユニットU2は、ユニットU3(親ユニットPU)のサブディレクトリ(「¥map¥D1606」)の直下に格納されるので、パスは、「¥MAP¥D1606¥M0401.map」となる。
以上のユニットU2のファイル名から分かるように、レベル「2」のユニットUのファイル名の頭文字および拡張子の間には、上述した位置コードが並ぶ。そのため、レベル「2」のユニットUのファイル名もまた、当該ユニットUの位置を規定することとなる。また、ユニットU2のパスから分かるように、ルート(「¥map」)からファイル名に至るまでにはサブディレクトリが1つだけ介在する。サブディレクトリの個数は、ユニットUがどの階層に属しているかを規定する。ユニットU2の場合には、ルートとファイル名との間に介在するサブディレクトリの個数が「1」であることにより、当該ユニットU2(M0401.map)がレベル「2」の階層に属することが分かる。
以上の規則に従うと、他のレベル「2」のパスは、「¥MAP¥D0000¥M0000.map」,「¥MAP¥D0000¥M0001.map」,…,「¥MAP¥D0000¥M0007.map」,「¥MAP¥D0000¥M0100.map」,…「¥MAP¥D0000¥M0707.map」,「¥MAP¥D0001¥M0000.map」,…「¥MAP¥D1606¥M0001.map」,…,「¥MAP¥D1606¥M0401.map」,…「¥MAP¥D1606¥M0707.map」,…等のように表される。
【0051】
同様に、レベル「2」のユニットU2を親ユニットPUとするユニットのグループは、サブディレクトリ「¥D0401」の下のディレクトリ(論理領域)の下に格納されることになる。例えば、ユニットU1は、ユニットU2の子ユニットCUの一つであって、当該ユニットU2が64分割されたユニットUの内、位置コード「0503」に該当するユニットである。そのため、ユニットU1のためのパスは、「¥MAP¥D1606¥D0401¥M0503.map」と表される。同様に、ユニットU2を親ユニットPUとするレベル「1」の各ユニットのパスは、「¥MAP¥D1606¥D0401¥M0000.map」、「¥MAP¥D1606¥D0401¥M0001.map」,…,「¥MAP¥D1606¥D0401¥M0707.map」で表される。
【0052】
さらに、ユニットU1を親ユニットPUとするユニットUのグループは、「¥MAP¥D1606¥D0401¥D0503」と表されるサブディレクトリの直下のディレクトリ(論理領域)に格納される。かかるグループに属するユニットU0は、ユニットU1が64分割されたユニットUの内、位置コード「0201」に該当するユニットである。そのため、ユニットU0のパスは、「¥MAP¥D1606¥D0401¥D0503¥M0201.map」と表される。同様に、ユニットU1を親ユニットPUとするレベル「0」の各ユニットのパスは、「¥MAP¥D1606¥D0401¥D0503¥M0000.map」,「¥MAP¥D1606¥D0401¥D0503¥M0001.map」,…「¥MAP¥D1606¥D0401¥D0503¥M0707.map」で表される。
【0053】
以上、地図ファイルCFにより実現される階層構造およびファイル名について説明した。ここで、以上のユニットUがデジタルデータ化され、必要な管理情報が付加されることにより、1つの地図ファイルCFが構成される(詳細は図7を参照)。以下の説明において、ユニットデータは、ユニットUをデジタルデータ化したものを意味する。つまり、1つの地図ファイルCFには、1つのユニットデータが含まれる。次に、地図ファイルCFのデータ構造について詳細に説明する。
【0054】
「地図ファイルCFのデータ構造」
図6は、1つの地図ファイルCFを基に描かれる地図を説明するための図である。また、図7は、1つの地図ファイルCFのデータ構造を示している。図7において、地図ファイルCFは、大略的に、ユニットヘッダとユニットデータとから構成される。まず、ユニットデータから説明する。一般的に、地図は、用途に応じて、図7に示すように、背景、道路、地図記号および文字から構成される。しかし、地図ファイルCFは、主として、端末装置1のディスプレイ上への表示、マップマッチングまたは経路探索処理に使用される。例えば、経路探索処理では、道路のつながりが分かればよく、背景の必要性は薄い。そこで、1つのユニットデータは、図6に示すように、文字記号データと、道路ネットワークデータと、背景データとに分けてデータ化される。これによって、文字記号データ、道路ネットワークデータおよび背景データはそれぞれ、独立的に使用することができる。文字記号データとは、ユニットUがカバーする地図に記載されるべき文字列(地名および交差点名称等)からなるデータと、当該地図に記載されるべき地図記号からなるデータとを意味する。道路ネットワークデータとは、ユニットUがカバーする地図に表されるべき道路そのものおよび道路同士のつながりを表す図形データを意味する。背景データとは、水系、山系、建造物等、ユニットUがカバーする地図に表されるべき背景を表す図形データを意味する。背景の例としては、河川、湖、山、緑地帯、鉄道、建造物、橋、公園がある。以上の文字記号データ、道路ネットワークデータおよび背景データを重ねあわせて表示することにより、図6に示すように、ユニットデータは、背景、道路、地図記号および文字を表すことができる。
【0055】
次に、背景データの詳細なデータ構造を、図7および図8を参照して説明する。図7に示すように、背景データは、基本背景テーブルおよび詳細背景テーブルから構成される。基本背景テーブルは、図8(a)から明らかなように、河川、鉄道および緑地帯等、地図の背景を表示する際に概略となる図形データを集合である。一方、詳細背景テーブルは、図8(b)から明らかなように、橋および建造物等、地図の背景をより詳細に表示するための図形データの集合である。これら基本背景テーブルおよび詳細背景テーブルは、図7から明らかなように、ユニットデータにおいて互いに別々に記録される。さらに、基本背景テーブルおよび詳細背景テーブルには、相互に参照し合うような情報は記録されない。つまり、基本背景テーブルを構成する背景データを描いている際に、詳細背景テーブルの背景データは何一つ参照されない。逆に、詳細背景テーブルを構成する背景データを描いている際に、基本背景テーブルの背景データは何一つ参照されない。このように、基本背景テーブルおよび詳細背景テーブルは、相互に独立したデータ構造を有する。したがって、背景をディスプレイ上に表示する場合には、図8(a)に示すように、基本背景テーブルのみで表される背景を表示することが可能になる。これによって、端末装置1のユーザは、概略的な地図を見ることが可能になる。また、図8(c)に示すように、基本背景テーブルおよび詳細背景テーブルで表される背景を表示することもできる。この場合、所定の原点を基準として、基本背景テーブルから得られる概略的な背景の上に、詳細背景テーブルから得られる詳細な背景を重ねあわせることとなる。これによって、端末装置1のユーザは、詳細な地図を見ることが可能となる。なお、本実施形態では、背景データは基本背景テーブルおよび詳細背景テーブルとから構成されるとして説明したが、第1の記憶装置19または第2の記憶装置24に記憶容量の制限がある場合等には、第1のデータベース111または第2のデータベース25を小さいサイズにする観点から、背景データは基本背景テーブルのみから構成されてもよい。逆に、本実施形態で説明したように、背景データは基本背景テーブルおよび詳細背景テーブルとから構成される場合には、センタ局2は、詳細な地図を端末装置1に提供することが可能となり、当該端末装置1は詳細な地図をディスプレイに表示できるようになる。
【0056】
上述の基本背景テーブルおよび詳細背景テーブルの内部のデータ構造は互いに同じである。以下には、基本背景テーブルおよび詳細背景テーブルを背景テーブルと総称して、双方のデータ構造についてより詳細に説明する。
上述したように、背景テーブルは、地図の背景をディスプレイ上に描画するために使用される図形データの集合である。各図形データによって、河川、公園、工場および鉄道等がディスプレイ上に描画される。以下、これら地図の背景の要素となる、河川、公園、工場および鉄道等を総称して「描画オブジェクト」と呼ぶこととする。ここで、図9は、描画オブジェクトの概念を示す図である。上述から明らかなように、描画オブジェクトは、公園または工場等のように、それ自体で意味のあるひとまとまりの対象物を表し、データ構造としては、対象物を折れ線で描画するための要素点の並びから構成される。例えば、図9には、矩形領域のユニットUが示されている。ユニットUがカバーする範囲には、2つの描画オブジェクトDO1およびDO2が存在する。描画オブジェクトDO1は、オブジェクトOBJ1とO2とから構成される。オブジェクトOBJ1は、要素点a→要素点b→要素点c→要素点d→要素点e→要素点aの順番に一筆書きした時に作成される折れ線で囲まれる領域である。また、オブジェクトOBJ2は、要素点f→要素点g→要素点h→要素点i→要素点fの順番に一筆書きした時に描かれる折れ線で囲まれる領域である。また、描画オブジェクトDO2は、オブジェクトOBJ3から構成される。オブジェクトOBJ3は、要素点j→要素点k→要素点l→要素点m→要素点n→要素点jの順番に一筆書きした時に描かれる折れ線で囲まれる領域である。以上から明らかなように、本実施形態の描画オブジェクトは、複数の要素点を一筆書きして得ることができる1つ以上のオブジェクトにより表される。
【0057】
ここで、図10は、背景テーブル、つまり基本背景テーブルまたは詳細背景テーブルの詳細なデータ構造を示す図である。図10において、背景テーブルには、背景レコード数Mと、M個の背景レコードBR1〜BRMとから構成される。ここで、Mは、1以上の自然数である。背景レコード数Mは、背景テーブルに含まれる背景レコードBR1〜BRMの個数を示す情報である。また、背景レコードBR1は、背景属性と、オブジェクト数Nと、オブジェクトOBJ1〜ONの要素点数N1〜NNと、オブジェクトレコードOR1〜ORNとから構成される。
背景属性は、背景レコードBR1内に含まれる各オブジェクトOBJにより表される背景の属性を示す情報である。より具体的には、背景属性は、背景レコードBR1内に含まれる各オブジェクトOBJのカラーコードおよびテクスチャーマッピングコードである。ここで、本実施形態の一つの特徴として、背景属性には、1つのカラーコードまたはテクスチャマッピングコードのみが記述される。つまり、例えば、「青」を示すカラーコードと、「赤」を示すカラーコードとが一緒に背景属性に記述されることはない。「青」を示すカラーコードのみ、または「赤」を示すカラーコードのみが背景属性に記述される。
【0058】
また、オブジェクト数Nは、背景レコードBR1内に含まれるオブジェクトOBJの数を示す情報である。また、要素点数N1は、オブジェクトOBJ1を構成する要素点の数を示している。要素点数N2は、オブジェクトOBJ2を構成する要素点の数を示している。以降、同様に、要素点数NNは、オブジェクトOBJNの要素点の数を示す。このように、背景レコードBR1には、そこに含まれるN個のオブジェクトOを構成する要素点の数が並ぶ。ここで、Nは1以上の自然数である。
【0059】
さらに、オブジェクトレコードOR1は、1つのオブジェクトOBJ1を構成する要素点の座標を示す情報である。ここで注意を要するのは、オブジェクトOBJ1は複数の要素点を含むので、オブジェクトレコードOR1には複数の座標情報が並ぶこととなる。つまり、オブジェクトレコードOR1には座標列の情報が記述される。ここで、上述から明らかなように、オブジェクトレコードOR1には、要素点数N1に相当する個数の座標情報が記述される。また、オブジェクトレコードOR2は、オブジェクトOBJ2を構成する要素点の座標列を示す情報である。オブジェクトレコードOR2には、要素点数N2に相当する個数の座標情報が記述される。以降、同様に、オブジェクトレコードORNは、オブジェクトOBJNを構成するNN個の要素点の座標列を示す情報である。オブジェクトレコードORNには、要素点数NNに相当する個数の座標情報が記述される。
【0060】
以上のように、各オブジェクトレコードORには、オブジェクトOBJを構成する要素点の座標列が記述される。座標列の表現方法としては、ユニットU内での絶対座標で表現する方法と、ある要素点の座標と直前の要素点の座標との差分を用いた相対座標で表現する方法とがある。絶対座標は、ユニットU内の所定の原点を基準とした各要素点の座標であるため、多くのビット数を必要とする。そのため、座標列の表現方法として、相対座標が使用されることが、地図ファイルCFのデータサイズを小型化する観点から、好ましい。以下、絶対座標と相対座標とについて、詳細に説明する。
【0061】
図11は絶対座標が多くのビット数を必要とすることを説明するための図である。図11には、8個の要素点P0〜P7で構成される図形データが示されている。要素点P0の絶対座標は、予め定められた原点を基準として、(X0,Y0)である。以降、同様に、要素点P1〜P7の絶対座標は、(X1,Y1)〜(X7,Y7)である。また、図12は、以上のP0〜P7の各絶対座標情報をオブジェクトレコードORに記述した時の図である。今、要素点P0〜P7の絶対座標は、東経方向(x軸方向)および北緯方向(y軸方向)それぞれについて、例えば2バイトで表現すると、P0〜P7の各絶対座標情報をオブジェクトレコードORに記述するためには、32バイトが必要となる。
【0062】
一方、図13は、図11と同じ図形データの各要素点P0〜P7を相対座標で表現した時の図である。図13において、図形データは、要素点P0→P1→P2→P3→P4→P5→P6→P7の順番で一筆書きされる。相対座標表現であっても、一筆書きされる最初の要素点P0は、絶対座標表現と同様に、所定の原点を基準として、(X0,Y0)で表される。ただし、次の要素点P1は、絶対座標表現の場合には、(X1,Y1)と表される。しかし、相対座標表現では、要素点P1は(ΔX1,ΔY1)で表される。ここで、ΔX1は、ΔX1=X1-X0である。また、ΔY1は、ΔY1=Y1-Y0である。以降の要素点P2〜P7も、それぞれの要素点の絶対座標と、直前の要素点の絶対座標との差分により表現される。
図14は、以上の要素点P0〜P7の各相対座標情報をオブジェクトレコードORに記述した時のデータ構造を示す図である。ここで注意を要するのは、相対座標表現は、それぞれの要素点の絶対座標と、直前の要素点の絶対座標との差分で表されるため、ΔX1≪X1,ΔX2≪X2,…ΔX7≪X7となる。同様に、ΔY1≪Y1,ΔY2≪Y2,…ΔY7≪Y7となる。そのため、要素点P1〜P7の相対座標は、東経方向(x軸方向)および北緯方向(y軸方向)それぞれについて2バイトで表現するのではなく、それぞれ1バイトで表現する。その結果、要素点P1〜P7の各相対座標情報をオブジェクトレコードORに記述するためには、14バイトが必要となる。ただし、最初の要素点P0は、絶対座標で記述される必要があるので、要素点P0〜P7の各座標情報をオブジェクトレコードORに記述するためには、差分数(「7」)の情報を含めて、19バイトが必要となる。
【0063】
以上、図11〜図14を参照して説明したように、オブジェクトOBJを構成する各要素点Pを相対座標を使って表現すると、絶対座標表現のみを用いた場合と比較して、オブジェクトレコードORのサイズが小さくなる。しかしながら、オブジェクトOBJを構成する各要素点を無条件に相対座標で表現すると、データサイズの小型化を実現できない場合が生じるという問題点が想定できる。かかる問題点を、図15を参照して説明する。図15には、要素点P0、P1およびPnで構成されるオブジェクトOBJが示されている。今、要素点P1は、相対座標では(ΔX1,ΔY1)で表される。ΔX1およびΔY1の双方は、1バイトで表現できるとする。同様に、要素点Pnは、相対座標では(ΔXn,ΔYn)で表される。しかしながら、ΔXnおよび/またはΔYnは、要素点Pnが直前の要素点P1から離れた位置にあるため、1バイトでは表現しきれない値であると仮定する。このような場合、図16に示すように、要素点P1およびPnを結ぶ直線上に、新しい要素点P2およびP3を作成する必要が生じる。これによって、要素点Pnの相対座標は、直前の要素点P3の絶対座標を基に、(ΔX4,ΔY4)で表すことができる。ΔX4およびΔY4は、要素点P3が要素点P1と比べて要素点Pnの近くに位置するため、1バイトで表現できる。以上の要素点P0,P1,P2,P3およびPnの各相対座標情報をオブジェクトレコードORに記述すると、図17に示すように、13バイト必要となる。
【0064】
以上、図15〜図17を参照して説明したように、2個の要素点Pが離れて位置している場合には、新しい要素点Pを補う必要が生じる。その結果、オブジェクトレコードORには、補った要素点Pの相対座標情報を記述しなければならない。このように、最初の要素点Pを除くすべての要素点Pを相対座標で表現しようとすると、要素点Pの数が不必要に多くなり、オブジェクトレコードORのデータサイズが不必要に大きくなるという問題点が顕在化してくる。そこで、図15の要素点P0およびPnを絶対座標で表現し、要素点P1を要素点P0を基準とした相対座標で表現することが有効となる。今、要素点Pnの絶対座標は、4バイトで表現できる(Xn,Yn)であると仮定して、要素点P0,P1およびPnの各座標情報をオブジェクトレコードORに記述すると、図18に示すようになる。図18において、要素点P0およびPnの絶対座標情報はそれぞれ4バイトであり、要素点P1の相対座標情報は2バイトである。さらに、絶対座標で表されたP0およびPnを基準として、いくつの相対座標が作成されているかを示す差分数の情報は2バイトである。以上の合計をとると、オブジェクトレコードORのデータサイズは12バイトとなる。このデータサイズは、相対座標だけで表現した場合のオブジェクトレコードORのデータサイズ13バイト(図17参照)よりも小さい。
【0065】
以上、図18を参照して説明したように、その直前の要素点と離れて位置する要素点は絶対座標で表現される。このように、本実施形態では、ある要素点は、主として相対座標で表現されるが、他の要素点は絶対座標で表現される。これによって、オブジェクトレコードORのデータサイズをより小さくすることが可能となる。
【0066】
また、上述したように、本実施形態では、オブジェクトの境界にも、相対座標表現が適用される。ここで、オブジェクトの境界とは、あるオブジェクトOBJを構成する1つの要素点Pからペンアップして、他のオブジェクトOBJを構成する1つの要素点Pにペンダウンする部分を意味する。かかる相対座標表現の適用によって、本実施形態は、背景テーブルのデータサイズを小型化できるという技術的効果を奏する。以下には、まず、かかる技術的効果を明確にするために、オブジェクトの境界に相対座標表現が適用されない場合について、図19および図20を参照して説明する。図19には、描画オブジェクトDO3が示されている。描画オブジェクトBO3は、オブジェクトOBJ3およびOBJ4から構成される。オブジェクトOBJ3は、6個の要素点P0〜P5から構成される。また、オブジェクトOBJ4は、4個の要素点P6〜P9から構成される。
【0067】
以上のオブジェクトOBJ3は、要素点P0→P1→P2→P3→P4→P5→P0という順番で一筆書きされる。その後、要素点P0でペンアップが行われ、要素点P6でペンダウンが行われる。そして、オブジェクトOBJ4は、要素点P6→P7→P8→P9→P6という順番で一筆書きされる。この時、オブジェクトの境界で相対座標が適用されないと仮定すると、要素点P0〜P5および要素点P6〜P9を表す座標のデータ構造は、図20に示すようになる。図20において、最初に、オブジェクトOBJ3の基準点となる要素点P0の絶対座標(X0,Y0)が4バイトで記述される。オブジェクトOBJ3の描画時には、要素点P0にベンダウンした後ペンアップするまでに、要素点P1〜P5を辿ることになるので、差分数(つまり相対座標の個数)は、5個となり、1バイトの情報である。今、要素点P1〜P5の相対座標は、前述と同様に2バイトで表され、(ΔX1,ΔY1)〜(ΔX5,ΔY5)である。また、オブジェクトの境界部分に相対座標が適用されないので、要素点P5の相対座標の後には、オブジェクトOBJ4の基準点となる要素点P6の絶対座標(X1,Y1)が4バイトで記述される。オブジェクトOBJ4の描画時には、要素点P6にペンダウンした後ペンアップするまでに、要素点P7〜P9を辿ることになるので、差分数(相対座標の個数)は、3個となり、1バイトの情報である。要素点P7〜P9の相対座標は、(ΔX6,ΔY6)〜(ΔX8,ΔY8)であり、2バイトで表される。したがって、両オブジェクトの境界に相対座標を適用することなく、オブジェクトOBJ3およびOBJ4を相対座標列は、26バイトで表現される。
【0068】
次に、オブジェクトの境界に相対座標表現が適用される場合について、図21および図22を参照して説明する。図21には、図19と同様に、2個のオブジェクトOBJ3およびOBJ4から構成される描画オブジェクトDO3が示されている。描画オブジェクトDO3は、要素点P0→P1→P2→P3→P4→P5という順番で一筆書きされる。その後、要素点P5から要素点P6へのペンアップおよびペンダウンが行われた後、描画オブジェクトDO3は、要素点P6→P7→P8→P9→P6という順番で一筆書きされる。ただし、描画時においては、一筆書きの開始点とペンアップした点とは必ず結ぶという原則があるので、要素点P5および要素点P0は線で結ばれる。以上の描画時において、オブジェクトの境界で相対座標が適用されると仮定すると、要素点P0〜P5および要素点P6〜P9を表す座標のデータ構造は、図22に示すようになる。図22において、最初に、オブジェクトOBJ3の基準点となる要素点P0の絶対座標(X0,Y0)が4バイトで記述される。描画オブジェクトDO3の描画時には、要素点P0から一筆書きを開始から終了までに、要素点P1〜P9を辿ることになるので、相対座標の個数、つまり差分数は、1バイトのデータであって、「9個」を示す。今、要素点P1〜P9の相対座標は、前述と同様に2バイトで表され、(ΔX1,ΔY1)〜(ΔX9,ΔY9)である。したがって、両オブジェクトの境界に相対座標を適用する場合には、オブジェクトOBJ3およびOBJ4を相対座標列は、23バイトで表現される。
【0069】
以上、図19〜図22を参照して説明したように、オブジェクトの境界に相対座標を適用すると、それを適用しない場合と比較して、背景テーブルのデータサイズを小型化することができる。
【0070】
ここで注意を要するのは、図20においてはオブジェクトの境界は、オブジェクトレコードORに記述された絶対座標により分かる。しかし、図22においては、オブジェクトの境界は、絶対座標からは見つけることはできない。図21に示すように、オブジェクトの境界を規定するペンアップする要素点Pおよびペンダウンする要素点Pはそれぞれ相対座標で示される場合があり、さらには、図18に示したように2点間の距離が離れている場合には、要素点Pが絶対座標で表現される場合があるからである。しかしながら、図22において、オブジェクトの境界は、図10に示された要素点数N1〜要素点数NNを参照すれば正確に規定できる。つまり、本実施形態では、要素点数N1〜要素点数NNはそれぞれ、ペンダウンしてからペンアップするまでに一筆書きで辿る要素点の個数を意味する。したがって、実際の描画時において、オブジェクトレコードORの先頭から座標の個数をカウントし、カウント値が要素点数N1と同じであれは、最初のオブジェクトの境界を正確に特定することができる。同様に、カウント値が要素点数N1およびN2の加算値と同じであれは、2回目のオブジェクトの境界を特定することができる。以降、同様に、カウント値が要素点数N1〜NNの加算値と同じであれは、N回目のオブジェクトの境界を特定することができる。
【0071】
「文字記号データの詳細なデータ構造」
次に、図7に示す文字記号データについて説明する。なお、文字記号データは本願発明の特徴的な事項ではないため、簡単に説明する。文字記号データとは、前述したように、ユニットUがカバーする地図に記載されるべき文字列(地名、道路名称および交差点名称等)からなるデータと、当該地図に記載されるべき地図記号からなるデータとを意味する。さらに、文字記号データは、図7に示すように、基本文字記号テーブルと詳細文字記号テーブルとから構成される。基本文字記号テーブルは、ユニットUがカバーする地図に記載される文字列または地図記号の内、基本的な文字列および地図記号を表すデータを集合である。より具体的には、基本文字記号テーブルには、図23(a)から明らかなように、河川名称、道路名称および地図記号等、ユニットUがカバーする地図を表示する際に概略となる文字列および地図記号とが記録される。一方、詳細文字記号テーブルは、ユニットUがカバーする地図に記載される文字列または地図記号の内、基本文字記号テーブルには記録されない文字列および地図記号を表すデータを集合である。より具体的には、詳細文字記号テーブルには、図23(b)から明らかなように、公園、鉄道、橋および工場の名称等、ユニットUがカバーする地図をより詳細に表示するための文字列および地図記号とが記録される。
【0072】
ここで、本実施形態の端末装置1としては、上述したようにカーナビゲーションシステムが想定されている。かかる事情から、基本文字データテーブルには、カーナビゲーションに重要な河川名称、道路名称および地図記号等が記録されると説明した。しかし、他の用途の端末装置1も想定できる。そのため、基本文字記号テーブルにどのような文字列および地図記号が記録されるか、また、詳細文字記号テーブルにどのような文字列および地図記号が記録されるかについては、端末装置1の用途に依存する。それゆえに、本願発明の技術範囲は、基本文字記号データテーブルには、河川名称、道路名称および地図記号等が記録される、というように限定解釈されてはならない。
【0073】
さて、以上の基本文字記号テーブルおよび詳細文字記号テーブルは、図7から明らかなように、ユニットデータにおいて互いに別々のフィールドに記録される。さらに、基本文字記号テーブルおよび詳細文字記号テーブルには、相互に参照し合うような情報は一切記録されない。つまり、基本文字記号テーブルを構成する文字列または地図記号を描いている際に、詳細文字記号テーブルの文字列または地図記号は何一つ参照されない。逆に、詳細文字記号テーブルを構成する文字列および地図記号を描いている際に、基本文字記号テーブルの文字列および地図記号は何一つ参照されない。このように、基本文字記号テーブルおよび詳細文字記号テーブルは、相互に独立したデータ構造を有する。したがって、文字列および地図記号をディスプレイ上に表示する場合には、図23(a)に示すように、基本文字記号テーブルのみで表される文字列および地図記号を表示することが可能になる。これによって、端末装置1のユーザは、概略的な地図を見ることが可能になる。また、図23(c)に示すように、基本文字記号テーブルおよび詳細文字記号テーブルそれぞれを構成する文字列および地図記号を表示することもできる。この場合、所定の原点を基準として、基本文字記号テーブルから得られる概略的な文字列および地図記号に、詳細文字記号テーブルから得られる文字列および地図記号を重ねあわせることとなる。これによって、端末装置1のユーザは、詳細な地図を見ることが可能となる。なお、本実施形態では、文字記号データは基本文字記号テーブルおよび詳細文字記号テーブルとから構成されるとして説明したが、第1の記憶装置19または第2の記憶装置24に記憶容量の制限がある場合等には、第1のデータベース111または第2のデータベース25を小さいサイズにする観点から、文字記号データは基本文字記号テーブルのみから構成されてもよい。逆に、本実施形態で説明したように、文字記号データは基本文字記号テーブルおよび詳細文字記号テーブルとから構成される場合には、センタ局2は、詳細な地図を端末装置1に提供することが可能となり、当該端末装置1は詳細な地図をディスプレイに表示できるようになる。
【0074】
上述の基本文字記号テーブルおよび詳細文字記号テーブルの内部のデータ構造は互いに同じである。以下には、基本文字記号テーブルおよび詳細文字記号テーブルを文字記号テーブルと総称して、双方のデータ構造についてより詳細に説明する。
【0075】
上述したように、文字記号テーブルは、ユニットUがカバーする地図上の文字列および地図記号をディスプレイ上に表すためのデータの集合である。ここで、図24は、文字記号テーブル、つまり基本文字記号テーブルまたは詳細文字記号テーブルの詳細なデータ構造を示す図である。図24において、文字記号テーブルは、文字記号レコード数Pと、P個の文字記号レコードTSR1〜TSRPとから構成される。文字記号レコード数Pは、文字記号テーブルに含まれる文字記号レコードTSR1〜TSRPの個数を示す情報である。ここで、Pは、1以上の自然数であって、ユニットUがカバーする地図上の文字列および地図記号の総数である。文字記号レコードTSR1〜TSRPは、ユニットUがカバーする地図上の文字列または地図記号の数だけ作成される。文字記号レコードTSR1は、文字記号属性と、ポイント座標と、文字記号コードとから構成される。
【0076】
文字記号属性は、文字記号レコードTSR1により表されるべき文字列または地図記号の属性を示す情報である。文字記号属性には、文字列または当該地図記号のサイズと、文字列が並ぶ方向(縦/横)とを示す情報が記録される。ここで注意を要するのは、地図記号は、複数の記号により1つの対象物を表すことがほとんどなく、さらに、1つの文字で表される地名もある。かかる場合には、文字列が並ぶ方向(縦/横)を示す情報が文字記号属性に記録される必要性は特にない。ポイント座標は、文字記号レコードTSR1により表されるべき文字列または地図記号がユニットU上のどの位置に表示されるかを特定するための座標情報である。文字記号レコードTSR1により表されるべき文字列等は、ディスプレイ上において、ポイント座標により特定される位置に表示される。また、文字記号コードは、文字記号レコードTSR1により表されるべき文字列および地図記号のコード番号である。文字列のコード番号としては、日本国ではシフトJISコードが典型的であり、文字記号属性に記録された文字列の大小を表すサイズに該当する情報が記録される。ここで、地図記号は、シフトJIS等のように、それに関連する規格がないので、独自に作成される。さらに、作成された地図記号のコード番号としては、日本国ではシフトJISの空きコード番号が割り当てられる。割り当てられたコード番号が、文字記号コードとして記録される。
なお、他の文字記号レコードTSR2〜TSRPは、文字記号レコードTSR1と同様のデータ構造を有するので、それぞれの説明を省略する。
【0077】
「道路ネットワークデータの詳細なデータ構造」
次に、図7に示す道路ネットワークデータについて説明する。道路ネットワークデータは、カーナビゲーションシステムとしての端末装置1において、ディスプレイ上に道路を表示するために使用されるだけでなく、マップマッチング、経路探索処理または経路案内処理にも使用される。そのため、道路ネットワークデータは、前述したように、ユニットUがカバーする地図に表されるべき道路そのものを表す図形データ、および道路同士のつながりを表すデータの集合を意味する。より具体的には、道路ネットワークデータはマップマッチング等に使用されるため、当該道路ネットワークデータには、単に、道路網の形状を表す図形データが記録されるだけではなく、ユニットUがカバーする範囲の地図に表される道路同士の接続関係を示すデータも記録される。
【0078】
以上の道路ネットワークデータは、図7に示すように、第1のネットワークデータと第2のネットワークデータとから構成される。第1のネットワークデータには、主要幹線道路の道路ネットワークデータが記録される。主要幹線道路とは、例えば、以下の3つの条件のいずれかを満たすものを意味する。まず、第1の条件は、地方自治体およびそれよりも上位の行政機関が造った道路(高速道路、国道)であることである。第2の条件は、地方自治体よりも下位の行政機関が造った道路(高速道路、国道)および私道であって、かつその幅員が5.5m以上の道路であることである。第3の条件は、上記第1および第2の条件に該当する道路に接続された道路であることである。また、第2のネットワークデータには、細街路の道路ネットワークデータが記録される。細街路とは、その幅員が3.0m以上であって、主要幹線道路に該当しない道路(例えば、住宅の周辺に造られた道路)を意味する。ただし、上記の主要幹線道路および細街路の定義は単なる一例であって、他の定義を採用しても構わない。それゆえに、本願発明の技術範囲は、第1および第2の道路ネットワークデータには、上記定義にのみ該当する道路ネットワークデータが記録される、というように限定解釈されてはならない。
【0079】
次に、第1の道路ネットワークデータおよび第2の道路ネットワークデータの関係について、図25を参照して説明する。第1の道路ネットワークデータは、主要幹線道路の道路ネットワークデータである。そのため、第1の道路ネットワークデータが端末装置1のディスプレイに表示されると、図25(a)に示すように、主要幹線道路を表す図形が表示される。一方、第2の道路ネットワークデータは、細街路の道路ネットワークデータである。そのため、第2の道路ネットワークデータが端末装置1のディスプレイに表示されると、図25(b)に示すように、細街路を表す図形が表示される。これら第1および第2の道路ネットワークチータは、図7から明らかなように、ユニットデータにおいて互いに別々に記録される。したがって、図25(a)に示すように、第1の道路ネットワークデータを構成する主要幹線道路のみを端末装置1のディスプレイに表示することが可能になる。これによって、端末装置1のユーザは、概略的な道路ネットワークを見ることが可能になる。また、図25(c)に示すように、第1および第2の道路ネットワークデータを構成する主要幹線道路および細街路を表示することもできる。この場合、所定の原点を基準として、第1の道路ネットワークデータから得られる主要幹線道路網の上に、第2の道路ネットワークデータから得られる細街路の道路網を重ねあわせることとなる。これによって、端末装置1のユーザは、詳細な道路網を見ることが可能となる。なお、本実施形態では、道路ネットワークデータは、第1および第2の道路ネットワークデータから構成されるとして説明したが、第1の記憶装置19または第2の記憶装置24に記憶容量の制限がある場合等には、第1のデータベース111または第2のデータベース25を小さいサイズにする観点から、道路ネットワークデータは、第1の道路ネットワークデータのみから構成されてもよい。逆に、本実施形態で説明したように、道路ネットワークデータが第1および第2の道路ネットワークデータから構成される場合には、センタ局2は、詳細な道路網を端末装置1に提供することが可能となり、当該端末装置1は詳細な道路網をディスプレイに表示できるようになる。
【0080】
上述の第1および第2の道路ネットワークデータのデータ構造は互いに同じである。以下には、第1および第2の道路ネットワークデータのデータ構造についてより詳細に説明する。
周知のように、道路ネットワークデータは、主として、ノードとリンクにより構成される。ノードとは、主として、交差点または道路の区切りを表現するためのデータを意味する。また、リンクとは、2個の交差点の間をつなぐ道路を表現するためのデータである。かかるノードとリンクを用いることにより、ユニットUがカバーする地図上に表されるべき道路(主要幹線道路または細街路)の形状および道路同士の接続関係が端末装置1のディスプレイ上に表示される。そのため、図7に示すように、第1の道路ネットワークデータは、第1のノードテーブルおよび第1のリンクテーブルから構成され、第2の道路ネットワークデータは、第2のノードテーブルおよび第2のリンクテーブルから構成される。以下には、まず、第1および第2のノードテーブルのデータ構造をまず説明する。
【0081】
ここで、図26は、ノードおよびリンクの概念を説明するための図である。図26には、1つのユニットUがカバーする範囲に存在する道路網が示されている。図26の道路網は、11個のノードN0〜N10と、11個のリンクL0〜L10とから構成される。11個のノードN0〜N10は、非隣接ノードと隣接ノードとに大別される。非隣接ノードとは、通常の交差点、もしくは道路の種別または属性が変わる点(上述の道路の区切りに相当する)に作成されるノードであり、ユニットU内での道路の接続関係を表す分岐点を意味する。ところで、図26のユニットUには、同じレベルに属しかつ隣接するユニットUがいくつかある(図2参照)。したがって、1本の道路が、互いに隣り合う複数のユニットUにまたがる場合がある。以下では、図26のユニットUに隣接するユニットUのことを、便宜上、隣接ユニットNUと称する。図26には、隣接ユニットNUの1つが点線にて示されている。隣接ノードは、図26のユニットUおよび隣接ユニットNUの間をまたがる道路が存在する場合に、当該ユニットUの境界(つまり矩形領域の辺)上に作成されるノードであり、当該ユニットUと隣接ユニットNUとの道路の接続関係を表す点を意味する。以上の定義に従うと、図26のノードN1、N2、N5およびN8の4つ(○印参照)が非隣接ノードに分類される。また、ノードN0、N3、N4、N6、N7、N9、N10の7つ(●印参照)が隣接ノードに分類される。ここで注意を要するのは、交差点または道路の区切りを表すノードNがユニットUの境界上に存在する場合には、当該ノードNを隣接ノードと分類するか、非隣接ノードと分類するかが問題となる。かかる場合、交差点または道路の区切りを表すノードNを境界上からずらして、新しい非隣接ノードを作成することが1つの対処方法である。他の対処方法として、ユニットUの境界上の交差点または道路の区切りと同じ座標上に非隣接ノードを作成することがある。以上から明らかなように、ユニットUの境界上には隣接ノードが作成されてはならない。
【0082】
図27は、第1のノードテーブルの詳細なデータ構造を示す図である。ここで、予め断っておくが、第1および第2のノードテーブルは、互いに同様のデータ構造を有しており、主要幹線道路および細街路について作成される点で相違する。そのため、説明の簡素化の観点から、第2のノードテーブルの詳細な説明を省略する。さて、図27において、第1のノードテーブルは、隣接ノード数Qと、非隣接ノード数Rと、(Q+R)個のノードレコードNR1〜NR(Q+R)とから構成される。隣接ノード数Qは、第1のノードテーブルに含まれる隣接ノードの個数を示す情報である。ここで、Qは、1以上の自然数であって、ユニットUにより表される地図上の道路網に隣接ノードがいくつ存在するかを示す。非隣接ノード数Rは、第1のノードテーブルに含まれる非隣接ノードの個数を示す情報である。ここで、Rは、1以上の自然数であって、ユニットUにより表される地図上の道路網に非隣接ノードがいくつ存在するかを示す。
【0083】
ノードレコードNR1〜NR(Q+R)は、ユニットUにより表される地図上の道路網に存在するノードNの数だけ作成される。ノードレコードNR1〜NR(Q+R)には、(Q+R)個のノードNに関連する情報が記録される。
次に、本実施形態におけるノードレコードNR1〜NR(Q+R)の並べ方について説明する。第1のノードテーブルにおいて、最初のQ個のノードレコードNR1〜NRQには、Q個の隣接ノードに関連する情報が記録され、後のR個のノードレコードNR(Q+1)〜NR(Q+R)には、R個の非隣接ノードに関連する情報が記録される。
また、Q個のノードレコードNR1〜NRQにおいて、先頭から順番に、矩形領域(ユニットU)の左辺上に存在する隣接ノード(図26の▲1▼参照)に関連する情報が記録される。次に、矩形領域の上辺上に存在する隣接ノード(図26の▲2▼参照)に関連する情報が記録される。次に、矩形領域の右辺上に存在する隣接ノード(図26の▲3▼参照)に関連する情報が記録される。最後に、矩形領域の下辺上に存在する隣接ノード(図26の▲4▼参照)に関連する情報が記録される。
また、上記上辺上または下辺上の隣接ノードのノードレコードNRは、当該隣接ノードの緯度が昇順になるよう並べられる。一方、上記右辺上または左辺上の隣接ノードのノードレコードNRは、当該隣接ノードの経度が昇順になるよう並べられる。
【0084】
さらに、非隣接ノードのノードレコードNRは、最初に、当該非隣接ノードの緯度が昇順になるように並べられる。この時、同じ緯度の非隣接ノードが複数存在した場合には、ノードレコードNRは、当該非隣接ノードの経度が昇順になるように並べられる。
【0085】
図26のノードN0〜N10に関して、上記の並べ方に従うと、図28に示すように、先頭のノードレコードNR1には、隣接ノードN6の情報が記録される。次のノードレコードNR2には、隣接ノードN0の情報が記録される。ノードレコードNR3、NR4、NR5、NR6およびNR7には、隣接ノードN4、N7、N10、N3およびN9の情報が記録される。ここで、図28中の▲1▼〜▲4▼は、図26の▲1▼〜▲4▼に対応しており、隣接ノードが並べられる順位を示している。次のノードレコードNR8には、非隣接ノードN8の情報が記録される。ノードレコードNR9、NR10およびNR11には、非隣接ノードN5、N2およびN1の情報が記録される。以上のように、本実施形態では、ユニットUに含まれるノードNの情報は、ランダムにではなく、上述した規則に従った順番でノードレコードNRに記録されていく。ここで、以下の説明において、ノードレコード番号とは、最初のノードレコードNR1を「0」として、各ノードレコードNR2以降が何番目に記録されているかを特定する番号を意味する。以上のノードレコード番号を図28のノードレコードNR1〜NR11に当てはめると、当該ノードレコードNR1〜NR11のノードレコード番号は「0」〜「10」となる。なお、以上のような並べ方は、ユニットUと隣接ユニットNUの間にまたがる道路の接続関係をたどる処理を高速に行ったり、ユニットUの親子間におけるノードやリンクの対応づけを的確に行ったりできるという効果を生むが、これらの具体的な処理および効果については後述する。
【0086】
さて、再度図27を参照して、ノードレコードNR1の内部データ構造を詳細に説明する。ノードレコードNR1は、ノード属性と、ノード座標と、ノード接続情報とから構成される。ノード属性は、ノードレコードNR1に記録されるノードの属性を表すための情報である。ノード属性の例としては、記録されたノードに交差点での交通が規制されているか否かを示す情報、当該ノードにより表される交差点に名称があるか否かを示す情報、当該ノードにより表される交差点に信号機が存在するか否か等の情報がある。なお、ノード属性に交通規制または交差点名称の有無に関する情報を記録する場合には、本実施形態では説明しない交差点規制テーブルおよび交差点名称テーブル等のテーブルを別途作成し、該当する情報を記録するようにする。
【0087】
また、ノード座標は、ノードレコードNR1に記録されるノードの経度方向の座標および緯度方向の座標を表すための情報である。ノードの経度方向の座標および緯度方向の座標としては、絶対経度緯度座標を記録しても良いが、記録されるノードを含むユニットU(矩形領域)の左下隅を基準点として、当該ユニットUがカバーする範囲の経度幅および緯度幅を2バイト程度の値で正規化した座標で表すのが一般的である。例えば、図29に示すように、ユニットUの左下隅Naの座標を(0000h,0000h)と表現し(hは16進数の値を表す)、当該ユニットUの座標系を経度方向および緯度方向共に8000hで正規化する。この場合、ユニットの左上隅Nbの座標は(0000h,8000h)と表現される。また、ユニットの右下隅Ncの座標は(8000h,0000h)と表現される。さらに、ユニットの右上隅Ndの座標は(8000h,8000h)で表現される。
また、ノード接続情報は、ノードレコードNR1に記録されるノードNと、後述するリンクレコードLRに記録されるリンクLとの接続関係を表す情報である。ノード接続情報の詳細については後述する。
なお、他のノードレコードNR2〜NR(Q+R)の内部データ構造については、ノードレコードNR1と同様であるため説明を省略する。ただし、他のノードレコードNR2〜NR(Q+R)には、互いに異なるノードNの情報が記録される。
【0088】
次に、図7の第1のリンクテーブルのデータ構造を説明する。ここで、予め断っておくが、第1および第2のリンクテーブルは、同様のデータ構造を有しており、主要幹線道路および細街路について作成される点で相違する。そのため、以降では、第2のリンクテーブルの詳細な説明を省略する。図30は、第1のリンクテーブルの詳細なデータ構造を示す図である。図30において、第1のリンクテーブルは、道路数Sと、S個の道路レコードRR1〜RRSとから構成される。道路数Sは、第1のノードテーブルにより表される道路網に含まれる道路の本数を示す情報である。ここで、Sは、1以上の自然数であって、ユニットUにより表される地図上の道路網に道路が何本存在するかを示す。道路レコードRR1には、ある1つの道路属性が割り当てられ、当該道路属性が同じリンクLおよびノードNに関する情報が記録される。また、道路レコードRR2には、他の1つの道路属性が割り当てられ、当該道路属性が同じリンクLおよびノードNに関する情報が記録される。以降、同様に、道路レコードRRSには、他の道路レコードRR1〜RR(S-1)には割り当てられていない1つの道路属性が割り当てられ、当該道路属性が同じリンクLおよびノードNに関する情報が記録される。以上から明らかなように、道路レコードRR1〜RRSには、互いに異なる道路属性が割り当てられる。ここで、道路属性とは、道路の種別毎に分類するための情報である。典型的には、道路は、高速道路、国道、県道、市道、私道等といった区分で分類され、さらには、各道路の名称によってより詳細に分類される。なお、必要に応じて、道路の一方通行規制等を道路属性に採用してもよい。
【0089】
道路レコードRR1は、道路属性と、リンク数T1と、先頭ノードレコード番号と、T1個のリンクレコードLR1〜LRT1とから構成される。道路属性には、道路種別(高速道路、国道、県道等)、道路の一方通行規制等を示す情報が記録される。リンク数T1は、道路レコードRR1に記録されるリンクLの個数を示す情報である。ここで、T1は、1以上の自然数であって、ユニットUにより表される地図上の道路網において、道路属性の情報に該当するリンクLが何個存在するかを示す情報である。先頭ノードレコード番号は、所定のノードレコードNRを特定するためのノードレコード番号を意味する。このノードレコード番号は、図28等を参照して上述したように、最初のノードレコードNR1を「0」として、各ノードレコードNR2以降が何番目に記録されているかを特定する番号である。さらに、所定のノードレコードNRとは、道路レコードRR1により表される道路網の先頭に位置するノードNが記録されたものを意味する。また、リンクレコードLR1には、ユニットUにより表される地図上の道路網において、道路属性により分類されるリンクLの内のある1つに関する情報が記録される。そのために、リンクレコードLR1は、リンク属性と、リンク接続情報とから構成される。リンク属性とは、リンクレコードLR1により表されるリンクLの属性を示す情報である。リンク属性の典型例としては、リンク種別(本線リンクであるか、側道リンクであるか等)または車線数等がある。また、リンク接続情報は、リンクレコードLR1により表されるリンクLに接続されたノードN、またはリンクレコードLR1により表されるリンクLとノードNを介してつながっているリンクLの情報である。また、リンクレコードLR2には、道路属性により分類されるリンクLの内の他の1つに関する情報が記録される。以降同様に、リンクレコードLRT1には、道路属性により分類されるリンクLの内、他のリンクレコードLR(T1-1)に記録されていない1つのリンクLに関する情報が記録される。ここで、リンクレコードLR2〜LRTは、リンクレコードLR1と同様に、リンク属性と、リンク接続情報とから構成される。以上から明らかなように、リンクレコードLR1〜LRT1には、互いに異なるリンクLに関する情報が記録される。
【0090】
さて、次に、第1のリンクテーブルに記載される情報の具体例を、図26の道路網の場合について具体的に説明する。上述したように、図26の道路網は、11個のノードN0〜N10と、11個のリンクL0〜L10とから構成される。また、説明をより具体的にするために、リンクL0〜L2は、ノードN0を先頭として、L0→L1→L2の順番で接続されることにより、1本の道路(例えば、国道)を構成すると仮定する。この仮定下では、リンクL0〜L2は互いに同一の道路属性(国道)を有する。リンクL3〜L5は、ノードN4を先頭として、L3→L4→L5の順番で接続されることにより、1本の道路(例えば、県道)を構成すると仮定する。この仮定下では、リンクL3〜L5は互いに同一の道路属性(県道)を有する。リンクL6〜L8は、ノードN7を先頭として、L6→L7→L8の順番で接続されることにより、1本の道路(例えば、幅員が5.5m以上の私道)を構成すると仮定する。この仮定下では、リンクL6〜L8は互いに同一の道路属性(私道)を有する。リンクL9およびL10は、ノードN5を先頭として、L9→L10の順番で接続されることにより、1本の道路(例えば、市道)を構成すると仮定する。この仮定下では、リンクL9およびL10は互いに同一の道路属性(市道)を有する。
【0091】
以上の仮定下では、道路は、国道、県道、私道および市道の4本であるから、第1のリンクテーブルの道路数Sとして、「4」が記録される。また、道路属性としては、国道、県道、私道および市道の4種類があるので、第1のリンクテーブルには、4個の道路レコードRR1〜RR4が記録される。まず、道路レコードRR1について説明する。道路属性としては「国道」を表す情報が記録される。また、リンク数T1としては、国道がリンクL0〜L2で構成されることから「3」を示す情報が記録される。また、リンクL0〜L2で表される道路の先頭は、ノードN0により表される。ノードN0のレコード番号は「1」である(図28参照)。ゆえに、先頭ノードNの番号としては「1」が記録される。次に、リンクレコードLR11(リンクL0のレコード)において、リンク属性については説明を省略する。
【0092】
さて、ここで、各リンクレコードLRに記録されるリンク接続情報、および図27に示されるノード接続情報を説明する。同時に、ノードNとリンクLの接続関係をたどる処理についても説明する。例えば、図26に示すように、ノードN2はリンクL1、L2、L6、およびL7の4本と接続している。このように、各ノードN2を中心として、4本のリンクL1、L2、L6およびL7がつながっている。また、ノードレコードNR10には、ノードN2に関連する情報が記録される(図27参照)。また、リンクレコードLR12、LR13、LR31およびLR32には、リンクL1、L2、L6およびL7に関連する情報が記録される(図31参照)。ノードレコードNR10のノード接続情報(図27参照)、および各リンクレコードLR12、LR13、LR31およびLR32のリンク接続情報(図31参照)には、ノードN2に接続されたリンクL1、L2、L6およびL7をたどるための情報が記録される。まず、ノードレコードNR10には、ノード接続情報として、ノードN2に接続された最初のリンクL(今、仮にリンクL1とする)が記録されたリンクレコードLR12を参照するための情報が記録される。より具体的には、ノード接続情報としては、リンクテーブルの先頭からリンクレコードLR12までのオフセットアドレスを記録しても良いし、リンクレコードLR12のリンクレコード番号を記録しても良い。ここで、リンクレコード番号とは、リンクテーブルにおいて最初のリンクレコードLR11を「0」として、リンクレコードLR12以降が何番目に記録されているかを特定する番号を意味する。以上のリンクレコード番号を図31のリンクレコードLRに当てはめると、リンクレコードLR11〜LR13のリンクレコード番号は「0」〜「3」となる。また、リンクレコードLR21〜LR23のリンクレコード番号は「4」〜「6」となる。また、リンクレコードLR31〜LR33のリンクレコード番号は「7」〜「9」となる。さらに、リンクレコードLR41およびLR42のリンクレコード番号は「10」および「11」となる。
【0093】
ここで注意を要するのは、ノード接続情報には、同じユニットU内の道路網の接続をたどる場合に限り、オフセットアドレスおよびリンクレコード番号が記録される。同様に、リンク接続情報には、同じユニットU内の道路網の接続をたどる場合に限り、オフセットアドレスおよびノードレコード番号が参照される。詳しくは図37および図38を参照して説明するが、あるユニットUおよび隣接ユニットNUの境界をまたぐような道路網の接続をたどる場合には、オフセットアドレスおよびリンクレコード番号は参照されない。
【0094】
図32の例では、ノードレコードNR10のノード接続情報には、当該ノードレコードNR10から、リンクテーブルのリンクレコードLR12を参照可能なように、当該リンクレコードLR12までのオフセットアドレスまたは当該リンクレコードLR12のリンクレコード番号が記録される。また、図32の例では、リンクレコードLR12からはリンクレコードLR31が参照されるので、リンクレコードLR12のリンク接続情報には、リンクL1と接続する他のリンクL6を参照可能なように、当該リンクレコードLR31へのオフセットアドレスまたは当該リンクレコードLR31のリンクレコード番号が記録される。かかるノードレコードNR10のノード接続情報およびリンクレコードLR12のリンク接続情報により、リンクL1はノードN2を起点として、リンクL6と接続していることが分かる。
【0095】
ここで注意を要するのは、リンクレコードLR12のリンク接続情報としては、リンクレコード番号やオフセットアドレスだけでなく、当該リンク接続情報が他のリンクLに対してであることを示すフラグを記録しておく。
さらに注意を要するのは、同一道路レコードRR内で記録されるリンクLを参照するためのリンク接続情報は、各リンクレコードLRには記録されない。同一道路レコードRRに属するリンクL同士は、リンク接続情報を参照しなくとも、リンクレコードLRの並び方によりたどることができるからである。つまり、道路レコードRR1においてリンクレコードLR11とリンクレコードLR12とは、連続するアドレス領域に並べて記録されるため、リンクL1およびリンクL2は相互に接続していると判断することができる。同様に、道路レコードRR3において、リンクレコードLR31およびLR32は連続アドレス領域に並べて記録されるため、リンクL6とリンクL7とは相互に接続していると判断することができる。
【0096】
さて、リンクレコードLR12の次に参照されるリンクレコードLR31に記録されたリンクL6は、道路レコードRR1以外に区分されたリンクLとは接続されていない。そのため、リンクレコードLR31のリンク接続情報としては、リンクL1、L2、L6およびL7の中心に位置するノードN2が記録されたノードレコードNR10を参照可能な情報が記録される。リンクレコードLR31のリンク接続情報としても、ノードレコードNR10へのオフセットアドレスまたは当該ノードレコードNR10のノードレコード番号が用いられる。
ここで注意を要するのは、リンクレコードLR31のリンク接続情報としては、ノードレコードNR10のノードレコード番号またはオフセットアドレスだけでなく、当該リンク接続情報がノードテーブルNRに対して設定されていることを示すフラグも記録される。
【0097】
以上のように、各ノードレコードNRには、最初に接続するリンクLへのノード接続情報のみを記録し、各リンクレコードLRには、そこに記録されるリンクLに接続する他の道路レコードRR内のリンクLへのリンク接続情報、もしくは起点となったノードNが記録されるノードレコードNRへのリンク接続情報を記録することによって、各ノードNを起点としたリンクLの接続をたどることができる。
【0098】
「ユニットヘッダのデータ構造」
さて、再度図7を参照して、ユニットヘッダのデータ構造について詳細に説明する。ユニットヘッダには、地図ファイルCFのユニットデータの管理情報が記録される。ユニットヘッダは、少なくともユニットID、バージョンコード、およびユニットデータを構成する8種類のテーブルのデータサイズから構成される。ユニットIDは、当該地図ファイルCFにより表されるユニットUを一意に特定できる識別番号である。より具体的には、ユニットIDは、ユニットUのレベルL、およびユニットUの親子関係および隣接関係が特定できる番号であり、地図ファイルCFのパス名と相互に変換できるものが望ましい。例えば、ユニットIDを32ビット(4バイト)のコードで表現するとし、MSBから2ビットをリザーブビットとし、順にユニットレベルLを2ビット、レベル「3」の経度方向の分割位置X3を5ビット、レベル「3」の緯度方向の分割位置Y3を5ビット、レベル「2」の経度方向の分割位置X2を3ビット、レベル「2」の緯度方向の分割位置Y2を3ビット、レベル「1」の経度方向の分割位置X1を3ビット、レベル「1」の緯度方向の分割位置Y1を3ビット、レベル「0」の経度方向の分割位置X0を3ビット、レベル「0」の緯度方向の分割位置Y0を3ビットで表す。ここで、レベル「3」の経度方向の分割位置X3は、ユニットUがレベル「3」に属するとした場合に東経方向に数えて何番目(起算点は経度0度)に位置するかを示す数である。レベル「3」の緯度方向の分割位置Y3は、ユニットUがレベル「3」に属するとした場合に北緯方向に数えて何番目(起算点は北緯0度)に位置するかを示す数である。レベル「2」の経度方向の分割位置X2は、ユニットUがレベル「2」に属するとした場合に東経方向に数えて何番目(起算点はレベル「3」のユニットUの左下)に位置するかを示す数である。レベル「2」の緯度方向の分割位置Y2は、ユニットUがレベル「2」に属するとした場合に北緯方向に数えて何番目(起算点はレベル「3」のユニットUの左下)に位置するかを示す数である。レベル「1」の経度方向の分割位置X1は、ユニットUがレベル「1」に属するとした場合に東経方向に数えて何番目(起算点はレベル「2」のユニットUの左下)に位置するかを示す数である。レベル「1」の緯度方向の分割位置Y1は、ユニットUがレベル「1」に属するとした場合に北緯方向に数えて何番目(起算点はレベル「2」のユニットUの左下)に位置するかを示す数である。レベル「0」の経度方向の分割位置X0は、ユニットUがレベル「0」に属するとした場合に東経方向に数えて何番目(起算点はレベル「1」のユニットUの左下)に位置するかを示す数である。レベル「0」の緯度方向の分割位置Y0は、ユニットUがレベル「0」に属するとした場合に北緯方向に数えて何番目(起算点はレベル「1」のユニットUの左下)に位置するかを示す数である。
【0099】
例えば、図4に示すレベル「0」のユニットU0のパス名は「¥MAP¥D1606¥D0401¥D0503¥M0201.map」であるため、前述のL=0、X3=16、Y3=6、X2=4、Y2=1、X1=5、Y1=3、X0=2、Y0=1となる。この場合、ユニットU0のユニットIDは、135928529(10進数表記)となる。以上から明らかなように、地図ファイルCFのパス名からユニットIDを一意に特定することができ、逆にユニットIDからパス名を一意に特定することができる。
【0100】
またバージョンコードは、地図ファイルCF(ユニットU)のバージョンを表すための識別コードであり、例えば、当該ユニットのフォーマットバージョンを表すコードを2バイト、当該ユニットのコンテンツバージョンを表すコードを2バイト等で記述した、合計4バイトのコードで表すものとする。このバージョンコードは、センタ局2からあるユニットIDの地図ファイルCFが端末装置1にダウンロードされた際に、端末装置1の第1の記憶装置19に既に格納されている同一ユニットIDの地図ファイルCFと置き換えるか否かの判断等に使用される。なお、この際の詳細な処理については後述する。
【0101】
また、各テーブルのデータサイズには、地図ファイルCFを構成する各テーブルのデータサイズが記録されており、それぞれは例えば2バイトで表される。各テーブルのデータサイズを順に加算していくことにより、各テーブルが格納されている、地図ファイルCFの先頭からのオフセットアドレスが算出可能となる。なお、各テーブルのデータサイズとしては、基本背景テーブルのデータサイズ、詳細背景テーブルのデータサイズ、基本文字記号テーブルのデータサイズ、詳細文字記号テーブルのデータサイズ、第1のノードテーブルのデータサイズ、第1のリンクテーブルのデータサイズ、第2のノードテーブルのデータサイズ、第2のリンクテーブルのデータサイズが並ぶ。それぞれのテーブルの内容については上述した通りである。
【0102】
以上、地図ファイルCFの詳細なデータ構造について説明した。次に、第1のデータベース111から地図ファイルCFを読み出す際の端末装置1の動作について、図面を参照して説明する。
「読み出し処理」
図1を参照して説明したように、本実施形態の端末装置1は、典型的にはカーナビゲーションシステムである。周知のように、マップマッチング、経路探索、または経路案内等の処理が実行される。以下には、これらの処理の内、経路探索処理に関連して、地図ファイルCFを読み出す処理、あるユニットUと隣接ユニットNUにまたがる道路の接続をたどる処理、および階層間でのノードNとリンクLとの対応づけを行う処理について詳細に説明する。なお、以下では、出発地および目的地の間の最短ルートを求める処理そのものについては本願発明のポイントではないため特に説明しない。
【0103】
図33は、経路探索処理の概念を示す図である。図33に示すように、最短ルートを求める処理では、出発地SP側と目的地DP側の両方向から探索が広げられる。さらに、経路探索処理では、下位階層から上位階層までの複数階層の地図ファイルCFが用いられる。この時、出発地SPおよび目的地DP周辺では、詳細な道路網を表す下位階層の地図ファイルCFを用いて、最短ルートが探索される。一方、出発地SPおよび目的地DP周辺以外では、粗い道路網を表す上位階層の地図ファイルCFが用いられる。以上の図33に示す経路探索処理では、いわゆる双方向階層別探索の手法が用いられる。また、地図ファイルCFを用いて、出発地SPから目的地DPへの最短ルートを求める場合には、周知のダイクストラ法等が使用される。なお、ダイクストラ法については、本願発明のポイントではなく、かつ周知の技術であるため、これ以上説明しない。
【0104】
以下、図34のフローチャートを参照して、端末装置1で実行される双方向階層別探索の処理手順を詳細に説明する。まず、双方向階層別探索では、端末装置1の出発地SPおよび目的地DPの設定が実行される(ステップS101,S102)。ステップS101およびS102において、出発地SPおよび目的地DPは、出力装置110のディスプレイに表示されるメニューに従って、端末装置1のユーザが入力装置11を操作することにより設定される。ここで、最近のカーナビゲーションシステムでは、出発地SPおよび目的地DPは、一般的に、住所、電話番号、地名または施設名称等を使って設定される。設定された出発地SPおよび目的地DPを特定する情報は、入力装置11からデータ処理部13に送信される。
【0105】
ステップS102が終了すると、データ処理部13は、読み出し/書き込み制御部18と協働して、経路探索処理に必要な地図ファイルCFを、第1の記憶装置19から主記憶(図示せず)に順次読み込む(ステップS103)。前述したように、第1の記憶装置19に格納された各地図ファイルCFは、図2等に示すように、地図を矩形領域に分割したユニットUを単位としてデジタルデータ化される。さらに、各地図ファイルCFは、ファイルシステムにより管理される。ファイルシステムは、第1の記憶装置19の論理領域がツリー構造をとるようにディレクトリを作成する。これによって、各地図ファイルCFが格納される論理領域は、ルートおよびファイル名、ならびにそれらの間に介在するサブディレクトリ名により表されるパスにより一意に特定される。また、本実施形態のツリー構造およびファイル名は、上述したように、ユニットU同士の親子関係および隣接関係を特定する。ファイルシステムを構成するデータ処理部13および読み出し/書き込み制御部18は、最初のステップS103において、入力装置11から送信されてくる出発地SP周辺を表す地図ファイルCFを第1の記憶装置19から読み出すためには、当該地図ファイルCFのパス名を求めなければならない。
【0106】
ここで、図35は、図34のステップS103の詳細な処理手順を示すフローチャートである。図35の処理を簡単に説明すると、データ処理部13が読み込むべき地図ファイルCFのレベル(階層)および代表点となる地点の座標情報から、当該地図ファイルCFのパス名を求める。そして、読み出し/書き込み制御部18は、データ処理部13により求められたパス名を基に、第1の記憶装置19から地図ファイルCFを読み出す。以下、図35のフローチャートを参照して、図4および図5に示すレベル「0」のユニットU0を表す地図ファイルCF(「¥M0201.map」)を読み出す際の処理手順を説明する。
【0107】
ここで、代表点とは、読み出すべき地図ファイルCFがカバーする範囲に含まれる1つの地点を意味する。以下の説明において、経度座標LON0および緯度座標LAT0は、ユニットU0の代表点の経度方向の位置を示す座標および緯度方向の位置を示す座標とする。本実施形態では、経度座標LON0および緯度座標LAT0は、東経132度39分20秒および北緯32度55分37秒とする。
【0108】
さらに、ステップS103の処理には、いくつかのパラメータが必要となる。以下の説明において、経度幅W3は、レベル「3」に属する各ユニットUがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅H3は、レベル「3」に属する各ユニットUがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。本実施形態の場合、図2および図3で説明したように、レベル「3」の矩形領域が約640km四方の場合には、経度幅W3および緯度幅H3は28800秒(8度)および19200秒(5度20分)である。経度幅W2は、レベル「2」に属する各ユニットUがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅H2は、レベル「2」に属する各ユニットUがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。レベル「2」の矩形領域が約80km四方の場合には、経度幅W2および緯度幅H2は3600秒(1度)および2400秒(40分)である。経度幅W1は、レベル「1」に属する各ユニットUがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅H1は、レベル「1」に属する各ユニットUがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。レベル「1」の矩形領域が約10km毎の場合には、経度幅W1および緯度幅H1は450秒(7分30秒)および300秒(5分)である。経度幅W0は、レベル「0」に属する各ユニットUがカバーする矩形領域の経度方向に沿う辺の長さを意味する。緯度幅H0は、レベル「0」に属する各ユニットUがカバーする矩形領域の緯度方向に沿う辺の長さを意味する。レベル「0」の矩形領域が約1.2km毎の場合には、経度幅W0および緯度幅H0は56.25秒および37.5秒である。
【0109】
さて、データ処理部13は、まず、代表点の経度座標LON0および緯度LAT0を特定し(ステップS201)、読み込むべき地図ファイルCFのレベルL(ユニットU0の地図ファイルCFを読み込む場合、L=0)を特定する(ステップS202)。ここで、ステップS201およびS202は、双方向階層別探索において一般的に実行される処理であるため、ここでは詳細に説明しない。
【0110】
次に、データ処理部13は、ステップS203に進み、代表点の経度座標LON0をレベル「3」の経度幅W3で除算した時の商DLON3、および、当該代表点の緯度LAT0をレベル「3」の緯度幅H3で除算した時の商DLAT3を算出する。今、経度幅W3=28800秒(8度)、緯度幅H3=19200秒(5度20分)、経度座標LON0=東経132度39分20秒、緯度座標LAT0=北緯32度55分37秒であるから、商DLON3=16、商DLAT3=6となる。データ処理部13は、算出された商DLON3および商DLAT3を順番に並べて4桁の数字を作成する。今回作成される4桁の数字は、「1606」である。ここで、商DLON3および/または商DLAT3が1桁となる場合は、下から2桁目に「0」を付ける。
【0111】
データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびファイル名の頭文字を定義する「M」を付加し、さらにその末尾にファイル名の拡張子「.map」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCF(ユニットU0のもの)のファイル名(今回の場合、「¥M1606.map」)を導き出す。
さらに、データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびサブディレクトリ名の頭文字を定義する「D」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCFが格納されたサブディレクトリ名(今回の場合「¥D1606」)を導出する(ステップS203)。
【0112】
次に、データ処理部13は、ステップS202で指定されたレベルLが「3」か否かを判断する(ステップS204)。レベルLが「3」の場合、データ処理部13は、ステップS205に進み、ルート(「¥MAP」)の後に、ステップS203で導出したファイル名(「¥M1606.map」)を付加して、パス名を導出する。したがって、パス名は「¥MAP¥M1606.map」となる。データ処理部13は、導出したパス名を読み出し/書き込み制御部18に出力する(ステップS205)。読み出し/書き込み制御部18は、入力されたパス名(「¥MAP¥M1606.map」)に従って、地図ファイルCFを第1の記憶装置19内の第1のデータベース111から読み出す。読み出し/書き込み制御部18は、読み出した地図ファイルCFをデータ処理部13内の主記憶(図示せず)に転送する。このようにして、データ処理部13は、地図ファイルCFを第1の記憶装置19から主記憶に読み込む(ステップS206)。
【0113】
ところで、上述したように、ステップS202で指定されたレベルは「0」であるから、データ処理部13は、ステップS204においてレベルLが「3」でないと判断して、ステップS207に進む。データ処理部13は、ステップS203で導出した商DLON3の余りRLON3を算出した後、当該余りRLON3をレベル「2」の経度幅W2で除算した時の商DLON2を算出する。さらに、データ処理部13は、ステップS203で導出した商DLAT3の余りRLAT3を算出した後、当該余りRLAT3をレベル「2」の緯度幅H2で除算した時の商DLAT2を算出する。今、上述した数値を用いた場合、商DLON2および商DLAT2は、DLON2=4およびDLAT2=1となる。データ処理部13は、算出された商DLON2および商DLAT2を順番に並べて4桁の数字を作成する。今回作成される4桁の数字は、「0401」である。ここで、商DLON2および/または商DLAT2が1桁となる場合は、2桁目に「0」を付ける。
【0114】
データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびファイル名の頭文字を定義する「M」を付加し、さらにその末尾にファイル名の拡張子「.map」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCFのファイル名(今回の場合、「¥M0401.map」)を導き出す。
さらに、データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびサブディレクトリ名の頭文字を定義する「D」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCF(ユニットU0のもの)が格納されたサブディレクトリ名(今回の場合「¥D0401])を導出する(ステップS207)。
【0115】
次に、データ処理部13は、ステップS202で指定されたレベルLが「2」か否かを判断する(ステップS208)。レベルLが「2」の場合、データ処理部13は、ステップS209に進み、ルート(「¥MAP」)の後に、ステップS203で導出したサブディレクトリ名(「¥D1606」)およびステップS207で導出したファイル名(「¥M0401.map」)を付加して、パス名を導出する。したがって、パス名は「¥MAP¥D1606¥M0401.map」となる。データ処理部13は、導出したパス名を読み出し/書き込み制御部18に出力する(ステップS209)。読み出し/書き込み制御部18は、入力されたパス名(「¥MAP¥D1606¥M0401.map」)に従って、地図ファイルCFを第1の記憶装置19内の第1のデータベース111から読み出す。読み出し/書き込み制御部18は、読み出した地図ファイルCFをデータ処理部13内の主記憶(図示せず)に転送する。このようにして、データ処理部13は、地図ファイルCFを第1の記憶装置19から主記憶に読み込む(ステップS206)。
【0116】
上述したように、ステップS202で指定されたレベルは「0」であるから、データ処理部13は、ステップS208においてレベルLが「2」でないと判断して、ステップS210に進む。データ処理部13は、ステップS207で導出した商DLON2の余りRLON2を算出した後、当該余りRLON2をレベル「1」の経度幅W1で除算した時の商DLON1を算出する。さらに、データ処理部13は、ステップS207で導出した商DLAT2の余りRLAT2を算出した後、当該余りRLAT2をレベル「1」の緯度幅H1で除算した時の商DLAT1を算出する。今、上述した数値を用いた場合、商DLON1および商DLAT1は、DLON1=5およびDLAT1=3となる。データ処理部13は、算出された商DLON1および商DLAT1を順番に並べて4桁の数字を作成する。今回作成される4桁の数字は、「0503」である。ここで、商DLON1および/または商DLAT1が1桁となる場合は、2桁目に「0」を付ける。
【0117】
データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびファイル名の頭文字を定義する「M」を付加し、さらにその末尾にファイル名の拡張子「.map」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCFのファイル名(「¥M0503.map」)を導き出す。
さらに、データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびサブディレクトリ名の頭文字を定義する「D」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCF(ユニットU0のもの)が格納されたサブディレクトリ名(今回の場合「¥D0503])を導出する(ステップS2010)。
【0118】
次に、データ処理部13は、ステップS202で指定されたレベルLが「1」か否かを判断する(ステップS2011)。レベルLが「1」の場合、データ処理部13は、ステップS2012に進み、ルート(「¥MAP」)の後に、ステップS203で導出したサブディレクトリ名(「¥D1606」)、ステップS207で導出したサブディレクトリ名(「¥D0401」)およびステップS210で導出したファイル名(¥M0503.map)を付加して、パス名を導出する。したがって、パス名は「¥MAP¥D1606¥D0401¥M0503.map」となる。データ処理部13は、導出したパス名を読み出し/書き込み制御部18に出力する(ステップS2012)。読み出し/書き込み制御部18は、入力されたパス名(「¥MAP¥D1606¥D0401¥M0503.map」)に従って、地図ファイルCFを第1の記憶装置19内の第1のデータベース111から読み出す。読み出し/書き込み制御部18は、読み出した地図ファイルCFをデータ処理部13内の主記憶(図示せず)に転送する。このようにして、データ処理部13は、地図ファイルCFを第1の記憶装置19から主記憶に読み込む(ステップS206)。
【0119】
上述したように、ステップS202で指定されたレベルLは「0」であるから、データ処理部13は、ステップS2011においてレベルLが「1」でないと判断して、ステップS2013に進む。データ処理部13は、ステップS210で導出した商DLON1の余りRLON1を算出した後、当該余りRLON1をレベル「0」の経度幅W0で除算した時の商DLON0を算出する。さらに、データ処理部13は、ステップS210で導出した商DLAT1の余りRLAT1を算出した後、当該余りRLAT1をレベル「0」の緯度幅H0で除算した時の商DLAT0を算出する。今、上述した数値を用いた場合、商DLON0および商DLAT0は、DLON0=2およびDLAT0=1となる。データ処理部13は、算出された商DLON0および商DLAT0を順番に並べて4桁の数字を作成する。今回作成される4桁の数字は、「0201」である。ここで、商DLON0および/または商DLAT0が1桁となる場合は、2桁目に「0」を付ける。
データ処理部13は、作成した4桁の数字の先頭に、ディレクトリの識別子「¥」およびファイル名の頭文字を定義する「M」を付加し、さらにその末尾にファイル名の拡張子「.map」を付加する。これによって、データ処理部13は、代表点の経度座標LON0および緯度座標LAT0から、読み込むべき地図ファイルCFのファイル名(今回の場合、「¥M0201.map」)を導き出す(ステップS2013)。ここで、ステップS2013では、レベルLが最下位層の「0」と自動的に判断できるので、データ処理部13は、サブディレクトリ名を導出しない。
【0120】
次に、データ処理部13は、ステップS2014に進み、ルート(「¥MAP」)の後に、ステップS203、S207およびS210で導出したサブディレクトリ名の配列(「¥D1606¥D0401¥D0503」ならびにステップS2013で導出したファイル名(今回の場合、「¥M0201.map」)を付加して、パス名を導出する。したがって、パス名は「¥MAP¥D1606¥D0401¥D0503¥M0201.map」となる。データ処理部13は、導出したパス名を読み出し/書き込み制御部18に出力する(ステップS2014)。読み出し/書き込み制御部18は、入力されたパス名(「¥MAP¥D1606¥D0401¥M0503.map」)に従って、地図ファイルCFを第1の記憶装置19内の第1のデータベース111から読み出す。読み出し/書き込み制御部18は、読み出した地図ファイルCFをデータ処理部13内の主記憶(図示せず)に転送する。このようにして、データ処理部13は、所望の地図ファイルCF(ユニットU0を表す地図を表示可能なデータ)を第1の記憶装置19から主記憶に読み込む(ステップS206)。
【0121】
データ処理部13は、以上のステップS206の後、図35のフローチャートから抜けて、図34のステップS104に進む。データ処理部13は、主記憶上に読み込まれた地図ファイルCFを用いて、出発地SP側からの経路探索処理を行う(ステップS104)。ここで注意を要するのは、ダイクストラ法等の手法は周知であるため、その詳細な説明を省略する。ダイクストラ法等を簡単に説明すると、地図ファイルCF内の道路ネットワークの接続をたどりながら最短ルートを求める処理が行われる。かかる地図ファイルCF内でのノードNとリンクLの接続関係をたどる手順については、図32を参照して前述の通りである。
【0122】
また、データ処理部13は、ステップS102の後、ステップS103と並行して、ステップS105を実行する。データ処理部13は、ステップS102で設定された目的地DP周辺の地図ファイルCFを第1の記憶装置19から、自身の内部に有する主記憶(図示せず)に読み込む(ステップS105)。さらに、データ処理部13は、ステップS105で読み込んだ地図ファイルCFを用いて、目的地DP側の経路探索処理を行う(ステップS106)。ここで、ステップS105およびS106の処理については、ステップS103およびステップS104と同様であるため詳細な説明は省略する。
【0123】
データ処理部13は、ステップS104およびS106の処理が終了すると、当該ステップS104およびS106で使用された地図ファイルCFの階層での探索終了条件を満たしたか否かの判断を行う(ステップS107)。ステップS107では、一般的に、読み込んだ地図ファイルCFの数、または探索したノードNの数等が所定の値に達しているか否かに基づいて、探索条件が終了したか否かが判断される。ステップS107において探索終了条件を満たしていないと判断された場合には、データ処理部13は、ステップS103およびS105に戻って、出発地SP側および目的地DP側の双方からの探索処理で既に読み込まれている地図ファイルCFに隣接する地図ファイルCFを読み込む。ここで、既に読み込まれている地図ファイルCFがユニットUの地図を表すとすると、隣接する地図ファイルCFは、隣接ユニットNU(図26参照)の地図を表すこととなる。データ処理部13は、新たな代表点の経度座標LONおよび緯度座標LATを求めて、隣接する地図ファイルCFのパス名を導出し、当該パス名により特定される地図ファイルCFを第1の記憶装置19から主記憶に読み込む。
【0124】
ここで、図36に示すように、隣接ユニットNUを決定するための新しい代表点の位置は、道路網の接続をたどるリンクLが、どのユニット境界上の隣接ノード(詳しくは図26を参照)を経由して当該隣接ユニットNU内のリンクLと接続するかによって異なる。より具体的に説明すると、図36のリンクL11は、ユニットUの境界(矩形)の上辺上に位置する隣接ノードN12を経由して隣接ユニットNU1のあるリンクLと接続する。このため、ユニットUの代表点Pの緯度座標LATに対して、当該ユニットUが属するレベルLの緯度幅Hを加算した緯度座標LAT1をもつ地点が新しい代表点P1と定められる。
【0125】
一方、図36のリンクL12は、ユニットUの境界(矩形)の右辺上に位置する隣接ノードN13を経由して隣接ユニットNU2内のあるリンクLと接続する。このため、ユニットUの代表点Pの経度座標LONに対して、当該ユニットUが属するレベルLの経度幅Wを加算した経度座標LON2をもつ地点が新しい代表点P2と定められる。
【0126】
2回目以降のステップS103およびS105では、データ処理部13は、図36を参照して説明したようにして求められた新しい代表点に基づいて、当該代表点を含む範囲を表す地図の地図ファイルCFを読み込む。なお、この際の処理手順は前述の通りである。次のステップS104およびS106では、データ処理部13は、ステップS103およびS105で読み込んだ地図ファイルCFを使って探索処理を行う。かかる探索処理は、前回読み込んだ地図ファイルCFから今回読み込んだものへと、つまりユニットUと隣接ユニットNUとの境界をまたいで道路網の接続をたどることを意味している。
【0127】
ところで、従来の技術では、ユニットUおよび隣接ユニットNUの境界をまたいだ場合であっても、道路網の接続をたどることができるように、各地図ファイルの隣接ノードのレコードに、隣接ユニットNUの隣接ノードを特定する番号またはオフセットアドレス等が記録されていた。しかし、このような地図ファイルの内部データ構造に関わる情報を当該ユニットに記録してしまうと、隣接ユニットNUを表す地図ファイルが更新された場合、上記番号またはオフセットアドレスが変わってしまう場合がある。したがって、1つの地図ファイルが更新されることにより、その周囲のすべての隣接ユニットNUを表す地図ファイルが更新される必要が生じるおそれがあるという問題点があった。かかる問題点を解消すべく、本実施形態の各地図ファイルCFには、隣接ユニットNUの内部データ構造に直接関わる情報は記録されておらず、データ処理部13は、ノードNの座標情報および/またはリンクLの属性情報を用いて、隣接ユニットNUの隣接ノードNをたどる処理を実行する。
【0128】
以下、図37および図38の2つの図面を参照して、図34のステップS104またはS106における、データ処理部13がユニットUと隣接ユニットNUの境界をまたいで道路網の接続をたどる処理について詳細に説明する。図37は、互いに隣接し合う4個のユニットU1〜U4を並べた際に構成される道路網を示している。ユニットU1に含まれる道路網は、4個のノードN10〜N13と、3個のリンクL10〜L12とから構成される。ユニットU1では、3個のノードN10、N12およびN13(●印参照)は隣接ノードであって、ユニットU1の境界上に位置する。また、ユニットU2に含まれる道路網は、5個のノードN20〜N24と、4個のリンクL20〜L23とから構成される。ユニットU2では、4個のノードN20およびN22〜24(●印参照)は、隣接ノードであって、ユニットU2の境界上に位置する。また、ユニットU3に含まれる道路網は、4個のノードN30〜N33と、3個のリンクL30〜L32とから構成される。ユニットU3では、ノードN30、N32およびN33(●印参照)が隣接ノードであり、ユニットU3の境界上に位置する。さらに、ユニットU4に含まれる道路網は、4個のノードN40〜N43と、3個のリンクL40〜L42とから構成される。3個のノードN40〜N43(●印参照)は、隣接ノードであって、ユニットU4の境界上に位置する。
さらに、図37において、ノードN13およびN20が接続され、ノードN12およびN30が接続され、ノードN24およびN43が接続され、さらにノードN33およびN40が接続され、これによって、1つの道路網が構成される。
【0129】
以上の図37の道路網において、リンクL12は、隣接ノードN13およびN20を経由して、リンクL20とつながっている。上述したように、経路探索処理において、データ処理部13は、隣接ユニットNUを表す地図ファイルCFを順次読み込んで、目的地DPまたは出発地SPの方向へと探索を広げていく。そのためには、データ処理部13は、あるユニットUおよび隣接ユニットNUの境界をまたぐような2個のリンクLの接続関係をたどる必要がある。そこで、まず、データ処理部13は、主記憶上に読み込まれたユニットU(つまり、ユニットU1)の地図ファイルCF(より具体的には、リンクレコードRR(図30および図31参照))から、ユニットU1からユニットU2へと向かうリンクL12のリンク属性を取り出す(図38;ステップS301)。以下では、ユニットU1の境界へと向かうリンクL12を脱出リンクL12と呼ぶこととする。
【0130】
次に、データ処理部13は、脱出リンクL12の接続先情報(ノードレコード番号またはオフセットアドレス)を参照して、地図ファイルCF(より具体的には、第1または第2のノードテーブル)から、当該脱出リンクL12に接続された隣接ノードN13のノードレコードNR(図27参照)を探し出す。その後、データ処理部13は、探し出したノードレコードNRから、隣接ノードN13のノード座標を取り出す(ステップS302)。以下では、脱出リンクL12に接続された隣接ノードN13を脱出ノードN13と呼ぶこととする。
【0131】
次に、データ処理部13は、主記憶上に読み込まれている隣接ユニットNU(つまり、ユニットU2)の地図ファイルCF(より具体的には、第1または第2のノードテーブル)から、ノード座標を1つずつ取り出す(ステップS303)。データ処理部13は、ステップS302で取り出した脱出ノードN13のノード座標と、ステップS303で取り出したノード座標との差分値を算出して、当該差分値が所定の閾値以下であるか否かを判断する(ステップS304)。ここで、図29を参照して説明したように、本実施形態では、ノード座標は正規化された値で記録されている。上記所定の閾値としては、正規化された座標値の幅により異なるが、「1」〜「2」程度の値が好ましい。データ処理部13は、ステップS304の条件を満たすまで、ステップS303およびS304を繰り返し実行する。ただし、データ処理部13は、ステップS303を実行するたびに、過去に取り出したものとは異なるノード座標を取り出す。ここで、ステップS304の条件を満たすということは、ステップS303で取り出したノード座標を有するノードNが脱出ノードN13と同じ位置を示していることとなる。つまり、制御部13は、ステップS303およびS304を繰り返し実行することにより、脱出ノードN13とほぼ同じ位置を有する隣接ノードN20を探し出すことができる。以下では、探し出された隣接ノードN20を進入ノードと呼ぶこととする。
【0132】
ここで、一般的に、ステップS303においては、ノードレコード番号(図28参照)の順番に従って、ノード座標が1つずつ順番に取り出される。本実施形態では、図26および図28を参照して説明したように、第1または第2のノードテーブルにおいて、隣接ノードNのノードレコードNRは、非隣接レコードNのノードレコードNRの前に記録されている。これによって、データ処理部13は、非隣接ノードNのノードレコードNRからノード座標を取り出すことなく、進入ノードを見つけ出すことができる。これによって、データ処理部13が進入ノードを検索する処理の負荷を最小限に抑えることができる。すわなち、データ処理部13は、隣接ユニットNUの地図ファイルCFに記録された第1および第2のノードテーブル内に並ぶ全てのノードレコードNRを検索しなくても、当該第1または第2のノードテーブルの先頭から隣接ノードの数だけノードレコードNRを検索すれば、必ず進入ノードを見つけ出すことができる。このように、本実施形態におけるノードレコードNRの並べ方は、進入ノードを検索する処理の高速化にも寄与する。
【0133】
また、隣接ノードのノードレコードNRは、図26を参照して説明したように、ユニットU(矩形)の左辺→上辺→右辺→下辺という優先順位に従って並べられる。さらに、左辺および右辺上に位置する隣接ノードのノードレコードNRは緯度の昇順に並べられ、上辺および下辺上に位置する隣接ノードのノードレコードNRは経度の昇順に並べられる。また、非隣接ノードのレコードNRについては、まず緯度の昇順に並べられ、緯度が同一座標の複数の非隣接ノードのレコードNRについては経度の昇順に並べられる。かかる並べ方によって、進入ノードの検索処理をさらに高速化することができる。例えば、上記の並べ方の規則に従えば、図39の隣接ノードN10〜N20のノードレコードNRは、N10→N11→N12→N13→N14→N15→N16→N17→N18→N19→N20の順で、ユニットU1の地図ファイルCF内に記録される。同様に、隣接ノードN20〜N27のノードテーブルU2のノードレコードNRは、N20→N21→N22→N23→N24→N25→N26→N27の順で、ユニットU2の地図ファイルCF内に記録される。さらに、ユニットU3の地図ファイルCF内には、ノードN30→N31→N32→N33→N34→N35→N36→N37→N38の順にノードレコードNRが記録される。
【0134】
通常、経路探索処理では、読み込んだ地図ファイルCF内で探索が広げられ、探索中のルートが隣接ノードに到達した際には、その対応する隣接ユニットNUが新たに読み込まれる。本実施形態では、隣接ユニットNUの地図ファイルCFが読み込まれた際に、まず前回読み込まれた地図ファイルCFと今回読み込まれた地図ファイルCFとの、ユニットの間の境界上に存在する全隣接ノードの対応付けが行われる。この際に、前述のようにノードテーブルにおいて、隣接ノードのノードレコードNRが、上述した順位で記録されることにより、隣接ノードの対応付けを高速化することができる。このため、例えば、ユニットU1の隣接ノードN12と同じ位置を示すユニットU3の隣接ノードN35が見つかれば、ユニット1の次の隣接ノードN13に対応するユニット3の隣接ノードN36は必ずN35の次のレコードに並んでいる。また同様に、ユニット2の隣接ノードN20に対応するユニット1の隣接ノードN16が見つかれば、ユニット2の次の隣接ノードN21に対応するユニット1の隣接ノードN17は必ずN16の次のレコードに並んでいる。このように、前述のような規則性に従って隣接ノードを並べることにより、隣接ユニット間における隣接ノードの検索処理を高速化することができる。
【0135】
さて、ステップS304で進入ノードが見つかると、データ処理部13は、進入ノードN20の接続先情報(ノードレコード番号またはオフセットアドレス)を参照して、ユニットU2の地図ファイルCF(より具体的には、第1または第2のリンクテーブル)から、当該進入ノードN20に接続されたリンクL20のリンクレコードLR(図30および図31参照)を探し出す。以下では、進入ノードN20に接続されたリンクL20を進入リンクL20と呼ぶこととする。その後、データ処理部13は、探し出したリンクレコードLRから、進入リンクL20の属性情報を取り出す(ステップS305)。
【0136】
次に、データ処理部13は、ステップS301で取り出した脱出リンクL12の属性情報と、ステップS305から取り出した進入リンクL20の属性情報が同じか否かを判断する(ステップS306)。データ処理部13は、2つの属性情報が互いに異なると判断した場合、ステップS303に戻って、新しい進入ノードNを探す。ここで、本実施形態では、図2を参照して説明したように、互いに異なる縮尺の地図を表すいくつかの地図ファイルCFが第1の記憶装置19には格納されている。下位階層の地図ファイルCFは、詳細な道路網を表すことができるので、2つのノード座標の差分値が所定の閾値以下であれば、両ノードNが同じ位置を示す確率が相対的に高くなる。しかしながら、上位階層の地図ファイルCFは粗い道路網しか表すことができないので、2つのノード座標の差分値が所定の閾値以下であっても、両ノードNが同じ位置を示す確率は相対的に低くなる。本実施形態では、ステップS306において脱出リンクおよび進入リンクの属性を一致/不一致を判断することにより、データ処理部13が、ある道路から別の道路をたどることなく、同じ1本の道路を正確にたどるようにしている。つまり、ステップS306の処理は、下位階層の地図ファイルCFに対して実行されなくともよい。
【0137】
データ処理部13は、ステップS306で脱出リンクL12および進入リンクL20の属性情報が一致していると判断すると、1本の道路を正確にたどっているとみなして、図38のフローチャートから抜けて、図34のステップS107に進む。データ処理部13は、今回の読み込み続けた地図ファイルCFの階層での探索終了条件を満たしたと判断した場合、出発地SP側の経路と目的地DP側の経路がつながったかどうかを判断する(ステップS108)。データ処理部13は、出発地SP側と目的地DP側の経路とがつながっている場合には、両地点間の最短ルートが求まったと判断し、経路探索処理を終了する。一方、出発地SP側と目的地DP側との経路がまだつながっていない場合には、データ処理部13は、ステップS109に進み、1つ上位の階層に移行して、広域かつ粗い道路網を表す地図ファイルCFを使って経路探索処理を続行する。
【0138】
次に、ある下位階層から上位階層への以降処理について詳細に説明する。この時、データ処理部13は、下位階層における探索処理の終点となるノードN(探索中のルートの終点)から、上位階層の地図ファイルCF内に存在しかつ同じ位置を示すノードNへと移行する。したがって、データ処理部13が上位階層への移行処理を確実に行うためには、上位階層の地図ファイルCFに含まれるすべてのノードNが、その子ユニットCUの各ノードNから必ず検索できる必要がある。
【0139】
従来では、かかる検索を実現するために、下位階層のノードNと同じ位置を示すに上位階層のノードNのノード番号やオフセットアドレス等がノードレコード内に記録されるという方法が採用されていた。しかし、このような上位階層の地図ファイルの内部データ構造に関わる情報が下位階層の地図ファイルに記録されると、上位階層の地図ファイルが更新された場合、下位階層の地図ファイルも更新されなければ、下位階層から上位階層への移行処理をスムーズに行えなくなるという問題点があった。そこで、本実施形態では、各地図ファイルCFには、上位階層の地図ファイルCFの内部データ構造に直接関わるような情報は記録されず、階層移行を行う際にノードの座標情報やリンクの属性情報が参照される。しかし、この場合、一般的に上位階層の地図ファイルCFが表す地図は、下位階層の地図ファイルCFが表す地図に比べて座標の分解能が低い。そのため、図40に示すように、下位階層および上位階層の地図ファイルCFでは互いに異なる座標をもっていた2つのノードNが、上位階層の地図ファイルCFにおける座標の丸め誤差のために、同一の座標をもってしまう可能性がある。したがって、ノード座標だけでは、下位階層のノードNと一致する上位階層のノードNを一意に特定することはできない。
【0140】
そこで、本実施形態では、ノード座標だけでなく、ノードレコードNRの記録順序(並び方)が利用される。すなわち、前述のように第1または第2のノードテーブルにおけるノードレコードNRの並びの順は、隣接ノード、非隣接ノード共に明確に規定されている。このため、座標の丸め誤差が生じるような上位階層のユニットUにおいても、丸め誤差が生じる前の正規化経度緯度座標を利用して、座標の昇順でノードレコードNRが記録される。これによって、データ処理部13は、下位階層のノードNから、同じ位置を示しかつ上位階層の親ユニットPUに含まれるノードNを検索する場合にも、下位階層ユニットU内に記録されているノードNの内で、親ユニットUにも記録されており、かつ上位階層で丸め誤差が生じた場合に同一座標になると考えられるノードNの中から、ノードレコードNRの記録順序に基づいて、親ユニットPU内で対応するノードNを一意に特定することができる。
【0141】
より具体的には、前述のように地図ファイルCFでは、相対的に1階層上の親ユニットPUは、その子ユニットCUに対して、経度方向および緯度方向共に8倍のユニット幅を有する。その一方で、階層には関係なく、各ノードは、ユニットUの経度方向および緯度方向共に8000h(16ビット)で正規化した正規化座標をもつ。すなわち、親ユニットPUは子ユニットCUに対して、その座標分解能が、経度方向および緯度方向共に1/8であるということができる。このため、子ユニットCUの正規化経度および正規化緯度座標16ビットの内、上位13ビットが同じ値をもつノードNは、その親ユニットPUにおいて同一の正規化座標をもつことになる。
【0142】
例えば、図41に示すように、子ユニットCUに記録されている5つのノードNa、Nb、Nc、Nd、Neの正規化経度および正規化緯度座標16ビットの内、その上位13ビットが同じ値をもち、かつこの内の4つのノードNa、Nc、Nd、Neの親となるノードNa2、Nc2、Nd2およびNe2が親ユニットPUに記録されている(各ノードレコードNRに、親ノードPUが存在することを示すフラグあるいはコードを記録している)とする。この場合、図42に示すように、子ユニットCUのノードテーブルには、ノードNa、Nb、Nc、NdおよびNeの5個のノードレコードNRは、緯度および経度の昇順に従って(前述)、Na→Nb→Nc→Nd→Neの順に記録されている。なお、この際、ノードNa、Nb、Nc、NdおよびNeの5個のノードレコードNRは、ノードテーブル内で必ずしも連続しているわけではない。
【0143】
親ユニットPUのノードテーブルを作成する際には、上記5個のノードレコードNRの並びの順に基づいて、ノードNa、Nc、NdおよびNeそれぞれに対応する親ノードNa2、Nc2、Nd2およびNe2のノードレコードNRが、この順に記録(必ずしも連続して記録する訳ではない)される。この結果、下記のようにして、子ユニットCUに記録されているノードNdに対する、親ユニットPUにおける親ノードNd2を特定することができる。最初に、子ユニットCUのノードNdは、ノードテーブルにおいて、その正規化座標16ビットの内の上位13ビットが同じノードNで、かつ親ノードNが存在するものの内の3番目のノードレコードNRに記録されている。次に、子ユニットCUにおけるノードNdの正規化座標から、親ユニットPUにおける正規化座標が算出される。次に、算出した正規化座標をもつノードNが、親ユニットPUのノードテーブルから探し出される。その結果、図41および図42の例では、4つのノードNa2、Nc2、Nd2およびNe2が検出される。次に、子ユニットCUのノードNdに対応する親ノードNdは、上述したように、これらノードNa2、Nc2、Nd2、Ne2の4つのノードの内の3番目に記録されているはずなので、ノードNdの親ノードはNd2であることが分かる。
【0144】
以上のように、データ処理部13は、上位階層に移行した後、その上位階層でステップS103からステップS108までの処理を繰り返し、出発地SP側と目的地DP側の探索がつながった時点で経路探索処理を終了する。
【0145】
以上のように、本願発明で用いる地図データは矩形領域で区切られたユニット単位でファイル化され、かつこれらの各ユニットには、同一階層内の隣接ユニット間においても、上下階層に存在する親子ユニット間においても、他ユニット内の内部データ構造に関係するようなレコード番号や記録アドレス等を一切記録していないため、任意の範囲、任意の階層のユニットファイルを置き換えることにより、地図データの更新を柔軟に行うことができる。
【0146】
「地図ファイルCFの送受信処理」
近年、センタ局2から端末装置1へと地図を提供するようなシステムが研究・開発がされている。かかるシステムにより、端末装置1は、必要な時に必要な地図を得ることができる。そのため、センタ局2の第2の記憶装置24には、一般的に、端末装置1側の第1のデータベース111よりも大規模な第2のデータベース25が準備されている。本実施形態では、第1のデータベース111および第2のデータベース25には、上述したファイルシステムによりいくつかの地図ファイルCFが管理されている。そして、以下に説明するようにして、センタ局2および端末装置1とは地図ファイルCFの送信および受信を行う。
【0147】
まず、端末装置1はセンタ局2に地図ファイルCFの送信を要求する。図43(a)は、端末装置1がある地図ファイルCFの送信をセンタ局2に要求する際の処理手順を示すフローチャートである。また、図43(b)は、図43(a)の処理手順により送信される制御データとしての要求REQのフォーマットを示す図である。端末装置1のユーザは、第1の記憶装置19に、新しい地図ファイルCFを追加したい場合、または、古い地図ファイルCFを新しいものに更新したい場合、入力装置11を操作して、地図の要求・受信機能を起動する。次に、ユーザは、出力装置110のディスプレイに表示されるメニュー画面に従いつつ、入力装置11を操作して、必要な地図の範囲および階層(レベル)を入力する。入力装置11は、ユーザの入力に応答して、地図の範囲および階層を示す情報をデータ処理部13に出力し指定する(ステップS401)。ここで、地図の範囲の入力には、ディスプレイに表示される広域地図に対して所望の範囲をユーザが入力装置11を用いて矩形領域で囲って指定したり、住所索引を使って地域をユーザが入力装置11で指定したりする方法がある。
【0148】
データ処理部13は、入力装置11から出力された範囲および階層の情報が入力されると、当該範囲情報を経度・緯度座標に変換する。データ処理部13は、経度・緯度座標および階層の情報を要求生成部14に出力する。要求生成部14は、入力された経度・緯度座標および階層の情報を用いて、図43(b)に示すフォーマットの要求REQを生成する(ステップS402)。図43(b)において、要求REQは、ユーザが必要とする地図ファイルCFの階層を示す情報と、当該地図ファイルCFが表す地図の範囲を特定する経度・緯度座標とから構成される。ここで、経度・緯度座標は、より具体的には、ユーザが広域地図を矩形領域で囲って指定する場合に、その左下経度座標、左下緯度座標、右上経度座標および右上緯度座標からなる。要求生成部14は、生成した要求REQを第1の送受信部15に出力し、当該第1の送受信部15は、アンテナ16を通じて、入力された要求REQをアップリンクULに送出する(ステップS403)。
【0149】
次にセンタ局2における地図ファイルCFの送信処理について説明する。端末装置1から送出された要求REQは、通信網3のアップリンクULを通じて、センタ局2の第2の送受信部21により受信される。第2の送受信部21は、受信した要求REQを受信要求解析部22に出力する。ここで、図44は、センタ局2が要求REQの受信後に実行する処理手順を示すフローチャートである。受信要求解析部22は、入力された要求REQを解析して、解析結果を読み出し制御部23に出力する。読み出し制御部23は、解析結果により特定される地図ファイルCFを第2のデータベース25から検索する(ステップS501)。ここで、要求REQには、端末装置1が要求した地図ファイルCFの階層(レベル)、および当該地図ファイルCFが表す地図の左下経度座標、左下緯度座標、右上経度座標、および右上緯度座標が記述されている。そこで、受信要求解析部22は、まず、要求REQから左下経度座標および左下緯度座標を取り出し、当該左下経度座標および左下緯度座標を代表点として、図35のフローチャートで示した処理手順に従って、要求された地図ファイルCFのパス名を導出する。
【0150】
次に、受信要求解析部22は、導出したパス名を有する地図ファイルCFが第2の記憶装置24に格納されているか否かを調べる(ステップS502)。地図ファイルCFが格納されていない場合、センタ局2は図44の処理を終了する。一方、地図ファイルCFが格納されている場合、読み出し制御部23は、受信要求解析部22により導出されたパス名を受け取って、当該パス名に従って第2の記憶装置24から、要求された地図ファイルCFを読み出す。読み出し制御部23は、読み出した地図ファイルCFをパケット組み立て部25のメモリに転送する。これによって、パケット組み立て部25は、要求された地図ファイルCFを内部に読み込む(ステップS503)。パケット組み立て部25は、読み込んだ地図ファイルCFを基にパケットPを組み立てて(ステップS504)、第2の送受信部21に出力する。第2の送受信部21は、入力されたパケットPをダウンリンクDLに送出する(ステップS505)。なお、ステップS504の詳細については後述される。
【0151】
ステップS505が終了すると、受信要求解析部22は、要求REQで指定される範囲の地図ファイルCFが第2のデータベース25にさらに存在するか否かを調べるために、前回のステップS501で指定した代表点座標に、要求REQで指定されるレベルの経度幅Wおよび緯度幅Hを加算して、当該加算値を、新しい代表点として設定する。さらに、受信要求解析部22は、新しい代表点の経度座標および緯度座標が要求REQで指定される右上経度座標および右上緯度座標を越えているか否かを判断する。新しい代表点の経度座標および緯度座標が右上経度座標および右上緯度座標を越えていなければ、センタ局2では、引き続きステップS502〜S505を処理が実行され、もう1つの地図ファイルCFを基に組み立てられたパケットPが端末装置1に送信される。新しい代表点の経度座標および緯度座標が右上経度座標および右上緯度座標を越えていれば、要求された地図ファイルCFをすべて端末装置1に送信したとして、センタ局2は図44の処理を終了する。
以上のステップS501〜S505を繰り返すことにより、センタ局2は、端末装置1が要求した通りのレベルおよび範囲の地図を表す地図ファイルCFを当該端末装置1に送信することができる。
【0152】
ここで、図45は、地図ファイルCFからパケットPが組み立てられるまでの過程における、各データの構造を示している。ステップS503の終了時点で、パケット組み立て部25の内部には、図45(a)に示すように、1つの地図ファイルCFが読み込まれている。パケット組み立て部25は、ステップS504を実行する。ここで、図46は、ステップS504の詳細な処理手順を示すフローチャートである。以下、図45および図46を参照して、パケット組み立て部25の処理を詳細に説明する。最初に、パケット組み立て部25は、内部に読み込んだ地図ファイルCFを基に、マスタデータMDを作成する(ステップS601)。マスタデータMDは、図45(b)に示すように、データヘッダDHとデータ部とから構成される。ここで図47は、マスタデータMDの詳細な内部データ構造を示す。図47において、データヘッダDHは、ユニットIDおよびバージョンコードから構成される。
ユニットIDは、このマスタデータMDの基礎となる地図ファイルCFを特定するためのコードである。バージョンコードは、このマスタデータMDの基礎となる地図ファイルCFのフォーマットバージョンおよびコンテンツバージョンを表すコードである。なおユニットID、バージョンコード共に地図ファイルCFのユニットヘッダ(図7参照)に格納されている情報であり、地図ファイルCFがパケット組み立て部25に読み込まれた時点で、当該パケット組み立て部25により取り出され保持される。なお、これらユニットIDとバージョンコードは、後述する端末装置1の処理において使用される。
【0153】
またマスタデータMDのデータ部には、地図ファイルCFそのものが設定される。ところで、地図ファイルCFは、前述したように、各種テーブルから構成される(図7参照)。これら各テーブルには互いに、他のテーブルを参照し合うような情報は記録されない。言い換えれば、端末装置1は各テーブルを独立的に使用することができる。例えば、図8(a)に示すように、端末装置1は、基本背景テーブルのみを出力装置110に表示することができる。つまり、各テーブルは、互いに分離可能なデータ構造を有する。そのため、データ部は、基本背景テーブル、基本文字記号テーブル、主要道ノードテーブル、主要道リンクテーブルの基本データ(つまり、大略的な地図を表すデータ)のみから構成されても良い。また、データ部は、詳細背景テーブル、詳細文字記号テーブル、細街路ノードテーブル、細街路リンクテーブルの詳細データのみから構成されても良い。以上のように、地図ファイルCFの一部分がデータ部に設定される場合がある。
【0154】
なお、図7に示すように、ユニットヘッダには、ユニットIDおよびバージョンコードが含まれる。このユニットIDおよびバージョンコードは、データヘッダDH(図47参照)に含まれる。したがって、マスタデータMDのデータ部に、ユニットIDおよびバージョンコードが設定されると、マスタデータMD内に2個のユニットIDおよびバージョンコードが含まれることになる。そのため、このデータ部にはユニットIDとバージョンコードは含まれなくとも良い。
【0155】
パケット組み立て部25は、以上のようにして生成されたマスタデータMDをi個に分割する。これによって、図45(c)のように、i個のセグメントデータSD1〜SDiが生成される(ステップS602)。このステップS602において、パケット組み立て部25は、マスタデータMDに含まれるデータヘッダDHおよびデータ部(つまり地図ファイルCF)を意識しない。つまり、いずれかのセグメントデータSDに、データヘッダDHの一部と、データ部の一部とが混在する場合も起こりうる。これらi個のセグメントデータSDには、番号(以降、セグメント番号と称す)が付加される。このセグメント番号は、セグメントデータ相互で重複せず、かつ連続する番号であることが好ましい。なぜなら、後述する端末装置1の処理が容易になるからである。
【0156】
さらに、パケット組み立て部25は、i個のセグメントデータSD1〜SDiに、誤り訂正符号(または誤り検出符号)を付加する(ステップS603)。これによって、図45(d)に示すように、i個のセグメントデータ(誤り訂正符号付き)SD1〜SDiが生成される。パケット組み立て部25はさらに、各セグメントデータ(誤り訂正符号付き)SD1〜SDiをj個に分割する。これによって、図45(e)に示すように、1個のセグメントデータSDにつき、j個のパケットが生成される(ステップS604)。以上の処理の結果、パケット組み立て部25は、1つの地図ファイルCFを基に、全部でi×j個のパケットP11,P12,…,P1j,…Pijを生成する。また、これらi×j個のパケットP11,P12,…,P1j,…Pijにはそれぞれ、番号(以降、パケット番号と称す)が付加される。このパケット番号は、パケット毎で互いに重複しないようにかつ連続する番号であることが好ましい。なぜなら、後述する端末装置1の処理が容易になるからである。このパケット番号により、端末装置1は、別々に送信されるi×j個のパケットP11,P12,…,P1j,…Pijが、すべて揃ったかどうかを容易に判断できるようになる。このステップS604が終了すると、パケット組み立て部25は、サブルーチンである図46の処理から抜けて、図44の処理に戻る。そして、ステップS505の処理が行われる。以上の各パケットP11,P12,…,P1j,…Pijは、ステップS505において、第2の送受信部21から、通信網3(ダウンリンクDL)に順次送出され、端末装置1に送信される。
【0157】
次に、図48のフローチャートを参照して、端末装置1における地図ファイルCFの受信手順について説明する。センタ局2より送信された各パケットP11,P12,…,P1j,…,Pijは、通信網3を通じて、端末装置1のアンテナ16に入力される。第1の送受信部15は、アンテナ16から出力されるパケットP11,P12,…,P1j,…Pijを順次受信する(ステップS701)。また、第1の送受信部15は、図示しないバッファメモリを有する。第1の送受信部15は、受信された各パケットP11,P12,…,P1j,…Pijを、バッファメモリに順次格納する。
パケット分解部17は、第1の送受信部15のバッファメモリに定期的にアクセスして、センタ局2により送信されたi×j個のパケットP11,P12,…,P1j,…,Pijがバッファメモリ内に揃っているか否かを判断する(ステップS702)。ステップS702の判断は、各パケットP11,P12,…,P1j,…,Pijに付加されたパケット番号に基づいて行われる。より具体的には、パケット番号が連番であれば、パケット分解部17は、1から(i×j)までのパケット番号が全て揃っているか否かを判断する。
【0158】
ステップS702で、パケットPが全て揃っていない場合、パケット分解部17はステップS703に進まず、ステップS701が再度実行される。その結果、第1の送受信部15は、不足分のパケットPをやがて受信する。
一方、ステップS702で、パケットPが全て揃っている場合、パケット分解部17は、ステップS703に進む。パケット分解部17は、ステップS701で受信されたパケットP11,P12,…,P1j,…PijからマスタデータMDを分解(デアセンブリ)する(ステップS703)。ステップS703の間に、誤り訂正も必要に行われる。分解されたマスタデータMDはデータ処理部13に出力される。データ処理部13は、入力されたマスタデータMDを基に地図ファイルCFを作成して、作成した地図ファイルCFを読み出し/書き込み制御部18と協働してを第1の記憶装置19に格納する(ステップS704)。
【0159】
ステップS704の後、データ処理部25は、受信すべき一連のパケットPがまだあるか否かを判断する(ステップS705)。受信すべきパケットPがある場合、ステップS701に戻り、パケットPの受信処理が引き続き行われる。一方、受信すべきパケットPがない場合には、図48の処理を終了する。
ここで、図49は、図48のステップS703の詳細な処理手順を示すフローチャートである。また、図50は、パケットP11,P12,…,P1j,…Pijから地図ファイルCFが作成されるまでの過程における各データの構造を示している。上述から明らかなように、図48のステップS703が開始される時点で、第1の送受信部15には、図50(a)に示すように、一連のパケットP11,P12,…,P1j,…,Pijが揃っている。パケット分解部17は、第1の送受信部15にバッファされているパケットP11,P12,…,P1j,…,Pijから、処理すべきパケットPを得る(ステップS801)。今、パケット分解部17はパケットP11,P12,…,P1jを得ると仮定する。
【0160】
次に、パケット分解部17は、ステップS801で得られた各パケットPからパケット番号を外す。パケット分解部17は、番号が外された各パケットPを一まとめにして、図50(b)に示すように、1つのセグメントデータSDを復元する(ステップS802)。上述の仮定に従うと、パケットP11,P12,…,P1jが一まとめにされ、その結果、セグメントデータSD1が復元される。
各セグメントデータSDには誤り訂正符号(または誤り検出符号)が付加されている。ステップS802の次に、パケット分解部17は、誤り訂正符号を利用して、復元されたセグメントデータ(誤り訂正符号付き)SDに生じている可能性がある誤りを訂正する(ステップS803)。
次に、パケット分解部17は、セグメントデータ(誤り訂正符号付き)SDから誤り訂正符号を外し、これによって、図50(c)に示すように、セグメントデータ(誤り訂正符号なし)SDが復元される(ステップS804)。復元されたセグメントデータSDは、パケット分解部17の記憶領域に保持される。上述の仮定に従うと、セグメントデータSD1に誤り訂正が施された後、パケット分解部17の記憶領域に保持される。
【0161】
ステップS804の次に、パケット分解部17は、第1の送受信部15内に、処理すべきパケットPが残っているか否かを判断する(ステップS805)。処理すべきパケットPが残っている場合、パケット分解部17はステップS801に戻って、ステップS801〜S804を行って、図50(a)〜(c)に示すように、パケットPからセグメントデータSDを復元する。本説明では、図49の処理の開始時点で、第1の送受信部15には、(i×j)個のパケットPがある。したがって、ステップS701〜S705で構成されるループはi回繰り返される。その結果、i個のセグメントデータSD1〜SDiが復元される。
このループが必要回数だけ繰り返されると、第1の送受信部15内には、処理すべきパケットPがなくなる。この状態で、ステップS805の判断が行われると、パケット分解部17は、ステップS806に進む。処理すべきパケットPがなくなった時点で、i個のセグメントデータSD1〜SDiがパケット分解部17に保持される。また、上述したように、各セグメントデータSD1〜SDiには、セグメント番号が付されている。パケット分解部17は、このセグメント番号に従って、つまりセグメント番号が連続するように、セグメントデータSD1〜SDiを順番に並べる。その後、セグメント番号は、各セグメントデータSD1〜SDiから取り外される。パケット分解部17は、セグメント番号が取り外されたセグメントデータSD1〜SDiを一まとめにする。その結果、図50(d)に示すように、マスタデータMDが復元される(ステップS806)。復元されたマスタデータMDは、データ処理部13に出力される(ステップS807)。
【0162】
なお、本地図提供システムに限らず、通信システムでは通信障害が起こりうる。したがって、端末装置1は、全てのセグメントデータSDを正しく復元できるとは限らない。ここで、正しく復元されたセグメントデータSDとは、センタ局2が生成したものと同じセグメントデータSDを意味する。例えば、セグメントデータSD2が正しく復元されなかった場合であって、他のセグメントデータSD1、SD3〜SDiが正しく復号された場合を想定する。かかる場合、パケット分解部17は、セグメントデータSD1、SD3〜SDiに付加された誤り訂正符号を利用して、セグメントデータSD2を正しいものに復元することもできる。
【0163】
データ処理部13は、マスタデータMDの入力に起因して、ステップS704を開始する。このステップS704は、上述したように、マスタデータMDから地図ファイルCFを作成する処理と、作成された地図ファイルCFを第1の記憶装置19に格納するための処理である。ここで、図51は、図48のステップS704の詳細な処理の手順を示すフローチャートである。
まず、データ処理部13は、入力されたマスタデータMDのデータヘッダDHから、ユニットIDを取り出す(ステップS901)。前述のようにユニットIDは、当該ユニットのパス名と相互に変換できるように付与されている。データ処理部13は、取り出したユニットIDから、マスタデータMD内の地図ファイルCFのパス名を導出する。
【0164】
データ処理部13は、ステップS902で導出したパス名をもつ地図ファイルCFが既に、第1の記憶装置19内に格納されているかどうかを判断する(ステップS903)。もし格納されていなければ、データ処理部13は、マスタデータMDからデータヘッダDHを取り外して、地図ファイルCFを得る。そして、データ処理部13は、導出したパス名および今回受信した地図ファイルCFとを読み出し/書き込み制御部18に転送する。読み出し/書き込み制御部18は、転送されてきたパス名に従って、今回受信した地図ファイルCFを第1の記憶装置19に格納する。これによって、第1のデータベース111には、新しい地図ファイルCFが追加されることとなる。
【0165】
一方、ステップS903において、ステップS902で導出したパス名をもつ地図ファイルCFが、第1の記憶装置19内に既に存在すると判断された場合の処理について説明する。この場合、データ処理部13は、ステップS904に進んで、マスタデータMDのデータヘッダDH内に格納されているバージョンコードを取り出す。さらに、データ処理部13は、読み出し/書き込み制御部18と協働して、ステップS902で導出したパス名を持つ地図ファイルCFを第1の記憶装置19から読み込む。データ処理部13は、第1の記憶装置19から読み込んだ地図ファイルCFのユニットヘッダ内に記録されたバージョンコードを取り出し、ステップS904で取り出したバージョンコードと比較する。データ処理部13は、マスタデータMDから取り出したバージョンコードの方が新しいと判断された場合には、ステップS906に進み、マスタデータMDのデータ部のみを取り出して、新しいバージョンの地図ファイルCFを第1の記憶装置19に格納する。これによって、第1のデータベース111において、古い地図ファイルCFは、新しいものに更新される。
【0166】
逆に、データ処理部13は、第1の記憶装置19から読み込んだ地図ファイルCFの方が新しいと判断した場合には、受信したマスタデータMDを破棄する。つまり、今回受信した地図ファイルCFは第1の記憶装置19には格納されない。
以上のように、本実施形態に係る地図ファイルCFは、複数の縮尺の地図をユニット単位で区切ってデジタルデータ化されることにより生成される。各地図ファイルCFの記録領域(論理領域)は、その親子関係および隣接関係を表すツリー構造で特定されるパス名で表現される。これによって、各地図ファイルCFは効率的に管理される。これによって、1つのユニットUには、他のユニットのデータ構造に関連する情報が記録されないので、複数のユニットUの間の関係が薄くなる。これによって、ある1つの地図ファイルCFを更新した場合であっても、それ以外の地図ファイルCFを更新する必要がなくなる。このように、本実施形態に係る地図ファイルCFによれば、第1の記憶装置19における地図ファイルCFの新規格納処理および更新処理が非常に簡単になる。
【0167】
また、このような各地図ファイルCFにおいて、互いに隣接するユニットUの境界をまたがる道路網の接続をたどる際に、データ処理部13は、脱出ノードおよび進入ノードの座標情報、ならびに/もしくは脱出リンクおよび進入リンクの属性情報を参照する。つまり、データ処理部13は、隣接ユニットNUに記録されたノードNまたはリンクLのレコード番号またはオフセットアドレスのような、隣接ユニットNUの内部データ構造に関わる情報を参照しない。そのため、第1の記憶装置19内のある1つの地図ファイルCFが更新された場合においても、隣接ユニットNUの地図ファイルCFを更新することなく、互いに隣接し合う地図ファイルCFの道路網の接続を正確にたどることができる。
【0168】
また、本実施形態では、あるユニットUおよび隣接ユニットNUの境界をまたがる道路網の接続をたどる際に、隣接ユニットNU側の進入ノードおよび進入リンクを検索する必要が出てくる。しかしながら、各ユニットUにおいて、ノードレコードNRおよびリンクレコードLRの並び方は予め規定されている。これによって、進入ノードおよび進入リンクの検索処理を高速化することができる。
【0169】
また、本実施形態では、経路探索処理において、データ処理部13は、下位階層のあるノードNから、それと同じ位置を示すノードNを上位階層の地図ファイルCFから探し出す場合がある。この場合においても、上下階層のユニットUの間においても、子ユニットCU側に親ユニットPUの内部データ構造に関わる情報が記録されず、親ユニットPU側に子ユニットCUの内部データ構造に関わるような情報が記録されないので、上位の階層の地図ファイルCFだけが更新されたような場合においても、その子ユニットCUを表す地図ファイルCFを全て更新するような必要性は生じない。
【0170】
また以上のように、ユニットUのように部分的な領域の地図だけが新しいものに更新されたような場合においても、隣接ユニット間および上下階層間でのデータの整合性は保持されるため、センタ局2が端末装置1などに有線あるいは無線で地図ファイルCFを提供する場合においても、端末装置1が必要とする地図ファイルCFのみを送信することができる。これによって、データ送信時間および通信コストの低減につながる。
【0171】
なお、以上の実施形態は、端末装置1の一例としてカーナビゲーションシステムを想定して説明した。しかし、パーソナルコンピュータ内に地図ファイルCFのデータベースを作成して、当該パーソナルコンピュータが地図を表示したり、経路探索を行ったりするような用途にも、本実施形態は適用することができる。つまり、本実施形態は、移動可能な端末装置に限らず、据え置き型の端末装置にも適用することができる。
また、据え置き型の端末装置に対しては、通信網3は無線伝送路である必要性はなく、有線であってもよい。
【0172】
なお、本実施形態では、端末装置1は、センタ局2と通信網3を通して双方向通信を行って、ユーザが必要とする地図の範囲をセンタ局2に通知し、当該範囲に対応する地図ファイルCFを受信していた。しかし、センタ局2は、放送形式で、地図ファイルCFを端末装置1に送信してもよい。
【0173】
なお、本実施形態では、第1のデータベース111および第2のデータベース25は、レベル「0」〜「3」までの4段階の階層構造を有する地図ファイルCFから構成されていた。しかし、第1のデータベース111および第2のデータベース25は、4階層に限らず、何階層の地図ファイルCFから構成されても構わない。
また、本実施形態では、各階層地図は経度方向および緯度方向に等間隔に分割され、これによって矩形領域(ユニットU)が形成されていた。しかし、各階層の地図ファイルCFのデータ量がほぼ一定になるように、各階層地図は、経度方向および緯度方向に様々な間隔で分割されてもよい。ただし、この場合、各地図ファイルCFには、経度方向および緯度方向に沿う分割サイズを特定する情報を付加する必要がある。
【0174】
また、本実施形態では、地図ファイルCFは、ユニットU単位で作成されていた。しかし、地図ファイルCFは、複数のユニットUと、当該複数のユニットUを管理するための管理情報とから構成されてもよい。この場合、地図ファイルCFの更新の容易さを確保するために、1つの地図ファイルCFにまとめるユニットUの個数は最大64個程度で、かつまとめられたユニットUを管理するための管理情報は複雑にならないようにすることが望ましい。
【0175】
また、1つの地図ファイルCFにおいて、隣接ノードのノードレコードNRは、当該ユニットUの境界を一周するような順序で記録されてもよい。今、記録順序の一例として、隣接ノードのノードレコードNRは、ユニットUの左下隅から時計周りの順序に従って記録されると仮定する。この仮定下では、図39に示すユニットU1に含まれる隣接ノードのノードレコードNRは、「N10」→「N11」→「N12」→「N13」→「N14」→「N15」→「N18」→「N17」→「N16」→「N20」→「N19」という順序で記録される。また、ユニットU3に含まれる隣接ノードのノードレコードNRは、「N30」→「N31」→「N32」→「N34」→「N33」→「N38」→「N37」→「N36」→「N35」という順序で記録される。さらに、ユニットU2に含まれる隣接ノードのノードレコードNRは、「N20」→「N21」→「N22」→「N23」→「N24」→「N25」→「N27」→「N26」という順序で記録される。今、具体例として、データ処理部13が、隣接ノードN14およびN15に対応する隣接ノードN37およびN38を検索する場合について説明する。上述したように、ユニットU1の地図ファイルCFでは隣接ノードN14→N15の順序でノードレコードNRは記録される。一方、ユニットU3の地図ファイルCFでは隣接ノードN38→N37の順序でノードレコードNRは記録される。したがって、データ処理部13が隣接ノードN14に対応する隣接ノードN37を探し出せれば、隣接ノードN15に対応する隣接ノードは、隣接ノードN37のノードレコードNRの一つ手前に記録されている。そのため、データ処理部13は、隣接ノードN15に対応する隣接ノードをいち早く探し出すことができる。このように、隣接ノードのノードレコードNRがユニットUの境界を一周するような順序で記録されることにより、あるユニットNとその隣接ユニットとの境界上に並ぶ隣接ノードは、それぞれの地図ファイルCFにおいて互いに逆順に連続して並ぶこととなるので、データ処理部13は、あるユニットの隣接ノートに対応する隣接ユニットの隣接ノードを高速に見つけることができる。
【0176】
「第2の実施形態」
図52は、本発明の第2の実施形態に係る地図提供システムの構成を示す。本地図提供システムには、センタ局101と端末装置102とが収容される。センタ局101と端末装置102とは無線伝送路103により接続される。無線伝送路103には、センタ局101から端末装置102へのダウンリンクが少なくとも形成される。センタ局101は、地図サーバ1011と、アンテナ1012とを備える。地図サーバ1011には、第1の記憶装置1013と、読み出し制御部1014と、パケット組み立て部1015と、送信部1016とを含む。端末装置102は、典型的には、カーナビゲーションシステムであって、アンテナ1021と、受信部1022と、パケット分解部1024およびファイル管理部1025を含むデータ処理部1023と、第2の記憶装置1026とを備える。
【0177】
次に、センタ局101の構成を説明する。第1の記憶装置1013には、端末装置102に提供可能な地図ファイルCFが1つ以上蓄積される。地図ファイルCFの詳細は後述される。第1の記憶装置1013は、典型的には、ハードディスクドライブ、CD-ROMドライブまたはDVD-ROMドライブから構成される。
読み出し制御部1014は、必要に応じて第1の記憶装置1013から、地図ファイルCFの一部分を、端末装置102に提供すべき地図データCDとして読み出す。この地図データCDの詳細は後述される。読み出された地図データCDは、パケット組み立て部1015に出力される。
【0178】
パケット組み立て部1015は、入力された地図データCDを基にパケットPを組み立てる(アセンブリする)。パケット組み立て部1015の詳細な処理およびパケットPの形式は、後述される。組み立てられたパケットPは送信部1016に出力される。
送信部1016は、入力されたパケットPを、アンテナ1012を通じて無線伝送路103に送り出し、これによって、地図データCDはパケットPとして端末装置102に送信される。送信部1016およびアンテナ1012は、典型的には、携帯電話等の移動体通信装置、もしくは、地上波デジタル放送または衛星デジタル放送等の放送装置により実現される。
【0179】
次に、端末装置102の構成について説明する。受信部1022は、センタ局101により送信されたパケットPを、無線伝送路103を通じて受信する。アンテナ1021および受信部1022は、典型的には、携帯電話等の移動体通信装置、もしくは、地上波デジタル放送または衛星デジタル放送等の受信装置を用いて実現される。受信部1022は、受信したパケットPをパケット分解部1024に出力する。
パケット分解部1024は、入力されたパケットPを分解(デアセンブリ)して、地図データCDを復元する。復元された地図データCDはファイル管理部1025に出力される。
ファイル管理部1025は、入力された地図データCDを、予め定められた手順に従って処理する。この処理の手順は後述される。この処理により、地図ファイルCFが作成される。地図ファイルCFは、センタ局101側の地図ファイルCF地図データと同様の構造を有する。地図ファイルCFの詳細は後述される。
第2の記憶装置1026は、読み出しおよび書き込みが可能で、大容量の記憶媒体を有する。第2の記憶装置1026は、典型的には、HDD、DVD-RAM駆動装置により構成される。この記憶媒体上に、ファイル管理部1025により生成された地図ファイルCFが書き込まれる。また、周知のように、第2の記憶装置1026はクラスタ単位で記憶領域を管理する。
【0180】
なお、データ処理部1023は、上記復号やファイル管理以外にも、様々な処理(例えば、経路探索、マップマッチングまたは経路案内)を行う。さらに、データ処理部1023は、必要に応じて、第2の記憶装置1026内の地図ファイルCFを部分的に取り出して、後述する出力装置に出力する。また、端末装置102は、図示された構成以外にも、入力装置および出力装置を備える。しかし、これらの処理、入力装置および出力装置は、本願発明のポイントではなく詳説されず、さらに図示もされない。
入力装置および出力装置を簡単に説明する。入力装置は、端末装置102のユーザにより操作される。ユーザは、入力装置を通じて、地図のスクロールまたは縮尺変更等を、端末装置102に対して要求する。また、出力装置は、主として、ディスプレイおよびスピーカから構成される。ディスプレイには、必要に応じて地図が表示される。さらに、ディスプレイには、データ処理部1023が行った経路探索処理または経路案内処理の結果も表示する場合がある。スピーカは、データ処理部1023が行った経路案内処理の結果を音声によりユーザに提供する。
【0181】
次に、図53を参照して、各地図ファイルCFの構造を説明する。まず、図53(a)のように、ある範囲の地図αは、予め定めされた形状(本実施形態では便宜上、矩形形状とされる)のM×N個(MおよびNは任意の自然数)の領域に区画され、ユニットU0,0〜UM-1,N-1が作成される。ユニットU0,0〜UM-1,N-1はそれぞれデータ化され、ユニットデータUD0,0〜UDM-1,N-1が生成される。ユニットデータUD0,0〜UDM-1,N-1は、後述するユニットレコードUR0,0〜URM-1,N-1の一部を構成する。地図ファイルCFは、各ユニットU0,0〜UM-1,N-1を基に作成され、第1の記憶装置1013の所定アドレス領域に格納される。
【0182】
各地図ファイルCFは、図53(b)のように、ファイルヘッダFHと、ユニット管理情報MIUNITと、M×N個のユニットレコードUR0,0〜URM-1,N-1とから構成される。ファイルヘッダFHには、地図ファイルCF(地図α)がカバーする範囲を特定するための情報が記述される。より具体的には、ファイルヘッダFHは、最小の緯度LATMINおよび経度LONMIN、最大の緯度LATMAXおよび経度LONMAX、緯度方向の実距離DLAT、および経度方向の実距離DLONとを含む。ここで、LATMIN、LONMIN、LATMAXおよびLONMAXは、図53(a)に示すように、地図αの最小緯度、最小経度、最大緯度および最大経度を示す。また、DLATおよびDLONは、図53(a)に示すように、地図αの緯度方向および経度方向の実際の距離を示す。このように、LATMIN、LONMIN、LATMAX、LONMAX、DLAT、およびDLONは、地図ファイルCF(つまり地図α)がカバーする範囲を規定する。
ユニット管理情報MIUNITには、各ユニットレコードUR0,0〜URM-1,N-1を管理するための情報が記述される。より具体的には、ユニット管理情報MIUNITは、地図ファイルCFに含まれるユニットレコードの数NOUと、各ユニットレコードのオフセット値X0,0〜XM-1,N-1とを含む。ここで、NOUは、M×Nの値である。このオフセット値X0,0〜XM-1,N-1は、この地図ファイルCFが格納されている先頭のアドレス(第1の記憶装置1013における格納位置)から、各ユニットレコードUR0,0〜URM-1,N-1が格納される先頭アドレスまでのオフセットである。図53(b)には、ユニットレコードUR0,0のオフセット値X0,0が例示されている。
【0183】
各ユニットレコードUR0,0〜URM-1,N-1は、ユニット管理情報MIUNITのオフセット値X0〜XN-1により特定されるアドレスを基準にして、第1の記憶装置1013の記憶媒体に格納される。また、ユニットレコードUR0,0〜URM-1,N-1は、図54のように、ユニットデータUD0,0〜UDM-1,N-1を含む。また、各ユニットデータUD0,0〜UDM-1,N-1には、ユニットヘッダUH0,0〜UHM-1,N-1が付加される。これによって、各ユニットレコードUR0,0〜URM-1,N-1が構成される。
以下、各ユニットレコードURを具体的に説明するために、ユニットレコードUR0,0を例に採り上げる。まず、ユニットデータUD0,0は、図53に示すように、地図αが区画された領域の一つをデータ化したものであり、対応するユニットU0,0が表す領域の地図を構成する実データである。なお、以下、説明を明確にするため、ユニットU0,0が表す領域の地図を地図β0,0と記す。ユニットデータUD0,0は、より具体的には、地図β0,0について、背景データBD0,0、文字記号データCD0,0、および道路ネットワークデータND0,0から構成される。
【0184】
背景データBD0,0は、地図β0,0上の河川、鉄道、緑地帯、建造物、橋等を表示するための図形データである。背景データBD0,0は、図54に示すように、基本背景データテーブルBBD0,0と、詳細背景データテーブルDBD0,0とから構成される。基本背景データテーブルBBD0,0には、図55(a)に示すように、河川、鉄道および緑地帯等、地図β0,0上の基本的な要素(つまり背景)を表示するための図形データが記録される。詳細背景データテーブルDBD0,0には、地図β0,0の基本的な背景をより詳細に表示するために、図55(b)のように、建造物、橋等の図形データが記録される。
【0185】
また、基本背景データテーブルBBD0,0および詳細背景データテーブルDBD0,0は、図54に示すように互いに独立した構造を有する。これによって、センタ局101と端末装置102とは、基本背景データテーブルBBD0,0および詳細背景データテーブルDBD0,0を分離して、独立的に用いることが可能となる。つまり、端末装置102は、図55(a)のように、基本背景データテーブルBBD0,0を単体で表示することができる。さらに、端末装置102は、図55(c)のように、基本背景データテーブルBBD0,0に詳細背景データテーブルDBD0,0を重畳して表示することもできる。
また、地図β0,0の背景は、基本背景データテーブルBBD0,0が表示するものと、詳細背景データテーブルDBD0,0が表示するものとが重畳されることにより構成される。つまり、見方を変えれば、詳細背景データテーブルDBD0,0は、背景データBD0,0と、基本背景データテーブルBBD0,0との差分データである。
【0186】
また、文字記号データCD0,0は、地図β0,0上の文字列および/または地図記号を表すデータである。この文字記号データCD0,0により、地名、道路名称、施設名称、地図記号等が地図β0,0上に表示される。文字記号データCD0,0は、図54に示すように、基本文字記号データテーブルBCD0,0と、詳細文字記号データテーブルDCD0,0とから構成される。基本文字記号データテーブルBCD0,0には、図56(a)に示すように、地名、道路名称、地図記号等、地図β0,0を構成するための基本的なデータが記録される。詳細文字記号データテーブルDCD0,0には、図56(b)のように、公園、鉄道、橋および工場の名称等、地図β0,0を詳細に表示するために必要なデータが記録される。
【0187】
また、基本文字記号データテーブルBCD0,0および詳細文字記号データテーブルDCD0,0は、図54に示すように互いに独立した構造を有する。これによって、基本文字記号データテーブルBCD0,0および詳細文字記号データテーブルDCD0,0は独立的に用いられることが可能となる。つまり、端末装置102が、図56(a)のように、基本文字記号データテーブルBCD0,0を単体で表示したり、図56(c)のように、基本文字記号データテーブルBCD0,0に詳細文字記号データテーブルDCD0,0を重畳して表示したりできる。
また、詳細文字記号データテーブルDCD0,0は、文字記号データCD0,0と、基本文字記号データテーブルBCD0,0との差分データである。
【0188】
さらに、道路ネットワークデータND0,0は、背景データBD0,0および文字記号データCD0,0と共に用いられ、地図β0,0上に道路を表示するためのデータである。この道路ネットワークデータND0,0はさらに、マップマッチング、経路探索または経路案内の各処理に使用される場合もある。道路ネットワークデータND0,0は、主要幹線ネットワークデータテーブルMND0,0と細街路ネットワークデータテーブルSND0,0とから構成される。主要幹線ネットワークデータテーブルMND0,0には、図57(a)に示すように、幅員が相対的に広い(例えば5.5m以上)道路、つまり主要道路用の道路ネットワークデータが記録される。さらに、主要幹線ネットワークデータテーブルMND0,0には、道路ネットワークデータが、高速道路、一般国道および都道府県道等の道路種別毎に記録されることが好ましい。細街路ネットワークデータテーブルSND0,0には、図57(b)に示すように、幅員が相対的に狭い(例えば、3.0m以上かつ5.5m未満)道路、つまり細街路用の道路ネットワークデータが記録される。
【0189】
また、主要幹線ネットワークデータテーブルMND0,0および細街路ネットワークデータテーブルSND0,0もまた、基本背景データテーブルBBD0,0および詳細背景データテーブルDBD0,0と同様の独立的な構造を有している。そのため、端末装置102は、図57(a)のように、主要幹線ネットワークデータテーブルMND0,0を単体で用いて、主要道路のみを表示させることができる。また、端末装置102は、図57(b)のように、細街路ネットワークデータテーブルSND0,0を単体で用いて、細街路のみを表示させることもできる。さらに、端末装置102は、図57(c)のように、主要幹線ネットワークデータテーブルMND0,0に細街路ネットワークデータテーブルSND0,0を重畳して用いて、主要道路および細街路を表示させたりすることができる。
また、細街路ネットワークデータテーブルSND0,0は、道路ネットワークデータND0,0と、主要幹線ネットワークデータテーブルMND0,0との差分データである。
【0190】
なお、端末装置102は、マップマッチング処理等の際に、主要幹線ネットワークデータテーブルMND0,0を単独で用いたり、主要幹線ネットワークデータテーブルおよび細街路ネットワークデータテーブルSND0,0の両方を用いたりすることもできる。
また、主要道路と細街路との接続関係を辿る場合にも、主要幹線ネットワークデータテーブルMND0,0および細街路ネットワークデータテーブルSND0,0が用いられる。かかる接続関係を辿る場合、主要道路と細街路との交差点を示すノードが用いられる。
【0191】
また、図58(a)のように、基本背景データテーブルBBD0,0と、基本文字記号データテーブルBCD0,0と、主要幹線ネットワークデータテーブルMND0,0とが重畳され、これによって、端末装置102は、相対的に粗い地図β0,0を作成することができる。一方、詳細背景データテーブルDBD0,0、詳細文字記号データテーブルDCD0,0、および細街路ネットワークデータテーブルSND0,0が、図58(a)のように構成された粗い地図β0,0に重ね合わされることにより、図58(b)のような、より詳細な地図β0,0を構成することができる。
【0192】
以上、ユニットデータUD0,0の詳細な構造について説明した。他のユニットデータUD0,1、…UD0,N-1、UD1,0、…UDM-1,N-1もまた、ユニットデータUD0,0と同様に、対応する範囲について、図54〜図58を参照して説明したような構造を有する。
【0193】
また、ユニットレコードUR0,0〜URM-1,N-1は、上述したように、ユニットヘッダUH0,0〜UHM-1,N-1を含む。ユニットヘッダUH0,0〜UHM-1,N-1には、ユニットデータUD0,0〜UDM-1,N-1の属性情報が記述される。より具体的には、例えばユニットヘッダUH0,0には、ユニットデータUD0,0を特定するためユニットIDと、基本背景データテーブルBBD0,0、詳細背景データテーブルDBD0,0、基本文字記号データテーブルBCD0,0、詳細文字記号データテーブルDCD0,0、主要幹線ネットワークデータテーブルMND0,0および細街路ネットワークデータテーブルSND0,0のサイズとが記述される。他のユニットヘッダUH0,1〜UHM-1,N-1もまた、ユニットヘッダUH0,0と同様に、対応するユニットデータUD0,1〜UDM-1,N-1の属性情報が記述される。ユニットヘッダUH0,0〜UHM-1,N-1内の各ユニットIDは、対応するユニットデータUD0,0〜UDM-1,N-1を特定さえできれば、どのような情報でもよいが、連続番号または、経度および緯度等によりこれらを特定することが典型的である。
【0194】
次に、図59のフローチャートを参照して、センタ局101における地図データの送信手順について説明する。上述したように、第1の記憶装置1013には、1つ以上の地図ファイルCF(図53および図54参照)が予め格納されている。読み出し制御部1014は、必要に応じて、第1の記憶装置1013から、予め定められたいくつかの地図ファイルCFの一部またはすべてを読み出す(ステップS1001)。ここで、地図ファイルCFの一部とは、本実施形態では、地図ファイルCFを構成するファイルヘッダFH、ユニット管理情報MIUNITおよびいくつかのユニットレコードURを意味する。一方、地図ファイルCFのすべてとは、本実施形態では、地図ファイルCFを構成するファイルヘッダFH、ユニット管理情報MIUNITおよびすべてのユニットレコードURを意味する。以下では、読み出し制御部1014により読み出された一部またはすべての地図ファイルCFを地図データCDと称する。読み出された地図データCDは、パケット組み立て部1015内の記憶領域(典型的にはRAM)に展開される。
【0195】
パケット組み立て部1015は、ステップS1001の後、内部の記憶領域に展開された地図データCDから、端末装置102に送信するために必要なファイルヘッダFH、ユニット管理情報MIUNIT(図53(b)参照)および1つのユニットレコードUR(図53(b)参照)を取り出す(ステップS1002)。
【0196】
パケット組み立て部1015は、ステップS1002で得られたユニットレコードUR、ファイルヘッダFH、およびユニット管理情報MIUNITを基に、パケットPを組み立てる(ステップS1003)。なお、ステップS1003の詳細な処理は後述される。組み立てられたパケットPは、送信部1016に出力される。送信部1016は、入力されたパケットPを、アンテナ1012を通じて無線伝送路103に送出して、パケットPを端末装置102に送信する(ステップS1004)。
【0197】
パケット組み立て部1015は、ステップS1004の次に、内部の記憶領域に展開された地図データCDに、送信すべきユニットデータUDがさらに存在するか否かを判断する(ステップS1005)。送信すべきユニットデータUDがまだ存在する場合には、パケット組み立て部1015は、必要なデータを得るために、ステップS1002に戻る。一方、送信すべきユニットデータUDが存在しない場合には、パケット組み立て部1015は読み出し制御部1014にその旨を通知する。
【0198】
読み出し制御部1014は、パケット組み立て部1015の通知に応答して、ステップS1001で読み出された地図データCDを閉じる(ステップS1006)。次に、読み出し制御部1014は、端末装置102に送信すべきユニットデータUDを含む地図データCD(ステップS1006で閉じられたものとは別のもの)が存在するか否かを判断する(ステップS1007)。別の地図データCDが存在する場合、読み出し制御部1014は、当該地図データCDを読み出すべく、ステップS1001に戻る。一方、別の地図データCDがない場合には、センタ局101は、図59のフローチャートに示された一連の処理を終了する。
【0199】
ここで、図60は、地図データCDからパケットPが生成されるまでの過程における、各データの構造を示している。
ステップS1001(図59参照)の終了時点で、読み出し制御部1014は、図60(a)に示すように、地図データCDを読み出している。また、ステップS1002の終了時点で、パケット組み立て部1015は、ファイルヘッダFHおよびいくつかのユニットレコードURを保持している。図60(a)では、ユニットレコードUR0,0が保持される例が示されている。そして、パケット組み立て部1015は、ステップS1003を実行する。ここで、図61は、ステップS1003の詳細な処理の手順を示すフローチャートである。以下、図61を参照して、パケット組み立て部1015の処理を詳細に説明する。最初に、マスタデータMDが、パケット組み立て部1015により保持されているファイルヘッダFH、ユニット管理情報MIUNIT、および1つのユニットレコードURに基づいて生成される(ステップS1101)。なお、マスタデータMDは、地図ファイルCFから直接的に生成されるのではなく、パケット組み立て部1015が保持する1つのユニットレコードURに基づいて生成される。かかる生成方法が採用されることにより、たとえ、図59のステップS1001〜S1007において、外部的あるいは内部的要因によってエラーが発生しても、そのエラーの影響は、1個のユニットレコードURにしか及ばないからである。つまり、エラーの影響が地図データCD全体に及ぶことを避けるためである。
【0200】
マスタデータMDは、図60(b)に示すように、データヘッダDHとデータ部とから構成される。ここで、図62は、マスタデータMDの詳細な構造を示す。図62において、データヘッダDHは、ファイルID、ユニットIDおよびユニットサイズから構成される。
ファイルIDは、このマスタデータMDの基礎となる地図データCD(つまり、現在、パケット組み立て部1015に展開されているもの)を特定するためのコードである。このファイルIDの生成方法の一例を説明する。パケット組み立て部1015は、ファイルヘッダFHを保持している。前述したように、ファイルヘッダFHには、地図ファイルCF(地図α)がカバーする範囲を特定するための情報が記述される(図53(b)参照)。したがって、ファイルヘッダFHは、地図ファイルCFを特定することも可能である。パケット組み立て部1015は、このファイルヘッダFHを用いて、ファイルIDを生成する。
ユニットIDは、このマスタデータMDの基礎となるユニットレコードUR(つまり、ステップS1002で抜き出されたもの)を特定するためのコードである。パケット組み立て部1015は、ステップS1002の終了以降、送信すべきユニットレコードUR(図54参照)を保持している。パケット組み立て部1015は、保持されたユニットレコードURから、ユニットIDを取り出す。取り出されたユニットIDが、データヘッダDHに設定される。
なお、以上の2つのIDおよびユニットサイズは、後述する端末装置102の処理において使用される。
【0201】
また、マスタデータMDのデータ部には、ファイルヘッダFHと、ユニットレコードURが有する全データまたは一部のデータが設定される。設定されるファイルヘッダFHおよびユニットレコードURは、パケット組み立て部1015が保持しているものである。ところで、ユニットレコードURには、前述したように、各種テーブルが保持される(図54参照)。これら各テーブルは、互いに分離可能な構造を有する。そのため、データ部は、基本背景データテーブルBBD、基本文字記号データテーブルBCD、主要幹線ネットワークデータテーブルMNDの基本データ(つまり、大略的な地図を表すデータ)のみから構成されても良い。また、データ部は、詳細背景データテーブルDBD、詳細文字記号データテーブルDCD、細街路ネットワークデータテーブルSNDの詳細データのみから構成されても良い。以上のように、ユニットレコードURの一部分がデータ部に設定される場合がある。
なお、図54に示すように、ユニットヘッダUHには、ユニットIDが含まれる。このユニットIDは、データヘッダDH(図62参照)に含まれる。したがって、マスタデータMDのデータ部に、ユニットIDが設定されると、マスタデータMD内に2個のユニットIDが含まれることになる。そのため、このデータ部にはユニットIDが含まれなくとも良い。
【0202】
ところで、データヘッダDHのデータサイズは、データ部のサイズである。ファイルヘッダFHと、ユニットレコードURの全体とのサイズは、第1の記憶装置1013に地図ファイルCFが生成された時点で決まるので、容易に求められる。また、データ部に、部分的なユニットレコードURが設定される場合には、対応するユニットヘッダUHに設定されている各サイズに基づいて、当該部分的なユニットレコードURのサイズは求められる。
【0203】
パケット組み立て部1015は、生成されたマスタデータMDをi個に分割する。これによって、図60(c)のように、i個のセグメントデータSD1〜SDiが生成される(ステップS1102)。このステップS1102において、パケット組み立て部1015は、マスタデータMDに含まれるデータヘッダDHおよびデータ部(つまりユニットレコードUR)を意識しない。つまり、いずれかのセグメントデータSDに、データヘッダDHの一部と、データ部の一部とが混在する場合も起こりうる。これらi個のセグメントデータSDには、番号(以降、セグメント番号と称す)が付加される。このセグメント番号は、セグメントデータ相互で重複せず、かつ連続する番号であることが好ましい。なぜなら、後述する端末装置102の処理が容易になるからである。
【0204】
さらに、パケット組み立て部1015は、i個の各セグメントデータSD1〜SDiに、誤り訂正符号(または誤り検出符号)を付加する(ステップS1103)。これによって、図60(d)に示すように、i個のセグメントデータ(誤り訂正符号付き)SD1〜SDiが生成される。パケット組み立て部1015はさらに、各セグメントデータ(誤り訂正符号付き)SD1〜SDiをj個に分割する。これによって、図60(e)に示すように、1個のセグメントデータSDにつき、j個のパケットが生成される(ステップS1104)。以上の処理の結果、パケット組み立て部1015は、ステップS1002で抜き出された1つのユニットレコードURを基に、全部でi×j個のパケットP11、P12、…P1j、…Pijを生成する。また、これらi×j個のパケットP11、P12、…P1j、…Pijにはそれぞれ、番号(以降、パケット番号と称す)が付加される。このパケット番号は、パケット毎で互いに重複しないようにかつ連続する番号であることが好ましい。なぜなら、後述する端末装置102の処理が容易になるからである。このパケット番号により、端末装置102は、別々に送信されるi×j個のパケットP11、P12、…P1j、…Pijが、すべて揃ったかどうかを容易に判断できるようになる。このステップS1104が終了すると、パケット組み立て部1015は、サブルーチンである図61の処理から抜けて、図59の処理に戻る。そしてステップS1004が行われる。以上の各パケットP11、P12、…P1j、…Pijは、ステップS1004において、送信部1016から、アンテナ1012を通じて無線伝送路103に順次送出され、端末装置102に送信される。
【0205】
次に、図63のフローチャートを参照して、端末装置102における地図データの受信手順について説明する。センタ局により送信された各パケットP11、P12、…P1j、…Pijは、無線伝送路103を通じて、端末装置102のアンテナ1021に入力される。受信部1022は、アンテナ1021から出力されるパケットP11、P12、…P1j、…Pijを順次受信する(ステップS1201)。また、受信部1022は、図示しないバッファメモリを有する。受信部1022は、受信された各パケットP11、P12、…P1j、…Pijを、バッファメモリに順次格納する。
【0206】
パケット分解部1024は、受信部1022のバッファメモリに定期的にアクセスして、センタ局101により送信されたi×j個のパケットP11、P12、…P1j、…Pijがバッファメモリ内に揃っているか否かを判断する(ステップS1202)。ステップS1202の判断は、各パケットP11、P12、…P1j、…Pijに付加されたパケット番号に基づいて行われる。より具体的には、パケット番号が連番であれば、パケット分解部1024は、1から(i×j)までのパケット番号が全て揃っているか否かを判断する。
【0207】
ステップS1202で、パケットPが全て揃っていない場合、パケット分解部1024はステップS1203に進まず、ステップS1201が再度実行される。その結果、受信部1022は、不足分のパケットPを受信する。
一方、ステップS1202で、パケットPが全て揃っている場合、パケット分解部1024は、ステップS1203に進む。パケット分解部1024は、ステップS1201で受信されたパケットP11、P12、…P1j、…Pijを分解して、マスタデータMDを復元する(ステップS1203)。復元されたマスタデータMDはファイル管理部1025に出力される。ファイル管理部1025は、入力されたマスタデータMDを基に地図ファイルCFを生成する。生成された地図ファイルCFは第2の記憶装置1026に格納される(ステップS1204)。
【0208】
ステップS1204の後、データ処理部1023は、受信すべき一連のパケットPがまだあるか否かを判断する(ステップS1205)。受信すべきパケットPがある場合、ステップS1201に戻り、パケットPの受信処理が引き続き行われる。一方、受信すべきパケットPがない場合には、図63の処理を終了する。
【0209】
ここで、図64は、図63のステップS1203の詳細な処理の手順を示すフローチャートである。また、図65は、パケットP11、P12、…P1j、…Pijから地図ファイルCFが生成されるまでの過程における各データの構造を示している。上述から明らかなように、図63のステップS1203が開始される時点で、受信部1022には、図65(a)に示すように、一連のパケットP11、P12、…P1j、…Pijが揃っている。パケット分解部1024は、受信部1022に保持されているパケットP11、P12、…P1j、…Pijから、処理すべきパケットPを得る(ステップS1301)。今、パケット分解部1024はパケットP11、P12、…P1jを得ると仮定する。
【0210】
次に、パケット分解部1024は、ステップS1301で得られた各パケットPからパケット番号を外す。パケット分解部1024は、番号が外された各パケットPを分解して、図65(b)に示すように、1つのセグメントデータSDを復元する(ステップS1302)。上述の仮定に従うと、パケットP11、P12、…P1jが一まとめにされ、その結果、セグメントデータSD1が復元される。
各セグメントデータSDには誤り訂正符号(または誤り検出符号)が付加されている。ステップS1302の次に、パケット分解部1024は、誤り訂正符号を利用して、復元されたセグメントデータ(誤り訂正符号付き)SDに生じている可能性がある誤りを訂正する(ステップS1303)。
次に、パケット分解部1024は、セグメントデータ(誤り訂正符号付き)SDから誤り訂正符号を外し、これによって、図65(c)に示すように、セグメントデータ(誤り訂正符号なし)SDが復元される(ステップS1304)。復元されたセグメントデータSDは、パケット分解部1024の記憶領域に保持される。上述の仮定に従うと、セグメントデータSD1に誤り訂正が施された後、パケット分解部1024の記憶領域に保持される。
【0211】
ステップS1304の次に、パケット分解部1024は、受信部1022内に、処理すべきパケットPが残っているか否かを判断する(ステップS1305)。処理すべきパケットPが残っている場合、パケット分解部1024はステップS1301に戻って、ステップS1301〜S1304を行って、図65(a)〜(c)に示すように、パケットPからセグメントデータSDを復元する。本説明では、図64の処理の開始時点で、受信部1022には、(i×j)個のパケットPがある。したがって、ステップS1201〜S1205で構成されるループはi回繰り返される。その結果、i個のセグメントデータSD1〜SDiが復元される。
【0212】
このループが必要回数だけ繰り返されると、受信部1022内には、処理すべきパケットPがなくなる。この状態で、ステップS1305の判断が行われると、パケット分解部1024は、ステップS1306に進む。処理すべきパケットPがなくなった時点で、i個のセグメントデータSD1〜SDiがパケット分解部1024に保持される。また、上述したように、各セグメントデータSD1〜SDiには、セグメント番号が付されている。パケット分解部1024は、このセグメント番号に従って、つまりセグメント番号が連続するように、セグメントデータSD1〜SDiを順番に並べる。その後、セグメント番号は、各セグメントデータSD1〜SDiから取り外される。パケット分解部1024は、セグメント番号が取り外されたセグメントデータSD1〜SDiを一まとめにする。その結果、図65(d)に示すように、マスタデータMDが復元される(ステップS1306)。復元されたマスタデータMDは、ファイル管理部1025に出力される(ステップS1307)。
【0213】
なお、本地図提供システムに限らず、通信システムでは通信障害が起こりうる。したがって、端末装置102は、全てのセグメントデータSDを正しく復元できるとは限らない。ここで、正しく復元されたセグメントデータSDとは、センタ局101が生成したものと同じセグメントデータSDを意味する。例えば、セグメントデータSD2が正しく復元されなかった場合であって、他のセグメントデータSD1、SD3〜SDiが正しく復号された場合を想定する。かかる場合、パケット分解部1024は、セグメントデータSD1、SD3〜SDiに付加された誤り訂正符号を利用して、セグメントデータSD2を正しいものに復元することもできる。
【0214】
ファイル管理部1025は、マスタデータMDの入力に起因して、ステップS1204を開始する。このステップS1104は、上述したように、マスタデータMDから地図ファイルCFを生成する処理と、生成された地図ファイルCFを第2の記憶装置1026に格納するための処理である。ここで、図66は、図63のステップS1204の詳細な処理の手順を示すフローチャートである。
【0215】
ところで、第2の記憶装置1026は、ステップS1204の開始時点で、以前に生成された地図ファイルCFを既に記憶していることがある。また、地図ファイルCFが記憶されていない場合もある。ファイル管理部1025は、マスタデータMDの入力後、第2の記憶装置1026内に地図ファイルCFが格納されているか否かを判断する(ステップS1401)。ファイル管理部1025は、地図ファイルCFがある場合、後述するステップS1404に進む。一方、ファイル管理部1025は、地図ファイルCFが無い場合、今回のマスタデータMDを基に、完全に新規な地図ファイルCFを作成する(ステップS1402)。なお、この地図ファイルCFは、地図ファイルCFと同様のデータ構造を有する(図53(b)および図54参照)。
【0216】
ここで、地図ファイルCFの作成方法を説明する。マスタデータMDは、図62に示したように、地図ファイルID、ユニットIDおよびデータサイズをデータヘッダDHに有する。さらに、このマスタデータMDは、ファイルヘッダFHと、全部または一部のユニットレコードURをデータ部に有する。ファイル管理部1025は、マスタデータMDから、ファイルヘッダFHを取り出す。
【0217】
前述したように、マスタデータMDには1個のユニットレコードURしか含まれない。また、ファイル管理部1025は、今回、完全に新規な地図ファイルCFを生成する。そのため、ファイル管理部1025は、初期値「1」のユニット数NOUを生成する。さらに、ファイル管理部1025は、ファイルヘッダFHおよびユニット数NOUのデータサイズとから、今回得られたユニットレコードURまでのオフセット値X0,0を求める。これによって、ユニット管理情報MIUNITが生成される。
【0218】
これによって、ファイル管理部1025は、完全に新規な地図ファイルCFを生成するために必要な情報を全て得たこととなる。ファイル管理部1025は、今回得られたファイルヘッダFH、ユニット管理情報MIUNITおよびユニットレコードURを一まとめにして、地図ファイルCFを生成する。この地図ファイルCFのデータ構造は、図67に示す通りである。以上のようにして生成された地図ファイルCFは、第2の記憶装置1026内に格納される(ステップS1403)。
【0219】
次に、ステップS1401で、地図ファイルCFが見つけられた場合の処理について説明する。この場合、ステップS1404が行われる。ファイル管理部1025は、今回入力されたマスタデータMDから、ファイルIDを取り出す。ファイルIDは、前述したように、マスタデータMD内のユニットレコードURがどの地図ファイルCFに属していたかを特定する。このファイルIDは、図61を参照して前述したように、パケット組み立て部1015により、地図ファイルCFのファイルヘッダFHを用いて生成されている。
また、ファイル管理部1025は、第2の記憶装置1026内の各地図ファイルCFのファイルヘッダFHを取り出す。ファイルヘッダFHは、地図ファイルCFがカバーする範囲を特定するものである。地図ファイルCFのファイルヘッダFHは、ステップS1402で説明したように、センタ局101側で管理される地図ファイルCFを基に作成されている。
したがって、ファイルIDとファイルヘッダFHとに同一性があれば、今回入力されたユニットレコードURは、地図ファイルCFの一部を構成することとなる。そのため、ファイル管理部1025は、両者の同一性を判断する(ステップS1404)。
【0220】
ステップS1404で、同一性が無いと判断されると、入力されたユニットレコードURを構成要素とする地図ファイルCFがまだ作成されていないことを意味する。この場合、ファイル管理部1025は、上述のステップS1402およびS1403を実行する。つまり、全く新規な地図ファイルCFが生成された後に、第2の記憶装置1026に格納される。
【0221】
一方、ステップS1404で、ファイルIDおよびファイルヘッダFHに同一性があると判断されると、入力されたユニットレコードURを構成要素とする地図ファイルCFが既に生成されていることを意味する。この場合、ファイル管理部1025は、この地図ファイルCFを処理対象として選択する。ファイル管理部1025は、この処理対象の地図ファイルCFを開き(ステップS1405)、入力されたユニットレコードURを、処理対象として選択された地図ファイルCFに追加する(ステップS1406)。つまり、ステップS1406では、入力されたユニットレコードURと、地図ファイルCFとが一まとめにされ、更新された地図ファイルCFが生成される。
【0222】
ステップS1406について、より詳細に説明する。ファイル管理部1025は、今回のマスタデータMDから、ユニットIDを取り出す。以降、入力されたマスタデータMDから取り出されたユニットIDを、第1のユニットIDと称す。第1のユニットIDは、図62を参照して説明したように、今回入力されたマスタデータMDの基礎となったユニットレコードURを特定する。また、ファイル管理部1025は、ステップS1405で開かれた地図ファイルCFから、全てのユニットIDを取り出す。以降、地図ファイルCFから取り出された各ユニットIDを、第2のユニットIDと称す。第2のユニットIDの中には、第1のユニットIDと一致するものが含まれていない場合と、一致するものが含まれている場合がある。
【0223】
第1および第2のユニットIDが一致しない場合、ファイル管理部1025は、今回入力されたマスタデータMDから、ユニットレコードURを取り出して、図68に示すように、現在開かれている地図ファイルCFに追加して、当該地図ファイルCFを更新する。
第1および第2のユニットIDが一致する場合、今回入力されたユニットレコードURは、過去に、センタ局101により、端末装置102に提供されていることとなる。例えば、図54に示す構造をもつユニットレコードURにおいて、基本背景データテーブルBBD、基本文字記号データテーブルBCD、主要幹線ネットワークデータテーブルMND等の基本データ(概略データ)のみが、ステップS1204の時点で、端末装置102に既に提供されているような場合がある。この場合、現在開かれている地図ファイルCFは、図69のような構造を有する。ファイル管理部1025は、この場合、図70に示すように、今回入力されたマスタデータから取り出されたユニットレコードURを、現在開かれている地図ファイルCFにおいて、同じユニットIDが付されているユニットレコードURに追加する。これによって、地図ファイルCFが更新される。
【0224】
ファイル管理部1025は、さらに、今回入力されたマスタデータMDのデータサイズに従って、ユニット管理情報MIUNITを更新する(ステップS1407)。次に、ファイル管理部1025は、更新された地図ファイルCFを、第2の記憶装置1026に格納する(ステップS1408)。
【0225】
以上のように、本地図提供システムでは、第1の記憶装置1013には、地図ファイルCFが格納される。パケット組み立て部1015は、端末装置102に送信すべき部分的な地図のみを読み出し制御部1014から受け取り、当該地図を表す一連のパケットPを生成する。この一連のパケットPが、無線伝送路103上を伝送される。この無線伝送路103上には、部分的な地図を表すデータしか送信されない。そのため、本地図提供システムは、たとえ、地図ファイルCF自体が大きなサイズであっても、無線伝送路103に送出するデータの量を抑えることができる。これによって、無線伝送路103は輻輳しにくくなる。
【0226】
また、端末装置102は、部分的な地図を表すデータを順次受信することになる。しかし、端末装置102は、初期的には、部分的な地図データを個別にファイル化することになる。しかし、端末装置102は、所定条件を満たす地図ファイルCFが存在する場合には、受信された部分的な地図データを、当該地図ファイルCFに追加して、一まとめにする。そのため、本地図提供システムは、端末装置102において、大量のファイルが発生することを抑えることができる。そのため、第2の記憶装置1026内には、空き領域を有するクラスタが生じにくくなる。その結果、本地図提供システムは、第2の記憶装置1026の記憶領域を有効的に利用することができる。
【0227】
また、地図ファイルCFは、図53に示すように、予め定められた範囲の地図αが複数の領域に区画されることにより、つまり、ユニットU単位で構成される。このような地図αのユニット化により、読み出し制御部1014は、必要な部分の地図を容易に第1の記憶装置1013から読み出すことができる。さらに、このユニット化により、センタ局101は、無線伝送路103が輻輳しない最適量のデータを容易に当該無線伝送路103に送出することができる。
さらに、センタ局101が複数のユニットレコードURを送信した場合であっても、通信エラーにより、端末装置102は、いずれかのユニットレコードURを受信できない場合がある。このような場合、端末装置102は、受信できたユニットレコードURを用いて地図ファイルCFを作成する。端末装置102は、作成された地図ファイルCFに基づいて各種処理を行える。つまり、センタ局101から送信されたユニットレコードURの一部が抜けても、その抜けによる影響は、端末装置102が受信した他のユニットレコードには及ばない。かかる効果も、地図のユニット化により生まれる。
【0228】
また、ユニットレコードUR内において、地図の基本的なデータ(概略データ)と、当該地図の詳細なデータとは、互いに独立した複数のテーブルに記述される。これによって、各テーブルは、たとえ、1ユニットレコードUR内に格納されていても、独立的に使用されることが可能となる。つまり、例えば、センタ局101は、端末装置102に地図を提供する際に、基本データ(概略データ)を単独で送信したり、詳細データを単独で送信したり、双方を組み合わせて送信したりすることが可能となる。これによって、センタ局101は、端末装置102の状況や用途に適した地図を提供することが可能になる。
【0229】
例えば、端末装置102側が、詳細な地図よりも、広範囲の地図を速く受信したい場合には、センタ局101は、基本データ(概略データ)だけを優先的に送信することができる。さらに、端末装置102が基本データ(概略データ)を完全に受信した後に、センタ局2が詳細データを送信することもできる。これによって、端末装置102は、基本データ(概略データ)と詳細データとを混在させて使用することも可能になる。
【0230】
なお、前述したように、送信部1016および受信部1022として、前述したように、移動体通信装置を用いることも可能である。この場合、センタ局101と端末装置102との双方向通信を容易に実現できるので、端末装置102は、提供を希望する地図の種別(概略データか詳細データかを示す情報)を、センタ局101に対してリアルタイムに要求することができる。
また、送信部1016および受信部1022として、地上波ディジタル放送等の放送装置および、この放送を受信する装置を用いることも可能である。この場合、センタ局101は、互いに異なるチャンネルを用いて、基本データ(概略データ)と詳細データとに異なるチャンネルを割り当てることにより、基本データ(概略データ)と詳細データとの受信時間、および受信可能な地図の範囲を調節することができる。
【0231】
なお、以上の実施形態では、第2の記憶装置1026側の地図ファイルCFのファイルヘッダFHは、第1の記憶装置1013側の地図ファイルCF内のそれをそのまま用いられていた。つまり、双方地図ファイルCFは、互いに同範囲をカバーする。しかしながら、センタ局101と端末装置102との処理能力は違う場合が多い。例えば、第2の記憶装置1026の記憶容量は、第1の記憶装置1013のそれよりも小さい場合が多い。したがって、端末装置102は、地図ファイルCFが表す地図の範囲よりも、狭い範囲をカバーする地図ファイルCFを生成してもよい。つまり、端末装置102は、独自の範囲をカバーする地図ファイルCFを生成しても良い。
【0232】
なお、第2の実施形態は、端末装置102の一例としてカーナビゲーションシステムを想定して説明した。しかし、パーソナルコンピュータ内に地図ファイルCFのデータベースを作成して、当該パーソナルコンピュータが地図を表示したり、経路探索を行ったりするような用途にも、本実施形態は適用することができる。つまり、本発明の技術分野は、移動可能な端末装置に限らず、据え置き型の端末装置にも適用することができる。
また、据え置き型の端末装置に対しては、通信網103は無線伝送路である必要性はなく、有線であってもよい。
【図面の簡単な説明】
【図1】
本発明の第1の実施形態に係る地図提供システムの構成を示すブロック図である。
【図2】
図1に示す第1の地図ファイル111および第2の地図ファイル25により表現される地図の階層構造を説明するための図である。
【図3】
図2に示す最上位階層(レベル「3」)のユニットU3を説明するための図である。
【図4】
レベル「3」からレベル「0」までのそれぞれの階層間における親子関係を説明するための図である。
【図5】
第1の地図ファイル111および第2の地図ファイル25を管理するためのツリー構造を示す図である。
【図6】
あるレベルに属する1つのユニットUのデータ構造を示す図である。
【図7】
地図ファイルCFのデータ構造を示す図である。
【図8】
背景データにより表現される地図の模式図である。
【図9】
描画オブジェクトBO1およびBO2を用いて、描画オブジェクトの概念を説明するための図である。
【図10】
背景データテーブルの詳細なデータ構造を示す図である。
【図11】
8個の要素点P0〜P7で構成される図形データを示す図である。
【図12】
図11のP0〜P7の各絶対座標をオブジェクトレコードORに記述した時のデータ構造を示す図である。
【図13】
図11と同じ図形データの各要素点P0〜P7を相対座標で表現した時の図である。
【図14】
図13の要素点P0〜P7の各相対座標をオブジェクトレコードORに記述した時のデータ構造を示す図である。
【図15】
要素点P0、P1およびPnで構成されるオブジェクトOBJを示す図である。
【図16】
図15の要素点P1およびPnを結ぶ直線上に補われる要素点P2およびP3を示す図である。
【図17】
図16の要素点P0,P1,P2,P3およびPnの各相対座標情報をオブジェクトレコードORに記述した時のデータ構造を示す図である。
【図18】
図15の要素点P0およびPnを絶対座標で表現し、要素点P1を相対座標で表した時のオブジェクトレコードORのデータ構造を示す図である。
【図19】
描画オブジェクトDO3を用いて、オブジェクトの境界に相対座標が適用されない場合を説明するための図である。
【図20】
そのオブジェクトの境界に相対座標が適用されない描画オブジェクトDO3の座標列のデータ構造を示す図である。
【図21】
描画オブジェクトDO3を用いて、オブジェクトの境界に適用される相対座標を説明するための図である。
【図22】
そのオブジェクトの境界に相対座標が適用された描画オブジェクトDO3の座標列のデータ構造を示す図である。
【図23】
基本文字記号テーブルおよび詳細文字記号テーブルとの関係を説明するための図である。
【図24】
文字記号テーブルの詳細なデータ構造を示す図である。
【図25】
第1の道路ネットワークデータおよび第2の道路ネットワークデータの関係を説明するための図である。
【図26】
ノードおよびリンクの概念を説明するための図である。
【図27】
第1のノードテーブルの詳細なデータ構造を示す図である。
【図28】
図26のノードN0〜N10に関して作成されたノードレコードNR1〜NR11の並び方を示す図である。
【図29】
ノードの経度方向および緯度方向の座標の表現方法の一つである正規化座標を説明するための図である。
【図30】
第1のリンクテーブルの詳細なデータ構造を示す図である。
【図31】
各リンクレコードLRに記録されるリンク接続情報を説明するための図である。
【図32】
ノード接続情報およびリンク接続情報により、道路網の接続をたどる時の処理を説明するための図である。
【図33】
端末装置1における経路探索処理の概念を示す図である。
【図34】
端末装置1で実行される双方向階層別探索の処理手順を示すフローチャートである。
【図35】
図34の地図ファイルCFの読み込み処理(ステップS103)の詳細な処理手順を示すフローチャートである。
【図36】
隣接ユニットNUを決定するための新しい代表点の位置を説明するための図である。
【図37】
互いに隣接し合う4個のユニットU1〜U4を並べた際に構成される道路網を示す図である。
【図38】
2個のユニットUの境界をまたいで道路網の接続をたどる時のデータ処理部13の処理手順を示すフローチャートである。
【図39】
隣接ノードのノードレコードNRが記録される順番を示す図である。
【図40】
下位階層および上位階層の地図ファイルCFのノードN同士の対応づけに関する問題点を説明するための図である。
【図41】
下位階層および上位階層の地図ファイルCFのノードN同士の対応関係を説明するための図である。
【図42】
正規化座標およびノードレコードNRの記録順序から、子ユニットCUのノードNdと対応する座標を有する親ユニットPU内のノードを探し出す方法を説明するための図である。
【図43】
地図ファイルCFの送信要求時における端末装置1の処理を説明するための図である。
【図44】
センタ局2が要求REQの受信後に実行する処理手順を示すフローチャートである。
【図45】
地図ファイルCFからパケットPが組み立てられるまでの過程における、各データの構造を示す図である。
【図46】
ステップS504の詳細な処理手順を示すフローチャートである。
【図47】
マスタデータMDの詳細な内部データ構造を示す図である。
【図48】
端末装置1における地図ファイルCFの受信処理の手順を示すフローチャートである。
【図49】
図48のステップS703の詳細な処理手順を示すフローチャートである。
【図50】
パケットP11,P12,…,P1j,…Pijから地図ファイルCFが作成されるまでの過程における各データの構造を示す図である。
【図51】
図48のステップS704の詳細な処理の手順を示すフローチャートである。
【図52】
本発明の第2の実施形態に係る地図提供システムの構成を示すブロック図である。
【図53】
図52に示された第1の記憶装置1013に格納された各地図ファイルCFの構造を示す図である。
【図54】
図53(b)に示された各ユニットレコードURの詳細な構造を示す図である。
【図55】
図54に示された背景データBDを説明するための図である。
【図56】
図54に示された文字記号データCDを説明するための図である。
【図57】
図54に示された道路ネットワークデータNDを説明するための図である。
【図58】
図54に示された基本背景テーブルデータBBD、基本文字記号データテーブルBCDおよび主要幹線ネットワークデータテーブルMNDを重畳したときに表示される地図、ならびに、図54に示された詳細背景テーブルデータDBD、詳細文字記号データテーブルDCDおよび細街路ネットワークデータテーブルSNDを重畳したときに表示される地図を示している。
【図59】
図52に示されるセンタ局101において実行される処理の手順を示すフローチャートである。
【図60】
図52に示されるセンタ局101が地図ファイルCFからパケットPを生成するまでの過程における、各データの構造を示している。
【図61】
図59に示されるステップS1003が含む、詳細な処理手順を示すフローチャートである。
【図62】
図60(b)に示されるマスタデータMDの詳細な構造を示している。
【図63】
図52に示される端末装置102において実行される処理の手順を示すフローチャートである。
【図64】
図63に示されるステップS1203の詳細な処理手順を示すフローチャートである。
【図65】
図52に示される端末装置102がパケットPから地図ファイルCFを生成するまでの過程における、各データの構造を示している。
【図66】
図63に示されるステップS1204が含む、詳細な処理手順を示すフローチャートである。
【図67】
図52に示される地図ファイルCFの構造を示している。
【図68】
図66に示されるステップS1406において、ファイル管理部1025が、第1および第2のユニットIDが一致しない場合に実行する処理を示している。
【図69】
図54に示される基本背景データテーブルBBD、基本文字記号データテーブルBCD、主要幹線ネットワークデータテーブルMNDが、ステップS1204の時点で端末装置102に既に提供されているような場合における、地図ファイルCFの構造を示している。
【図70】
図66に示されるステップS1406において、ファイル管理部1025が、第1および第2のユニットIDが一致する場合に実行する処理を示している。
【図71】
ある範囲を表す地図βが、64個の矩形のユニットに区画化された場合を示している。
【図72】
端末装置の記憶装置内において、空き領域を有する4個のクラスタ91〜94が発生したときの様子を示している。
【図73】
ある範囲を表す地図βが、16個の矩形のユニットに区画化された場合を示している。
【図74】
端末装置の記憶装置内において、空き領域を有する1個のクラスタ96が発生した場合を示しており、さらに、かかる場合には、無線伝送路の利用効率が悪くなることを説明するための図である。
【符号の説明】
1…端末装置
11…入力装置
12…位置検出装置
13…データ処理部
14…要求生成部
15…第1の送受信部
16…アンテナ
17…パケット分解部
18…読み出し/書き込み制御部
19…第1の記憶装置
110…出力装置
111…第1の地図ファイル
2…センタ局
21…第2の送受信部
22…受信要求解析部
23…読み出し制御部
24…第2の記憶装置
25…パケット組み立て部
3…通信網
101…センタ局
1011…地図サーバ
1012…アンテナ
1013…第1の記憶装置
1014…読み出し制御部
1015…パケット組み立て部
1016…送信部
102…端末装置
1021…アンテナ
1022…受信部
1023…データ処理部
1024…パケット分解部
1025…ファイル管理部
1026…第2の記憶装置
 
訂正の要旨 審決(決定)の【理由】欄参照。
異議決定日 2005-12-14 
出願番号 特願平11-331885
審決分類 P 1 651・ 121- YA (G06F)
最終処分 維持  
前審関与審査官 平井 誠  
特許庁審判長 小林 信雄
特許庁審判官 篠原 功一
久保田 健
登録日 2002-07-26 
登録番号 特許第3332225号(P3332225)
権利者 松下電器産業株式会社
発明の名称 地図提供システム  
代理人 小笠原 史朗  
代理人 小笠原 史朗  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ