¿Cómo debo administrar los datos Ráster PostGIS con diferentes proyecciones?

Tengo el requisito de almacenar y administrar datos de geofísica arqueológica que se recopilan como una matriz rectangular de muestras, una imagen de trama.

• Cada ráster generalmente tendrá muestras de punto flotante de 20x20 o 30x30, típicamente muestreadas a intervalos de 1m.
• Una encuesta consistirá en una o más de estas imágenes en una ubicación determinada.
• Es posible que se realicen dos encuestas diferentes en diferentes países o áreas que utilizan diferentes proyecciones, pero cada encuesta utilizará una y solo una proyección.
• Es probable que nunca se vean juntos, cada encuesta generalmente se considerará sola.
• Solo se podrá acceder a los datos mediante un front-end personalizado, por lo que no habrá usuarios que obtengan un control directo a través de ellos psqlo similar.
• Cada muestra debe almacenarse tal como se recopiló, por lo que no puedo volver a proyectarla en un CRS común como Web Mercator porque una muestra podría terminar cubriendo más o menos área que en la proyección original, y será necesario realizar un análisis en los datos.

¿Cómo debería almacenar mejor los datos en una base de datos Ráster PostGIS? Las opciones que se me ocurrieron son:

1. Ignore las restricciones de SRID y almacene todos los datos en una tabla, escribiendo mi código de front-end para lidiar con la manipulación de los datos de manera consistente.
2. Almacene todos los datos en una tabla y reescriba la restricción SRID como un compuesto de SRID e ID de encuesta.
3. Mediante la herencia de tablas, cree una nueva tabla para cada nuevo SRID.
4. Mediante la herencia de tablas, cree una nueva tabla para cada encuesta.

1 y 2 rompen algunas de las bonitas partes automatizadas de PostGIS, pero de lo contrario estarán ocultas en el código de front-end. Pero las consultas probablemente tomarán un poco más de tiempo.

3 y 4 podrían terminar con una explosión de tablas que dificultaría la gestión de las restricciones de FK, etc.

Prácticamente, el número de rásteres por encuesta es de 1 a 100 o más, y es probable que el número de encuestas llegue a cientos. Pero es probable que el número de proyecciones distintas siga siendo muy bajo, lo que favorece 3.

He pensado en su pregunta y finalmente llegué a la conclusión de que almacenaría cada encuesta en su propia base de datos .

NOTA : por base de datos me refiero a una base de datos creada dentro de un único clúster de base de datos postgres según la terminología postgres dada aquí , no un proceso postgres completamente separado con sus propios usuarios, template1, etc.

Si bien esto puede parecer excesivo, de hecho, ofrece varias ventajas:

• manejabilidad: cada encuesta tiene solo una tabla ráster con su cuadrícula que le permite adherirse lo más posible a los estándares postgis de gestión de datos (es decir, no se mete con la tabla raster_columns o FKs o restricciones. Todas las funciones postgis todavía funcionan como se esperaba)

• simplicidad: siempre que adopte y aplique una estrategia de denominación coherente como: llamar a cada db como srvy_ name y luego reutilizar el mismo nombre (es decir, surveydata ) para todas las tablas y columnas ráster. Si está tan interesado (sé que lo haría ;-)) también podría agregar una tabla de metadatos a cada base de datos que describa qué tipo de datos se almacenan en esa base de datos, cuándo se actualizaron por última vez, etc. Crear una secuencia de comandos / consultar una estructura de base de datos con una denominación tan coherente sería fácil (y agradable).

• funciona según sus requisitos, siempre y cuando cada encuesta use su propia cuadrícula

• escalabilidad: se escala porque puede mover bases de datos (asignándolas en diferentes espacios de tabla ) a diferentes ejes (o discos, agrupaciones, lun, según el proveedor de almacenamiento) para que la E / S se pueda paralelizar. Sería mucho más difícil mover tablas de la misma base de datos a diferentes discos

• seguridad: puede otorgar diferentes permisos a diferentes encuestas explotando la seguridad de la base de datos (como una capa adicional sobre la aplicación)

• probado: ha habido informes de postgres que manejan miles de bases de datos en una sola instancia, vea esto como referencia

• [esto tiene que ser probado, sé que funciona para geometrías, no sé para rásteres] todavía puede consultar (y transformar) todos los rásteres a la vez creando vistas como las siguientes:

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 posible argumento en contra es que esta configuración es compleja, pero diría que, en cambio, es muy simple replicar una vez que se ha establecido la primera base de datos y luego se puede administrar por completo en las secuencias de comandos si se implementa una política de nomenclatura adecuada.