Як слід керувати даними PostGIS Raster з різними прогнозами?

У мене є вимога зберігати та керувати даними археологічної геофізики, які збираються у вигляді прямокутного масиву зразків - растрового зображення.

• Кожен растр, як правило, 20x20 або 30x30 зразками з плаваючою точкою, як правило, відбирають з інтервалом 1 м.
• Опитування складається з одного або декількох цих зображень у певному місці.
• Можливо, що в різних країнах або областях, що використовують різні прогнози, можуть проводитись два різних опитування, але для кожного опитування буде використана одна і лише одна прогноза.
• Їх ніколи не буде розглядати разом, кожне опитування зазвичай буде самостійно.
• Доступ до даних матиме лише спеціальний інтерфейс, тому користувачі не отримуватимуть безпосереднього контролю над ним через psqlабо подібні.
• Кожен зразок потрібно зберігати так, як він був зібраний, тому я не можу повторно відмовити його у загальній системі обміну даних, наприклад, Web Mercator, тому що один зразок міг би охопити більшу чи меншу площу, ніж у початковій проекції, і аналіз потрібно буде виконати на дані.

Як мені найкраще зберігати дані в базі даних RasGR Raster? Варіанти, які я придумав:

1. Ігноруйте обмеження SRID і зберігайте всі дані в одну таблицю, записуючи мій передній код, щоб вирішити маніпулювання даними послідовно.
2. Зберігайте всі дані в одній таблиці та перепишіть обмеження SRID як з'єднання SRID та ідентифікаційного опиту.
3. За допомогою успадкування таблиць створіть нову таблицю для кожного нового SRID.
4. За допомогою успадкування таблиць створіть нову таблицю для кожного опитування.

1 і 2 розбивають деякі приємні автоматизовані частини PostGIS, але в іншому випадку вони будуть приховані в передньому коді. Але запити, ймовірно, займуть трохи більше часу.

3 і 4 можуть закінчитися вибухом таблиць, які б ускладнювали управління обмеженнями ФК тощо.

Практично кількість растратів на опитування становить від 1 до 100 і більше, а кількість обстежень, ймовірно, зіткнеться в сотні. Але кількість чітких прогнозів, ймовірно, залишиться дуже низькою, що сприяє 3.

Я задумався над вашим запитанням і, нарешті, дійшов висновку, що я буду зберігати кожне опитування у власній базі даних .

ПРИМІТКА : під базою даних я маю на увазі базу даних, створену всередині одного кластера баз даних postgres відповідно до наведеної тут термінології postgres , а не зовсім окремий процес postgres зі своїми власними користувачами, template1 тощо.

Хоча це може здатися надмірним, воно, правда, пропонує ряд переваг:

• керованість: у кожному опитуванні є лише одна растрова таблиця з її сіткою, яка дозволяє максимально дотримуватися постгістських стандартів управління даними (тобто: ніякого змішування зі таблицею растрових стовпців або ФК або обмежень. Усі функції постгістів все ще працюють як очікувалося)

• простота: доки ви приймаєте та застосовуєте цілісну стратегію іменування, наприклад: викликайте кожен db як ім'я srvy_, а потім повторно використовуйте те саме ім'я (тобто оглядові дані ) для всіх растрових таблиць та стовпців. Якщо ви захоплено (я знаю, що хотів би ;-)), ви також можете додати таблицю метаданих до кожної бази даних, яка описує, який тип даних зберігається в цій базі даних, коли вона востаннє оновлювалася тощо. Сценарій / запит на структуру бази даних з таким узгодженим іменуванням було б легко (і приємно).

• воно працює відповідно до ваших вимог, якщо кожне опитування використовує власну сітку

• масштабованість: вона масштабує, тому що ви можете переміщувати бази даних (розподіляючи їх на різних просторах таблиць ) на різні шпинделі (або диски, пули, ланцюги, залежно від постачальника пам’яті), щоб введення / виведення можна було паралелізувати. Було б набагато складніше перемістити таблиці з однієї бази даних на різні диски

• безпека: ви можете надати різні дозволи для різних опитувань, використовуючи захист бази даних (як додатковий рівень над додатком)

• перевірено: були повідомлення про постгреси, що обробляють тисячі баз даних на одному екземплярі, див. це для посилання

• [це потрібно перевірити, я знаю, що це працює для геометрій, не знаю для растрових] ви все одно можете запитувати (і трансформувати) всі растри одночасно, створюючи представлення, такі як:

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

Один з можливих аргументів - це те, що ця установка є складною, але я б заперечував, що натомість дуже просто повторити, як тільки була створена перша база даних, і тоді її можна повністю керувати в сценаріях, якщо буде застосовано правильну політику іменування.