問題タブ [spatial-query]

SQL データベースからポリゴン データを取得するクエリを作成しました。

結果を取得するために次のクエリがあります。

このテーブルでは、以下のように空間インデックスを既に追加しています

しかし、2483 件のレコードを取得するのに 38 秒かかりました。誰でもこのクエリを最適化するのを手伝ってくれますか

mysql で空間データ型のポイントを使用すると問題が発生します。次の情報を保存しているmysqlに「タスク」と呼ばれる1つのテーブルがあります。

以下はサンプルデータです。

iPhone に 2 つの異なる緯度経度値を送信するアプリケーションがあり、その緯度経度の間にあるすべての場所を渡す必要があります。たとえば。それらは次の 2 つの緯度経度値を渡しているため、その間にあるすべての場所を導出する必要があります。ポイント A: 22.327847、73.172894 ポイント B: 22.272259、73.227825

同じGoogleマップのスクリーンショットを添付。

データを取得するために、次のクエリを作成しています。

指定されたポイント A とポイント B の間のすべてのポイントを取得できません。保存されているポイントがこのポイントの間にあることがわかりますが、すべての値を取得することはできません。結果として得られる値は 1 つだけです。クエリの何が問題なのですか、または間違ったロジックを適用していますか?

誰でもこれで私を助けることができますか？

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

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

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

そしてURI形式で：

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

• 距離は形状（ルート）の中心から計算されるようです。これは、ラインまでではなくスポットまでの距離を取得していることを意味します。このクエリでは、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: インデックス内のフィールドの説明:

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

このクエリの結果から x,y 座標を抽出するにはどうすればよいですか? 多くのバリエーションを試しましたが、どれも正しく機能しませんでした。

間違った結果:

次のようにする必要があります。

postgis で PostgreSQL を使用しています。ジオメトリは UTM であり、いくつかの形状タイプ (ポイント、ポリゴン、ラインストリングなど) を持つ WKB として保存されます。wkb をラジアンまたは UTM のポイントのリストに変換する方法はありますか? 形状タイプと各ポイントの文字列解析なしで? ありがとう

の空間テーブルがありpolygonsます。MySQL 空間テーブル内にあるものを効率的にpolygon見つけようとしています。lat/lng point

ST_Withinが利用可能であることはわかっていますがMySQL 5.6、私のバージョンはこれよりも前のものであるため、自由に使える2つの機能を組み合わせて、個別よりも効率的/正確なものにしています。

これらは、MySQL フォーラムの投稿からのネイティブMBRWITHIN関数とカスタムGISWithinです。MBRWITHIN は通常、1 つしかないはずのポイントに対して約 2 行を提供しますが、高速です。GISWithin は正しい行を提供しますが、非常に遅いです。

だから私は次のようなクエリを書こうとしています:

最初に、クイック MBRWITHIN 関数を使用して、ポイントを含む可能性のあるいくつかの行を選択します。

次に、現在 9000 行ではなく約 2 行で動作している低速の GISWithin を使用して、このリストを 1 つの正しい行に絞り込みます。

私はあらゆる種類のサブクエリを試しました

と

エラーメッセージを取得するためだけに

そのようなクエリや関数を書く方法を知っている人はいますか?

私のテーブルのポリゴンフィールドは呼び出されgeometry、タイプはGeometryogr2ogrからインポートされています。

gIntersection を使用して、SpatialPolygonsDataFrame から一度に 1 つずつポリゴンで全国的なパス ネットワークをクリップしています。各ポリゴンをループし、パス ネットワークをクリッピングし、クリッピングされたパスの長さを計算し、これを path.lgth というデータ フレームに保存します。

vid 行は、パスの長さとともにデータフレームに保存するポリゴン ID を抽出するだけです。

私の問題は、最初のポリゴンを作成するのに時間がかかりすぎることです (約 12 分!)。これをスピードアップする方法はありますか？gIntersection が数学的に何をするのかわかりません (すべてのパスをチェックして、それらがポリゴンと重なっているかどうかを確認していますか?)。パスを単純化したので、それらは 1 つの機能にすぎません。

ご協力いただきありがとうございます。

空間ハッシュが非常に遅いのはなぜですか? 滑らかな粒子の流体力学を使用して地滑りの動きをモデル化するコードに取り組んでいます。滑らかな粒子の流体力学では、各粒子は 3 つの「平滑化長さ」の距離内にある粒子に影響を与えます。隣接する粒子をすばやく検索するために、空間ハッシュ関数を実装しようとしています。

私の実装では、stl の「set」データ型を使用しました。各時間ステップで、粒子は以下の関数を使用してバケットにハッシュされます。「bucket」はセットのベクトルで、グリッド セルごとに 1 つのセットがあります (空間ドメインは制限されています)。各粒子は整数で識別されます。

衝突を探すために、以下の「getSurroundingParticles」という名前の関数が使用されます。この関数は整数 (粒子に対応) を取り、粒子のサポート長の 3 倍以内にあるすべてのグリッド セルを含むセットを返します。

問題は、この実装が非常に遅く、粒子の数が 2000 の場合、各粒子を他のすべての粒子に対してチェックするよりも遅いことです。

getSurroundingParticles を呼び出すように見えるコード:

どうもありがとう！