4

断片化されすぎて効率的にクエリできないように見える無線マップを使用しています。単一のポイントがマルチポリゴン内にあるかどうかを尋ねると、応答時間は20〜40秒です(「範囲内」/「含む」/「重複」をテストしました)。私はPostGISとGeoDjangoを使用してクエリを抽象化します。

マルチポリゴン列にはGiSTインデックスがあり、VACUUMANALYZEを試しました。私はPostgreSQL8.3.7を使用しています。およびDjango1.2。

マップは広い地理的領域に広がっています。これらは元々、地形を意識した無線ツールによって生成されたため、無線セル/ポリゴンは断片化されています。

私の目標は、マルチポリゴン内のポイント(つまり、信号でカバーされている場合とされていない場合がある家)を照会することです。

すべてのラジオマップは、100.000から300.000の頂点(合計)で構成されており、ポリゴンの数は大きく異なります。一部のマップには、10未満のポリゴンがあります。そこから、10.000〜30.000ポリゴンにジャンプします。ポリゴンと頂点の比率は、クエリが完了するまでにかかる時間にはあまり影響しないようです。

私は投影座標系を使用しており、住宅とラジオの両方のセクターで同じシステムを使用しています。Qgisは、無線セクターとマップが地形に正しく配置されていることを示しています。

私のテストクエリは、単一の無線マップ内で一度に1つの家だけを対象としています。「within」/「contains」/「overlaps」などのクエリをテストしましたが、結果は同じです。

  • 家がラジオマップから「遠い」場合の1秒未満の応答(これは、クエリで自動的に使用されるバウンディングボックスの外側にあるためだと思います)。

  • 家/ポイントが無線マップに近いか、無線マップ内にある場合、応答時間は20〜40秒です。

クエリを最適化する別の方法がありますか、それとも何らかの方法でソースマテリアルを変更/簡略化する必要がありますか?アドバイスをいただければ幸いです。

4

1 に答える 1

4

ハロー

私が最初に行うことは、マルチポリゴンを単一のポリゴンに分割し、新しいインデックスを作成することでした。そうすれば、インデックスはより効果的に機能します。これで、マルチポリゴン全体に1つの大きなバウンディングボックスがあり、インデックスは家がバウンディングボックス内にあるかどうかを判断する以外に何もできません。したがって、データセット全体に比べてポリゴンが小さいほど、インデックスの使用がより効果的になります。クエリのインデックス部分をさらに効果的にするために、グリッドを使用して単一のポリゴンを小さなポリゴンに分割する手法もあります。ただし、最初に行うことは、ST_Dump()を使用してマルチポリゴンを単一のポリゴンに分割することです。同じテーブルに多くの属性がある場合は、それを別のテーブルに配置し、それが属するラジオマップを示すIDのみを保持することをお勧めします。そうしないと、重複した属性データが大量に取得されます。

HTHニクラス

于 2010-08-04T08:17:56.933 に答える