JP2002055601A

JP2002055601A - 地図表示システム及び方法

Info

Publication number: JP2002055601A
Application number: JP2000240401A
Authority: JP
Inventors: Wataru Shoji; 渉庄司; Daisuke Tabuchi; 大介田渕; Yasuo Higano; 保夫日向野; Ichiro Nakajima; 一郎中島
Original assignee: Dream Technologies Corp
Current assignee: Dream Technologies Corp
Priority date: 2000-08-08
Filing date: 2000-08-08
Publication date: 2002-02-20

Abstract

(57)【要約】【課題】通信ネットワークを用いた地図表示システム
において、地図のスクロールや拡大縮小を連続的に円滑
に行えるようにする。【解決手段】地図サーバ１０は、微小地域（メッシ
ュ）に細分された地図データ１１を有している。地図デ
ータ１１は、建物などのポリゴンデータのレイヤと、道
路などの線データのレイヤと、地名などの文字データの
レイヤなどの複数レイヤに分れており、各レイヤの各メ
ッシュの地図データが１つのファイルであり、各メッシ
ュの位置座標（メッシュ番号）が各メッシュのファイル
名となっている。クライアントコンピュータ３０は、地
図サーバ１０からインターネット２０を通じて、必要な
メッシュ番号のファイルをダウンロードし、そのファイ
ルから地図画像を描画して表示する。その際、クライア
ントコンピュータ３０は、ポリゴンレイヤ、線レイヤ、
文字レイヤの順でファイルダウンロードする。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、インターネットの
ような通信ネットワークを通じてクライアントコンピュ
ータが地図サーバから地図データを受信して表示するた
めのシステムに関する。

【０００２】

【従来の技術】従来のこの種のシステムでは、クライア
ントコンピュータに対してユーザが、画面に表示されて
いる地図のスクロールや拡大縮小などの地図表示範囲を
変更する操作を行うと、クライアントコンピュータは、
新たな地図表示範囲の地図画像を地図サーバに要求す
る。地図サーバは、その新たな地図表示範囲の地図デー
タを同サーバのデータベースから読み出し、その地図デ
ータから、その新たな地図表示範囲のビットマップ地図
画像を描画して、そのビットマップ地図画像をクライア
ントコンピュータへ送信する。クライアントコンピュー
タは、そのビットマップ地図画像を受信して表示する。

【０００３】

【発明が解決しようとする課題】この従来のシステムの
問題は、地図のスクロールや拡大縮小を連続的に円滑に
行うことができない点にある。すなわち、ユーザが地図
のスクロールや拡大縮小操作を行うと、サーバが新たな
地図表示範囲の地図画像を描画し終わって返送してくる
まで、しばらくの時間待たされた後、画面上の地図画像
が一気に新たな地図表示範囲の地図画像に切換わる。こ
れは、ちょうど、ウェブブラウザで或るページを別のペ
ージへとジャンプしたような不連続な切換わりである。
そして、このようにしばらく待って画面上の地図画像が
切換わって初めて、ユーザは、スクロール先がどの場所
か、或いは拡大縮小後の倍率がどの程度かを知ることに
なる。これでは、地図をスクロールしているとか拡大縮
小しているという操作感覚をユーザが得ることはまった
くできず、非常に使いずらい。この問題は、多数のユー
ザがサーバにアクセスしていたり通信回線が混んでいる
などの事情で、待ち時間が長くなるとより顕著になる。

【０００４】従って、本発明の目的は、通信ネットワー
クを用いた地図表示システムにおいて、地図のスクロー
ルや拡大縮小を連続的に円滑に行えるようにすることに
ある。

【０００５】

【課題を解決するための手段】本発明に従う地図表示シ
ステムは、多数の断片地図データに細分された全体地図
データをもつ地図サーバと、所望の断片地図データを地
図サーバから通信ネットワークを通じてダウンロード
し、ダウンロードした断片地図データから地図画像を描
画して表示するクライアントとを備える。

【０００６】この地図表示システムによれば、クライア
ントは、所望の断片地図データを地図サーバからダウン
ロードして、地図画像を描画して表示する。よって、地
図サーバは、地図画像を描画しないので、地図サーバの
負荷は軽く、高速に地図データをクライアントへ送れ
る。全体地図データは多数の断片地図データに細分され
ているので、早くダウンロードできた断片地図データか
ら先に描画して表示できる。結果として、地図のスクロ
ールや拡大縮小を連続的に円滑に行える。ここで、断片
地図データとは、例えば、全体地図データがカバーする
全体地域を緯度経度などで地域的に細分した小地域（メ
ッシュ）の地図データである。或いは、断片地図データ
とは、例えば、地図画像に含まれる個々の地理要素（例
えば、各道路、各鉄道線路、各河川、各建物、各敷地、
各地物名称、各地図記号、各アイコンなどの個々の地理
的事物）毎のデータ（例えば、各地理的事物を表したポ
リゴンデータ、線データ、文字データ、ビットマップイ
メージデータなど）である。

【０００７】好適な実施形態では、地図サーバにおい
て、各断片地図データは、各断片地図データの地理的な
位置座標（例えば、全体地域における各メッシュ又は各
地理的事物の緯度経度方向の座標）によって指定するこ
とができる記憶場所に格納されている。そのため、クラ
イアントは、所望の断片地図データの地理的な位置座標
から、直ちに地図サーバ内の所望の断片地図データの格
納場所（例えば、パス）を割り出して、地図サーバに要
求することができる。結果として、ダウンロードを短時
間で完了させ得る。

【０００８】好適な実施形態では、地図サーバがもつ全
体地図データは、異なる種類の地理要素毎の複数のレイ
ヤに分けられており、クライアントは、所望の断片地図
データを前記地図サーバからダウンロート゛するとき、前
記複数のレイヤに対して予め与えてある優先順位に従っ
た順序で、各レイヤの断片地図データを逐次にダウンロ
ードする。例えば、建物のようなポリゴンデータのレイ
ヤ、道路のような線データのレイヤ、及び地名のような
文字データのレイヤに各メッシュの地図データが分れて
いて、クライアントは、ポリゴンレイヤ、線レイヤ及び
文字レイヤの順でダウンロードを行う。これにより、先
にダウンロードしたレイヤの画像から先に表示されてい
くというプログレッシブ表示が行われ、結果として、高
速に地図が表示され、地図のスクロールや拡大縮小を連
続的に円滑に行える。

【０００９】好適な実施形態では、地図サーバは、異な
る縮尺の複数の地図の地図データを有しており、クライ
アントは、それら異なる縮尺の複数の地図のうち、より
小縮尺の地図から優先的に断片地図データをダウンロー
ドする。これにより、小縮尺の地図から大縮尺の地図へ
と順次に地図画像が表示されていくというプログレッシ
ブ表示が行われ、結果として、地図のスクロールや拡大
縮小の操作をユーザが行うと速やかに地図画像の表示が
開始され、地図のスクロールや拡大縮小を連続的に円滑
に行える。

