Bagaimana saya harus mengelola data PostGIS Raster dengan berbagai proyeksi?

Saya memiliki persyaratan untuk menyimpan dan mengelola data geofisika arkeologi yang dikumpulkan sebagai array sampel persegi panjang - gambar raster.

• Setiap raster biasanya akan sampel titik apung 20x20 atau 30x30, biasanya sampel pada interval 1m.
• Survei akan terdiri dari satu atau lebih dari gambar-gambar ini di lokasi tertentu.
• Ada kemungkinan bahwa dua survei berbeda dapat dilakukan di negara yang berbeda, atau wilayah yang menggunakan proyeksi berbeda, tetapi setiap survei akan menggunakan satu dan hanya satu proyeksi.
• Mereka tidak akan pernah dilihat bersama, setiap survei biasanya akan berdiri sendiri.
• Data hanya akan diakses oleh front-end kustom, sehingga tidak akan ada pengguna yang mendapatkan kontrol langsung psqlatau sejenisnya.
• Setiap sampel perlu disimpan saat dikumpulkan, jadi saya tidak dapat memproyeksikan kembali ke CRS umum seperti Web Mercator karena satu sampel dapat berakhir mencakup lebih atau kurang area daripada dalam proyeksi asli, dan analisis perlu dilakukan pada data.

Bagaimana saya sebaiknya menyimpan data dalam database PostGIS Raster? Opsi yang saya buat adalah:

1. Abaikan kendala SRID dan simpan semua data dalam satu tabel, tulis kode front-end saya untuk berurusan dengan memanipulasi data secara konsisten.
2. Simpan semua data dalam satu tabel, dan tulis ulang batasan SRID sebagai gabungan dari SRID dan ID survei.
3. Melalui pewarisan tabel, buat tabel baru untuk setiap SRID baru.
4. Melalui pewarisan tabel, buat tabel baru untuk setiap survei.

1 dan 2 memecah beberapa bagian otomatis bagus dari PostGIS, tetapi akan disembunyikan dalam kode front-end. Tetapi pertanyaan mungkin akan memakan waktu sedikit lebih lama.

3 dan 4 bisa berakhir dengan ledakan tabel yang akan membuat lebih sulit untuk mengelola kendala FK dan sebagainya.

Secara praktis, jumlah raster per survei berkisar antara 1 hingga 100 atau lebih, dan jumlah survei kemungkinan mencapai ratusan. Tetapi jumlah proyeksi yang berbeda kemungkinan akan tetap sangat rendah, yang menguntungkan 3.

Saya telah memikirkan pertanyaan Anda dan akhirnya sampai pada kesimpulan bahwa saya akan menyimpan setiap survei ke dalam databasenya sendiri .

CATATAN : berdasarkan database yang saya maksud adalah database yang dibuat di dalam satu cluster basis data postgres sesuai dengan terminologi postgres yang diberikan di sini , bukan proses postgres yang sepenuhnya terpisah dengan penggunanya sendiri, template1, dll.

Walaupun ini mungkin terdengar berlebihan, pada kenyataannya, menawarkan beberapa keuntungan:

• pengelolaan: setiap survei hanya memiliki satu tabel raster dengan srid yang memungkinkan Anda untuk mematuhi sebanyak mungkin standar postgis dalam mengelola data (yaitu: tidak mengacaukan tabel raster_columns atau FK atau batasan. Semua fungsi postgis masih berfungsi seperti yang diharapkan)

• kesederhanaan: selama Anda mengadopsi dan menerapkan strategi penamaan yang koheren seperti: memanggil setiap db sebagai nama srvy_ dan kemudian menggunakan kembali nama yang sama (yaitu surveydata ) untuk semua tabel dan kolom raster. Jika Anda sangat tertarik (saya tahu saya akan ;-)) Anda juga bisa menambahkan tabel metadata ke setiap basis data yang menggambarkan jenis data apa yang disimpan ke dalam basis data itu, kapan terakhir diperbarui dan seterusnya. Membuat skrip / query struktur database dengan penamaan yang koheren akan mudah (dan menyenangkan).

• itu berfungsi sesuai kebutuhan Anda, selama setiap survei menggunakan srid sendiri

• skalabilitas: skalabilitas karena Anda dapat memindahkan basis data (dengan mengalokasikannya pada tablespace yang berbeda ) ke spindle yang berbeda (atau disk, pool, lun, tergantung pada vendor penyimpanan) sehingga I / O dapat diparalelkan. Akan jauh lebih sulit untuk memindahkan tabel dari database yang sama ke disk yang berbeda

• keamanan: Anda dapat memberikan izin yang berbeda untuk survei yang berbeda dengan memanfaatkan keamanan basis data (sebagai lapisan tambahan di atas aplikasi)

• teruji: ada laporan postgres yang menangani ribuan basis data dalam satu contoh, lihat ini sebagai referensi

• [ini harus diuji, saya tahu ini berfungsi untuk geometri, tidak tahu untuk raster] Anda masih dapat meminta (dan mengubah) semua raster sekaligus dengan membuat tampilan seperti berikut:

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 [...]

Salah satu argumen yang mungkin menentang adalah bahwa pengaturan ini rumit, tetapi saya berpendapat bahwa itu sangat sederhana untuk ditiru begitu database pertama telah dibuat dan kemudian dapat sepenuhnya dikelola dalam skrip jika kebijakan penamaan yang tepat diterapkan.