PostGISの巨大なポイントクラウドレーザーデータ-格納と処理

膨大な数のレーザースキャンされたポイントクラウドデータを、処理の時間的側面を念頭に置いてPostGISに保存する方法はどのように考えられるのでしょうか。PointPostGISにはジオメトリオブジェクトが存在します。しかし、私が知る限り、各ポイントが新しいtupelに保存されるため、数百万以上が保存されている場合、特定のポイントの検索は非常に遅いプロセスになります。

このトピックについて議論しているHSR Universtiy of Applied Sciences Rapperswillの論文を見つけました。そのようなデータを保存する3つの方法を提案します：Whole data in one tupel、Each point in one tupelまたはSplitting Data into Blocks各ブロックの拡張を保持する情報テーブルによって参照されます。3番目の方法は、保存されたポイントを見つけるのに最も役立つように思えるので、誰かが既にそれを使って経験をしたことがあるのでしょうか？

論文はここにあります：http : //wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

最後になりましたが、私はgithubのプロジェクトに困惑しました。これはPostgeSQLの点群マナーに対処しているようです。残念ながら、ネットに関する情報はあまり多くありません。ここで同じ質問があります：誰かが既にそれでいくつかの経験をしましたか？そのような目的に使用できますか？

プロジェクトはここにあります：https : //github.com/pramsey/pointcloud

また、もしあれば、他の提案、アイデア、または経験について聞いてうれしいです。しかし、非営利的なソリューションが好まれることを認めなければなりません。

あなたの質問にはたくさんあります。簡単な答えはイエスです。巨大なポイントクラウドデータをPostGISに保存し、処理に使用することは完全に可能です。これを行う完全なシステムを構築しました。

このビデオは数字が少し古くなっていますが、バックエンドで処理するためにPythonを介してアクセス可能なpostgisのTBのモバイル/地上および航空データと、データの3D表示とダウンロードを可能にするWebフロントエンドがありました。 https://vimeo.com/39053196

結局のところ、PostGISにデータを保存する方法と、データへのアクセス方法にかかっています。航空データの適切な解決策は、何らかの方法でデータをグリッド化し、効率のためにマルチポイントを使用することです。ただし、ポイント密度が1平方あたり500〜30000ポイント以上になる可能性があるモバイルデータまたは地上データを使用している場合、この方法は機能しません。次に、ハードウェアと、予想される同時ユーザー数に注目します。これについての詳細は、私たちの論文のいくつかで見つけることができます http：//www.mendeley.com/profiles/conor-mc-elhinney/のます。

（答えは上記の私と他の人のコメントに基づいています;実際にはテストしていません）

ポイントをMultiPointZMとして保存します。最適なグリッドサイズはおそらくアクセスパターンに依存するため、これをテストする必要があります。空間インデックスを持つ通常のグリッドは、クエリを非常に高速にする必要があります。3Dアクセスが重要な場合、MultiPointZMは2D平面グリッドではなく3Dブロックベース（1）になり、（PostGIS> = 2.0の場合）&&&を使用して高速3Dクエリを実行できます。

グリッドパターンを別のテーブルに保存することもできます。これは、データを更新したり、編集後などにMultiPointZMブロックが境界内に留まることを検証する場合などに便利です。

タイムスタンプまたは他のデータの保存は、一度に1つのブロックに対してのみ可能ですが、一部のバイナリ/カテゴリデータは、カテゴリや属性が多すぎない場合、属性ごとに各ブロックを分解することで保存できます。

データを個別のPointZMとして保存しなければならない場合、グリッドテーブル+ Bツリーインデックスの外部キーにより、特定のポイントのみの読み込みが、空間がある場合でも、テーブルを直接クエリするよりもはるかに高速になります。インデックス。

（1）Z値の範囲が小さい場合（結局、道路です）、これはおそらく意味をなさないでしょう。