Jak zarządzać danymi PostGIS Raster przy użyciu różnych prognoz?

Mam obowiązek przechowywania danych geofizyki archeologicznej i zarządzania nimi, które są gromadzone jako prostokątny zestaw próbek - obraz rastrowy.

• Każdy raster zwykle pobiera próbki zmiennoprzecinkowe 20 x 20 lub 30 x 30, zwykle próbkowane w odstępach 1 m.
• Ankieta będzie składać się z jednego lub więcej z tych obrazów w danej lokalizacji.
• Możliwe jest, że w różnych krajach lub obszarach, w których stosuje się różne prognozy, mogą odbywać się dwie różne ankiety, ale każda ankieta wykorzysta jedną i tylko jedną projekcję.
• Prawdopodobnie nigdy nie będą oglądane razem, każda ankieta zwykle siedzi sama.
• Dostęp do danych będzie możliwy tylko za pomocą niestandardowego interfejsu użytkownika, więc użytkownicy nie będą mieli nad nimi bezpośredniej kontroli psqllub podobnie.
• Każda próbka musi być przechowywana w takiej postaci, w jakiej została zebrana, więc nie mogę ponownie przerzucić jej na wspólny CRS, taki jak Web Mercator, ponieważ jedna próbka może ostatecznie obejmować więcej lub mniej powierzchni niż w pierwotnej projekcji, a analiza będzie musiała zostać wykonana na danych.

Jak najlepiej przechowywać dane w bazie danych PostGIS Raster? Dostępne opcje to:

1. Ignoruj ​​ograniczenia SRID i przechowuj wszystkie dane w jednej tabeli, pisząc mój kod front-end, aby radzić sobie z manipulowaniem danymi w spójny sposób.
2. Przechowuj wszystkie dane w jednej tabeli i przepisz ograniczenie SRID jako związek SRID i ID ankiety.
3. Poprzez dziedziczenie tabeli utwórz nową tabelę dla każdego nowego SRID.
4. Poprzez dziedziczenie tabeli utwórz nową tabelę dla każdej ankiety.

1 i 2 psują niektóre ładne zautomatyzowane części PostGIS, ale w przeciwnym razie zostaną ukryte w kodzie frontonu. Ale zapytania prawdopodobnie potrwają nieco dłużej.

3 i 4 mogą zakończyć się eksplozją tabel, która utrudniłaby zarządzanie ograniczeniami FK i tak dalej.

W praktyce liczba rastrów na ankietę wynosi od 1 do 100 lub więcej, a liczba ankiet prawdopodobnie osiągnie setki. Ale liczba wyraźnych prognoz prawdopodobnie pozostanie bardzo niska, co sprzyja 3.

Zastanowiłem się nad twoim pytaniem i ostatecznie doszedłem do wniosku, że każdą ankietę przechowuję we własnej bazie danych .

UWAGA : przez bazę danych rozumiem bazę danych utworzoną w jednym klastrze bazy danych postgres zgodnie z podaną tutaj terminologią postgres , a nie całkowicie odrębnym procesem postgres z własnymi użytkownikami, szablonem 1 itd.

Choć może się to wydawać przesadne, w rzeczywistości ma kilka zalet:

• łatwość zarządzania: każda ankieta ma tylko jedną tabelę rastrową z jej oknem, co pozwala na przestrzeganie w jak największym stopniu standardów zarządzania danymi postgis (tj .: brak bałaganu w tabeli raster_columns lub FK lub ograniczeń. Wszystkie funkcje postgis nadal działają zgodnie z oczekiwaniami)

• prostota: o ile przyjmujesz i egzekwujesz spójną strategię nazewnictwa, np .: wywołujesz każdą bazę danych jako srvy_ name, a następnie ponownie używasz tej samej nazwy (tj. surveyydata ) dla wszystkich tabel rastrowych i kolumn. Jeśli jesteś tak chętny (wiem, że tak ;-)), możesz również dodać tabelę metadanych do każdej bazy danych opisującą, jakie dane są przechowywane w tej bazie danych, kiedy była ona ostatnio aktualizowana i tak dalej. Skrypty / zapytania do struktury bazy danych z tak spójnym nazewnictwem byłyby łatwe (i przyjemne).

• działa zgodnie z twoimi wymaganiami, o ile każda ankieta używa własnego okienka

• skalowalność: skaluje się, ponieważ można przenosić bazy danych (przydzielając je w różnych przestrzeniach tabel ) na różne wrzeciona (lub dyski, pule, jednostki logiczne, w zależności od dostawcy pamięci masowej), aby umożliwić równoległe operacje we / wy. Znacznie trudniej byłoby przenieść tabele z tej samej bazy danych na różne dyski

• bezpieczeństwo: możesz nadać różne uprawnienia różnym ankietom, wykorzystując zabezpieczenia bazy danych (jako dodatkową warstwę nad aplikacją)

• testowane: pojawiły się doniesienia o postgresach obsługujących tysiące baz danych w jednej instancji, zobacz to w celach informacyjnych

• [musi to zostać przetestowane, wiem, że to działa w przypadku geometrii, nie wiem w przypadku rastrów] nadal możesz wyszukiwać (i przekształcać) wszystkie rastry jednocześnie, tworząc widoki takie jak poniżej:

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

Jednym z możliwych argumentów przeciwko jest to, że ta konfiguracja jest złożona, ale chciałbym z powrotem argumentować, że zamiast tego bardzo łatwo jest replikować po ustanowieniu pierwszej bazy danych, a następnie można nią całkowicie zarządzać w skryptach, jeśli zostaną wprowadzone odpowiednie zasady nazewnictwa.