Come devo gestire i dati di PostGIS Raster con diverse proiezioni?

Ho l'obbligo di archiviare e gestire i dati geofisici archeologici raccolti come una matrice rettangolare di campioni: un'immagine raster.

• Ogni raster di solito campionerà 20x20 o 30x30 in virgola mobile, in genere campionati ad intervalli di 1m.
• Un sondaggio consisterà in una o più di queste immagini in una determinata posizione.
• È possibile che due diversi sondaggi possano aver luogo in diversi paesi o aree che utilizzano proiezioni diverse, ma ogni sondaggio utilizzerà una sola proiezione.
• Non saranno mai visti insieme, di solito ogni sondaggio siederà da solo.
• I dati saranno accessibili solo da un front-end personalizzato, quindi non ci saranno utenti che ne ottengano il controllo diretto psqlo simile.
• Ogni campione deve essere archiviato così come è stato raccolto, quindi non posso riproiettarlo in un CRS comune come Web Mercator perché un campione potrebbe finire per coprire un'area più o meno rispetto alla proiezione originale e sarà necessario eseguire l'analisi sui dati.

Come devo conservare al meglio i dati in un database PostGIS Raster? Le opzioni che ho escogitato sono:

1. Ignora i vincoli SRID e archivia tutti i dati in una tabella, scrivendo il mio codice front-end per gestire la manipolazione dei dati in modo coerente.
2. Archivia tutti i dati in una tabella e riscrivi il vincolo SRID come un composto di SRID e ID sondaggio.
3. Tramite l'ereditarietà delle tabelle, creare una nuova tabella per ogni nuovo SRID.
4. Tramite l'ereditarietà delle tabelle, creare una nuova tabella per ciascun sondaggio.

1 e 2 rompono alcune delle belle parti automatizzate di PostGIS, ma saranno altrimenti nascoste nel codice front-end. Ma le query richiederanno probabilmente un po 'più di tempo.

3 e 4 potrebbero finire con un'esplosione di tabelle che renderebbe più difficile la gestione dei vincoli FK e così via.

In pratica, il numero di raster per sondaggio è compreso tra 1 e 100 o più e il numero di sondaggi è probabile che raggiunga le centinaia. Ma è probabile che il numero di proiezioni distinte rimanga molto basso, il che favorisce 3.

Ho pensato alla tua domanda e alla fine sono giunto alla conclusione che avrei archiviato ogni sondaggio nel suo database .

NOTA : per database intendo un database creato all'interno di un singolo cluster di database postgres secondo la terminologia postgres qui fornita , non un processo postgres completamente separato con i propri utenti, template1, ecc.

Sebbene ciò possa sembrare eccessivo, in realtà offre diversi vantaggi:

• gestibilità: ogni sondaggio ha una sola tabella raster con il suo srid che consente di aderire il più possibile agli standard postgis di gestione dei dati (ovvero: nessun pasticcio con la tabella raster_columns o FK o vincoli. Tutte le funzioni postgis funzionano ancora come previsto)

• semplicità: il tempo che adottare e applicare una strategia di denominazione coerente, come: chiama ogni db come srvy_ nome e poi riutilizzare lo stesso nome (cioè surveydata ) per tutte le tabelle e le colonne raster. Se sei così appassionato (so che lo farei ;-)) potresti anche aggiungere una tabella di metadati a ciascun database che descrive il tipo di dati archiviati in quel database, quando è stato aggiornato l'ultima volta e così via. Scrivere / interrogare una struttura di database con un nome così coerente sarebbe facile (e piacevole).

• funziona secondo le vostre esigenze, purché ogni sondaggio utilizzi il proprio srid

• scalabilità: si ridimensiona perché è possibile spostare database (allocandoli su diversi tablespace ) su diversi mandrini (o dischi, pool, lun, a seconda del fornitore di archiviazione) in modo da poter parallelizzare l'I / O. Sarebbe molto più difficile spostare le tabelle dallo stesso database su dischi diversi

• sicurezza: è possibile concedere autorizzazioni diverse a diversi sondaggi sfruttando la sicurezza del database (come livello aggiuntivo sopra l'applicazione)

• testato: sono stati segnalati casi di postgres che gestiscono migliaia di database in una singola istanza, vedere questo per un riferimento

• [questo deve essere testato, so che funziona per le geometrie, non lo so per i raster] puoi comunque interrogare (e trasformare) tutti i raster contemporaneamente creando viste come le seguenti:

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

Un possibile argomento contrario è che questa configurazione è complessa, ma vorrei ribattere che è invece molto semplice replicare una volta che il primo database è stato creato e quindi può essere completamente gestito negli script se viene messa in atto una politica di denominazione adeguata.