ฉันจะจัดการข้อมูล PostGIS Raster ด้วยการคาดการณ์ที่แตกต่างกันได้อย่างไร

ฉันมีข้อกำหนดในการจัดเก็บและจัดการข้อมูลธรณีฟิสิกส์ที่เก็บรวบรวมเป็นตัวอย่างรูปสี่เหลี่ยมผืนผ้า - ภาพแรสเตอร์

• โดยทั่วไปแล้วแรสเตอร์แต่ละตัวอย่างจะมีจุดลอยตัว 20x20 หรือ 30x30 โดยปกติจะสุ่มตัวอย่างที่ระยะ 1 เมตร
• การสำรวจจะประกอบด้วยภาพเหล่านี้หนึ่งภาพขึ้นไปในตำแหน่งที่กำหนด
• อาจเป็นไปได้ที่การสำรวจสองแบบที่แตกต่างกันอาจเกิดขึ้นในประเทศต่าง ๆ หรือพื้นที่ที่ใช้การคาดการณ์ที่แตกต่างกัน แต่การสำรวจแต่ละครั้งจะใช้การฉายภาพเพียงภาพเดียว
• พวกเขาไม่เคยถูกมองด้วยกันการสำรวจแต่ละครั้งมักจะนั่งอยู่คนเดียว
• ข้อมูลจะถูกเข้าถึงได้โดย front-end ที่กำหนดเองดังนั้นจะไม่มีผู้ใช้ที่ได้รับการควบคุมโดยตรงผ่านpsqlหรือคล้ายกัน
• ต้องเก็บตัวอย่างแต่ละตัวอย่างขณะที่รวบรวมดังนั้นฉันไม่สามารถปฏิเสธมันลงใน CRS ทั่วไปเช่น Web Mercator ได้เพราะตัวอย่างหนึ่งอาจครอบคลุมพื้นที่มากหรือน้อยกว่าในการฉายต้นฉบับและการวิเคราะห์จะต้องดำเนินการ บนข้อมูล

ฉันควรเก็บข้อมูลไว้ในฐานข้อมูล PostGIS Raster ได้อย่างไร ตัวเลือกที่ฉันคิดไว้คือ:

1. ละเว้นข้อ จำกัด SRID และจัดเก็บข้อมูลทั้งหมดไว้ในตารางเดียวเขียนรหัสส่วนหน้าของฉันเพื่อจัดการกับการจัดการข้อมูลในลักษณะที่สอดคล้องกัน
2. เก็บข้อมูลทั้งหมดไว้ในตารางเดียวและเขียนข้อ จำกัด SRID ใหม่เป็นสารประกอบของ SRID และรหัสสำรวจ
3. ผ่านการสืบทอดตารางสร้างตารางใหม่สำหรับ SRID ใหม่แต่ละรายการ
4. ผ่านการสืบทอดตารางสร้างตารางใหม่สำหรับแต่ละการสำรวจ

1 และ 2 แบ่งส่วนอัตโนมัติที่ดีของ PostGIS แต่จะถูกซ่อนไว้ในรหัสส่วนหน้า แต่ข้อความค้นหาอาจใช้เวลานานกว่าเล็กน้อย

3 และ 4 อาจจบลงด้วยการระเบิดของตารางที่จะทำให้ยากต่อการจัดการข้อ จำกัด FK และอื่น ๆ

ในทางปฏิบัติจำนวนแรสเตอร์ต่อการสำรวจอยู่ที่ใดก็ได้ตั้งแต่ 1 ถึง 100 หรือมากกว่าและจำนวนของการสำรวจมีแนวโน้มที่จะวิ่งเข้าไปนับร้อย แต่จำนวนของการคาดการณ์ที่แตกต่างกันมีแนวโน้มที่จะอยู่ในระดับต่ำมากซึ่งเป็นที่โปรดปราน 3

ผมได้ให้ความคิดคำถามของคุณและในที่สุดก็มาถึงข้อสรุปว่าผมจะเก็บสำรวจแต่ละลงในฐานข้อมูลของตัวเอง

