さまざまな投影法でPostGISラスターデータを管理するにはどうすればよいですか？

私は、サンプルの長方形の配列、つまりラスターイメージとして収集された考古学的地球物理学データを保存および管理する必要があります。

• 各ラスターは通常、20x20または30x30の浮動小数点サンプルで、通常1m間隔でサンプリングされます。
• 調査は、特定の場所にあるこれらの1つ以上の画像で構成されます。
• 2つの異なる調査が異なる国または異なる予測を使用する地域で行われる可能性がありますが、各調査は1つだけの予測を使用します。
• これらは一緒に表示される可能性は低く、通常、各調査は単独で行われます。
• データはカスタムのフロントエンドによってのみアクセスされるため、ユーザーがデータを直接制御することなどはありませんpsql。
• 各サンプルは収集されたとおりに保存する必要があるため、1つのサンプルが元の投影よりも多かれ少なかれカバーする可能性があり、分析を実行する必要があるため、Webメルカトルなどの一般的なCRSに再投影することはできません。データについて。

PostGIS Rasterデータベースにデータを保存するにはどうすればよいですか？私が思いついたオプションは次のとおりです。

1. SRID制約を無視し、すべてのデータを1つのテーブルに格納して、一貫した方法でデータを操作するためのフロントエンドコードを記述します。
2. すべてのデータを1つのテーブルに保存し、SRID制約をSRIDと調査IDの複合として書き換えます。
3. テーブルの継承により、新しいSRIDごとに新しいテーブルを作成します。
4. テーブルの継承により、調査ごとに新しいテーブルを作成します。

1と2はPostGISの自動化された優れた部分のいくつかを壊しますが、そうでなければフロントエンドコードに隠されます。しかし、クエリはおそらく少し長くかかります。

3と4は、テーブルの爆発で終わり、FK制約の管理などが困難になる可能性があります。

実際には、調査ごとのラスタの数は1〜100以上であり、調査の数は数百に達する可能性があります。しかし、明確な予測の数は非常に少ないままである可​​能性が高く、3が有利です。

私はあなたの質問について考え、最終的には各調査を独自のデータベースに保存するという結論に達しました。

注：データベースとは、ここに記載されているpostgresの用語に従って、単一のpostgresデータベースクラスタ内に作成されたデータベースを意味します。独自のユーザーやテンプレート1などの完全に別個のpostgresプロセスではありません。

これはやり過ぎに聞こえるかもしれませんが、実際には、いくつかの利点があります。

• 管理性：各調査には、sridを備えたラスターテーブルが1つだけあります。これにより、データを管理するpostgis標準に可能な限り準拠することができます（つまり、raster_columnsテーブルやFKまたは制約を変更する必要はありません。すべてのpostgis関数は引き続き期待どおりに機能します）。

• シンプルさ：次のような一貫した命名戦略を採用して適用する限り：各dbをsrvy_ nameとして呼び出し、すべてのラスターテーブルと列に 同じ名前（つまり、surveydata）を再利用します。あなたが非常に熱心な場合は（私はそうだと思います;-)）、各データベースにメタデータテーブルを追加して、そのデータベースに格納されているデータの種類、最後に更新された日時などを説明することもできます。このような一貫性のあるネーミングでデータベース構造をスクリプト化/クエリすることは簡単です（そして快適です）。

• 各調査が独自のsridを使用している限り、要件に応じて機能します

• スケーラビリティ：I / Oを並列化できるように、データベースを（異なるテーブルスペースに割り当てることにより）異なるスピンドル（または、ストレージベンダーに応じてディスク、プール、LUN）に移動できるため、スケーリングします。同じデータベースから別のディスクにテーブルを移動するのははるかに困難です。

• セキュリティ：データベースのセキュリティを活用することで、さまざまな調査にさまざまな権限を付与できます（アプリケーションの上の追加レイヤーとして）

• テスト済み：postgresが1つのインスタンスで数千のデータベースを処理しているという報告があります。参照としてこれを参照してください

• [これはテストする必要があります。ジオメトリでは機能しますが、ラスターではわかりません]次のようなビューを作成することで、すべてのラスターを一度にクエリ（および変換）できます。

create or replace view v_all_surveys_as_wgs84 as select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number1.rasterdata union all select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number2.rasterdata [...]

考えられる反論の1つは、このセットアップは複雑であるということですが、最初のデータベースが確立されたら複製するのは非常に簡単であり、適切な命名ポリシーが設定されていれば、スクリプトで完全に管理できると主張します。