JP2003208597A

JP2003208597A - 画像コンバータ及び画像コンバート方法

Info

Publication number: JP2003208597A
Application number: JP2002005114A
Authority: JP
Inventors: Wataru Shoji; 渉庄司; Daisuke Tabuchi; 大介田渕; Ichiro Nakajima; 一郎中島; Yasuo Higano; 保夫日向野; Tomonori Ito; 友紀伊藤
Original assignee: Dream Technologies Corp
Current assignee: Dream Technologies Corp
Priority date: 2002-01-11
Filing date: 2002-01-11
Publication date: 2003-07-25

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をそれぞれ
８で割っていくという上記の計算方法は一例にすぎず、
別の計算方法を採用してもよい。

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

【００３９】図５は、イメージビューワ３２の機能的な
構成を示す。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００７５】さて、上述したシステムは、地図を取り扱
うものであるが、本発明が適用できる画像の種類は、地
図だけに限られず、あらゆる種類の画像にわたる。一般
的な画像に本発明を適用した場合、例えば、その画像に
ついてピクセルサイズの異なる複数のビットマップ画像
データを用意し、各サイズのビットマップ画像データを
メッシュに分割し、それらのメッシュデータを、上述し
たようにサーバからネットワークを通じてクライアント
配信し、クライアントにて表示することができる。

【００７６】次に、本発明に従う画像コンバータの一実
施形態について説明する。

【００７７】この画像コンバータは、上述した画像表示
システムのサーバ１０に蓄積されるような、それぞれメ
ッシュ分割された異なる縮尺（ピクセルサイズ、深さ）
をもつた複数枚の画像データを作成して、それをサーバ
にアップロードするために用いられる。この画像コンバ
ータは、例えば上述した地図表示システムのために使用
される場合には、上述したような地図画像データ１１を
作成するのであるが、地図は単なる説明のための一例に
すぎず、あらゆる内容のビットマップ画像を処理するこ
とができる。この画像コンバータは、以下の実施形態で
はコンピュータプログラムをコンピュータで実行するこ
とによって実現されるが、それだけに限られるわけでは
なく専用ハードウェアを用いて実現することもできる。
この画像コンバータを実現するコンピュータプログラム
は、以下の実施形態では例えば図１に示したクライアン
トコンピュータ３０にインストールされるが、それにの
みに限られるわけではなく、他のコンピュータにもイン
ストールすることができる。

【００７８】図１１は、この画像コンバータが行う処理
の流れを示す。

【００７９】図１１に示すように、画像コンバータは、
ステップＳ１０１で、ユーザの指示によりコンバート対
象の元画像データを選択する。元画像データは原則的に
ビットマップ（ラスタ型）画像データであるが、それに
限られるわけではなく、ベクタ型画像データであっても
よく、その場合には、画像コンバータはそのベクタ型画
像データを読み込んでビットマップ（ラスタ型）画像デ
ータに変換することになる。

【００８０】ステップＳ１０２とＳ１０３で、画像コン
バータは、ユーザの指示により、メッシュサイズと圧縮
方式を選択する。ここで、メッシュサイズとは、各メッ
シュデータ（この実施形態では正方形とする）の一辺の
ピクセル数である。例えば、６４、１２８及び２５６ピ
クセルの３つのメッシュサイズの中からユーザ所望の一
つが選択できる。例えば、地図の基礎として用いられる
航空写真のように微細な変化を見逃せない画像では、６
４ピクセルのような比較的に小さいメッシュサイズを選
ぶとよく、逆に、イラストのような微細な変化の少ない
画像では、２５６ピクセルのように比較的に大きいメッ
シュサイズを選ぶとよい。風景や人物などの通常の写真
画像では、１２８ピクセルのような中程度のメッシュサ
イズを選ぶことができる。

【００８１】また、圧縮方式とは、作成されたたメッシ
ュデータをファイル化する際に行う圧縮方式のことであ
り、例えば、特定の不可逆圧縮方式と特定の可逆圧縮方
式の２通りの中からユーザ所望の一つを選ぶことができ
る。微細な変化を見逃せない画像では可逆圧縮方式がよ
いであろうし、通常の写真画像のような用途では不可逆
圧縮方式でも十分であろう。

