En lien avec #17

Mettre à jour l'année (2012).
2012-2015 ?

modifier la base de données pour obtenir une base faune flore.
renommer dans l'application les labels relatifs uniquement à la faune.

A destination des partenaires
existant actuellement 3 modules : SINP, LPO, BDD flore 05

Faire aussi une petite vidéo ou un pdf avec des captures d'écran de l'appli

Soit ajouter un bouton radio FAUNE / FLORE / FONGE / TOUS, soit utiliser l'arbre existant "CHOISIR PLUSIEURS TAXONS".

Ce critère se basera sur la champ REGNE de la table "taxref".

Suite à la suppression des champs spécifiques du PNE dans bib_taxons (reproducteur, statut_migration, frequence, importance...) et les 3 bibliothèques associées (ccbdc12), ces infos n'apparaissent plus dans la fiche taxon dans l'appli SYNTHESE.

Pour permettre à chaque structure d'avoir des infos spécifiques sur les taxons, chacun pourra ajouter des champs dans la table bib_taxons (+ éventuellement les bib associées).
L'application affichera le contenu d'une vue v_infos_taxon que chacun pourra se construire à sa guise à partir de ses champs spécifiques relatifs au taxon.

pb identifié : function ndims to st_ndims
srid to st_srid
...autres à creuser

Du coup utiliser la bib_taxons_pn uniquement si besoin de son contenu spécifique.

Nombreuses actions à conduire progressivement:

• interface
• nom des variables, champs ...

travail sur la taxonomie de geonature

modèle de données pour réflexion

J'ai commencé à traduire ça dans le code. Pas simple mais ça fonctionne. Maintenant pour le traduire de manière générique entre la base, l'interface client et le backend de géonature : ça va être du sport.
Pas simple de passer en paramètres + en interface, des champs d'attributs qui ne préexistent pas en base. Pour le moment, j'ai mis des valeurs en dur : comme patrimonial (oui ou non), protection_stricte (oui ou non) mais si on veut faire du générique, sans connaître les valeurs de l'attribut, ça va être complexe.
Je n'ai pas encore commité mes modifs dans geonature.

La table centrale bib_taxons :

La table bib_attributs avec ici la notion de patrimonial et de protection stricte. On a ici une liste de valeurs correspondant à un boolean mais on peut mettre par exemple, pour répondre à Amandine, un attribut avec l'id 3 pour "liste rouge" et lister les 4,5 ou 6 valeurs dans "liste_valeur_attribut"

Dans cor_taxon_attribut On affecte pour chaque taxon concerné la valeur de l'attribut. Si liste rouge on pourrait avoir par exemple pour le lynx : 64;3;vulnérable
C'est le remplissage de cette table qu'il faut faire via une interface car difficile de se fader ça à la main.

Pour la partie liste : bib_listes, le but est de construire des menus déroulant, notamment pour définir les taxons dont la saisie est autorisée. Mais on peut envisager un autre usage. Il s'agit simplement de dire dans la liste A, il y a tel et tel taxon, dans la liste B, tel et tel autre

Dans cor_taxon_liste on dit liste par liste quel taxon est dans la liste :

Pour les groupes, dans bib_groupes, la discussion est ouverte. Le modèle proposé permet de mettre un taxon dans plusieurs groupe. Par exemple, le grand murin dans le groupe des mammifères et dans un groupe des murins. On peut aussi faire un groupe des plantes vasculaires et un groupe des orchidées. Maintenant, il faut voir l'usage de ces groupes en saisie ou dans l'interface que l'on doit créer. L'avantage des groupes est que l'on peut ajouter un groupe entier dans une liste, ce qui accélère la saisie. Mais cette possibilité n'est pas présente dans le modèle.

cor_taxon_groupe

J'ajoute qu'il ne va pas être simple d'implémenter ça en interface car on ne connait pas le contenu des tables à l'avance.