【００１０】好適な実施形態では、複数台の前記地図サ
ーバを備え、クライアントは、その複数台の地図サーバ
のいずれからも地図データダウンロードすることができ
る。これにより、各地図サーバの負担が軽減され、結果
として、高速に地図データがダウンロードでき、地図の
スクロールや拡大縮小を連続的に円滑に行える。

【００１１】

【発明の実施の形態】図１は、本発明に従う地図表示シ
ステムの一実施形態の概略的な全体構成を示す。

【００１２】地図提供サービスを行う地図サーバ１０
と、多数のユーザがそれぞれ利用する多数のクライアン
トコンピュータ３０とが、例えばインターネット２０の
ような通信ネットワークを通じて通信可能になってい
る。地図サーバ１０は広範な地域の地図データを格納し
た地図データベース１１を有している。クライアントコ
ンピュータ３０は、地図サーバ１０にアクセスするため
のクライアントプログラム３１を有する。クライアント
プログラム３１には、地図サーバ１０に具体的な地図デ
ータの要求を送り地図サーバ１０から受信した地図デー
タを表示するための地図表示プログラム３２が、例えば
プラグインのような形で付属している。クライアントコ
ンピュータ３０は、ディスプレイ装置３３や、マウス３
４のようなコントローラも有している。

【００１３】（必ずしもそうである必要はないが、）こ
の実施形態では、地図サーバ１０はＷＷＷサーバであ
り、クライアントコンピュータ３０内のクライアントプ
ログラム３１はＷＷＷブラウザであり、両者はＨＴＴＰ
プロトコルによって地図データの要求や地図データをや
り取りする。

【００１４】図２は、地図サーバ１０がもつ地図の種類
と、クライアントコンピュータ３０内の地図表示プログ
ラム３２が地図サーバ１０に対して地図データを要求す
るときの順序を説明したものである。

【００１５】地図サーバ１０の地図データベース１１に
は、縮尺の異なる複数種類の地図１１０〜１１２のデー
タが格納されている。図示の例では、2千５百分の１の
大縮尺地図（いわゆる市街地図）１１０、２万５千分の
１の中縮尺地図１１１、及び２０万分の１の小縮尺地図
１１２の３種類が格納されている（勿論、もっと多くの
種類の地図が格納されていてもよい）。

【００１６】これらの異なる縮尺の地図１１０〜１１２
はいずれも、その地図がカバーする広範囲な地域を緯度
と経度の方向で細かく分割した小さい矩形地域（以下、
「メッシュ」という）単位の地図データに分割されてい
る。１つのメッシュを単位として、地図サーバ１０から
地図表示プログラム３２への地図データの送信が行われ
る。すなわち、両者間の１回のＨＴＴＰセッションで、
１つのメッシュの地図データが地図表示プログラム３２
から地図サーバ１０へ要求され、そして、その１つのメ
ッシュの地図データが地図サーバ１０から地図表示プロ
グラム３２へ返信される。従って、メッシュのサイズ
（面積）が小さいほど、メッシュの地図データの量が少
なくなり、１回のＨＴＴＰセッションに要する時間は短
くなるから、１つのメッシュの表示に要する時間は短く
なる。しかし、メッシュのサイズ（面積）が小さいほ
ど、ユーザが所望する地図の表示範囲に含まれるメッシ
ュの個数が多くなるから、地図表示プログラム３２と地
図サーバ１０との間で行われるＨＴＴＰセッションの回
数が増える。この観点から、ユーザが所望する地図の表
示範囲を高速に表示し終わるようにする（または、その
ようにユーザに感じさせる）ためには、１つのメッシュ
の地図データ量が適度であって、１回のＨＴＴＰセッシ
ョンに要する時間が長すぎず、かつ、ユーザが所望する
地図の表示範囲に必要なＨＴＴＰセッションの回数が多
すぎないように、１つのメッシュのサイズ、換言すれば
一つのメッシュのデータ量、を適度に設定することが肝
要である。この理由から、地図の縮尺が異なればメッシ
ュのサイズも異なる。すなわち、縮尺が小さい（つま
り、縮尺の分母が大きい）地図ほど、同じ地図データ量
でカバーできる地域面積が大きくなるので、メッシュの
サイズも大きく設定されている（但し、１つのメッシュ
のデータ量がどの地図１１０〜１１２でも同じというわ
けではない）。

【００１７】クライアントコンピュータ３０内の地図表
示プログラム３２は、ユーザのマウス３４等による地図
のスクロールや拡大縮小の操作に応じて、ユーザの所望
する地図の表示範囲を把握し、その表示範囲と重なる
（つまり、その表示範囲に含まれるか、又は、その表示
範囲を包含する）メッシュがどれであるかを、各縮尺の
地図１１０〜１１２ごとに決定する。例えば、図２でデ
ィスプレイ装置３３内に示された地図の表示範囲の例の
場合、その表示範囲と重なっているメッシュは、大縮尺
地図１１０の１６個のメッシュ１１０Ａ〜１１０Ｐ（図
中、破線で境界が示されている）と、中縮尺地図１１１
の４個のメッシュ１１１Ａ〜１１１Ｄ（図中、実線で境
界が示されている）と、大縮尺地図１１２の１個のメッ
シュ１１２Ａである。これらのメッシュ１１０Ａ〜１１
０Ｐ、１１１Ａ〜１１１Ｄ、１１２Ａを決定すると、続
いて、地図表示プログラム３２は、それらのメッシュの
地図データを地図サーバ１０に要求する。その際、地図
表示プログラム３２は、小縮尺の地図から優先的に、す
なわち、まず小縮尺の地図１１２のメッシュ１１２Ａ、
次に中縮尺の地図１１１のメッシュ１１１Ａ〜１１１
Ｄ、最後に大縮尺の地図１１０のメッシュメッシュ１１
０Ａ〜１１０Ｐという順序で、地図サーバ１０にメッシ
ュデータ要求を発する。但し、ユーザの拡大縮小操作に
よって決まる表示範囲が広域であって、そのために、或
る縮尺以上の縮尺の地図（例えば、大縮尺地図１１０）
を表示する必要がない場合には、その不要な地図（例え
ば、大縮尺地図１１０）のメッシュは要求しない。

【００１８】地図サーバ１０は、要求された順序で各メ
ッシュの地図データを地図データベース１１から読み出
して地図表示プログラム３２に返信する。結果として、
地図表示プログラム３２は、（時には、通信ネットワー
クの事情によって順序が前後することがあるが）通常
は、より小縮尺の地図のメッシュデータから先に受信し
て表示することができる。より小縮尺な地図ほど、前述
したように、１つのメッシュのサイズがより大きいか
ら、ユーザの所望する表示範囲の全域を少ない個数のメ
ッシュでカバーできる。よって、より小縮尺の地図が高
速に、ユーザの所望する表示範囲の全域に表示される。
その後に、より大縮尺の地図が表示されていく。より大
縮尺の地図ほど、より詳細な地物まで表現している。よ
って、ユーザの所望する表示範囲に、まず高速に、小縮
尺地図の大まかな地物の表示が出現し、その後に、より
大縮尺な地図の詳細な地物の表示が現われてくる。

