1

Solr 4.5 での作業と使用例は、指定されたルートまでの距離で結果を並べ替える必要があることです。rpt フィールドgeo(関心のあるポイントの場所) として 1 つの地理座標を含むドキュメントの操作。

これが私が目指しているものの図です: http://i.imgur.com/lGgMEal.jpg . ドキュメントから特定のルートまでの最短距離を計算し、それをブースティング コンポーネントとして使用したいと考えています。

現在の試みは、モードで{!score=recipDistance}関数を使用edismaxし、ルートの説明を WKT の LineString として送信することです。現在送信されているクエリは次のとおりです。

fl=*,score,distdeg:query({!score=distance filter=false v=$spatialfilter})
defType=edismax
q.alt=*:*
boost=query({!score=distance filter=false v=$spatialfilter})
spatialfilter=geo:"Intersects(LINESTRING (59.79619 11.38690, 60.25974 11.63869))"

そしてURI形式で：

http://sokemotortest:8080/solr/collection1/select?fl=*%2Cscore%2Cdistdeg%3Aquery%28{!score%3Ddistance+filter%3Dfalse+v%3D%24spatialfilter}%29&wt=json&debugQuery=true&defType=edismax&q.alt=*%3A*&boost=query%28{!score=distance%20filter=false%20v=$spatialfilter}%29&spatialfilter=geo:%22Intersects%28LINESTRING%20%2859.79619%2011.38690,%2060.25974%2011.63869%29%29%22

このアプローチに関する私の問題は次のとおりです。

  • 距離は形状（ルート）の中心から計算されるようです。これは、ラインまでではなくスポットまでの距離を取得していることを意味します。このクエリでは、Pt(x=60.027965,y=11.512795)

  • 距離計算の結果が間違っているようです。インデックスには 4 つのドキュメントがあり、次の順序で表示されます。

    • (1) 59.7333、7.61283
    • (2) 59.6236、10.7263
    • (3) 59.6238、10.7385
    • (4) 64.12379、22.14029

    順序がむしろあるべきだった場合：

    • (3) 59.6238、10.7385
    • (2) 59.6236、10.7263
    • (1) 59.7333、7.61283
    • (4) 64.12379、22.14029

ここでブースト計算デバッグを使用して完全な結果を確認できます: pastebin.com/5tvCb0Cf

別の有効な解決策は、ルートまでの距離でドキュメントをフィルタリングすることです (例: http://i.imgur.com/EJu8Kcg.jpg )。これは、jTS と spatial4j の両方でサポートされていると思われるバッファリングされた行を使用して行うことができます。唯一の問題は、バッファリングされた行をIntersect関数への入力として送信する方法です (このようなものです: geo:"Intersects(LINESTRING (59.79619 11.38690, 60.25974 11.63869) d=1)")。

ここでの解決策は、LineString としてルートを受け入れ、Polygon または MuliPolygon としてさらにクエリを転送するカスタム検索コンポーネントを作成することですが、必要でない限り、カスタム コンポーネントの開発は避けたいと思います。

私の質問は次のとおりです。

  • Solr 4.5 で、形状の中心ではなく LineString までの距離を取得することは可能ですか?
  • バッファリングされた行を関数への入力として送信できますかIntersect(次のように: geo:"Intersects(LINESTRING (59.79619 11.38690, 60.25974 11.63869) d=1)")?

PS: インデックス内のフィールドの説明:

<field name="geo" type="location_rpt" indexed="true" stored="true"/>

フィールド タイプの定義:

<fieldType name="location_rpt"
    class="solr.SpatialRecursivePrefixTreeFieldType"
    spatialContextFactory="com.spatial4j.core.context.jts.JtsSpatialContextFactory" 
    geo="true"
    distErrPct="0.025"
    maxDistErr="0.000009"
    units="degrees"
    />
4

1 に答える 1

0

  1. ドキュメントごとにインデックス付きポイントからクエリ LineString までの距離を取得することは (Solr をカスタマイズしない限り) 不可能です。lineString (JTS WKT パーサーで解析できます) を参照し、インデックス付きポイント フィールドも参照する ValueSourceParser を作成する必要があります。ドキュメントからポイントをドキュメントごとに効率的に取得するには、RPT ではなく LatLonType を使用します。JTS はポイントと LineString の間の距離を計算できますが、JTS はユークリッド空間で動作することに注意してください。精度を高めるには、データ (インデックス付きポイントと lineString の両方) を、lineString を中心とする投影に「投影」する必要があります。Proj4j はそれを助けることができます。

  2. RE bufferedLineStrings の場合、Spatial4j のマスター ブランチが「BufferedLineString」形状を持っていることに興味があるかもしれません。これは Spatial4j にネイティブです。ただし、形状解析にはまだ統合されていないため、まだ完全には準備が整っていません。明確にするために、それは十分にテストされており、オープンソースではないパーサーで私的に使用しています。また、JTS のようにユークリッド空間に制限されています。これにアプローチする最善の方法は、独自の Solr クエリ パーサーを追加することです (思ったより簡単です)。このクエリ パーサーは、バッファー距離、LineString を読み取り、そこから JTS を使用してバッファーします。インデックス付きデータと整列する必要があるため、形状の中心点への投影は現実的ではありません。代わりに、適切な量のオーバーバッファリングによって補正することができます。これにより、形状のサイズが大きくなりますが、少なくとも最小距離が確実にキャプチャされます。これをより良く解決する計画はありますが、忙しくしています。

于 2013-10-21T19:51:50.207 に答える