Autant il est simple de filtrer une liste de taxon sur la base de critères type "mammifères, poissons, oiseaux" connu à l'avance, autant prévoir d'activer ou non ce critère, ou un autre type liste rouge (permettre de n'afficher que les taxons vulnérables par exemple) s'il n'est pas connu à l'avance, demande une grosse modification de l'interface extjs de GeoNature mais aussi de la logique des requêtes correspondantes en backend.

La difficulté est de prévoir le fonctionnement des filtres sans les connaitre au moment des dev.
Pour le moment, j'ai traduit ce modèle dans GeoNature et j'ai conservé le fonctionnement existant avec patrimonial et protection_stricte. Mais si on retire l'enregistrement de ces filtres en base où qu'on change leur nom, tout pète... A affiner donc.

Une V2

Ici on créér les champs de filtres en dur dans la tables taxons 5 booléens et 5 strings et on les décrits dans une table isolée qui servira au fonctionnement du front-end et du back-end.

J'ai aussi ajouter un lien entre les groupes et les listes. On peut ainsi ajouter un groupe à une liste et pour retrouver les tous les taxons, qu'ils soient issus de groupes ou pas, on doit pouvoir faire ça avec une requête UNION.

Analyse rapide et qq propositions

pour la traduction possible de ces modèles dans les dev, une liste des points à adapter ou supprimer dans le cadre de la mise en place de filtres non prédéfinis.

Partie liste des observations

• Présence ou non du filtre dans le store de la grid des résultats : lors de la construction du store on donne la liste des champs de ce store. Ce store est ensuite alimenté (rempli) par le backend. Ce store gère le contenu du tableau de résultats (grid dans extjs). Il faut passer dynamiquement ce nom de champ au store est à la grid. Il faut aussi que la requête en backend soit construite avec le champ correspondant : même nom et même type.
• Gestion éventuelle d'un icone dans le tableau de résultat (grid) dans une colonne action (exemple une colonne "patrimoniale" avec un icône logo_pne) :
  = présence de l'image png ou jpg dans le répertoire images de l'application avec le nom de l'attribut (par exemple "patrimonial.jpg")
  o = aussi présence ou non de cette colonne action dans le grid.
  o Lien stricte entre le front et le backend-end car le comportement de l'interface, affichage ou non de l'icone patrimonial, dépendra de la valeur du champ "patrimonial" dans le store et donc de la valeur renvoyée par le backend pour ce champ "patrimonial")
• Présence ou non de la valeur de l'attribut dans le bandeau présentant des informations relatives au taxon choisi dans la grid (tableau de résultats). Il y a là une phrase en dur dans le code qui dit ce qu'il en est de ce taxon pour l'attribut : ex : "Ce taxon n'est pas patrimonial pour le PNE"

Partie construction d'une requête (rechercher)

• Filtrage du menu déroulant des taxons affichés : le frontend écoute les actions de l'utilisateur sur l'interface. Par exemple si on coche la case "taxon patrimonial" :
  o le menu déroulant (combobox) des taxons est filtrée pour n'afficher que les taxons patrimoniaux = filtrage du store du combobox sur le champ "patrimonial". Il faut donc (ou non)
  § créer ce champ "patrimonial" au moment de la construction du store
  § créer ce champ "patrimonial" au moment de la construction du combobox
  § créer un champ "hidden", dans le formulaire de requêtage général de recherche des observations. ex :
  { xtype:'hidden',id:'hidden-patri',name:'patrimonial',value:''}
  voir point suivant concernant la recherche des observations
  § créér la case à cocher "patrimoniale" (possibilité de créer une liste déroulante avec oui, non ou autre valeur).
  § créer le listener (écouteur) qui va déclencher les actions sur modification de la case à cocher ou de la liste pour
• filtrer le store et donc la liste taxons
• transmettre la valeur modifiée au champ "hidden-patri" du formulaire
  § Enfin qu'une action symfony alimente ce store des taxons en backend et qu'elle comporte un champ "patrimonial" avec comme valeur true;false ou oui;non.
  = Grosse réflexion à conduire ici pour faire qq chose de générique.
• Filtrage de la liste des observations correspondant aux critères de la requête :
  o le frontend-end transmet au backend une liste de critères avec leur valeur : par exemple
  patrimonial = true.
  Le backend reçoit ces critères et s'ils ont un contenu, il complète la clause "WHERE" de la requête SQL avec pour l'exemple :
  $sql .= " AND patrimonial = true";
  Ici, c'est le champ "hidden-patri" du formulaire est utilisé.

La backend va renvoyer une liste des observations avec ou non la présence du champ patrimonial pour utilisation en front-end comme vu au début dans la partie liste des observations.

Réflexions

A ce stade, il faut se poser les bonnes questions et on a le choix entre

• prédéfinir les critères de recherches des observations et de filtrage des taxons (à la limite activable ou non). C'est ce qui est en place dans GéoNature pour le moment avec 2 filtres (patrimonial et protection_stricte)
  Avantage : on sait leur nom, leur type, le comportement attendu en interface, les labels utilisés en interface, etc... Donc cohérence facile à gérer entre frontend et backend.
  Inconvénients : ils sont prédéfinis et on ne peut pas en ajouter sans revoir les devs.
• Utiliser le modèle que je propose et tout mettre en paramètres et en conditions
  Avantage : on peut en ajouter à volonté et totalement personnalisables
  Inconvénients : ils sont nombreux :
  § faire une usine à gaz pour le dev (décrite ci-dessus avec une faisabilité restant à évaluer)
  § rendre complexe la mise en place de l'appli et surtout son paramétrage (il faudra que celui qui installe comprenne l'usine à gaz et les liens entre fichier de config, comportement de l'appli, contenu des tables)