【００８２】ステップＳ１０４でユーザから実行要求を
受けると、画像コンバータは、ステップＳ１０５で、元
画像データを読み込んでメッシュ作成処理を行う。メッ
シュ作成処理の具体的な流れは、後に図１２を参照して
説明する。メッシュ作成処理の実行によって、元画像デ
ータは、それぞれメッシュ分割された縮尺（ピクセルサ
イズ、深さ）の異なる複数枚の画像データにコンバート
され、コンバートされた画像データは、図４に示したよ
うな階層状のフォルダに分類格納された多数のメッシュ
データファイルの形式で、クライアントコンピュータ３
０内の所定のディレクトリに保存される。

【００８３】ステップＳ１０６で、画像コンバータは、
ユーザの指示により雛型ＨＴＭＬファイルを選択する。
ここで、雛型ＨＴＭＬファイルとは、図１に示したイメ
ージビューワ３２（例えば、米国マイクロソフト社のAc
tiveX技術を用いたプラグインプログラム）を実行する
ためのスクリプトや、その表示画面の背景の定義などが
記述されたＨＴＭＬファイルである。

【００８４】ステップＳ１０７で、ユーザからのプレビ
ューの要求を受けると、画像コンバータは、図１に示し
たＷＷＷブラウザ３１を起動してイメージビューワ３２
を実行させて、上述のコンバートされた画像データのプ
レビュー（予備的表示）を行わせる。すなわち、画像コ
ンバータは上述した雛型ＨＴＭＬファイルを読み込み、
その雛型ＨＴＭＬファイル内のイメージビューワ実行用
のスクリプトを、上述のコンバートされた画像データが
表示対象になるように書き換えた上で、その書き換え後
のＨＴＭＬファイルを所定ディレクトリに新たに保存
し、そして、ＷＷＷブラウザ３１を起動して、その保存
された書き換え後ＨＴＭＬファイルをＷＷＷブラウザ３
１に開かせる。ＷＷＷブラウザ３１は、そのＨＴＭＬフ
ァイルを開き、その中のスクリプトに従ってイメージビ
ューワ３２を実行して、上述の所定ディレクトリに保存
されているコンバートされた画像データを表示する。既
に説明したとおり、画像のスクロールや拡大縮小がスム
ーズに行える。

【００８５】ステップＳ１０８で、画像コンバータは、
ユーザの指示により、上述の書き換え後ＨＴＭＬファイ
ルとコンバートされた画像データのそれぞれのアップロ
ード先（例えば、図１に示したサーバ１０内の所定場所
を示すＵＲＬ）を指定する。ステップＳ１０９で、ユー
ザからアップロード実行を要求されると、画像コンバー
タは、上述の書き換え後ＨＴＭＬファイルとコンバート
された画像データとを、それぞれの指定されたアップロ
ード先に、インターネットなどのネットワークを通じて
アップロードする。

【００８６】図１２は、上述のステップＳ１０５のメッ
シュ作成処理の具体的手順を示す。

【００８７】図１２に示すように、ステップＳ２０１
で、画像コンバータは、選択された元画像データを読み
込み、その元画像データのピクセルサイズに基づいて、
深さ数ｎを決定する。ここで、深さ数ｎとは、その元画
像データをコンバートした結果出来上がる、ピクセルサ
イズの段階的に異なる複数枚のビットマップ画像データ
の枚数である。例えば、深さ数ｎが３であれば、コンバ
ート結果として、例えば、元画像データと同じピクセル
サイズと、それより１段階小さいピクセルサイズと、さ
らに１段階小さいピクセルサイズの、計３段階の深さ
（ピクセルサイズ）のビットマップ画像データが出来上
がることになる。深さ数ｎの決め方については、例え
ば、元画像データの縦横辺のうちの長辺のピクセル数、
或いは、ピクセル総数（つまり、縦ピクセル数×横ピク
セル数）などを、所定の複数の閾値と比較して、その比
較結果に応じて、例えば最小閾値未満ならｎ＝３、最小
閾値以上２番目閾値未満ならｎ＝４、２番目閾値以上な
らｎ＝５などというように決定することができる。

【００８８】ステップＳ２０２で、画像コンバータは、
決定された深さ数ｎに従って、深さ（ピクセル）の異な
るｎ枚の画像を、元画像データを用いて作成する。例え
ば、ｎ＝３の場合、第１の深さの画像データは元画像デ
ータであり、第２の深さの画像データは元画像データを
ピクセル数において１段階縮小することで作成し、第３
の深さの画像データは元画像データをピクセル数におい
て２段階縮小する、というような方法で３枚の画像デー
タを用意することができる。この場合、１段階分の縮小
倍率として例えばｋ＝０．８のような１未満の定数ｋを
用いて、この定数ｋの段階的なべき乗倍率で縮小するこ
ともできるし、或るいは、深さ毎に予め設定された最適
な縮小倍率を使用してもよい。

