Feat/fiche esp/add stat count city and observers to vm profile

[andriacap]

Bonjour,

Dans le cadre d'une prestation pour l'ARB-IDF concernant l'amélioration de la fiche espèce (voir exemple de la fiche espèce actuelle: https://demo.geonature.fr/geonature/#/synthese/taxon/447950).

Actuellement les informatinos récupérées via la vue matérialisée vm_valid_profiles sont : nombre d'observation valides, première et dernière observations et plages d'altitude.

Les développements proposés sur la base des besoins métiers ( ajout des informations statistiques concernant le nombre de communes et d'observateurs liés à l'espèce observée) sont fait sur cette PR .

Voici le rendu des développements proposés:

[camillemonchicourt]

Il y a eu un début de discussion sur le sujet dans un ticket dédié et un élément identifié était de discuter les infos des fiches espèces de la notion de profils.
Les profils sont un concept bien particulier lié à la validation des données.
Donc au niveau BDD et API on avait parlé que ce soit plutôt une API /synthese, voire même plutôt /species ou /observations

[andriacap]

Bonjour Camille,

Tu fais référence aux interrogations que tu as soulevées dans ton commentaire à ce ticket : #2981 (comment)

Je m'interroge si on peut supprimer les infos des profils de chaque espèce dans les fiches espèces, car les utilisateurs ne passeront pas forcément par la fiche d'une observation et son onglet VALIDATION avant d'arriver à la fiche d'une espèce.
A moins que l'essentiel des infos du profil ne soient repris par ailleurs dans la fiche espèce que vous prévoyez. Sinon, il vaudrait mieux garder un onglet PROFIL dans le fiche de chaque espèce.

Actuellement, on accède à une fiche espèce via le bouton "Fiche GeoNature", de la fiche Observation.
L'onglet validation ne joue aucun rôle dans l'accès à la fiche espèce.
La fiche espèce actuelle contient un certain nombre d'indicateurs, qui sont tous calculés sur la même source de donnée (la vm: vm_valid_profile)

Etant donné ceci, nous avons choisit la solution la moins invasive.

Cependant, de ta réponse, je comprends que les indicateurs actuels sont calculés sur une mauvaise source de données.
La correction de cette source des données nous paraissait dépasser le périmètre de l'ajout de ces deux nouveaux indicateurs. Cette correction n’apparaît d'ailleurs ni dans le ticket, ni dans tes remarques.

Cette correction serait:

• une route dédiée à la place du fonctionnement actuel basé sur une vm
• les indicateurs seraient calculés sur l'ensemble des observations, et pas seulement sur les observations valides.
• les indicateurs de la vue actuelle seraient basculés dans l'onglet "validation"
• la vm_valid_profile ne serait plus utilisée que par la route check_observation

Est-ce que tu affirmes la décision du changement de source de données du calcul de ces indicateurs ?

Nous avons eu le sentiment d'avoir de votre part deux registres de consignes un peu distinctes. D'un côté la volonté de changement d'approche d'une partie de la synthèse, d'une stratégie par VM vers une stratégie par API. De l'autre, la nécessité de se conformer à l'existant. Dans ce contexte, nous avons besoin que vous balisiez les questions structurelles de ce genre.

Est-ce que vous avez aujourd’hui une vision des modifications structurelles que vont amener les différents développements autour de la fiche espèce ?

Auquel cas, il nous semble très pertinent d'en discuter ensemble autour d'un schéma ou d'une webcam.

De plus, cela nous donne l'impression qu'il y a encore des points à faire valider, et des mauvaises surprise à éviter. Est-ce que vous seriez disponible que nous vous montrions le plan des développements à venir, et qu'on définisse ensemble un fonctionnement clair pour la mise en place de ces développements ?

[camillemonchicourt]

Oui je fais bien référence à ce ticket.
Celui-ci posait les questions globales à étudier, discuter.
Car c'est un sujet assez large.
Et nous attendions une analyse et proposition technique globale de votre part.

Il y a confusion entre les profils de taxons existants et la création souhaitée de fiches espèces avec des infos générales sur celles-ci.

Il n'y a pas à modifier ou corriger les profils de taxons.
Ils ont une logique et fonctionnement bien clair et défini (voire la doc sur les profils de taxons et le ticket sur leur mise en place si besoin) pour comparer les nouvelles données aux données existantes validées.
Il n'y a pas de changement ou de correction à faire.

Ce qui était discuté est de garder de la visibilité aux profils de taxons sur ces futures fiches espèces. Donc les garder dans un onglet dédié dans ces futures fiches espèces.

Par ailleurs il y a tout à construire pour ces fiches espèces qui sont distincts et différentes des profils.
Les données des fiches espèces doivent bien sûr s'appuyer sur toutes les données dans la Synthèse, éventuellement en appliquant les permissions de l'utilisateur et le foutage (à préciser comme indiqué dans les sujets soulevés dans le ticket).

Il n'y a pas non plus de stratégie VM vs stratégie API, ce sont 2 choses distinctes. Il faudra forcément une API pour les fiches espèces (à construire le plus REST possible pour ouvrir d'autres usages). Que cette API tape sur des VM ou fasse des requêtes directement et dynamiquement sur la BDD est un autre sujet, plutôt au sujet des performances et temps de calcul, aussi mentionné comme un sujet à analyser dans le ticket mentionné.

[andriacap]

Plutot ok avec certains points.
Par contre il y a quelques points qui ne sont pas clair et qui reste encore flou étant donné que je vois beaucoup de "à discuter" . Cela implique que l'on trouve un moyen d'avoir une étape de "relecture" de votre part sur le projet https://github.com/orgs/PnX-SI/projects/20 . Etant donné que vous semblez avoir à la fois des stratégies de développements précises et certaines à discuter , il faut qu"on trouve un moyen pour que ce soit clair pour les contributeurs de la communauté de GN de proposer des développements qui soit en adéquation avec une éventuelle roadmap / stratégie de dev souhaité ( Mise en place d'API, réutilisation de code de certains modules car considéré comme étant du code déjà "propre" et "refact" , liste de parties de code à ne reprendre car à terme elle seront modifiées etc ).

Pour reprendre l'exemple de ce développement proposé, la stratégie de rajouter deux indicateurs sur un fonctionnement existant c'est une stratégie qui a été également mentionnée dans les réunions . A savoir faire "simple" , "sans redondance" etc . Donc le choix de modifier la VM qui est déjà existante était pertinent sur ces deux principes mentionnés en réunion.

Autre point , tu dis "Que cette API tape sur des VM ou fasse des requêtes directement et dynamiquement sur la BDD est un autre sujet" . C'est quand même intimement lié . Si on se base sur une VM, ça implique de créer "N" revisions alembic à chaque fois qu'on se dit qu'on souhaite ajouter une information à la vue matérialisée . Donc si à terme c'est d'avoir moins de vue matérialisée (comme ça a été mentionné dans d'autres issues) le sujet se pose maintenant .

Bref, tout ça pour dire que c'est pas assez clair de notre coté sur les stratégies de développements envisagés de manière globale sur GN .

Donc à voir pour organiser une réunion tous ensemble pour qu'on puisse être plus pertinents dans nos propositions de développements afin que cela bénéficie à tout le monde : les mainteneurs, les contributeurs et les utilisateurs .