• Faire qq chose d'intermédiaire comme :
  créer dans le modèle de données (table bib_taxons) 6, 8 ou 10 champs de filtres nommés filtres filtre0, filtre1, filtre2, ..., filtre9 (qq booléen, qq string avec leur valeurs qq part)
  Pour le front, en paramètre on met un tableau ou un objet js qui fait une description des filtres et de leur comportement en interface genre

filters = [ {"field":"filter0","actif":true,"name":"patrimonial","combo_label":"Taxons patrimoniaux","query_label":"Patrimonial","info_label":"Ce taxon est patrimonial","img":"patri.png"} ,{"field":"filter1","actif":true,"name":"protection","combo_label":"Taxons protégé","query_label":"Protection stricte","info_label":"Ce taxon bénéficie d'un statut de protection","img":"prot.png"}
,{"field":"filter2","actif":false,"name":""," combo_label":"","query_label":"","info_label":"","img":""}
,{"field":"filter5","actif":true,"name":"liste_rouge","combo_label":"Statut liste rouge","query_label":"liste rouge","info_label":"Ce taxon est inscrit en liste rouge comme ","img":"","values":["en danger","menacé","vulnérable","c foutu"]}
,{"field":"filter6","actif":false,"name":"","combo_label":"","query_label":"","info_label":"","img":"","values[]}
, {...}
];

On peut aussi envisager de mettre ces informations dans la base et de faire construire ce json dynamiquement à l'ouverture de l'appli par une action symfony en backend.
o avantages : on garde la souplesse, on peut utiliser les noms de champ (filter0, filter1, filter2,...) en dur coté frontend et coté backend. On connait le type : par exemple les 5 premiers sont des booléens et les 5 suivants sont des strings (ou des integer) avec des valeurs textuelles (ou des ID)
o inconvénients : le nombre de filtres ne peut pas dépasser le nombre prévus dans les dev mais facile à changer pour l'étendre, la structure est en place. C'est un peu pourri en terme de modèle car on aura des champs vides (tous les filtres inutilisés) pour tous les enregistrements. Idéalement il faudrait créer la gestion de la description de ces filtres dans le back-office taxon.

Il serait préférable de se baser sur une liste dans le schéma taxonomie géré par TaxHub, plutôt que sur un champ fixe de la table taxonomie.bib_taxons - PnX-SI/TaxHub#11

L'application est fourni avec quelques protocoles, leurs formulaires de saisie, leurs schémas dans la BDD et les triggers pour alimenter la synthèse dès qu'une donnée est saisie dans ces différents protocoles.

Il est possible d'ajouter de nouveaux protocoles dans GeoNature.
Il faut les ajouter de la manière la plus générique possible pour ne pas modifier le code de GeoNature et ainsi pouvoir bénéficier des prochaines mises à jour de GeoNature.

GENERIQUE :

• Créer un schéma par protocole dans la base de données pour ne pas modifier les schémas existants dans GeoNature.
• Dans les schémas des nouveaux protocoles, mettre en place les triggers alimentant automatiquement la synthèse à chaque fois d'une donnée est insérée ou modifiée dans un de ces protocoles (en s'inspirant des triggers existants dans les schémas des protocoles existants).
• Si vous souhaitez intégrer les formulaires de saisie dans l'application, créer un nouveau module Symfony pour chaque protocole pour leurs formulaires de saisie. Vous pouvez copier un des modules existants pour s'en inspirer en le modifiant.
• Compléter les tables meta.bib_programmes, meta.bib_lots, meta.t_protocoles et synthese.bib_sources et renseignez leurs identifiants dans les fichiers de configuration lib/sfGeonatureConfig.php et web/js/config.js avec les identifiants de chaque protocole. Voir #63

NON GENERIQUE :

• Les parties qui ne sont pas dissociables sont le module Symfony bibs, le fichier de routing, la description de la BDD dans le fichier config/doctrine/schema.yml et l'appel des JS et CSS dans apps/backend/modules/home/config/view.yml.
  A terme ces éléments pourraient être éclatés dans un fichier par protocole/module mais aujourd'hui il faut y ajouter les parties spécifiques à vos nouveaux protocoles.
  Pensez à bien les grouper et les commenter pour pouvoir les reporter après mise à jour de GeoNature.
• La liste des protocoles et les liens vers leurs formulaires de saisie sur la page d'accueil de GeoNature est à modifier dans le fichier apps/frontend/modules/home/template/indexSuccess.php.
• Pour pouvoir éditer une donnée source dans son formulaire de saisie depuis la liste des observations de la synthèse, complétez le fichier web/js/synthese/application.synthse.search.js.

