cnigfr / Geostandards-Risques

4 stars 5 forks source link

Commentaires sur la v0.1 de la DDT 38 reçus le 29/09 #61

Open gcebelieu opened 10 months ago

gcebelieu commented 10 months ago

Commentaires de @StanBesson sur la v0.1 après essais de traduction de PPRT, PPRM et PPRN (cf. résultats ici : https://github.com/cnigfr/Geostandards-Risques/tree/main/ressources/traduction/PPR-DDT38 ). A rajouter aux premiers commentaires de #60

Remarques liminaires :

Les observations suivantes sont émises à l’issue de la conversion de deux PPR geostandardisés selon le modèle COVADIS en vigueur depuis 2012 : PPRN Drac aval approuvé le 17 juillet 2023 (38DDT20190003), ce PPRN a été sélectionné car il dispose de données enjeux et aléas. PPRT Sobégal approuvé le 08 février 2017 (69DREAL20090005), ce PPRT a été sélectionné car il dispose de mesures foncières. Toutes les classes n’ont pas pu être testées, en fonction des données disponibles.

Généralités sur le géostandard

Présentation

Primitive géographique :

Nomenclature

PPR[N|M|T]_[CodeGASPARComplet].gpkg

Complexité des géométries

Le seuil de surface minimale de 25 m² semble trop macro, il faut pouvoir réduire la surface minimale (5 m²?)

Sémiologie

Structures de données :

classe référenceinternet

De plus les attributs proposés ne sont pas pertinents, l’attribut typereference ne correspond pas à la réalité, le choix retenus par défaut est ‘autre’. 2 attributs sont suffisants : nomressource (ou url) et description

classe alea reference

La réalisation d‘une couche par phénomène est pertinente. Conversion facile

classe enjeu :

Je n’ai pas pu utiliser la classe typeenjeux.

classe zonereglementaireurba :

Comme pour la classe aléa, facile à prendre en main.

Classe zonereglementairefoncier :

C’est une réelle plus-value de distinguer les mesures foncières des mesures d’urbanisme.

gcebelieu commented 10 months ago

Premiers éléments de réponse ou propositions de traitement / discussiosn

  • [x] Pour la bonne appropriation du géostandard, mettre en évidence les classes et attributs obligatoires pour la validité d’un PPR standardisé.

=> OK, noté dans le cadre #60

  • [ ] Pour la classe perimetre, le type multipolygone est pertinent et correspond à la réalité, en revanche pour les autres classes géographiques (aléas, zonereglementaireurba, zonereglementairefoncier), il est préférable de retenir le polygone, cela simplifie les géométries et réduit les sources d’erreur de géométrie.

=> Cela avait été mentionné en atelier. J'avais retenu cela comme une bonne pratique à conseiller, mais pas forcément à limiter strictement au niveau du type de données car peut-être trop restrictif dans certains cas. A rediscuter donc.

Nomenclature

  • [ ] L’utilisation du ‘-’ pour définir le type de PPR complexifie la dénomination du dossier, plutôt rester sur les trois grandes familles de PPR (PPRN, PPRT et PPRM) :

PPR[N|M|T]_[CodeGASPARComplet].gpkg

=> Est-ce que le problème repose sur la présence du "-" ou le fait d'avoir plus de types de PPR ? La proposition reprenait les codes tels que sortis de GASPAR pour éviter des règles de reformatage. OK, si c'est plus simple et plus juste juste N,M et T => à discuter.

  • [ ] De même, les noms des attributs et des classes sont très longs, il faudra essayer de les raccourcir pour faciliter l’appropriation du géostandard.

=> Pourquoi pas, à discuter. NB : Pour les noms de table, une partie de la longueur réside dans la présence du préfixe [TypePPR]_[codeGASPAR]

Complexité des géométries

  • [x] Les seuils de complexité proposés ne semble pas être en adéquation avec la réalité des PPR, ainsi certains peuvent être utilisés au 1/2500.

Le seuil de surface minimale de 25 m² semble trop macro, il faut pouvoir réduire la surface minimale (5 m²?)

=> Noté comme à traiter dans l'issue #60

Sémiologie

  • [ x] Ajouter la couleur verte pour les recommandations (178,223,138)

=> Noté comme à traiter dans l'issue #60

classe référenceinternet

  • [ ] Je m’interroge toujours sur l’opportunité d’une classe autonome ? Pourquoi ne pas la rattacher à la classe procédure ?

De plus les attributs proposés ne sont pas pertinents, l’attribut typereference ne correspond pas à la réalité, le choix retenus par défaut est ‘autre’. 2 attributs sont suffisants : nomressource (ou url) et description

=> La motivation de la création de cette classe était de pouvoir rattacher plusieurs références documentaires de différents types (règlement, cartes, ...) à un PPR. Dans le cadre de la reprise des anciens PPR ce n'est pas utile car il n'y avait qu'une référence. A voir si c'est utile pour les nouveaux, et éventuellement revoir la classification si elle n'est pas pertinente.

classe enjeu :

  • [ ] Absence de lien avec les types d’enjeux présents dans les guides d’élaboration des PPR (centre historique, zone urbaine, etc.)
  • [ ] Il semble manquer une relation avec la classe typeenjeux Je n’ai pas pu utiliser la classe typeenjeux.

=> Cela doit être mal présenté car normalement les classifications d'enjeux proposées sont issues de ces guides. Type enjeux est plutôt un type de données complexe (à appliquer à l'attribut typeEnjeu de la classe Enjeu) qu'une classe, c'est pour cela qu'il n'y a pas de relation représentée dans le modèle. La proposition faite a de toute façon était mal perçue. Il faut qu'on en rediscute. L'objectif est de pouvoir qualifier un objet enjeu par potentiellement plusieurs catégories d'enjeu (en fonction des nomenclatures disponibles et des usages avals).

