問題タブ [spatial-query]

私は、扱っているデータ セットに対して適切な SQL Server 2008 空間インデックスのセットアップを選択しようとしています。

データセットは、地球全体の等高線を表すポリゴンです。テーブルには 106,000 行あり、ポリゴンはジオメトリ フィールドに格納されています。

私が抱えている問題は、多くのポリゴンが地球の大部分をカバーしていることです。これにより、プライマリ フィルターで多くの行を除外する空間インデックスを取得することが非常に難しくなっているようです。たとえば、次のクエリを見てください。

これは、テーブル内の 2 つのポリゴンのみと交差する領域をクエリしています。選択した空間インデックス設定の組み合わせに関係なく、その Filter() は常に約 60,000 行を返します。

もちろん、Filter() を STIntersects() に置き換えると、必要な 2 つのポリゴンだけが返されますが、当然、はるかに時間がかかります (Filter() は 6 秒、STIntersects() は 12 秒)。

60,000 行で改善される可能性が高い空間インデックスのセットアップがあるかどうか、または私のデータセットが SQL Server の空間インデックスとうまく一致しないかどうかについて、誰かヒントを教えてもらえますか?

より詳しい情報：

示唆されたように、世界中の 4x4 グリッドを使用して、ポリゴンを分割しました。QGIS でそれを行う方法が見つからなかったので、それを行うための独自のクエリを作成しました。最初に 16 個のバウンディング ボックスを定義しました。最初のボックスは次のようになりました。

次に、各境界ボックスを使用して、そのボックスと交差するポリゴンを選択して切り捨てました。

明らかに、4x4 グリッドの 16 個のバウンディング ボックスすべてに対してこれを行いました。最終結果は、約 107,000 行の新しいテーブルを作成したことです (これは、実際には多くの巨大なポリゴンがないことを確認しています)。

オブジェクトごとに 1024 セルの空間インデックスを追加し、レベルごとのセルには低、低、低、低を追加しました。

ただし、非常に奇妙なことに、分割されたポリゴンを含むこの新しいテーブルは、古いテーブルと同じように機能します。上記の .Filter を実行しても、最大60,000 行が返されます。私はこれをまったく理解していません。明らかに、空間インデックスが実際にどのように機能するかを理解していません。

逆説的に、.Filter() はまだ 60,000 行を返しますが、パフォーマンスは向上しています。.Filter() は 6 秒ではなく約 2 秒かかり、.STIntersects() は 12 秒ではなく 6 秒かかるようになりました。

ここで要求されているのは、インデックスの SQL の例です。

覚えていますが、オブジェクトごとにグリッドとセルのさまざまな設定を試しましたが、毎回同じ結果が得られました。

sp_help_spatial_geometry_index を実行した結果は次のとおりです。これは、単一のポリゴンが地球の 1/16 以上を占めていない私の分割データセットです。

Base_Table_Rows 215138 Bounding_Box_xmin -90 Bounding_Box_ymin -180 Bounding_Box_xmax 90 Bounding_Box_ymax 180 Grid_Size_Level_1 64 Grid_Size_Level_2 64 Grid_Size_Level_3 64 Grid_Size_Level_4 64 Cells_Per_Object 16 Total_Primary_Index_Rows 378650 Total_Primary_Index_Pages 1129 Average_Number_Of_Index_Rows_Per_Base_Row 1 Total_Number_Of_ObjectCells_In_Level0_For_QuerySample 1 Total_Number_Of_ObjectCells_In_Level0_In_Index 60956 Total_Number_Of_ObjectCells_In_Level1_In_Index 361 Total_Number_Of_ObjectCells_In_Level2_In_Index 2935 Total_Number_Of_ObjectCells_In_Level3_In_Index 32420 Total_Number_Of_ObjectCells_In_Level4_In_Index 281978 Total_Number_Of_Interior_ObjectCells_In_Level2_In_Index 1 Total_Number_Of_Interior_ObjectCells_In_Level3_In_Index 49 Total_Number_Of_Interior_ObjectCells_In_Level4_In_Index4236 Total_Number_Of_Intersecting_ObjectCells_In_Level1_In_Index 29 Total_Number_Of_Intersecting_ObjectCells_In_Level2_In_Index 1294 Total_Number_Of_Intersecting_ObjectCells_In_Level3_In_Index 29680 Total_Number_Of_Intersecting_ObjectCells_In_Level4_In_Index 251517 Total_Number_Of_Border_ObjectCells_In_Level0_For_QuerySample 1 Total_Number_Of_Border_ObjectCells_In_Level0_In_Index 60956 Total_Number_Of_Border_ObjectCells_In_Level1_In_Index 332 Total_Number_Of_Border_ObjectCells_In_Level2_In_Index 1640 Total_Number_Of_Border_ObjectCells_In_Level3_In_Index 2691 Total_Number_Of_Border_ObjectCells_In_Level4_In_Index 26225 Interior_To_Total_Cells_Normalized_To_Leaf_Grid_Percentage 0.004852925 Intersecting_To_Total_Cells_Normalized_To_Leaf_Grid_Percentage 0.288147586 Border_To_Total_Cells_Normalized_To_Leaf_Grid_Percentage 99.70699949 Average_Cells_Per_Object_Normalized_To_Leaf_Grid 405.7282349 Average_Objects_PerLeaf_GridCell 0.002464704 Number_Of_SRIDs_Found 1 Width_Of_Cell_In_Level1 2.8125 Width_Of_Cell_In_Level2 0.043945313 Width_Of_Cell_In_Level3 0.000686646 Width_Of_Cell_In_Level4 1.07E-05 Height_Of_Cell_In_Level1 5.625 Height_Of_Cell_In_Level2 0.087890625 Height_Of_Cell_In_Level3 0.001373291 Height_Of_Cell_In_Level4 2.15E-05 Area_Of_Cell_In_Level1 1012.5 Area_Of_Cell_In_Level2 15.8203125 Area_Of_Cell_In_Level3 0.247192383 Area_Of_Cell_In_Level4 0.003862381 CellArea_To_BoundingBoxArea_Percentage_In_Level1 1.5625 CellArea_To_BoundingBoxArea_Percentage_In_Level2 0.024414063 CellArea_To_BoundingBoxArea_Percentage_In_Level3 0.00038147 CellArea_To_BoundingBoxArea_Percentage_In_Level4 5.96E-06 Number_Of_Rows_Selected_By_Primary_Filter 60956 Number_Of_Rows_Selected_By_Internal_Filter 0 Number_Of_Times_Secondary_Filter_Is_Called 60956 Number_Of_Rows_Output 2 Percentage_Of_Rows_NotSelected_By_Primary_Filter 71.66655821 Percentage_Of_Primary_Filter_Rows_Selected_By_Internal_Filter 0 Internal_Filter_Efficiency 0 Primary_Filter_Efficiency 0.003281055

「Base_Table_Rows 215138」はあまり意味がありません。テーブルには215,000ではなく107,000行があります

レンダリングすると、データセットは次のようになります: _{(ソース: norman.cx )}

さらなる研究:

このデータを使用したプライマリ フィルターのパフォーマンスの悪さに、私は引き続き戸惑っています。そこで、データがどのように分割されるかを正確に確認するためのテストを行いました。元の分割されていない機能を使用して、テーブルに「セル」列を追加しました。次に、16 のクエリを実行して、フィーチャが 4x4 グリッド内でいくつのセルにまたがっているかをカウントしました。そこで、各セルに対して次のようなクエリを実行しました。

次に、表の「セル」列を見ると、データ セット全体で、4x4 グリッド内の複数のセルと交差するフィーチャは 672 個しかありません。では、まったく文字通り、幅 200 マイルの小さな四角形を参照するクエリに対して、プライマリ フィルターが 60,000 個のフィーチャを返すことができるでしょうか。

この時点で、これらの機能に対する SQL Server のパフォーマンスよりも優れた独自のインデックス作成スキームを作成できるようです。

このプラグインを使用して、Solr で空間クエリを許可しています。ドキュメントに記載されている手順に従いましたが、空間クエリは正常に機能しています。

ここで、計算された距離を取得したいと思います。solrconfig.xml ファイルに次の行を追加しました。

そして、「geodistance」コンポーネントを標準のリクエスト ハンドラーに追加しました。

次に、「q={!spatial lat=41.641184 long=-0.894032 radius=2 calc=arc unit=km} cafeteria」などのクエリを実行すると、機能しますが、初回のみです。同じクエリを再度実行すると、次のエラーが発生します。

クエリが初めて機能し、「geo_distance」フィールドで計算された距離を取得するため、エラーがどこにあるのかわかりません。しかし、クエリを繰り返すと、NullPointerException が発生します。

2D 範囲カウント クエリを実行するためのデータ構造が必要です (つまり、特定の四角形に含まれるポイントの数)。

私の最善の策は範囲ツリーだと思います（log ^ 2でカウントするか、いくつかの最適化後にログに記録することもできます）。それは良い選択のように聞こえますか？Python の実装について知っている人はいますか、それとも自分で作成する必要がありますか?

geography データ型に読み込まれた地理データがあります。非常に具体的な目的のために、これをジオメトリとして保存する必要があります。ただし、このようなクエリを実行する必要があります。

GPS 位置のデータベースを保存し、特定の半径内のポイントと最も近いポイントを見つけるクエリを実行しようとしています。私はmysqlを使用しており、空間拡張を見てきました。位置半径クエリで探していることを実際に空間拡張を使用して行う方法がわかるかどうかはわかりません。

だからここに私のオプションについて考えていることがあります：

1. 緯度と経度の gps 座標を浮動インデックス変数として db に保存します。ポイントの gps 座標と範囲を取得したら、緯度と経度の最大値と最小値を計算してクエリを実行し、これらの距離関数に基づいて並べ替えて並べ替えます。

