Répartir les données de zones d'aléa dans des tables séparées

[gcebelieu]

Sujet levé en atelier implémentation du 14/06/2023 (#42)

Le standard a fait le choix de représenter les Zones d'Aléas PPR dans deux classes différentes : ZoneAleaReference ou ZoneAleaEcheance100ans du fait de la distinction qui est faite de ces deux types d'aléas dans le réglement relatif aux PPRI pour la submersion marine. La proposition est d'aller plus loin et de répartir les objets dans des tables séparées selon :

• l'occurence
• le type d'aléa

Avantages :

• avoir directement les données correspondantes à un aléa et une occurence donnés sans avoir à faire de filtre
• tables plus petites

Inconvénients :

• Dictionnaire de tables beaucoup plus important et dépendant de la nomenclature risques et de la définition des occurences
• Gestion plus complexe pour un système aval qui aurait à unifier ces tables pour les représenter dans une cartographie dynamique (Géorisques)

[GuillaumeChretien]

Cette question a été soulevée par la DDTM76 car en l'état le projet de standard reproduit à un détail près (distinction échéance100ans) l'organisation des aléas du standard COVADIS dans une seule table.
Difficulté de cette table : elle est non utilisable en l'état et nécessite toujours des filtres et des mises en forme sur des instanciations multiples dans les projet qgis ou les cartes interactives.

D'où la question posée : pourquoi ne pas directement faire un standard qui correspond à l'utilisation la plus courante pour représenter les aléas ?

Autre avantage : on pourrait attacher une mise en forme par table.

En seine-maritime cela ferait au max 5 tables au lieu de 2 pour les risques naturels et 2 ou 3 au lieu de 1 pour les risques techno.

Si l'objectif du standard est de diminuer le nombre de tables, l'effort pourrait aussi porter sur d'autres classes moins prioritaires.

[gcebelieu]

La dernière version du standard Covadis TRI, pour éviter d'avoir des tables trop volumineuses, avait introduit la possibilité de séparer les tables relatives aux surfaces inondables par alea, scenario et cours d'eau :

Pour répondre à la demande on pourrait s'inspirer de ce mécanisme pour gérer cette séparation au niveau implémentation en proposant d'implémenter nos tables d'aléas de cette manière :

[TypePPR]_[CodeGASPARComplet]_zonealea_[code alea]_[occurence]_[TypeGeometrie]

Exemple pour un alea submersion marine (code GASPAR 117), à échéance 100ans :

pprn_76ddtm20120001_zonealea_117_q100_s

Cela soulève quelques remarques et questions :

• Cela nécessite de bien normaliser les types d'occurences (pour l'instant, c'est libre dans le modèle)
• Est-ce qu'on laisse cette proposition d'éclatement facultatif (dans la mesure où la structure des tables reste la même) ?
• Doit-on maintenir une table ZoneAleaReference et ZoneAleaEcheance100ans si on peut faire la distinction par l'occurence ?