【００１９】以上のような、縮尺の異なる複数種類の地
図を用いたプログレッシブな地図表示方法を採用するこ
とで、ユーザが地図のスクロールや拡大縮小を行なう
と、直ちに大まかな小縮尺地図が表示されるので、ユー
ザはもはや、従来のようにしばらく待ってから地図が不
連続に切り替わるという感覚を感じることは無くなり、
地図のスクロールや拡大縮小を連続的に円滑に行えると
いう操作感覚を得ることができる。

【００２０】また、地図サーバ１０がもつ地図データ
は、ポリゴンや線や文字コードなどを記述したベクトル
データを主体にして構成されており、地図サーバ１０
は、要求されたメッシュの地図データを、ビットマップ
データ化する（つまり、地図画像を描画する）ことな
く、ベクトルデータのままで地図表示プログラム３２に
送信する。そして、地図表示プログラム３２が、その受
信したベクトルデータから地図画像を描画する。要する
に、地図サーバ１０は、クライアントから要求されたデ
ータをデータベースから取得してクライアントへ返すと
いう単純な作業をひたすら繰り返すだけである。これに
より、地図サーバ１０の負担は小さくなり、地図サーバ
１０は、多数のクライアントから要求を受けているとき
でも、各クライアントに対して即座に要求された地図デ
ータを返信することができる。このことも、地図のスク
ロールや拡大縮小を連続的に円滑に行えるという操作感
覚を得ることができるという効果に寄与する。

【００２１】図３は、地図サーバ１０がもつ各種類の地
図のファイル構成を示す。

【００２２】図２を参照して既に説明したように、地図
サーバ１０は複数種類の地図１１０〜１１２を有してい
るが、それらの地図１１０〜１１２の各々は、図３に示
すようなファイル構成を有している。図３に示すよう
に、１つの種類の完全な地図２００は、データの種類が
異なる複数のレイヤ、例えば、ポリゴンレイヤ２１０、
線レイヤ２２０及び文字レイヤ２３０に分かれている。
ポリゴンレイヤ２１０は、例えば建物や敷地などを表し
たポリゴンデータを集めたものである。線レイヤ２２０
は、例えば道路や鉄道や河川などを表した線データを集
めたものである。文字レイヤ２３０は、例えば地名や建
物名称などを表した文字コード列と、アイコンや地図記
号などのシンボルマークのデータを集めたものである。

【００２３】既に説明したように、地図がカバーする全
体地域は緯度と経度の方向に細分された多数のメッシュ
に分割されている。よって、ポリゴンレイヤ２１０、線
レイヤ２２０及び文字レイヤ２３０はそれぞれ、メッシ
ュごとのデータ２１１、２２１、２３１に分割されてい
る。そして、１つのレイヤの１つのメッシュのデータ
が、１つのファイルとして構成されている。

【００２４】各メッシュには、各メッシュの全体地図上
での位置座標に相当するメッシュ番号が割り当てられて
いる。図３に示すように、各メッシュのメッシュ番号
は、経度方向の座標値（経度方向のメッシュ番号）Ｘi
と、緯度方向の座標値（緯度方向のメッシュ番号）Ｙｊ
とのセット（Ｘi、Ｙｊ）で表される。そして、図３に
示すように、ポリゴンレイヤ２１０に含まれるメッシュ
ごとのポリゴンファイル２１１、２１１、…、線レイヤ
２２０に含まれるメッシュごとの線ファイル２２１、２
２１、…、及び文字レイヤ２３０に含まれるメッシュご
との文字ファイル２３１、２３１、…には、それぞれの
メッシュのメッシュ番号（Ｘi、Ｙｊ）と同じファイル
名「ＸiＹｊ」が付けられている。従って、或るメッシ
ュの地図データが欲しいとき、そのメッシュのメッシュ
番号（つまり、緯度方向と経度方向の座標値）が分れ
ば、そのメッシュ番号がそのまま欲しい地図データのフ
ァイル名を表すことになる。これにより、地図表示プロ
グラム３２が、ユーザの欲する表示範囲に必要なメッシ
ュかを決定して、それらのメッシュのデータを地図サー
バ１０に要求するとき、メッシュ番号から要求すべきフ
ァイル名を即座に決めることができる。

【００２５】図３に示すように、（必ずしもそうである
必要はないが）この実施形態では、ポリゴンレイヤ２１
０、線レイヤ２２０及び文字レイヤ２３０はぞれぞれ、
地図データベース１１内の異なるディレクトリ、例えば
ポリゴンレイヤディレクトリ１２１、線レイヤディレク
トリ１２２及び文字レイヤディレクトリ１２３に格納さ
れている。

【００２６】図４は、図３に示した地図データベース１
１内のレイヤ別のディレクト１２１〜１２３の各々の内
部の階層構造を示す。

【００２７】前述したように、１つのメッシュのサイズ
は、ユーザに待つという実感を与えない程度の短時間で
１回のＨＴＴＰセッションを終えられる程度に、適度に
小さく設定されている。そのため、地図の全体領域は膨
大な数のメッシュに分割されている。この膨大な数のメ
ッシュのファイルを単純に１つのディレクトリに並列に
格納したとすると、或るファイルの要求が着たとき、そ
のファイルを検索するのに非常に長い時間がかかってし
まう。そこで、この実施形態では、図４に示すような階
層構造のディレクトリで、その膨大な数のメッシュのフ
ァイルを管理している。

【００２８】すなわち、図４（Ｃ）に示すような連続的
な位置座標（つまりメッシュ番号、つまりファイル名）
をもつ８×８配列の６４個のメッシュのファイル１３
１、１３１、…を１群に纏めて、図４（Ｂ）に示す１階
層上（第２階層）のディレクトリ（以下、「フォルダ」
という）１３２、１３２、…の一つに格納してある。そ
して、図４（Ｂ）に示す各フォルダ１３２のフォルダ名
（ディレクトリ名）は、各フォルダに格納された６４個
のメッシュファイル１３１、１３１、…のファイル名
「ＸiＹj」の経度成分「Ｘi」と緯度成分「Ｙj」をそれ
ぞれ経度方向と緯度方向のファイル数「８」で除算した
商で表した名称、つまり

【００２９】

【数１】となっている。よって、この第２階層の各フォルダ１３
２のフォルダ名は、各フォルダ１３２に格納されている
６４個のメッシュファイルがカバーする８×８メッシュ
区域の位置座標に相当するということができる。

