Comment gérer les données PostGIS Raster avec différentes projections?

J'ai besoin de stocker et de gérer les données de géophysique archéologique qui sont collectées sous la forme d'un réseau rectangulaire d'échantillons - une image tramée.

• Chaque raster comprend généralement des échantillons à virgule flottante 20x20 ou 30x30, généralement échantillonnés à des intervalles de 1 m.
• Une enquête consistera en une ou plusieurs de ces images dans un emplacement donné.
• Il est possible que deux enquêtes différentes puissent avoir lieu dans différents pays ou zones qui utilisent des projections différentes, mais chaque enquête utilisera une et une seule projection.
• Ils ne sont jamais susceptibles d'être vus ensemble, chaque enquête sera généralement indépendante.
• Les données ne seront accessibles que par un frontal personnalisé, il n'y aura donc aucun utilisateur qui en aura le contrôle direct via psqlou similaire.
• Chaque échantillon doit être stocké tel qu'il a été collecté, donc je ne peux pas le reprojeter dans un CRS commun tel que Web Mercator car un échantillon pourrait finir par couvrir plus ou moins de zone que dans la projection d'origine, et une analyse devra être effectuée sur les données.

Comment dois-je stocker au mieux les données dans une base de données PostGIS Raster? Les options que j'ai trouvées sont:

1. Ignorez les contraintes SRID et stockez toutes les données dans une table, en écrivant mon code frontal pour gérer la manipulation des données de manière cohérente.
2. Stockez toutes les données dans une table et réécrivez la contrainte SRID en tant que composé de SRID et d'ID d'enquête.
3. Grâce à l'héritage de table, créez une nouvelle table pour chaque nouveau SRID.
4. Grâce à l'héritage de table, créez une nouvelle table pour chaque enquête.

1 et 2 cassent certaines des belles parties automatisées de PostGIS, mais seront autrement cachées dans le code frontal. Mais les requêtes prendront probablement un peu plus de temps.

3 et 4 pourraient se retrouver avec une explosion de tables qui rendrait plus difficile la gestion des contraintes FK et ainsi de suite.

Dans la pratique, le nombre de rasters par enquête est compris entre 1 et 100 ou plus, et le nombre d'enquêtes est susceptible de se chiffrer par centaines. Mais le nombre de projections distinctes devrait rester très faible, ce qui favorise 3.

J'ai réfléchi à votre question et suis finalement parvenu à la conclusion que je stockerais chaque enquête dans sa propre base de données .

REMARQUE : par base de données, je veux dire une base de données créée à l'intérieur d'un cluster de base de données postgres unique selon la terminologie postgres donnée ici , pas un processus postgres entièrement distinct avec ses propres utilisateurs, template1, etc.

Bien que cela puisse sembler exagéré, il offre en fait plusieurs avantages:

• gérabilité: chaque enquête n'a qu'une seule table raster avec son srid qui vous permet d'adhérer autant que possible aux normes postgis de gestion des données (c'est-à-dire: pas de problème avec la table raster_columns ou les FK ou contraintes. Toutes les fonctions postgis fonctionnent toujours comme prévu)

• simplicité: tant que vous adoptez et appliquez une stratégie de dénomination cohérente comme: appelez chaque base de données comme nom srvy_ puis réutilisez le même nom (c'est-à-dire surveydata ) pour toutes les tables et colonnes raster. Si vous êtes si intéressé (je sais que je le ferais ;-)), vous pouvez également ajouter une table de métadonnées à chaque base de données décrivant le type de données stockées dans cette base de données, la date de sa dernière mise à jour, etc. Créer un script / interroger une structure de base de données avec un nom aussi cohérent serait facile (et agréable).

• cela fonctionne selon vos besoins, tant que chaque enquête utilise son propre srid

• évolutivité: elle évolue parce que vous pouvez déplacer des bases de données (en les allouant sur différents espaces de table ) sur différentes broches (ou disques, pools, lun, selon le fournisseur de stockage) afin que les E / S puissent être parallélisées. Il serait beaucoup plus difficile de déplacer des tables de la même base de données vers des disques différents

• sécurité: vous pouvez accorder différentes autorisations à différentes enquêtes en exploitant la sécurité de la base de données (en tant que couche supplémentaire au-dessus de l'application)

• testé: il y a eu des rapports de postgres gérant des milliers de bases de données sur une seule instance, voir ceci pour une référence

• [cela doit être testé, je sais que cela fonctionne pour les géométries, je ne sais pas pour les rasters] vous pouvez toujours interroger (et transformer) tous les rasters à la fois en créant des vues comme celle-ci:

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 argument possible contre est que cette configuration est complexe, mais je dirais qu'il est plutôt très simple de répliquer une fois que la première base de données a été établie et qu'elle peut ensuite être complètement gérée dans les scripts si une stratégie de nommage appropriée est mise en place.