空間検索

bin/solr post ツールを使用する場合

リクエストで渡す主要なパラメーターは次のとおりです。

geofilt フィルタを使用すると、指定された点からの地理空間距離（別名「大円距離」）に基づいて結果を取得できます。別の見方をすると、円形のシェイプフィルタを作成します。たとえば、指定された緯度/経度ポイントから5キロメートル以内のすべてのドキュメントを検索するには、次のように入力します。

このフィルタは、初期点の周りの指定された半径の円内にあるすべての結果を返します。

bbox フィルタは、計算された円の境界ボックスを使用することを除いて、geofilt と非常によく似ています。下の図の青いボックスを参照してください。geofilt と同じパラメータを取ります。

以下はクエリのサンプルです。

長方形の形状は計算が速いため、半径外の点を返すことが許容される場合は、geofilt の代替として使用されることがあります。ただし、理想的な目標が円でありながら、高速に実行したい場合は、代わりにRPTフィールドを使用し、distErrPct 値を 0.1 （半径の10％）などの大きな値にすることを検討してください。これにより、半径外の結果が返されますが、シェイプの周りで均一に結果が返されます。

空間検索の要件として、ユーザーが表示しているマップでカバーされる領域など、長方形の領域内のすべてを検索する必要がある場合があります。この場合、geofilt と bbox は役に立ちません。これは一種のトリックですが、範囲の開始として左下隅を指定し、範囲の終了として右上隅を指定することで、Solr の範囲クエリ構文を使用できます。

以下に例を示します。

RPT および BBoxField の場合、緯度/経度座標を使用しない場合（geo="false"）、スペースがあるため、ポイントを引用符で囲む必要があります。例："x y"。

空間クエリを "fq" パラメータ（フィルタクエリ）に入れるのが最も一般的です。デフォルトでは、Solr はフィルタキャッシュにクエリをキャッシュします。

フィルタクエリ（空間的かどうかに関わらず）がかなりユニークであり、キャッシュヒットが得られる可能性が低い場合は、次の例に示すように、cache="false" をローカルパラメータとして指定します。このテクニックからメリットを得られる空間タイプは、LatLonPointSpatialField や BBoxField などの docValues を持つタイプのみです。

geodist は、3つのオプションパラメータ (sfield,latitude,longitude) を取る距離関数です。geodist 関数を使用すると、距離で結果をソートしたり、結果のスコアを返したりできます。

たとえば、結果を距離の昇順でソートするには、次のようなリクエストを使用します。

ドキュメントスコアとして距離を返すには、次のようなリクエストを使用します。

ここでは、フロリダ州ジャクソンビル、または45.15、-93.85（ミネソタ州バッファロー付近）から50キロメートル以内の結果をクエリします。

距離でファセットするには、frange クエリパーサーを使用できます。

各 facet.query で {!geofilt} を使用するなど、他の方法もあります。

DisMax クエリパーサーまたはExtended DisMax (eDisMax) クエリパーサーを使用すると、空間検索とブースト関数を組み合わせて、最近傍の結果をブーストできます。

距離を擬似フィールドとして返すには、フィールドリストで geodist() 関数を使用できます。

RPTを使用するには、フィールドタイプをコレクションのスキーマに登録して構成する必要があります。このフィールドタイプには多くのオプションがあります。

その他にも次のようなものがあります。 normWrapLongitude、datelineRule、validationRule、autoIndex、allowMultiOverlap、precisionModel。詳細については、上記で参照されている spatialContextFactory の実装に関する以下の注記、特に JTS ベースのものへのリンクを参照してください。

RPT フィールドタイプは、一連の標準形状をサポートしています。点、円 (別名、バッファ付き点)、エンベロープ (別名、長方形または境界ボックス)、ラインストリング、ポリゴン、およびこれらの「マルチ」バリアントです。エンベロープとラインストリングは、ユークリッド/直交座標 (フラット 2D) 形状です。基盤となる Solr は、それらを実装する Spatial4j ライブラリです。他の形状をサポートするには、フィールドタイプの spatialContextFactory 属性を設定して、他のオプションを参照できます。JTS と Geo3D の 2 つが利用可能です。

JTS Topology Suite は、ユークリッド/直交座標 (フラット 2D) モデルを備えた一般的な計算幾何学ライブラリです。ポリゴン、バッファリング形状、およびいくつかの無効なポリゴン修復フォールバックを含む、さまざまな形状をサポートしています。Solr に付属の Spatial4j の助けを借りて、ポリゴンはデータライン (子午線) の横断をサポートします。それを (JAR ファイル) ダウンロードして、Solr の内部の特別な場所に配置する必要があります: SOLR_INSTALL/server/solr-webapp/webapp/WEB-INF/lib/。ここで簡単にダウンロードできます: https://mvnrepository.com/artifact/org.locationtech.jts/jts-core/1.15.0。他の一般的な Solr lib ディレクトリに配置しても機能しませんので、ご注意ください。

フィールドタイプの spatialContextFactory 属性を JTS に設定します。

有効にすると、追加の構成属性が利用可能になります。Javadocs については org.locationtech.spatial4j.context.jts.JtsSpatialContextFactory を参照し、スーパークラスのオプションも必ず参照してください。特に有効にする可能性が高いオプションの 1 つは autoIndex (つまり、JTS の PreparedGeometry を使用) です。これは、複雑なポリゴンに対して大幅なパフォーマンス向上になることが示されています。

フィールドタイプが定義されたら、それを使用するフィールドを定義します。

