JP3691405B2 - データ管理装置及び地図表示システム - Google Patents
データ管理装置及び地図表示システム Download PDFInfo
- Publication number
- JP3691405B2 JP3691405B2 JP2001128071A JP2001128071A JP3691405B2 JP 3691405 B2 JP3691405 B2 JP 3691405B2 JP 2001128071 A JP2001128071 A JP 2001128071A JP 2001128071 A JP2001128071 A JP 2001128071A JP 3691405 B2 JP3691405 B2 JP 3691405B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- map
- file
- cache
- mesh
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Instructional Devices (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明が属する技術分野】
本発明は、データ管理装置及び地図表示システムに関する。
【0002】
【従来の技術】
コンピュータシステムにおいて、CPU(Central Processing Unit)は、プログラムに基づいて、RAM(Random Access Memory)等のメモリに記憶されたデータを取り出し、所定の演算処理を行う。
【0003】
必要なデータのサイズがメモリサイズよりも小さい場合には、必要な全てのデータをメモリに記憶させて処理することが可能である。しかし、プログラムで扱うデータ量がメモリサイズを上回る場合には、必要な全てのデータを予めメモリに格納しておくことができない。
【0004】
そこで、HDD(Hard Disk Drive)等の大容量の外部記憶装置にデータを格納しておき、必要なデータをメモリに移し替えて処理することになる。しかし、外部記憶装置のデータ書き込み速度及び読出し速度は一般的に遅く、また、大量のデータの中から特定のデータを検索するのにも時間を要する。従って、外部記憶装置とメモリとの間で頻繁なデータ交換を行うと、プログラムの実行速度が低下する。
【0005】
このため、キャッシュシステムを採用し、いったんメモリが読み込んだデータをキャッシュメモリと呼ばれるメモリ領域に一時的に記憶させておく。これにより、キャッシュされたデータを再度使用する場合は、キャッシュメモリを検索して所望のデータを読み出すだけでよく、プログラムの実行速度を向上させることができる。キャッシュメモリを効率的に使用するために、ガーベージコレクタと呼ばれるメモリ解放プログラムによって、不要のデータはキャッシュメモリから削除される。
【0006】
キャッシュメモリに何を残し、何を削除するかは重要な問題である。キャッシュメモリ内を探して所望のデータを得られなかった場合(キャッシュミス)は、そのデータを求めて、大容量記憶装置内を検索しなければならない。また、不要となったデータをいつまでもキャッシュメモリ内に記憶しておくと、新たなデータを一時記憶するためのメモリ領域が不足する。
【0007】
このため、従来技術では、キャッシュメモリに記憶されたデータを管理するためにキャッシュ管理テーブルを用意している。この管理テーブルには、キャッシュメモリに記憶された各データ毎に、データ参照回数等に基づいた優先度が設定されている。キャッシュ管理テーブルを検索することにより、所望のデータを読み出すことができる。また、キャッシュ管理テーブルを参照して優先度の低いデータを削除することにより、ガーベージコレクションを行うことができる。
【0008】
【発明が解決しようとする課題】
上述のように、キャッシュメモリを用いることにより、データ読込みの度に大容量記憶装置にアクセスしてデータ検索を行う必要が無くなり、プログラムの処理速度を高めることができる。しかし、キャッシュメモリを利用するには、キャッシュ管理テーブルを作成し、テーブル内容の更新作業等を行う必要がある。また、不要なデータを削除するガーベージコレクタをバックグラウンドで実行させると、その分だけCPUの負担が重くなるため、全体としてのプログラム実行速度が低下する。
【0009】
このようなキャッシュメモリの管理がプログラムの実行速度に大きな影響を及ぼす場合としては、キャッシュメモリ内の既存データを利用しつつ新たなデータを随時要求されるプログラムを実行する場合が該当する。その典型的な一例として、地図表示システムを挙げることができる。
【0010】
地図表示システムでは、ユーザの操作に応じて、地図のスクロールや拡大又は縮小が頻繁に行われる。スクロールや拡大縮小を行う場合、(スクロールの幅や拡大率又は縮小率等によっても相違するが)現在の表示に使用されている地図データと、新たに読み込む必要のある地図データとが同時に又は連続的に使用されることがある。地図では、隣接する地理要素(例えば、各道路、各鉄道線路、各河川、各建物、各敷地、各地物名称、各地図記号、各アイコンなどの個々の地理的事物)が互いに関連しており、既に表示されたデータを再使用しながらスクロール等を行う場合が多いためである。また、地図表示システムでは、そのカバーする範囲や縮尺等によっても相違するが、大量のデータを使用する。従って、大量のデータ中から表示に必要なデータを速やかに検索し、不要なデータを削除してキャッシュメモリを効率的に使用することが重要となる。
【0011】
ところで、従来の地図表示システムでは、クライアントが地図サーバに地図データを要求する場合、所望の地図データを緯度経度等で特定し、これら緯度経度を文字列として地図サーバに渡すようになっている。地図サーバは、データリクエストを受信すると、緯度経度で特定された範囲のメッシュデータを新たに生成してクライアントに返信する。
【0012】
即ち、データリクエスト毎に、クライアントから地図サーバに対して、数十〜百文字程度の情報送信を必要する。従って、例えば、インターネットのようなデータ帯域の狭い通信ネットワークを利用して地図データの送受信を行う場合は、データのリクエストを行うだけでもデータ帯域の負荷が大きくなってしまい、スムーズに地図データを受信するのが難しい。また、地図サーバ側では、緯度経度の文字列を解釈して指定された範囲のメッシュデータを新たに生成しているため、応答性が低く、スムーズな地図表示を一層困難なものとしている。
【0013】
本発明は、上述した種々の問題に鑑みてなされたもので、その目的は、データ処理を高速で行うことができるようにしたデータ管理装置及び地図表示システムを提供することにある。本発明の他の目的は、高速なデータ処理によって、連続的かつ円滑な地図操作を可能とした地図表示システムを提供することにある。本発明の更なる目的は、後述する実施の形態から明らかになるであろう。
【0014】
【課題を解決するための手段】
上記課題を解決すべく、本発明に係るデータ管理装置は、n次元の第1の記憶空間に多数のデータを保持する第1の記憶装置から第1の記憶空間よりも小さい第2の記憶空間を有する第2の記憶装置に所定のデータを移して管理するようになっており、格納位置指定手段、データ取得手段及びデータ削除手段を備えて構成されている。格納位置指定手段は、第1の記憶空間に保持された多数のデータのそれぞれについて、第2の記憶空間における指定格納位置を予め設定する。データ取得手段は、第1の記憶空間から所定のデータを検索し、検索されたデータを該データに設定された指定格納位置に格納させる。データ削除手段は、所定のデータが指定格納位置に格納されていない場合には、該指定格納位置に既に格納されているデータを削除する。
【0015】
第1の記憶装置には、例えば、二次元配列や三次元配列のようなn次元の第1の記憶空間が形成され、この第1の記憶空間にデータが格納されている。第2の記憶装置には、第1の記憶空間よりも小さいn次元の第2の記憶空間が形成されている。第1の記憶空間に格納されている各データには、第2の記憶空間における格納位置が予め指定格納位置としてそれぞれ設定されている。第1の記憶空間から検索され読み出されたデータは、指定格納位置で第2の記憶空間内に記憶される。従って、データを検索するときは、第2の記憶空間の全てを検索する必要はなく、所望するデータに割り当てられた指定格納位置を直接的に検索すれば足りる。もっとも、第2の記憶空間は第1の記憶空間よりも小さく設定されているので、一つの指定格納位置に複数のデータが割り当てられることになる。各指定格納位置に幾つのデータが割り当てられるかは、各記憶空間のサイズによって定まる。単純には、(第1の記憶空間のサイズ/第2の記憶空間のサイズ)個のデータが一つの指定格納位置に割り当てられる。従って、指定格納位置のデータを検索したときに、所望のデータがその指定格納位置に格納されておらず、その指定格納位置を共有する他のデータが格納されている場合がある。この場合、データ削除手段は、指定格納位置に既に格納されているデータを削除し、そのメモリ領域を解放する。
【0016】
このように、第1の記憶空間から第2の記憶空間にデータを移す場合に、予め設定した指定格納位置に格納させるため(データキャッシュ)、検索が容易となる。そして、所望のデータが指定格納位置に格納されていない場合は、該指定格納位置に格納されている不要なデータを削除するため(ガーベージコレクション)、第2の記憶空間を効率的に利用することができる。
【0017】
ここで、第1の記憶空間の各座標値を第2の記憶空間の各座標値に予め割り当てることにより、各指定格納位置をそれぞれ設定することができる。具体的には、第2の記憶空間の各座標値に第1の記憶空間の各座標値を均等に割当てるのが好ましい。
【0018】
データの種別や利用頻度等のデータに依存する性質に基づいて指定格納位置を決定することも可能であるが、格納位置の割当構造が複雑化する。そこで、第1,第2の記憶空間の各座標値同士を対応付けることにより、データの性質等に依存することなく指定格納位置を決定する。
【0019】
第2の記憶空間の各座標値に第1の記憶空間の各座標値を均等に割り付ける方法としては、例えば、第1の記憶空間の各座標値に連続した整数値を付与しておき、これら各座標値を第2の記憶空間のサイズでそれぞれ除算して余りを求め、この余りの値で示される第2の記憶空間内の座標値を指定格納位置として設定すればよい。
【0020】
具体例を挙げる。説明の便宜のために、第1の記憶空間を10×10の二次元配列、第2の記憶空間を3×3の二次元配列とする。第1の記憶空間は、X軸及びY軸にそれぞれ0〜9の連続した整数値が、第2の記憶空間のx軸及びy軸にはそれぞれ0〜2の連続した整数値が与えられている。第1の記憶空間の座標値(X,Y)を第2の記憶空間のサイズ(x,y軸方向に共に3である)で割って余りを求める。余りの取り得る値は、0,1,2のいずれかとなる。例えば、第1の記憶空間の座標値(0,0)に格納されているデータは、第2の記憶空間において座標値(0,0)に格納され、第1の記憶空間の座標値(7,9)に格納されているデータは、第2の記憶空間において座標値(1,0)に格納されることになる。つまり、第1の記憶空間の座標値(X,Y)を第2の記憶空間のサイズ(Cx,Cy)で除算したときの余りの値((X mod Cx),(Y mod Cy))が指定格納位置となる。従って、第2の記憶空間からデータを読み出す場合は、所望のデータが第1の記憶空間で有する座標値さえわかれば足りる。データの元々の格納位置に応じて第2の記憶空間内での格納場所が予め定まっているためである。
【0021】
そこで、第1の記憶空間に、n次元空間で連続的に使用可能なデータを、該n次元空間における位置に応じて定まる整数値の座標値をもって格納しておくことにより、より効率的により簡単にデータをキャッシュし、検索することができるようになる。
【0022】
ここで、「n次元空間で連続的に使用可能なデータ」とは、例えば、n次元空間に互いに関連性をもって展開されるデータであって、隣接するデータが連続的に使用されうるものとして定義することができ、典型的一例としては、地図データが該当する。単にシーケンシャルに読み出されるデータとは異なる点に留意するべきである。
【0023】
n次元空間における位置に基づいて設定された座標値で所望のデータを特定することにより、該データの指定格納位置を直ちに求めて、該データが第2の記憶空間に格納されているか否かを調べることができる。
【0024】
本発明に係る地図表示システムでは、多数の断片地図データに細分された全体地図データを有する地図サーバと、所望の断片地図データを地図サーバから通信ネットワークを介して受信し、受信した断片地図データから地図画像を描画して表示させるクライアントとを備えている。さらに、本地図表示システムでは、クライアントに、地図サーバから受信した断片地図データを地図サーバの記憶空間よりも小さい記憶空間を有するキャッシュメモリに保持するためのキャッシュデータ管理装置を設けている。
【0025】
そして、キャッシュデータ管理装置は、座標割当手段、データ取得手段及びデータ削除手段を備えている。座標割当手段は、地図サーバの記憶空間の各座標値をキャッシュメモリの記憶空間における座標値に割り当てる。データ取得手段は、地図サーバから所定のデータを検索し、検索されたデータを該データに割り当てられた座標値でキャッシュメモリに格納させる。データ削除手段は、所定のデータが割り当てられた座標値でキャッシュメモリに格納されていない場合には、該座標値に既に格納されているデータをキャッシュメモリから削除する。
【0026】
これにより、クライアントは、キャッシュメモリに記憶されたデータを速やかに読み出して地図を描画し表示させることができる。即ち、クライアントは、表示に必要な範囲のデータを地図サーバに要求し、地図サーバから受信した地図データを描画して表示する。地図サーバでは描画を行わないので、サーバ側の処理負荷を軽くすることができる。従って、地図サーバは、多数のクライアントから地図データの要求があった場合でも、必要な地図データを次々に各クライアントに送信することができる。
【0027】
地図サーバから受信された地図データは、所定の座標値でキャッシュメモリ内の記憶空間に記憶される。スクロール操作等によって表示範囲が変更された場合は、キャッシュメモリの全体を検索したり、別に用意したキャッシュ管理テーブルを参照したりすることなく、キャッシュメモリの所定位置を直接検索することにより、再利用可能な地図データを直ちに読み出すことができる。表示範囲の外に出たために不要となった地図データは、データ削除手段により削除され、その分だけキャッシュメモリのメモリ領域が解放される。必要なデータは座標値に基づいた所定位置でキャッシュメモリに格納されているため、表示に必要なデータがキャッシュされているか否かを直ちに知ることができ、不要なデータを速やかに削除することができる。キャッシュ管理テーブルを生成し更新等する手間をかけずに、効率的にキャッシュメモリを使用することができる。
【0028】
ここで、断片地図データとは、例えば、地図画像に含まれる個々の地理要素(例えば、各道路、各鉄道線路、各河川、各建物、各敷地、各地物名称、各地図記号、各アイコンなどの個々の地理的事物)毎のデータ(例えば、各地理的事物を表したポリゴンデータ、線データ、文字データ、ビットマップイメージデータなど)である。あるいは、断片地図データは、例えば、全体地図データがカバーする全体地域を緯度経度などで地域的に細分した小地域(メッシュ)の地図データであってもよい。
【0029】
一方、本発明に係るデータ管理装置は、データを蓄積するサーバと、サーバからデータを取得するクライアントとを備える。いわゆるクライアントサーバシステムである。サーバは、各ディレクトリ及び各ファイルの名称が最小文字数で表現される階層化ファイルシステムを備えている。各ファイルには、ファイル名以外の識別情報が予め付与されている。クライアントは、所望するデータのファイルに付与された識別情報に基づいてファイルシステムにおけるパス名に変換する変換手段と、変換手段により得られたパス名によってサーバに所望のデータ送信を要求する要求手段とを備えている。
【0030】
従って、クライアントからサーバへのデータリクエストは、最小文字の名称で構成されたパス名となり、この最も単純な形式のパス名によって階層化ファイルシステムに記憶された任意のファイルを一意に特定する。具体的には、例えば、HTTP(Hyper Text Transfer Protocol)を用いてデータ取得を要求する場合、クライアントは、「http://サーバ名/a/b/c/8/5.dat」のようなHTTPリクエストをサーバに送信する。このリクエストを受信したサーバは、パス名によってファイルを特定し、このファイルをクライアントに返信する。サーバは、パス名で特定されたファイルを単純に返信するだけである。
【0031】
ここで、サーバ側のファイルシステムでは、ルートディレクトリ名、ルートディレクトリ直下のサブディレクトリ名及びファイル名、サブディレクトリ内のファイル名のそれぞれについて、最小文字数の名称が設定される。「最小文字数」とは、OS(Operating System)が使用を許可している文字(数字、記号を含む)であって、最小単位の文字であることを意味する。例えば、1バイトで表現されるアルファベットや数字を最小文字数の名称として採用できる。「識別情報」とは、使用目的を同じくするひとまとまりのファイル群において、一のファイル(データ)を他のファイル(データ)から区別するための情報である。ファイル群全体として、各ファイルには固有の識別情報がそれぞれ付与されている。
【0032】
使用目的を同じくするひとまとまりのファイル群としては、例えば、全体地図を構成する断片地図データ群を挙げることができる。
【0033】
即ち、地図サーバは、各ディレクトリ名が最小文字数で構成される階層化ファイルシステムに、それぞれ最小文字数のファイル名が付与された多数の断片地図データを格納しており、クライアントは、地図空間における位置に基づいて各断片地図データにそれぞれ付与された識別情報を最小文字数で構成される階層化ファイルシステムにおけるパス名に変換することにより、地図サーバに所望のデータを要求することができる。これにより、地図サーバは要求された断片地図データを速やかに送信することができ、より高速な地図表示が可能となる。
【0034】
また、上述したキャッシュデータ管理装置及び最小文字数の階層化ファイルシステム等を結合させて地図表示システムを構成することもできる。
【0035】
これにより、より高速にデータの取得、読出し等を行うことができ、連続的で円滑な地図表示を効率よく行うことができる。
【0036】
【発明の実施の形態】
図1〜図10に基づいて、本発明の実施の形態を地図表示システムに適用した場合を例に挙げて説明する。
【0037】
図1は、本実施の形態に係る地図表示システムの全体構成を概略的に示す構成説明図である。
【0038】
本地図表示システムは、地図提供サービスを行う地図サーバ10と、ユーザにより利用される複数のクライアントコンピュータ(一台のみ図示)30とにより大略構成されており、地図サーバ10と各クライアントコンピュータ30とは、例えば、インターネット20のような通信ネットワークを介して通信可能に接続されている。
【0039】
地図サーバ10は、広範な地域の地図データを格納した地図データベース11を有している。クライアントコンピュータ30は、地図サーバ10にアクセスするためのクライアントプログラム31を有する。クライアントプログラム31には、地図サーバ10に対して地図データの送信を要求し、また、地図サーバ10から受信した地図データを描画して表示するための地図表示プログラム32が、例えば、プラグインソフトウエアのような形で付属している。また、クライアントコンピュータ30は、例えば、液晶ディスプレイ等の表示装置33やマウスのような操作装置34も備えている。さらに、クライアントコンピュータ30は、マイクロコンピュータを利用したコンピュータシステムとして構成されており、CPU等の演算処理部やメモリ等の記憶部を有している。そして、記憶部には、図2と共に後述するように、地図サーバ10から取得した地図データを一時的に記憶するためのキャッシュ領域35が形成されている。
【0040】
(必ずしもそうである必要はないが、)本実施の形態において、地図サーバ10はWWW(World-Wide Web)サーバであり、クライアントコンピュータ30内のクライアントプログラム31はWWWブラウザである。地図サーバ10とクライアントプログラム31とは、HTTPプロトコルによって地図データの要求(HTTPリクエスト)や地図データの受信(HTTPレスポンス)等を行う。
【0041】
地図データベース11は、例えば、HDD装置等の大容量記憶装置を利用して実現されるものである。地図データベース11には、例えば、ポリゴン、線、文字等を描画するためのベクトルデータを主体とする地図データが階層化されて記憶されている。ポリゴンデータは、例えば、建物や敷地等を描画するためのものである。線データは、例えば、道路や鉄道等を描画するためのものである。文字データは、例えば、地名や建物名称等を描画するための文字コードとアイコンや地図記号等のシンボルマークを描画するためのデータとを含んでいる。なお、ポリゴン等は一例であって、これらに限定されない。図5,図6と共に後述するように、ポリゴン、線、文字の各地理要素データは、メッシュサイズの異なるレイヤを階層化して構成されたデータベース内にそれぞれ登録されている。
【0042】
地図データベース11が保持する全体地図は、経度及び緯度の方法に細分された多数のメッシュにより分割されている。各メッシュ毎のデータがそれぞれ一つのファイルを構成しており、各データには、全体地図上での位置座標を特定する識別情報と表現可能なメッシュ番号がそれぞれ割り当てられている。
【0043】
地図サーバ10は、ベクトルデータの形式で地図データをクライアントコンピュータ30に送信する。地図表示プログラム32の描画エンジンは、ベクトルデータを解釈してビットマップイメージデータを生成する。これにより、表示装置33にはユーザが所望する範囲の地図が表示される。即ち、地図サーバ10は、クライアントから要求されたデータを地図データベース11から取得してクライアントへ返信するだけであり、描画処理は行わない。従って、地図サーバ10の処理負担は小さくなる。これにより、地図サーバ10は、多数のクライアントから要求を受けているときでも、各クライアントに対して即座に要求された地図データを返信することができる。
【0044】
次に、図2に基づき、地図表示プログラム32の機能的構成を説明する。
【0045】
地図表示プログラム32は、表示部320とダウンローダ323を有する。表示部320は、ユーザによる操作装置34を用いた地図のスクロールや拡大縮小の操作に応答して、地図の表示すべき範囲を決定する。表示部320は、表示範囲に必要なメッシュのファイル名(メッシュ番号、図中では「ファイルID」と表示)を選定し、そのメッシュのファイルをダウンローダ323に要求する。また、表示部320は、ダウンローダ323から取得したメッシュのファイルに含まれるベクトルデータに基づいて地図画像を描画する。ダウンローダ323は、表示部320からのファイル取得要求を受け付けると、その要求されたファイルの送信を地図サーバ10に要求し、地図サーバ10から必要なファイルをダウンロードする。
【0046】
表示部320は、キャッシュ管理部321を介してメモリ・キャッシュ322にアクセスする。メモリ・キャッシュ322には、ダウンローダ323を介して過去に取得したメッシュの地図データが所定の位置に記憶されている。
【0047】
ダウンローダ323は、ダウンロード対象のファイルのファイル名(地図サーバ10に格納されたファイルへのパス名又はファイルID)をリストアップしたダウンロード・リクエスト・リスト327(表示部320は、随時このリスト内のファイル名を消去する)と、新たなファイルがダウンロードされたか否かを表示部320に知らせるためのダウンロード・フラグ328と、各ファイルをダウンロードするときの各HTTPセッションをそれぞれ行う複数のHTTPセッション・スレッド326A〜326D(4個のスレッドを図示するが、その個数は可変である)とを備えている。
【0048】
また、ダウンローダ323は、キャッシュ管理部324を介して、HDD装置等の大容量不揮発性記憶装置内に形成されたディスク・キャッシュ325にアクセスすることができる。ディスク・キャッシュ325には、地図サーバ10からダウンロードした地図データが所定の位置に格納されている。
【0049】
地図表示プログラム32は、ユーザの操作に応じて表示すべき範囲を確定し、この表示範囲に含まれる(一部が含まれる場合も含む)メッシュの番号を割り出して、必要なメッシュのデータを地図サーバ10に要求する。地図表示プログラム32は、表示範囲に含まれる全レベルの全メッシュについて地図データを要求する。一つのHTTPセッション・スレッドにより一つのメッシュのデータが地図サーバ10からクライアントコンピュータ30にダウンロードされる。
【0050】
このとき、例えば、小縮尺(例えば全国地図)→中縮尺→大縮尺(例えば市街地図)のように、縮尺の小さなデータ(高レベルにあるメッシュのデータ)から縮尺の大きなデータ(低レベルにあるメッシュのデータ)を地図サーバ10に要求することにより、最適縮尺の地図を徐々に表示させていくことができる(プログレッシブ表示)。また、建物等を表すポリゴンデータ、道路等を表す線データ、地名等を表す文字データについても、取得した順に表示させることにより、ユーザにストレスを与えることなく、滑らかに連続的に地図を表示させることができる。なお、ユーザ操作による表示範囲の変化時に、地図表示プログラム32は、全ての地図データを地図サーバ10に要求するわけではない。既に取得した地図データは、キャッシュ領域35(メモリ・キャッシュ322及びディスク・キャッシュ325)に記憶されているためである。
【0051】
ここで、注意すべきは、地図情報の有する性質、特徴である。地図情報は、単に氏名等を所定の順序で並べただけの名簿等とは異なり、地理的実体(建物、道路、山河等)の属性と位置を対応付けたものである。即ち、地図サーバ10が管理する地図情報は、実世界を抽象化した空間データベースであり、二次元または三次元の空間で連続的に使用されうるデータ群である。このため、例えば、ある地点を中心に周辺の地域を参照するような使われ方が多く、あるデータが単独で離散的に使用される可能性は低い。従って、表示範囲が変化する場合も、キャッシュ領域35にキャッシュされている地図データの一部を再利用できる可能性が高い。このため、キャッシュ領域35の効率的な管理は、地図表示システムにとって重要となる。
【0052】
図3は、地図データベース11の構造を示す説明図である。地図データベース11は、図3に示すような階層化されたファイル構造を有し、各ディレクトリ及び各ファイルの名称は、OSが許容する最小文字数で構成されている。即ち、ルートディレクトリ、サブディレクトリ、ファイルの各名称は、英数字一文字から構成されている。このディレクトリ構造は、メッシュ番号に対応して形成されている。また、一文字のファイル名を与えられた地図データ中にもメッシュ番号が含まれている。
【0053】
即ち、メッシュ番号に基づく所定の規則で各ファイルへのパスが設定されているため、地図表示プログラム32は、必要な地図データのメッシュ番号に基づいて所定のファイルのパスを算出し、地図サーバ10にデータ送信を要求することができる。地図サーバ10は、指定されたパスのファイルを地図データベース11から読み出してクライアント側に返信するだけである。メッシュ番号をパスに変換する処理は地図表示プログラム32側で担当しており、地図サーバ10側ではHTTPリクエストに応答する機能以外に何らの特別な機能を必要としない。ディレクトリ名及びファイル名を最小文字数としての一文字で構成するため、地図表示プログラム32から地図サーバ10にデータをリクエストするときのデータ量を低減することができる。また、文字数を制限する結果、階層が分かれるため、一つのディレクトリ内に含まれるサブディレクトリ及びファイルの数を制限することができ、HTTPリクエストに対する応答性を高めることができる。
【0054】
次に、図4はキャッシュ領域35のデータ管理方法を示す説明図である。
【0055】
上述した通り、地図データベース11は、最小文字数の名称を有する階層化ファイルシステムにより構成されているが、保持する地図データはそれぞれ固有のメッシュ番号を有しており、このメッシュ番号は地図上の位置座標に基づく値である。地図データベース11から取得された地図データは、クライアントコンピュータ30のキャッシュ領域35に記憶され必要に応じて再使用される。
【0056】
地図表示プログラム32は、上述した通り、必要な地図データのメッシュ番号から地図データベース11へのパスを生成する。地図サーバ10は、要求された地図データをクライアントコンピュータ30に返信する。メッシュ番号(Xi,Yj)を有するデータMDがクライアント側にダウンロードされた場合、このメッシュのデータMDは、キャッシュ領域の所定位置に格納される。キャッシュ領域の配列サイズをCnx,Cnyとすると、式1に示すように、メッシュデータMDのメッシュ番号を各座標軸毎にキャッシュ配列サイズでそれぞれ除算したときの余りが、キャッシュ領域中での格納位置となる。
【0057】
キャッシュ領域の格納位置=((Xi mod Cnx),(Yj mod Cny))・・・(式1)
即ち、メッシュのデータがキャッシュ領域で格納される位置は、そのメッシュ番号によって一意に定まっている。従って、所望するメッシュのデータをキャッシュ領域中で検索する場合は、該データのメッシュ番号から上記式1に基づいて指定格納位置を算出し、算出された位置に格納されているデータを直接調べれば足りる。つまり、キャッシュデータを検索するときは、メッシュ番号から定まる格納位置のみを検索すればよく、キャッシュ領域の全体を検索したり、あるいはデータ検索のためにキャッシュデータ管理テーブル等を特別に用意したりする必要はない。
【0058】
一方、所望のメッシュのデータが指定された格納位置に存在しない場合は、この不要となったデータを削除してメモリ領域を解放する。そして、地図データベース11から改めて取得したデータを、その指定格納位置に格納させる。つまり、ユーザが地図をスクロール操作すると、表示範囲がユーザの望む方向に変化していき、この変化に連れて、古いデータの削除(ガーベージコレクション)と新たなデータのキャッシュとが同時に行われることになる。なお、地図ベース11とディスク・キャッシュ325との関係に止まらず、ディスク・キャッシュ325とメモリ・キャッシュ322との間でも前記同様に、メッシュ番号から一意に定まる所定の位置にデータをキャッシュすることができる。
【0059】
次に、図5及び図6に基づいて、地図データベース11に地図データを登録する方法を説明する。
【0060】
まず、図5は、それぞれメッシュサイズの異なる複数のレベルを階層化した概念図である。本実施の形態では、メッシュサイズを違えた複数のレベルという新たな概念を導入している。各レベル内のメッシュサイズはそれぞれ同一であり不変である。なお、図5中では、レベルL0〜レベルLnまで4つのレベルを図示しているが、これは説明の便宜上一部のみを示したものであり、実際には、より多くのレベルを階層化する。
【0061】
最下位のレベルL0から最上位のレベルLnに上がるにつれて、メッシュサイズが段階的に大きくなるように設定されている。最上位レベルLnを構成するメッシュには最大のメッシュサイズが設定される。最大のメッシュサイズ(Hn×Wn)は、地図データベース11に登録される最大のオブジェクトを包含可能なサイズとして規定される。即ち、地図データベース11が対象とする全体地図で使用される最大のオブジェクト(例えば、日本地図なら列島全体のポリゴンデータ、市街地図の場合はその市が属する県の形状のポリゴンデータ、地名等)を包含可能なメッシュサイズである。図6中では、最上位レベルLnを単一のメッシュで構成する場合を例示したが、これは説明の便宜のためである。
【0062】
図6は、メッシュサイズの異なるレベルにオブジェクトを格納する様子を示す説明図である。図6(a)に示すポリゴンのオブジェクトを地図データベース11に格納するときは、まず、図6(b)に示すように、オブジェクトに外接する外接区矩形(バウンディングボックス)を算出する。次に、図6(c)に示すように、オブジェクトの外接矩形を収容可能な最小サイズのメッシュがどのレベルに存在するかを判定する。具体的には、最下位のレベルL0からメッシュサイズを調べていき、メッシュサイズが外接矩形よりも小さい場合は、さらに上位レベルのメッシュサイズを調べる。図6中では、レベルL3のメッシュサイズML3がオブジェクトの外接矩形を収容する最小サイズとして検出されている。なお、最上位レベルLnのメッシュサイズは最大のオブジェクトを収容可能に設定されているため、どのようなオブジェクトであっても最上位レベルLnのメッシュで必ず収容可能である。
【0063】
レベルが決定した後は、そのレベルのどのメッシュにオブジェクトを登録するか決定しなければならない。地図データである以上、オブジェクトの表示位置は、そのオブジェクトが象徴している地理的実体の位置に基づいて予め決定されている。図6(d)に示すように、オブジェクトが4つのメッシュML3(1)〜ML3(4)にまたがって存在する場合、いずれのメッシュに格納するかが問題となる。従来の地図表示システムでは、本来一つのオブジェクトを各メッシュ毎に分割してそれぞれ格納するようになっているが、これでは本来ひとまとまりのデータがばらばらとなってデータ量が増大し、データ処理の手間もかかる。
【0064】
そこで、本実施の形態では、ひとまとまりのオブジェクトを分割することなくそのままの形で格納することにしている。このため、本実施の形態では、オブジェクトに外接する矩形の左上隅の座標Pが位置するメッシュML3(1)を当該オブジェクトの格納先として決定する。もちろん、他の選択も可能である。例えば、オブジェクトの重心が位置するメッシュを格納先メッシュとして選択することもできるし、または、外接矩形の座標ではなく、オブジェクトそのものの左端や右端等が位置するメッシュを格納先として選択することもできる。あるいは、外接矩形の右上隅、左下隅等の他の座標を基準にすることも可能である。
【0065】
しかし、外接矩形の座標を格納先選択の基準とすることで格納先選択処理が容易となる。また、外接矩形の左上隅Pを基準とすることにより、オブジェクトが文字データの場合に、利便性が増す。表示画面に文字の一部しか表示されない場合、文字の先頭部分(左側)を表示する方が、文字の終わり部分(右側)を表示するよりもユーザにとって便利だからである。具体的には、例えば「***ビルディング」という文字の一部が表示される場合に、「***ビル」と表示する方が「ルディング」と表示されるよりも分かり易い。左下隅ではなく左上隅Pを基準とするため、縦書き文字の場合も文字列の先頭部分を優先して表示させることができる。横書きの場合に左から右に読み、縦書きの場合に上から下に読むという言葉の特性に基づいて、オブジェクトの格納先を決定しているため、右から左に読み流す言葉で地図を表示する場合は、右上隅の座標を格納先選択の基準として採用してもよい。
【0066】
なお、「外接図形」として外接矩形を用いる場合を例に挙げたが、本発明はこれに限定されない。円形や三角形等の他の外接図形を用いることもできる。また、三次元オブジェクトを管理する場合は、外接図形として直方体、球体等を採用することもできる。但し、データ登録の利便や効率を考慮すると、矩形や直方体を用いるのがより好ましいと言える。
【0067】
次に、図7〜図10に基づいて本実施の形態の作用を説明する。なお、図に示すフローチャートは、処理の要部の流れを概略的に示すもので、実際のプログラムとは異なる。また、ステップを「S」と略記する。
【0068】
まず、図7は、表示部320の動作の流れを示す。
【0069】
ユーザが地図のスクロール又は拡大縮小等の地図の表示範囲を変化させる操作を行うと(S1)、表示部320はこれに応答して、次の動作を行う。即ち、ダウンロード・リクエスト・リスト327に記載されている全てのファイル名を消去し(S3)、ダウンロード・フラグ328をリセットし(S4)、そして、変化後の新しい表示範囲を決定して、その表示範囲に必要なメッシュのファイル名(メッシュ番号)を決定する(S5)。なお、図10と共に後述するように、表示範囲に含まれる全てのメッシュと該メッシュ群の左横及び左上に隣接するメッシュ群とが、必要なメッシュとして決定される。
【0070】
S5では、表示部320は、拡大縮小操作で決まる表示倍率に基づいて、その表示範囲に表示すべき地図の縮尺として最適な縮尺を(例えば、表示倍率が大きければ大縮尺、中程度なら中縮尺、小さければ小縮尺というように)決定し、その最適縮尺の地図について、新しい表示範囲に必要なファイル名を決定する(ここで決定したの最適縮尺のファイルを、以下「必要ファイル」という)。それに加え、この最適縮尺の必要ファイルが直ちに入手できなかったときの一時的な代替表示(つまり、前述したプログレッシブ表示を行う)ために、最適縮尺よりも小さい(つまり、分母がより大きい)各縮尺の地図についても、新しい表示範囲と重なるメッシュのファイル名を決定する(この代替表示のためのより小縮尺の地図のファイルを、以下、「代替ファイル」という)。
【0071】
次に、表示部320は、新しい表示範囲について、ポリゴンレイヤ、線レイヤ及び文字レイヤの全てが表示されたか否かを判定する(S6)。表示未完了のオブジェクト(データ)がある場合は、そのデータのファイルがメモリ・キャッシュ322に格納されているか否かを判定する(S7)。メモリ・キャッシュ322に必要ファイルまたは代替ファイルが残っている場合は、そのファイルを読み出して描画し、表示する(S8)。上述した通り、各キャッシュファイルは、メッシュ番号(ファイルID)に基づいてメモリ・キャッシュ322における格納位置が定められているため、指定された格納位置のファイルに直接アクセスして必要なファイルであるか否かを検査することができる。なお、キャッシュデータの管理処理については、図9と共に詳述する。
【0072】
メモリ・キャッシュ322に必要ファイルまたは代替ファイルが存在しない場合は(S7:NO,S9:YES)、見つからなかった必要ファイル及び該必要ファイルのための代替ファイルであってメモリ・キャッシュ322から見つからなかったもの(以下、「不足ファイル」と総称する)を、ダウンローダ323に要求する(S10)。後述のように、ダウンローダ323は、表示部320から不足ファイルの要求を受けると、要求された順番で(まず必要ファイル、それが見つからなければ、段階的により小縮尺の代替ファイルの順で)、各不足ファイルをディスク・キャッシュ325から検索する。不足ファイルが発見された場合、ダウンローダ323は、ディスク・キャッシュ325内のファイルへのパスを表示部320に返し、見つからない場合はファイル無しと回答する。表示部320は、ダウンローダ323からファイルへのパスを受けた場合には(S11:YES)、そのファイルをディスク・キャッシュ325から読込んでメモリ・キャッシュ322に保存し(S12)、そのファイルのベクトルデータから地図画像を描画して、ディスプレイ画面の対応する領域に表示する(S13)。
【0073】
一方、不足ファイルがディスク・キャッシュ325にも存在しない場合は(S11:NO)、不足ファイルの有無を再度判定し(S14)、不足ファイルがある場合にはS1に戻って表示範囲に変更が生じたか否かを判定する。表示範囲に変化がない場合は、ダウンローダ323によってダウンロードフラグがセットされるまで待機する(S2)。後述のように、ダウンローダ323は、あるファイルについてファイル無しという回答を返した場合には、そのファイルを地図サーバ10からダウンロードする作業に入り、そのファイルのダウンロードが終わると、そのファイルをディスク・キャッシュ325に格納して、ダウンロード・フラグ328を立てる。ダウンロード・フラグ328が立った場合(S2:YES)、表示部320は、表示範囲が変化したときに行ったと同様の処理を再び繰り返す。即ち、ダウンロード・リクエスト・リスト327内の全てのファイル名を消去し(S3)、ダウンロード・フラグ328をリセットし(S4)、表示範囲を計算し直して、表示範囲に必要なメッシュのファイル(メッシュ番号)を決定し(S5)、ファイルを取得して地図画像を描画して表示するためのS9以下の処理を繰り返す。これにより、表示部320は、既に描画して表示済みであったメッシュについては、再び同じ地図画像を描画して表示し直すことになり、また、ファイルがダウンロードされたメッシュについては、そのダウンロードされたファイルをディスク・キャッシュ325から読み込み、地図画像を描画してそのメッシュの領域に表示することになる。
【0074】
不足ファイルが1つダウンロードされる度に、表示部320は、S3からの処理を繰り返すので、画面上の表示領域は1メッシュずつ順次完成に近づく。表示領域全域の地図画像が完成すると(S6:YES)、表示部320はS1に戻り、ユーザによって表示範囲が変更されるの待ち、変更されればS3以下の処理を再び繰り返す。
【0075】
また、画面上の表示領域全域の地図画像が完成する前に、ユーザによって表示範囲が変更された場合(S15:YES)にも、表示部320は、S3以下の処理を再び繰り返す。
【0076】
次に、図8は、ダウンローダ323の動作の流れを示す。
【0077】
ダウンローダ323は、表示部320からファイルの要求を受けると(S21)、要求されたファイルをディスク・キャッシュ325から探す(S22)。ディスク・キャッシュ325から目的のファイルが見つかった場合(S22:YES)、ダウンローダ323は、そのファイルのディスク・キャッシュ325内でのパスを表示部320に知らせる(S23)。表示部320から要求された全てのファイルのパスを表示部320に通知できた場合(S24:NO)、ダウンローダ323は、S21へ戻り、表示部320から再びファイルの要求が来るのを待つ。
【0078】
一方、表示部320から要求されたファイル中、ディスク・キャッシュ325内に格納されていないファイルがあった場合は(S24:YES)、ダウンローダ323は、その見つからなかったファイルについてファイル無しの旨を表示部320へ通知する(S25)と共に、その見つからなかったファイルのファイルIDをダウンロード・リクエスト・リスト327に書く(S26)。図7と共に上述した通り、表示部320によって、ダウンロード・リクエスト・リスト327からは過去に書いてあったファイル名が全て消去されているので、このときに見つからなかったファイルのIDだけが書かれることになる。
【0079】
次に、ダウンロード・リクエスト・リスト327にファイルIDが記述されている場合(S27:YES)、ダウンローダ323は、ダウンロード・リクエスト・リスト327に書かれているファイルを取得すべく、リストの先頭から順に、アイドル状態にあるHTTPセッション・スレッド326A〜326Dへ割り当てていく(S28)。HTTPセッション・スレッド326A〜3246は、ファイル名を割り当てられると、直ちに地図サーバ10との間でHTTPセッションを実行し、それぞれに割り当てられたファイルを地図サーバ10からダウンロードする。
【0080】
個々のファイルのダウンロードが完了する都度(S29:YES)、ダウンローダ323は、そのファイルの取得要求をダウンロード・リクエスト・リスト327から消去し(S30)、ダウンロード済みファイルをディスク・キャッシュ325に保存し(S31)、ダウンロード・フラグ328を立てる(S32)。その後、ダウンローダ323は、S21へ戻って、表示部320から再びファイル要求が来るのを待つ。ダウンロード・フラグ328を立てると、既に説明したように、表示部320が再びファイル要求を発し、ダウンロードされたファイルをディスク・キャッシュ325から読み出してその地図画像を描画し表示する。なお、ダウンローダ323により取得されたファイルは、メッシュ番号に基づく所定の格納位置でディスク・キャッシュ325に記憶される。
【0081】
以上の表示部320とダウンローダ323の動作を要約すれば、ダウンローダ323は、不足したファイルのダウンロードを単純に繰り返すだけである。また、表示部320は、表示範囲の変化又はファイルのダウンロード完了が発生する都度、表示範囲に必要な全てのファイルの入手を試みて、入手できたファイルのみで地図を描画する処理を単純に繰り返すだけである。従って、どのファイルの描画が完了し、どのファイルの描画が完了してないか等を判別して、未描画のファイルだけを選択的に描画するというような面倒な判断処理を行わない。また、表示部320とダウンローダ323は非同期で動作しており、両者の動作タイミングを合わせるというような面倒な同期処理も行っていない。これらのことから、結果的に、地図画像を高速に表示することが可能である。
【0082】
また、クライアントコンピュータ30で描画を行うため、地図サーバ10に描画の負担をかけさせないという点も、地図サーバ10の応答を高速化し、地図画像の高速表示に寄与する。
【0083】
次に、キャッシュデータの管理方法について図9を参照しつつ説明する。図9に示す処理は、メモリ・キャッシュ322及びディスク・キャッシュ325の双方で適用可能である。
【0084】
まず、必要とされるファイルのID(メッシュ番号[Xi,Yj])を、各座標軸毎に、キャッシュ領域のキャッシュサイズでそれぞれ割って余りを求める(S41)。これにより求められたキャッシュ領域(メモリ・キャッシュ322またはディスクキャッシュ325)での格納位置(Xi mod Cnx,Yj mod Cny)に、所望のファイルが格納されているか否かを検査する(S42,S43)。
【0085】
メッシュ番号により指定されている格納位置に目的とするファイルが格納されている場合は、そのファイルを読み出して使用する(S44)。指定された格納位置に目的とするファイルが格納されていない場合は(S43:NO)、その格納位置に以前使用した不要なファイルが残っている場合であるから、その不要なファイルを消去し、その記憶領域を解放する(S45)。そして、S41で必要とされたファイルを上位の記憶装置(地図データベース11等)から所得し、所定の格納位置に格納させる(S46)。
【0086】
このように、メッシュ番号に基づいてキャッシュ領域における格納位置を予め指定するため、従来のようにキャッシュ管理テーブルを参照等して目的とするファイルの所在を確認する手間がいらず、目的とするファイルが格納されている場所を直接的に検査することができる。従って、キャッシュデータの検索、読出しを高速化することができ、上述した各構成と結合することにより高速な地図表示を実現することができる。また、目的とするファイルが指定された格納位置にキャッシュされていない場合は、その格納位置に格納されているファイルを不要なファイルと判断して直ちに削除するため、従来のようにキャッシュ管理テーブル等で優先度を管理する手間がかからず、効率的に不要データの削除(ガーベージコレクション)を行うことができる。
【0087】
次に、図10は、地図データベース11にポリゴンデータ等の各種オブジェクトを格納等する場合の管理方法を示すフローチャートである。
【0088】
まず、オブジェクトの格納であるか取出しであるかを判定し(S51)、オブジェクトの格納である場合は、図6と共に上述したように、そのオブジェクトに外接する矩形を算出する(S52)。そして、どのレベルに格納するかを決定するために以下の処理を行う。即ち、メッシュサイズを検査するための初期値としてレベル番号を最下位レベルにセットし(S53)、そのレベルのメッシュサイズが外接矩形のサイズ以上であるか否かを判定する(S54)。メッシュサイズが外接矩形よりも小さい場合(S54:NO)、レベル番号を1つインクリメントして(S55)、再びS54でメッシュサイズと外接矩形のサイズを比較する。
【0089】
外接矩形のサイズ以上のメッシュサイズを有するレベルが検出された場合は(S54:YES)、外接矩形が含まれるメッシュのうち、その外接矩形の左上隅の座標が位置するメッシュを検出する(S56)。なお、オブジェクトの外接矩形は、一つのメッシュ内に収まる場合もあるし、図6中に示すように最大で4個のメッシュにまたがって存在する場合もある。そして、外接矩形の左上隅の座標が位置するメッシュを、当該オブジェクトの格納先として選択し、このメッシュにオブジェクトのデータを対応付けて地図データベース11に登録する(S57)。
【0090】
一方、オブジェクトの取出し(読出し)の場合は、地図表示に必要な範囲に含まれる全てのメッシュ群及び該メッシュ群の左辺及び上辺に位置するメッシュ群のデータを取り出す(S58)。オブジェクトの外接矩形の左上隅が位置するメッシュに該オブジェクトを対応付けて登録するため、表示範囲に直接含まれるメッシュ以外に、その周辺のメッシュのデータも必要とされるためである。
【0091】
このように、ポリゴンや文字等の各種オブジェクトを、該オブジェクトに外接する矩形を包含するメッシュに対応付けて登録するため、従来のように複数メッシュにまたがるオブジェクトを各メッシュ毎に分割して登録することがなく、ひとまとまりのデータをそのままでハンドリングすることができる。従って、データ量が増大するのを防止し、高速なデータ処理を行うことができ、上述した各構成と相まって、より高速で滑らかな地図表示を実現することができる。
【0092】
なお、本発明は上記実施の形態に限定されるものではない。当業者であれば、実施の形態の構成に新たな追加や変更を加える等のように、種々の変形を行うことができる。
【図面の簡単な説明】
【図1】本発明に従う地図表示システムの一実施形態の概略的な全体構成を示すブロック図である。
【図2】地図表示プログラムの機能的構成を示すブロック図である。
【図3】地図サーバの階層化ファイルシステムを示す説明図である。
【図4】キャッシュ方法を示す説明図である。
【図5】メッシュサイズの異なるレベルを階層化した記憶空間の概念図である。
【図6】オブジェクトの格納方法を示す説明図である。
【図7】表示部の動作を示すフローチャートである。
【図8】ダウンローダの動作を示すフローチャートである。
【図9】キャッシュデータの管理方法を示すフローチャートである。
【図10】オブジェクトの管理方法を示すフローチャートである。
【符号の説明】
10 地図サーバ
11 地図データベース
20 インターネット
30 クライアントコンピュータ
31 クライアントプログラム
32 地図表示プログラム
33 表示装置
34 操作装置
35 キャッシュ領域
Claims (1)
- 多数の断片地図データに細分された全体地図データを有する地図サーバと、所望の断片地図データを前記地図サーバから通信ネットワークを介して受信し、受信した前記断片地図データから地図画像を描画して表示させるクライアントとを備えた地図表示システムにおいて、
(1)前記地図サーバは、各ディレクトリ名が最小文字数で構成される階層化ファイルシステムに、それぞれ地図上の座標値に対応したメッシュ番号を有する前記多数の断片地図データをそれぞれ最小文字数のファイル名で格納しており、
(2)前記クライアントには、
(2a)前記地図サーバから受信した前記断片地図データを前記地図サーバの記憶空間よりも小さい記憶空間を有するキャッシュメモリに保持するためのキャッシュデータ管理装置と、
(2b)前記メッシュ番号を前記最小文字数で構成される階層化ファイルシステムにおけるパス名に変換することにより所定のデータを要求するデータ要求装置と
を設け、
(3)前記キャッシュデータ管理装置は、
(3a)前記断片地図データが有するメッシュ番号を前記キャッシュメモリのキャッシュサイズで除算した余り値に対応する座標値に割り当てる座標割当手段と、
(3b) 前記データ要求装置を介して前記地図サーバから取得したデータを該データに割り当てられた座標値で前記キャッシュメモリに格納させるデータ取得手段と、
(3c)前記所定のデータが前記割り当てられた座標値で前記キャッシュメモリに格納されていない場合には、該座標値に既に格納されているデータを前記キャッシュメモリから削除するデータ削除手段と、
を備えて構成されていることを特徴とする地図表示システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001128071A JP3691405B2 (ja) | 2001-04-25 | 2001-04-25 | データ管理装置及び地図表示システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001128071A JP3691405B2 (ja) | 2001-04-25 | 2001-04-25 | データ管理装置及び地図表示システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002324069A JP2002324069A (ja) | 2002-11-08 |
JP3691405B2 true JP3691405B2 (ja) | 2005-09-07 |
Family
ID=18976830
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001128071A Expired - Fee Related JP3691405B2 (ja) | 2001-04-25 | 2001-04-25 | データ管理装置及び地図表示システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3691405B2 (ja) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005109377A1 (ja) * | 2004-05-10 | 2005-11-17 | Pioneer Corporation | 表示制御装置、表示方法、表示制御用プログラム及び情報記録媒体並びに記録媒体 |
JPWO2007013280A1 (ja) * | 2005-07-29 | 2009-02-05 | 株式会社Access | プラグインモジュール実行方法、ブラウザ実行方法、メーラ実行方法、プログラム、端末装置、及び、ページデータが記録されたコンピュータ読み取り可能な記録媒体 |
JP2007200145A (ja) * | 2006-01-27 | 2007-08-09 | Casio Comput Co Ltd | クライアント装置、サーバー装置、サーバーベースコンピューティングシステムおよびプログラム |
KR100725792B1 (ko) * | 2006-02-01 | 2007-06-08 | 엔에이치엔(주) | 개인 웹페이지에서의 지리 정보 제공 방법 및 시스템 |
JP4623088B2 (ja) | 2007-11-30 | 2011-02-02 | ソニー株式会社 | 地図表示装置と地図表示方法および撮像装置 |
JP5285538B2 (ja) * | 2009-08-20 | 2013-09-11 | 株式会社ナビタイムジャパン | ナビゲーションシステム、ナビゲーション装置、ナビゲーションサーバ、および、保存データ削除方法 |
US8850075B2 (en) * | 2011-07-06 | 2014-09-30 | Microsoft Corporation | Predictive, multi-layer caching architectures |
KR101187537B1 (ko) | 2011-08-25 | 2012-10-02 | 주식회사 인클라우드 | 실시간 u포털 지도서비스를 위한 데이터 처리방법 |
JP5790571B2 (ja) | 2012-03-30 | 2015-10-07 | 株式会社デンソー | 情報処理システム |
CN104423839A (zh) * | 2013-08-30 | 2015-03-18 | 中兴通讯股份有限公司 | 浏览器资源显示方法和装置 |
US9465811B2 (en) * | 2014-03-20 | 2016-10-11 | Facebook, Inc. | Polygon-based indexing of places |
JP6220323B2 (ja) | 2014-09-05 | 2017-10-25 | 株式会社東芝 | オブジェクト検索装置およびその検索方法 |
-
2001
- 2001-04-25 JP JP2001128071A patent/JP3691405B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002324069A (ja) | 2002-11-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11461286B2 (en) | Fair sampling in a hierarchical filesystem | |
US9575770B2 (en) | Method of graphical display of hierarchical hardlinks to files in a file system | |
JP3691405B2 (ja) | データ管理装置及び地図表示システム | |
JP4295791B2 (ja) | アトミックに更新される集中キャッシュメモリのための方法及びシステム | |
US7020658B1 (en) | Data file management system and method for browsers | |
JP2013520755A (ja) | 地理情報システムに対する携帯グローブ形成 | |
US10929368B2 (en) | Data set visualizer for tree based file systems | |
KR100853308B1 (ko) | 항목 타입별 구조화된 검색 | |
CN112424770A (zh) | 无状态应用中以接近恒定的时间浏览和随机访问大型层次结构的能力 | |
JP5105894B2 (ja) | 文書検索システム、文書検索装置及びその方法とプログラム、記憶媒体 | |
JP3615716B2 (ja) | データ管理装置及び地図データ記憶システム | |
JP3445912B2 (ja) | ハイパーテキスト自動取得装置 | |
JP2010182008A (ja) | 画像表示プログラム、および画像表示装置 | |
JP2001134776A (ja) | 地図データ配信方法 | |
JPH08185348A (ja) | 情報処理装置および情報処理方法 | |
JPH1031615A (ja) | 分散ハイパーメディアシステム | |
JP3476805B2 (ja) | 画像表示システム及び方法 | |
JP2002055601A (ja) | 地図表示システム及び方法 | |
JP3819366B2 (ja) | 地図データ提供方法,及び、地図データ提供プログラム | |
JP4491423B2 (ja) | 地図データ提供方法,及び、地図データ提供プログラム | |
JPH10269348A (ja) | 衛星画像データの管理方法及び地理画像処理装置、記録媒体 | |
JP2004287931A (ja) | 地図データ提供システム、地図データ記憶装置の管理装置および管理方法 | |
JPH1139206A (ja) | メディア情報アクセス履歴管理システム | |
CN114116943A (zh) | 一种优化地图瓦片加载的方法、终端设备以及存储介质 | |
Rashad et al. | Vector Pyramids: A Multi-scale Vector Rendering and Processing Algorithm |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040419 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040616 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040709 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040907 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20040907 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20041004 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041102 |
|
A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20041203 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050610 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050615 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 3691405 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090624 Year of fee payment: 4 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090624 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100624 Year of fee payment: 5 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110624 Year of fee payment: 6 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110624 Year of fee payment: 6 |
|
S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
S533 | Written request for registration of change of name |
Free format text: JAPANESE INTERMEDIATE CODE: R313533 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110624 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120624 Year of fee payment: 7 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120624 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130624 Year of fee payment: 8 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140624 Year of fee payment: 9 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
LAPS | Cancellation because of no payment of annual fees |