Atelier implémentation du 10/05/2023

[gcebelieu]

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 :

• Evolutions du modèle GASPAR : Ajustements du modèle GASPAR #18 et Proposition de changement dans la nomenclature des risques inondations #28
• Formats d'échange
• Problématiques d'implémentations (géométries, encodage, systèmes de coordonnées, ...)
• Production des jeux tests

[gcebelieu]

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]

Quelques observations sur l'atelier du 10/05/2023, n'ayant pu y participer :

• format d'échange : OK pour le Géopackage, à privilégier au shape, c'est le format natif de QGIS depuis la version 3. A noter toutefois que peu d'outils "officiels" exploitent ce format (GPU, GeoIDE-Carto, etc.) pour le moment
• règles de géométries : pertinent de se baser sur les règles du GPU
• topologie : à mon sens, il faut éviter les lacunes et les superpositions. Les superpositions entrainent de grosses difficultés à lire un zonage et biaise les analyses SIG pouvant être réalisées (superposition de surface, etc...) Pour avoir le cas en Isère, il y toujours une probabilité d'oublier un zonage à un endroit précis.
• production de jeux tests : ok pour y participer.

[StanBesson]

Quelques remarques suite à mes essais de conversion de PPRN COVADIS en CNIG :

• la classe "référence internet" me laisse perplexe, hormis l'adresse URL vers les pièces écrites, je ne perçois pas l'utilité des autres attributs
• Il faudrait ajouter une des classes ou dans les métadonnées l'échelle (ou l'ordre de grande) d'utilisation des cartographies du PPR. Un zonage de PPR réalisé au 1/5000 ou au 1/10000 n'est pas pertinent au 1/1000 ou au 1/500, les limites d'utilisation doivent être mentionnées (c'est notamment un retour utilisateur de l'affichage des SUP PM1 dans le Géoportail de l'Grbanisme)

[gcebelieu]

Mes retours d'investigation sur le format Geopackage :

• Au CNIG (évoqué à l'occasion de la présentation du GT Risques en Commission des STandards) : il n'y a pas d'incitation particulière pour un format en particulier ni de contre indication. Le choix de Geopackage ne pose pas de problème en soi.
• Pour la Géoplateforme : c'est le format privilégié pour l'alimentation du Géotuileur qui préfigure le mode d'alimentation de la Géoplateforme en pour générer ses flux de diffusion.

[gcebelieu]

Merci pour le retour d'utilisation et essais de conversion @StanBesson

la classe "référence internet" me laisse perplexe, hormis l'adresse URL vers les pièces écrites, je ne perçois pas l'utilité des autres attributs

Les attributs supplémentaires permettent de qualifier le type de ressource concernée et d'identifier celle qui correspond à un besoin particulier. Dans tous les cas, aucun n'a été mis en obligatoire mais je pense qu'il peut être utile de pouvoir faire cette qualification.

Il faudrait ajouter une des classes ou dans les métadonnées l'échelle (ou l'ordre de grande) d'utilisation des cartographies du PPR. Un zonage de PPR réalisé au 1/5000 ou au 1/10000 n'est pas pertinent au 1/1000 ou au 1/500, les limites d'utilisation doivent être mentionnées (c'est notamment un retour utilisateur de l'affichage des SUP PM1 dans le Géoportail de l'Grbanisme)

Oui, pour moi cela est clairement un champ de métadonnées (normalement, c'est le champ relatif aux contraintes d'usages qui permet de le préciser : "Conditions applicables à l’accès et à l’utilisation")