gcebelieu
commented
1 year ago Notes prises lors de l'atelier :
Evolutions nomenclature Gaspar (#18 et #28)
La présence de Victor Zimmermann (DGPR/Gaspar) a permis de discuter des modalités d'évolution de GASPAR en fonction d'éventuelles demandes du GT
- La possibilité d'instruire des procédures PaC dans GASPAR a déjà été ajouté (même si pas encore utilisé)
- L'instruction des demandes d'évolutions de GASPAR se fait avec une Task Force réunissant des représentants des service déconcentrés. Une réunion est à programmer en ce sens pour instruire les demandes du GT, y compris la mise en commun de certains concepts (liste de procédures, des états des procédures et de la nomenclature risques eu travers d'un registre)
- Le BRIL n'ayant pu être présent, les demandes d'évolution sur les nomenclatures risques n'ont pas été tranchées. Une alerte a été levée sur la charge de travail de reprise que peut induire une redéfinition de la nomenclature.
- En terme de budget, il est possible pour GASPAR de mener à bien des demandes d'évolution à court / moyen terme si elles sont acceptées
action (@gcebelieu) : organiser une réunion avec GASPAR sur ces sujets d'évolution et de partage des ressources avec GASPAR
Formats d'échange
Parmi les formats présentés, le format Geopackage est celui préféré par les DDT, DREAL présentes. Le format Shapefile est à abandonner. Il faut cependant s'enquérir :
- de l'existence de préconisations du CNIG et de la Géoplateforme (action @gcebelieu )
- de l'existence de préconisations du BRGM (action @DGPRNicolasBonnin )
Concernant la charge de travail liée au passage de l'ancien format vers celui choisi. La difficulté technique va essentiellement résider dans le paramétrage des outils pour produire les données dans le format relativement aux exigences du standard, à priori quelque soit le format choisi (Geopackage ou GML). Il conviendra dans tous les cas de proposer un accompagnement sur la production de ces données dans le nouveau format.
La capacité de Geopackage à gérer des données raster a fait remonter un besoin de prise en compte de certaines donnée raster dans les géostandards risques (utilisées notamment pour le risque inondation ou incendie) qui sont plus faciles à produire et pourraient être directement incluses sans être vectorisées. Ce sujet sera à traiter dans une seconde phase. Une issue est créée pour instruire le sujet (#38)
Implémentations : règles sur les géométries
- Géométries invalides
Les problématiques sur les géométries invalides sont plutôt bien maitrisées avec les retours d'expériences des TRIs. Il convient de les mentionner dans les standards.
Les problématiques sur les géométries valides qui deviennent invalides après un changement de coordonnées sont à investiguer (pas de cas connu par les membres du GT). Action @gcebelieu pour retrouver les cas mentionnés par le GPU.
-
Complexité des géométries
Il parait pertinent de conserver des seuils similaires à ceux appliqués par le GPU.
A priori ces seuils concernent toutes les thématiques des géostandards (aléas, zonage réglementaire, périmètre)
A noter que le seuil de rejet uniquement sur le nombre de points peut être bloquant pour certains grands polygones (par nature) qui auraient déjà une géométrie suffisamment simple. Une proposition est faite de pondérer ce seuil avec la surface.
- Une alerte est levée sur la capacité ou la volonté de certains Bureau d'étude à mettre en oeuvre la simplification des géométries qu'ils produisent. Les DDT n'ont pas forcément non plus toutes la capacité à mettre en oeuvre elles même les actions de simplification elles mêmes. Les leviers d'amélioration pour cela sont un partage auprès des services déconcentrés des méthodes déjà mise en oeuvre (notamment par la DDTM 76) mais aussi l'élaboration de cahier des charges types énonçant ces critères sur la complexité des géométries.
Une présentation des actions mises en oeuvre par la DDTM 76 sera proposée au prochain atelier du 14 juin (action @GuillaumeChretien )
- Règles topologiques
Pour le zonage réglementaire, deux approches sont possibles
- Cas 1 (à gauche sur l'image) Superposition autorisée des différents zonages à condition que les outils et ou les styles permettent d'accéder à toutes les informations de chacun des réglements concernés (pas d'occultation)
- Cas 3 (à droite) Superposition interdite ce qui implique le redécoupage de toutes des zones de chevauchement en objets séparés
La DDTM76 a mis en place le cas 3. Le processus est assez complexe (difficilement reprenable de façon homogène au niveau national) et peut induire des erreurs de géométrie.
Il n'y a pas d'avis tranché au niveau du GT. des retours d'expériences sont à récupérer auprès du GPU (action @gcebelieu )
Pour lez zones d'aléas
Il ne doit pas y avoir de superposition entre les différents niveaux d'aléas d'un même risque Il peut y avoir des règles à énoncer entre les ouvrages de protection et les zones protégées (rarement mis en oeuvre)
Pour les périmètres
Règle d'inclusion entre le périmètre prescrit et celui de la zone d'aléa (le premier incluant le second)
Pas de règles d'inclusion entre la zone d'aléa et le zonage réglementaire dans la mesure où certaines prescriptions/recommandations peuvent être faites sur des zones hors aléa afin d'éviter d'aggraver le risque.
Autres règles d'encodages
- Identifiants :
Proposer une règle logique de codage des identifiants des classe à l'instar des COVADIS PPR et TRI. Le code Procédure suit la règle de l'identifiant de procédure GASPAR.
- Codes pour les énumérés :
Rester sur la logique du framacalc : codes Alphanumériques issus de GASPAR, codes numériques sur deux chiffres pour les autres codes propres au standard. Principe du 0 de complément pour avoir toujours le même nombre de chiffres dans le code (01, 02, ...)
- Encodage des caractères:
Pas de restrictions sur les caractères accentués. Mention obligatoire (et au bon endroit selon le format) du jeu de caractères (UTF-8). Les logiciels devraient interpréter correctement les caractères.
- Système de coordonnées
Pas de débat : appliquer les systèmes légaux. A noter la possibilité de faire du Lambert conique 9 zones ou du Lambert 93 en France métropolitaine. NB : Lambert 93 suffisant pour le niveau de précision des données de risque.
Production des jeux tests
On continue sur les initiatives en cours (DDTM 76 et IGN). Il est convenu de faire un point sur les résultats au prochain atelier du 14 juin (actions : @gcebelieu et @alisonlenain pour l'IGN et @GuillaumeChretien pour la DDTM 76) @gcebelieu prendra contact avec @StanBesson pour voir s'ils souhaite aussi initier des expérimentations.
A noter qu'il reste du travail de conception pour les enjeux avant d'envisager une implémentation
@NicolasBoudesseul mentionne l'existence de données sur le risque incendie et propose de confronter ces nouveau type de données avec les nouveaux standards (à priori, nouvelle classe à créer relative à la "défendabilité")
StanBesson
Issue relative aux discussions de l'atelier "implémentation" du 10/05/2023
Support de présentation : https://github.com/cnigfr/Geostandards-Risques/blob/main/suivi/2023-05-10-Atelier-implementation/SPP-23-0736-GT-Risques-Implementation-10-05-2023.pdf
Ordre du jour :