JP3598183B2 - 多次元データ管理方法、多次元データ管理装置、多次元データ管理プログラムを記録した媒体 - Google Patents
多次元データ管理方法、多次元データ管理装置、多次元データ管理プログラムを記録した媒体 Download PDFInfo
- Publication number
- JP3598183B2 JP3598183B2 JP29440396A JP29440396A JP3598183B2 JP 3598183 B2 JP3598183 B2 JP 3598183B2 JP 29440396 A JP29440396 A JP 29440396A JP 29440396 A JP29440396 A JP 29440396A JP 3598183 B2 JP3598183 B2 JP 3598183B2
- Authority
- JP
- Japan
- Prior art keywords
- mesh
- area
- data
- multidimensional data
- search
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/22—Indexing; Data structures therefor; Storage structures
- G06F16/2228—Indexing structures
- G06F16/2264—Multidimensional index structures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Processing Or Creating Images (AREA)
Description
【発明の属する技術分野】
本発明は、2次元乃至はそれ以上の多次元空間中で位置の決まる多次元データの管理に適した多次元データ管理方法、多次元データ管理装置および多次元データ管理プログラムを記録した媒体に関するものである。より具体的には、平面あるいは空間内における図形データや、複数の属性を有する統計的なデータを個々の属性を各次元に対応させることにより、登録、削除、修正、検索(例えば、範囲検索、最近傍値検索)などの処理を、単独であるいは適宜組み合わせて実施することのできる多次元データ管理装置、方法およびそのプログラムを記録した媒体に関する。
【0002】
【従来の技術】
従来から、複数の属性を有するデータをコンピュータを用いて管理する手法が数多く提案されている。例えば、画像処理、コンピュータビジョン、図面管理などの分野においては、ベクトル、点、記号などの大量の図形要素により表される膨大な図面をコンピュータにより管理し、データの登録、削除を行ったり、所望の図面を検索し、変更する作業が必要とされている。このようなデータ管理として、従来から知られていたものに、固定グリッド法がある。この固定グリッド法は、空間を固定の領域に分割して、各領域単位でデータを管理するものである。この固定グリッド法は、データが定まっている場合には、空間検索が高速に行えてメモリ効率も良い。しかし、例えば設備データのように頻繁に追加削除されるデータに対しては、領域の分割が固定のため分割領域ごとのデータ数のばらつきが大きくなる。そのため、全くデータが存在しない領域についても、他の領域と同様に検索処理を行ったり、データの蓄積領域を確保する必要があり、検索速度が上がらず、メモリ効率も低くなる。
【0003】
このような固定グリッド法の問題点を解消し、多次元データの効率的管理や高速な検索を目的として、空間分割に基づく階層的なデータ構造が着目され、種々の提案がなされている。例えば、特開平3−48974号公報に示された図形データ管理装置は、多次元空間中の大量の図形の位置情報及び属性を、3分木構造を有するMD木の理論を適用して分割・構造化することにより、表示領域の変更に伴うデータ検索速度の向上を図るものである。また、同様な手法として、2次元データに対する2n分割木を使用したquad−tree法も知られている。
【0004】
[1.MD木による方法]
MD木による方法では、木は、図42に示すように、末端の葉Lと内部ノードIの2種類のノードとポインタから構成されている。データを配置する空間は再帰的に分割され、各ノードは分割された空間に対応付けられる。すなわち、親ノードは、すべての子ノードの空間を包含する最小の(n次元)長方形に対応する。また、データはすべて末端の葉Lに蓄積される。内部ノードは、初期状態をのぞき、2つ以上3つ以下の子ノードを持つように設定され、子ノード数が3を越える場合には、内部ノードを分割し、この条件を満足するように設定されている。
【0005】
各葉に蓄積できるデータ数をデータ容量Pと呼び、ある葉にP+1個目のデータが投入されると、そのノードに対応する空間は分割される。例えば、図43に示すように、P=3とし、空間内に1から6のデータが図43(A)のように配置されているとすると、この空間は分割軸X1によって2分割される。このような分割された空間は、図43(B)のような木構造に対応しており、各空間に対応する各葉にはそれぞれ1,4,5と2,3,6の3個のデータがそれぞれ蓄積されている。
この状態で新たなデータ7が投入されると、各葉にはそれ以上データを蓄積することはできないので、データ7が投入された側の領域は図43(A)の第2の分割軸Y1によって分割される。この領域の分割に対応して、木構造においても分割された領域に対応する葉を分割し、新しい葉を作成すると共に、この葉に対応する子ノードを追加する。
【0006】
このようにすると葉の数が増加した分、新たなデータ7の投入が可能となり、さらにデータ8の投入も可能となる。さらに、データ9の投入すると、データ9を投入領域に対応する葉には、それ以上のデータを投入する余地がないので、この投入領域を3回目の分割軸X2によって分割すると共に、対応する新しい葉を作成する。ところが、MD木による分割では、1つの親ノードが3つの子ノードしか持つことができないように設定されているため、図43(C)のノードCに対応する葉を分割して新しい葉を作成する場合には、内部ノードそのものを、図43(D)のように分割する必要がある。
【0007】
このような木構造を有するMD木では、内部ノードの分割により、データの分布状態や投入順序にかかわりなく、木の根(ROOT)からすべての葉までの距離が等しいため、木構造としてのバランスが良く、検索効率がよい利点がある。また、どの葉にも必ず(P+1)/2のデータが蓄積されるため、固定グリッド法に比較して、メモリの利用効率も向上する。
【0008】
[2.quad−tree法]
quad−tree法では、領域を2次元平面の各軸に平行な面で4等分割する。分割された1つの空間に含まれるデータ数がP以下になるまで再帰的に分割を繰り返し、この過程を4分木として記憶する。このquad−tree法は、例えば、ACM Computing Surveys, Vol,20,No.4 December 1988に記載されている。
【0009】
この分割法では、葉の分割時にそれに対応する子ノードを新設するだけであるため、MD木法のように内部ノードの分割時に新規なROOTを作成する作業は不要であり、木構造の管理は容易となる。また、領域を等分割するため、分割位置は簡単に特定でき、MD木法のように個々の分割軸を記憶しておく必要はない。
【0010】
一方、quad−tree法では、データの分布を無視した等面積分割が行われるため、データの分布が一様でない場合に、木のバランス性およびメモリの利用効率が極端に低下する。
【0011】
[3.範囲検索、最近傍データ検索]
前記のようなMD木法やquad−tree法によって空間を階層的に分割するデータの管理方法においても、通常のデータ管理方法と同様に、範囲検索や最近傍データ検索が要求される。すなわち、範囲検索は、一定の値の範囲に属するデータを検索するものである。また、最近傍データ検索は、例えば、図形の中心点やカーソル、各データの平均値や中心値などのある特定の値から最も近い値を持つデータを検索するものである。
【0012】
図44に最近傍データ検索の一例を挙げる。この例は、平面図形データを管理する装置において、登録されたデータである図形要素の指定が容易に行えるようにカーソルに最も近い図形要素を常に色替え表示するものである。この例では、図44(A)に示すようにカーソル位置に対応する点Qを含む領域に対応する葉を求め、その葉の中で点Qに最も近いデータ1を求める。次に、点Qとデータ1の距離D1に含まれるデータを範囲検索を利用して他の葉の中から検索し、点Qとの距離D2がより近いデータ3を得る。以下、指定範囲をD2に変更し検索を続ける。
【0013】
【発明が解決しようとする課題】
[1.分割手法による問題点]
ところで、前記のようなMD木法においては、葉の分割における空間分割法は、X−Y−X−Y・・のように巡回的に分割軸を選択したり、あるいは長方形の辺の長さにより分割軸を選択するなどの方法があるが、基本的には、データ量によって分割する可変面積(容積)分割を基本としている。しかしながら、このような可変面積分割は、分割軸の位置が一定でないため、分割作業時に分割位置の算定に時間がかかると共に、各分割軸の座標を記憶しておく必要があり、その分だけ必要な記憶領域が増大する欠点があった。また、完全平衡木を作成するために、内部ノードの分割時に分割する葉に対応するノードを新設するだけでなく、新設したノードから遡ってROOTとなるノードを新設する必要があり、分割する葉に対応するノードのみを新設すれば良い他の方法に比較して、木構造の管理が複雑化する欠点があった。
【0014】
[2.末端の葉のみのデータ登録による問題点]
さらに、前記MD木法やquad−tree法などの従来の技術では、木構造の末端に存在する各葉にだけデータを蓄積するものであるため、領域内に投入するデータが他の領域にもまたがる場合には、複数の領域に重複登録されるデータ数が多くなり、それに伴って個々の領域内に存在すると判定されるデータ数が大きくなるため、その分領域の分割数も多くなる。すなわち、図45に示すように、線分Lが領域B,C,Dにまたがって存在する場合、この線分はLは各領域に対応するすべての葉に登録される。しかし、各葉に登録できるデータ数はあらかじめPに設定されているので、重複分だけ余分にデータ数が領域に投入されているのと同じことになり、そのために領域の分割数が多くなり、分割領域に対応する内部ノードや葉の数も多くなる。その結果、木構造が複雑がすると共に、必要とするメモリの増大や、検索効率の低下を招く欠点があった。特に、工事設計、設備管理、図面管理などのように、異なった長さ、面積、容積などを有する多数の図形データを管理する場合には、従来技術のように末端の葉に各領域に属するデータをすべて登録し、かつデータ数によって領域を分割していると、ほとんどの図形データが重複登録の対象となり、メモリの利用効率が極端に低下する。
【0015】
さらに、前記の従来技術では、末端の葉を分割する基準を、その葉に登録するデータ数が予め設定された値Pを越えるか否かによっていた。そのため、重複登録が多いと、末端の葉を分割しても分割後の葉に登録されたデータ数が分割前の葉に登録されたデータ数に比較してほとんど減少せず、その結果、さらに分割を繰り返す必要性が生じ、記憶領域の限度まで際限なく分割が行われてしまう欠点もあった。
【0016】
また、MD木法では、データ数が等しくなるように領域を分割するため、結果として分割軸による図形データの分割を避けることもあるが、quad−tree法では、データの分布を無視した等面積分割が行われるため、図形データの分割を避けるように分割軸を配置することはできない。そのため、一定のサイズを有する図形データが分割される機会が多くなり、重複登録の可能性がより高くなっていた。
【0017】
[3.中間ノードへの登録]
これを改善するために、quad−tree法では、次のような手法が採用されている。まず、前記ACM Computing Surveys, Vol,20,No.4 December 1988の第299頁のFigure19.に記載の手法は、図46に記載のような図形データA−Gをquad−treeによって管理する場合に、2以上の領域にまたがる図形については、中間ノードに登録することにより、重複登録を避けている。すなわち、図形データA,Eは全領域(全世界)を4分割してなる領域の複数にまたがるために、これらの領域を包含する全領域に対応する親ノード1に登録される。同様に、領域をまたがる図形データB,C,Dはそれらをすべて包含する領域に対応するノード3に、図形データGはノード5に対応する。そして、またがることのない図形データFは、最も細分化された領域に対応するノード15に登録される。
【0018】
確かにこのような従来技術では複数領域にまたがったデータの重複登録は完全に解消される利点はある。しかし、このような手法では、図形データHのように複数の領域にまたがる部分がごく少ないデータであっても、その複数の領域を包含する上位の領域に対応するノードに登録することになる。その結果、上位の領域内に登録するデータが多くなり、データ検索の範囲が広くなって、検索効率が低下する。すなわち、広大な範囲を持つ上位の領域全体を検索するよりも、たとえ重複登録の結果検索対象領域の数は多くなっても範囲の狭い複数の領域を検索する方が、検索を高速に行えるからである。
【0019】
このような重複登録を完全に避ける手法の問題点を解決するために、前記の文献第301頁のFigure 21.には、中間ノードへの登録を行うと同時に重複登録も可能とした手法も提案されている。この手法を図47により説明する。
【0020】
例えば、図形データGは、それを含む最小の領域は全領域を4分割した際の右下の領域5#に属するので、この領域をさらに4分割してその境界X1で図形Gを2つの図形データG1,G2に分割する。そして、分割されたそれぞれの図形データG1,G2について、それを包含する最小の領域10#,11#を求める。この場合、図形データFが属する領域14#と同じサイズまで領域の分割を行うと、図形データGの分割された部分はG1,G2さらに分割されることになるため、「図形データを包含する最小の領域を判定した後、1回だけ図形データの分割を行う」という条件に反する。そのため、図形データGは、領域10#,11#に対応するノード10,11に登録する。
【0021】
ここで、ノード11は中間ノードであり、この中間ノード11にデータを登録することにより、それよりも中間ノード11の子ノードである末端のノード15,16にデータを重複して登録するよりも、検索速度を向上できる。一方、図形データGが存在する2つのノード10,11の両方に図形データGを登録することにより、検索対象範囲を図形データGが属する最小の領域5#よりもより狭い領域6#,7#に対応するノード6,7に限定することが可能になる。
【0022】
ところが、この従来技術は、図形データの分割を1回しか行わないことを条件としているために、1つのデータについての重複登録が1回で済むという利点はあるものの、パイプライン、送電線、交通路などのように長尺の図形データのように、重複数が多くなったとしても分割して登録したいデータを処理するには不適当であった。
【0023】
[4.最近傍データ検索時の問題点]
また、前記の従来技術では、最近傍データ検索を行う場合に、指定された点Qを含む葉を求め、その葉の中で最も近いデータを求めてから、そのデータと指定された点Qとの距離を利用して範囲検索を行っていた。しかし、MD木法のように、各葉の内部に必ずデータが存在する場合には、このような手法を利用することは可能である。しかし、quad−tree法のように、領域を等分割するものでは、分割された領域内にデータが存在しない場合があり、そのような場合には、前記のような手法では最近傍データの検索を行うことが不可能であった。
【0024】
[5.発明の目的]
本発明は前記のような従来技術の問題点を解決するために提案されたもので、その目的は、末端の葉を分割するか否かの判定を行うことにより、それ以上分割してもデータ管理上のメリットがない場合には、分割を行わないことによって、メモリの利用効率の向上と検索処理の高速化を可能とすることにある。
【0025】
本発明の他の目的は、一定の条件下で、内部ノードにもデータを登録すると共に過剰な重複登録を抑制することにより、複数の分割領域にまたがるようなデータについての検索速度の向上および記憶領域の節約を可能とすることにある。
【0026】
本発明の他の目的は、1個あるいは複数個の分割された領域を包含する一定の範囲を定め、この範囲内に属するデータを迅速に検索することにある。
本発明の他の目的は、指定した点の最近傍に位置するデータを検索する処理に当たって、指定した点を含む分割された領域内に最近傍データが存在しない場合でも、他の領域内の最近傍データを迅速に検索することにある。
本発明の他の目的は、2のN乗分木で領域の分割を管理すると共に、各領域を等面積(等容積)に分割することにより、領域の分割および領域の合併作業を容易に実施できると共に、分割位置を記憶することを不要として利用するメモリ領域を低減することにある。
【0027】
本発明の他の目的は、2のN乗分木で領域の分割を管理すると共に、各領域をデータ数に依存することなく、一定の分割規則(制限された範囲内におけるランダムな分割も含む)にしたがって分割することにより、領域の分割作業を容易に実施することにある。
【0032】
【課題を解決するための手段】
前記の目的を達成するため、請求項1の発明は、コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理方法において、前記所定の領域の中の第1の領域が、その子領域である第2の領域に階層的に分割されている場合に、前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断し、前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合し、前記第1の領域に前記多次元データを割り当てることを特徴とする。
【0033】
請求項3の発明は、請求項1の発明を装置の観点から把握したものであり、コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理装置において、請求項1の発明の各段階に対応する手段として、併合許容条件を満たすか否かを判断する手段と、第2の領域を第1の領域に併合する手段と、第1の領域に多次元データを割り当てる手段とを備えたことを特徴とする。
【0034】
請求項5の発明は、請求項1、3の発明を記録媒体の観点から把握したものであり、コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理プログラムを記録した記録媒体であって、プログラムが、コンピュータに、請求項1の発明の各段階に対応する処理として、併合許容条件を満たすか否かを判断する処理と、第2の領域を第1の領域に併合する処理と、第1の領域に多次元データを割り当てる処理と、を行わせることを特徴とする。
【0035】
以上のような請求項1、3、5の発明によれば、管理対象となる多次元データが含まれる第2の領域を併合してその親領域である第1の領域に多次元データを割り当てることに、データ管理上のメリットがあるか否かを判断し、メリットがある場合にはその併合を行うことによって、メモリの利用効率の向上と、データ検索処理の高速化が可能となる。
【0036】
請求項2の発明は、コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理方法において、前記所定の領域の中の第1の領域を、その子領域である第2の領域に階層的に分割する場合に、前記第1の領域に前記多次元データを割り当てたときの状態と、前記第2の領域に前記多次元データを割り当てたときの状態とに基づいて示される分割許容条件を満たすか否かを判断し、前記分割許容条件を満たすと判断した場合には、前記第1の領域を前記第2の領域に階層的に分割し、前記第2の領域に前記多次元データを割り当て、また、前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断し、前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合し、前記第1の領域に前記多次元データを割り当てることを特徴とする。
【0037】
請求項4の発明は、請求項2の発明を装置の観点から把握したものであり、コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理装置において、請求項2の発明の各段階に対応する手段として、分割許容条件を満たすか否かを判断する手段と、第1の領域を第2の領域に階層的に分割する手段と、併合許容条件を満たすか否かを判断する手段と、第2の領域を第1の領域に併合する手段と、第1の領域および第2の領域の少なくとも一方に多次元データを割り当てる手段とを備えたことを特徴とする。
【0038】
請求項6の発明は、請求項2、4の発明を記録媒体の観点から把握したものであり、コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理プログラムを記録した記録媒体であって、プログラムが、コンピュータに、請求項2の発明の各段階に対応する処理として、分割許容条件を満たすか否かを判断する処理と、第1の領域を第2の領域に階層的に分割する処理と、第2の領域に多次元データを割り当てる処理と、併合許容条件を満たすか否かを判断する処理と、第2の領域を第1の領域に併合する処理と、第1の領域に多次元データを割り当てる処理と、を行わせることを特徴とする。
【0039】
以上のような請求項2、4、6の発明によれば、管理対象となる多次元データが含まれる第1の領域をさらに分割してその子領域である第2の領域に多次元データを割り当てることに、データ管理上のメリットがあるか否かを判断し、また、管理対象となる多次元データが含まれる第2の領域を併合してその親領域である第1の領域に多次元データを割り当てることに、データ管理上のメリットがあるか否かを判断し、データ管理上で最適な領域に多次元データを割り当てることによって、メモリの利用効率の向上と、データ検索処理の高速化が可能となる。
【0040】
本発明における一つの態様は、請求項2の多次元データ管理方法において、前記分割許容条件が、前記第2の領域に所属する多次元データ数の和と、前記第1の領域に所属する多次元データ数とを比較して、分割するか否かを判定するものである。請求項4の多次元データ管理装置において、同様の分割許容条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0041】
本発明における一つの態様は、請求項2の多次元データ管理方法において、前記分割許容条件が、前記第1の領域に所属する多次元データ数と、前記第2の領域の中の複数の領域に所属する多次元データ数とを比較して、分割するか否かを判定するものである。請求項4の多次元データ管理装置において、同様の分割許容条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0042】
本発明における一つの態様は、請求項1または2の多次元データ管理方法において、前記併合許容条件が、前記第2の領域に所属する多次元データ数の和と、前記第1の領域に所属する多次元データ数とを比較して、併合するか否かを判定するものである。請求項3または4の多次元データ管理装置において、同様の併合許容条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0043】
本発明における一つの態様は、請求項1または2の多次元データ管理方法において、前記併合許容条件が、前記第1の領域に所属する多次元データ数と、前記第2の領域の中の複数の領域に所属する多次元データ数とを比較して、併合するか否かを判定するものである。請求項3または4の多次元データ管理装置において、同様の併合許容条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0044】
本発明における一つの態様は、請求項1または2の多次元データ管理方法において、前記併合許容条件が、前記第2の領域に登録できる多次元データ数を一定値以下に設定し、親領域を同じくする第2の領域のそれぞれに登録された多次元データ数がいずれも前記設定値未満の場合に、前記第2の領域を併合するものである。請求項3または4の多次元データ管理装置において、同様の併合許容条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0045】
以上のように分割許容条件や併合許容条件を限定した各態様によれば、数値によって明確に定義した分割許容条件あるいは併合許容条件を用いることにより、領域の分割あるいは併合を行った場合にデータ管理上のメリットがあるか否かを数値に基づいて客観的に判断することができる。
【0046】
本発明における一つの態様は、請求項2の多次元データ管理方法において、前記第1の領域の分割時に、前記多次元データを、分割によって生じた第2の領域および前記第1の領域のいずれに再登録すべきかを判断して、再登録を行うものである。請求項4の多次元データ管理装置において、第1の領域の分割時に、同様の再登録先に関する判断および再登録を行うことも可能であり、それもまた、本発明における一つの態様である。
【0047】
以上のような再登録先の判断を行う各態様によれば、第1の領域の分割時に、多次元データを第1の領域および第2の領域のいずれに再登録することにデータ管理上のメリットがあるか否かを判断し、メリットがない場合には、第1の領域および第2の領域の両方に重複して登録しないようにすることにより、過剰な重複登録を抑制して記憶領域を節約すると共に、複数の領域にまたがる多次元データについての検索速度を向上できる。
【0048】
本発明における一つの態様は、請求項2の多次元データ管理方法において、再登録先の判断を行う場合に、前記多次元データを前記第1の領域および第2の領域のいずれに再登録すべきかを判断する条件が、前記多次元データが前記第1の領域を完全に含んでいないことを条件とするものである。請求項4の多次元データ管理装置において、再登録先の判断を行う場合に、再登録先を判断する条件として同様の条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0049】
本発明における一つの態様は、請求項2の多次元データ管理方法において、再登録先の判断を行う場合に、前記多次元データを前記第1の領域および第2の領域のいずれに再登録すべきかを判断する条件が、前記多次元データが重なっている前記第2の領域の数が、予め設定された数以下であることを条件とするものである。請求項4の多次元データ管理装置において、再登録先の判断を行う場合に、再登録先を判断する条件として同様の条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0050】
本発明における一つの態様は、請求項2の多次元データ管理方法において、再登録先の判断を行う場合に、前記多次元データを前記第1の領域および第2の領域のいずれに再登録すべきかを判断する条件が、前記多次元データごとに重複登録される領域の数の上限を定め、前記第2の領域に登録しても、重複登録数が前記上限以下であることを条件とするものである。請求項4の多次元データ管理装置において、再登録先の判断を行う場合に、再登録先を判断する条件として同様の条件を用いることも可能であり、それもまた、本発明における一つの態様である。
【0051】
以上のように再登録先を判断する条件を限定した各態様によれば、再登録先を判断する条件として、明確に定義した条件を用いることにより、特定の領域への再登録を行うことにデータ管理上のメリットがあるか否かをその明確な条件に基づいて客観的に判断することができる。
【0061】
本発明における一つの態様は、請求項1または2の多次元データ管理方法において、前記所定の領域内において指定された範囲に属する多次元データを検索する範囲検索ステップを含むものである。請求項3または4の多次元データ管理装置において、前記範囲検索ステップに対応する範囲検索手段を備えることも可能であり、それもまた、本発明における一つの態様である。
【0062】
以上のような多次元データの範囲検索を行う各態様によれば、1個あるいは複数個の分割された領域を包含する一定の範囲を定め、この範囲内に属するデータを迅速に検索することができる。
【0063】
本発明における一つの態様は、請求項1または2の多次元データ管理方法において、前記所定の領域内において指定された点に最も近い多次元データを検索する最近傍データの検索ステップを含むものである。請求項3または4の多次元データ管理装置において、前記最近傍データの検索ステップに対応する最近傍データの検索手段を備えることも可能であり、それもまた、本発明における一つの態様である。
【0064】
本発明における一つの態様は、請求項1または2の多次元データ管理方法において、前記最近傍データの検索ステップが、前記指定された点を含む最小の領域に多次元データが登録されていない場合に、最近傍データの候補が1つ決定されるまで検索範囲を拡大するステップを含むものである。請求項3または4の多次元データ管理装置において、前記最近傍データの検索手段が、前記検索範囲を拡大するステップに対応する機能を有することも可能であり、それもまた、本発明における一つの態様である。
【0065】
以上のような最近傍データの検索を行う各態様によれば、指定した点の最近傍に位置する最近傍データを迅速に検索することができる。特に、検索範囲を拡大するステップまたは機能を有する態様によれば、指定された点を含む最小の領域に多次元データが登録されていない場合であっても、検索範囲を拡大することに より、最近傍データを迅速に検出することができる。
【0066】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照して具体的に説明する。なお、以下の実施形態は、電力系統の配電線図のような2次元データの管理・検索についてのものである。
【0067】
[1.用語の説明]
各実施形態について説明する前に、本明細書中で用いられる種々の用語について説明する。
【0068】
(a)「データの管理」:
データの登録・削除、メッシュの分割・併合、データの検索(例えば、矩形検索、最近傍データ検索)などのデータを処理する1つあるいは複数の手続きを包含する。
【0069】
(b)「世界座標範囲または世界範囲」:
データを管理する空間の範囲のことをいう。通常、データ格納領域の初期時に与えられた範囲である。
【0070】
(c)「図形」:
多次元空間内で座標によって表示される多次元データの1つであって、本実施の形態では、2次元空間内に配置された点、線、面などの図形要素の単独あるいは組み合わせからなるデータを指す。図形は、その図形が世界座標範囲でどのような位置/領域を占めているかを表わす数値データを持っている。この図形データは与えられたままデータ領域にコピーされる。なお、3次元空間内においては、立体図形を指すことは言うまでもない。
図形には、図形要素の組み合わせからなる比較的小さな図形(本実施の形態ではサブ図形と呼ぶ)と、このサブ図形をさらに組み合わせてなるより大きな図形(本実施の形態ではスーパー図形と呼ぶ)がある。本実施の形態において、登録、削除、検索などの管理対象となる図形には、図形要素、サブ図形、スーパー図形のいずれもが含まれる。図形をどのような態様で管理するかは、管理の目的、コンピュータの記憶領域の大小、検索速度、分割するメッシュの階層レベルなどによって適宜選択することができる。
【0071】
(d)「メッシュ」:
世界座標範囲が2のN乗分割されてできる空間を言う。従来技術の説明で使用したデータが属する領域と同じ。本発明の第1実施形態ないし第3実施形態では図形という2次元データを管理するため、世界座標範囲を4分割(繰り返し4分割された場合も含む)された結果できる四角形をいう。
世界座標範囲全体自体もメッシュと呼ぶ。ある程度の数の図形データがデータ格納領域に登録された状態では、世界座標範囲はいくつかのメッシュに分割されている。通常、図形の詰まったところは細かく小さいメッシュに分割され、図形の少ないところは大きなメッシュに分割される。
【0072】
N次元空間における分割では、各次元について2分割するので、メッシュは2のN乗分割される。世界範囲から始まって細かく分割されるメッシュを2のN乗分木を用いて管理する。2のN乗分木のデータ構造もデータ領域上に載せる。2のN乗分木の各ノードから対応するメッシュに関する情報が容易に得られる。
【0073】
(e)「木構造」:
メッシュ分割された世界座標範囲は4分木で管理され、世界座標範囲内の各メッシュは4分木の1つのノードに対応する。逆に、4分木のどのノードも、メッシュ分割された世界座標範囲のいずれか1つのメッシュに対応する。例えば、与えられたデータ格納領域の初期時には、前記世界座標範囲には図形は一つもなく、世界座標範囲全体を指すたった1個のノード(根ノード)からなる4分木だけを構成する。
ノードとメッシュは1対1に対応し、メッシュの分割・併合に伴ってノードの追加・削除を行うことによってこの対応が維持される。各ノードは対応するメッシュが存在する時は、そのメッシュデータを指していて、存在しないときはどこも指さない。メッシュ分割の時は、与えられた飯データ領域を指し、合併しメッシュがなくなったときはどこも指さないようにノードは変わる。おな、ノードの追加・削除を動的に行わず、あらかじめ定められた4分木乗でメッシュと対応付けられているノードの範囲のみを管理することもできるが、その場合はこの限りでない。
具体的には、世界座標範囲全体を示す四角形のメッシュは「根ノード」に対応し、根ノードの4つの子ノードは世界座標範囲の四角形を4分割した4つのメッシュに対応する。例えば、メッシュMがメッシュm0〜m3に4分割されているとき、メッシュMに対応するノードNはメッシュm0〜m3に対応するノードn0〜n3をすぐ下の子ノードとして持つ。以下の実施形態では、メッシュの親子関係が分かるように、子メッシュの番号を親メッシュの番号の4倍プラス0,1,2,3とし、4分割したメッシュの左下、左上、右下、右上の順にその番号を付する。すなわち、m0=4M,m1=4M+1,m2=4M+2,m3=4M+3である。
【0074】
逆に、メッシュに対応するノードを決定する方法としては、例えば4分木の根ノードから出発して、与えられたメッシュを含むメッシュに対応する子ノードに順次降りて行き、与えられたメッシュに一致するメッシュに対応するノードに至る方法がある。いずれにせよ、ノードとメッシュは1対1に対応するから、その対応を実現する方法には種々の形態があり、いずれの方法を採用してもメッシュ及びノードが一意に決定される。
なお、管理するデータの種類によっては、4分木は1本とは限らず、表示倍率別あるいは図形種類別に用意することもある。
【0075】
(f)「末端ノードと内ノード」:
葉ノードに対応するメッシュは分割されておらず、このメッシュを「末端メッシュ」と呼ぶ。これに対し、内ノードに対応するメッシュは必ず分割済みである。また、図形は末端メッシュに所属するものとし、末端メッシュに対応する葉ノードは、そのメッシュに所属する全図形リストを持つ。さらに、図形が占める領域とメッシュの領域の重なりがあるとき、「図形はメッシュに所属する」という。なお、内ノードは「中間ノード」とも呼ばれ、これに対応するめしは「中間メッシュ」「被分割メッシュ」呼ばれる。
【0076】
(g)「メッシュの状態データ」:
1つノードを指定すると、そのノードに対応するメッシュがどれであるかを検索する手段(後述するメッシュ検索手段)があるが、この手段としては、例えば、メッシュの座標を計算で割り出したり、メッシュのデータを直接ノードが持つことにより実現される。
【0077】
例えば、各ノードが直接対応するメッシュに関するデータを持つ方法がある。このデータを「メッシュの状態データ」と呼ぶ。このデータはデータ領域上に置かれ、対応するメッシュが存在するノードにはそのデータ格納領域を指すポインタを格納すればよい。一方、対応するメッシュがないノードは何も指さない(ヌルを指すポインタを格納する)。このメッシュの状態データ図3に示すような構造をしており、は、図形のリストを状態データとして持つ。この図形リストから具体的な図形データ(座標、色、幅、種類など)にアクセスすることが容易となる。その他、状態データとして、メッシュと重なりのある図形数や、種類毎の所属する図形数などを持つ場合もある。なお、以下の実施形態では、所属図形数を状態データとして持っている。
【0078】
ここで、図形がメッシュに登録されているとは、図形データがメッシュの所属図形リストに入っていることを言い、図形がメッシュに所属するとは、単に図形がメッシュには言っているだけでなく、メッシュの下層の子メッシュにも登録されていることを言う。また、所属図形数とは、メッシュそれ自体に登録されている図形と、そのメッシュより下層の子メッシュに登録されている図形を重複なく数えることを言う。所属図形リストとは、メッシュに登録されている図形(図形要素やサブ図形)のリストを意味する。
【0079】
また、メッシュデータとして、葉ノードと内ノードが持つ情報の種類が異なることもある。これは、内ノードには所属する図形リストを保持させる必要がないことによるが、データ領域に余裕があれば、内ノードにも所属する図形リストを保持させることもできる。なお、ノードが持つメッシュの状態データは、与えられたデータ領域上に格納される。
【0080】
(h)「メッシュの分割」:
葉ノードNに対応する末端メッシュMは、一定の条件(例えば、そのメッシュに所属する図形数が一定数を超えたとき)を満たすと4分割される。そして、4分割によって生じる4つのメッシュ(m0〜m3)に対応するノードが4つ(n0〜n3)作られ、それらはノードNの子ノードになる。つまり、ノードNは内ノードになり、4つのノード(n0〜n3)が葉ノードになる。メッシュMに所属している図形のうち、分割後のメッシュ(m0〜m3)に所属すべき図形は分割後のメッシュに所属させる。メッシュMの所属のままでよい図形はそのままで良い。メッシュM,m0,m1,m2,m3の状態データを各対応ノードで更新する。
一方、内ノードNに対応するメッシュMは必ず分割されている。メッシュMが一定の条件(例えば、そのメッシュに所属する図形数が一定数を下回ったとき)を満たしたとき、メッシュMに対応するノードの子ノード、孫ノードを抹消する。その結果、メッシュMは未分割のメッシュになり、対応ノードは葉ノードになる。そして、メッシュM以下の末端メッシュに所属していた図形をメッシュMに所属させる。これにより、ノードNが持つメッシュMの状態データは、所属図形リストを持つことになる。
【0081】
[2.各実施形態とコンピュータ]
本発明の各実施形態はコンピュータ上に実現され、実施形態の各機能は、所定の手順(プログラム)がこのコンピュータを制御することで実現される。
本明細書における各「手段」は、実施形態の各機能に対応する概念的なもので、必ずしも特定のハードウェアやソフトウェア・ルーチンに1対1には対応しない。同一のハードウェア要素が、場合によって異なった手段を構成する。例えば、コンピュータは、ある命令を実行するときにある手段となり、別の命令を実行するときは別の手段となりうる。また、一つの手段が、わずか1命令によって実現される場合もあれば、多数の命令によって実現される場合もある。したがって、本明細書では、以下、実施形態の各機能を有する仮想的回路ブロック(手段)を想定して実施形態を説明する。また、本実施形態における各手順の各ステップは、その性質に反しない限り、実行順序を変更し、複数同時に実行し、また、実行ごとに異なった順序で実行してもよい。このような順序の変更は、例えば、ユーザが実行可能な処理を選択するなどメニュー形式のインターフェース手法によって実現することができる。
【0082】
[3.第1実施形態]
第1実施形態は、前記第1の目的を達成するための発明に関するものであり、請求項1〜請求項3に記載の多次元データ管理方法、請求項5〜7に記載の多次元データ管理装置及び請求項9〜11に記載のプログラムを記録した媒体に対応するものである。
【0083】
第1実施形態は、末端メッシュのみに図形を登録すると共に、末端メッシュの分割を所定の条件下で行うことにより、データ管理の観点から見て非効率的なメッシュの分割を抑制することで、メモリの使用効率の向上を可能としたものである。
【0084】
すなわち、末端メッシュの分割を許容する所定の条件としては、例えば、次のようなものがある。
(a)所属図形が一定数以上である。
(b)分割した場合、子メッシュの所属図形数の和が、分割前の親メッシュの所属図形数のm倍未満である。
(c)分割した場合、3つ以上の子メッシュに所属する図形の数が、所属図形数のn%未満である。
なお、mの典型的な値は、2倍(4分割だから、4以上は無意味である)、nの典型的な値は例えば30%に設定することができる。
【0085】
木構造を利用したデータ管理方法において、前記(a)の条件のみを用いるのは公知である。第1実施形態では、この(a)の条件に(b)ないし(c)の条件を併用することによって、図形の複数メッシュへの重複登録を抑制し、分割に伴う所要記憶領域の増加を抑制している。使用すべき条件としては、(b)(c)のような形のものだけではなく、(a)のみの条件を用いて分割を行った場合に比較して、個々の図形についてあるいは全図形に関して平均的に1つの図形あたりの所属(登録)メッシュ数を減少させるような効果を持つものならば、どのような条件を用いても良い。例えば、(b)のmの値を所属図形の種類別の数の比率に基づいて決定したり、非常に長い線分のようにもともとある程度の数のメッシュへの重複登録が避けられないタイプの図形を除外して(b)あるいは(c)の条件をチェックするなど、種々考えられる。
【0086】
(a)の条件に基づいて分割を行うことの効果は、より小さなメッシュにより少ない図形を登録することにより、第2実施形態において、矩形検索で矩形に重なると判定されたメッシュから図形を取り出して矩形への所属をチェックする際に、矩形に所属しないと判定される図形を減少させることによって、処理の高速化を図るものである。また、最近傍検索においても、1つのメッシュ所属する図形数が少なければ、最近傍図形を決定するまでに検索調査される図形数が減少することによって高速化が図られる。
【0087】
しかしながら、前記(b)(c)の条件を併用しないで(a)の条件によって資源の許す限り無制限に分割を進めれば、多数重なり合って存在するある程度の大きさを有する図形を登録した場合には、1つの図形の所属メッシュは非常に多数になり、近接するメッシュに所属している図形には共通のものが多いという状況が生じる。このような状況では、分割による個々のメッシュの所属図形の現象が十分はかられないばかりか、検索に際して既にチェックした図形を再度チェックする、あるいは既にチェックしたものと判定して捨象するという無駄な作業の割合が増加し、所要記憶領域の増加のみならず処理速度の低下をも招く。
【0088】
これに対して、(b)(c)の条件を併用すれば、1つの図形あたりの所属メッシュ数を著しく増加させるような分割を抑制することができ、所要記憶領域の増加を抑制し、かつ検索処理の速度を向上させる(低下させない)という効果がある。さらには、分割/併合の頻度が減少することによって、登録/削除の処理も高速化される。
【0089】
末端メッシュの分割に対応して、併合の場合の所定の条件としては、次のようなものを用いることができる。
(d)親メッシュの所属図形が一定数未満である。
(e)併合した場合、子メッシュの所属図形数の和が、親メッシュの所属図形数のm`倍以上である。
(f)併合した場合、3つ以上の子メッシュに所属する図形の数が、所属図形数のn%以上である。
(d)は分割の(a)に対応する条件で、(d)のみを用いるのは公知である。(e)を併用する場合、登録において(b)を併用したとすれば、m`をmに対してどの程度に設定するかで併合の発生を抑制し得る。m`がmに対して大きければ併合が生じにくく、小さければ併合が生じやすい。同様に、(f)と(c)を用いる場合、n`がnに対して大きければ併合が生じにくく、小さければ併合が生じ易い。
【0090】
なお、併合を判定する前記の条件は、併用せず単独で用いても良い。すなわち、(e)のみを用いて併合の可否を判定しても良い。(d)の条件を用いないとすれば、登録の結果として併合すべきメッシュが生じることもあるので、登録処理時において、末端メッシュの所属図形リストに図形を加えた後に、メッシュの分割処理を試みるだけでなく、メッシュの併合処理も合わせて試みることが効果的である。
【0091】
また、(e)の条件判定を行う場合、第1実施形態においては各メッシュの所属図形数は得られるようになっているので、メッシュ状態データはそのままでよい。(b)に関しては、末端メッシュの状態データの一部として子メッシュの所属図形数の和を保持するカウンタを設け、登録処理時において末端メッシュを分割して作成する子メッシュについて図形の所属をチェックし、所属すればそのカウンタを増すなどの手段を講じて、判定が迅速に行えるようにすれば効果的である。
【0092】
[3−1.第1実施形態の構成]
図1は、第1実施形態の構成を示す機能ブロック図である。
【0093】
すなわち、本実施形態の多次元データ管理装置は、中央処理装置1に接続されたキーボードマウスその他の入力装置2、ディスプレイやプリンタ、外部ファイルなどの出力装置3、本発明のデータ管理プログラム6や管理データを保存する記憶装置5、データ管理プログラム6の実行・記憶領域であるメインメモリ5を備えている。
【0094】
メッシュデータ記憶手段7は、多次元空間を複数のメッシュに階層的に分割し、分割された各階層のメッシュを木構造の各ノードに対応させ、各メッシュと各ノードとの対応関係を記憶する。すなわち、分割された各メッシュに前記多次元データに関する情報を登録する。前記多次元データ記憶手段8は、管理対象となる複数の多次元データを多次元空間内に配置し、各多次元データの値を多次元空間内における座標として登録する。
【0095】
これら各記憶手段によってファイル装置あるいはメインメモリのデータ格納領域に記録される各データの一例を図2乃至図4に示す。なお、データ格納領域は、アクセスが早いものが望ましく、コンピュータのメインメモリ上に確保することが非常に好ましい。また、前記「4分木管理領域」には、4分木のノードに対応するメッシュ番号が付されており、そのノードが末端メッシュの場合には、メッシュデータを格納している領域を指すポインタが記されている。
【0096】
このデータ格納領域は、一例として図2に示すように、パラメータ格納領域、図形キー管理、4分木管理構造、メッシュデータおよび図形データの格納領域などから構成されている。前記パラメータ格納領域に格納されるパラメータとしては、世界座標範囲、各メッシュに登録する最大の図形数、4分木を分割する際の最大分割レベル数、メッシュの分割・合併の条件を定める各種の値(メッシュ分割する図形数、メッシュ合併する図形数など)、図形に種類がある時その内容、4分木が複数ある場合その判別、データサイズ、空き領域の先頭などが格納されている。
【0097】
メッシュデータは、一例として図3に示すように、所属図形数、最大図形数(所属図形数がこの数より大きくなったら、そのメッシュは4分割される)、所属図形リストを備えており、この所属図形リストに、所属する図形のデータの前記データ格納領域上における格納領域を示すポインタを登録する。なお、本実施形態においては、末端メッシュでないメッシュは、前記所属図形リストは持たないものとする。
【0098】
さらに、サブ図形の組合わせで構成される図形データの場合には、図4に示したように、サブ図形単位でメッシュに所属させることにより、サブ図形を分けて別個の図形データとして格納するよりもデータ領域を節約できる。また、一つにまとまった図形はまとめた方が人間の感覚に合致するし、画面への表示は大きくまとまっている方が速いというメリットもある。
【0099】
データ管理プログラム6は、木構造管理手段9、多次元データ登録削除手段10、メッシュデータ登録削除手段11、メッシュ分割手段12、分割判定手段13、メッシュ併合手段14および併合判定手段15を備えている。
【0100】
木構造管理手段9は、前記多次元空間を複数のメッシュに階層的に分割し、分割された各階層のメッシュを木構造の各ノードに対応させ、各メッシュと各ノードとの対応関係を管理する。この木構造管理手段9においては、世界座標範囲の中のメッシュを4分木のノードと対応させ、そのノードから対応するメッシュに関するデータが格納されているデータ領域を指す。第1実施形態では、4分木ノードとメッシュの対応付けは、メッシュの番号と4分木のノードの番号を同一にすることにより実現している。例えば、あるメッシュの4分割後の4つのメッシュの番号を、分割前のメッシュの番号の4倍プラス0,1,2,3,とし、左下、左上、右下、右上の順に番号を付けることとする。これにより、メッシュの親子関係が簡単に分かり、また、メッシュの番号から計算によりメッシュの座標が求まり、分割レベルも求まる。
【0101】
また、木構造管理手段9は、4分木から検索対象メッシュが末端メッシュ(4分木の葉ノード)であるか否かを判定し、検索対象メッシュがカバーする範囲(左下と右上の座標)を指示し、検索対象メッシュの分割レベルを示す。この場合、全図形データに「図形キー」と呼ばれるユニークな図形ID番号を付し、その図形キーに基づいて全図形を管理し、図形キーが与えられると該当図形のデータ格納場所を検索することができる。また、図形データを格納するデータ領域を、図形データの大きさに合わせて確保する。さらに、図形データの座標とメッシュの座標を使って、検索対象図形が検索対象メッシュに入っているか否かを判定する。
【0102】
多次元データ登録削除手段10は、前記多次元データ記憶手段8に多次元データを登録・削除する。メッシュデータ登録削除手段11は、メッシュデータ記憶手段7に作用して、前記各メッシュのうち、少なくとも前記木構造の末端のノードに対応する末端メッシュに、その末端メッシュに対応する前記多次元データに関する情報を登録または削除する。
【0103】
これらの各手段により、本発明では、前記各メッシュデータ記憶手段に登録された情報に基づいて前記多次元データ記憶手段に蓄積されている多次元データを管理する。
【0104】
本発明においては、前記のような構成を有する多次元データ管理装置において、次の構成を備えたことを特徴とする。まず、メッシュ分割手段12は、前記末端メッシュに登録できる多次元データ数を一定値以下に設定し、末端メッシュに登録する多次元データ数が前記設定値を超えた場合にその末端メッシュを分割する。分割判定手段13は、このメッシュ分割手段による末端メッシュの分割処理に当たり、予め設定された分割許容条件にしたがって分割の可否を判定する。メッシュ併合手段14は、前記末端メッシュの親メッシュに登録できる多次元データ数を一定値以下に設定し、前記親メッシュに所属する多次元データ数が前記設定値未満の場合に、その末端メッシュの併合を試行する。併合判定手段15は、前記末端メッシュをその兄弟メッシュと共に親メッシュに併合するステップの試行に当たり、予め設定された併合許容条件にしたがって併合の可否を判定する。
【0105】
具体的には、前記分割判定手段13としては、
(a)分割後の子メッシュに所属する多次元データ数の和と、分割前の親メッシュに所属する多次元データ数とを比較して、分割の可否を判定するもの、
(b)親メッシュに所属する多次元データ数と、前記親メッシュから分割された子メッシュの中の複数の子メッシュに所属する多次元データ数とを比較して、分割の可否を判定するもの、
が使用できる。
【0106】
前記併合判定手段15としては、
(a)併合前の各子メッシュに所属する多次元データ数の和と、併合後の親メッシュに所属する多次元データ数とを比較して、併合の可否を判定するもの、
(b)併合後の親メッシュに所属する多次元データ数と、これら子メッシュの中の複数の子メッシュに所属する多次元データ数とを比較して、併合の可否を判定するもの、
(c)前記末端メッシュに登録できる多次元データ数を一定値以下に設定し、親メッシュを同じくする各末端メッシュに登録された多次元データ数がいずれも前記設定値未満の場合に、その末端メッシュの併合を実行するもの、
が使用できる。
【0107】
[3−2.第1実施形態の作用]
以下前記のような構成を有する第1実施形態の多次元データ管理装置の作用並びに、これに対応する多次元データ管理方法について、図5乃至図7の木構造とメッシュとの関係、図8のスタックの機能、図9乃至図15のフローチャートに従って説明する。
【0108】
[3−2−1.データ領域への図形の登録処理]
データ領域に新たな図形を登録する処理は、図9に示したフローチャートにしたがって実行される。以下、各ステップごとに説明する。
【0109】
(ステップ901)
登録する図形データに合ったデータ領域を確保する。
【0110】
(ステップ902)
データ領域が確保できたか否かが判断され、データ領域が確保できた場合には、次のステップに進み、データ領域が確保できない場合には、データ領域への図形の登録はできず、この処理は終了する。
【0111】
(ステップ903)
ステップ902でデータ領域が確保できた場合には、図形データを確保したデータ領域にコピーする。
【0112】
(ステップ904)
図形キー管理エリアにその図形を加える。
【0113】
(ステップ905)
図形キー管理エリアに図形を加えることができたか否かが判断され、加えることができた場合には、次のステップ906に進み、一方、加えることができない場合には、ステップ909に進む。
【0114】
(ステップ906)
図形キー管理エリアに図形を加えることができた場合には、その図形をメッシュに登録する。
【0115】
(ステップ907)
図形をメッシュに登録できたが否かが判断され、登録できた場合には、データ領域への図形の登録は完了する。一方、登録できなかった場合には、次のステップに進む。
【0116】
(ステップ908)
登録処理の過程で変化したメッシュを元に戻して、図形データを削除し、この処理を終了する。
【0117】
(ステップ909)
ステップ905で図形キー管理エリアに図形を加えることができなかった場合には、ステップ903においてデータ領域にコピーした図形データを消し、データ領域への図形の登録処理を終了する。
【0118】
ここで、「登録処理の過程で変化したメッシュ」とは、例えば、そのメッシュに所属する図形の数が増えた結果、4分割されたメッシュ等をいう。したがって、本処理によって、結果的に図形の登録ができなかった場合には、すべてのデータは元の状態に戻される。
【0119】
なお、図9に示したフローチャートの内、ステップ906の「図形をメッシュに登録する処理」、及びステップ908の「図形をデータ領域から削除する処理」については、後述する。
【0120】
[3−2−2.メッシュデータへの図形の登録処理]
全世界を再帰的に分割したメッシュに新たな図形を登録する処理は、図10に示したフローチャートにしたがって実行される。本実施例では図形を末端メッシュにのみ登録する。以下、各ステップごとに説明する。
【0121】
(ステップ1001)
メッシュスタックを空にする。
【0122】
(ステップ1002)
メッシュスタックに世界全体(全世界1)をメッシュとして入れる。
【0123】
(ステップ1003)
メッシュスタックが空か否かを判断し、空の場合には本処理を終了する。一方、空でない場合には次のステップに進む。なお、ここでは、前ステップにおいて、全世界1が入っているので次のステップに進む。
【0124】
(ステップ1004)
メッシュスタックからメッシュを一つ取り出し、現メッシュとする。すなわち、ここでは全世界1が取り出される。
【0125】
(ステップ1005)
現メッシュと図形が重なっているか否かを判断し、重なっていない場合にはステップ1003に戻る。一方、重なっている場合には次のステップに進む。ここでは、全世界1は登録すべき図形aと重なっているので、次のステップに進む。
【0126】
(ステップ1006)
現メッシュの所属図形数を増やす。ここでは、全世界1のメッシュデータの所属図形数を、図形aの分として1つ増やす。
【0127】
(ステップ1007)
現メッシュが末端のメッシュであるか否かが判断され、末端メッシュである場合には、ステップ1009に進む。一方、末端メッシュでない場合には、ステップ1008に進む。ここで、全世界1がすでに4〜7のメッシュに分割されており、4〜7が末端メッシュであるとすると、現メッシュである全世界1は末端メッシュではないので、ステップ1008へ進む。
【0128】
(ステップ1008)
現メッシュを4分割した4つのメッシュをメッシュスタックに入れ、ステップ1004へ戻る。すなわち、ここでは、全世界1を4分割した4〜7のメッシュをメッシュスタックに入れ、ステップ1004へ戻る。そして、ステップ1004において、メッシュスタックからメッシュを順に一つずつ取り出して現メッシュとし、上記ステップ1005〜ステップ1007の処理を各メッシュについて行う。この例では、メッシュスタックからメッシュ7を取り出し、現メッシュとしてステップ1005へ進む。このメッシュ7は、図5に示したように、登録する図形aと重なっているので、ステップ1006及びステップ1007に進み、ステップ1007でメッシュ7は末端メッシュであると判断され、ステップ1009に進む。
【0129】
(ステップ1009)
現メッシュの所属図形リストに登録する図形を加える。
【0130】
(ステップ1010)
現メッシュについて、後述する「メッシュの分割処理」がなされ、ステップ1003へ戻る。この例では、他のメッシュ6、5、4は、いずれも図形aと重ならないので、ステップ1003〜ステップ1005を順次繰り返し、すべての末端メッシュのチェックが終了すると、ステップ1003でメッシュスタックが空になるので、本処理を終了する。結局、末端メッシュ7に図形aが登録される。
【0131】
なお、後述する「メッシュの分割処理」において、現メッシュが4分割されると、現メッシュは親メッシュになるので、前記ステップ1009でメッシュ7の所属図形リストに加えた図形aは、メッシュ7の所属図形リストから削除される。
【0132】
[3−2−3.データ領域からの図形の削除処理]
データ領域から所定の図形を削除する処理は、図11に示したフローチャートにしたがって実行される。以下、各ステップごとに説明する。
【0133】
(ステップ1101)
後述する「図形をメッシュから削除する処理」がなされる。
【0134】
(ステップ1102)
図形キー管理エリアから該当図形を除く。
【0135】
(ステップ1103)
図形データ格納場所にあるデータを消去して、本処理を終了する。
【0136】
[3−2−4.メッシュからの図形の削除処理]
メッシュから所定の図形を削除する処理は、図12に示したフローチャートにしたがって実行される。以下、各ステップごとに説明する。
【0137】
(ステップ1201)
メッシュスタックを空にする。
【0138】
(ステップ1201)
メッシュスタックに世界全体(全世界1)をメッシュとして入れる。
【0139】
(ステップ1203)
メッシュスタックが空か否かを判断し、空の場合には本処理を終了する。一方、空でない場合には次のステップに進む。なお、ここでは、前ステップにおいて、全世界1が入っているので次のステップに進む。
【0140】
(ステップ1204)メッシュスタックからメッシュを一つ取り出し、現メッシュとする。すなわち、ここでは全世界1が取り出される。
【0141】
(ステップ1205)
現メッシュと図形が重なっているか否かを判断し、重なっていない場合にはステップ1203に戻る。一方、重なっている場合には次のステップに進む。ここでは、全世界1は登録すべき図形aと重なっているので、次のステップに進む。
【0142】
(ステップ1206)
現メッシュの所属図形数を減らす。ここでは、全世界1のメッシュデータの所属図形数を、図形aの分として1つ減らす。
【0143】
(ステップ1207)
現メッシュが末端のメッシュであるか否かが判断され、末端メッシュである場合には、ステップ1209に進む。一方、末端メッシュでない場合には、ステップ1208に進む。ここで、全世界1がすでに4〜7のメッシュに分割されており、4〜7が末端メッシュであるとすると、現メッシュである全世界1は末端メッシュではないので、ステップ1208へ進む。
【0144】
(ステップ1208)
現メッシュを4分割した4つのメッシュをメッシュスタックに入れ、ステップ1204へ戻る。すなわち、ここでは、全世界1を4分割した4〜7のメッシュをメッシュスタックに入れ、ステップ1204へ戻る。そして、ステップ1204において、メッシュスタックからメッシュを順に一つずつ取り出して現メッシュとし、上記ステップ1205〜ステップ1207の処理を各メッシュについて行う。この例では、メッシュスタックからメッシュ7を取り出し、現メッシュとしてステップ1205へ進む。このメッシュ7は、図5に示したように、削除する図形aと重なっているので、ステップ1206及びステップ1207に進み、ステップ1207でメッシュ7は末端メッシュであると判断され、ステップ1209に進む。
【0145】
(ステップ1209)
現メッシュの所属図形リストから図形を削除する。
【0146】
(ステップ1210)
現メッシュについて、後述する「メッシュの併合処理」がなされ、ステップ1203へ戻る。この例では、他のメッシュ6、5、4は、いずれも図形aと重ならないので、ステップ1203〜ステップ1205を順次繰り返し、すべての末端メッシュのチェックが終了すると、ステップ1203でメッシュスタックが空になるので、本処理を終了する。結局、末端メッシュ7から図形aが削除される。
【0147】
なお、後述する「メッシュの併合処理」において、現メッシュが併合されると、親メッシュ(全世界1)が現メッシュになるので、前記ステップ1209でメッシュ7の所属図形リストから削除された図形aは、親メッシュ1からも削除され、親メッシュの所属図形数が一つ減少する。
【0148】
[3−2−5.データ領域における図形データの修正処理]
データ領域に記憶された図形データを修正する処理は、図13に示したフローチャートにしたがって実行される。なお、修正の前後で、図形を同定する図形キーは不変である。以下、各ステップごとに説明する。
【0149】
(ステップ1301)
旧図形データを図形キーから検索する。
【0150】
(ステップ1302)
修正後の新図形データのためのデータ領域を確保する。
【0151】
(ステップ1303)
データ領域が確保できたか否かが判断され、データ領域が確保できた場合には、次のステップに進む。一方、データ領域が確保できない場合には、データ領域への新図形の登録はできず、この処理は終了する。
【0152】
(ステップ1304)
新図形データを確保したデータ領域にコピーする。
【0153】
(ステップ1305)
図形キー管理エリアに登録されている旧図形データへのポインタと新図形データへのポインタを置き換える。
【0154】
(ステップ1306)
新図形をメッシュに登録する。
【0155】
(ステップ1307)
新図形をメッシュに登録できたか否かが判断され、登録できた場合にはステップ1308へ進み、登録できなかった場合には、ステップ1310へ進む。
【0156】
(ステップ1308)
旧図形をメッシュから削除する。
【0157】
(ステップ1309)
図形データ格納場所にある旧図形データを消去して、本処理を終了する。
【0158】
(ステップ1310)
前記ステップ1307において、新図形をメッシュに登録できなかった場合には、登録処理の過程で変化したメッシュを元に戻して、新図形データを削除する。
【0159】
(ステップ1311)
図形キー管理エリアにおいて置き換えた新図形データへのポインタを旧図形データへのポインタに戻し、本処理を終了する。すなわち、本処理によって、結果的に修正後の新図形の登録ができなかった場合には、すべてのデータは元の状態に戻される。
【0160】
[3−2−6.メッシュの分割処理]
末端のメッシュに登録された図形数が一定数を越えた場合に行われるメッシュの分割処理は、図14に示したフローチャートにしたがって実行される。以下、各ステップごとに説明する。
【0161】
(ステップ1401)
分割メッシュスタックを空にする。
【0162】
(ステップ1402)
分割メッシュスタックに現メッシュを入れる。
【0163】
(ステップ1403)
分割メッシュスタックからメッシュを一つ取り出し、親メッシュとする。
【0164】
(ステップ1404)
別途説明した所定の分割条件に照らして、親メッシュを分割して良いか否かが判断され、分割して良い場合には次のステップ1405に進む。一方、分割すべきでない場合には、ステップ1417に進み、分割メッシュスタックが空か否かが判断され、空の場合には本処理は終了し、空でない場合にはステップ1403へ戻る。
【0165】
(ステップ1405)
前記ステップ1404において、親メッシュを分割して良いと判断された場合には、そのメッシュを4分割する。
【0166】
(ステップ1406)
4分割された各子メッシュについてメッシュデータ領域を確保する。
【0167】
(ステップ1407)
すべての子メッシュについて、メッシュデータ領域が確保されたか否かが判断され、確保された場合には次のステップに進み、一方、4つのメッシュの内、いずれか一つでもメッシュデータ領域が確保されない場合には、ステップ1409に進む。
【0168】
(ステップ1408)
4分割されたすべてのメッシュについてメッシュデータ領域が確保された場合には、親メッシュに登録されている図形の内から一つの図形を選択する。
【0169】
(ステップ1409)
ステップ1407において、4つのメッシュの内、いずれか一つでもメッシュデータ領域が確保されない場合には、メッシュの4分割処理はできないので、確保されたメッシュデータ領域を元に戻し、本処理を終了する。
【0170】
(ステップ1410)
4分割されたメッシュから一つの子メッシュを選択する。
【0171】
(ステップ1411)
ステップ1408において選択された図形が、その子メッシュに重なるか否かが判断され、重なる場合にはステップ1412に進み、重ならない場合にはステップ1413に進む。
【0172】
(ステップ1412)
ステップ1411において図形がその子メッシュに重なると判断された場合には、その図形をその子メッシュに登録する。具体的には、子メッシュの所属図形数を増やし、所属図形リストに図形を加える。
【0173】
(ステップ1413)
ステップ1411において図形がその子メッシュに重ならないと判断された場合には、上記ステップ1407及びステップ1412の処理がすべての子メッシュについてなされたか否かが判断され、まだなされていない場合にはステップ1410に戻り、一方、すべての子メッシュについて終了している場合には、次のステップに進む。
【0174】
(ステップ1414)
親メッシュに登録されていたすべての図形について、ステップ1410〜ステップ1413の処理がなされたか否かが判断され、まだなされていない場合にはステップ1408に戻り、一方、すべての図形について終了している場合には、次のステップに進む。
【0175】
(ステップ1415)
上記のようにして、親メッシュに登録されていたすべての図形について処理が終了した後、親メッシュの所属図形リストのデータ領域を消去する。
【0176】
(ステップ1416)
4つの子メッシュを分割メッシュスタックに入れ、ステップ1403に戻る。
【0177】
[3−2−7.メッシュの併合処理]
末端のメッシュに登録された図形数が一定数以下になった場合に行われるメッシュの併合処理は、図15に示したフローチャートにしたがって実行される。以下、各ステップごとに説明する。
【0178】
(ステップ1501)
現メッシュの親のメッシュを「親メッシュ」、現メッシュを含む親メッシュの4つの子メッシュを「子メッシュ」(4個)とする。
【0179】
(ステップ1502)
別途説明した所定の併合条件に照らして、4つの子メッシュを親メッシュに併合して良いか否かが判断され、併合して良い場合には次のステップ1503に進む。一方、併合すべきでない場合には本処理は終了する。
【0180】
(ステップ1503)
前記ステップ1502で親メッシュに併合して良いと判断された場合には、親メッシュにメッシュデータ領域を割り当てる。
【0181】
(ステップ1504)
子メッシュの一つを選択する。
【0182】
(ステップ1505)子メッシュの所属図形リストから図形を一つ選ぶ。
【0183】
(ステップ1506)
親メッシュの所属図形リストに、その図形がすでに含まれているか否かが判断され、含まれていない場合には次のステップに進み、一方、すでに含まれている場合には、ステップ1508に進む。
【0184】
(ステップ1507)
親メッシュの所属図形リストに図形を加える。
【0185】
(ステップ1508)
子メッシュに所属するすべての図形を処理したか否かが判断され、未処理の図形がある場合にはステップ1505へ戻り、すべての図形について処理が終了している場合には、次のステップに進む。
【0186】
(ステップ1509)
4つの子メッシュのすべてを処理したか否かが判断され、未処理の子メッシュがある場合にはステップ1504へ戻り、すべての子メッシュについて処理が終了している場合には、次のステップに進む。
【0187】
(ステップ1510)
親メッシュを現メッシュとし、ステップ1501へ戻る。
【0188】
[3−3.第1実施形態の効果]
前記の様な構成を有する第1実施形態は、次のような効果を有する。すなわち、固定メッシュからデータ密度によってメッシュを分割し、その大きさを変えるので、無駄なデータ領域が減り、主記憶装置上でデータを扱うことができる。また、4分木で分割を管理するので、メッシュへのアクセスがスムーズに実行でき、階層を下る検索により、無駄な条件判断を減らすことができる。さらに、データの股がりによって、末端メッシュだけでなく内メッシュにもデータを入れることができるので、メッシュ1つ当りのデータ数が減り、無駄なデータ領域を減らすことができる。
【0189】
また、メッシュの分割を無制限に進めると指数オーダーでデータ領域を消費するので、分割レベルの限界を設けることにより、有限なデータ領域を節約することができる。また、1メッシュ当りのデータ数が少ないときは、メッシュの分割を解消してメッシュを合併するので、データ密度に応じた分割レベルを保つことができる。さらに、メッシュの分割を解消した結果、使わなくなったデータ領域を再利用することができる。また、サブ図形の組合わせで構成される図形データの場合に、サブ図形単位でメッシュに所属させることとしたため、データ領域をさらに節約することができる。
【0190】
このように本実施形態の多次元データ管理装置によれば、データ領域を大幅に節約することができるので、計算機の主記憶上でデータを扱うことができ、高速なデータアクセスが可能となる。
【0191】
[3−4.第1実施形態の変形例]
第1実施形態では図1に示すように、メッシュ分割手段12と分割反対手段13、およびメッシュ併合手段14と併合判定手段15の両方を設けたが、いずれか一方の組み合わせのみを設けても良い。
【0192】
[4.第2実施形態]
第2実施形態は、前記第1実施形態と同様に4分木ノード、メッシュ状態データ、図形検索キーデータ、図形データを記憶領域上に配置し、利用する。第1実施形態と異なるのは、末端メッシュでない被分割メッシュの状態データにも所属図形リストを含める点である。すなわち、4分木構造において被分割メッシュに対応する中間ノードについても図形データを登録することにより、末端メッシュに登録された図形だけでなく、被分割メッシュに登録された図形をも検索対象とするものである。また、被分割メッシュにも図形を登録する手法としては、末端メッシュを分割する際に子メッシュに登録するのが適切でない図形を親メッシュに残すようにしたものである。
【0193】
このような第2実施形態においては、前記第1実施形態における図形のメッシュへの登録、メッシュの4分割、図形のメッシュからの削除、およびメッシュの併合の手法が次のように変更される。
【0194】
第2実施形態では、被分割メッシュの状態データにも所属図形リストを含めるが、そのリストに実際に図形が登録されている状態は、次のようなメッシュ分割フローの処理によって作り出される。前記第1実施形態とは異なるこの分割処理の特徴は、図形の所属を親メッシュから子メッシュに移す際に、親メッシュに所属するすべての図形を無条件に移すのではなく、所定の条件に照らして子メッシュに移すのが適切と判断された図形のみを移し、適切でないと判断された図形については親メッシュに所属させたままにしておく点である(図16、図5及び図6を参照)。
【0195】
ここで、「所定の条件(図形の登録先変更条件)に照らして図形を子メッシュに移して良いか?」という判定に係る所定の条件とは、無条件に子メッシュに移した場合に比較して1つの図形あたりの複数メッシュへの重複登録を抑制するような条件であり、例えば次のようなものである。なお、これらの条件は単独で用いても良いし、複数を併用しても良い。
【0196】
(a)図形がその親メッシュを完全に含んでいない。
【0197】
(b)図形が重なっている子メッシュが2つ以下である。
【0198】
(c)図形ごとに重複登録メッシュ数の上限が定められており、子メッシュへの登録(移動)を行っても重複登録数が上限以下である。
【0199】
(d)図形の種類・大きさなどの属性によって登録して良い最小のメッシュの大きさが定められており、子メッシュの大きさがその最小メッシュの大きさ以上である。
【0200】
これらの条件によって、メッシュ分割における図形の登録メッシュの増加が抑制されると共に、子メッシュに登録を変更する図形の数が減少するため、分割処理自体も高速化される。例えば、図形の面積(大きさ)・形状に応じて予め登録すべき最小のメッシュを決めておき、条件(d)を採用して判定を行いつつ図形の登録を進めれば、メッシュの分割が進んでも1つの図形はその図形の面積(大きさ)に比例する数以下の、その図形に予め定められた最小のメッシュ以上に大きさのメッシュにのみ登録される。これによって、過剰な重複登録を抑制して記憶領域を節約すると共に、検索処理の速度の低下を防止することができる。
【0201】
例えば、矩形の形状の図形に関しては、メッシュの短辺がその図形の短辺より長い最も小さなメッシュを、その図形を登録して良い最小のメッシュとして設定するという方法がある。この方法に従えば、細長い矩形は長手方向に小さな多数のメッシュに所属するので、検索時にそのメッシュが選択された場合に最終的な検索結果として選ばれる割合が高まって検索効率が向上する。いたずらに上位の大きなメッシュに属させておけば、メッシュが選ばれる割合が大きい反面その図形が最終的な検索結果として選ばれる割合が減少し、検索効率の悪化を招く。この方法では、予測可能な範囲である程度多数のメッシュに重複登録されるが、無制限に著しく記憶領域を浪費することはなく、検索効率が劣化することはない。縦横の長さが極端に違わない矩形に関しては、最も重複が多くなっても数個のメッシュに所属するだけで済む。この方法を採用した場合の長所は、検索において所属メッシュが選択された場合に、最終的な検索結果としてその図形が採用される割合を細長い矩形とそうでない矩形で極端に違わないようにする効果が得られることである。
【0202】
細長い図形の場合と類似の効果は、線分を扱う場合にも得られる。例えば、メッシュの短辺が線分の長さのn分の1以上である最小のメッシュをその線分を登録して良い最小のメッシュとする方法が考えられる。その線分は、多くとも4n個よりは少ない数のメッシュに重複登録されるに過ぎない。
【0203】
(c)を採用した場合、1つの図形について重複登録メッシュ数が制限されるので、記憶領域の節約には非常に有効である。しかも、所属メッシュの大きさにはばらつきがあっても良いから、重複登録数の上限以下であれば、図形の密度に応じて分割されていくので、さらに細かなメッシュへの登録を進めることができ、検索効率の向上を図ることができる。
【0204】
[4−1.第2実施形態の構成]
図17は、本発明の第2実施形態の構成を示す機能ブロック図である。すなわち、本実施形態の多次元データ検索装置は、第1実施形態に示した多次元データ管理装置の構成要素に加えて、前記メッシュデータ登録削除手段11およびメッシュ分割手段12に関連して、メッシュデータ再登録手段16と再登録メッシュ判定手段17が設けられていることを特徴とする。このメッシュデータ再登録手段16は、末端メッシュの分割時において、前記各メッシュのうち、前記木構造の末端のノードに対応する分割によって生じた子メッシュと、前記末端ノードの親ノードに対応する分割によって生じた親メッシュいずれかに多次元データを登録しなおすものである。また、再登録メッシュ判定手段17は、末端メッシュの分割時において、1つの図形あたりの複数メッシュへの重複登録を抑制する条件に従って、前記多次元データを分割によって生じた子メッシュと分割によって生じた親メッシュのいずれに登録しなおすかを判定する。
【0205】
前記再登録メッシュ判定手段17としては、
(a)前記多次元データがその親メッシュを完全に含んでいないことを重複登録を抑制する条件とするもの、
(b)前記多次元データが重なっている子メッシュ数が予め設定された数以下であることを重複登録を抑制する条件とするもの、
(c)前記多次元データごとに重複メッシュ数の上限が定められており、子メッシュへの登録を行っても重複登録数が上限以下であることを重複登録を抑制する条件とするものが使用される。
【0206】
[4−2.第2実施形態の作用]
以下前記のような構成を有する第2実施形態の多次元データ管理装置の作用並びに、これに対応する多次元データ管理方法について、図16〜17の木構造とメッシュとの関係を示す図、および図18のフローチャートにしたがって、中間ノードに図形データを登録する第1の方法について説明する。
なお、この中間ノードに図形データを登録する第1の方法は、第1実施形態において説明した「末端メッシュの分割処理」において、子メッシュに登録するのが適切でない図形を、中間ノードに相当する親メッシュに残すようにするものである。また、図18に示したフローチャートは、図14に示した[メッシュの分割処理]フローに一部の処理(ステップ1818)を追加したものなので、この変更部分について説明する。
【0207】
(ステップ1818)
図18に示したように、ステップ1808において、親メッシュに登録されている図形の内から選択された一つの図形について、別途説明した図形の登録先変更条件に照らして、図形を子メッシュに移して良いか否かが判断され、子メッシュに移して良い場合には、ステップ1810に進む。その結果、ステップ1810〜ステップ1812の処理によって、図形が子メッシュに登録される。一方、ステップ1818において、図形を子メッシュに移すことは適切でないと判断された場合には、ステップ1814に進む。その結果、その図形は子メッシュには登録されず、親メッシュに登録されたままの状態に保持される。そして、ステップ1814において、親メッシュに所属するすべての図形について、ステップ1818、ステップ1810〜ステップ1813の処理がなされたか否かが判断される。
【0208】
[4−3.第2実施形態の変形例]
第2実施形態では、図17に示すように、メッシュ分割手段12と分割反対手段13、およびメッシュ併合手段14と併合判定手段15を設けたが、これらの一方の組のみを設けても良いし、両者を省くこともできる。
【0209】
[5.第3実施形態]
第3実施形態は、前記第2実施形態と同様に被分割メッシュにも図形を登録するものであるが、末端メッシュの分割時ではなく、図形の登録時に適切なメッシュを選んで登録するものである。すなわち、第3実施形態では、被分割メッシュの状態データにも所属図形リストを含めるが、第2実施形態とは異なって、その状態は図形の登録処理の過程によって直接に作成され、分割という付随処理の結果生じるものではない。
【0210】
なお、この第3実施形態においては、メッシュ分割処理は再帰的でなくても良く、親メッシュからの登録図形の移動を伴わない形で、単に4つの子メッシュを作成し、子メッシュの所属図形リストは空のままにしておくという形でも実施できる。もちろん、第2実施形態のように所定の条件を吟味した上で分割し、さらに所定の条件を満たす図形を子メッシュに移しても良い。
【0211】
ところで、この第3実施形態において、「所定の条件(図形の登録先変更条件)に照らして現メッシュに図形を登録して良いか?」という判定に係る「所定の条件」とは、例えば次のようなものである(図19及び図20参照)。
(a)図形が重なり合っている現メッシュの子メッシュが3個以上である。
(b)図形の種類、大きさなどの属性によって登録して良い最小のメッシュの大きさが決まっており、現メッシュの子メッシュの大きさがその最小のメッシュ未満である。
(c)図形の種類、大きさなどの属性によって登録して良い最大のメッシュの大きさが決まっており、現メッシュの親メッシュの大きさがその最大のメッシュを越えている。
(d)図形ごとに重複登録メッシュ数の上限が定められており、子メッシュへの登録を行うと重複登録数の上限を越えてしまう。
(e)図形の面積が現メッシュのα%を占める。面積のない線分などの場合には、現メッシュの中心からの距離がメッシュの短辺の1/2の長さのβ%以内である。
【0212】
これらの条件は単独で用いても良いし、複数を併用してそのすべてが成立したら条件を満足したものと判定しても良い。また、複数を併用していずれか1つが成立したら条件を満足したものとしても良い。
【0213】
例えば、(a)と(e)を併用して両方が成立したら条件を満足するとして使用した際に、αが例えば10%というような値に設定されているとすれば、図19に示したように、すべての子メッシュ2−4に重なっているが、現メッシュ1に比較して大きさが非常に小さい図形F1は(e)の条件を満たさないために現メッシュよりもさらに小さなメッシュに所属するように促される。一方、図20に示したように、メッシュに比較してある程度大きい面積の図形F2、すなわち図形の面積は現メッシュの10%以上あるが、現メッシュの周辺に存在する図形F2は(a)の条件を満たさないためにさらに小さなメッシュに所属するように促される。
【0214】
このようにして、メッシュの中心を含みかつメッシュ中のある程度の面積を占めるような状況でのみ図形がメッシュに登録されるので、後述する最近傍図形検索手続きにおいて、図形を探索する範囲が狭められて検索が効率化されるという効果が得られる。
【0215】
また、(b)の条件を図形ごとに適切に設定することにより、図形がその大きさに比較してあまりに大きなメッシュに所属して検索効率を低下させることを防ぐことができる。さらには、(c)の条件を図形ごとに適切に設定することにより、図形がその大きさに比較してあまりに小さな多数のメッシュに重複登録されることを避け、検索の効率化および記憶領域の節約を図ることができる。
【0216】
なお、(b)および(e)の条件は、図形の属性によって一方的に決まる場合ばかりでなく、現メッシュの所属図形数などのメッシュ側の状況を吟味して判定するなど、より柔軟かつ多様な変形例が種々考えられる。
【0217】
上述のように、第3実施形態は、前記登録に係る所定の条件として図形の属性に応じた条件を設定することによって、図形のメッシュへの重複登録を制限あるいは抑制する効果を得ると共に、検索手続きの効率化を図ることを可能にするものである。
【0218】
1つの木構造に対応させたデータ管理方法及び装置において、木構造を構成する各ノード部分に種々の図形を登録する際に、同一の手続きによって図形ごとやその種類ごとに異なる条件を採用することを特徴とするものであり、これによって、従来技術のquad−tree法やその変形例のように、中間ノードに図形を登録させる場合にどの図形であっても画一的な分割手法を使用していたものに比較して、より優れた記憶領域の有効利用と検索処理の高速化が可能になる。
【0219】
[5−1.第3実施形態の構成]
図21は、本発明の第3実施形態の構成を示す機能ブロック図である。すなわち、本実施形態の多次元データ検索装置は、第1実施形態に示した多次元データ管理装置の構成要素に加えて、前記メッシュデータ登録削除手段11およびメッシュ分割手段12に関連して、末端あるいは中間メッシュへのデータ登録手段18と登録位置判定手段19を備えていることを特徴とする。データ登録手段18は、前記各メッシュのうち、前記木構造の末端のノードに対応する末端メッシュと、前記末端ノードの親ノードに対応する中間メッシュの少なくとも一方に多次元データを登録する。登録位置判定手段19は、多次元データの登録時において、登録する多次元データの状態に従って、前記多次元データを末端メッシュと中間メッシュのどこに登録するかを判定する。
【0220】
前記登録位置判定手段19としては、
(a)前記多次元データが重なり合っている子メッシュ数に応じて登録するメッシュを選択するもの、
(b)前記多次元データによって登録すべきメッシュの大きさの限度が決まっており、このメッシュの大きさの限度に従って前記多次元データを登録するメッシュを選択するもの、
(c)前記多次元データごとに重複登録メッシュ数の限度が定められており、この限度に従って前記多次元データを登録するメッシュを選択するもの、
(d)前記多次元空間内における前記多次元データの大きさと、前記多次元空間内における所定のメッシュの大きさとの比較から、前記多次元データを登録するメッシュを選択するもの、が使用できる。
【0221】
[5−2.第3実施形態の作用]
以下前記のような構成を有する第3実施形態の多次元データ管理装置の作用並びに、これに対応する多次元データ管理方法について、図19,20によって、その条件を説明すると共に、図22に示したフローチャートにしたがって、中間ノードに図形データを登録する第2の方法について説明する。なお、この中間ノードに図形データを登録する第2の方法は、第2実施形態と異なり、図形の登録時に適切なメッシュを選んで登録するものである。以下、各ステップごとに説明する。
【0222】
(ステップ2201)
メッシュスタックを空にする。
【0223】
(ステップ2202)
メッシュスタックに世界全体(全世界1)をメッシュとして入れる。
【0224】
(ステップ2203)
メッシュスタックからメッシュを一つ取り出し、現メッシュとする。
【0225】
(ステップ2204)
現メッシュと図形が重なっているか否かを判断し、重なっていない場合にはステップ2203に戻る。一方、重なっている場合には次のステップに進む。
【0226】
(ステップ2205)
現メッシュの所属図形数を増やす。
【0227】
(ステップ2206)
後述する図形の登録先変更条件に照らして、現メッシュに図形を登録して良いか否かが判断され、登録して良い場合には、次のステップ2207に進む。一方、現メッシュに図形を登録することが適切でないと判断された場合には、ステップ2209に進む。
【0228】
(ステップ2207)
現メッシュの所属図形リストに図形を加える。
【0229】
(ステップ2208)
メッシュスタックが空か否かを判断し、空の場合には本処理を終了する。一方、空でない場合にはステップ2203に戻る。
【0230】
(ステップ2209)
ステップ2206において、現メッシュに図形を登録することが適切でないと判断された場合には、現メッシュが末端のメッシュであるか否かが判断され、末端メッシュである場合には、ステップ2210に進む。一方、末端メッシュでない場合には、ステップ2212に進む。
【0231】
(ステップ2210)
ステップ2209において現メッシュが末端のメッシュである場合には、メッシュ分割処理によって、現メッシュの4分割を試みる。
【0232】
(ステップ2211)
現メッシュが4分割できたか否かが判断され、分割できた場合にはステップ2213に進み、分割できない場合にはステップ2207に戻る。
【0233】
(ステップ2212)
ステップ2209において現メッシュが末端のメッシュでない場合には、現メッシュを4分割する。
【0234】
(ステップ2213)
ステップ2211及びステップ2212において現メッシュを4分割した場合には、4分割したメッシュをメッシュスタックに入れ、ステップ2203へ戻る。
【0235】
[5−3.第3実施形態の変形例]
第3実施形態では、図21に示すように、メッシュ分割手段12と分割反対手段13、およびメッシュ併合手段14と併合判定手段15を設けたが、これらの一方の組のみを設けても良いし、両者を省くこともできる。
【0236】
[6.第4実施形態]
矩形検索とは、与えられた矩形の枠内にある図形を全て探し出すことをいう。具体的には、まず、世界座標範囲内の矩形とメッシュを与えたとき、矩形とメッシュの重なりの有無が判定され、矩形と重なりを有するメッシュが検索される。次に、そのメッシュに含まれる図形と矩形の領域の重なりの有無が判定され、与えられた矩形の枠内にある図形が全て検索される。
【0237】
[6−1.第4実施形態の構成]
図29は、本発明の第4実施形態の構成を示す機能ブロック図である。すなわち、本実施形態の多次元データ検索装置は、前記各実施形態に示した多次元データ管理装置の構成要素に加えて、前記コンピュータの記憶領域内に蓄積されている多次元データを管理する装置が、前記多次元空間内における指定された範囲を対象とし、この指定された範囲内に属する多次元データを検索する範囲検索手段20を含むことを特徴とする。
【0238】
この範囲検索手段20は、入力装置2から入力されたメッシュの座標と矩形の座標を使って、メッシュと矩形の領域が重なっているか否かを判定するメッシュ/矩形領域重なり判定手段201と、図形データの座標と矩形の座標を使って、図形が矩形に入っているか否かを判定する図形/矩形所属判定手段202と、データ領域上に、固定パラメータを格納したり、初期4分木(根ノードしかない4分木)を作成したり、図形キー管理領域を構成する際にデータ領域を初期化するデータ領域初期化手段203と、与えられた一点を含む末端メッシュを検索するメッシュ検索手段204とを備えている。
【0239】
この範囲検索手段20による検索結果は、前記出力装置3に出力される。すなわち、本実施形態においては、前記検索結果は、入力装置2および出力装置3において、検索を使用する側が用意したデータ領域に検索結果を書き込むことにより実現される。例えば、矩形検索の場合、矩形内にある図形のデータ格納領域の場所を指すポインタのリストを返し、また、最近傍図形検索の場合は、図形のデータ領域を指すポインタと距離と最近傍点を返すように構成されている。なお、前記メッシュ/矩形枠重なり判定手段12においては、矩形にすっぽり含まれるメッシュや矩形をすっぽり含むメッシュは、「重なっている」と言わないこととする。さらに、メッシュ検索手段16においては、与えられた一点がメッシュの境界上に乗っているときは、存在するならば右上のメッシュ、上のメッシュ、右のメッシュ、下のメッシュ、左のメッシュに含まれるとする。メッシュ/矩形領域重なり判定手段11とメッシュ/矩形枠重なり判定手段12とによって、世界座標範囲内の矩形とメッシュを与えたとき、矩形とメッシュの重なりを、次の4つの場合について判定することができる。
【0240】
すなわち、(a)メッシュが矩形を含む、(b)メッシュが矩形に含まれる、(c)メッシュと矩形の重なりがある、(d)メッシュと矩形の重なりがないの4つの場合について判定がなされる。したがって、この手段を繰り返し使うことによって、矩形と重なりのあるメッシュを全て探し出すことができる。また、前記(a)が判定できると、他のメッシュを判定する必要がなくなり、4分木で言えば、横方向に検索を広げなくて済む。さらに(b)が判定できると、そのメッシュが分割されていたとき、分割された4つのメッシュを判定する必要がなくなる。4分木で言えば、縦方向に検索を進めなくて済むというメリットがある。
【0241】
[6−2.第4実施形態の作用]
以下前記のような構成を有する第4実施形態の多次元データ管理装置の作用並びにこれに対応する多次元データ管理方法について、図23によってそ木構造を説明すると共に、図24〜28のフローチャートに従って説明する。
【0242】
[6−2−1.中間メッシュにも末端メッシュにも図形を登録する場合の矩形検索]
上記第2実施形態及び第3実施形態において説明した中間メッシュにも図形を登録する場合の矩形検索は、図25及び図26に示したフローチャートにしたがって実行される。以下、各ステップごとに説明する。
【0243】
まず、図25に示したフローチャートは、検索する矩形にかかっているすべてのメッシュを探し出す処理の流れを示したものである。
【0244】
(ステップ2501)
検索する矩形及び検索結果格納図形リストをセットする。すなわち、検索する矩形のセットは、矩形の左下と右上の座標をセットすることによりなされ、また、検索結果格納図形リストのセットは、記憶領域のポインタをセットすることによりなされる。なお、この検索する矩形と検索結果格納図形リストは、矩形検索を行なう側から与えられる。
【0245】
(ステップ2502)
探し出したメッシュリストを入れておく空のメッシュリストを用意する。
【0246】
(ステップ2503、ステップ2504)
処理すべきメッシュの順番を覚えておくためのメッシュスタックを空にして用意し、まず世界全体のメッシュ1をこのスタックに入れる。
【0247】
(ステップ2505)
スタックが空か否かが判断され、スタックが空であれば、図26に示す図形が矩形に入っているか否かの検索処理へ進む。このとき、矩形と重なりのある中間メッシュと末端メッシュのリストができている。一方、スタックが空でなければ、次のステップ2506に進む。この例では、検索を始めた直後であり世界全体のメッシュ1がスタックにあるので、ステップ2506に進む。
【0248】
(ステップ2506)
スタックから1つメッシュを取り出す。この例では、世界全体のメッシュ1が取り出され、スタックは空の状態になる。
【0249】
(ステップ2507)
取り出したメッシュが矩形と重なっているか否かを判断し、重なっていないならば、スタックが空か否かの判断ステップ2505へ戻る。一方、重なっているならば、次のステップ2508へ進む。ここでは、世界全体のメッシュ1と矩形の重なりを判断し、重なっているのでステップ2508へ進む。なお、本実施形態においては、メッシュの座標を4分木で管理し、また、メッシュ番号を規則的に付けていることから、メッシュの座標を容易に計算できるため、メッシュの座標と矩形の座標からメッシュが矩形と重なっているか否かの判断は容易である。
【0250】
(ステップ2508)
メッシュをメッシュリストに加える。ここでは、世界全体のメッシュ1だけのメッシュリストができる。
【0251】
(ステップ2509)
メッシュが末端メッシュか否かを判断し、末端メッシュならばステップ2505へ戻る。一方、末端メッシュでなければ4分割された子メッシュがあるので、それらについても調べる必要があるため、次のステップ2510へ進む。本例では、世界全体メッシュ1は末端メッシュでないので、ステップ2510に進む。なお、メッシュが末端メッシュか否かの判断は、4分木から容易に分かる。
【0252】
(ステップ2510)
メッシュを4分割した4つの子メッシュをスタックに入れ、ステップ2505に戻る。本例では、世界全体の子メッシュ7、6、5、4をスタックに入れる。スタック内は、上から7、6、5、4と並ぶ。本例では、ステップ2505での判断は、スタックは空ではないので、NOとなり、ステップ2506へ進む。
【0253】
以下、図23に示した例に基づいて、本処理をさらに詳しく説明する。
【0254】
ステップ2506においてスタックから1つ取り出す場合、末尾のメッシュ4が取り出され、スタックは7、6、5になる。ここで、図23に示したように、メッシュ4と矩形は重なっているので(ステップ2507)、メッシュリストにメッシュ4を加える(ステップ2508)。その結果、メッシュリストは1、4になる。続いて、ステップ2509において、メッシュ4は末端メッシュなのでステップ2505へ戻る。
【0255】
ステップ2505において、まだスタックは空でないので、ステップ2506でスタックから次のメッシュを1つ取り出す。ここではメッシュ5が取り出され、スタックは、7、6になる。ここで、図23に示したように、メッシュ5と矩形は重ならないので(ステップ2507)、ステップ2505に戻る。
【0256】
ステップ2505に戻ってもまだスタックは空でないので、スタックから次のメッシュを1つ取り出す。ここではメッシュ6が取り出され、スタックは7のみになる。ここで、図23に示したように、メッシュ6と矩形は重なっているので、メッシュリストにメッシュ6を加える(ステップ2508)。その結果、メッシュリストは、1、4、6になる。続いて、ステップ2509において、メッシュ6は末端メッシュでないので、ステップ2510でメッシュの6の4つの子メッシュ27、26、25、24をスタックに入れた後、ステップ2505に戻る。その結果、スタックは7、27、26、25、24になる。
【0257】
ステップ2506において、次にスタックから取り出されるのは24であるが、これは矩形と重なりがない(ステップ2507)ので、再びステップ2505に戻る。次にメッシュ25が取り出されるが、図23に示したように、このメッシュ25は矩形と重なりがある(ステップ2507)ため、メッシュ25はメッシュリストに加えられる(ステップ2508)。その結果、メッシュリストは1、4、6、25になる。また、このメッシュ25は末端メッシュなので(ステップ2509)、このままステップ2505に戻る。この時点で、スタックは7、27、26になっている。
【0258】
さらに、ステップ2506において、スタックからメッシュ26が取り出されるが、図23に示したように、このメッシュ26は矩形と重ならない(ステップ2507)。続いて、ステップ2506において、スタックからメッシュ27が取り出されるが、このメッシュ27も矩形と重ならない(ステップ2507)。この時点で、スタックは7になる。
【0259】
次に、ステップ2506において、スタックからメッシュ7を取り出すと、スタックは空になる。また、図23に示したように、このメッシュ7も矩形と重ならない(ステップ2507)。ここでステップ2505へ戻るとスタックが空なので、YESの方へ進む(すなわち、図26に示す図形が矩形に入っているか否かの検索処理へ進む)。なお、この時、メッシュリストには1、4、6、25が入っており、これが矩形にかかっている全メッシュのリストである。
【0260】
図26に示したフローチャートは、図25で挙げられたメッシュリストのメッシュを1つずつ調べて、図形が矩形に入っているか否かを検索する処理の流れを示したものである。
【0261】
(ステップ2601)
メッシュリスト内のすべてのメッシュに対して、矩形内に含まれる図形を集める処理を行ない、すべてのメッシュに対してこの処理が終わっている場合には、矩形検索は終了する。一方、未処理のメッシュが残っている場合には、次のステップ2602へ進む。
【0262】
(ステップ2602)
まだ図形を探していない未処理のメッシュをメッシュリストから1つ選ぶ。本例では、メッシュリストに1、4、6、25が入っているので、まずメッシュ1から始める。
【0263】
(ステップ2603)
メッシュに登録されているすべての図形に対して、後述するステップ2604〜ステップ2607の処理が終了しているならば、ステップ2601に戻る。一方、未処理の図形があれば、次のステップ2604に進む。本例では、メッシュ1には図形が1つもないので、処理済みとみなされ、ステップ2601に戻る。次に、ステップ2602においてメッシュ4が選ばれる。
【0264】
(ステップ2604)
メッシュに登録されている図形の中から未処理の図形を1つ選ぶ。ここでは、図23に示したように、メッシュ4の図形cを選ぶ。
【0265】
(ステップ2605)
ステップ2604において選んだ図形がすでに検索結果格納図形リストに入っているか否かが判断され、入っているならば何もせずにステップ2603に戻る。一方、検索結果格納図形リストに入っていなければ、次のステップ2606に進む。本例では、検索結果格納図形リストは初期時は空であり、図形cは入っていない。したがって、ステップ2606に進む。なお、この処理は、図形データに調査済マークを付けることによっても実現できる。
【0266】
(ステップ2606)
ステップ2604において選んだ図形が矩形に入っているか否かが判断され、入っていれば、次のステップ2607に進む。一方、入ってなければステップ2603へ戻る。本例の図形cは矩形に入っているので、ステップ2607に進む。なお、この条件判断は行わなくてもよいこともある。つまり、矩形に入っているか否かに関係なく図形リストに加える場合もある。図形表示を行なう場合、ディスプレイの外の図形を表示してもまったく見えないので、表示について影響ないからである。グラフィック表示が大変高速ならばこの判断を省くことは有効である。
【0267】
(ステップ2607)
検索結果格納図形リストに図形データポインタを加え、その後ステップ2603に戻る。その結果、図形cが検索結果格納図形リストに加わる。ここでは図形cだけの図形リストができる。
【0268】
以下、図23に示した例に基づいて、本処理をさらに詳しく説明する。
【0269】
すなわち、図形cが検索結果格納図形リストに加えられた後、ステップ2603に戻る。図23に示したように、メッシュ4にはさらに図形dがあるので、ステップ2604に進み、この図形dが選ばれる(ステップ2604)。次に、ステップ2605において、図形dは検索結果格納図形リストにないと判断され、ステップ2606に進む。ここで、図形dは矩形に入っているので、検索結果格納図形リストに加えられる(ステップ2607)。その結果、検索結果格納図形リストは、c、dになる。
次に、ステップ2603に戻り、メッシュ4に登録されているすべての図形についての処理が終了したと判断され、さらにステップ2601に戻る。ステップ2601において、まだメッシュ6と25について処理が済んでいないので、ステップ2602に進み、本例ではメッシュ6を選ぶ。図16及び図23に示したように、このメッシュ6には図形hだけが登録されている。ステップ2604において、この図形hが選ばれる。
【0270】
次に、ステップ2605において、図形hは検索結果格納図形リストにないと判断され、ステップ2606に進む。ここで、図形hは矩形に入っているので、検索結果格納図形リストに加えられる(ステップ2607)。その結果、検索結果格納図形リストは、c、d、hになる。
次に、ステップ2603に戻り、メッシュ6に登録されているすべての図形についての処理が終了したと判断され、ステップ2601に戻る。ステップ2601において、まだメッシュ25について処理が済んでいないので、ステップ2602に進み、メッシュ25が選ばれる。図16及び図23に示したように、このメッシュ25には未処理の図形d、iがあるので(ステップ2603)、ステップ2604に進む。なお、図形hは、図16に示したように、中間メッシュであるメッシュ6に登録されており、メッシュ25には登録されていないので、ここでは検索の対象とはならない。
【0271】
ステップ2604において図形dが選ばれるが、この図形dはすでに検索結果格納図形リストにあるので、ステップ2603に戻る。一方、図形iは検索結果格納図形リストにないので(ステップ2605)、ステップ2606に進む。このステップ2606において、図形iは矩形に入っていないので、ステップ2603に戻る。このようにして、メッシュ25内のすべての図形の処理が終わったので、ステップ2601に戻る。
【0272】
そして、メッシュリスト内のすべてのメッシュに対して処理が終わったので、本処理を終了する。この時点で、検索結果格納図形リストは、図形c、d、hとなる。
【0273】
[6−2−2.サブ図形を扱うとき]
表示側の都合上、図形が複数の構成要素からなることがある。一般に、図形は数種類の複数の単純な図形(サブ図形)から構成される。例えば、配電線は、複数の線分の集まりである。この場合、表示側は、配電線を1つ1つの線分に分けて管理しない。1つの図形として扱う方が人間の感覚に合っているからである。表示の上でも、線分を線分の数だけ描画することを繰り返すよりも、線分の集まりとして一度に表示する方が効率が良い。このようなサブ図形で構成される図形を「スーパー図形」と呼ぶ。
【0274】
1つの図形データが複数のサブ図形から構成されている場合、図形キー(ID)はスーパー図形に対してのみ1つだけ発番される。また、4分木のメッシュデータの所属図形リストは、図形データではなくサブ図形のデータ領域を指す。ただし、サブ図形のデータ領域を指してはいるが、元のスーパー図形がどれか分かるようにサブ図形を指すポインタをつくる。例えば、サブ図形を指すのに、元のスーパー図形のデータ領域の場所と、そこからのサブ図形のデータ領域へのオフセットを対にして、サブ図形へのポインタとする。このようにポインタを作ると、サブ図形も元のスーパー図形も分かる。このポインタを使ってメッシュへの登録はサブ図形単位に行なうことができる。
【0275】
このようにサブ図形単位に登録することは、後述する最近傍検索で利益がある。その理由は、複数の単純な図形(サブ図形)からなる図形は、通常大きな図形になることが多く、複数のメッシュにまたがる場合が多い傾向があるからである。例えば、2つのサブ図形A,B(2本の線分)からなるスーパー図形Aを例に考える。なお、線分A,Bはそれぞれたった1つのメッシュm、nにしか登録されていないとする。しかし、スーパー図形Aから見ると、この図形は2つのメッシュm、nにまたがっていることになる。
【0276】
ここで、矩形にはちょうどスーパー図形Aしか存在せず、最近傍検索を行なう中心点がメッシュmにあるとする。サブ図形に分けないでスーパー図形単位で登録している場合には、スーパー図形Aがメッシュmに登録されているということしか情報はなく、線分A,Bがどのように位置しているかは分からないため、中心点からの距離計算を行うには、線分A,B両方に対して行なうことになる。すなわち、スーパー図形Aが最近傍図形であることを得るのに、2回線分に対する距離計算を行なわねばならない。
【0277】
一方、サブ図形に分けて登録すると、メッシュmには線分Aのみが登録されていて、線分Bは登録されていないので、距離計算は線分Aに対してだけ行われる。この距離を半径とする円に他のメッシュが入ってなければ、線分に対する距離計算を1回するだけで最近傍図形であることを得る。最近傍図形を返すときは、サブ図形Aの元のスーパー図形Aを返す。なぜなら、もともと表示側はスーパー図形単位でデータを与えているからである。
【0278】
このようなサブ図形を扱う場合に、上記矩形検索処理で変わるところを述べる。すなわち、図26において、ステップ2603、ステップ2604、ステップ2606の「図形」という言葉は「サブ図形」と変わる。また、図25のステップ2501,図26のステップ2605の「検索結果格納図形リスト」は、スーパー図形のリストである。さらに、ステップ2605の条件は「そのサブ図形が検索結果格納スーパー図形リスト内のスーパー図形のサブ図形であるか」と書き直し、また、ステップ2607の図形データポインタは、スーパー図形のポインタと書き直す。
【0279】
[6−2−3.末端メッシュにのみ図形を登録する場合の矩形検索]
図25及び図26に示した「中間メッシュにも末端メッシュにも図形を登録する場合の矩形検索」に対して、「末端メッシュに図形を登録する場合の矩形検索」は、図28に示したフローチャートにしたがって実行される。なお、この処理の流れは図25に類似しているので(図28のステップ2801〜ステップ2807は、図25のステップ2501〜ステップ2507と同じ)、以下、相違点について説明する。
【0280】
(ステップ2807)
取り出したメッシュが矩形と重なっているか否かを判断し、重なっていないならば、スタックが空か否かの判断ステップ2805へ戻る。一方、重なっているならば、次のステップ2808へ進む。
【0281】
(ステップ2808)
メッシュが末端メッシュか否かを判断し、末端メッシュならばステップ2809へ進み、一方、末端メッシュでなければ4分割された子メッシュがあるので、それらについても調べる必要があるため、次のステップ2810へ進む。
【0282】
(ステップ2809)
メッシュをメッシュリストに加え、ステップ2805に戻る。
【0283】
(ステップ2810)
メッシュを4分割した4つの子メッシュをスタックに入れ、ステップ2805に戻る。
【0284】
すなわち、矩形検索のスピードは検索にかかるデータ数にほぼ比例するため、データ密度が小さいにもかかわらず多くの検索時間がかかることがなくなり、データ密度に見合った矩形検索速度を得ることができる。また、4分木の階層を下る検索により、無駄な条件判断が減るので、矩形検索速度が高速化される。
【0285】
[6−3.第4実施形態の変形例]
第4実施形態では、図24に示すように、メッシュ分割手段12と分割反対手段13、およびメッシュ併合手段14と併合判定手段15を設けたが、これらの一方の組のみを設けても良いし、両者を省くこともできる。また、範囲検索手段20を第3実施形態に組み合わせる代わりに、第2実施形態に組み合わせても良い。
【0286】
[7.第5実施形態]
最近傍図形検索とは、一点と矩形を指定し、その点に最も近い矩形内の図形を1つ検索し、最近傍図形のデータ格納ポイント、距離、その距離を図った図形上の座標を出力することをいう。なお、この一点を「中心点」、矩形を「検索範囲」と呼ぶ。
【0287】[最近傍(スーパー)図形検索の概要]
最近傍(スーパー)図形検索とは、矩形と一点(中心点と呼ぶ)が与えられたとき、矩形内のスーパー図形のうち中心点に最も近いスーパー図形(最近傍図形と呼ぶ)を探し出す操作をいう。また、この最近傍図形検索は、例えば、画面に表示される設備図のうち、マウスカーソルに最も近い設備を見つけて、その色を目立たせるような状況で使われる。この場合、画面の範囲が矩形になり、マウスカーソルの位置が中心点になる。
【0288】
通常、中心点は矩形内に入っているものであるが、この最近傍図形検索においては、中心点が矩形に入っていない場合でも、中心点に最も近い矩形内のスーパー図形を探し出すことができる。
【0289】
(1)検索対象地点(図31に示したように、矩形内に中心点があれば中心点、中心点が矩形外にある場合には、中心点に最も近い矩形上の一点)の周辺で、1つ以上のサブ図形を見つけて、最近傍サブ図形を一時的に設定する。
【0290】
検索対象地点の周辺から1つ以上のサブ図形を見つける手続きは、次のように行われる。まず、検索対象地点を含む末端メッシュから調べる。この末端メッシュにサブ図形がなければ、サブ図形が存在するまで4分木を親メッシュへ遡る。4分木の根ノードまで(世界全体メッシュ)まで遡ってもサブ図形が見つからなければ、はじめの末端メッシュの周辺のメッシュへ検索範囲を広げる。この検索範囲を検索枠と呼ぶ。
【0291】
これら周辺の末端メッシュにもサブ図形がなければ、末端メッシュから親メッシュへ遡って調べる。サブ図形を1つ以上調べるまで、検索枠を周囲へ広げて末端メッシュから探し、親メッシュへ遡ることを繰り返す。検索枠を周囲へ広げ続けて、矩形をすっぽり囲むほど大きくなっても、その検査枠内にサブ図形がなければ、最近傍サブ図形が見つけられずに終了する。
【0292】
以下に示すフローチャートにおいては、末端メッシュに図形がなかったときには、まず親メッシュへ遡り、それでも図形がなかったときに、末端メッシュの周辺に検索範囲を広げるようにしているが、逆に、まず末端メッシュの周辺に検索範囲を広げてから、次に親メッシュを探すように処理の順序を変えてもよい。
【0293】
また、中心点から遠い図形を検索対象としたくないので、図形がなかったときの検索するメッシュを選ぶ順序を次のようにする。すなわち、メッシュの選ぶ順序は、短形と重なるメッシュそれぞれにおいて中心点から最も離れた地点(最遠点)を見つけて、中心点との最遠点の距離が近いメッシュ順とする。しかし、実際には、図形がない場合は、もともと図形の密度が小さいところで最近傍図形検索を行なうことになる。そのため多少遠いところを一時的な最近傍図形と設定しても、検索する図形数が少ないので実行時間に問題はない。
【0294】
(2)一時的な最近傍図形への距離を半径とし、中心点を中心とする円を作り、その円の中の図形からより近い図形を探す。この場合、何らかの最近傍サブ図形が見つかる。このサブ図形から元のスーパー図形が分かり、スーパー図形を返す。
【0295】
[7−1.第5実施形態の構成]
図29は、本発明の第5実施形態の構成を示す機能ブロック図である。すなわち、本実施形態の多次元データ検索装置は、前記各実施形態に示した多次元データ管理装置の構成要素に加えて、前記コンピュータの記憶領域内に蓄積されている多次元データを管理するステップが、前記多次元空間内における指定された点に最も近い多次元データを検索する最近傍データの検索手段21を含むことを特徴とする。第5実施形態において、前記最近傍データの検索手段21としては、前記指定された点を含む最小のメッシュに多次元データが登録されていない場合に、前記最小のメッシュの親メッシュ、最小のメッシュに隣接するメッシュ、親メッシュの親メッシュ、隣接するメッシュの親メッシュ、隣接するメッシュに隣接する他のメッシュのごとく、再帰的に最近傍データの候補が1つ決定されるまで検索範囲を拡大するものを使用する。
【0296】
また、この最近傍データ検索手段21は、前記範囲検索手段20と同様に、入力装置2から入力されたメッシュの座標と矩形の座標を使って、メッシュと矩形の領域が重なっているか否かを判定するメッシュ/矩形領域重なり判定手段211と、図形データの座標と矩形の座標を使って、図形が矩形に入っているか否かを判定する図形/矩形所属判定手段212と、図形の座標データを使って、与えられた一点(中心座標)との距離を計算し、その中心座標に最も近い図形上の座標を求める距離計算手段213と、データ領域上に、固定パラメータを格納したり、初期4分木(根ノードしかない4分木)を作成したり、図形キー管理領域を構成する際にデータ領域を初期化するデータ領域初期化手段214と、与えられた一点を含む末端メッシュを検索するメッシュ検索手段215とを備えている。
【0297】
[7−2.第5実施形態の作用]
以下前記のような構成を有する第5実施形態の多次元データ管理装置の作用並びに、これに対応する多次元データ管理方法について、図30,31の最近傍データの説明図と、図32〜41のフローチャートに従って説明する。
【0298】
[7−2−1.最近傍図形検索...その1]
図32〜図38は、中間メッシュにもサブ図形を登録するときの最近傍図形検索の処理の流れを示すフローチャートである。
【0299】
以下、最近傍(スーパー)図形検索の処理の流れを、図30及び図32〜図38を参照して、各ステップごとに説明する。
【0300】
(ステップ3201...図32参照)
中心点と矩形をセットする。例えば、図30に示したように中心点と矩形をセットする。
【0301】
(ステップ3202)
検索過程で見つける最近傍サブ図形について記憶するところを初期化する。
最近傍サブ図形=無し◎最近傍点=無し◎最短距離=無限大(または、世界全体で引ける最も長い線分の長さより長い長さ)
ここで、「最近傍サブ図形」は、検索過程で見つけた最も近いサブ図形であり、「最近傍点」は、そのサブ図形上で中心点に最も近い点である。また、「最短距離」は、そのサブ図形への中心点からの距離である。すなわち、「最短距離」は最近傍点と中心点の距離である。
【0302】
(ステップ3203)
中心点から最も近い矩形内の点(検索対象地点)を見つける。すなわち、矩形内に中心点があるときは検索対象地点は中心点である。一方、中心点が矩形外にあるときは、中心点と矩形の間の距離計算を行なえば得られる。図30に示したように、本例では、中心点そのものが検索対象地点になる。
【0303】
(ステップ3204)
検索対象地点のある末端メッシュを見つける。これが検索を始めるメッシュとなる。なお、この末端メッシュを見つける方法は、検索対象地点の座標から4分木を使って得られる。本例では、メッシュ5が見つかる。
【0304】
(ステップ3205)
見つけた末端メッシュを、これまでに調べた範囲を示す矩形(検索枠と呼ぶ)とする。例では、全世界を4分割した左上4分の1の四角形(メッシュ5)が検索枠となる。
【0305】
(ステップ3206)
検索のループのために、今見つけた末端メッシュだけからなる検索対象メッシュリストを作る。例では、検索対象メッシュリストは5となる。
【0306】
(ステップ3207)
検索対象メッシュリストから順にメッシュを1つ取り出し、現メッシュとする。例では、メッシュ5が選ばれる。そして、このメッシュ5に登録されているサブ図形から調べる。
【0307】
(ステップ3208)
まず、図形を調べる前に、現メッシュが検索済みか否かを判断する。この処理は、検索済メッシュリストに現メッシュが入っているかどうかを調べることで分かる。そして、検索済みならば次のステップ3209へ進み、未検索ならば、図33に示したステップ3301へ進む。例では、検索を始めたところなので、メッシュ5は未検索であるため、ステップ3301へ進む。
【0308】
ここからは、メッシュに登録されているサブ図形を調べる処理についての説明である。
【0309】
(ステップ3301...図33参照)
検索済メッシュリストに現メッシュを加える。例では、検索済メッシュリストは、5だけからなる。
【0310】
(ステップ3302)
現メッシュにサブ図形が登録されているか否かを判断し、現メッシュにサブ図形が登録されていなければ、図34に示した根ノードへ遡るフローへ進む。一方、現メッシュにサブ図形がある場合には、次のステップ3303に進む。例では、図30に示したように、現メッシュ5は図形bを1つ持っているので、ステップ3303に進む。
【0311】
(ステップ3303)
現メッシュに登録されているサブ図形を順に調べる。ここでは、サブ図形を1つずつ取ってきて現図形とする。例では、メッシュ5の図形bを現図形とする。
【0312】
(ステップ3304)
すでに調べたサブ図形のリスト(調査済サブ図形リスト)に現図形があるか否かを調べ、あるならば、この現図形への処理をスキップし、ステップ3311へ進む。一方、調査済サブ図形リストに現図形がないならば、現図形への処理へ移り、ステップ3305へ進む。なお、メッシュまたがりのあるサブ図形のとき、このステップで(YES)に進むことがある。例では、図形bは検索済サブ図形リストにないので、ステップ3305へ進む。
【0313】
(ステップ3305)
現図形を2度調べないように、調査済サブ図形リストに現図形を加える。例では、調査済サブ図形リストは、図形bだけからなる。
【0314】
(ステップ3306)
現図形が矩形に入っているか否かを調べ、矩形に入っていなければ、処理を行なうことは無駄なので、ステップ3311へスキップする。一方、矩形に入っていれば、距離計算のステップ3307へ進む。例では、図形bは矩形内に入っているので、距離計算のステップ3307へ進む。
【0315】
(ステップ3307)
中心点から現図形への距離を計算し、図形上の最も近い点(近傍点)を計算する。この処理に対しては、座標からの計算手段が用意されている。例では、図30に示したように、図形bに対して距離計算手段で計算すると、距離はLで、近傍点は点Vと分かる。距離、遠近の定義は多次元データの種類に依存する。例では、ユークリッド距離である。
【0316】
(ステップ3308)
計算した距離とこれまでの最短距離を比較し、計算した距離がこれまでの最短距離より小さければ、最近傍サブ図形、最近傍点、最短距離を更新するステップ3309へ進む。一方、計算した距離がこれまでの最短距離と等しいか大きければ、何もせずにステップ3311に進む。本例では、今のところ最短距離は無限大なので、図形bの方が距離が小さいので、ステップ3309へ進む。
【0317】
(ステップ3309)
最近傍サブ図形、最近傍点、最短距離を更新する。例の場合、最近傍サブ図形=図形b、最近傍点=点V、最短距離=距離Lに更新される。
【0318】
(ステップ3310)
最短距離が0かどうか調べ、もし0ならば、もうこれより小さい距離はありえないので、ここで検索を打ち切り、ステップ3312へ進む。一方、0でないならば、ステップ3311へ進む。例では、図形bは距離が0でないので、ステップ3311へ進む。
【0319】
(ステップ3311)
現メッシュ内の登録サブ図形全てについてのループの終了条件の判断である。全てのサブ図形について処理が終わってなければ、ステップ3303へ戻る。一方、全てのサブ図形について処理が終わっている場合には、図32のステップ3211へ進み、検索対象メッシュリストの全てについて、処理したか否かを判断する。例の場合、メッシュ5の全図形について処理が終わったので、次のメッシュについて調べるか否かを判断するステップ3211へ進む。
【0320】
(ステップ3312)
ここでは検索結果を返す。最近傍の図形としてサブ図形が得られている。検索結果としては、スーパー図形を返す必要があるので、サブ図形の元のスーパー図形のデータへのポインタに直す。それと合わせて最短距離と最近傍点を返す。
【0321】
ここからは、ステップ3302で調べるメッシュに図形が1つもなかったり、ステップ3208でメッシュが検索済の場合の処理についての説明である。
【0322】
(ステップ3209)
ステップ3302で調べるメッシュに図形が1つもなかったり、ステップ3208でメッシュが検索済ならば、図32のステップ3209へ進む。ステップ3209からステップ3210へのループでは、メッシュに調べるべき図形があるまで、親メッシュへ遡る。このステップ3209は、遡って行って根ノード(世界全体)まで来たらループを中断するための判断である。すなわち、メッシュが世界全体でなければ、親メッシュへ遡るステップ3210へ進み、世界全体ならば、次の末端メッシュを調べるためのフローへ進む。
【0323】
(ステップ3210)
親メッシュを調べるため、現メッシュを親メッシュに置き換える。そしてステップ3208へ進む。
【0324】
(ステップ3211)
世界全体まで遡った場合、ステップ3209からステップ3211へ進んでいる。ここで、検索対象メッシュリストのメッシュ全てに対して処理が終わっているか否かが判断され、処理が終わってなければステップ3207へ戻る。一方、終わっていれば次のステップ3212へ進む。例の場合、検索対象メッシュリストにはメッシュ5だけしかなく、メッシュ5の処理が終わっているので、ステップ3212へ進む。
【0325】
(ステップ3212)
ここで、1つ以上のサブ図形について距離計算を行なったか否かを判断し、分岐する。すなわち、最近傍図形=無しのままでなければ、サブ図形1つ以上に対して距離計算をしたことを意味する。一方、最近傍図形=無しならば、まだ1つもサブ図形に対して距離計算をしていないことになる。サブ図形1つ以上に対して距離計算をしていれば、これまでの最短距離、最近傍点、最近傍サブ図形があることになる。そして、このステップの次は、この最短距離を半径とする円内のサブ図形を調べるフローステップ3401へ進む。
【0326】
上述したように、図32のステップ3212において、サブ図形に対して一度も距離計算をしていなければ、検索対象メッシュリスト内のメッシュすべてと、それぞれのメッシュから親メッシュへ遡ってもサブ図形が1つも見つからなかったことを意味する。そのため、この先のフロー(図36に示したステップ3603から)では、検索枠を広げて検索し直すための準備を行なう。簡単に言うと、これまで調べた末端メッシュの範囲を少し広げて、新たな末端メッシュのリストを作って検索対象メッシュリストとする。ただし、範囲を広げた結果、検索枠が矩形より大きくなったときには、最近傍検索は終了する。この点について、図39を参照してより具体的に説明する。すなわち、はじめ、検索枠はメッシュZの四角に設定される。そして、メッシュZを検索して、親メッシュをさかのぼっても図形がないときは、回りを探す。この検索枠と接するか、重なる末端メッシュで、検索済みではなく、矩形と重なるのはメッシュA〜Hである。メッシュA〜Hの中で最小のメッシュBの縦幅、横幅分だけ検索枠を広げる。すると、図39に示したように、旧検索枠(太実線)から新検索枠(一点鎖線)に広がる。さらに、メッシュA〜Hとその親メッシュに図形がないならば、新検索枠を使ってメッシュリストを作る。メッシュリストは、メッシュI〜Mになり、新たな検索枠(新々検索枠)は点線で囲んだ部分となる。
【0327】
以下、この処理を各ステップごとに説明する。
【0328】
(ステップ3601)
このステップへは、図32に示したステップ3212から来る。なお、このステップにおけるメッシュリストの作成の詳細なルーチンについては、図37に示し、後述する。はじめにこのステップに到達したときは、検索枠は検索対象地点のある末端メッシュである。この末端メッシュの回りの末端メッシュを検索対象にしたいので、検索枠に接するか重なる末端メッシュを探す。そして、これらの中の矩形に重ならないメッシュと検索済のメッシュを除いて検索対象メッシュリストとする。
【0329】
もし、検索対象メッシュリストにメッシュが1つもなければ、検索枠が十分に広がって、矩形より大きくなっていることを意味する。本例の矩形の場合、メッシュ5に図形がなければ、メッシュ5の回りの末端メッシュ28、29が検索対象メッシュリストになる。なお、メッシュ4、メッシュ25もメッシュ5の回りの末端メッシュであるが、矩形に重なっていないので対象外である。
【0330】
(ステップ3602)
検索対象メッシュリストにメッシュあるか否かが判断され、メッシュが1つもなければ、検索すべきメッシュがもうないことを意味し、検索結果として返るのは、最近傍図形がないということである。一方、検索対象メッシュリストにメッシュがあれば、ステップ3603に進む。
【0331】
(ステップ3603)
ここでは、新たな検索対象メッシュリスト内のメッシュの中で最小のメッシュの縦幅、横幅分だけ検索枠を縦にも横にも正負両方向に広げる。このように広げると、次に再び図形が1つもなくて検索対象メッシュリストを作るとき、近いところにあるメッシュから順に検索対象メッシュリストに加わることになる。検索対象メッシュリストができているので、図32のステップ3207へ戻ってメッシュに対する処理を行なう。
【0332】
このように、図32、図33及び図36に示したフローチャートにしたがって最近傍図形検索を行なうと、1つの最近傍サブ図形候補が見つかるか、最近傍図形がないという結果が返るかどちらかになる。そして、最近傍図形候補が1つ見つかっていると、図32のステップ3212から(NO)の分岐へ進み、図34のステップ3401へ到達する。
【0333】
(ステップ3401)
このステップに到達した場合には、最近傍サブ図形が1つ見つかっているが、これより近いものがないかどうかを調べなければならない。このために中心点を中心として、最短距離を半径とする円を作り、それにかかるメッシュを調べる。このステップでは、その円と重なりかつ矩形と重なるメッシュ(末端も中間も)を検索し、検索対象メッシュリストとする。このメッシュ検索のルーチンについては、図38に詳細に表わし、後述する。本例では、メッシュ1,5,7,28,29が検索対象メッシュリストに含まれる。
【0334】
(ステップ3402)
検索対象メッシュリスト内のメッシュを1つずつ調べるため、メッシュを1つ取って現メッシュとする。
【0335】
(ステップ3403)
現メッシュが検索済か否かを調べる。すなわち、検索済メッシュリスト内に現メッシュがあるか否かを調べれば良い。そして、現メッシュが検索済ならば、メッシュに対する処理をスキップして、図35のステップ3506へ進む。一方、検索済でなければ次のステップ3404に進む。例の場合、メッシュ5が検索済リストにあるので、メッシュ5の処理の時に、図35のステップ3506へスキップする。
【0336】
(ステップ3404)
現メッシュを検索済メッシュリストに加える(なお、検索したメッシュリストが必要なければこのステップはなくてもよい)。
【0337】
(ステップ3405)
現メッシュに登録サブ図形があるか否かを判断し、あれば、図形の処理へ進み、なければ、図35のステップ3506へスキップする。例では、メッシュ1,7がステップ3506へスキップすることになる。
【0338】
(ステップ3406)
現メッシュに登録されているサブ図形1つ1つへの処理を始める。すなわち、現メッシュに登録されているサブ図形を1つ選んで、現図形とする。例では、メッシュ28の処理の場合、図形iが選ばれ、メッシュ29の処理の場合、図形aが選ばれる。
【0339】
(ステップ3407)
現図形が調査済か否かを調べる。これは、調査済サブ図形リストを調べれば分かる。そして、調査済ならば、図35のステップ3505へスキップし、調査済でなければ、次のステップ3408へ進み、現図形への処理を行う。例では、図形iは調査済ではないので、ステップ3408へ進む。また、図形aも調査済ではないので、同様にステップ3408へ進む。
【0340】
(ステップ3408)
メッシュまたがりがある場合に2度計算しないように、調査済サブ図形リストに現図形を加える。
【0341】
(ステップ3409)
距離計算をする前に、現図形が矩形に入っているか否かを調べ、矩形に入っていれば距離計算へ進み、矩形に入ってなければ、図35のステップ3505へスキップする。本例では、図形iの場合、矩形に入っていないので、距離計算をせずにステップ3505へスキップする。一方、図形aの場合、矩形に入っているので、ステップ3410で距離計算を行なう。
【0342】
(ステップ3410)
中心点からの距離、近傍点を距離計算手段によって計算する。図形aの距離はK、近傍点は点Uと計算される。
【0343】
(ステップ3501...図35参照)
距離計算した結果を、これまでの最短距離と比べる。これまでの最短距離と等しいか大きければ、何もせずにステップ3505に進む。一方、これまでの最短距離より小さければ、最近傍サブ図形更新のフローへ進む。本例では、図形aの場合、これまでの最短距離より距離が短いので、ステップ3502へ進み更新する。
【0344】
(ステップ3502)
最近傍サブ図形、最近傍点、最短距離を更新する。例の場合、最近傍サブ図形=図形a、最近傍点=点U、最短距離=距離Kとなる。
【0345】
(ステップ3503)
最短距離が0かどうか調べる。もし0ならば、もうこれより小さい距離はありえないので、ここで検索を打ち切り、ステップ3504へ進む。0でないならば、ステップ3505へ進む。例の図形aの場合、距離が0でないので、ステップ3505へ進む。
【0346】
(ステップ3504)
ここでは検索結果を返す。最近傍の図形としてサブ図形が得られているため、検索結果としては、スーパー図形を返す必要があるので、サブ図形の元のスーパー図形のデータへのポインタに直す。それと合わせて最短距離と最近傍点を返す。
【0347】
(ステップ3505)
現メッシュに登録されている登録サブ図形全てについてのループの終了条件の判断である。すべてのサブ図形について処理が終わっていなければ、図34のステップ3406へ戻り、次の図形を調べる。一方、すべてのサブ図形について終わっていれば、次のステップ3506に進む。
【0348】
(ステップ3506)
検索対象メッシュリストのメッシュ全てに対して処理を終えたか否かが判断され、すべてのメッシュについて処理を終えたら、次のステップ3507へ進む。一方、終えていければ、図34のステップ3402に戻り、次のメッシュへの処理を行なう。
【0349】
(ステップ3507)
ここでは検索結果を返す。最近傍の図形としてサブ図形が得られているため、検索結果としては、スーパー図形を返す必要があるので、サブ図形の元のスーパー図形のデータへのポインタに直す。それと合わせて最短距離と最近傍点を返す。本例の場合は、最後には、「図形aが最近傍図形である」との結果を得る。
【0350】
ここで、図37を参照して、図36のステップ3601におけるメッシュリストの作成のルーチンについて、さらに詳しく説明する。すなわち、図36のステップ3601においては、その時点で設定されている検索枠と接するか、重なる末端メッシュのうち、検索済メッシュリストになく、且つ、矩形と重なるものを探し出して、新たな検索対象メッシュリストとする場合を示している。
【0351】
なお、この処理は、上述した矩形検索での、矩形に重なるメッシュリストの作成のフローチャート(図25)とほぼ同じである。違う点は、メッシュリストを作成するステップに至るまでに、2つ条件分岐(ステップ3707、ステップ3709)が加わっている点である。
【0352】
また、このフローでは、末端メッシュだけがメッシュリストに加わえられるが、ステップ3710とステップ3711の順番を入れ替えて、メッシュが末端か否かを判断する前に、メッシュリストにメッシュを加えると、条件に合う中間メッシュと末端メッシュの両方を含むメッシュリストが得られる。
【0353】
次に、図38を参照して、図34のステップ3401におけるメッシュリストの作成のルーチンについて、さらに詳しく説明する。すなわち、図34のステップ3401においては、それまでの最短距離(それまでの最近傍図形までの距離)を半径、中心点を中心とする円と矩形に重なる末端メッシュ及び中間メッシュを探し出して、新たな検索対象メッシュリストとする場合を示している。
【0354】
なお、この処理は、上述した矩形検索での、矩形にかかるメッシュリストの作成のフローチャート(図25)とほぼ同じである。違う点は、メッシュリストを作成するステップに至るまでに、1つ条件分岐(ステップ3808)が加わっている点である。
【0355】
また、このフローでは、末端メッシュと中間メッシュがメッシュリストに加わえられるが、ステップ3809とステップ3810の順番を入れ替えて、メッシュが末端か否かを判断した後で、メッシュリストにメッシュを加えると、条件に合う末端メッシュだけのメッシュリストが得られる。
【0356】
[7−2−2.最近傍図形検索...その2]
上述した最近傍図形検索は、中間メッシュにもサブ図形を登録する場合についてのものであったが、以下に述べる最近傍図形検索は、末端メッシュにのみサブ図形を登録する場合についてのものである。
【0357】
以下、中間メッシュに図形を登録する場合と登録しない場合の最近傍図形検索の違いについて、図32(中間メッシュにもサブ図形を登録する場合)と図40(末端メッシュにのみサブ図形を登録する場合)で比べる。図から明らかなように、図32では、ステップ3209、ステップ3210のループがあるが、図40にはない。その理由は、図32では、中間メッシュにも図形が存在するので、末端メッシュを調べて図形が存在しなかった場合には、親メッシュへ溯って調べなければ、検索漏れを起こしてしまうからである。
【0358】
次に、図33(中間メッシュにもサブ図形を登録する場合)と図41(末端メッシュのみにサブ図形を登録する場合)を比べる。この違いは、図33では、ステップ3302の条件分岐でNOのとき、図32のステップ3211の検索対象メッシュリストの処理終了判断へ飛ばず、ステップ3209に飛んでいる。一方、図41では、図33のステップ3302に相当するステップ4102でNOのとき、図32のステップ3211に相当するステップ4008に飛んでいる。その理由は、中間メッシュにも図形がある図33においては、親メッシュを調べなければならないので、親メッシュを調べるフローであるステップ3209へ飛ばなければならないからである。
【0359】
なお、図40からBへ進み、Cから戻ってくるところに接続するフローチャートは、上述した図36(中間メッシュに図形がある場合の図)と同一である。また、図40のAへ進む先のフローチャートは、ステップ3401を除いて、図34及び図35と同一である。
【0360】
図34のステップ3401に対応する処理が異なるのは、それまでに見つけた最近傍図形までの距離を半径とする円の範囲内のメッシュを見つけるに際し、中間メッシュにも図形がある場合は、円にかかるメッシュを探すとき、末端だけでなく、中間メッシュも探し出さなければならないからである。一方、末端メッシュにしか図形がない場合には、中間メッシュを調べる必要がないので、ステップ3401のステップを、末端メッシュのみを探し出すように変更する。すなわち、図38のステップ3809とステップ3810を置き換えれば良く、メッシュが末端か否かを判断し、YESのときのみ、メッシュをリストに加えるようになっている。
【0361】
このように、図34のステップ3401を変え、図38のステップ3809及びステップ3810を変えて、図40のAから図34及び図35のフローを実行すれば、末端メッシュにのみ図形がある場合の最近傍図形検索の処理フローになる。
【0362】
[7−3.第5実施形態の効果]
前記の様な構成を有する第5実施例によれば、最近傍図形検索処理において、1回の検索あたりに距離計算するデータが少なくなるので、検索時間が速くなる。さらに、最近傍図形検索処理の速さが、データ密度の疎密に影響されず、いつでも同程度の速さで処理できるようになる。
【0363】
[7−4.第5実施形態の変形例]
第5実施形態では、図29に示すように、メッシュ分割手段12と分割反対手段13、およびメッシュ併合手段14と併合判定手段15を設けたが、これらの一方の組のみを設けても良いし、両者を省くこともできる。また、範囲検索手段20を第3実施形態に組み合わせる代わりに、第2実施形態に組み合わせても良い。また、最近傍データ検索手段21を範囲検索手段20と組み合わせ両方の検索が可能としたが、範囲検索手段20がなくても良い。
【0364】
[8.他の実施形態]
[8−1.図形のメッシュへの所属条件の拡張]
第2実施形態において図形の所属を親メッシュから子メッシュへ移すべきか否かを判定する条件、及び第3実施形態において図形を現メッシュに所属させる(登録する)べきか否かを判定する条件とは、類似の作用及び効果を有するものである。第3実施形態においては条件判定及びその結果に依存した図形のメッシュへの登録作用が、その時のメッシュ分割(4分木)の状態の如何にかかわらず、必要な場合にはメッシュ分割を行なっても、条件に合致するメッシュに図形を所属させる。これに対して第2実施形態においては、その作用が図形登録時のメッシュ分割の状態によって制限され、図形登録時ではなくて、別の基準に従って作用するメッシュ分割操作の作用時に同時に行なわれる。つまりメッシュ分割時までその作用が延期されるという差があるにすぎない。
【0365】
この条件としてどのようなものを採用するかによって、各図形のメッシュへの重複登録の数及び図形とメッシュとの重なり具合が異なってくる。これが所要記憶容量の大小及び矩形検索、最速傍図形検索の効率に影響する。
【0366】
従来技術はこの条件として、
(a)末端のメッシュで、かつ所属図形数がP未満のメッシュか否かを判定し、該当メッシュであれば登録する。(該当していなければメッシュ分割によって該当するメッシュを作り出す。)
(b)図形全体を包含する最小のメッシュか否かを判定し、最小のメッシュに該当していれば登録する。
【0367】
(c)図形全体を包含する最小のメッシュを分割した子メッシュの境界によって分断された各部分図形に注目し、それらの部分図形のうち1つを含む最小のメッシュか否かを判定し、該当メッシュであればそこに図形を登録する。
【0368】
という条件を設定したのとそれぞれ等価である。これらの条件を用いた場合には、それぞれ[発明が解決しようとする課題]に述べたような問題点によって記憶領域の浪費や検索性能の劣化が生じる場合を排除することができなかった。
【0369】
これらの従来技術は判定基準にかかわる図形とメッシュとの関係として、例えば前記(a)の場合、登録しようとする図形及び既にメッシュに所属している図形の種類の如何にかかわらず、メッシュに既に所属している図形数のみを用いている。また、(b)の場合はメッシュが図形を包含する最小のメッシュか否か、つまりメッシュを分割した子メッシュのうち複数のものに図形が重なるか否かのみを用いている。(c)は判定の過程を二段階に分けているとはいえ、用いられている図形とメッシュとの関係は(b)と同様に、図形の種類の如何にかかわらず、メッシュが(部分)図形を包含する最小のメッシュか否かのみを用いている。
【0370】
ここにいう「図形の種類」とは、登録しようとするn次元空間データのn次元空間内での空間の占有(ひろがり)の態様に主として起因する分類・区別である。例えば極端な例として点データは大きさ(ひろがり)を持たないので前記(b)(c)のような判定基準では扱えず、他の基準例えば(a)のような基準を使用せざるを得ない。線分は長さのみあって面積や体積はないから、メッシュとの重なり具合及びそれが検索の効率に及ぼす影響も面積や体積を持つ図形、就中各次元の最大径の比がメッシュの各次元の長さの比に近いような凸な図形とは異なっている。後者に関しては前記(c)あるいは(b)のような基準はメモリ効率の点でも検索速度の点でも有効である場合が多いが、線分や細長い矩形直方体に関しては必ずしも有効でないことは前述のとおりである。
【0371】
さらには、ある目的・性質を(共)有することが予めわかっているデータに関しては、それに応じた適切な条件を設定することで資源の浪費を避け、検索効率を高めることができる。例えば、地図、グラフ等の背景に用いられる罫線や座標線は数はそれ程多くはないが、1つ1つが非常に長いという性質がある。これらのデータを他の非常に短い線分や小さな図形と同様な基準でメッシュに所属させたとすると、所属メッシュが細分化されすぎて非常に多くのメッシュに重複登録され、多量のメモリを浪費したうえ、検索効率をも劣化させるおそれが大きい。逆にあまりにも小数のメッシュにしか所属せず、同一のメッシュに多数の罫線が所属することになって検索効率が著しく低下するという事態もまた生じうる。例えば前記(b)の条件を用いれば、すべての罫線は世界座標範囲と同じ1つの(最大の)メッシュにのみ所属することになり、領域を分割して図形を登録することによって検索の効率を向上させるという効果は全然得られない。
【0372】
このような状況を避けるために、罫線については、罫線の間隔と同程度の長さの辺を持つメッシュにのみ登録するように第4実施例(b)の条件を設定することが考えられる。この条件に従って登録を行なえば、1つのメッシュに属する罫線は(1方向)1本だけになり、なおかつ極端な重複登録は避けられる。この場合、選ばれる罫線の数が罫線の総本数に比較して非常に少ない矩形検索には特に有効である。前記の条件は個々の罫線の線分としての属性(例えば長さ)ではなく、罫線同士の間隔から予め決定あるいは計算される長さを規準にして登録すべきメッシュを判定するものである。
【0373】
面積や体積を持つ図形に関しても、例えば背景として用いられる非常に広い面積を占める図形を、例えば前記(a)のような条件で他の小さな図形と同様に扱えば重複登録の数は膨大になる。このような図形に対しては第3実施形態の(d)のような条件で重複登録の数を限るのが、メモリの浪費を避けるのに効果的である。
【0374】
上述のように、図形の形状・大きさのみならず、その目的や他の図形との関係から最適と考えられる基準にもとづいて、メッシュへの図形の登録あるいは子メッシュへの図形の所属移動を制御することによって、図形に依存しない一律な条件では達成できないメモリの効率的使用並びに検索の効率化を図ることができる。
【0375】
[8−2.多次元データへの適用]
前記各実施形態は、2次元や3次元空間内の図形データを扱う場合について具体的に述べてきたが、それ以外にも各次元が何らかの量を表すような多次元のデータに関して、本実施例と同様の方法で他の多次元空間、すなわちn次元空間を再帰的に2のN乗分割したn次元直方体をメッシュとしてデータを登録・検索することができる。これらn次元データはn次元空間内の点として扱われるようなデータばかりではなく、1つの(1組の)データがn次元空間内にある広がりを持った超立体として扱われるものも希ではない。例えば、1つの物体に関するn種の属性の測定値はそれぞれに誤差を含んでおり、それを各次元の真の値がある確率で存在する範囲として扱う場合、n次元直方体データになる。その形状は測定の状況に依存して種々変化するので、それらのデータを一括して記録し、各次元の真の値がある範囲に存在する物体を選択する等の検索を効率良く実施するためには、本発明のような多次元データ管理・検索手段が必要である。
【0376】
このように本発明は、上述した実施形態に限られず、多次元空間中で位置の決まるデータの管理・検索に適用できるが、この場合、N次元空間のデータに関しては、[2のN乗]分木でメッシュの分割が管理される。また、データが多種類ある場合には、種類を限定して検索することもできる。さらに、データの種類や座標データの扱いの違いによって、[2のN乗]分木を複数用意することも可能である。
【0377】
【発明の効果】
以上述べた様に、本発明によれば、データ領域の削減が可能で、しかも矩形検索及び最近傍図形検索の高速化を可能とした多次元データ管理方法及び装置を提供することができる。
【図面の簡単な説明】
【図1】本発明の第1実施形態の構成を表す機能ブロック図
【図2】本発明にかかるデータ領域の全体構成を示す図
【図3】本発明のメッシュデータの構成を示す図
【図4】メッシュデータと図形データとの対応を示す図
【図5】本発明の第1実施形態において、図形aを登録する世界全体を示す図
【図6】メッシュ分割をした場合の番号付けを示す図
【図7】メッシュとそのメッシュに登録された図形を示すツリー図
【図8】スタックの動作を示す図
【図9】図形のデータ領域への登録の処理の流れを示すフローチャート
【図10】図形をメッシュに登録する処理の流れを示すフローチャート
【図11】図形をデータ領域から削除する処理の流れを示すフローチャート
【図12】図形をメッシュから削除する処理の流れを示すフローチャート
【図13】図形の修正の処理の流れを示すフローチャート
【図14】メッシュの分割の処理の流れを示すフローチャート
【図15】メッシュの併合の処理の流れを示すフローチャート
【図16】中間メッシュにも図形を登録する場合のメッシュとそのメッシュに登録された図形を示すツリー図
【図17】本発明の第2実施形態の構成を表す機能ブロック図
【図18】第2実施形態の処理の流れを示すフローチャート
【図19】中間メッシュにも図形を登録する場合の条件を説明するための図
【図20】中間メッシュにも図形を登録する場合の条件を説明するための図
【図21】本発明の第3実施形態の構成を表す機能ブロック図
【図22】第3実施形態の処理の流れを示すフローチャート
【図23】本発明の第4実施形態の矩形検索を説明するための図
【図24】本発明の第4実施形態の構成を表す機能ブロック図
【図25】矩形検索において、検索する矩形にかかっている全てのメッシュを探し出す処理の流れを示すフローチャート
【図26】矩形検索において、図形が矩形に入っているか否かを検索する処理の流れを示すフローチャート
【図27】メッシュリストと図形リストの対応を示す図
【図28】末端メッシュにのみ図形を登録した場合の矩形検索の処理の流れを示すフローチャート
【図29】本発明の第5実施形態の構成を表す機能ブロック図
【図30】最近傍図形検索を説明するための図
【図31】中心点と矩形の関係を示す図
【図32】最近傍図形検索の処理の流れを示すフローチャート
【図33】最近傍図形検索の処理の流れを示すフローチャート
【図34】最近傍図形検索の処理の流れを示すフローチャート
【図35】最近傍図形検索の処理の流れを示すフローチャート
【図36】最近傍図形検索の処理の流れを示すフローチャート
【図37】最近傍図形検索の処理の流れを示すフローチャート
【図38】最近傍図形検索の処理の流れを示すフローチャート
【図39】最近傍図形検索の処理の流れを示すフローチャート
【図40】末端メッシュにのみ図形を登録した場合の最近傍図形検索の処理の流れを示すフローチャート
【図41】末端メッシュにのみ図形を登録した場合の最近傍図形検索の処理の流れを示すフローチャート
【図42】MD木法の従来手法を示す図であって、(A)は領域分割、(B)はMD木
【図43】MD木法の問題点を示す図であって、(A)は領域分割、(B)はデータ4の投入後、(C)はデータ7の投入後、(D)はデータ8の投入後
【図44】従来の最近傍データ検索の手法を説明する図
【図45】重複登録の例を示す図
【図46】quad−tree法の第1の変形例を示す図
【図47】quad−tree法の第2の変形例を示す図
【符号の説明】
1...中央処理装置
2...入力装置
3...出力装置
4...メインメモリ
5...ファイル装置
6...データ管理プログラム
7...メッシュデータ記憶手段
8...多次元データ記憶手段
9...木構造管理手段
10...多次元データ登録削除手段
11...メッシュ/矩形領域重なり判定手段
12...メッシュ/矩形枠重なり判定手段
13...図形/矩形所属判定手段
14...距離計算手段
15...データ領域初期化手段
16...メッシュ検索手段
17...検索結果出力手段
Claims (6)
- コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理方法において、
前記所定の領域の中の第1の領域が、その子領域である第2の領域に階層的に分割されている場合に、前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断し、
前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合し、
前記第1の領域に前記多次元データを割り当てることを特徴とする多次元データ管理方法。 - コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理方法において、
前記所定の領域の中の第1の領域を、その子領域である第2の領域に階層的に分割する場合に、前記第1の領域に前記多次元データを割り当てたときの状態と、前記第2の領域に前記多次元データを割り当てたときの状態とに基づいて示される分割許容条件を満たすか否かを判断し、
前記分割許容条件を満たすと判断した場合には、前記第1の領域を前記第2の領域に階層的に分割し、前記第2の領域に前記多次元データを割り当て、
また、前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断し、
前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合し、前記第1の領域に前記多次元データを割り当てることを特徴とする多次元データ管理方法。 - コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理装置において、
前記所定の領域の中の第1の領域が、その子領域である第2の領域に階層的に分割されている場合に、前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断する手段と、
前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合する手段と、
前記第1の領域に前記多次元データを割り当てる手段とを備えたことを特徴とする多次元データ管理装置。 - コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理装置において、
前記所定の領域の中の第1の領域を、その子領域である第2の領域に階層的に分割する場合に、前記第1の領域に前記多次元データを割り当てたときの状態と、前記第2の領域に前記多次元データを割り当てたときの状態とに基づいて示される分割許容条件を満たすか否かを判断する手段と、
前記分割許容条件を満たすと判断した場合には、前記第1の領域を前記第2の領域に階層的に分割する手段と、
前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断する手段と、
前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合する手段と、
前記判断結果に基づいて、前記第1の領域および第2の領域の少なくとも一方に前記多次元データを割り当てる手段と、
を備えたことを特徴とする多次元データ管理装置。 - コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理プログラムを記録した記録媒体であって、
前記プログラムは、コンピュータに、
前記所定の領域の中の第1の領域が、その子領域である第2の領域に階層的に分割されている場合に、前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断する処理と、
前記併合許容条件を満たすと判断された場合には、前記第2の領域を前記第1の領域に併合する処理と、
前記第1の領域に前記多次元データを割り当てる処理と、
を行わせることを特徴とする多次元データ管理プログラムを記録した記録媒体。 - コンピュータの所定の領域に配置される複数の多次元データを管理する多次元データ管理プログラムを記録した記録媒体であって、
前記プログラムは、コンピュータに、
前記所定の領域の中の第1の領域を、その子領域である第2の領域に階層的に分割する場合に、前記第1の領域に前記多次元データを割り当てたときの状態と、前記第2の領域に前記多次元データを割り当てたときの状態とに基づいて示される分割許容条件を満たすか否かを判断する処理と、
前記分割許容条件を満たすと判断された場合には、前記第1の領域を前記第2の領域に階層的に分割する処理と、
前記第2の領域に前記多次元データを割り当てる処理と、
前記第2の領域に前記多次元データを割り当てたときの状態と、前記第1の領域に前記多次元データを割り当てたときの状態とに基づいて示される併合許容条件を満たすか否かを判断する処理と、
前記併合許容条件を満たすと判断した場合には、前記第2の領域を前記第1の領域に併合する処理と、
前記第1の領域に前記多次元データを割り当てる処理と、
を行わせることを特徴とする多次元データ管理プログラムを記録した記録媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29440396A JP3598183B2 (ja) | 1996-10-16 | 1996-10-16 | 多次元データ管理方法、多次元データ管理装置、多次元データ管理プログラムを記録した媒体 |
| US08/951,636 US6137493A (en) | 1996-10-16 | 1997-10-16 | Multidimensional data management method, multidimensional data management apparatus and medium onto which is stored a multidimensional data management program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP29440396A JP3598183B2 (ja) | 1996-10-16 | 1996-10-16 | 多次元データ管理方法、多次元データ管理装置、多次元データ管理プログラムを記録した媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10124528A JPH10124528A (ja) | 1998-05-15 |
| JP3598183B2 true JP3598183B2 (ja) | 2004-12-08 |
Family
ID=17807294
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP29440396A Expired - Fee Related JP3598183B2 (ja) | 1996-10-16 | 1996-10-16 | 多次元データ管理方法、多次元データ管理装置、多次元データ管理プログラムを記録した媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6137493A (ja) |
| JP (1) | JP3598183B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8843525B2 (en) | 2011-06-07 | 2014-09-23 | Samsung Electronics Co., Ltd. | Apparatus and method for calculating the selectivity of a range query for multidimensional data |
Families Citing this family (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6122628A (en) * | 1997-10-31 | 2000-09-19 | International Business Machines Corporation | Multidimensional data clustering and dimension reduction for indexing and searching |
| JP3607107B2 (ja) * | 1998-03-13 | 2005-01-05 | 株式会社東芝 | データ管理装置 |
| US6721759B1 (en) * | 1998-12-24 | 2004-04-13 | Sony Corporation | Techniques for spatial representation of data and browsing based on similarity |
| US7027644B1 (en) | 1999-02-01 | 2006-04-11 | Lg Electronics Inc. | Multilevel image grid data structure and image search method using the same |
| JP2001109760A (ja) | 1999-10-06 | 2001-04-20 | Toshiba Corp | 地理情報表示装置とそれを実行するプログラムを記憶した記憶媒体 |
| US6446068B1 (en) * | 1999-11-15 | 2002-09-03 | Chris Alan Kortge | System and method of finding near neighbors in large metric space databases |
| US7318053B1 (en) * | 2000-02-25 | 2008-01-08 | International Business Machines Corporation | Indexing system and method for nearest neighbor searches in high dimensional data spaces |
| JP3302986B1 (ja) * | 2000-09-20 | 2002-07-15 | 昇 正岡 | 情報管理システム |
| US6996575B2 (en) * | 2002-05-31 | 2006-02-07 | Sas Institute Inc. | Computer-implemented system and method for text-based document processing |
| CN1717883B (zh) * | 2002-11-27 | 2012-05-09 | Rgb网络有限公司 | 用于时分多路复用处理多个数字视频节目的方法和设备 |
| US20040181518A1 (en) * | 2003-03-14 | 2004-09-16 | Mayo Bryan Edward | System and method for an OLAP engine having dynamic disaggregation |
| EP1616401A4 (en) * | 2003-04-21 | 2012-01-04 | Rgb Networks Inc | TIME-MULTIPROUGH MULTIPROGRAM ENCRYPTION SYSTEM |
| CA2537280C (en) | 2003-08-29 | 2014-04-01 | Rgb Networks, Inc. | Advanced, self-balancing video multiplexer system |
| CN101069178A (zh) * | 2004-11-30 | 2007-11-07 | 惠普开发有限公司 | 区域信息的管理装置·方法·程序 |
| US7853669B2 (en) | 2007-05-04 | 2010-12-14 | Microsoft Corporation | Mesh-managing data across a distributed set of devices |
| JP5151394B2 (ja) * | 2007-10-25 | 2013-02-27 | 株式会社リコー | 情報管理装置、情報管理方法、及びプログラム |
| JP5333815B2 (ja) * | 2008-02-19 | 2013-11-06 | 株式会社日立製作所 | k最近傍検索方法、k最近傍検索プログラム及びk最近傍検索装置 |
| KR101420237B1 (ko) * | 2008-02-25 | 2014-07-17 | 삼성전자주식회사 | 이웃 포인트의 탐색이 용이한 3d 영상 처리 방법 |
| US8572033B2 (en) | 2008-03-20 | 2013-10-29 | Microsoft Corporation | Computing environment configuration |
| US9298747B2 (en) * | 2008-03-20 | 2016-03-29 | Microsoft Technology Licensing, Llc | Deployable, consistent, and extensible computing environment platform |
| US9753712B2 (en) | 2008-03-20 | 2017-09-05 | Microsoft Technology Licensing, Llc | Application management within deployable object hierarchy |
| US8484174B2 (en) * | 2008-03-20 | 2013-07-09 | Microsoft Corporation | Computing environment representation |
| US20100185672A1 (en) * | 2009-01-21 | 2010-07-22 | Rising Iii Hawley K | Techniques for spatial representation of data and browsing based on similarity |
| US8411319B2 (en) * | 2009-03-30 | 2013-04-02 | Sharp Laboratories Of America, Inc. | Methods and systems for concurrent rendering of graphic-list elements |
| JP5059132B2 (ja) * | 2010-01-06 | 2012-10-24 | ヤフー株式会社 | 地域情報検索サーバ及び地域情報検索方法 |
| JP5475629B2 (ja) * | 2010-01-12 | 2014-04-16 | 本田技研工業株式会社 | 軌道計画方法、軌道計画システム及びロボット |
| JP5094904B2 (ja) * | 2010-04-13 | 2012-12-12 | ヤフー株式会社 | 地域情報検索サーバ及び地域情報検索方法 |
| US8730235B2 (en) * | 2010-07-14 | 2014-05-20 | Disney Enterprises, Inc. | Method for determining point connectivity on a two manifold in 3D space |
| US20120311474A1 (en) * | 2011-06-02 | 2012-12-06 | Microsoft Corporation | Map-based methods of visualizing relational databases |
| US8730264B1 (en) | 2011-09-26 | 2014-05-20 | Google Inc. | Determining when image elements intersect |
| CN105339931B (zh) | 2013-02-08 | 2020-09-08 | 黄馥萍 | 用于处理数据容器的方法和设备 |
| JP6253053B2 (ja) * | 2013-11-29 | 2017-12-27 | 富士通株式会社 | データ探索装置、データ探索装置の制御方法およびデータ探索装置の制御プログラム |
| US10769175B1 (en) | 2014-06-20 | 2020-09-08 | Amazon Technologies, Inc. | Real-time hosted system analytics |
| EP3158478B1 (en) | 2014-06-20 | 2023-06-07 | Amazon Technologies, Inc. | Embeddable cloud analytics |
| US11868372B1 (en) | 2014-06-20 | 2024-01-09 | Amazon Technologies, Inc. | Automated hierarchy detection for cloud-based analytics |
| US10776397B2 (en) * | 2014-06-20 | 2020-09-15 | Amazon Technologies, Inc. | Data interest estimation for n-dimensional cube computations |
| BR112020025049A2 (pt) * | 2018-06-15 | 2021-03-23 | Panasonic Intellectual Property Corporation Of America | método de codificação de dados tridimensionais, método de decodificação de dados tridimensionais, dispositivo de codificação de dados tridimensionais e dispositivo de decodificação de dados tridimensionais |
| KR102909417B1 (ko) * | 2018-06-27 | 2026-01-08 | 파나소닉 인텔렉츄얼 프로퍼티 코포레이션 오브 아메리카 | 삼차원 데이터 부호화 방법, 삼차원 데이터 복호 방법, 삼차원 데이터 부호화 장치, 및 삼차원 데이터 복호 장치 |
| CN111757108B (zh) * | 2020-07-01 | 2023-03-24 | 格兰菲智能科技有限公司 | 集成电路及递归划分解码区块的方法 |
| CN113713381B (zh) * | 2021-09-09 | 2023-06-20 | 腾讯科技(深圳)有限公司 | 对象管理方法、装置、设备、存储介质及系统 |
Family Cites Families (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63157279A (ja) * | 1986-12-22 | 1988-06-30 | Ricoh Co Ltd | パタ−ン情報の処理方式および演繹方式 |
| JP2577397B2 (ja) * | 1987-09-03 | 1997-01-29 | 株式会社東芝 | 図形表示装置 |
| JPH01106177A (ja) * | 1987-10-19 | 1989-04-24 | Nec Corp | 二次元図形データ検索方法 |
| JPH0646343B2 (ja) * | 1988-11-18 | 1994-06-15 | アルパイン株式会社 | 地図データ検索方法 |
| JPH0561922A (ja) * | 1991-08-30 | 1993-03-12 | Fuji Facom Corp | 画像フアイリング装置 |
| US5592599A (en) * | 1991-12-18 | 1997-01-07 | Ampex Corporation | Video special effects system with graphical operator interface |
| CA2117846C (en) * | 1993-10-20 | 2001-02-20 | Allen Reiter | Computer method and storage structure for storing and accessing multidimensional data |
| JPH07271999A (ja) * | 1994-03-31 | 1995-10-20 | Oki Electric Ind Co Ltd | 3次元地形出力方法 |
| JP3467879B2 (ja) * | 1994-12-20 | 2003-11-17 | 三菱電機株式会社 | 図面データ分散配置装置 |
| JPH08202889A (ja) * | 1995-01-27 | 1996-08-09 | Iyo Eng:Kk | 画像データの分割管理方法及び装置 |
| JP2945601B2 (ja) * | 1995-03-06 | 1999-09-06 | 日本電信電話株式会社 | 対話型図面入力方法 |
| US5877775A (en) * | 1996-08-08 | 1999-03-02 | Theisen; Karen E. | Method of generating a 3-D representation of a hierarchical data structure |
-
1996
- 1996-10-16 JP JP29440396A patent/JP3598183B2/ja not_active Expired - Fee Related
-
1997
- 1997-10-16 US US08/951,636 patent/US6137493A/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8843525B2 (en) | 2011-06-07 | 2014-09-23 | Samsung Electronics Co., Ltd. | Apparatus and method for calculating the selectivity of a range query for multidimensional data |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10124528A (ja) | 1998-05-15 |
| US6137493A (en) | 2000-10-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3598183B2 (ja) | 多次元データ管理方法、多次元データ管理装置、多次元データ管理プログラムを記録した媒体 | |
| Bender et al. | Cache-oblivious B-trees | |
| Arge et al. | Optimal external memory interval management | |
| CN101324896B (zh) | 一种矢量数据的存储方法、查询方法和管理系统 | |
| US20040111406A1 (en) | System and method for processing a hierarchical data tree | |
| JP5237837B2 (ja) | 空間データ管理装置、空間データ管理方法、および、空間データ管理プログラム | |
| JP2005322020A (ja) | ストレージシステム、ファイルアクセス制御プログラム及びファイルアクセス制御方法 | |
| US20220391320A1 (en) | Operation device of convolutional neural network, operation method of convolutional neural network and computer program stored in a recording medium to execute the method thereof | |
| JP2024502119A (ja) | 空間2タプルの決定方法、装置、コンピュータ装置及び記憶媒体 | |
| JP5879445B2 (ja) | 時空間データ管理システム、時空間データ管理方法、及びプログラム | |
| KR102354343B1 (ko) | 블록체인 기반의 지리공간 데이터를 위한 공간 데이터 인덱싱 방법 및 장치 | |
| CN120218241A (zh) | 大语言模型的推理方法、装置、电子设备及介质 | |
| KR102753532B1 (ko) | 그래프기계학습 가속화를 지원하는 계산형스토리지 | |
| CN119106202A (zh) | 一种数据访问模式感知的软硬协同动态图处理设备 | |
| CN116303436A (zh) | 一种基于可扩展多维学习索引结构的数据存储方法及系统 | |
| JP2644735B2 (ja) | 図面情報管理方法 | |
| Ivanov et al. | Zipped Data Structure for Adaptive Mesh Refinement | |
| JPH0228877A (ja) | レンジ分割変更方式 | |
| CN120067713B (zh) | 一种面向动态图的异构协同子图匹配方法 | |
| JP2590327B2 (ja) | 図面情報の管理方法 | |
| KR102943289B1 (ko) | 그래프 쿼리에 적합한 메모리 버퍼 관리 방법 및 이를 위한 컴퓨팅 장치 | |
| JP5434500B2 (ja) | 木構造処理装置及びプログラム | |
| JPH03201045A (ja) | データ管理方式 | |
| KR101656619B1 (ko) | Rbi 그래프 기반의 서브 그래프 리스팅 방법 | |
| CN118799482A (zh) | 可变分辨率的体素化三维建模方法、装置、设备及介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040309 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040415 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040622 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040811 |
|
| 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: 20040907 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040913 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070917 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080917 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080917 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090917 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090917 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100917 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110917 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110917 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120917 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120917 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130917 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |