問題タブ [spatial-index]

分析してアプリケーションで使用する必要のある大量の空間データがあります。元のデータはWKT形式で表され、データをアップロードするためにINSERTSQLステートメントにラップしています。

ただし、このアプローチには時間がかかりすぎ、データが大きくなります（1,000万行）。それで、大量の空間データをアップロードする他の方法はありますか？

スピードアップのハックとトリックは大歓迎です。

すべてジオコーディングされた130万件のレコードを含むテーブルに空間インデックスを設定しました。これらの値は、地理データタイプの列に格納されます。私が抱えている問題は、空間インデックスを持つこの列をクエリすると、まだ本当に遅いということです。たとえば、1マイル以内のすべてのアカウントを見つけるのに約20秒かかります。

実行速度が遅いクエリの例を次に示します。

これが私のcreateindexステートメントです：

データは、単一の州の一部にあるすべての家です。したがって、半径1マイルでは、1000ポイント以上になると思います。これを適切にインデックス付けしていますか？どんな助けでも素晴らしいでしょう。

別の遅いクエリの例：

バウンティ

この質問は、いくつかの問題を引き起こします。報奨金は、全体的に対処する回答に送られます。

これが私が遊んできた問題です。

注私は、ユークリッド空間に基づかないソリューションに特に興味があります。

サイズ K の群集を形成するアクタのセットがあります。距離d(ActorA,ActorB)は任意の 2 つのアクタについて簡単に計算できます (「距離」のさまざまな定義に対してソリューションが機能するはずです)。数多くの確立されたアルゴリズムのいずれか。

この隣接セットは最初は正しいですが、アクタは常に移動しているため、各アクタの N 個の最近傍の展開リストを維持したいと考えています。私が興味を持っているのは、完全解よりも効率的な近似解です。

1. エラーが導入された後、ソリューションは正確に収束する必要があります。
2. エラーが大きくなりすぎた場合は、完全な再計算を実行しても問題ありませんが、これらのエラーの検出は安価です。

これまでのところ、友人の友人アルゴリズムを使用してきました。

これは、群集の動きが遅く、N が適切に大きい場合に、適切に機能します。小さな誤差の後に収束し、最初の基準を満たしますが、

• 大きなエラーを検出する良い方法がありません。
• エラーのサイズと頻度の定量的な説明はありませんが、
• 実際には収束しますが、常に収束することを証明することはできません。

これらの点について何かお手伝いできますか？

また、うまく機能する代替アプローチを知っていますか

• 群衆の動きが速いとき、
• 一部のアクターの動きが速い場合、
• N が小さい場合、
• ある場所では群衆がまばらで、別の場所では密集している場合、
• または特定の空間索引付けアルゴリズムを使用しますか?

私が現在取り組んでいる拡張機能は、友人の友人を一般化して、隣人の動きが速い場合に友人の友人の友人を取ることです。これはうまくスケーリングできず、エラーを定量化せずに適切なパラメーターを導き出すのは難しいと思います。

私はすべての提案を歓迎します！それは楽しい小さな問題です:-)

これまでの注目すべき提案

Fexvez: エージェントの速度に応じて、ランダムな余分な隣人をサンプリングします。サンプル サイズ。移動しようとしているエリアからサンプリングすることもおそらく役立つでしょう。

エージェントspeed*delta_timeが既知の最も遠い隣人までの距離を超えると、隣人を再サンプリングします。

最近傍グラフのスーパーセットであるDelaunay 三角形分割を維持します。1 つの最近傍のみを考慮します。

David Mount のANN ライブラリは、 移動体を処理していないようです。

私の些細なクエリは戻るのに3秒かかり、SQLプロファイラーによると大量の読み取りが必要です。なんで？

すべてジオコーディングされたポイントである5,000,000のアカウントで満たされたテーブルがあります。すべてのアカウントは、都市から半径20マイル以内に集まっています。私のインデックスはそのように見えます。

次のような単純なクエリを実行すると、次のようになります。

戻るには3秒かかり、SQL Server Profilerによると、CPUは12,203、読み取りは1,218,873でした。これらは、インデックスを使用するための膨大な数のようです。

なぜこれがとても遅いのですか？なぜこれはハードドライブからの読み取りをそれほど必要とするのですか？これのパフォーマンスを向上させるために何ができますか？

クエリプランを見ると、下のスクリーンショットのFilter演算子は、クエリのコストの34％です。

「ClusteredIndexSeek」演算子は、クエリの63％です。

すべてのラスターの空間インデックスを作成するスクリプトを作成しました。単一のディレクトリで実行すると問題なく動作しましたが、os.walk の一部としてサブディレクトリで実行するように修正しようとすると、多くのエラーが発生し始めました。私が修正できない現在のものを手伝ってもらえますか。

ありがとう、

Python 2.6.5 (r265:79096、2010 年 3 月 19 日、21:48:26) [MSC v.1500 32 ビット (Intel)] 詳細については、「help」、「copyright」、「credits」、または「license」と入力してください。

[RasterExtent_toSHP_Ver2.py を評価] P:\2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic からファイルを読み込み中 ディレクトリを次のように変更: P:\2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic\1 ディレクトリ内の 2 つの .tif ファイルを処理しています。['308000_8105000.tif', '309000_8105000.tif'] 308000_8105000.tif Created: P:\2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic\1\Temp_Polygon_Extent_1.shp Filling in: 308000_8105000 TIFF P:\2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic\ 1 64000000 309000_8105000.tif 作成: P:\2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic\1\Temp_Polygon_Extent_2.shp 記入: 309000_8105000 TIFF P: \2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic\1 64000000 [] マージ: []to: Spatial_Extent.shp arcgisscripting.ExecuteError: 実行に失敗しました。パラメータが無効です。エラー 000735: 入力データセット: 値が必要です警告 000725: 出力データセット: データセット P:\2011\Job_154_PythonScript_for_AOI\Working\Orthophotomosaic\1\Spatial_Extent.shp は既に存在します。実行 (マージ) に失敗しました。

SQL Server の空間地理インデックスには、次のレベル定義があります。

高い 低い 低い 低い

問題は、すべてのポイントが都市にあるため、すべてのポイントがレイヤー 1 の単一のセルにあることです。その結果、プライマリ フィルターはすべてのポイントを調べているため、インデックスの効率は 0% です。HIGH グリッドは 256 個のセルがあることを意味することに気付きました。代わりに 512 セルまたは 1024 セルを使用するにはどうすればよいですか? 256じゃ物足りない。

レベル別はこちらのページをご覧ください。

HIGH よりも高い値を取得する方法を知っている人はいますか?

R-tree、kd-treeなど、Haskellの空間インデックスの適切な実装はありますか...

ジオメトリ (円、多角形、ポリライン) にインデックスを付け、交差点の質問に答えることができる C# の空間インデックス ライブラリを探しています。NetTopologySuite (NTS) およびその他の 1 ファイル ソリューション プロジェクトを見つけましたが、何か重要なものを見落としていませんか?

NTSはかなり良いですが、やや重いです。2つ目はワンマンアートで、どうやら私はそれを手に取り、自分自身を維持する必要があります. サポートされ、テストされているものを見つけることができるのだろうか。

私はC#のものを探していますが、Javaのものを手に入れることができれば、それを適応させることができます.

MSSQL でデータベースを設定する際に少し問題があります。地理データ型の列にインデックスを設定しようとすると、次のエラーが発生し続けます。

メッセージ 6507、レベル 16、状態 2、行 1 HRESULT 0x80070008 で不正な形式のアセンブリ 'mscorlib' を開くことができませんでした。

ここにコードがあります

PostgreSQL / PostGIS は初めてです。私は単純なアルゴリズムを解決するためにそれを評価しています:半径 (メートル) 内のすべての点を見つけようとします。これが私のテーブルです：

列に要旨索引を追加しましたpointが、それが正しい設計かどうかわかりません。挿入されたすべての「ポイント」はSRID=4326.

近くのポイントを取得するには2つの方法があるようです：

ST_Distance、ST_Distance_Sphere。例として2を取り上げます。

どのアルゴリズムが " point_index" を利用するのだろうか? 何百万ものポイントがある場合、両方とも非常に高速に実行できますか?

別の質問ですが、セルの SRID を照会するにはどうすればよいですか (答えが見つかりませんで検索しました)。私にできることは、 hibernate-spatial-postgis で " com.vividsolutions.jts.geom.Point" を取得し、返されたポイントから SRID を取得することだけです。SQL でクエリを実行するにはどうすればよいですか? ありがとう。

環境 ：

- - 更新しました - -

ありがとう@filiprem、私はこれを試しました：

を利用しているかどうかはどうすればわかり"point_index" gist (point)ますか? データ量の多い検索に耐えられるでしょうか？