classe zonereglementaireurba :

  • [ ] Il faudrait modifier l’attribut obligationtravaux pour pouvoir préciser s’il y a des recommandations, d’autant plus que la classification type_obligation_travaux existe

=> Pourquoi pas : où peut on trouver cette classification ?

  • [ ] Valeurs de typereglement : ajouter une classification pour les zones grisées facilitera leur intégration.

=> Il me semble que c'est ce qui est proposé. Faut-il aller plus loin ?

image
gcebelieu commented 6 months ago

Statut des traitements par la v0.2

  • [x] Pour la classe perimetre, le type multipolygone est pertinent et correspond à la réalité, en revanche pour les autres classes géographiques (aléas, zonereglementaireurba, zonereglementairefoncier), il est préférable de retenir le polygone, cela simplifie les géométries et réduit les sources d’erreur de géométrie.

Appliqué (Multipolygone pour périmètre et Polygone pour zonage reglementaires (et aussi zones d'aléas)

  • [x] L’utilisation du ‘-’ pour définir le type de PPR complexifie la dénomination du dossier, plutôt rester sur les trois grandes familles de PPR (PPRN, PPRT et PPRM) :

PPR[N|M|T]_[CodeGASPARComplet].gpkg

Appliqué

  • [ ] De même, les noms des attributs et des classes sont très longs, il faudra essayer de les raccourcir pour faciliter l’appropriation du géostandard.

=> Pourquoi pas, à discuter. NB : Pour les noms de table, une partie de la longueur réside dans la présence du préfixe [TypePPR]_[codeGASPAR]

Non traité dans la v0.2

  • [x] Je m’interroge toujours sur l’opportunité d’une classe autonome ? Pourquoi ne pas la rattacher à la classe procédure ?

Vu en discussions plénières ou ateliers : conservation de cette classe.

classe enjeu :

  • [x] Absence de lien avec les types d’enjeux présents dans les guides d’élaboration des PPR (centre historique, zone urbaine, etc.)

Ils y figurent : espaces urbanisés (centres urbains et hors centre urbains) et non urbanisés.

  • [x] Il semble manquer une relation avec la classe typeenjeux

Vu en atelier (et intégré) : il n'y a plus de table typeenjeux, ses propriétés ont été intégrées à la table enjeu

  • [x] Il faudrait modifier l’attribut obligationtravaux pour pouvoir préciser s’il y a des recommandations, d’autant plus que la classification type_obligation_travaux existe

On est resté sur obligationtravaux (oui|non) et recommandations comme type de reglementurba

  • [x] Valeurs de typereglement : ajouter une classification pour les zones grisées facilitera leur intégration.

=> Il me semble que c'est ce qui est proposé. Faut-il aller plus loin ?

image