(57)【要約】【課題】全文検索エンジンでプローブデータを検索する【解決手段】データ処理システムが、点列データの点データ毎にハッシュ文字列と属性情報と日時とを対応付けて１つのレコードに格納した第１の表構造データを生成し、点列データに含まれる全ての点データのハッシュ文字列を、第１の表構造データの各レコードに格納した順序にて１つのレコードに格納した第２の表構造データを生成し、第１の表構造データの各レコードを、設定された所定のトークナイザによりトークンに分割しトークン毎に識別情報と対応付けて格納した第１のインデクスデータを生成し、第２の表構造データの各レコードに含まれるハッシュ文字列を、設定された所定のトークナイザによりトークンに分割しトークン毎に第２の表構造データの当該レコードにおける位置をそれぞれ識別する識別情報と対応付けて格納した第２のインデクスデータを生成する。【選択図】図６
2015035015.tif 000002
【特許請求の範囲】
【請求項１】
点の位置情報と属性情報と日時とをそれぞれ含む連続した点データから構成される点列データを解析することにより、前記点列データを検索する際に用いられるインデクスデータを生成するデータ処理装置であって、
前記点列データに含まれる各点データ毎に前記位置情報をハッシュ文字列に変換し、前記ハッシュ文字列と前記属性情報と前記日時とを対応付けて１つのレコードに格納した第１の表構造データを生成する手段と、
前記点列データに含まれる全ての点データの前記ハッシュ文字列を、前記第１の表構造データの各レコードに格納した順序にて１つのレコードに格納した第２の表構造データを生成する手段と、
前記第１の表構造データの各レコードに含まれる前記ハッシュ文字列と前記属性情報と前記日時とを、設定された所定のトークナイザによりトークンに分割し、各トークン毎に、前記点列データと前記第１の表構造データにおけるレコードと当該レコードにおける位置とをそれぞれ識別する識別情報と対応付けて格納した第１のインデクスデータを生成する手段と、
前記第２の表構造データの各レコードに含まれる前記ハッシュ文字列を、設定された所定のトークナイザによりトークンに分割し、各トークン毎に、前記点列データと前記第２の表構造データの当該レコードにおける位置とをそれぞれ識別する識別情報と対応付けて格納した第２のインデクスデータを生成する手段と、を備えたことを特徴とする
データ処理装置。
【請求項２】
点列データの検索条件として、当該点列データに含まれる１または複数の点データについて、当該１または複数の点データの各々のハッシュ文字列、属性情報及び日時を含む第１の検索クエリと、当該１または複数の点データの順序に関する第２の検索クエリと、を入力される手段と、
前記第１の検索クエリを、設定された所定のトークナイザによりトークンに分割し、分割した各トークン毎に前記第１のインデクスデータから該当するレコードを抽出し、抽出したレコードの中から同一の識別情報をもつレコードを絞り込む第１の検索手段と、
前記第２の検索クエリを、設定された所定のトークナイザによりトークンに分割し、分割した各トークンのいずれとも対応付けをもつ点列データの識別情報を前記第２のインデクスデータから抽出することを少なくとも含む第２の検索手段と、を備えたことを特徴とする、
請求項１に記載のデータ処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理装置に関し、特に、コンピュータ上のプローブデータを検索するためのデータ処理装置に関するものである。
【背景技術】
【０００２】
近年、情報技術やGPSの発達により、GPSが様々なデバイスに搭載されるようになっている。GPSから取得したプローブデータと呼ばれる移動軌跡情報(各点に日時及び経緯度等の情報を持った連続した点列)がサーバで集約され、様々な解析に利用されている。
【０００３】
例えば、船から取得したプローブデータを解析することにより、船が港間をどのような経路で航行したかを把握することができる。この場合例えば、ロンドンから横浜に航行する際は、ロンドンからスエズ運河を経由して横浜に向かうケースが多く、ロンドンから北極海を経由して横浜に向かうケースは少ない、といったことがわかる。
【０００４】
また、近年コンピュータ及び検索エンジンの発達により、ハードディスクなどの記憶装置上に格納された様々なファイルを検索可能となっている。
【０００５】
例えば、全文検索エンジンSolr(非特許文献１)では、ファイル内のテキストデータを検索可能である。Solrは、ドキュメント毎にデータの種類を区別した検索(属性検索)を行うことが可能である。データの種類(属性)は、Solrではフィールドと呼ばれ、フィールド名で区別される。Solrに対して、[フィールド名]:[検索式]のような検索クエリを与えると、フィールドを指定した検索が可能である。例えば、ファイル名のフィールド名が「fileName」、本文のフィールド名が「contents」である場合に、fileNameが「sample.txt」、contents内に「サンプル」を含むドキュメントを検索する際には、「fileName:sample.txt AND contents:サンプル」のような検索クエリをSolrに与えることにより検索可能である。なお、Solrでは「AND」や「OR」のような論理演算子を使用することも可能である。ANDは論理積を表し、ORは論理和を表す。また、Solrを導入したサーバを複数連結させてスケーラビリティを向上させることも可能である。これにより、数億個のドキュメントを検索対象とすることも可能である。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】関口宏司, “Apache Solr入門”, 技術評論社, 2010
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、非特許文献１の技術では、プローブデータのような連続した点列データに対して、インデクス生成し、経路を検索条件とした検索を行うことが困難である。例えば、図２（ｂ）に示すように、X座標、Y座標、時刻が、それぞれXa,Ya,Taである点A(以降、(Xa,Ya,Ta)と表記する)、点B(Xb,Yb,Tb)、点C(Xc,Yc,Tc)で構成されるプローブデータをインデクス生成し、範囲P(Xpmin≦X≦Xpmax, Ypmin≦Y≦Ypmax, Tpmin≦T≦Tpmax)、範囲Q(Xqmin≦X≦Xqmax, Yqmin≦Y≦Yqmax, Tqmin≦T≦Tqmax)、範囲R(Xrmin≦X≦Xrmax, Yrmin≦Y≦Yrmax, Trmin≦T≦Trmax)を順に通過したプローブデータを検索し、前述のプローブデータを検索結果として取得することができない。Solrでは、プローブデータのように複数の点それぞれに日時及び経緯度などの属性情報を持つデータをインデクス生成及び検索ができないためである。
【０００８】
本発明は、このような状況に鑑みてなされたものであり、プローブデータのような連続した点列データに対して、インデクス生成し、経路を検索条件として検索可能にするデータ処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記目的を達成するために、本発明の態様は、点の位置情報と属性情報と日時とをそれぞれ含む連続した点データから構成される点列データを解析することにより、前記点列データを検索する際に用いられるインデクスデータを生成するデータ処理装置であって、
前記点列データに含まれる各点データ毎に前記位置情報をハッシュ文字列に変換し、前記ハッシュ文字列と前記属性情報と前記日時とを対応付けて１つのレコードに格納した第１の表構造データを生成する手段と、
前記点列データに含まれる全ての点データの前記ハッシュ文字列を、前記第１の表構造データの各レコードに格納した順序にて１つのレコードに格納した第２の表構造データを生成する手段と、
前記第１の表構造データの各レコードに含まれる前記ハッシュ文字列と前記属性情報と前記日時とを、設定された所定のトークナイザによりトークンに分割し、各トークン毎に、前記点列データと前記第１の表構造データにおけるレコードと当該レコードにおける位置とをそれぞれ識別する識別情報と対応付けて格納した第１のインデクスデータを生成する手段と、
前記第２の表構造データの各レコードに含まれる前記ハッシュ文字列を、設定された所定のトークナイザによりトークンに分割し、各トークン毎に、前記点列データと前記第２の表構造データの当該レコードにおける位置とをそれぞれ識別する識別情報と対応付けて格納した第２のインデクスデータを生成する手段と、を備えたことを特徴とする。
【００１０】
上記態様において、点列データの検索条件として、当該点列データに含まれる１または複数の点データについて、当該１または複数の点データの各々のハッシュ文字列、属性情報及び日時を含む第１の検索クエリと、当該１または複数の点データの順序に関する第２の検索クエリと、を入力される手段と、
前記第１の検索クエリを、設定された所定のトークナイザによりトークンに分割し、分割した各トークン毎に前記第１のインデクスデータから該当するレコードを抽出し、抽出したレコードの中から同一の識別情報をもつレコードを絞り込む第１の検索手段と、
前記第２の検索クエリを、設定された所定のトークナイザによりトークンに分割し、分割した各トークンのいずれとも対応付けをもつ点列データの識別情報を前記第２のインデクスデータから抽出することを少なくとも含む第２の検索手段と、を備えることが好適である。
【発明の効果】
【００１１】
本発明によれば、全文検索エンジンを使用して、点列データ(例えばプローブデータ)に対して、各点が通過した経路、各点の属性を指定して検索可能となる。また、検索時には、点列データが含む全ての点データを検索クエリとして指定せずに一部の点データを省略することも可能である。また、点の範囲の大小をフレキシブルに指定可能である。
なお、上述した以外の課題、構成及び効果は、以下の本発明を実施するための形態および図面によって明らかになるものである。
【図面の簡単な説明】
【００１２】
【図１】図１は、本発明の実施形態に係るデータ処理装置の概略構成を示す図である。
【図２】図２は、プローブデータの一例を示す図である。
【図３】図３は、設定データの一例を示す図である。
【図４】図４は、インデクスデータの一例を示す図である。
【図５】図５は、Tableデータ及びOrderデータの一例を示す図である。
【図６】図６は、検索画面の一例を示す図である。
【図７】図７は、中間データ生成処理を説明するためのフローチャートである。
【図８】図８は、インデクス生成処理の概要を説明するためのフローチャートである。
【図９】図９は、インデクス生成処理の詳細を説明するためのフローチャートである。
【図１０】図１０は、検索処理の概要を説明するためのフローチャートである。
【図１１】図１１は、検索処理の一部を説明するためのフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。
【００１４】
以後の説明では「プログラム」を主語として説明を行うが、これは、プログラムがプロセッサによって実行されることにより、定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うことに基づいている。また、プログラムを主語として開示された処理は、管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていてもよい。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。プログラムを実行するためのこれらの装置を「データ処理装置」と称する。
【００１５】
また、本発明の処理対象の点列データとしてプローブデータを用いた例について説明するが、処理対象の点列データはプローブデータに限られない。
【００１６】
＜データ処理装置の構成＞
図１は、本発明の実施形態によるデータ処理装置の概略構成を示す機能ブロック図である。このデータ処理装置は、必要な演算処理及び制御処理等を行う中央処理装置（プロセッサ）100と、データの入出力を行うための入出力装置110と、中央処理装置100での処理に必要なプログラムを格納するプログラムメモリ120と、中央処理装置100での処理対象となるデータまたは処理後のデータを格納する記憶装置130と、プログラムが処理過程で生成する中間データを格納するデータメモリ140と、を有している。
【００１７】
入出力装置110は、データを表示するための表示装置111やプリンタ（図示せず）等で構成される出力デバイスと、表示されたデータに対してメニューを選択するなどの操作を行うためのキーボード112、マウスなどのポインティングデバイス113と、を有している。
【００１８】
プログラムメモリ120は、プローブデータをもとに表構造をもつ中間データであるTableデータとOrderデータとを生成する中間データ生成プログラム121と、Tableデータ及びOrderデータをもとに検索用のインデクスデータを生成するインデクス生成プログラム122と、ユーザにより入力された検索クエリをもとにインデクスデータを用いて該当するプローブデータを検索する検索プログラム123と、経緯度などの位置情報とジオハッシュとの変換を行うジオハッシュ変換プログラム124と、を格納している。なお、各処理プログラムは、プログラムコードとしてプログラムメモリ120に格納されており、中央処理装置100が各プログラムコードを実行することによって各処理が実現される。
【００１９】
記憶装置130は、プローブ情報であるプローブデータ131と、プログラムを実行する上での設定情報である設定データ132、検索用のインデクスであるインデクスデータ133とを、格納している。なお、記憶装置130は、ネットワークを介して遠隔的に配置されていているストレージシステムであってもよい。
【００２０】
データメモリ140は、プローブデータ131をもとに生成されるTableデータ141及びOrderデータ142を格納している。また、プログラムを実行する際に一時的に使用されるデータ(図示せず)が格納される。
【００２１】
以上に述べた各プログラム及び各データ等は、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＭＯ、フロッピー（登録商標）ディスク、ＵＳＢメモリ等の種々の記録媒体に格納して提供することもできる。
【００２２】
＜プローブデータ＞
図２（ａ）は、図１に示した記憶装置130内のプローブデータ131の一例を示す図である。記憶装置130内のプローブデータ131は、実際はプローブデータ群として格納されているが、以下では、プローブデータ群のうちの１つのプローブデータをプローブデータと称することとする。１つのプローブデータは、点列データの一例であり、１件のプローブ実行により得られた連続した複数の点データから構成されている。１つのプローブデータ131は、識別用ＩＤであるID201毎に格納されている。１つのプローブデータ131における各点データには、日時202、緯度203、経度204などのデータが含まれる。複数の点データは、日時が古いデータから順に格納されている。
【００２３】
＜設定データ＞
図３は、図１に示した記憶装置130内の設定データ132の一例を示す図である。設定データ132には、本発明で使用される各種パラメータが設定され、例えばXML形式で保存される。fieldType301、304は、インデクス生成時及び検索時に使用するフィールドの定義情報すなわちフィールドタイプがそれぞれ格納されており、name属性でフィールド名が設定される。ここでは、fieldType301は、１つの点データ自体に関連するポイントフィールド（以下「pointフィールド」と表記）である。fieldType304は、複数の点データの順序に関連するオーダーフィールド（以下「orderフィールド」と表記）である。tokenizer303、305は、インデクス生成時及び検索時に文字列をトークナイズする際に使用されるトークナイザ(以下「tokenizer」と表記)の情報が格納される。トークナイズとは、文字列をトークン(以下「Keyword」と表記)に分割する処理である。例えばtokenizer303に設定されているWhitespaceTokenizerは、空白文字をKeywordの区切りと認識してKeyword分割を行う。tokenizerは様々な種類があり、任意のものが適用可能である。tokenizer302に設定されているcolumnTokenizerはプローブデータ131から生成されるTableデータや、検索クエリを解析するためのtokenizerである。columnTokenizerは、フィールドタイプのname属性がpointであった場合に設定される。
【００２４】
＜Tableデータ＞
図５（ａ）は、図１に示したデータメモリ140内のTableデータ141の一例を示す図である。図５（ａ）は、図２（ａ）のプローブデータ131をTableデータに変換した例を示している。Tableデータ141は、プローブデータ131をもとに表形式に変換したデータである。Tableデータ141は、DocID501、RowID502、ColumnID503で構成される。さらにColumnID503は、3列のデータ(504、505、506)で構成される。DocID501は、プローブデータ毎に設定される識別用IDであり、図２のID201を付け替えたものである（ID201が一意であればそのまま用いてもよい）。RowID202は、１つのプローブデータ内の各点データ毎に設定される識別用IDである。ColumnID503の各々504〜506は、列の識別用IDである。ColumnID503の１列目504（ColumnID「1」）は、当該点データの経緯度から算出した位置情報を表すハッシュ文字列すなわちジオハッシュである。ジオハッシュとは、経緯度に基づくジオコーディング方法の一つである。階層的な空間データ構造であり、空間を分割していくことによって表現する。ジオハッシュは、任意の精度で表現できる、文字列の末尾を削っていくと徐々に精度が落ちる、といった特徴がある。例えば元の点データの緯度経度がそれぞれ「50.801」「-1.099」であった場合、５文字のジオハッシュで表した場合は「gcp1p」となる。ColumnID503の２列目505（ColumnID「2」）は、当該プローブデータにおける当該点データの属性を表す。１つのプローブデータにおいて、「start」は始点、「mid」は途中点、「end」は終点を表す。ColumnID503の３列目506（ColumnID「3」）は当該点データの日時を表し、「YYYYMMDDhhmmss」の形式で表す。例えば「2013年1月1日0時0分0秒」であれば、「20130101000000」となる。
【００２５】
図示の例では、ColumnID503の各列内に１つの文字列のみ格納されているが、１つの列のデータ内に複数の文字列を含む場合は、図３の設定データによりpointフィールドに対して設定されたtokenizerにより区切るものとする。
【００２６】
＜Orderデータ＞
図５（ｂ）は、図１に示したデータメモリ140内のOrderデータ142の一例を示す図である。図５（ｂ）は、図２（ａ）のプローブデータ131をOrderデータに変換した例を示している。Orderデータ142は、直接的にはTableデータ141をもとに生成されるデータである。Orderデータ142は、DocID507及びジオハッシュ508で構成される。DocID507は、Tableデータ141におけるDocID501と同じである。ジオハッシュ508には、Tableデータ141において同じDocID501をもつ全ての行のColumnID503の１列目504のジオハッシュが始点から順に格納される。ジオハッシュ508内の複数のジオハッシュは、図３の設定データによりorderフィールドに対して設定されたtokenizer（この場合は空白）で区切られている。
【００２７】
＜インデクスデータ＞
図４は、図１に示した記憶装置130内のインデクスデータ133の一例を示す図である。インデクスデータ133は、Tableデータ141及びOrderデータ142をもとに、設定データ132に設定されたフィールドタイプ毎に生成される。図４（ａ）は、Tableデータ141から生成されたpointフィールドのインデクスデータである。また、図４（ｂ）は、Orderデータ142から生成されたorderフィールドのインデクスデータである。インデクスデータ133は、図４（ａ）（ｂ）のようなデータで構成される。
【００２８】
図４（ａ）のpointフィールドのインデクスデータにおけるKeyword401は、図５（ａ）のTableデータ141におけるColumnID503の３列の各列におけるデータ内の１または複数の文字列を、pointフィールドに対して設定されたtokenizerにより分割したKeyword単位で格納される。DocID402は、Tableデータ141における当該Keyword401のDocID501と同じである。RowID403は、Tableデータ141における当該Keyword401のRowID502である。ColumnID404は、Tableデータ141における当該Keyword401が出現する列のColumnID504〜506のいずれかを格納する。Position405は、図５のTableデータ141における当該DocIDの当該ColumnIDにおいて、当該Keyword401が出現する位置を表す。この位置は、設定データ132にてpointフィールドに対して設定されたtokenizerにより分割されたKeywordの出現する順番を表す。
【００２９】
図４（ｂ）のorderフィールドのインデクスデータにおけるKeyword406は、図５（ｂ）のOrderデータ142におけるジオハッシュ508を、orderフィールドに対して設定されたtokenizerにより分割したKeyword単位で格納される。DocID407は、Orderデータ142における当該Keyword406のDocID507と同じである。Position408は、図５のOrderデータ142における当該DocID507において、当該Keyword406が出現する位置を表す。図４（ａ）のPosition405と同様に、この位置は、設定データ132にてorderフィールドに対して設定されたtokenizerで分割されたKeywordの出現する順番を表す。
【００３０】
＜検索画面＞
図６は、プローブデータ131を検索する際に使用される検索画面(GUI)の一例を示す図である。図６に示されるように、GUIのウインドウ601では、上側の領域に検索条件を入力する検索ボックス602と検索ボタン603が表示され、下側の領域には、602に入力した検索条件の検索結果604が表示される。図６では、プローブデータにおける１又は複数の点のジオハッシュと属性に関する条件、図示の例では３点(始点、途中点、終点)の条件と、それぞれの点の順序に関する条件とを検索条件とした場合の検索結果すなわち該当するプローブデータが表示された状態が示されている。
【００３１】
＜データ処理装置における処理概要＞
上述の構成を有するデータ処理装置において行われる処理について説明する。まず、中央処理装置100は、中間データ生成プログラム121を用いて、記憶装置130におけるプローブデータ131を読み込み、プローブデータを解析して得られるTableデータ141とOrderデータ142をデータメモリ140に格納する。次に、インデクス生成プログラム122が実行される。インデクス生成プログラム122は、記憶装置130から設定データ132を、データメモリ140からTableデータ141とOrderデータ142を読み込み、設定データ132に設定されているフィールドタイプ毎にインデクスを生成し、インデクスデータ133として記憶装置130に格納する。次に、検索プログラムは、検索画面において検索ボタンが押下されると、検索条件を解析し、インデクスデータ133から検索条件に該当するプローブを検索し、検索結果を検索画面に表示する。それぞれの処理について、以下詳細に説明する。
【００３２】
＜中間データ生成処理＞
図７は、中間データ生成プログラム121が実行する中間データ生成処理を説明するためのフローチャートである。中間データ生成処理では、図２（ａ）のようなプローブデータから、図５（ａ）のようなTableデータと、図５（ｂ）のようなOrderデータを生成する。ここでの動作主体は中間データ生成プログラムである。
【００３３】
ステップ701では、プローブデータ131（図７の処理ではプローブデータ群を意味する）を読み込む。
ステップ702では、プローブデータ131から未処理のID201を１つ選択する、すなわち未処理のプローブデータを１つ選択する。この例では、この時、ID201に替えてDocID501を一意に設定する。
ステップ703では、選択及び設定したDocID501における未処理の行(１つのプローブデータを構成する１又は複数の点データ)の中から日時が最も古い行を１つ選択する。この時、RowIDを設定する。初期値は「１」である。その後RowIDを１だけインクリメントする。
ステップ704では、選択した行から、緯度203と経度204を取得し、ジオハッシュを求める。ジオハッシュの文字列長は任意に設定可能である。本実施形態では５文字で表す。例えば緯度経度がそれぞれ「50.801」「-1.099」であった場合は、「gcp1p」となる。
【００３４】
ステップ705では、ステップ702で設定したDocID501を、Tableデータ141におけるDocID501と、Orderデータ142におけるDocID501に格納する。また、ステップ703で設定したRowIDを、Tableデータ141におけるRowID502に格納する。また、ステップ704で求めたジオハッシュをTableデータ141におけるColumnID「1」504に格納する。
ステップ706では、ステップ704で求めたジオハッシュを、Orderデータ142におけるジオハッシュ508の末尾に追加する。
ステップ707では、当該点の属性に応じた値をTableデータ141のColumnID「2」505に格納する。当該点が、開始点ならば「start」を、途中点ならば「mid」を、終了点ならば「end」を格納する。
ステップ708では、当該点の日時をTableデータ141のColumnID「3」506に格納する。
【００３５】
ステップ709では、ステップ702で選択したID（すなわち１つのプローブデータ）において、全ての行（すなわち全ての点データ）を処理したか否かを判定し、真であればステップ710に進み、偽であればステップ703に戻る。
【００３６】
ステップ710では、プローブデータ131において全てのID（すなわち全てのプローブ）を処理したか否かを判定し、真であれば処理を終了し、偽であればステップ702に戻る。
【００３７】
＜インデクス生成処理＞
図８は、インデクス生成プログラム122が実行するインデクス生成処理の概要を説明するためのフローチャートである。インデクス生成処理では、図５のTableデータ141とOrderデータ142から、図５のようなインデクスデータ133を生成する。ここでの動作主体はインデクス生成プログラムである。
【００３８】
ステップ801では、記憶装置130から設定データ132を、データメモリ140からTableデータ141とOrderデータ142を読み込む。
ステップ802では、pointフィールドのインデクス生成を行う。図９はpointフィールドのインデクス生成処理の詳細を説明するためのフローチャートである。
【００３９】
ステップ901では、Tableデータ141から未処理のレコードを読み込む。例えば、図５における１行目のレコードに対してインデクス生成処理を行う場合を説明する。
ステップ902では、ColumnID504〜506の各列のデータを必要に応じてKeyword分割する。まず設定データ132からpointフィールドのtokenizerを取得する。pointフィールドのtokenizerはWhitespaceTokenizerである。WhitespaceTokenizerのKeyword分割ロジックは様々な実装が考えられるが、本実施形態では、空白またはピリオドでKeyword分割する実装であるとする。図５（ａ）の例ではCollumnID504〜506の各列中に空白またはピリオドで区切られた文字列はないが、例えばColumnID「2」505において属性を表す文字列が空白で区切られて複数存在した場合、それらを分割できる。空白またはピリオドで区切られた文字列が存在しない場合は、元の文字列が維持される。
【００４０】
ステップ903では、分割した各Keywordに対してインデクス生成するために、ステップ902で取得したKeyword群から未処理のKeywordを1つ選択する。例えば「gcp1p」を選択したとする。
ステップ904では、当該Keywordにおける、DocID、RowID、ColumnID及びPositionをインデクスデータのレコードとして登録する。Keywordが「gcp1p」の場合は、Keyword401に「gcp1p」を、DocID402に「1」を、RowID403に「1」を、ColumnID404に「1」を、Position405に「1」を格納する。
【００４１】
ステップ905では、ステップ902で得られたKeywordがすべて処理されたか否かを判定する。真の場合はステップ906に進み、偽の場合はステップ903に戻る。
【００４２】
ステップ906では、Tableデータ141における全レコードを処理したか否かを判定する。真の場合は処理を終了する。偽の場合はステップ902に戻る。
【００４３】
次に、図８のフローチャートにおけるステップ803で、orderフィールドのインデクス生成を行う。
まず、Orderデータ142から未処理のレコードを読み込む。例えば、「gcp1p  gcp0y  gcp0z」に対してインデクス生成処理を行う場合を説明する。
次に設定データ132からorderフィールドのtokenizerを取得し、ジオハッシュ508をKeyword分割する。orderフィールドのtokenizerはWhitespaceTokenizerであり、前述のものと同様である。前述の「gcp1p  gcp0y  gcp0z」は、「gcp1p」「gcp0y」「gcp0z」に分割される。
次に分割した各Keywordに対してインデクス生成するために、未処理のKeywordを一つ選択する。例えば「gcp0z」を選択したとする。
次に、当該Keywordにおける、DocID及びPositionをインデクスデータのレコードとして登録する。Keywordが「gcp0z」の場合は、Keyword406に「gcp0z」を、DocID407に「1」を、Position408に「3」を格納する。
同様の処理を、Orderデータ142における全レコードに対して行う。
【００４４】
＜検索処理＞
図１０は、検索プログラム123が実行する検索処理を説明するためのフローチャートである。検索処理では、図４のインデクスデータ133をもとに、図６のような検索画面で入力された検索クエリ(検索条件を表す文字列)に該当するプローブを検索結果として表示する。
【００４５】
検索画面において検索クエリが入力され検索ボタンが押下されると、検索処理が開始する。検索クエリが、次のようなものであった場合を例として説明する(図６に例示した検索条件と同一)。この検索クエリの１行目から３行目は、プローブにおける各点の条件を表す。１行目は、イギリスのポーツマス港付近を始点として、2013年1月1日0時0分0秒から2013年1月31日0時0分0秒までの期間に通過した点の条件である。２行目は、エジプトのスエズ付近を途中点として、日時条件なしに通過した点の条件である。３行目は、横浜港を終点として、日時条件なしに通過した点の条件である。４行目は、各点の順序条件であり、ポーツマス港付近→スエズ付近→横浜港付近の順序で通過したという条件を表す。詳細条件は以下の通りである。
【００４６】
point:(<gcp1*> <start> <[20130101000000 TO 20130131000000]>) AND
point:(<str4*> <mid> *) AND
point:(<xn73*> <end> *) AND
order:(“gcp1* str4* xn73*”~MAX,INORDER)
【００４７】
ステップ1001では、記憶装置130から、設定データ132、インデクスデータ133を読み込む。
ステップ1002では、検索クエリを解析してフィールド単位に分割する。本実施形態では、分割された検索クエリをフィールドクエリと呼ぶ。上記の例では、4個のフィールドクエリに分割される。それぞれ、「point:(<gcp1*> <start> <[20130101000000 TO 20130131000000]>)」、「point:(<str4*> <mid> *)」、「point:(<xn73*> <end> *)」、「order:(“gcp1* str4* xn73*”~MAX,INORDER)」である。この際、各フィールドクエリ間の論理演算子の位置はデータメモリ141に記憶される。
【００４８】
ステップ1003では、未処理のフィールドクエリを1つ選択する。
ステップ1004では、ステップ1003で選択されたフィールドクエリがorderフィールドか、pointフィールドかを判定する。orderフィールドの場合はステップ1005に進み、pointフィールドの場合はステップ1007に進む。なお、本実施形態では、これ以外のフィールドの場合は除外する。
【００４９】
ステップ1005では、orderフィールドのフィールドクエリを解析し、Keyword単位に分割する。「order:(“gcp1* str4* xn73*”~MAX,INORDER)」の場合で説明する。設定データ132から、fieldTypeのname属性が「order」のtokenizerを読み込む。この場合はWhitespaceTokenizerである。そして、WhitespaceTokenizerで、当該フィールドのフィールド値をKeyword分割する。「“gcp1* str4* xn73*”~MAX,INORDER」に適用すると、「gcp1*」、「str4*」、「xn73*」に分割される。
【００５０】
ステップ1006では、ステップ1005で得られたKeywordをもとに該当する文書を絞り込む。具体的には、まずインデクスデータ133のorderフィールドのテーブル(図４（ｂ）)を参照し、ステップ1005で得られたKeywordの「gcp1*」、「str4*」、「xn73*」に該当する文字列をともに含むDocIDをリストアップする。この時、「*」記号はワイルドカードを表し、任意の文字列に置き換えられることから、例えば「gcp1*」に該当する文字列は「gcp1」から始まる任意の文字列、すなわち「gcp1p」や「gcp1xw」などが該当する。本発明では、ジオハッシュをワイルドカードとともに使用することで、検索条件に指定する空間範囲をフレキシブルに指定可能である。例えば、横浜をジオハッシュで表す場合、「xn739」とすると、約10km四方の範囲を表す。「xn73」とすると約50km四方の範囲を表す。このことを利用し、検索時にジオハッシュにワイルドカードを付与することで、検索指定したい粒度の範囲を指定可能となる。
【００５１】
次に、近傍検索の条件を評価し、該当するDocIDをリストアップする。近傍検索とは、フレーズ検索を一般化した検索方式である。フレーズ検索の場合は、「”a b”」で指定した条件に対し、「a  b」のように「a」と「b」が順番に出現し、かつ「a」と「b」の間に他の文字列が含まれない場合に検索ヒットする。近傍検索では、順番を指定する/しない、他の文字列が含まれる場合の許容数の指定、が可能である。例えば順番を「指定する」場合、前述の条件に対し、「a  b」は検索ヒットするが、「b  a」は検索ヒットしない。順番を「指定しない」とした場合、両方が検索ヒットする。また、他の文字列が含まれる許容数を「1」とした場合、前述の条件に対して、「a  b」に加えて「a  x  b」も検索ヒットする。これは、「a」と「b」との間に含まれる文字列数が1以下であったためである。そのため「a  x  y  b」は検索ヒットしない。本発明では、これを利用して点の順番を検索条件に指定可能とする。
【００５２】
「“gcp1* str4* xn73*”~MAX,INORDER」における「~MAX,INORDER」は、順番を「指定する」、かつ、他の文字列が含まれる場合の許容値を限界まで大きい数値、として検索を実行する際に指定する。例えば、orderフィールドのインデクスデータとして、「gcp1p  str4m  w21z3  xn739」が格納されており、検索クエリとして、「order:” gcp1*  str4*  xn73*”~MAX,INORDER」が設定された場合を考える。インデクスデータには、ポーツマス、スエズ、シンガポール、横浜の順に経由した点のデータが格納されている。ジオハッシュの文字数はそれぞれ5文字である。検索クエリでは、ポーツマス、スエズ、横浜を順に経由し、ジオハッシュの粒度が４文字で設定されている。インデクスデータではジオハッシュが５文字であり検索クエリではジオハッシュが４文字であるが、ワイルドカード指定していることにより、それぞれの該当する地域が検索ヒットする。また、インデクスデータでは途中点にシンガポールが含まれ、検索クエリではシンガポールが含まれないが、MAX,INORDERが指定された近傍検索であるため、検索ヒットする。このように本発明では、範囲指定や途中点の条件に曖昧さを許容することが可能となる。このようにしてリストアップされたDocIDはデータメモリ141に記憶しておく。
【００５３】
ステップ1007では、pointフィールドのフィールドクエリを解析し、Column単位に分割する。「point:(<gcp1*> <start> <[20130101000000 TO 20130131000000]>)」の場合で説明する。設定データ132からfieldTypeのname属性が「point」のcolumnTokenizerを読み込む。この場合はTableTokenizerである。そして、TableTokenizerで、当該pointフィールドのフィールド値をColumn分割する。TableTokenizerは、「<>」で囲まれた文字列を認識し、出現した順にColumnIDを割り振る処理を行う機能を持つ。「point:(<gcp1*> <start> <[20130101000000 TO 20130131000000]>)」に適用した場合、「gcp1*」がColumnID「1」、「start」がColumnID「2」、「[20130101000000 TO 20130131000000]」がColumnID「3」となる。本実施形態では、pointフィールドのフィールドクエリは、3つのColumnで構成される。
【００５４】
ステップ1008では、ステップ1007で得られた各ColumnIDの文字列を解析し、Keyword単位に分割する。設定データ132から、fieldTypeのname属性が「point」のtokenizerを読み込む。この場合はWhitespaceTokenizerである。そして、WhitespaceTokenizerで、当該ColumnIDの文字列をKeyword分割する。「gcp1*」に適用すると、空白やピリオドを含まないため「gcp1*」がそのまま維持される。
【００５５】
ステップ1009では、ステップ1008で得られたKeywordをもとに該当する文書を絞り込む。図１１は、検索プログラム123が実行する検索処理内のpointフィールドにおける文書の絞り込み処理を説明するためのフローチャートである。
【００５６】
ステップ1101では、ステップ1008で得られたKeywordの中から未処理のKeywordを1つ選択する。
ステップ1102では、当該KeywordのColumnIDが一致するDocIDとRowIDの組合せをリストアップする。例えば、Keywordが「gcp1*」の場合、ワイルドカードのため、のpointフィールドにおけるインデクスデータ133から、「gcp1」から始まる文字列を取得する。その結果例えば「gcp1p」が取得された場合、ColumnIDは「1」である。インデクスデータ133において、Keywordが「gcp1p」かつColumnIDが「1」であるDocIDとRowIDの組合せはそれぞれ「1」と「1」の場合((1,1)と表記することがある)が該当する。
ステップ1103では、ステップ1008で得られた全Keywordを処理したか否かを判定する。真ならば1104に進み、偽ならば1101に進む。
ステップ1104では、ステップ1008で得られた全Keywordと、ステップ1102で得られたDocIDとRowIDの組合せを照合し、全Keywordで、DocIDとRowIDの組合せが同一となるDocIDをリストアップする。例えば、前述したpointフィールドのフィールドクエリにおけるKeywordはすべて、DocIDとRowIDの組合せが(1,1)となる場合がある。そのためDocIDが「1」の場合はリストアップされる。リストアップされたDocIDはデータメモリ141に記憶しておく。
【００５７】
図１０のフローチャートに戻り、ステップ1010では、全フィールドクエリを処理したか否かを判定する。真の場合はステップ1011に進み、偽の場合はステップ1003に進む。
【００５８】
ステップ1011では、各フィールドクエリに該当する文書を、論理条件を考慮して絞り込む。例えば、検索クエリが「point:(<gcp1*> <start> <[20130101000000 TO 20130131000000]>)  AND   order:(“gcp1* str4* xn73*”~MAX,INORDER)」であった場合、「point:(<gcp1*> <start> <[20130101000000 TO 20130131000000]>)」に該当するDocIDと、「order:(“gcp1* str4* xn73*”~MAX,INORDER)」に該当するDocIDを、論理条件「AND」で絞り込む。
ステップ1012では、ステップ1011で絞りこまれた該当文書を検索結果に表示する。この際、検索結果数や、各文書のフィールド値を表示してもよい。
【００５９】
＜まとめ＞
以上説明したように、本実施形態によれば、プローブデータの各プローブを表形式のデータに変換して検索することにより、プローブデータを、各点の条件を指定して検索可能となる。また、ジオハッシュを用いることにより、範囲をフレキシブルに指定可能となる。また、各点をジオハッシュで定義し、それらを順に格納したインデクスデータを生成しておき、近傍検索を行うことにより、各点の順序を指定する/しない、点と点との間に含まれる点の数を指定することが可能となる。また、属性値として、始点、途中点、終点を区別可能なインデクスデータを生成することで、各点に属性値を指定した検索をすることが可能となる。属性値の条件をワイルドカード指定すれば属性値を指定しないで検索することも可能となる。
【００６０】
なお、本発明は、実施形態そのままに限定されるものではなく、実施段階では、その要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【００６１】
また、実施形態で示された各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上記各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能等を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録或いは記憶装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録或いは記憶媒体に格納することができる。
【００６２】
さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
【符号の説明】
【００６３】
１００  中央処理装置（プロセッサ）
１１０  入出力装置
１１１  表示装置
１１２  キーボード
１１３  マウス
１２０  プログラムメモリ
１２１  中間データ生成プログラム
１２２  インデクス生成プログラム
１２３  検索プログラム
１３０  記憶装置
１３１  プローブデータ
１３２  設定データ
１３３  インデクスデータ
１４０  データメモリ
１４１  Tableデータ
１４１  Orderデータ
【図１】
2015035015.tif 000003
【図２】
2015035015.tif 000004
【図３】
2015035015.tif 000005
【図４】
2015035015.tif 000006
【図５】
2015035015.tif 000007
【図６】
2015035015.tif 000008
【図７】
2015035015.tif 000009
【図８】
2015035015.tif 000010
【図９】
2015035015.tif 000011
【図１０】
2015035015.tif 000012
【図１１】
2015035015.tif 000013