【００３０】そして、図４（Ｂ）に示すような連続的な
フォルダ名（つまり図４（Ｃ）に示した８×８メッシュ
区域の位置座標）をもつ８×８配列の６４個の第２階層
のフォルダ１３２、１３２、…を１群に纏めて、図４
（Ａ）に示す更に１階層上（第１階層）のフォルダ１３
３、１３３、…の一つに格納してある。そして、図４
（Ａ）に示す各フォルダ１３３のフォルダ名（ディレク
トリ名）は、各フォルダ１３３に格納された６４個のフ
ォルダ１３２、１３２、…のフォルダ名の経度成分「Ｘ
i／８」と緯度成分「Ｙj／８」をそれぞれ経度方向と緯
度方向のフォルダ数「８」で除算した商で表した名称、
つまり

【００３１】

【数２】となっている。よって、この第１階層の各フォルダ１３
３のフォルダ名は、各フォルダ１３３に格納されている
第２階層の８×８個のフォルダ（つまり、６４×６４個
のメッシュファイル）がカバーする６４×６４メッシュ
区域の位置座標に相当するということができる。

【００３２】さらに、図４（Ａ）に示すような連続的な
フォルダ名（つまり６４×６４メッシュ区域の位置座
標）をもつ８×８配列の６４個の第１階層のフォルダ１
３３、１３３、…を１群に纏めて、図示しない更に上の
階層のディレクトリ（ポリゴンレイヤの場合ならば、例
えば図３に示したポリゴンレイヤディレクトリ１２１）
に格納してある。

【００３３】なお、この実施形態では、図４（Ａ）〜
（Ｃ）に示したように、３階層の構造のディレクトリを
用い、１つのディレクトリで６４個のファイル又はフォ
ルダを管理することで、全部で６４×６４×６４＝約２
６万個のメッシュのファイルを管理することができる。
しかし、これは一例であり、メッシュの個数が更に多く
なれば、更に階層数を増やしても良い。また、６４個の
ファイル又はフォルダを１ディレクトリに管理するよう
にした理由は、米国マイクロソフト社のＯＳ環境である
Windows環境（このＯＳ環境では、１ディレクトリ内の
ファイル又はフォルダの数が１００より少ないときに高
い検索速度が得られる）で地図サーバ１０を稼動させる
場合には６４個が扱いやすいと判断したためであり、一
例に過ぎない。

【００３４】図４に示した階層構造のディレクトリで重
要なことは、各階層のディレクトリの名称が、最終的な
検索目的である特定のメッシュのファイル名から簡単に
計算できるようになっている点である。すなわち、「Ｘ
iＹj」という名称のファイルが欲しいとき、そのファイ
ル名「ＸiＹj」の経度成分Ｘiと緯度成分Ｙjをそれぞれ
８で割っていくことで、より上位のフォルダのフォルダ
名が簡単に決定され、それを並べることで、目的のメッ
シュのファイルのへのパスが

【００３５】

【数３】というように簡単に決定される。因みに、ｎ階層のディ
レクトリであるならば、目的のファイルのへのパスは

【００３６】

【数４】というように、簡単に計算で決定される。なお、ファイ
ル名「ＸiＹj」の経度成分Ｘiと緯度成分Ｙjをそれぞれ
８で割っていくという上記の計算方法は一例にすぎず、
別の計算方法を採用してもよい。

【００３７】どのような計算方法を用いるにせよ、目的
のメッシュのファイル名から、そのファイルへのパスが
所定の数値演算で演算できることは、各メッシュのファ
イル名がそのメッシュのメッシュ番号（位置座標）に相
当するという前述の特徴と相俟って、地図表示プログラ
ム３２が表示に必要なメッシュのファイルを地図サーバ
１０に要求するときの手間を大幅に簡単化し、地図表示
の高速化に寄与する。

【００３８】図５は、地図表示プログラム３２の機能的
な構成を示す。

【００３９】図５に示すように、地図表示プログラム３
２は、表示部３２０とダウンローダ３２２を有する。表
示部３２０の主たる役目は、ユーザによるマウス等を用
いた地図のスクロールや拡大縮小の操作に応答して、地
図の表示すべき範囲を決め、その表示範囲に必要なメッ
シュのファイル名（メッシュ番号）を決めて、そのメッ
シュのファイルをダウンローダ３２２に要求すること
と、ダウンローダ３２２から取得したメッシュのファイ
ルに含まれるベクトルデータから表示すべき地図画像を
描画することである。また、ダウンローダ３２２の主た
る役割は、表示部３２０からファイルの要求を受けて、
その要求されたファイルを地図サーバ１０からダウンロ
ードすることである。

【００４０】表示部３２０は、過去に取得したファイル
のデータを最近のアクセス頻度などに応じた優先順位で
メモリ内に保存しておくメモリ・キャッシュ３２１を有
している。ダウンローダ３２６は、ダウンロード対象の
ファイルのファイル名（地図サーバ１０内のそのファイ
ルへのパス）をリストアップしたダウンロード・リクエ
スト・リスト３２５（表示部３２０は随時にこのリスト
内のファイル名を消去する）と、新たなファイルがダウ
ンロードされたか否かを表示部３２０に知らせるための
ダウンロード・フラグ３２６と、各ファイルをダウンロ
ードするときの各ＨＴＴＰセッションをそれぞれ行う複
数のＨＴＴＰセッション・スレッド３２４Ａ〜３２４Ｄ
（図示の例では４個のスレッドがあるが、その個数は可
変である）、及び、ダウンロードしたファイルをハード
ディスクドライブなどの大容量の不揮発性ストレージに
保存しておくディスク・キャッシュ３２３を有してい
る。

【００４１】図６は、表示部３２０の動作の流れを示し
ている。

【００４２】ユーザがマウスなどで地図のスクロール又
は拡大縮小などの地図の表示範囲を変化させる操作を行
うと（ステップＳ１）、表示部３２０はこれに応答し
て、次の動作を行う。すなわち、ダウンロード・リクエ
スト・リスト３２５に記載されている全てのファイル名
を消去し（Ｓ２）、ダウンロード・フラグ３２６をリセ
ットし（Ｓ４）、そして、変化後の新しい表示範囲を決
定して、その表示範囲に必要なメッシュのファイル名
（メッシュ番号）を決定する（Ｓ５）。ステップＳ５で
は、表示部３２０は、拡大縮小操作で決まる表示倍率に
基づいて、その表示範囲に表示すべき地図の縮尺として
最適な縮尺を（例えば、表示倍率が大きければ大縮尺、
中程度なら中縮尺、小さければ小縮尺というように）決
定し、その最適縮尺の地図について、新しい表示範囲に
必要なファイル名を決定する（ここで決定したの最適縮
尺のファイルを、以下「必要ファイル」という）。それ
に加え、この最適縮尺の必要ファイルが直ちに入手でき
なかったときの一時的な代替表示（つまり、前述したプ
ログレッシブ表示を行う）ために、最適縮尺よりも小さ
い（つまり、分母がより大きい）各縮尺の地図について
も、新しい表示範囲と重なるメッシュのファイル名を決
定する（この代替表示のためのより小縮尺の地図のファ
イルを、以下、「代替ファイル」という）。

