gcebelieu
commented
10 months ago Des éléments de réponse et propositions de résolution ou discussion
- [x] dans le profil applicatif PPR pour nom Enjeu, dans exemple de valeur tu as laissé character string et dans classe ancien PPR tu as mis un exemple de valeur ?
=> Désolé c'est une erreur, il y a un décalage de colonne vers la droite. il faut enlever CharacterString. L'exemple de valeur est "Zone d'habitat peu dense", la classe Ancien PPRN est EnjeuPPR et l'attribut ancien PPRN (qu'on ne voit pas) est DESCRIPT. Ce sera corrigé dans le github.
- [x] Et dans le framacalc : dans description de l'objet à l'origine du risque au lieu de nom de l'objet d'enjeu
=> Là aussi, encore désolé, c'est une erreur. Je l'ai corrigée.
- [ ] A première vue j'avais l'impression que je pourrais transposer mes anciennes tables directement mais si je comprend la logique il faut les éclater en deux ou trois :
-> une table enjeu avec un identifiant, la géométrie et le nom de l'enjeu (par exemple : un point avec mairie d'Etretat) et deux colonnes mystérieuse de la page 130 : type_enjeu et vulnérabilité qui ne sont pas reprise dans le gabarit ?
=> Oui c'est ça, type_enjeu et vulnerabilite ne sont pas repris dans le gabarit car ce sont les tables Type_enjeu et Type_vulnerabilité qui font le lien vers la table enjeu pour permettre d'attribuer plusieurs types d'enjeu ou plusieurs vulnérabilités à un objet enjeu.
-> une table type_enjeu sans géométrie dans lequel je dois reprendre l'identifiant de l'enjeu, du coup repris dans 3 colonnes dans le gabarit (p,l,s) dans laquelle j'ajoute juste le codeenjeu en précisant la nomenclature_enjeu retenue qui devrait faire référence à une énumération (je ne l'ai pas vu).
=> En effet, je n'ai pas mis de table d'énumération des enjeux dans le gabarit car je n'étais pas encore certain de l'acceptation des nomenclatures proposées. Je mettrai en priorité celle de l'ancienne nomenclature COVADIS pour permettre les tests de conversion des anciens PPR.
-> une table type_vulnérabilite sans géométrie qui n'est pas décrite dans la partie sur le remplissage d'objet (je l'attendrais autour de la page130) mais qui semble avoir la même logique que type enjeu
=> Je ne l'ai pas mise dans la page 130 car cette partie est dédiée à la conversion des anciens PPR vers les nouveaux et cette notion de vulnérabilité n'existe pas dans le standard COVADIS. Donc dans le cadre de la conversion on ne crée aucun élément dans la table vulnérabilité.
Pour une table non prioritaire, difficile à homogéniser dans l'absolu, ça me semble tellement compliqué et lourd en stockage (on multiplie par trois le nombre d'individu !)... Et comment faire une analyse thématique par catégorie d'enjeu sans faire de jointure, la géométrie et la classification se retrouve dans deux tables différentes ?
Je ne comprend pas la logique donc j'ai du rater une étape ou un concept car je m'attendais à avoir une seule table enjeu quitte à avoir une table d'énumération à fabriquer soi même qui reprenne la nomenclature retenue avec les libellés précis des codes et la précision de la nomenclature retenue (covadis, pprn, pprt etc...) qui elle même peut être une énumération...
Si il faut faire des requêtes de jointure pour représenter visuellement la donnée des enjeux on perd tous les utilisateurs...
- [ ] Une autre solution serait de simplement fusionner ces trois classes et d'avoir une table enjeu par type de géométrie du type :
codeprocedure idenjeu nomenjeu codeenjeu (de la nomenclature ci-après) nomeclatureenjeu (et toutes les lignes auraient la même valeur) vulnerabilite (mais je n'ai pas saisi ce qu'on met derrière pour les PPR) dateenjeu et à la fin parce que c'est pas le plus important idrefexterne refexterne
=> La proposition de tables séparées vient du fait de pouvoir affecter plusieurs classifications à un même objet enjeu. Idem pour la vulnérabilité. Je comprends que cela complexifie la gestion. S'il y a une solution pour permettre cela avec une seule table, prenons là. Ou sinon il faut s'interroger sur le besoin de permettre plusieurs classifications d'enjeu pour un même objet.
Du coup, en l'état, je ne vais pas fabriquer cette donnée dans mon jeu test et je ne me verrai pas élaborer un nouveau ppr avec cette logique.
=> C'est dommage. A discuter pour trouver une solution plus simple et acceptable.
Là on retombe dans les mêmes écueils qu'à l'époque de la COVADIS : entre les description successives des classes, des objets puis des exemples de gabarits qui m'embrouillent, le fait que les attributs se limitent aux codes (sans leur signification intelligible) et les subtilités de conception liés à des réflexions ou des contraintes non métier PPR, il est très difficile de comprendre ce qui est attendue alors qu'en fait la table des enjeux est la plus simple du lot !
=> Je ne comprends pas la remarque sur les attributs se limitant aux codes sans signification intelligible.
Commentaires de @GuillaumeChretien sur la v0.1 du profil applicatif PPR plus spécifiquement sur la partie Enjeux
[ ] Et dans le framacalc : dans description de l'objet à l'origine du risque au lieu de nom de l'objet d'enjeu
[ ] A première vue j'avais l'impression que je pourrais transposer mes anciennes tables directement mais si je comprend la logique il faut les éclater en deux ou trois :
-> une table enjeu avec un identifiant, la géométrie et le nom de l'enjeu (par exemple : un point avec mairie d'Etretat) et deux colonnes mystérieuse de la page 130 : type_enjeu et vulnérabilité qui ne sont pas reprise dans le gabarit ?
-> une table type_enjeu sans géométrie dans lequel je dois reprendre l'identifiant de l'enjeu, du coup repris dans 3 colonnes dans le gabarit (p,l,s) dans laquelle j'ajoute juste le codeenjeu en précisant la nomenclature_enjeu retenue qui devrait faire référence à une énumération (je ne l'ai pas vu).
-> une table type_vulnérabilite sans géométrie qui n'est pas décrite dans la partie sur le remplissage d'objet (je l'attendrais autour de la page130) mais qui semble avoir la même logique que type enjeu
Pour une table non prioritaire, difficile à homogéniser dans l'absolu, ça me semble tellement compliqué et lourd en stockage (on multiplie par trois le nombre d'individu !)... Et comment faire une analyse thématique par catégorie d'enjeu sans faire de jointure, la géométrie et la classification se retrouve dans deux tables différentes ?
Je ne comprend pas la logique donc j'ai du rater une étape ou un concept car je m'attendais à avoir une seule table enjeu quitte à avoir une table d'énumération à fabriquer soi même qui reprenne la nomenclature retenue avec les libellés précis des codes et la précision de la nomenclature retenue (covadis, pprn, pprt etc...) qui elle même peut être une énumération...
Si il faut faire des requêtes de jointure pour représenter visuellement la donnée des enjeux on perd tous les utilisateurs...
codeprocedure idenjeu nomenjeu codeenjeu (de la nomenclature ci-après) nomeclatureenjeu (et toutes les lignes auraient la même valeur) vulnerabilite (mais je n'ai pas saisi ce qu'on met derrière pour les PPR) dateenjeu et à la fin parce que c'est pas le plus important idrefexterne refexterne
Du coup, en l'état, je ne vais pas fabriquer cette donnée dans mon jeu test et je ne me verrai pas élaborer un nouveau ppr avec cette logique.
Là on retombe dans les mêmes écueils qu'à l'époque de la COVADIS : entre les description successives des classes, des objets puis des exemples de gabarits qui m'embrouillent, le fait que les attributs se limitent aux codes (sans leur signification intelligible) et les subtilités de conception liés à des réflexions ou des contraintes non métier PPR, il est très difficile de comprendre ce qui est attendue alors qu'en fait la table des enjeux est la plus simple du lot !