以下は、solr.SpatialRecursivePrefixTreeFieldType または RptWithGeometrySpatialField のいずれかである可能性のあるフィールド「geo」のポリゴンクエリの例です。

検索述語に続く括弧内は、形状定義です。その形状の形式は、フィールドタイプの format 属性によって制御され、デフォルトは WKT です。GeoJSON を使用する場合は、代わりにそれを指定できます。

このリファレンスガイドと Spatila4j のドキュメント以外に、Solr Wiki に残っている詳細がいくつかあります: https://cwiki.apache.org/confluence/display/solr/SolrAdaptersForLuceneSpatial4。

Geo3D は、Solr に含まれる Lucene spatial-3d モジュールの通称です。これは、球体または WGS84 楕円体上のさまざまな形状 (ポリゴンを含む) を実装する計算幾何学ライブラリです。Geo3D は、ジオメトリが地球全体にわたる長距離をカバーする場合や、極に近い空間アプリケーションに特に適しています。Geo3D は、3 次元ジオメトリをサポートしていないにもかかわらず、ジオセントリック座標 (X、Y、Z) を使用する内部実装が原因でそのように命名されています。これらの内部的な詳細にもかかわらず、Solr では通常どおりに緯度と経度を指定します。

フィールドタイプの spatialContextFactory 属性を Geo3D に設定します。

フィールドタイプが定義されたら、それを使用するフィールドを定義します。

prefixTree="s2" 設定はオプションであり、Geo3D でのみ可能です。これは、他のグリッドよりも効率的になるように、Geo3D を念頭に置いて開発されました。

RptWithGeometrySpatialField フィールドタイプは、SpatialRecursivePrefixTreeFieldType の派生物であり、元のジオメトリを Lucene DocValues に内部的に格納し、それを使用して正確な検索を実現します。インデックス付きポイントフィールドにも使用できます。Intersects 述語 (デフォルト) は、多くの検索結果をジオメトリチェックを必要とせずに正確なヒットとして返すことができるため、特に高速です。このフィールドタイプは RPT と同様に構成されますが、グリッドの正方形はパフォーマンスのためだけのものであり、形状を根本的に表すものではないため、デフォルトの distErrPct は 0.15 (0.025 より大きい) です。

オプションのインメモリキャッシュは solrconfig.xml で定義できます。これは、データに多数の頂点を持つ形状が含まれる傾向がある場合に行う必要があります。フィールドに「geom」という名前を付けると仮定すると、solrconfig.xml に次のものを追加することで、オプションのキャッシュを構成できます。キャッシュ名のサフィックスに注意してください。

このフィールドタイプを使用する場合、フィールドを格納済みとしてマークすることはおそらく望ましくありません。これは、DocValues データと重複しており、(WKT または GeoJSON であるかどうかにかかわらず) 書式設定のためにより大きくなるためです。DocValues から検索結果で空間データを取得するには、[geo トランスフォーマー]を使用します。

RPT フィールドは、各グリッドセルに空間データを持つドキュメントのファセットカウントの 2D グリッドを生成することをサポートします。詳細度の高いグリッドの場合、これは点をプロットするために使用でき、詳細度の低いグリッドの場合はヒートマップの生成に使用できます。グリッドセルは、RPT の構成に基づいてインデックス時に決定されます。ファセットカウント時に、対象領域のインデックス付きセルがトラバースされ、各セルに対応するカウンターのグリッドがインクリメントされます。Solr は、整数のストレートな 2D 配列または、より大きなデータセットに対してより適切に圧縮されますが、デコードする必要がある PNG でデータを返すことができます。

ヒートマップ機能は、Solr の標準ファセット機能と JSON ファセット API の両方からアクセスできます。ここでは標準ファセットについて説明します。ファセットの一部として、他のタイプのファセットと同様に、key ローカルパラメーターとタグ付きフィルタークエリの除外をサポートします。これにより、異なるフィルターを使用して、同じフィールドで複数のヒートマップを返すことができます。

以下は JSON での出力例です ("…​" は簡潔にするために挿入されています)

出力には gridLevel が表示されます。これは、他のパラメーターから計算されることが多いため、興味深いものです。開発中のインターフェイスで明示的な解像度を増減する機能が許可されている場合、後続の要求で gridLevel を明示的に指定できます。

minX、maxX、minY、maxY は、カウントが行われる領域を報告します。これは、ターゲットグリッドレベルでの入力 geom の最小包含境界長方形です。これは日付線を折り返す場合があります。columns および rows の値は、出力長方形を均等に分割する列と行の数です。注: セルデータが geo=true の場合は小数点以下の度数、geo=false の場合は指定された単位の座標空間にあるため、これらの長方形/点をプロットするために画面に投影されたマップ長方形を均等に分割しないでください。これは画面上のマップと同じように配置できますが、必ずしもそうであるとは限りません。

counts_ints2D キーには、整数の 2D 配列があります。最初の外側のレベルは行順 (上から下) で、内側の配列は列 (左から右) です。配列がすべてゼロになる場合は、効率上の理由から代わりに null が返されます。一致する空間データがない場合、値全体が null になります。

format=png の場合、出力キーは counts_png です。これは、4 バイトの PNG を base-64 エンコードした文字列です。この PNG は、論理的には ints2D 形式とまったく同じデータを保持しています。アルファチャネルのバイトは、診断目的で PNG を見やすくするために反転されていることに注意してください。反転されていない場合、counts が 2^24 を超えるまで不透明にならないためです。したがって、この値を超える counts は不透明になります。