【００４３】続いて、表示部３２０は、その新しい表示
範囲に、最初にポリゴンレイヤ、次に線レイヤ、最後に
文字レイヤの順で地図画像を描画して表示するために、
以下の処理に入る。

【００４４】まず、ポリゴンレイヤの表示が未完了の段
階（Ｓ６でＮＯ）では、ポリゴンレイヤのファイルであ
って、ステップＳ５で決定したファイル名（メッシュ番
号）をもつものを、メモリ・キャッシュ３２１から探す
（Ｓ９）。このとき、各メッシュについて、まず、最適
縮尺の必要ファイルを探し、それが無ければ、それより
１段階小縮尺の代替ファイルを探し、それも無ければ、
更に１段階小縮尺の代替ファイルを探す。このように、
最適縮尺の必要ファイルを最優先に探し、それがない場
合、段階的により小縮尺の代替ファイルを探していく。
メモリ・キャッシュ３２１内から目的のファイル（必要
ファイルか又は代替ファイル）が見つかれば（Ｓ９でＹ
ＥＳ）、そのファイルのベクトルデータからポリゴン地
図画像を描画してディスプレイ画面の対応するメッシュ
の領域に表示する（Ｓ１０）。このとき、より小縮尺の
地図画像が既に代替表示されていたところに、より大縮
尺の地図画像を表示しようとする場合には、その先に代
替表示されていた小縮尺の地図画像を消去して、より大
縮尺の地図画像を新たに表示することになる。

【００４５】全ての必要ファイルがメモリ・キャッシュ
３２１から見つかれば（Ｓ１１でＮＯ）、ポリゴンレイ
ヤの地図の表示が完了するので、次に、表示範囲に変化
がない限り（Ｓ１７でＮＯ）、まだ未完了な線レイヤの
地図の描画と表示を行うために（Ｓ７でＮＯ）、上述し
たステップＳ９以下の処理に入る。線レイヤについて
も、全ての必要ファイルがメモリ・キャッシュ３２１か
ら見つかれば（Ｓ１１でＮＯ）、次に、表示範囲に変化
がない限り（Ｓ１７でＮＯ）、まだ未完了な文字レイヤ
の地図の描画と表示をするために（Ｓ８でＮＯ）、上述
したステップＳ９以下の処理に入る。ポリゴンレイヤの
地図画像が既に表示されているところに、次に線レイヤ
の地図画像を表示するときや、更にその文字レイヤの地
図画像を表示するときには、より小縮尺の地図画像が代
替表示されていたところにより大縮尺の地図画像を表示
する場合とは違って、既に表示されているポリゴンレイ
ヤの地図画像を消去することなく、それに重ねて線レイ
ヤの地図画像を表示し、更にそれに重ねて文字レイヤの
地図画像を表示していく。

【００４６】一方、ポリゴンレイヤの地図を表示しよう
としているとき、メモリ・キャッシュ３２１からは見つ
からない必要ファイルが一つでもあった場合には（Ｓ１
１でＹＥＳ）、表示部３２０は次に、その見つからなか
った必要ファイルと、その見つからなかった必要ファイ
ルのための代替ファイルであってメモリ・キャッシュ３
２１から見つからなかったもの（これらの見つからなか
った必要ファイルと代替ファイルを、以下、「不足ファ
イル」と総称する）を、ダウンローダ３２２に要求する
（Ｓ１２）。このときも、表示部３２０は、まず最適縮
尺の必要ファイルを最優先で要求し、続いて、段階的に
より小縮尺の代替ファイルを要求する。

【００４７】後述するように、ダウンローダ３２２は、
表示部３２０から不足ファイルの要求を受けると、要求
された順番で（つまり、表示部３２０がメモリ・キャッ
シュ内を探したときと同様に、まず必要ファイル、それ
が見つからなければ、段階的により小縮尺の代替ファイ
ルの順で）、各不足ファイルをディスク・キャッシュ３
２３の中から探し、見つかれば、ディスク・キャッシュ
３２３内で見つかったそのファイルへのパスを表示部３
２０に返し、見つからなければ、ファイル無しという回
答を表示部３２０に返す。表示部３２０は、ダウンロー
ダ３２２から、ディスク・キャッシュ３２３内で見つか
ったファイルへのパスを受けた場合には（Ｓ１３でＹＥ
Ｓ）、そのパスを用いてそのファイルをディスク・キャ
ッシュ３２３から読み込んでメモリ・キャッシュ３２１
に保存し（Ｓ１４）、そしてそのファイルのベクトルデ
ータからポリゴンの地図画像を描画して、ディスプレイ
画面の対応するメッシュの領域に表示する（Ｓ１５）。
前述したように、より小縮尺の地図画像が既に代替表示
されていたところに、より大縮尺の地図画像を表示しよ
うとする場合には、その先に代替表示されていた小縮尺
の地図画像を消去して、より大縮尺の地図画像を新たに
表示することになる。

【００４８】全ての必要ファイルがディスク・キャッシ
ュ３２３から見つかれば（Ｓ１６でＮＯ）、ポリゴンレ
イヤの地図の表示が完了するので、次に、表示範囲に変
化がない限り（Ｓ１７でＮＯ）、既に説明したと同様
に、線レイヤの地図を描画し表示する処理（Ｓ９以下）
に入る。線レイヤについても、全ての必要ファイルがデ
ィスク・キャッシュ３２３から見つかれば（Ｓ１６でＮ
Ｏ）、線レイヤの地図の表示が完了するので、次に、表
示範囲に変化がない限り（Ｓ１７でＮＯ）、同様に、文
字レイヤの地図を描画し表示する処理（Ｓ９以下）に入
る。前述したように、ポリゴンレイヤの地図画像が既に
表示されているところに、次に線レイヤの地図画像を表
示するときや、更にその文字レイヤの地図画像を表示す
るときには、より小縮尺の地図画像が代替表示されてい
たところにより大縮尺の地図画像を表示する場合とは違
って、既に表示されているポリゴンレイヤの地図画像を
消去することなく、それに重ねて線レイヤの地図画像を
表示し、更にそれに重ねて文字レイヤの地図画像を表示
していく。

【００４９】このようにして、全てのレイヤの全ての必
要ファイルがメモリ・キャッシュ３２１内か又はディス
ク・キャッシュ３２３内に存在すれば、新しい表示範囲
の地図の表示は瞬時に完了する。新しい表示範囲の地図
の表示が完了すれば（Ｓ８でＹＥＳ）、処理は最初に戻
る。