Par exemple à cette ligne du document : https://github.com/PnEcrins/GeoNature/blob/a64d83b96bb8d1d4de898a6f5c6e1db6526ff8bf/web/js/cf/application.cf.editFiche.js#L1929

Trouvé en recherchant "faune" dans le Github : https://github.com/PnEcrins/GeoNature/search?l=javascript&q=faune&utf8=%E2%9C%93

Police, taille, position.

table bib_taxons_faune_pn

• retirer les champs inutilisés "syn_fr", "syn_la", "id_frequence", "sap", "nom_latin_avant_v6", "nom_francais_avant_v6", "cd_nom_avant_v6",
• renommer "prot_fv" en "saisie_autorisee" default true
• renommer cette table en "bib_taxons" pour une généricité faune-flore

Passer sur PostgreSQL 9.4 et PostGIS 2 ?

SHA + grain de sel.
Idem dans UsersHub donc.

Aujourd'hui il n'y a qu'une application générale GeoNature dans UsersHub.
Il pourrait être intéressant de dissocier les droits des utilisateurs par protocole.
Une application Synthèse, une application Contact-Faune, une Faune-Invertébrés, une Flore-Station...

Actuellement il n'y a que 2 types de droits dans GeoNature :

• Rédacteur (niveau 2) qui peuvent saisir dans tous les protocoles et modifier leurs propres données
• Administrateur (niveau 6) qui peuvent modifier toutes les données.

voir à terme pour faire un lien direct avec la base de données

Bandeau de la page d'accueil
Nom de l'application et structure indiqué sur la page d'accueil
....

dans le "où" de la synthèse, tous les sites N2000, réserves et communes de France sont affichés. Mettre en place un système de filtre sur le territoire de travail.

• Ne pas intégrer la création de l'utilisateur serveur dans la procédure d'installation
• Utiliser des chemins relatifs et non en dur comme actuellement : /home/synthese/dev/
• Dissocier cela dans la documentation

analyser la faisabilité de l'utilisation d'un public_html
et donc la création d'un environnement personnalisé par utilisateur avec virtual host.

Liste des taxons :

Taxref complet :

Ils sont actuellement dans le schéma SYNTHESE.
Les déplacer dans les schémas CONTACTFAUNE et CONTACTINVERTEBRES.
Idem pour la table cor_unite_synthese qui fait le lien entre chaque donnée de la synthèse et les unités géographiques (pour ne pas le recalculer à la volée à chaque fois).
En effet les couleurs de chaque taxon dans chaque unités sont basées sur TOUTES les observations présentes dans la synthèse et pas uniquement sur les données CONTACT. Ce qui est un fonctionnement opportun.

PROBLEMES :

• Cela concerne 2 schémas (CF et CINV) et pas un seul.
• A chaque MODIF dans la SYNTHESE, il faut recalculer en dur la couleur du taxon concerné dans l'unité geo concernée.

• Regrouper les outils "OU ?" dans le bloc de recherche. Déplacer les outils DESSINER ZONE, EFFACER, MODIFIER et SHP dans le bloc de RECHERCHE avec les listes de ZONES. Ainsi les supprimer de la barre d'outils CARTO.
• Du coup, 3 modes de recherche géographique : IMPORTER un SHP, DESSINER un CONTOUR, SÉLECTIONNER une ZONE
• Pour la liste des zones, elle pourrait être rendue plus générique dans une seule table (ID, NOM, GEOM, ID_TYPE) + une bibliothèque des types de zones (Reserves, APPB, COEUR, N2000...).

Un taxon doit pouvoir faire partie de plusieurs groupes : exemple le petit murin fait partie du groupe des murins et du groupe des mammifères

Lister des 50 dernières obs par date décroissante.

Faune-Flore ? Vu que l'application intègre la synthèse mais aussi les BDD et saisie des protocoles sources ????

La SYNTHESE n'est qu'une partie de l'appli qui regroupe aussi les données des protocoles sources en aval et les exports vers les partenaires en aval.

retenir une stratégie
proposer une méthode ou des outils

Question du CREA :
J’aurais besoin de savoir comment sont enregistrées les coordonnées géographiques dans la BDD GeoNature. J’ai repéré 2 champs de type « geometry » (« synthese.syntheseff.the_geom_3857 » et « synthese.syntheseff.the_geom_2154 ») mais ce sont des données encodées, et je ne sais pas si c’est ça.
J’ai besoin de cette information pour importer des synthèses d’observation.

Changer l'ordre pour : Recherche, carte, liste, détail d'une observation.