Como devo gerenciar os dados do PostGIS Raster com diferentes projeções?

Eu tenho um requisito para armazenar e gerenciar dados geofísicos arqueológicos que são coletados como uma matriz retangular de amostras - uma imagem rasterizada.

• Cada varredura geralmente contém amostras de ponto flutuante de 20x20 ou 30x30, geralmente amostradas em intervalos de 1m.
• Uma pesquisa consistirá em uma ou mais dessas imagens em um determinado local.
• É possível que duas pesquisas diferentes possam ocorrer em diferentes países ou áreas que usam projeções diferentes, mas cada pesquisa utilizará uma e apenas uma projeção.
• É provável que eles nunca sejam visualizados juntos; cada pesquisa geralmente fica sozinha.
• Os dados serão acessados ​​apenas por um front-end personalizado, portanto, não haverá usuários obtendo controle direto dos mesmos psqlou similares.
• Cada amostra precisa ser armazenada conforme foi coletada, portanto não posso reprojetá-la em um CRS comum, como o Web Mercator, porque uma amostra pode acabar cobrindo mais ou menos área do que a projeção original, e a análise precisará ser realizada nos dados.

Como devo armazenar melhor os dados em um banco de dados PostGIS Raster? As opções que eu criei são:

1. Ignore as restrições SRID e armazene todos os dados em uma tabela, escrevendo meu código de front-end para lidar com a manipulação de dados de maneira consistente.
2. Armazene todos os dados em uma tabela e reescreva a restrição SRID como um composto de SRID e ID da pesquisa.
3. Por meio da herança de tabela, crie uma nova tabela para cada novo SRID.
4. Por meio da herança de tabela, crie uma nova tabela para cada pesquisa.

1 e 2 quebram algumas das partes automatizadas do PostGIS, mas ficam ocultas no código de front-end. Mas as consultas provavelmente levarão um pouco mais de tempo.

3 e 4 podem acabar com uma explosão de tabelas que dificultariam o gerenciamento de restrições de FK e assim por diante.

Praticamente, o número de rasters por pesquisa é de 1 a 100 ou mais, e é provável que o número de pesquisas chegue às centenas. Mas é provável que o número de projeções distintas permaneça muito baixo, o que favorece 3.

Pensei na sua pergunta e, finalmente, cheguei à conclusão de que eu armazenaria cada pesquisa em seu próprio banco de dados .

NOTA : Por banco de dados, quero dizer um banco de dados criado dentro de um único cluster de banco de dados do postgres, de acordo com a terminologia do postgres fornecida aqui , e não um processo completamente separado do postgres com seus próprios usuários, template1, etc.

Embora isso possa parecer um exagero, de fato, oferece várias vantagens:

• gerenciabilidade: cada pesquisa possui apenas uma tabela raster com seu srid, o que permite que você adira o máximo possível aos padrões de gerenciamento de dados postgis (ou seja: não mexa com a tabela raster_columns ou com os FKs ou restrições. Todas as funções do postgis ainda funcionam conforme o esperado)

• simplicidade: contanto que você adote e aplique uma estratégia de nomeação coerente, como: chame cada db como srvy_ name e, em seguida, reutilize o mesmo nome (por exemplo, surveydata ) para todas as tabelas e colunas de varredura. Se você gosta tanto (eu sei que faria ;-)), você também pode adicionar uma tabela de metadados a cada banco de dados, descrevendo que tipo de dados são armazenados nesse banco de dados, quando foi atualizado pela última vez e assim por diante. Criar scripts / consultar uma estrutura de banco de dados com uma nomeação coerente seria fácil (e agradável).

• funciona de acordo com os seus requisitos, desde que cada pesquisa use seu próprio srid

• escalabilidade: é escalável porque você pode mover bancos de dados (alocando-os em diferentes espaços de tabela ) em eixos diferentes (ou discos, conjuntos, lun, dependendo do fornecedor do armazenamento) para que a E / S possa ser paralelizada. Seria muito mais difícil mover tabelas do mesmo banco de dados para discos diferentes

• segurança: você pode conceder permissões diferentes para diferentes pesquisas explorando a segurança do banco de dados (como uma camada adicional acima do aplicativo)

• testado: houve relatos de postgres manipulando milhares de bancos de dados em uma única instância; consulte isso para uma referência

• [isso precisa ser testado, eu sei que funciona para geometrias, não para rasters], você ainda pode consultar (e transformar) todas as rasters de uma só vez, criando visualizações como as seguintes:

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

Um argumento possível é que essa configuração é complexa, mas eu diria que é muito simples replicar uma vez que o primeiro banco de dados tenha sido estabelecido e, em seguida, ele pode ser completamente gerenciado em scripts se a política de nomeação apropriada for implementada.