【００５０】一方、ポリゴンレイヤの不足ファイルをダ
ウンローダ３２２に要求したところ、ダウンローダ３２
２からファイル無しという回答が返って来た必要ファイ
ルが一つでもあった場合には（Ｓ１６でＹＥＳ）、表示
部３２０の処理は最初に戻る。そして、表示部３２０
は、表示範囲に変化が無い限り（Ｓ１でＮＯ）、ダウン
ロード・フラグ３２６が立つのを待つ（Ｓ２）。後述す
るように、ダウンローダ３２２は、或るファイルについ
てファイル無しという回答を返した場合には、そのファ
イルを地図サーバ１０からダウンロードする作業に入
り、そのファイルのダウンロードが終わると、そのファ
イルをディスク・キャッシュ３２３に格納して、ダウン
ロード・フラグ３２６を立てる。ダウンロード・フラグ
３２６が立ったことを知ると（Ｓ２でＹＥＳ）、表示部
３２０は、表示範囲が変化したときに行ったと同様のス
テップＳ３以下の処理を再び繰り返す。すなわち、ダウ
ンロード・リクエスト・リスト３２５内の全てのファイ
ル名を消去し（Ｓ２）、ダウンロード・フラグ３２６を
リセットし（Ｓ４）、表示範囲を計算し直して、その表
示範囲に必要なメッシュのファイル名（メッシュ番号）
を決定し（Ｓ５）、そして、ポリゴンレイヤ、線レイ
ヤ、文字レイヤの順でファイルを取得して地図画像を描
画して表示するためのステップＳ９以下の処理を繰り返
す。それにより、表示部３２０は、既に描画して表示済
みであったメッシュについては、再び同じ地図画像を描
画して表示し直すことになり、また、ファイルがダウン
ロードされたメッシュについては、そのダウンロードさ
れたファイルをディスク・キャッシュ３２３から読み込
んで地図画像を描画してそのメッシュの領域に表示する
ことになる。

【００５１】不足ファイルが１つダウンロードされる都
度に、表示部３２０は、ステップＳ３からの処理を繰り
返すので、ディスプレイ画面上の表示領域は１メッシュ
づつ順次に完成に近づいていく。ディスプレイ画面上の
表示領域全域の地図画像が完成すると（Ｓ８でＹＥ
Ｓ）、表示部３２０は、最初のステップＳ１に戻り、ユ
ーザによって表示範囲が変更されるの待ち、変更されれ
ばステップＳ３以下の処理を再び繰り返す。

【００５２】また、ディスプレイ画面上の表示領域全域
の地図画像が完成する前に、ユーザによって表示範囲が
変更された場合（Ｓ１７でＹＥＳ）にも、表示部３２０
は、ステップＳ３以下の処理を再び繰り返す。

【００５３】図７は、ダウンローダ３２２の動作の流れ
を示す。

【００５４】図７に示すように、ダウンローダ３２２
は、表示部３２０からファイルの要求を受けると（Ｓ２
１）、まず、その要求されたファイルをディスク・キャ
ッシュ３２３から探す（Ｓ２２）。ディスク・キャッシ
ュ３２３からその目的のファイルが見つかれば（Ｓ２２
でＹＥＳ）、ダウンローダ３２２は、そのファイルのデ
ィスク・キャッシュ３２３内でのパスを表示部３２０に
知らせる（Ｓ２３）。表示部３２０から要求された全て
のファイルがディスク・キャッシュ３２３から見つかっ
て、それらのパスを表示部３２０に通知ことができれば
（Ｓ２４でＮＯ）、ダウンローダ３２２は、最初のステ
ップＳ２１へ戻り、表示部３２０から再びファイルの要
求が来るのを待つ。

【００５５】一方、表示部３２０から要求されたファイ
ルの中にディスク・キャッシュ３２３から見つからなか
ったファイルがあれば（Ｓ２４でＹＥＳ）、ダウンロー
ダ３２２は、その見つからなかったファイルについてフ
ァイル無しの旨を表示部３２０へ通知する（Ｓ２５）と
共に、その見つからなかったファイルのファイル名（地
図サーバ１０内でのそのファイルへのパスを含む）をダ
ウンロード・リクエスト・リスト３２５に書く（Ｓ２
６）。このとき、ダウンロード・リクエスト・リスト３
２５には、予め、既に説明した表示部３２０による図６
のステップＳ３の処理により、過去に書いてあったファ
イル名は全て消去されているので、このときに見つから
なかったファイルのファイル名だけが書かれることにな
る。このとき、ダウンローダ３２２は、見つからなかっ
たファイルのうち、より小縮尺の地図のファイルを優先
的にダウンロード・リクエスト・リスト３２５に書いて
いく（つまり、小縮尺のファイルほどリストの先頭近く
に書かれる）。

【００５６】続いて、ダウンローダ３２２は、ダウンロ
ード・リクエスト・リスト３２５に書かれているファイ
ル名を、そのリスト３２５の先頭から順に（つまり、よ
り小縮尺の地図ファイルから優先的に）、アイドル状態
にあるＨＴＴＰセッション・スレッド３２４Ａ〜３２４
Ｄへ割り当てていく（Ｓ２８）。ＨＴＴＰセッション・
スレッド３２４Ａ〜３２４Ｄは、ファイル名を割り当て
られると直ちに地図サーバ１０との間でＨＴＴＰセッシ
ョンを実行して、それぞれに割り当てられたファイルを
地図サーバ１０からダウンロードする。より小縮尺の地
図のファイルから先にＨＴＴＰセッション・スレッド３
２４Ａ〜３２４Ｄに割り当てたので、ダウンロードも、
より小縮尺の地図のファイルから先に完了する。

【００５７】個々のファイルのダウンロードが完了する
都度（Ｓ２９でＹｅｓ）、ダウンローダ３２２は、その
ファイルのファイル名をダウンロード・リクエスト・リ
スト３２５から消去し（Ｓ３０）、そのファイルをディ
スク・キャッシュ３２３に保存し（Ｓ３１）、そして、
ダウンロード・フラグ３２６を立てる（Ｓ３２）。その
後、ダウンローダ３２２は、最初のステップＳ２１へ戻
って、表示部３２０から再びファイル要求が来るのを待
つ。ダウンロード・フラグ３２６を立てると、既に説明
したように、表示部３２０が再びファイル要求を発し、
ダウンロードされたファイルをディスク・キャッシュ３
２３から読み出してその地図画像を描画し表示する。

【００５８】以上の表示部３２０とダウンローダ３２２
の動作説明を要約すれば、ダウンローダ３２２は、ひた
すら、不足したファイルをダウンロードする処理を単純
に繰り返すだけである。また、表示部３２０は、表示範
囲の変化又はファイルのダウンロード完了が発生する都
度、ひたすら、表示範囲に必要な全てのファイルの入手
を試みて、入手できたファイルのみで地図を描画する処
理を単純に繰り返すだけである。そこには、表示範囲が
変化したり、ファイルのダウンロードが完了する都度、
既に描画済みのファイルも含めて必要な全てのファイル
を入手して始めから描画し直すという、一見無駄に思え
る重複作業が入っているが、その見返りとして、どのフ
ァイルの描画が完了し、どのファイルの描画が完了して
ないかを判別して、未描画のファイルだけを選択的に描
画するというような面倒な判断処理を行わずに済んでい
る。また、表示部３２０とダウンローダ３２２は非同期
で動作しており、両者の動作タイミングを合わせるとい
うような面倒な同期処理も行っていない。これらのこと
から、結果的に、地図画像を高速に表示することが可能
である。

