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


14

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

このトピックについて議論しているHSR Universtiy of Applied Sciences Rapperswillの論文を見つけました。そのようなデータを保存する3つの方法を提案します:Whole data in one tupelEach 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

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


1
巨大とはどういう意味か、ポイントクラウドからどのような情報が必要なのか、大まかな考えを教えていただけますか?すなわち、ブロックされたMultipointZMや、おそらく個別のポイント測定ごとに一意の値を取得するためにPointを必要とする他の属性データに保存できるXYZと強度のみですか?
トルスティ

1
ライダーを10x10メートルのマルチポイントに分類して保存します。グラウンドZ値のみを使用します
-simplexio

1
@AndreSilva目的は、データから道路の表面プロファイルを生成することです。ここでは、ポイントをDEMグリッドに変換し、PostGISを使用してそれらをラスタブロックとして保存し、SAGAを使用して最終的にプロファイルを作成しました。テスト目的で実行されますが、dbインポートの前にデータをラスタリングすることによる精度の低下も意味します。また、指定されたプロファイルラインによって切り取られたグリッドセルのエクスポートは、PostGISでは非常に遅くなります(ST_Unionのおかげです)。同様のタスクのためのツールをお勧めできたらいいと思います。
knutella

1
@til_b:まあ、これはまさに私が話していたものです...良い発見:)
knutella

1
私は同じ質問を自問し、いくつかのピースを組み合わせて、プロトタイプを作成しました。これまでのところ、数百万から数億のスケーラビリティの問題がなく、それぞれ約20の属性があり、うまく機能します。このように多くのポイントがあるため、エリア内のポイントを見つけるには数百ミリ秒かかります。タイムスタンプ(私にとって正確な取得時間)でフィルタリングするには、ほぼ同じ時間がかかります。全体的に、パフォーマンスは「LiDAR Data Management Pipeline; Spatial Database Population to Web-Application Visualization」よりも優れています。データはDBに圧縮されます(約1:2

回答:


5

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

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

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


こんにちは、非常に多くの詳細情報をありがとう。あなたの論文で提供されているides / testsは本当に便利なようです!全体を見るには時間がかかりますが、最初に読んだときに見たように、すでに完全な回避策が提供されています。追加していただきありがとうございます!また、ビデオとブラウザベースのPCビューアは非常に興味深いもので、非常にスムーズに動作するようです!残念ながら、私は他のものに短期的に手を取りました。しかし、まもなくpc-dataを使い続けたいと思っています。
knutella

垣間見るプロジェクトは、実際にデモをここに冷却していますncg.nuim.ie/glimpse/auth/login.php
Kozuch

7

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

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

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

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

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

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


前に述べた提案の結論として、あなたの「要約」はかなりよく当てはまると思います。あなたが言ったように、そのようなデータをロードする「正しい」方法は、ニーズと提案されたソリューション内で把握する必要があります。非常に多くのアイデアのおかげで不可能ではないことが判明しました。この問題に関する今後の研究に多くのインスピレーションを与えてくれました。どうもありがとう!
クヌーテラ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.