"複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置であって、前記ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定手段と、前記ツリーノードの前記検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定手段と、前記所定数のエントリデータがカウントされたと判定された場合、前記判定手段の判定処理の対象を前記ツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合手段と、前記ツリーノードのエントリデータが検索条件に一致しないと判定された場合、前記判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、前記検索条件に対する検索結果の概数を算出する算出手段と、を備えることを特徴とする検索装置。前記照合手段は、前記判定手段により前記検索条件に一致する連続した所定数のエントリデータがカウントされた場合に、前記上位の階層のツリーノードに前記判定手段の判定処理を移すことを特徴とする請求項1に記載の検索装置。地理上の領域の検索範囲の指定を取得する取得手段と、前記地理上の領域を複数の部分領域に区分する複数のメッシュから前記検索範囲を覆うメッシュを選定する選定手段と、前記選定手段で選定されたメッシュについて、前記算出手段により前記検索条件に対する検索結果の概数が所定以上になると算出される場合、前記メッシュを更に詳細な部分領域を示すメッシュに分割する分割手段と、前記選定手段で選定されたメッシュまたは前記分割手段で分割されたメッシュの地理上の位置を示すコードを検索文字列として検索を行う検索手段と、を更に備えることを特徴とする請求項1または2に記載の検索装置。前記検索手段は、前記検索文字列の末尾文字を除く文字列が、予め記憶されているメッシュコードと一致するものを検索結果候補として検索することを特徴とする請求項3に記載の検索装置。前記選定手段で選定されたメッシュまたは前記分割手段で分割されたメッシュが前記検索範囲に部分的に含まれる場合、前記検索手段は、当該メッシュの検索結果を除外することを特徴とする請求項3または4に記載の検索装置。前記検索手段の検索結果を表示する表示手段を更に備えることを特徴とする請求項3乃至5のいずれか1項に記載の検索装置。請求項1乃至6のいずれか1項に記載の検索装置を有することを特徴とする画像撮影装置。複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置における検索方法であって、前記検索装置の特定手段が、前記ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定工程と、前記検索装置の判定手段が、前記ツリーノードの前記検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定工程と、前記検索装置の照合手段が、前記所定数のエントリデータがカウントされたと判定された場合、前記判定工程の判定処理の対象を前記ツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合工程と、前記検索装置の算出手段が、前記ツリーノードのエントリデータが検索条件に一致しないと判定された場合、前記判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、前記検索条件に対する検索結果の概数を算出する算出工程と、を有することを特徴とする検索方法。コンピュータを、請求項1乃至6のいずれか1項に記載の検索装置の各手段として機能させるためのプログラム。特許文献1で提案されている方法は、複数の検索条件を組み合わせた際の概数を、処理の負荷を低減した計算によって算出する方式である。しかしながら、特許文献1で提案されている方法では、単一の条件に関する結果数の計数処理についてはコスト削減の効果が得られない。一方、検索装置においては、単一の検索条件を組み合せた複数の検索条件や複雑な条件式で検索する事はむしろ稀である。そのため、単一条件における件数の概数を、検索に要する処理の負荷を低減した計数処理により推定することが課題となっている。本発明は、単一条件における検索結果の概数でも、検索に要する処理の負荷を低減した計数処理により算出することが可能な検索技術を提供する。本発明の一つの側面にかかる検索装置は、複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置であって、前記ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定手段と、前記ツリーノードの前記検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定手段と、前記所定数のエントリデータがカウントされたと判定された場合、前記判定手段の判定処理の対象を前記ツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合手段と、前記ツリーノードのエントリデータが検索条件に一致しないと判定された場合、前記判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、前記検索条件に対する検索結果の概数を算出する算出手段と、を備えることを特徴とする。本発明によれば、単一条件における検索結果の概数を、検索に要する処理の負荷を低減した計数処理により算出することが可能になる。<実施形態1>以下、図面を参照しながら本発明の実施形態を詳細に説明する。図1は、本発明の実施形態1にかかる検索方法を実行することが可能な画像撮影装置の全体構成を示すブロック図である。画像撮影装置としては、例えば、デジタルカメラ、デジタルビデオカメラが含まれ得る。以下の説明では、デジタルカメラ、デジタルビデオカメラを想定して画像撮影装置を例示的に説明する。CPU101は検索処理、写真登録処理、画面制御処理、写真撮影処理等のための演算、論理判断等を行い、バスを介してバスに接続された各デバイスを制御する。BUS106はバスであり、CPU101の制御対象である各デバイスを指示するアドレス信号、コントロール信号を転送する。また、BUS106は各デバイス間のデータ転送を行う。入力部102は、例えば、ボタン、タッチパネル等であり、オペレータは、入力部102を介して各種の指示を行うことが可能である。表示部103は、例えば、液晶ディスプレイ等である。撮像部104は、例えば、撮像センサ等であり、映像を読み取って電子データに変換することが可能である。通信部105は、例えば、ネットワークコントローラであり、有線あるいは無線の通信路を介して外部とのデータ交換を行うことが可能である。ROM107は読出専用の不揮発性メモリである。ROM107はCPU101によるブートプログラム、システムの制御プログラム、後述する処理で使用される末尾文字遷移テーブル、及び各種処理で参照される各種初期データ等を記憶する。ブートプログラムはシステム起動時に初期データをRAM108にロードし、CPU101に制御プログラムを実行させる。制御プログラムについては、後にフローチャートを参照して詳述する。RAM108は読み書き可能なランダムアクセスメモリであって、各デバイスからの各種データの一次記憶に用いる。RAM108には、処理に必要なデータを記憶し、処理中に値変更が行われる各種データが格納される各種ワーク領域、指定される検索範囲を記憶する範囲指定テーブルが格納される。また、検索範囲を覆うメッシュ群を記憶する範囲メッシュテーブル、メッシュの統合および詳細化の際に一時的に作成される前方文字列テーブル、末尾文字テーブル、追加末尾文字テーブル等が格納される。FLASH109は、ブロック単位で一括消去可能な大容量の不揮発性メモリであり、大量のデータを変更可能に記憶するためのものである。FLASH109は、例えば、SDカード、CFカード等のフラッシュメディアであり、ハードディスク等で代用することもできる。FLASH109には、後述する処理で使用する代表位置テーブル、写真テーブル等を保持したリレーショナルデータベースが格納され、必要に応じて随時内容が修正される。尚、CPU101により実行される制御プログラムを、FLASH109に格納する構成も可能である。その場合は、必要に応じてRAM108に示す主記憶にロードし、実行することになる。そのようにすることで固定プログラムではなく、途中で修正可能な柔軟なシステムを構成することができる。実施形態1にかかる検索装置は、上述の各部を有しており、入力部102等からの各種イベントに応じて作動する。入力部102等からのインタラプトが供給されるとインタラプト信号がCPU101に送られる。それに伴ってイベントが発生し、イベントに応じてCPU101がROM107またはRAM108内に記憶されている各種命令を読み出し、CPU101の実行によって各種の制御が行われる。尚、CPU101はプログラムを実行することで各種の手段として機能することが可能である。なお、CPU101と協調して動作するASICなどの制御回路がこれらの手段として機能してもよい。また、CPU101と検索装置の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、CPU101は単一のものである必要はなく、複数であってもよい。この場合、複数のCPUは分散して処理を実行することが可能である。また、複数のCPUは単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、CPUがプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。図2は、地理情報検索の地理範囲指定検索の例を示す図である。図2aは、検索指示前の画面の表示例を示している。画面上にはある地図領域が表示されており、地図上の地点201を黒丸印で示している。矩形202は、地図上の検索範囲を示しており、検索範囲内に内包される地点の検索を行おうとしている。図2bは、検索実行後の画面の表示例を示している。各地点が検索結果となったか、ならなかったかが画面上に表示される。検索結果となった検索範囲に内包される地点はヒット203として丸印で表示され、検索結果とならなかった検索範囲に内包されない地点は非ヒット204としてバツ印で表示される。図3は、実施形態1における地理領域を表現するための地理コード体系を説明する図である。地表を階層的なメッシュで区分し、緯度経度情報に基づいてメッシュの位置を地理コードで表現する。本実施形態においては、地理コードは文字列で表現される。図3aは、緯度経度情報を地理コードに変換する具体例を示している。地表を緯度または経度の方向に沿って2分割していき、分割の度に0又は1のビットを割り当てる。緯度、経度のそれぞれに対して、そのビットを大分割から順番に並べてビット列を作成し、メッシュの緯度情報301及び経度情報302とする。このように生成されたビット列に対して、緯度、経度の順番で先頭から交互に1ビットずつ選択していき、ビット列303を生成する。ビット列303を先頭から5ビットずつに分割し、各5ビットを変換表304に従って文字コードに変換して地理コード305とする。各メッシュは地表の分割回数に応じて階層的に詳細化されたものになる。詳細化されたメッシュほど、緯度経度情報のビット数が多くなり、変換後の文字列の文字数も多くなる。文字数がメッシュの精度を表現することになるので、メッシュの精度を文字列の文字数と定義する。このように生成されたメッシュの地理コードをメッシュコードと呼ぶ。図3bはメッシュが構成する階層構造の例を説明する図である。メッシュ306は地理コード305のeが表現する精度=1すなわち、文字数=1のメッシュであり、図中の1文字を追加することによって下位メッシュに32分割される。ここでは、32進法BASE32を用いている。次の地理コード305の1文字が7の場合は、精度=2のメッシュ307になり、メッシュコードがe7となる。メッシュ308はメッシュ307に対応する下位メッシュである。同様に次の1文字を追加することによって32分割される。次の1文字がsの場合は、精度=3のメッシュ309となり、メッシュコードはe7sとなる。このようにメッシュコードの文字数に応じてメッシュが階層化されていることが分かる。メッシュコードの文字数が同じメッシュ群を、同じ階層に属していると言い表す。このように階層化されたメッシュが表現する地理領域の、赤道付近における概略面積を図3cの表3010に例示する。これによれば、精度=3のメッシュは156km×156kmの矩形を表現することが分かる。精度を大きくすればより詳細な地理領域を表現できる。例えば、精度12のメッシュコードは、1.8cm×3.7cmの概略面積を表現することになり、事実上、地図上の特定の地点を表現することになる。そこで本実施形態においては、地点を特定する場合は、システム上最も詳細な精度のメッシュコードで表現することにしている。図4は、検索範囲を覆うメッシュ群を求める例を示す図である。図4aに示す検索範囲401に対して、これを覆うメッシュが図4bに示すように求められる。検索範囲401は本実施形態の検索装置が提供する地理検索条件指定機能を使いユーザが指定することが可能である。各メッシュ402は、一旦すべて同じ階層に属すように求められる。メッシュのうち、メッシュ全体を検索範囲が内包するメッシュ403を完全内包メッシュと呼び、検索範囲がメッシュを部分的に含む内包するメッシュ404を部分内包メッシュと呼ぶ。完全内包メッシュは更に上位階層のメッシュに統合することが可能である。図4cはメッシュ統合の例を示している。統合されたメッシュ405は4つの完全内包メッシュが下位メッシュとして1つの上位メッシュに置換され統合されている。尚、図3に示した変換方式によれば、階層を1段階上げるためには本来32個のメッシュを統合する必要があるが、ここでは図面スペースの関係で4つのメッシュが1つのメッシュに統合されたとして説明している。図4dはメッシュ詳細化の例を示している。詳細化されたメッシュ406は1つのメッシュが32の各下位メッシュ407に分割され詳細化されている。図5は、撮像部104により撮影された写真等の画像データの属性情報を格納するテーブルの構成を示す図である。写真等の撮影された画像データの撮影地点は、図5aの代表位置テーブルに記憶される。写真等は複数枚まとめて撮影されることが多いので同一地点同一メッシュ範囲で撮影された写真群に対して、代表して1つの撮影地点が設定され、代表位置IDが付与されて代表位置テーブルで管理される。代表位置テーブルのカラム501には撮影地点のメッシュコードが格納され、カラム502には代表位置IDが格納される。写真等に関する他の属性情報は、例えば、図5bに示す写真テーブル中に、写真1枚ごとに情報が記憶される。写真テーブルのカラム503には撮影された個々の写真の識別情報IDが格納され、カラム504には、撮影された写真が撮影された撮影地点の代表位置IDが格納される。カラム505には、写真に関して記憶すべきそれ以外の情報が格納される。図6は、指定された検索範囲を管理するためのテーブルの構成を示した図である。図6aは範囲指定テーブルの構成を示している。指定された地図上の矩形の検索範囲に対して、範囲指定テーブルの左上地点601は、検索範囲の左上の位置にある地点のメッシュコードを保持し、右下地点602は、検索範囲の右下の位置にある地点のメッシュコードを保持する。この指定された検索範囲に対して、それを覆うメッシュ群が設定され、図6bに示すような範囲メッシュテーブルで管理される。例えば、検索範囲603に対しては、メッシュ604、605、606、607が設定される。メッシュ604~607は、地点601,602の上位階層メッシュである。このメッシュ群は、図6bに示す範囲メッシュテーブルで管理される。範囲メッシュテーブルのカラム608には各メッシュのメッシュコードが記憶される。カラム609には、各メッシュの領域を検索範囲が完全に内包するかどうかを示すフラグ完全フラグと呼ぶが記憶される。完全に内包するとき完全内包と呼ぶ1を、部分的に内包するとき部分内包と呼ぶ0を記憶する。この例では、各メッシュには検索範囲に入らない部分が必ず存在しているので、全メッシュに対して部分内包を示す0が記憶されている。図7は、検索範囲を覆うメッシュ群を求める際に使用して、隣接するメッシュのメッシュコードを順次求めるための末尾文字遷移テーブルの構成を示す図である。図7aは、精度が偶数文字数が偶数のメッシュについて使用する偶数精度用末尾文字遷移テーブルである。各セル内に記憶される文字はメッシュの末尾文字を意味し、上下左右に隣接するセルに記憶される文字は該メッシュの上下左右に隣接するメッシュの末尾文字と対応する。例えば、メッシュ701pを示しているの右の文字がrであることから、メッシュコードの末尾がpの偶数精度のメッシュの右隣のメッシュのメッシュコードの末尾はrであることが分かる。図7bは、同様に精度が奇数文字数が奇数のメッシュについて使用する奇数精度用末尾文字遷移テーブルである。同様にメッシュ702bを示しているの右の文字がcであることから、メッシュコードの末尾がbの奇数精度のメッシュの右隣のメッシュのメッシュコードの末尾はcであることが分かる。図7cは、この末尾文字遷移テーブルを使用して検索範囲のメッシュをスキャンしていく状況を示した図である。図中のメッシュコードを、例えば、4pruyqとすると、メッシュコードの末尾文字はqになる。このとき、1段階上位の階層のメッシュ703のメッシュコードは4pruyとなる。メッシュ703の右に隣接するメッシュ704のメッシュコードの末尾文字は、図7bを参照すると、末尾yの右隣りの末尾文字zとなり、メッシュ704のメッシュコードは4pruzとなる。検索範囲705に対する左上地点と右下地点の位置が、範囲指定テーブル706においてメッシュコードで記憶される。このとき、精度6で検索範囲を覆うメッシュを求めるには、まず左上メッシュのメッシュコード4pruykを求める。これは左上地点のメッシュコード4pruykdeを文字数=6にトランケート精度=6なのですることにより実行できる。この後、矢印の方向に沿ってメッシュをスキャンしていく。例えば4pruykから右にスキャンするときは次のように行う。まず、図7aに示す偶数精度用末尾文字遷移テーブルを参照して末尾文字kの右隣の文字sを取得する。次に4pruykの末尾文字kをsに置き換える。これによって、右隣のメッシュのメッシュコード4pruysを生成することができる。下にスキャンするときも同様にしてメッシュコードを求めることができる。このようにスキャンしていくことによって、検索範囲705を覆うメッシュ群のリストが図7dに示すようにリストアップされていく。スキャンに応じて、メッシュコード以外に、指定される検索範囲中での相対位置左上、上、右上、内部、下、完全フラグの情報完全内包か部分内包かも取得できる。図8は、メッシュの統合および詳細化の際に使用するテーブルを説明する図である。図8aは前方文字列テーブルである。メッシュのスキャンの際、末尾文字を除くメッシュコードの前方文字列を前方文字列テーブルのカラム801に記憶する。メッシュコードの文字列判定によって、同じ前方文字列は1つにまとめて格納される。末尾文字は、図8bに示す末尾文字テーブルに記憶していく。末尾文字テーブルのカラム802に末尾文字の文字コードを記憶し、カラム803に完全フラグの値を記憶する。すなわち、メッシュが完全内包か部分内包に応じて1または0を記憶する。また、カラム804にはこのメッシュに含まれる検索結果概数を記録する。検索結果概数はメッシュの詳細化対象である非完全内包メッシュに関してのみ格納される。完全内包メッシュの場合、検索結果概数の欄にはNULLが格納される。ここで検索結果概数が検索装置で事前に定めた所定数を超えるメッシュに関しては更に詳細化され、例えば、図8cに示す追加末尾文字テーブルに1段下位の末尾文字に関する情報が記憶される。追加末尾文字テーブルは末尾文字テーブルと同様にカラム805に末尾文字の文字コードを記録し、カラム806に完全フラグの値が記憶される。前方文字列テーブル図8aと、末尾文字テーブル図8bおよび追加末尾文字テーブル図8cからメッシュコードの情報を合成して、範囲メッシュテーブル図8dが作成される。ここで範囲メッシュテーブルには6桁のメッシュコードと、太枠で示す7桁のメッシュコードの2パターンのメッシュコードが格納されている。4pruyeを始めとする6桁のメッシュコードについては上位階層への統合対象となる。一方4pruyk0を始めとする7桁のメッシュコードについてはメッシュコードが4pruykであるメッシュが1段下位の階層に詳細化されたものである。このとき、完全内包のメッシュ完全フラグの値1を部分内包完全フラグの値0より先に置き、完全フラグの値が同じメッシュについては文字コード順にソートしておく。部分内包のメッシュから得られる検索結果候補に対しては、真に検索範囲にはいっているかどうかをチェック詳細チェックと呼ぶする必要がある。これに対して、完全内包のメッシュは検索範囲に完全に内包されるので、それから得られる検索結果候補に対しては詳細チェックの必要がなく、検索結果と判定できる。完全内包のメッシュを、部分内包のメッシュよりも先に置くことによって、完全内包のメッシュから優先的に検索結果が得られることになる。検索装置を組み込んだ画像撮影装置はリソースの制限が強いので、大量の検索結果を処理しきることが元々できず、大量の処理がある場合は、処理を途中で中断して打ち切ることが通例行われる。完全内包のメッシュを優先することによって、詳細チェックの処理を少なくでき、処理負荷を軽減するという効果が期待できる。尚、ここで想定する大量処理とは検索結果として画面表示用データだけでなくアプリ内に保持する制御データ等、様々なデータをレコードとしてフェッチするため、前述の検索結果件数の概数を得るための処理に比べはるかに処理負荷が大きい。図9は、検索結果数の概数を推定する処理を説明する図である。図9aは分岐したツリーインデックス以下、Bツリーインデックスを示した図である。Bツリーインデックスは、複数の階層を有し、それぞれの階層に複数のエントリデータ以下、エントリを格納するノードが複数配置されている。本実施形態では写真テーブルの代表位置IDカラムにBツリーインデックスが作成されている。Bツリーインデックスはそのエントリとして代表位置IDを複数格納したノードによって構成され、それらは格納する値の大小比較によって上位階層と下位階層とに分岐した階層構造を取る。ノードにはいくつかの種類があり、最も上位に位置するルートノード901、中間がブランチノード902、最も下位に位置するのがリーフノード903である。ブランチノードについてはレコード数が多くなる場合は複数存在し、逆にレコード数が少ない場合は存在しないこともある。写真レコード904へのポインタはブランチノードのみに存在し、ブランチノードはリーフノードのポインタを保持し、ルートノードはブランチノードのポインタを保持する。各ノードには、一意にノードを特定するためのノード番号が付与されている。例えば、ルートノード901のノード番号は1番であり、ルートノード901の左側に記述されている数字が各ノードのノード番号を意味する。例えば、ノード番号3番のリーフノードが格納する代表位置IDは値の小さい順に72、73、75となる。ここで本実施形態の検索装置において実際にBツリーインデックスを用いて検索を行う際には、例えば、次のようなSQLクエリを用いる。SQLの一例はSELECTCOUNTFROM写真テーブル、代表位置テーブルWHERE代表位置テーブルメッシュコードLIKE4pruykである。メッシュコードを地理検索条件として指定することで文字列の前方一致検索が可能となる。これを受けたデータベースエンジンはSQLを解析し、WHERE句の条件式で使用されるメッシュコードを、例えば図5のテーブルを用いて代表位置IDに変換する。変換されたWHERE句の条件指定はWHERE代表位置ID>=72AND代表位置ID<=734となる。これによって以降の検索で代表位置テーブルの参照は不要となる。以上の手順によって書き換えられたSQLを用いた処理手順について、以下に一般的な処理方法と本実施形態を適用した場合の検索処理方法とをそれぞれ説明する。一般的な検索結果のカウント処理手順を示したものが図9bである。まず条件に指定された最小値に合致する代表位置IDをBツリーインデックスのリーフから特定する。その後、条件に指定された最大値を超える代表位置IDが見つかるまで次のエントリを順次評価していく。図9bではまずノード番号3のエントリ72を特定し、その後、エントリ73、75を順次評価する。順次評価を繰り返した後、ノード64のエントリ735で条件に指定された代表位置IDの最大値を超えたと判定される。最後にエントリ732までカウントした値を結果として確定する。この処理手順で必要とされる処理時間は検索でヒットする件数に依存する。この処理手順では、最大値に達するまでアプリケーションに制御を返すことができない。検索結果を画面に表示できる件数には制限があり、所定以上の結果数を厳密にカウントする必要のない画像撮影装置での処理には適さない。これに対し、本実施形態における検索結果数の概数を推定する処理の手順を示したものが図9cである。まず条件に指定された最小値に合致する代表位置IDをBツリーインデックスのリーフから特定する。その後、所定の評価対象のエントリ数の上限に達するまで同一階層のノードについてスキャン処理を行う。スキャン処理では、ノード内に存在する検索条件に合致するエントリかどうかを評価し、合致するエントリの数をカウントアップする。ここで所定の評価対象のエントリ数の上限値については機器の性能に合わせて事前にROM107に記録しておく。たたし、ルートノードについてはこれ上位の階層のノードが存在しないため、スキャン処理では全てのエントリを評価する。評価対象のエントリ数の上限に達し、なお条件に一致し続ける場合は次の評価対象のエントリを現在評価中のBツリー階層の次のエントリではなく、上位階層の次のエントリにスキャン処理をスキップする。図9cではノード番号3のエントリ72、73、75を順次評価したが、評価対象のエントリ数の上限である3に達してなお条件に一致し続けるため上位の階層のノード番号2の親エントリ72の次のエントリ89を評価している。また、ここで上位の階層のノードに評価対象を移す前に、現階層の各ツリーノードに存在するカウント対象となるエントリデータ数の平均値平均エントリ数を記録しておく。これは最終的に概数を算出するためのエントリ数推定情報として使用する。以降、同様に同一階層内のエントリを順次評価し、更に評価対象のエントリ数の上限に達してなお条件に一致し続ける場合は上位階層のエントリを照合するように評価対象を移す。このような処理を最終的に検索条件で指定された最大値を超える代表位置IDが見つかるまで繰り返す。図9cでは最終的にルートノード901の末尾エントリ892に到達し、条件に指定された最大値を超える代表位置IDが見つかったと判定される。最後に検索結果の概数を推定し処理を終了する。検索結果の概数は導出式1によって算出することが可能である。検索結果概数=階層Nで条件に合致するノードの平均エントリ数×階層N1で条件に合致するノードの平均エントリ数×階層N2で条件に合致するノードの平均エントリ数×1NはBツリーインデックスの階層数ここで図9aのBツリーに対して図9b、図9cで示すそれぞれの方式での計算処理の負荷を比較してみる。ここで、画像撮影装置の画面表示に必要なデータは4件であり、それぞれの階層で上限合致するノードの平均エントリ数をそれぞれ4とする。また所定の評価対象のエントリ数の上限が4に設定されていたとする。これを図9bの方式で処理した場合、評価対象のエントリ数は41エントリであり、オーバーヘッドは37エントリ分=41-4の評価となる。一方、図9cの方式で処理した場合、評価対象のエントリ数は12エントリであり、オーバーヘッドは8=12-4となる。実際にはこれに概数を計算するための計算処理の負荷を考慮する必要があるが、FLASHメモリからデータを読み込む処理に比べればごく僅かの時間で済む。以上の手順により、検索でヒットする件数の影響を受けずに高速に検索ヒット件数の概数を推定する事ができる。実施形態1にかかる上述の検索処理の流れを図10のフローチャートに従って説明する。図10は実施形態1の検索装置のCPU101の処理手順を示す。ステップS1001において、CPU101は、検索装置の初期化処理として、各種パラメータの初期化や初期画面の表示等を行う。ステップS1002において、CPU101は、例えば、タッチパネル等の入力部102を介した指示により何らかのイベントが発生するのを待機する。イベントが発生すると、ステップS1003において、CPU101がこのイベントの種類を判別し、ステップS1004において、CPU101はイベントの種類に応じて各種の処理を実行する。イベントの種類に応じた処理として、検索処理図11、写真登録処理図15を後に詳細に説明する。他の処理としては、画面制御処理、写真撮影処理などの処理がある。ステップS1005において、CPU101は上記の各処理の処理結果や処理終了をユーザに通知するための表示処理を行う。検索結果出力の画面表示、エラーがあった場合のエラー表示、正常な処理が行われた場合の画面表示への反映などの処理が本ステップで実行される。ステップS1005の表示処理の終了後、処理はステップS1002に戻され、次のイベント待ちの状態でCPU101は待機する。新たなイベントが発生した場合S1002、ステップS1003~S1005の処理が同様に繰り返される。図11は、検索処理の詳細な流れを説明するフローチャートである。本処理は、CPU101により実行される。まず、ステップS1101において、検索範囲を取得する。すなわち、検索範囲を取得して範囲指定テーブルを設定する。この検索範囲は、例えば、図4の検索範囲401に示すものであり、検索装置が提供する地理検索条件指定機能を使いユーザが地理上の領域を指定することが可能である。ステップS1102において、図12に詳述するようにメッシュ群選定処理を行う。地理上の領域を複数の部分領域に区分する複数のメッシュから、先のステップS1101で取得された検索範囲を覆うメッシュ群を選定し、範囲メッシュテーブルを作成する。範囲メッシュテーブルは、例えば、先に説明した図6bに示すテーブルであり、図6aの検索範囲603に対しては、4つのメッシュ604、605、606、607が設定され、範囲メッシュテーブルで管理される。範囲メッシュテーブルのメッシュコード図6bのカラム608を参照することにより各メッシュを特定することができる。また、図6bのカラム609を参照することにより、検索範囲に対して各メッシュが完全内包メッシュであるか部分内包メッシュであるかを判定することできる。ステップS1103において、範囲メッシュテーブルからメッシュを1つずつ順番に取得する。範囲メッシュテーブルは完全内包メッシュから優先されるようにソートされて作成されているため、完全内包メッシュが部分内包メッシュに優先して取得される。ステップS1104において、取得されたメッシュのメッシュコードを検索文字列として設定する。ステップS1105では、先のステップS1104で設定された検索文字列に対して検索結果候補取得を行う。代表位置テーブル例えば、図5aを検索して、設定された検索文字列の末尾文字を除く前方文字列が、代表位置テーブルに記憶されている撮影地点のメッシュコードと一致するものを抽出してリストアップする。抽出されたメッシュコードが検索結果候補となる。ステップS1106において、今回、範囲指定テーブルから取得されたメッシュが完全内包メッシュか部分内包メッシュであるかを判定する。完全内包メッシュの場合S1106-Yes、今回の検索処理でリストアップされた検索結果候補をすべて正式な検索結果として、ステップS1108に処理を進める。一方、ステップS1106の判定で、部分内包メッシュの場合S1106-No、処理はステップS1107に進められ、検索範囲に内包されない検索結果を偽検索結果として除外するための処理偽検索結果除外処理を行う。本処理の具体的な処理の流れは図14の参照により後に詳細に説明する。偽検索結果除外処理により、ステップS1105で見つかった検索結果の候補のうち真の検索範囲に入らないものは除外される。ステップS1108において、これまでに検出された検索結果数が所定数例えば、100件を超えたかどうかを判定し、所定数を超えていればS1108-Yes、それ以上処理しきれないので処理を中断してリターンする。一方、ステップS1108において、検索結果数が所定数以下である場合S1108-No、処理はステップS1109に進められる。ステップS1109では、範囲メッシュテーブルに未処理のメッシュがまだ存在するかを判定し、未処理のメッシュが存在すれば、処理はステップS1102に戻され、次のメッシュを範囲指定テーブルから取得して、以下同様の処理を繰り返す。図12はステップS1102図11のメッシュ群選定処理の具体的な処理の流れを説明するフローチャートである。本処理は、CPU101により実行される。ステップS1201において、検索範囲の面積を求める。面積Sは最も詳細な精度nとするで必要なメッシュ数として、縦方向に必要なメッシュ数と、横方向に必要なメッシュ数とを乗算することで求める。ステップS1202において、適正な精度Nの推定を行う。ここでは、検索範囲が正方形に近い形を例にして、それを覆うメッシュ群のメッシュ数が所定個数以下となる精度、例えば、32以上64未満となる精度が適正であると想定して計算する。初期値N=nから開始して、精度が1段階変わるごとにメッシュ数が32倍変化することから、面積Sを32で除算して商が2以上ならばNを1減算し、商整数を新たな面積Sとする操作を繰り返していく。ステップS1203では、ステップS1202で推定された適正精度Nにより検索範囲を覆うメッシュ群を求め、図8に示した前方文字列テーブル、末尾文字テーブルを作成し、完全フラグを設定する。ステップS1204において、前方文字列テーブル、末尾文字テーブルを参照し、文字列判定して共通の前方文字列を持つメッシュ群を取得する。ステップS1205において、それらのメッシュ群のうち完全内包となっているメッシュ数が所定個数存在するか判定する。所定個数として、ここでは32以上存在するかを判定する。所定数以上でなければS1205-No、ステップS1211に分岐する。所定数以上ならS1205-Yes、ステップS1206において、上位階層のメッシュに統合する。ここでは、例えば、前方文字列4pruyに対して、prxなどで構成される32個の末尾文字が全て完全内包となっていた場合、このメッシュ群を1個の上位メッシュコードに統合する。統合されたメッシュコードの末尾文字を末尾文字テーブル例えば、図8bに追加して、末尾文字テーブルを修正更新する。ステップS1205において、完全内包となっているメッシュ数が所定個数以上存在しない場合S1205-No、処理はステップS1211に進められ、メッシュの詳細化を行う。ステップS1211からステップS1213までの処理については評価中の前方文字列に対応する末尾文字テーブルの全てのレコードに対して処理を行うループ処理である。ステップS1211では、前方文字列テーブルと末尾文字テーブルの文字とを連結したメッシュコード内に含まれる検索結果の概数を取得する。次に、ステップS1212において、検索結果の概数が所定数以上であるかを判定し、所定数X件以上であればS1212-Yes、ステップS1213に進む。ステップS1213では、ステップS1102で選定されたメッシュを更に詳細な部分領域を示すメッシュに分割する。本ステップでは、ステップS1202で求められた精度Nよりも高い精度を示す精度N1で、検索範囲を覆うメッシュ群を求め、図8に示した前方文字列テーブル、末尾文字テーブルを作成する。これにより検索装置の検索結果を表示出力する領域の表示精度を詳細化する表示精度詳細化処理。ステップS1207において、前方文字列テーブルから次の前方文字列を取得する。ステップS1208において、すべての前方文字列の処理が終了したかを判定し、終了していなければS1208-No、処理はステップS1204に戻され、同様の処理が繰り返される。すべての前方文字列の処理が終了している場合S1208-Yes、処理はステップS1209に進められる。ステップS1209において、前方文字列テーブルと末尾文字テーブルを参照して、完全内包となっているメッシュについて、メッシュコードのリストを作成し、文字コード順に範囲メッシュテーブル図6bに登録する。ステップS1210において、前方文字列テーブルと末尾文字テーブルを参照して、部分内包となっているメッシュについて、メッシュコードのリストを作成し、文字コード順に範囲メッシュテーブル図6bに追加登録し、本処理を終了する。図13は、ステップS1211の検索結果の概数を取得する具体的な処理検索ヒット件数の概数推定処理の流れを説明するフローチャートである。本処理は、CPU101により実行される。ステップS1301において検索条件に合致する最初のツリーノードを特定する。最初のツリーノードが検索の起点となる。その後、ステップS1302、ステップS1303、ステップS1304を一連の処理手順とするスキャン処理を繰り返す。まず、ステップS1302において、ツリーノードのエントリが検索条件に一致するか否かを判定し、一致する場合S1302-YesはステップS1303に進む。ステップS1303において評価中のBツリーインデックスの階層において所定数例えばY件Y:自然数のエントリに対して検索条件に一致するかどうかを判定する。所定数のエントリをまだ評価していない場合はステップS1304に進み、評価対象を次のエントリに進める。検索条件に一致する連続した所定数のエントリがカウントされたことにより所定数のエントリについて評価済となった場合S1303-Yes、ステップS1305に処理は進められる。そして、ステップS1305において、評価中である現在のBツリーインデックスの現階層のノード内に含まれる検索条件に合致するエントリ数の平均値を算出し記録する。ステップS1306では、現在のBツリーインデックススの階層よりも上位の階層のツリーノードに、ステップS1302~S1303における判定処理の対象を移すスキップ処理。以降、同様の手順をステップS1302にてエントリが条件に一致しないと判定されるまで繰り返す。エントリが条件に一致しないと判定された場合S1302-No、処理はステップS1307に進められ、検索結果の概数を、図9cの説明で参照した導出式1によって算出し、本処理を終了する。尚、一度も上位のBツリーの階層のノードに評価対象を移動させる必要が無かった場合、カウント数は概数でなく実際のカウント値となる。図14は検索範囲に内包されないメッシュについての検索結果を偽検索結果として除外する具体的な処理偽検索結果除外処理の流れを説明するフローチャートである。本処理は、CPU101により実行される。ステップS1401において、検索結果候補を1つずつ順次取得する。ステップS1402において、検索結果候補を取得できたかどうか判定する。すべての候補について処理が終了しており、検索結果候補が取得できなかったとき本処理は終了する。ステップS1402において、検索結果候補を取得できた場合S1402-Yes、処理はステップS1403に進められる。ステップS1403において、取得された検索結果候補が、もともとの範囲指定テーブルが規定する検索範囲に入っているかどうかを判定する。判定は、検索範囲が矩形の場合、左上地点と右下地点の緯度経度情報を判定することにより行う。検索範囲に入っていればS1403-Yes、ステップS1405に処理は進められる。一方、ステップS1403の判定で検索範囲に入っていなければS1403-No、ステップS1404に進み、その検索結果候補をリストから除外する。ステップS1405において、次の検索結果候補を取得し、ステップS1402以降の処理を繰り返す。ステップS1402の判定で、検索結果候補が取得できないと判定された場合S1402-No、本処理は終了する。図10のステップS1004における各種イベント対応処理として、写真登録処理の具体的な流れを図15のフローチャートを参照して説明する。本処理は、CPU101により実行される。ステップS1501において、指定された写真の撮影地点が既に代表位置テーブル例えば、図5aに登録されているかどうか確認する。ステップS1502において、撮影地点が既登録か判定し、既登録でなければS1502-No、ステップS1503に処理は進められる。ステップS1503において、撮影地点に対して新規の代表位置IDを付与して、撮影地点を代表位置テーブルに登録する。一方、ステップS1502の判定において、既登録であればS1502-Yes、処理はステップS1504に進められる。そして、ステップS1504において、既登録のIDを取得して、このIDを撮影地点の代表位置IDとする。ステップS1505において、指定された写真の情報を、ステップS1503またはS1504で求めた代表位置IDの情報と共に、写真テーブルに登録し、本処理を終了する。尚、図15の処理では、画像撮影装置としてデジタルカメラにより撮影された写真の登録を例として説明したが、この例に限定されず、例えば、デジタルビデオカメラにより撮影された動画を登録する場合にも適用可能である。実施形態1の構成によれば、実際のヒット件数を求めることなく、単一条件における検索結果の概数を、検索に要する処理の負荷を低減した計数処理により計算することが可能になる。また、メッシュを細かく分割して検索範囲内に存在する完全内包メッシュをより多く作成することが可能となり、検索の精度を向上させることができる。<実施形態2>なお、本発明は上述の実施形態1に限定されるのではなく、本発明の趣旨を逸脱しない限りにおいて適宜変更が可能である。例えば、検索条件を満たすBツリーのノード数をカウントして検索結果件数の概数を推定することも可能である。与えられた検索条件に合致するか否かの判定をBツリーインデックスのルートノード上のエントリに限定して行い、そのエントリの下層に存在するノード数をカウントする処理を行うことで検索結果件数の概数を推定する方法も考えられる。これによりインデックスのエントリデータを取り出して判定する計算コストも省略可能となるため、更に計算負荷を軽減して検索結果件数の概数を推定することができる。本発明は他にも日付や被写体名等を用いた条件を同時に満たす写真を検索する複合条件検索におけるインデックス選定処理にも適用できる。ここで日付、被写体名それぞれにインデックスが作成されていた場合を想定する。通常どちらのインデックスを利用すればより少ない計算量で結果が推定できるかを判断するには事前にデータを分析し、記憶しておく必要がある。この処理を、検索装置を組み込んだ画像撮影装置上で処理するには計算の負荷が大きい。しかしながら、本発明を適用すれば検索結果概数を軽量に推定できるため、事前にデータの実数を分析すること無く検索に有効なインデックスを選定することが可能になる。その他の実施例また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェアプログラムを、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータまたはCPUやMPU等がプログラムを読み出して実行する処理である。"