【００５９】また、クライアントコンピュータ３０で描
画を行うため、地図サーバ１０に描画の負担をかけさせ
ないという点も、地図サーバ１０の応答を高速化し、地
図画像の高速表示に寄与する。

【００６０】それに加え、最終的に欲しい地図画像を一
気に完成させようとするのではなく、ポリゴンレイヤ、
線レイヤ、文字レイヤの順で地図画像を順次に表示して
いくという、見え方の異なる地理要素のプログレッシブ
表示の手法と、より小縮尺の地図ファイルを先にダウン
ロードして先に表示するという、縮尺の異なる地図画像
のプログレッシブ表示（つまり、最適縮尺の地図が手元
に無い時のより小縮尺の地図によるを代替表示）の手法
とを用いることで、ユーザにダウンロード時間に起因す
る地図表示の遅さを実質的に感じさせることなく、連続
的で円滑なスクロールや拡大縮小の操作感を実感させる
ことができる。

【００６１】図８は、このプログレッシブ表示の一例を
示す。

【００６２】図８（Ａ）に示すような或る地域の大縮尺
地図を表示している状態から、ユーザが地図のスクロー
ルを行ったとする。すると、最終的には図８（Ｄ）に示
すような、スクロール先の地域の完全な大縮尺地図が表
示されることになるが、この図８（Ｄ）の最終的な画面
に至るまでに、図８（Ｂ）や（Ｃ）に示す中間段階の画
面が順番に表示される。

【００６３】図８（Ｂ）の画面は、スクロール直後のも
のであり、図中の破線は、メッシュの境界を示す。この
スクロール直後の画面では、右上の１つのメッシュ４１
についてだけ、大縮尺地図のポリゴンレイヤのファイル
が既にキャッシュ内にあったため、大縮尺地図のポリゴ
ン画像が表示されている。残りの３つのメッシュ４２〜
４４については、まだ大縮尺地図のポリゴンレイヤのフ
ァイルはダウンロード中であるため、大縮尺地図の画像
は全く表示されていないが、しかし、中縮尺地図のファ
イルがキャッシュ内にあったため、その中縮尺地図に載
っている大きい建物４３１、４４１のポリゴン画像が代
替表示されている。

【００６４】少し待つと、残り３つのメッシュ４２〜４
４についても、大縮尺地図のポリゴンレイヤのファイル
のダウンロードが完了して、図８（Ｃ）に示すような画
面となる。この画面では、大縮尺地図のポリゴンレイヤ
の表示は完了しているが、次の線レイヤについては、ま
だ、右上の１つのメッシュ４１についてしか表示が完了
していない。残りの３つのメッシュ４２〜４４について
は、まだ大縮尺地図の線レイヤのファイルはダウンロー
ド中であるため、大縮尺地図の線レイヤの画像は全く表
示されていないが、しかし、中縮尺地図のファイルがキ
ャッシュ内にあった（又は、先にダウンロード完了し
た）ため、その中縮尺地図に載っている主要な道路４３
２、４３３の線画像が代替表示されている。

【００６５】更に少し待つと、大縮尺地図の全てのレイ
ヤのファイルが揃い、図８（Ｄ）に示すような最終的な
画面が完成する（ただし、図では、文字レイヤの画像は
図示省略してある）。

【００６６】従来技術によれば、図８（Ａ）の状態から
スクロールを行うと、地図サーバ側で図８（Ｄ）のよう
な最終的な画面を作成して送信してくるため、スクロー
ル操作をしてから長い時間待った後に、画面が図８
（Ａ）から図８（Ｄ）へと一気に切換わることになる。
これに対し、本実施形態では、スクロール操作をする
と、直ぐに図８（Ｂ）のような画面が表示され、段階的
に図８（Ｄ）の最終画面へ完成されていくので、ユーザ
としては、直ちに地図表示が開始されたという実感をも
つことができ、スクロール先がどこであるかも即座に判
断できるので連続的なスクロール感が得られる（拡大縮
小も同様）。また、特に建物などのポリゴン画像が真っ
先に表示されるので、ユーザは即座に地図を把握し易
い。

【００６７】さらに、図８（Ｂ）のような不完全な画像
が表示された段階でも、ユーザはそれがどの地域である
かが分るから、更にもっと先へスクロールを進めるべき
か否かが即座に判断でき、必要なら、スクロールを止め
ることなく先へ先へと連続的に進めていくことができ
る。

【００６８】図９は、複数の地図サーバを設けて負担を
分散するようにした本発明の別の実施形態を示す。

【００６９】複数台の地図サーバ５０、５０、…が、イ
ンターネット６０などの通信ネットワークに接続されて
おり、多数のクライアントコンピュータ７０、７０、…
の各々は、それら複数台の地図サーバ５０、５０、…の
いずれにもアクセスすることができる。複数台の地図サ
ーバ５０、５０、…は、同じ地図データを格納した地図
データベース５１、５１、…をそれぞれもつ。

【００７０】図１０は、クライアントコンピュータ７０
がユーザの所望する表示範囲に必要なメッシュのファイ
ルを複数台の地図サーバ５０、５０、…に要求するとき
の方法を示したものである。

【００７１】各クライアントコンピュータ７０は、原則
的に、図１０（Ａ）に示すように、表示範囲８０と重な
る複数のメッシュ８１、８１、…のファイルを、全部１
台の地図サーバ５０に要求するのではなく、最初のメッ
シュはＡサーバに、次のメッシュはＢサーバに、次のメ
ッシュはＣサーバにというように、複数のファイルを複
数台のサーバ５０、５０、…にほぼ均等に分散して要求
する。それにより、複数台のサーバ５０、５０、…で負
荷が均等に分散され、より高速な地図表示が可能にな
る。また、複数台のサーバ５０、５０、…のどれもが同
じ地図データをもっているので、それらサーバ５０、５
０、…のメンテナンスも容易である。

【００７２】また、もし、複数台のサーバ５０、５０、
…の中のどれか、例えばＣサーバ、に障害が発生したと
する。この場合、各クライアントコンピュータ７０は、
Ｃサーバから正常な応答が返って来ないことを知ると、
図１０（Ｂ）に示すように、残りの正常なＡサーバとＢ
サーバに対して、ファイルを均等に分散して要求する。
このように、複数台のサーバ５０、５０、…のどれもが
同じ地図データをもっているので、その中の一部のサー
バで障害が発生しても、他のサーバが代わって対応する
ことができる。

