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.