หมายเหตุ : จากฐานข้อมูลฉันหมายถึงฐานข้อมูลที่สร้างขึ้นในคลัสเตอร์ฐานข้อมูล postgres เดียวตามคำศัพท์ postgres ที่กำหนดไว้ที่นี่ไม่ใช่กระบวนการ postgres แยกกันโดยสิ้นเชิงกับผู้ใช้ของตนเอง template1 ฯลฯ

ในขณะนี้อาจฟังดูเกินจริงในความเป็นจริงมีข้อดีหลายประการ:

• ความสามารถในการจัดการ: การสำรวจแต่ละครั้งมีเพียงตารางแรสเตอร์ที่มี srid ซึ่งช่วยให้คุณสามารถยึดตามมาตรฐาน postgis ของการจัดการข้อมูลได้มากที่สุด (เช่น: ไม่ยุ่งกับตาราง raster_columns หรือ FK หรือข้อ จำกัด ฟังก์ชัน postgis ทั้งหมดยังคงทำงานตามที่คาดไว้)

• ความเรียบง่าย: ตราบใดที่คุณยอมรับและบังคับใช้กลยุทธ์การตั้งชื่อที่สอดคล้องกันเช่น: เรียกแต่ละฐานข้อมูลเป็นชื่อ srvy_ แล้วนำชื่อเดียวกันกลับมาใช้ใหม่ (เช่นsurveydata ) สำหรับตารางและคอลัมน์แรสเตอร์ทั้งหมด หากคุณกระตือรือร้น (ฉันรู้ว่าฉันจะ ;-)) คุณสามารถเพิ่มตารางข้อมูลเมตาลงในแต่ละฐานข้อมูลที่อธิบายว่าข้อมูลประเภทใดที่เก็บอยู่ในฐานข้อมูลนั้นเมื่อมีการปรับปรุงครั้งล่าสุดเป็นต้น การเขียนสคริปต์ / การสืบค้นโครงสร้างฐานข้อมูลด้วยการตั้งชื่อที่สอดคล้องกันนั้นจะง่าย (และน่าพอใจ)

• มันทำงานได้ตามความต้องการของคุณตราบใดที่การสำรวจแต่ละครั้งใช้ srid ของตัวเอง

• ความสามารถในการขยาย: มันปรับขนาดได้เนื่องจากคุณสามารถย้ายฐานข้อมูล (โดยการจัดสรรบนพื้นที่ตารางที่แตกต่างกัน) ลงบนแกนที่แตกต่างกัน (หรือดิสก์, พูล, ลูนขึ้นอยู่กับผู้ขายหน่วยเก็บ) เพื่อให้ I / O มันจะเป็นการยากมากที่จะย้ายตารางออกจากฐานข้อมูลเดียวกันไปยังดิสก์อื่น

• ความปลอดภัย: คุณสามารถให้สิทธิ์ที่แตกต่างกันในแบบสำรวจต่าง ๆ โดยใช้ประโยชน์จากความปลอดภัยของฐานข้อมูล (เป็นเลเยอร์เพิ่มเติมด้านบนแอปพลิเคชัน)

• ทดสอบแล้ว: มีรายงานเกี่ยวกับ postgres ที่จัดการฐานข้อมูลหลายพันรายการในอินสแตนซ์เดียวดูที่นี่เพื่อการอ้างอิง

• [สิ่งนี้จะต้องมีการทดสอบฉันรู้ว่ามันใช้งานได้กับรูปทรงเรขาคณิตไม่ทราบสำหรับ rasters] คุณยังสามารถสอบถาม (และแปลง) rasters ทั้งหมดในครั้งเดียวโดยการสร้างมุมมองดังต่อไปนี้:

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

ข้อโต้แย้งที่เป็นไปได้ข้อหนึ่งคือการตั้งค่านี้มีความซับซ้อน แต่ฉันขอโต้กลับว่าเป็นการง่ายมากที่จะทำซ้ำเมื่อสร้างฐานข้อมูลแรกแล้วสามารถจัดการได้อย่างสมบูรณ์ในการสร้างสคริปต์หากมีการตั้งชื่อนโยบายที่เหมาะสม