【００８９】ステップＳ２０３で、画像コンバータは、
深さ毎のｎ枚の画像データの各々のピクセルサイズと、
選択されたメッシュサイズとから、各画像データをメッ
シュ分割したときに出来るメッシュの個数ｍを計算す
る。そして、このメッシュ数ｍに基づいて、画像コンバ
ータは、メッシュデータを格納するためのフォルダの階
層構造や、各フォルダの名称や、各メッシュデータファ
イルをどのフォルダに入れるかなどを決定し、そのよう
な階層構造をもったフォルダ群をクライアントコンピュ
ータ３０内の所定ディレクトリに作成する。

【００９０】ステップ２０４で、画像コンバータは、深
さ毎のｎ枚の画像データの各々を、その画像データ毎に
計算されたメッシュ数ｍ個のメッシュデータに分割す
る。そして、画像コンバータは、ステップＳ２０５で、
分割された個々のメッシュデータを、選択された圧縮方
法で圧縮されたファイルにして、ステップ２０６で、そ
のメッシュデータファイルを上記階層構造のフォルダ群
中のしかるべきフォルダに保存する。ｎ枚の全ての画像
データについて上記の処理が行なわれて、コンバートが
完了する。

【００９１】以上、本発明の実施形態を説明した、これ
らの実施形態は本発明の説明のための例示にすぎず、本
発明の範囲を上記実施形態のみに限定する趣旨ではな
い。よって、本発明は、上記の実施形態以外の様々な形
態でも実施することが可能である。

【図面の簡単な説明】

【図１】本発明が適用可能な画像表示システムの一実
施形態の概略的な全体構成を示すブロック図。

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

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

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

【図５】イメージビューワ３２の機能的な構成を示すブ
ロック図。

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

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

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

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

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

【図１１】本発明の一実施形態にかかる画像コンバータ
が行う処理全体のフローチャート。

【図１２】本発明の一実施形態にかかる画像コンバータ
のメッシュ分割処理のフローチャート。

【符号の説明】

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

フロントページの続き (72)発明者田渕大介東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー13階ドリームテクノロジーズ株式会社内 (72)発明者中島一郎東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー13階ドリームテクノロジーズ株式会社内 (72)発明者日向野保夫東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー13階ドリームテクノロジーズ株式会社内 (72)発明者伊藤友紀東京都渋谷区恵比寿４丁目20番３号恵比寿ガーデンプレイスタワー13階ドリームテクノロジーズ株式会社内Ｆターム(参考） 2C032 HB03 HB31 HC24 HC32 5B050 AA08 BA07 BA10 BA17 CA07 CA08 EA03 EA12 EA19 FA02 FA09 FA19 GA08 5B057 CA12 CA17 CB12 CB16 CD05 CE08 CE09 CH12 5C076 AA17 AA21 AA22 AA36 BA04 BB42 CB05

Claims

【特許請求の範囲】

【請求項１】元画像データから、ピクセルサイズが段
階的に異なる複数枚の副画像データを作成する手段と、前記複数枚の副画像データの各々を、多数の小領域の断
片画像データに分割する手段と、前記複数枚の副画像データの全部についての前記多数の
断片画像データを出力する手段とを備えた画像コンバー
タ。
【請求項２】各副画像データについての前記多数の断
片画像データが、階層構造のフォルダに格納されている
請求項１記載の画像表示システム。
【請求項３】元画像データから、ピクセルサイズが段
階的に異なる複数枚の副画像データを作成するステップ
と、前記複数枚の副画像データの各々を、多数の小領域の断
片画像データに分割するステップと、前記複数枚の副画像データの全部についての前記多数の
断片画像データを出力するステップとを備えた画像コン
バート方法。
【請求項４】元画像データから、ピクセルサイズが段
階的に異なる複数枚の副画像データを作成するステップ
と、前記複数枚の副画像データの各々を、多数の小領域の断
片画像データに分割するステップと、前記複数枚の副画像データの全部についての前記多数の
断片画像データを出力するステップとを備えた画像コン
バート方法をコンピュータに行わせるためのコンピュー
タプログラム。
【請求項５】共通の対象画像をそれぞれ表した、ピク
セルサイズが段階的に異なる複数枚の副画像データを含
み、前記複数枚の副画像データの各々が、多数の小領域の断
片画像データに分割されている、画像データ構造。