2. 空間拡張を使用します。私はこれがうまくいくと確信しているわけではありません。Distance() 関数は実装されていません。空間インデックスを使用するには、境界ボックスを見つけて (実行可能)、MBRContains 境界ボックス関数を呼び出して、この境界ボックス内にあるポイントを見つける必要があります。ただし、ポイントにはゼロの境界があるため、MBRContains 関数はポイントに対して機能しません。

これを行うための標準的な方法が何であるかはわかりませんが（存在しないようです）、経験/考え/決定の助けの言葉をいただければ幸いです。私は現在mysql 5.13を使用していますが、5.5でも距離メトリックがないことを確信しています。

また、2.が機能する場合でも、どちらが高速になりますか? あなたの考えを教えてください。特に、迅速かつ大規模な検索で何かが機能することを確信している/見たことがある場合は特にそうです!

Mysql 空間インデックス: http://dev.mysql.com/doc/refman/5.5/en/using-a-spatial-index.html

MySQLデータベースに、POINT型の空間ジオメトリ列を持つテーブルがあります。マップの中心にあるポイントを取得して、そのXマイル（または任意の距離）内のすべてのレコードを検索できるようにしたいと思います。幾何学の数学に深く関わっていない、これを行う方法の良い例や説明を見つけることができないようです。私はその道を進んでうれしいですが、最初に真の空間データベースでそれを解決しようと思います。

私はMySqlでGrails 1.3.2に取り組んでいます。特定の場所の緯度と経度をデータベースに保存する必要があり、ユーザーの現在の場所に基づいて、その場所の特定の半径内にあるアイテムを返す必要があります。したがって、基本的に次の要件があります。

1. ユーザーの現在の座標の指定された半径内にある場所を検索します
2. 全文検索を提供します。現在、これには検索可能を使用しています
3. ユーザーの現在の座標の指定された半径内で全文検索を組み合わせて実行します。

ここにあるさまざまなオプションを検討しており、これを実装するためのあなたの意見/提案を知りたいと思っていました. ここにあるさまざまなオプションは次のとおりです。

1. Lucene Spatial Search ( http://wiki.apache.org/lucene-java/SpatialSearch ) を検索して、検索可能で使用する方法を調べます

2. Grails Solr プラグイン ( http://www.grails.org/plugin/solr )。ただし、これはドメイン オブジェクトを返しません。

3. Grails スティッチ プラグイン ( http://www.grails.org/plugin/stitches )。著者のサイト ( http://www.philliprhodes.com/content/stitches-30-seconds ) を除いて、多くのドキュメントはありません。

4. ドメイン クラスのすべてのフィールドの全文インデックスに加えて、MySql 空間拡張。このルートに進むと、 searchable をまったく使用しなくなります。

5. Postgres/PostGIS と hibernate-spatial の統合 ( http://blog.mollusca.ch/2008/10/4/grails-spatial-data-postgis )

これは、マップと統合するすべてのアプリケーションにおける非常に基本的な要件であると考えています。

したがって、この機能を実装するための最も適切な方法を知りたいと思っています。

ありがとう

各セルの長さが X である 2D の均一間隔のグリッドにクラスター化できる 2D ポイントのセット P があります。

ヒートマップを作成しようとしているのでこれを行いたいのですが、多くの情報が得られるので、ポイントを均一間隔のグリッドにクラスター化することで、各グリッドの最終カウントを報告できることを望んでいます。

ありがとう！

それが違いを生む場合、細分化する前に、最初に指定されたポイントの特定の半径内にあるSQL（ポイント）を介して情報を取得しています。

このメソッドをリファクタリングしようとしています ( Massive.cs by Rob Coneryから):

Geography 型のチェックを追加すると、ExecuteNonQuery と空間データ型に関する問題が解決される可能性がありますが、どの型をチェックすればよいでしょうか?

if (item.GetType() == typeof(//WhatType?//)) {}

+10k ポイント (緯度、経度) があり、ユーザーの場所に最も近い k ポイントを表示するアプリを作成しています。

これは非常に一般的な問題であり、車輪の再発明はしたくありません。四分木について学んでいます。この空間的な問題を解決するための良いアプローチのようです。

私はこれらのツールを使用しています：

• パイソン2.5
• MySQL
• MongoDB

Quadtreeの構築はそれほど難しくありません。クエリ？

次のようなクエリを実行する必要があります。

1. ユーザーの位置から 10 km 以内のすべてのポイントを検索します。
2. ユーザーの位置に最も近い 6 つ (または少なくとも 6 つ) のポイントを見つけます。

それを行うための標準的で一般的なアプローチは何ですか?

編集1：

+10k ポイントを MongoDB (地理空間インデックス作成) にロードしましたが、一見すると問題なく動作します。とにかく私はPostGisを見つけました:

PostGIS は、GIS (地理情報システム) オブジェクトをデータベースに格納できるようにする PostgreSQL オブジェクト リレーショナル データベース システムの拡張機能です。

そこで、PostGis を試してみようと思います。

SimpleGeoも見つけました。ポイント/場所をクラウドに保存し、API を介してクエリを実行できます: https://simplegeo.com/docs/tutorials/python#how-do-radial-nearby-query