Base de données / initialisation du plugin

La version actuellement supportée est la version 15 de PostgreSQL, téléchargeable ici : https://www.postgresql.org/download/
Les versions antérieures ou ultérieures peuvent entraîner des erreurs à l’installation du plugin et des incohérences dans le diagnostic.

La version actuelle du plugin ne permet pas de travailler sur une emprise intersectant plusieurs départements. Cependant, cette évolution est bien prévue dans une prochaine version.

La base de données peut être reconstituée sur un serveur distant, dans ce cas, à l'exécution du fichier _creation_base.bat (ou _creation_base.sh pour les postes sous Linux) il faut utiliser un compte ayant des droits de superuser sur la base de données présente sur le serveur (au cas où aucune base postgresql / extension postgis ne serait déjà présente sur ce serveur, il faudra bien sûr qu'un administrateur du serveur procède à l'installation de PostGreSQL/PostGis, en version 15 car nos premiers tests ont montré que le script de restauration n'était fonctionnel que sur postgresql15).
En fonction de la politique de gestion des droits de la base de données de ce serveur, il est bien sûr possible d'opérer la restauration "manuellement" (il faut simplement bien tout réintégrer).

• “Droit refusé pour le schéma “r_fichiers_fonciers”, “authentification par mot de passe échouée pour l’utilisateur "admin_agirisk”

Il s’agit nécessairement d’un problème à l’installation de la base de données et la solution la plus efficace est la ré-installation de la base de données à partir de l’étape 5 de la notice du plugin.

Au préalable, vous pouvez vérifier que la ligne 42 du fichier _creation_base.bat comprend bien l’information suivante : SET PGPASSWORD=AdminRisk*

• '“ERREUR:  la relation « r_ban_plus.adresse_2023_d0** » n'existe pas”, “erreur : _dep/d**/r_ban_plus.adresse_2023_d0**.sql : No such file or directory r_ban_plus.lien_adresse_bati_2023_d0**.sql”, que se passe t-il ?

Il s’agit d’une erreur d’accès au package de données de votre département. Il faut vérifier que le dossier _dep contient bien votre dossier d** dézippé.

Il est parfois possible que la première exécution du fichier _creation_base.bat renvoie des erreurs de types "commande invalide", il s'agit d'un bug qui sera résolu dans les prochaines versions de l'outil. Dans ce cas, il ne faut pas hésiter à relancer l'exécution du fichier .bat et l'installation doit normalement se dérouler correctement. Dans le cas contraire, contactez-vous par mail ou via la communauté.

Il s’agit d’une mauvaise installation de la base de données en amont de l’utilisation du plugin. Attention à bien utiliser la version 15 de PostGreSQL pour éviter toute surprise !

Quatre options possibles :

Option 1, la plus rapide mais peu optimale :
- si ce n'est déjà fait, ajouter dans QGIS une nouvelle connexion PostgreSQL à la base "agirisk_v1" locale créée au moment de l'installation de l'outil AgiRisk ;
- ouvrir et rendre éditables successivement dans QGIS, les tables "zx" et "zq" présentes dans le schéma "c_phenomenes" de la base "agirisk_v1" ;
- supprimer manuellement les enregistrements "en double" dans chacune de ces deux tables, puis réenregistrer celles-ci ;
- rouvrir ensuite le plugin AgiRisk, réimporter le périmètre du territoire sous un nouveau nom encore non utilisé, puis importer, en une seule fois, la couche d'aléa pour ce nouveau nom de territoire ;
- relancer les calculs des variables, indicateurs et représentations cartographiques.
Il est en effet nécessaire de saisir un nouveau nom de territoire, et non forcément utile de supprimer les entités de la table "territoires" du schéma "c_general", pour pouvoir relancer tous les calculs. Dans le cas contraire (utilisation ou reprise d'un nom déjà saisi auparavant dans la base), les indicateurs resteront au vert dans le plugin, sans possibilité d'un recalcul correct.

Option 2, si vous êtes à l'aise en SQL : à partir d'une fenêtre de requête SQL dans QGIS ou d'un logiciel de gestion de base de données tel que pgAdmin ou DBeaver, se positionner dans la base "agirisk_v1" locale, puis lancer les commandes SQL suivantes, en les répétant autant de fois que ce territoire a pu être saisi sous un nom différent dans le plugin :

DELETE FROM c_phenomenes.zx WHERE territoire = '[remplacer ici par le nom1 du territoire saisi dans le plugin]';
DELETE FROM c_phenomenes.zx WHERE territoire = '[remplacer ici par le nom2 du territoire saisi dans le plugin]';
...
DELETE FROM c_phenomenes.zq WHERE territoire = '[remplacer ici par le nom1 du territoire saisi dans le plugin]';
DELETE FROM c_phenomenes.zq WHERE territoire = '[remplacer ici par le nom2 du territoire saisi dans le plugin]';
...
Rouvrir ensuite le plugin AgiRisk, réimporter le périmètre de ce territoire sous un nouveau nom encore non utilisé, puis importer, en une seule fois, la couche d'aléa pour ce nouveau nom de territoire, et relancer enfin les calculs des variables, indicateurs et représentations cartographiques.

Option 3, la moins dégradée : reconstituer la base de données "agirisk_v1" de nouveau en suivant la notice d'installation comme à l'état initial (la base sera automatiquement effacée et remplacée par la structure originale)

Option 4, la plus complexe : une quatrième option, pour éviter la réinstallation complète de la base de données, pourrait être d'exécuter le même type de commande SQL qu'à l'option 2, mais pour toutes les tables des schémas "c_general", "c_occupation_sol", "c_phenomenes", "p_indicateurs" et "p_rep_carto".
Supprimer complètement une ou plusieurs de ces tables, et non seulement leurs enregistrements, impliquerait de réinitialiser leur structure avec leurs attributs. Une procédure d'initialisation de la base de données existe, son exécution seule permettrait d'effacer et de réinitialiser automatiquement toutes les tables, mais elle ne permet pas à ce jour de réinitialiser les tables d'aléas. Il est donc moins fastidieux de restaurer entièrement la base de données comme expliqué dans l'option 3.
Avec l'option 4, il faudrait également supprimer toutes les vues matérialisées présentes dans ces schémas pour éviter de mauvais affichages dans le plugin. Ces vues sont désignées par le nom de la table ("zx", "zq") suivi du nom du territoire d'étude. La commande SQL à lancer est de type "DROP MATERIALIZED VIEW IF EXISTS nom_du_schema.nom_vue_materialisee CASCADE;". Il est également possible de supprimer les vues depuis l'explorateur de couches sous QGIS : clic droit sur la vue > Gérer > Supprimer la couche.

A ce jour les indicateurs sont calculés avec des données nationales (pour faciliter l’accès aux données, les tests de construction et de résultats des indicateurs) mais il est envisagé de prendre en compte l’expertise locale et les données associées crées par les territoires, sous différentes formes :

- par le biais d’une remontée de corrections à appliquer aux référentiels ;

- par le biais d’un partenariat spécifique permettant ainsi l’intégration de vos données et leur prise en compte dans la base et le calcul de l’indicateur associé.

Stack Builder est un gestionnaire de packages nécessaire à l'installation et à l'activation d'extensions telles que PostGis, indispensable à l'utilisation du plugin.

Dans le cas où votre structure bloquerait l'installation de PostGis via cet utilitaire, il est tout à fait possible, après installation de PostGreSQL, de lancer l'installation de PostGis via l'exécutable dédié. Il faut cependant veiller à ce que la version de PostGis soit la même que celle installée pour PostGreSQL.