【００７３】複数のサーバによる負荷分散の形態には、
上記以外にも色々なものが採用し得る。例えば、地域毎
にサーバを分けても良い。例えば、アクセスの多い首都
圏を１台か複数台のサーバが担当し、残りの地域を別の
１台か複数台のサーバが担当するというようにである。
或いは、縮尺の異なる地図別にサーバを分けてもよい。
例えば、データ量の多い大縮尺地図を１台か複数台のサ
ーバが担当し、残りの縮尺の地図を別の１台か複数台の
サーバが担当するというようにである。また、レイヤー
毎にサーバを分けても良い。

【００７４】以上、本発明の実施形態を説明した、これ
らの実施形態は本発明の説明のための例示にすぎず、本
発明の範囲を上記実施形態のみに限定する趣旨ではな
い。よって、本発明は、上記の実施形態以外の様々な形
態でも実施することが可能である。例えば、上記実施形
態では、ポリゴン、線及び文字の各レイヤの各メッシュ
のデータが１つのファイルとなっているが、必ずしもそ
うである必要はない。ポリゴン、線及び文字の各レイヤ
が、更に複数のサブレイヤに分れていて（例えば、線レ
イヤが、国道レイヤ、地方道レイヤ、鉄道レイヤ、河川
レイヤなどのサブレイヤに分れていて）、各サブレイヤ
の各メッシュのデータが１つのファイルになっていても
よい。また、上記実施形態では、各地図データのカバー
する全体地域が小面積のメッシュに細分されていて、全
体の地図データはメッシュ単位のデータに断片化されて
いたが、必ずしもそうである必要はない。メッシュ毎に
断片化する代わりに、或いは、メッシュ毎の断片化と併
用して、地図を構成する個々の地理要素（例えば、各道
路、各鉄道線路、各河川、各建物、各敷地、各地図記
号、各アイコンなど）毎に断片化することもできる。

【図面の簡単な説明】

【図１】本発明に従う地図表示システムの一実施形態の
概略的な全体構成を示すブロック図。

【図２】地図サーバ１０がもつ地図の種類と、クライア
ントコンピュータ３０内の地図表示プログラム３２が地
図サーバ１０に対して地図データを要求する順序を説明
した図。

【図３】地図サーバ１０がもつ各種類の地図のファイル
構成を示す説明図。

【図４】図３に示した地図データベース１１内のレイヤ
別のディレクト１２１〜１２３の各々の内部の階層構造
を示す説明図。

【図５】地図表示プログラム３２の機能的な構成を示す
ブロック図。

【図６】表示部３２０の動作のフローチャート。

【図７】ダウンローダ３２２の動作のフローチャート。

【図８】プログレッシブ表示の一例を示す画面の遷移
図。

【図９】複数の地図サーバで負担を分散した実施形態を
示すブロック図。

【図１０】クライアントコンピュータ７０がユーザの所
望する表示範囲に必要なメッシュのファイルを複数台の
地図サーバ５０、５０、…に要求するときの方法を示し
た説明図。

【符号の説明】

１０地図サーバ２０インターネット３０クライアントコンピュータ３１クライアントプログラム３２地図表示プログラム３４マウス１３１メッシュのファイル１３２第２階層のフォルダ１３３第１階層のフォルダ２１１、２２１、２３１メッシュ

───────────────────────────────────────────────────── フロントページの続き (72)発明者田渕大介東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー16階ドリームテクノロジーズ株式会社内 (72)発明者日向野保夫東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー16階ドリームテクノロジーズ株式会社内 (72)発明者中島一郎東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー16階ドリームテクノロジーズ株式会社内Ｆターム(参考） 2C032 HB25 HB31 HC24 HC25 5B050 BA06 BA17 CA07 EA12 EA19 FA02 FA19 5B075 KK07 KK33 ND20 PQ02 PQ66 UU13

Claims

【特許請求の範囲】

【請求項１】多数の断片地図データに細分された全体
地図データをもつ地図サーバと、所望の断片地図データを、前記地図サーバから通信ネッ
トワークを通じてダウンロードし、ダウンロードした前
記断片地図データから地図画像を描画して表示するクラ
イアントとを備えた地図表示システム。
【請求項２】前記断片地図データが、前記全体地図デ
ータのカバーする全体地域を地域的に細分した個々のメ
ッシュ毎の地図データである請求項１記載の地図表示シ
ステム。
【請求項３】前記断片地図データが、前記全体地図デ
ータが表す地図画像に含まれる個々の地理要素を表す地
図データである請求項１記載の地図表示システム。
【請求項４】前記地図サーバがもつ各断片地図データ
は、前記断片地図データがもつ地理的な位置座標によっ
て指定することができる前記地図サーバ内の記憶場所に
格納されている請求項１記載の地図表示システム。
【請求項５】前記地図サーバがもつ前記全体地図デー
タは、異なる種類の地理要素毎の複数のレイヤに分けら
れており、前記クライアントは、前記所望の断片地図データを前記
地図サーバからダウンロート゛するとき、前記複数のレイ
ヤに対して予め与えた優先順位に従った順序で、各レイ
ヤの前記断片地図データを逐次にダウンロードする請求
項１記載の地図表示システム。
【請求項６】前記地図サーバは、異なる縮尺の複数の
地図の地図データを有しており、前記クライアントは、前記異なる縮尺の複数の地図のう
ち、より小縮尺の地図から優先的に、前記所望のメッシ
ュの地図データをダウンロードする請求項１記載の地図
表示システム。
【請求項７】複数台の前記地図サーバを備え、前記クライアントは、前記複数台の地図サーバのいずれ
からも前記断片地図データをダウンロードできる請求項
１記載の地図表示システム。
【請求項８】多数の断片地図データに細分された全体
地図データを持つ地図サーバから、通信ネットワークを
通じて、所望の断片地図データをダウンロードするステ
ップと、ダウンロードした前記断片地図データから地図画像を描
画して表示するステップとを備えた地図表示方法。
【請求項９】多数の断片地図データに細分された全体
地図データを持つ地図サーバから、通信ネットワークを
通じて、所望の断片地図データをダウンロードする手段
と、ダウンロードした前記断片地図データから地図画像を描
画して表示する手段とを備えた地図表示装置。
【請求項１０】多数の断片地図データに細分された全
体地図データを持つ地図サーバから、通信ネットワーク
を通じて、所望の断片地図データをダウンロードするス
テップと、ダウンロードした前記所望の断片地図データから地図画
像を描画して表示するステップとをコンピュータに実行
させるためのプログラムを記録した、コンピュータ読取
可能な記録媒体。
【請求項１１】多数の断片地図データに細分された全
体地図データをもち、各断片地図データを、各断片地図データがもつ地理的な
位置座標によって指定することができる場所に格納して
おり、クライアントが所望する断片地図データを、通信ネット
ワークを通じて前記クライアントに送信する地図サー
バ。
【請求項１２】多数の断片地図データに細分された全
体地図データをもち、各断片地図データが、各断片地図データの地理的な位置
座標によって指定することができる場所に格納してある
地図データベースを記録した、コンピュータ読取可能な
記録媒体。