gcebelieu
commented
9 months ago Quelques éléments de réponse, proposition de traitement, de discussion
- [x] p20 : je trouve qu'il manque un schéma simple plus global. Avant d'être dans les classes de données précises avec les noms des champs et leur liens avec les énumérations, avoir un schéma qui montre déjà les thématiques ou les principales classes feraient un peu office de carte de navigation pour la suite (j'imagine que c'est par manque de temps et que c'est bien prévu mais là l'entrée en matière est complexe parce qu'on n'a pas une vision d'ensemble à laquelle se référer)
=> Oui, aussi remonté par @StanBesson dans #60. Il faudra le rajouter, notamment si on lit directement le profil applicatif sans passer par le modèle commun.
- [ ] On ne parle pas de la subtilité de procedure revisante est-ce un choix ?
=> Si on en parle après dans la partie livraison. En fait je pense qu'il y a un manque de rappel des concepts du modèle commun dans le profil PPR où j'ai juste mis les éléments qui diffèrent. Je vais remettre l'ensemble des classes dans le document (dans le modèle UML)
- [ ] p21 : pour la classe aléa, on évoque pas l'idée d'avoir zonealeareference_type_alea ?
=> C'est abordé au niveau de la livraison (implémentation en classes). Je peux le mentionner ici comme une possibilité d'implémentation.
- [ ] p21/22 : si je comprend pour les enjeux, la nomenclature est laissé au choix et pour la reprise des données on peut reprendre l'énumération du standard covadis, ça m'irait très bien ce système on a le choix de la nomenclature ! Je vais essayer de fabriquer une table enjeu dans le nouveau standard à partir de l'ancien.
=> Oui c'est bien l'idée.
- [ ] Dans ces premières pages on ne voit pas le détail des zones protégés et des ouvrages de protection, est-ce un choix ?
=> Cf commentaire précédent sur les procédures révisantes. Elles ne sont pas évoquées ici car il n'y a pas de modifications vis à vis du modèle commun. Je modifierai le schéma pour reprendre toutes les classes du modèle commun.
- [x] p54 : sur les polygones, je rejoins Stanislas, 25m² ça va être très très problématique : et dans le vieux ppr des collègues vous risquez de trouver pleins de petites surfaces collés les unes aux autres et qui ont les mêmes attributs... en supprimant toutes les zones <25m² vous allez supprimer en fait des grandes zones de polygones qui étaient juxtaposés ! Parfois aussi ont peut avoir des bandes, type ruissellement, qui ne sont pas des carrés de 5x5 qui seraient de 1 mm mais plutôt de 25 x1 m² en linéaire et ça a du sens de les garder... Dans notre travail sur les zonages règlmentaires on a supprimé les polygones <0.5m² après notre méthode qui dilate et qui érode et qui fusionne de peur d'être trop destructif, c'est bien entendu trop précis mais il est difficile pour un géomaticien des faire ce genre de choix a posteriori...
=> Oui, pris en compte et à traiter dans #60
pour mémoire, on n'a pas encore traité les aléas qui ressemble souvent à ça :
=> OK, il faudrait développer un peu plus pour savoir comment les traiter. A discuter
- [x] p58 : cf pièce jointe sur les pprt, on était en 80,149,51, un peu foncé à mon goût, celle de stanislas sera mieux
=> OK, j'intègrerai la couleur de Stanislas. Est-ce qu'il y a d'autres couleurs dans ce document qui peuvent être réexploitées ?
- [ ] p68 : la table perimetre du PPRN-I du Bassin versant de la Scie aura pour nom : pprn-i_76ddtm20120001_perimetres, pourrait-on mettre un au lieu d'un - et bien mettre pprn_i_76ddtm20120001_perimetre_s
pareil pour le deuxième exemple ? Sinon il faudra modifier le nom générique [TypePPR][CodeGASPARComplet][nom table][code aléa si table d'alea][type de geometrie].gpkg
=> Pourquoi pas, à discuter en regard du commentaire de @StanBesson sur les noms des tables et des préfixes
- [ ] p71 : je ne comprend pas bien l'exigence "Exigence Les tables du standard présentes dans la livraison GeoPackage doivent être déclarées dans la table gpkg_contents avec le type de table indiqué dans le tableau précédent.", pour faire un .gpkg je fais juste sauvegarder sous .gpkg dans qgis ? ? ? Pour le boulot dans nos services j'espère que sauvegarder un gpkg dans qgis gère ces subtilités...
=> Oui, il s'agit d'une exigence de conformité à GeoPackage. Normalement QGis fera correctement le boulot.
- [ ] p72 : là on parle de typeppr_codegaspart_revise mais ce point n'est pas détaillé dans les premières parties et je trouve que c'est dur à comprendre (Stanislas, je me souviens bien qu'on en ait parlé en GT car j'avais posé la question, je n'avais compris le concept).
- [ ] p77: pareil pour zone protégée (et zone danger specifique p79), c'est compliqué à comprendre car il n'y a pas de définition. Comme c'est des nouveautés par rapport au COVADIS ça mériterait d'être expliqué...
=> Oui, ça rejoint ma réponse à ta première remarque sur procédure révisante. Il faut que je rajoute les éléments du modèle commun dans le schéma UML pour que le profil PPR soit plus autoportant.
p92 : très bien d'avoir le code sql pour les tables d'énumération !
- [/] Enfin, je me pose la question de scinder ce document en plusieurs documents ou annexes dans sa forme finale
-> en séparant toute la partie fin de la page 71 à 102 pour faire un document technique de "gabarit" -> en séparant la correspondance avec covadis p 120 à 133 pour un autre document -> en séparant la correspondance avec CNIG SUP -> et pourquoi pas aussi l'alléger des énumérations des enjeux qui sont très volumineuses et en faire une autre annexe Le document ferait un peu moins peur (il faudrait retomber hors annexe sur une cinquantaine de page maxi !), les définitions importantes seraient moins diluées, et on aurait des pdf qu'on ouvrirait en parallèle au besoin lorsque l'on travaille.
=> Oui, je suis d'accord, cf. ma proposition sur la première remarque de @StanBesson dans #60 : il y a moyen de passer les éléments SQL, et des tables d'énumération en annexes pour que ce soit plus lisible.
- [ ] Je partage l'inquiétude de Stanislas sur l'appropriation, il faudrait un document d'une autre forme pour les ddtm ! Perso le site http://geostandards.developpement-durable.gouv.fr/accueil.do m'a bien plus aidé que le manuel covadis...
=> A voir le matériel d'accompagnement à produire à côté.
- [/] Je suis aussi ok pour inscrire dans ce document les priorités pour les tables procédures, périmètres et zonages règlementaires puis aléas puis les autres.
=> OK, vu aussi dans les remarques de @StanBesson
Commentaires de @GuillaumeChretien sur la v0.1 du profil applicatif PPR
[ ] p20 : je trouve qu'il manque un schéma simple plus global. Avant d'être dans les classes de données précises avec les noms des champs et leur liens avec les énumérations, avoir un schéma qui montre déjà les thématiques ou les principales classes feraient un peu office de carte de navigation pour la suite (j'imagine que c'est par manque de temps et que c'est bien prévu mais là l'entrée en matière est complexe parce qu'on n'a pas une vision d'ensemble à laquelle se référer)
[ ] On ne parle pas de la subtilité de procedure revisante est-ce un choix ?
[ ] p21 : pour la classe aléa, on évoque pas l'idée d'avoir zonealeareference_type_alea ?
[ ] p21/22 : si je comprend pour les enjeux, la nomenclature est laissé au choix et pour la reprise des données on peut reprendre l'énumération du standard covadis, ça m'irait très bien ce système on a le choix de la nomenclature ! Je vais essayer de fabriquer une table enjeu dans le nouveau standard à partir de l'ancien.
[ ] Dans ces premières pages on ne voit pas le détail des zones protégés et des ouvrages de protection, est-ce un choix ?
[ ] p54 : sur les polygones, je rejoins Stanislas, 25m² ça va être très très problématique : et dans le vieux ppr des collègues vous risquez de trouver pleins de petites surfaces collés les unes aux autres et qui ont les mêmes attributs... en supprimant toutes les zones <25m² vous allez supprimer en fait des grandes zones de polygones qui étaient juxtaposés ! Parfois aussi ont peut avoir des bandes, type ruissellement, qui ne sont pas des carrés de 5x5 qui seraient de 1 mm mais plutôt de 25 x1 m² en linéaire et ça a du sens de les garder... Dans notre travail sur les zonages règlmentaires on a supprimé les polygones <0.5m² après notre méthode qui dilate et qui érode et qui fusionne de peur d'être trop destructif, c'est bien entendu trop précis mais il est difficile pour un géomaticien des faire ce genre de choix a posteriori...
pour mémoire, on n'a pas encore traité les aléas qui ressemble souvent à ça :
toujours p54, Très bien le paragraphe sur la cohérence topologique, il me manquait cette indication dans mes précédents travaux...
Globalement, je trouve cette partie sur la qualité est une plus value de cette doc par rapport à covadis.
Symbologie PPRT.pdf
pareil pour le deuxième exemple ? Sinon il faudra modifier le nom générique [TypePPR][CodeGASPARComplet][nom table][code aléa si table d'alea][type de geometrie].gpkg
[ ] p71 : je ne comprend pas bien l'exigence "Exigence Les tables du standard présentes dans la livraison GeoPackage doivent être déclarées dans la table gpkg_contents avec le type de table indiqué dans le tableau précédent.", pour faire un .gpkg je fais juste sauvegarder sous .gpkg dans qgis ? ? ? Pour le boulot dans nos services j'espère que sauvegarder un gpkg dans qgis gère ces subtilités...
[ ] p72 : là on parle de typeppr_codegaspart_revise mais ce point n'est pas détaillé dans les premières parties et je trouve que c'est dur à comprendre (Stanislas, je me souviens bien qu'on en ait parlé en GT car j'avais posé la question, je n'avais compris le concept).
[ ] p77: pareil pour zone protégée (et zone danger specifique p79), c'est compliqué à comprendre car il n'y a pas de définition. Comme c'est des nouveautés par rapport au COVADIS ça mériterait d'être expliqué...
p92 : très bien d'avoir le code sql pour les tables d'énumération !
-> en séparant toute la partie fin de la page 71 à 102 pour faire un document technique de "gabarit" -> en séparant la correspondance avec covadis p 120 à 133 pour un autre document -> en séparant la correspondance avec CNIG SUP -> et pourquoi pas aussi l'alléger des énumérations des enjeux qui sont très volumineuses et en faire une autre annexe
Le document ferait un peu moins peur (il faudrait retomber hors annexe sur une cinquantaine de page maxi !), les définitions importantes seraient moins diluées, et on aurait des pdf qu'on ouvrirait en parallèle au besoin lorsque l'on travaille.
[ ] Je partage l'inquiétude de Stanislas sur l'appropriation, il faudrait un document d'une autre forme pour les ddtm ! Perso le site http://geostandards.developpement-durable.gouv.fr/accueil.do m'a bien plus aidé que le manuel covadis...
[ ] Je suis aussi ok pour inscrire dans ce document les priorités pour les tables procédures, périmètres et zonages règlementaires puis aléas puis les autres.