Ajouter protocole Contact Flore dans GeoNature

[camillemonchicourt]

Plusieurs utilisateurs de GeoNature seraient intéresser pour disposer du Contact Flore, en plus du Contact Faune déjà existant.
Le CREA a récemment déployé GeoNature et souhaiterait ainsi y intégrer un protocole Contact Flore, sur le modèle du Contact Faune.

Question de @delestrade :

Au niveau de la saisie d'observations de Flore, est ce qu'on sera sur le même modèle que pour la Faune (mêmes champs de saisie) ?
Au niveau de GeoNature, le protocole Faune et le protocole Flore sont 2 choses bien distinctes. Du coup, je me demande s'il ne faudrait pas faire un nouveau protocole, mais simplifié, regroupant les observations de Faune et de Flore.

Pour clarifier les choses, aujourd'hui dans GeoNature il y a le protocole Contact Faune (Vertébrés, Invertébrés et Mortalité) et le protocole Flore Station (qui n'est pas un protocole de contact Flore) mais d'inventaire partiel ou complet de toute la végétation sur une station définie avec des informations sur le relief, les strates, le milieu....
Il y a aussi un protocole d'inventaire des bryophytes qui est intégré sur un modèle assez proche de Flore Station (description station, puis listing des bryophytes observés sur la station).

La synthèse regroupe automatiquement les données Faune et Flore saisies dans les différentes protocoles.

Pour intégrer le Contact Flore, il y a en effet 2 approches possibles :

• Ajouter la Flore au Contact Faune, pour en faire un seul protocole Contact Faune et Flore
• Créer un autre protocole Contact Flore sur la base du Contact Faune existant.

A mon avis, la solution 2 serait préférable. Utiliser tout ce qui a été fait pour le protocole Contact Faune (formulaire et trigger pour alimenter la synthèse) mais en l'adaptant à la Flore. Dans le contact Faune on a un critère (vu, entendu....) et un dénombrement par sexe qui ne collent pas pour le Contact Flore qui a peut-être d'autres spécificités.
Donc je ferai plutôt comme pour les autres protocoles ajoutés (#54). Un nouveau schéma ContactFlore dans la BDD sur la base du schéma ContactFaune, ajouter les modules, compléter les YML et autres.

Par contre ce protocole interesse potentiellement d'autres structures, donc il serait fortement utile de récupérer ce qui a été fait au CREA pour l'intégrer dans une prochaine version générique de GeoNature.

J'en parle avec @gildeluermoz lundi.
@amandine-sahl un avis ?

[camillemonchicourt]

@amandine-sahl, @gildeluermoz, @delestrade, @Chrispnv, @samuelpriou, il faut aussi discuter du coup des champs du protocole Contact Flore si on veut partager le protocole et l'intégrer dans GeoNature de manière générique.

[samuelpriou]

A chaque structure son schéma de donnée. Il faut donc en discuter entre géomaticiens mais il faudra également y associer les chargés de mission flore des PN pour que le choix retenu fasse l'unanimité. Ici au PNM nous saisissons la station --> x visites --> x observations.

[camillemonchicourt]

A mon avis, un ContactFlore devrait rester ultra-basique si c'est du contact aléatoire...
Un point, un ou plusieurs taxons, éventuellement un dénombrement. A creuser.
Car là si il y a Un station, X visites par stations, X taxons par visites, on est sur du pseudo-suivi ???

[samuelpriou]

On peux le voir comme ça. Notre chargée de mission flore est je pense intéressée pour participer à la discussion.

[camillemonchicourt]

OK donc @gildeluermoz que le ContactFlore doit être un nouveau protocole avec son propre schéma dans la BDD.
Pour les champs, rester sur du contact, c'est-à-dire pointage, taxons, date, observateurs, remarques.

• Surface ? Denombrément ? Phénologie ? Habitat ? Substrat ?

[camillemonchicourt]

La position du CREA (@delestrade) : Avoir juste un indice d'abondance (dénombrement).

[Chrispnv]

Désolé d'arriver tardivement dans la discussion.

Comme je le disais hier à Gil, pourquoi un module Contact Flore dans Geonature alors que ObsOcc fait déjà ce travail. Après je peux concevoir que ObsOcc et Geonature sont 2 applis différentes avec une communication via un processus tiers pour migrées les données.
Nous actuellement dans notre application de relevés d'observations occasionnelles naturalistes sur internet 'Données naturalistes', pour la flore on a le processus suivant : sur 1 relevé (objet point avec date, observateur, commune (auto), altitude (auto)) on peut avoir 1->n observations faune, flore... et pour 1 observation flore, on a comme champ : espèce, abondance (5 classes de nb d'individus), phénologie (10 classes de stade de dev)). Après il faut que je vois avec mon botaniste (T. Delahaye) ce qu'il en pense d'avoir plus de champ.

Sur le coté appli de relévés d'observations occasionnelles sur mobile en mode déconnecté, on a actuellement un appli Aigle mobile sur le même schéma que la partie flore de notre appli 'Données naturalistes' sur internet sauf que c'est 1 relevé -> 1 observations (pas le choix). Ces relevés viennent alimenter la BDD de données d'observations occasionnelles.
Vu qu'on va arrêter d'utiliser la solution Aigle, on cherche une autre solution mobile. La solution viendrait de la déclinaison de l'appli Contact Faune (avec aide à la prospection) du PNE, avec une réflexion aussi sur les champs attributaires nécessaires. Pour ce, je suis en contact avec Makina Corpus via de reliquats de budget 2015 pour monter ce projet de déclinaison. Pour le moment 3 solutions envisagées :

• Prestation complète de Makina sur cahier des charges des modifs souhaitées pour la flore
• Prestation complète de Makina sur cahier des charges des modifs souhaitées pour la flore + formation sur code pour déployer à minima nous même par la suite
• formation pour apprendre à déployer une nouvelle déclinaison nous même.
  => selon proposition financière, la solution 2 serait la plus pertinente.
  Il est possible qu'avec le peu de temps qu'il me reste pour monter ce projet que cela ne se fasse pas avec des budgets 2015, mais sur des budgets 2016, par contre là je n'ai pas de vision sur les possibilités budgétaires, même si ce projet est prioritaire pour le pôle Patrimoine.
  J'aurais plus d'éléments sous peu. Si cela se fait, l'application Contact Flore sera bien sur disponible pour d'autres structures (comme Contact Faune).
  Comme on le disait hier avec Gil, reste à se mettre d'accord de façon simple (sinon on n'aura pas le temps) sur les champs utile à un protocole observations occasionnelles flore.

[camillemonchicourt]

Fait déjà ce travail, c'est discutable.
Et si il y a l'appli mobile alors autant avoir l'appli WEB qui va bien en face et en cohérence.

[Chrispnv]

Salut,
quel est l'intérêt en plus de ObsOcc d'avoir une appli internet de saisie d'observations occasionnelles avec aide à la prospection ? L'aide à la prospection est utile sur mobile quand l'agent est sur le terrain.

[camillemonchicourt]

Ce n'est pas vraiment la question de l'aide à la prospection ni que ObsOcc soit une application tiers.
Le point important est d'avoir un protocole cohérent et une structuration des données cohérentes entre l'appli web et la mobile.
ObsOcc c'est une grande boite où on peut mettre un peu tout.
Ce n'est pas du tout la même approche et l'outil est très différent aussi.
Et il serait dommage de tout mélanger.
Ceux qui utilisent déjà ObsOcc sont un peu obligé de le garder mais pour les autres qui peuvent déployer GeoNature ça n'a pas trop de sens. En tout je ne le vois pas.

Donc je ne comprends pas bien l'intérêt de déployer GeoNature et ObsOcc et c'est un risque que de tout mélanger et mettre de la confusion auprès des utilisateurs.

[Chrispnv]

Pourtant c'est ce qu'on avait validé en inter-parc et c'est pourquoi une version 2 de ObsOcc va sortir.

En tout cas, cela nous fait réfléchir car on était sur le point de faire installer un ObsOcc v2 par PNF. On a encore du mal à voir l'intérêt d'un contact Flore ou Faune avec aide à la prospection sur Web. Sur mobile, c'est évident.
On a une réunion le 30 novembre avec le pôle Patrimoine sur les aspects outils carto. On va poser ce genre de question. De plus Jérome Cavailhes venant du PNP est notre nouveau Chargé de mission faune, donc il doit avoir un avis sur ObsOcc.

Si vous développez Contact Flore pour internet, vous allez fare un déplication de contact Faune avec les mêmes technos de dev ou vous allez le faire avec les nouvelles technos inter-parcs (Angular et symfony2) et les modules génériques mis en place par le PNC ?

Sinon pour les champs attributaires pour contact Flore sur mobile, mon botaniste se pose des questions sur l'intérêt d'avoir en même temps un champ sur l'abondance et sur la surface occupée par une espèce. Il est plus partant pour l'abondance. Mais cela reste encore en réflexion. A suivre.

[camillemonchicourt]

Ce n'est pas la question de l'aide à la prospection en WEB.
Même si bien sur que c'est intéressant qu'ils puissent voir en WEB aussi où il y a quelles espèces à prospecter !
Et ObsOcc n'est pas un outil inter-parc mais l'outil pour ceux qui n'avaient rien à l'époque. Mais il y a pas mal de problèmes conceptuels, ergonomiques et scientifiques dans ObsOcc.
ObsOcc ça va bien si tu n'as rien. Mais si tu as déjà des protocoles bien cadrés et avec tout ce qu'offre GeoNature c'est pas une bonne idée du tout. As-tu retesté l'appli récemment ?
En plus ça ne fonctionnera de mettre notre appli mobile sur ObsOcc. C'est pas la même logique ni structure de données. De plus je reste convaincu qu'ObsOcc pose pas mal de questions sur la démarche scientifique et la qualité des données et embrouille les agents dans une démarche amateur naturaliste.

Si on l'a fait cela sera en dupliquant ce qui est fait dans GeoNature pour ContactFaune.
On ne fera surement pas un nouveau développement à côté alors que dupliquer le ContactFaune prendrait une journée.
Et le mieux serait que ça soit un autre parc qui en a besoin qui le fasse et l’intègre dand GeoNature, comme ça il prendrait la main sur l'outil !

Et ça ne pourra pas être dans l'appli Suivi_Projet du PNC, car c'est un outil générique fait pour les protocoles de suivi (X sites avec des visites regulieres de chaque site et des observations dans chaque visite).

[Chrispnv]

OK.
Je ne parlais pas de l'application Suivi_projets à proprement parlé, mais des modules génériques qui la compose qui peuvent servir de base à la réalisation d'une nouvelle appli, par exemple pour la gestion des formulaire depuis des schéma de BDD passé à la moulinette Symfony.

On vient à Gap le 17 novembre pour la réunion appli carto/BDD dans le cadre du réseau Alpes/Ain. On pourra discuter de tout cela.

[camillemonchicourt]

OK je ne serais pas là le 17 mais Gil sera là.

Vu la simplicité de dupliquer le ContactFaune dans GeoNature, je pense pas qu'il faille réinventer une appli en repartant quasiment à zéro.
D'autant plus que les agents auront ainsi un ContactFlore cohérent avec le ContactFaune.

Si on se met d'accord sur les champs, c'est plié en quelques jours de dev...

[Chrispnv]

OK

[camillemonchicourt]

Pour le PNE après échange avec le CDM flore :
Un point correspondant à une surface fixe (10x10m par exemple) et une classe d'abondance par taxon.
Pour le reste, voir les protocoles spécifiques.

[camillemonchicourt]

Pour les champs, on tomberait d'accord sur :

• Date
• Espèce (liste)
• Localisation XY
• Observateurs
• Abondance (liste)
• Phénologie (liste)

Chacun pouvant avoir les classes d'abondance et de phénologie qu'il souhaite.

PnVanoise :
Au niveau des champs, on a ça pour l'instant (mais on peut en changer, l'info importante pour nous reste la date, l’espèce, le lieu, l'observateur)
Espèce : liste
Abondance : <10 ; 10 à 100 ; 100 à 1000 ; > 1000
Phénologie :
1- Germination, bourgeonnement
2- Développement des feuilles
3- Formation des pousses latérales, tallage
4- Développement des tiges, croissance des rosettes
5- Développement des organes de propagation végétative
6- Apparition de l'inflorescence, épiaison
7- Floraison
8- Fructification
9- Maturité des fruits et des graines
10- Sénescence et dormance
Remarques : texte libre

PnEcrins

A vu, la phénologie est effectivement intéressante à noter (surtout si on considère que l'analyse en sera pertinante sur un temps un peu long).

Pour les échelles d'abondance, j'ai du mal à trancher. Je crois qu'il s'agit surtout d'une question d'habitude. Nous (PNE et CBNA), on estime des surfaces relatives au sein d'un quadrat (coefficients de Braun-Blanquet, gradués sur 5 échelons), la Vanoise un nombre de tiges... Je suis de manière générale assez contre les dénombrements chez les plantes, car dans l'écrasante majorité des cas, on croit compter des individus alors qu'on ne compte que des "innovations" (en somme, une partie fertile d'un individu, ce dernier en produisant parfois plusieurs centaines).
L'autre point est que si on compare les courbes données par les 2 échelles, celle de la Vanoise correspond à une exponentielle très forte.

• PNE :
  
• PNV :
  
  Avec seulement 4 échelons de valeurs, je ne sais pas du coup si autre chose que les 2 premiers auront un sens (<10 ou >100).
  Mais bon, les estimations à la Braun-Blanquet ne sont pas non plus exempt de critique. La seule conséquence de ces différences est que si on veut mener des analyses à l'échelle des Alpes (cf. travaux W. Thuiller), alors pour utiliser les abondances il faudra recréer une nouvelle échelle qui fera une mauvaise synthèse des 2.

[camillemonchicourt]

GD-PNE : Question de néophyte : est-ce que le protocole contact flore peut/doit permettre de mener des analyses, à l'échelle des Alpes ou même locale ?
Si noté l'abondance est peu exploitable, il en découle deux approches :
1- on la supprime considérant que c'est inutile
2- on la conserve pour la poursuite du protocole Vanoise (la question sera seulement : saisie facultative ou obligatoire ?)
OK pour la phénologie. Chaque structure pourra mettre les stades qui l'intéressent dans sa base.

CD-PNE : Réponse d'archéophyte : y contribuer, oui.
On la conserve, en connaissance de cause.

[camillemonchicourt]

Et bien sur altitude et commune sont calculés automatiquement.
A voir si comme dans Contact Faune on a une FICHE (XY) et un RELEVÉ (taxons) ?

[camillemonchicourt]

PnVanoise :

Du côté Vanoise, l'abondance est notée (dans 50% des cas environ, c'est facultatif) mais ne sert que d'indication pour les agents de terrain et leurs prospection. On passe ensuite sur le protocole suivi si on veut faire de réelles estimations.
Pour la phénologie, je pense qu'il y a trop de classes (à part les classes stade végétatif, floraison, fructification, on a très très peu de saisie, c'est facultatif également). C'est vrai que chaque parc pourrait mettre ses propres classes et j'imagine que tous auront les classes floraison et fructification, qui devraient être a priori les seules exploitées à une échelle inter-parcs ou nationales.
OK pour l'altitude et la commune calculés automatiquement
OK aussi pour garder la possibilité de mettre plusieurs espèces sur le même relevé XY + un champ remarques/observations.

[camillemonchicourt]

GD-PNE :

Sur la phénologie. Il sera possible de modifier les classes mais il est clair qu'il serait préférable d'avoir un contenu partagé. Doit-on rendre cette saisie obligatoire ?
Pour le reste, relevés et observations (avec remarques sur chaque observation), on est sur le modèle que Contact Faune. Donc c'est plus simple. Seul le vocabulaire est différent. Dans GeoNature, le relevé est une fiche et l'observation un relevé. Je préfère le vocabulaire Vanoise, plus explicite mais un changement dans Geonature serait trop impactant et très lourd à réaliser.

[samuelpriou]

Je ne pense pas qu'il faille rendre obligatoire la saisie de la phénologie. Il n'est pas toujours évident de la terminer.
C'est bien de reprendre le même modèle que contact faune avec un relevé et x observations. Tant pis pour le vocabulaire fiche.

[camillemonchicourt]

PNVANOISE :
Vu avec le CDM Flore :

• Phénologie (la liste de la Bd du RCFAA lui semble la plus adaptée car plus simple)
• Abondance (ok avec 4 classes - 1 ; 2 à 10; 10 à 100; >100)
  Il serait plutôt adepte de rendre ces champs obligatoire.

Demande pour pouvoir inclure des champs spécifiques bryophytes (mais est-ce seulement possible ?) :

• "Fertilité" (oui/non)
• Échantillon d'herbier (oui/non)
• Localisation de l'échantillon (texte)

[samuelpriou]

Nous avons fait un point avec notre CDM flore.
Tout colle excepté qu'elle souhaite conserver la description des menaces éventuelles sur la station ou fiche.

id_type_menace	type_menace	id_menace	detail_menace
1	Aménagements	7	Urbanisation
1	Aménagements	8	Voies de circulation (pistes, sentiers)
1	Aménagements	9	Equipements sportifs (escalade, via ferrate)
1	Aménagements	10	Recalibrage de cours d'eau
1	Aménagements	11	Comblement Zone humide
1	Aménagements	12	Drainage, captages
2	Actions humaines	13	Piétinement
2	Actions humaines	14	Abandon ou transformation cultures
2	Actions humaines	15	Surcharge pastorale
2	Actions humaines	16	Traitement herbicide
2	Actions humaines	17	Cueillette
2	Actions humaines	18	Arrachage ou vandalisme
2	Actions humaines	19	Débroussaillage ou fauchage
2	Actions humaines	20	Absence de débroussaillage ou fauchage
2	Actions humaines	21	Exploitation forestière
2	Actions humaines	22	Reboisement
3	Origine biotique	23	Concurrence végétale
3	Origine biotique	24	Dégâts de gibier ou animaux
4	Pollution	25	Pollution des eaux
4	Pollution	26	Pollution des sols
5	Non menacé semble t-il	3
5	Sans info	6

[gildeluermoz]

Techniquement possible. Le contenu doit rester propre à chaque structure et sera lu par l'application en base.
A noter :

• On s'éloigne de la notion de simple contact. L'observateur ne se limite pas à pointer la mocalisation du taxon, il entame une description.
• Y a t-il un véritable usage qui est fait de cette information, si oui comment (traitement stat, analyse en vue de mesures de conservation ou simple info), par qui et dans quel contexte.
• Cette information de menace n'ayant pas forcement un caratère permanent, elle peut aussi apparaitre après l'observation.Elle n'est pas non plus systématiquement en lien direct avec le taxon mais plutôt avec la station. N'est elle pas plutôt à évaluer lors de l'utilisation des données (portée à connaissance, projet d'aménagement).
• L'information, si elle est facultative est-elle couramment saisie par les observateurs ? Le champ 'remarques' peut-il suffire ?
• Ceci complexifie les dev car on s'éloigne du contact faune.

[gildeluermoz]

PNV : Demande pour pouvoir inclure des champs spécifiques bryophytes (mais est-ce seulement possible ?).

GD : Clairement non. S'il y a des champs spécifiques c'est qu'il y a un besoin spécifique bryophytes.
Donc on sortirait de la logique : un protocole = une BDD (un modèle de données).
On ne peut pas ajouter des champs qui sont "à ne pas remplir" dans la majorité des cas flore non bryo.
Dans ce contexte, tout milite pour un contact flore ET un contact Bryophyte.
On a la même logique pour contact faune (vertébrés) et contact invertébrés :
2 schémas, 2 formulaires web, 2 appli mobiles.

[camillemonchicourt]

En effet dans ce cas là, mieux vaut faire une application Bryophytes à part vu que c'est un autre protocole.

[samuelpriou]

Après discussion avec notre CDM flore, il s'avère que la menace s'apparente plus à la station qu'à une observation.
En résumé, pas de champs menace à jouter dans la saisie flore occasionnelle. On pourra éventuellement ajouter ces champs à la station dans le protocole flore station.

[camillemonchicourt]

PNV

Champs obligatoires :

• Coordonnées géographiques = se remplit automatiquement
• Date = date du jour par défaut, sinon choix
• Observateur = 1 -> n
• Nom du taxon (TAXREF)
• Phénologie (la liste de la Bd du RCFAA me semble plus adaptée que l'actuelle sur Aigle)
• Abondance (liste simple mais de bon goût)

On met quand même nos besoins pour les bryophytes au cas où.

• "Fertilité" (champ devenant actif que pour une saisie de bryophyte)
• Echantillon d'herbier (champ devenant actif que pour une saisie de bryophyte)
• Localisation de l'échantillon (champ devenant actif que pour une saisie de bryophyte)
  => l'ajout des bryophytes est à discuter, on se pliera au groupe. Nous on considère que c'est le même protocole que pour la flore (au CBNA, les bryophytes sont rangés au même niveau que la flore).

Champ facultatif :

• commentaire (texte)

PNE

On pense vraiment que si il y a des champs en plus pour les Bryophytes, alors c'est un autre protocole donc mieux vaut une schéma de BDD à part mais aussi une appli mobile (et WEB) à part.
Ce sera même aussi simple voir plus simple de reprendre l'appli ContactFlore, de la dupliquer et d'y ajouter les champs Bryophytes, que de faire afficher des champs en fonction du taxon.
Et pour tout ce qui n'est pas Bryophytes, ça évitera d’avoir des champs vides dans la BDD.
Par ailleurs si certains veulent saisir le ContactBryophytes comme le reste du ContactFlore, ils ne pourront pas le faire avec la solution proposée.

PNM

Je partage le sentiment de Camille sur les bryophytes et peut être que le plus simple est : "de reprendre l'appli ContactFlore, de la dupliquer et d'y ajouter les champs Bryophytes, que de faire afficher des champs en fonction du taxon".

PNV

Pour les bryophytes à voir pour faire au plus simple.

PNE

Pour les bryophytes, il ne faut pas juste faire au plus simple mais aussi en cohérence avec nos principes d'organisation.

PNE

S'il y a des besoins spécifiques bryophyte c'est que le protocole est différent donc le modèle de données est différent, donc un schéma "contactflore" ET un schéma "contactbryophyte". Même s'ils sont proches l'un de l'autre.
On respecte le principe : un protocole, une BDD (ou un MCD = un schéma PostgreSQL), une appli (un formulaire web et éventuellement une application mobile). Donc une appli contact flore ET une appli contact bryophyte. Comme le dit Camille c'est aussi plus simple à développer.

PNV

Pour les bryophytes on est d'accord sur le principe pour la base de données... Par rapport à notre expérience sur Aigle, ce qui marchait vraiment bien, c'était d'avoir dans une seule application mobile, la possibilité de saisir pour le protocole observations occasionnelles plusieurs thématiques différentes (flore, vertébrés, invertébrés, bouquetins marqués, bryophytes, flore patrimoniales) avec chacun leur champs spécifiques. Après pour l'import en bases chaque données allaient dans son schéma ou ses tables ad hoc. Là c'est vrai qu'avec l'aide à la prospection, il est plus difficile d'agglomérer différentes thématiques dans une seule application.

[camillemonchicourt]

Développement en cours sur la base du Contact Faune.

Tests PNV :

Pour notre CM, la saisie est très bien comme ça, le champs validité peut être mis en booléen, ça lui va aussi et c'est peut-être plus générique pour toi.
Le champs validité visible selon les droits -> OK
Le champs validité obligatoire à la saisie -> peut-être pas si c'est un booléen (valeur nulle par défaut= donnée en attente).
Par contre, dans la synthèse, si une observation est non valide, elle ne devrait être ni visible ni exportable par des utilisateurs autres que validateur/administrateur (peut-être même non exportable du tout).
Les validateurs/administrateurs, qui doivent donc valider les données devraient pouvoir identifier rapidement les données non validées (soit par un champ dans la recherche à gauche, soit par une couleur différente ou un flag à droite comme dans l'appli de bilan station flore).
Il faudrait peut-être penser aussi à un système de validation de données par lot (plutôt que d'avoir à ouvrir individuellement toutes les données...).

Retour PNE :

Le champ validité est actuellement obligatoire à cause de la clé étrangère sur bib_validites. Je pense effectivement que je vais le mettre en booléen, non obligatoire avec une valeur null par défaut de façon qu'il soit possible de ne pas l'utiliser (mise en paramètre de sa valeur par défaut et de son utilisation).

Pour ce qui est de la synthèse. Je ne peux retenir aucun de vos retours et j'en profite pour faire un rappel important à propos de sa fonction.
La synthèse est un regroupement des données de TOUS les protocoles. Au vu de la diversité possible des modèles de données des protocoles, la synthèse regroupe UNIQUEMENT les champs communs à toutes les observations de TOUS les protocoles : le qui, quand, quoi, où et comment (en gros l’occurrence de taxon du SINP). Tout ce qui est spécifique à un protocole, ici la notion de validité mais aussi la phénologie et l’abondance ne peuvent remonter dans la synthèse car spécifiques au contact flore. Pour chaque protocole on a des champs spécifiques : le dénombrement du contact faune ou le statut de reproduction d'un gite chiro ou un tas d'autres possibilités spécifiques à chaque protocole.

Je comprends la nécessité de pouvoir consulter les données du contact flore de manière complète. Surtout si la validation est requise. Il est évident que pour faire cela, il faut créer une application spécifique comme pour flore station. Ce n'est cependant pas d'actualité et il me semblait logique que le contact flore soit le pendant du contact faune. C'est à dire pas d'application spécifique car très basique et très proche de la synthèse. Par exemple dans contact faune, invertébrés ou dans mortalité, on saisie un dénombrement par sexe et âge (mais aussi un booléen prélèvement pour la mortalité ou l'heure et le milieu pour les invertébrés). Ces informations spécifiques ne remontent pas en synthèse, ne sont pas exportables ni consultables (sauf donnée par donnée) et ne sont accessibles qu'en base. A noter que je n'ai quasiment aucune demande d'export de ces informations. Ce qui mène à se poser la question de leur utilité/pertinence...

J'en profite pour vous faire part de notre approche concernant le concept de validation. Suite à de nombreuses tentatives/tentations de mettre en place ce mécanisme, nous avons constaté qu'il soulève de nombreuses questions et difficultés qui nous ont conduit à y renoncer.

 - Quelle est la définition d'une donnée valide ?
 - Quels sont les critères de validité : la crédibilité/compétence de l'observateur ? La connaissance du territoire du ou des validateurs ? Le dire d'expert ?
 - Doit-on distinguer une donnée non validée et une donnée invalide ?
      - Si oui, comment ? (null, true, false ?)
      - Si oui, quelle valeur a une donnée invalidée ?
           - Faut-il la supprimer ?
           - Pourquoi la conserver et avec quel niveau d'accessibilité ?
           - Peut-on la consulter ? Qui ?
           - Peut-on l'exporter ? Qui ?
           - Faut-il en informer l'auteur ?
      - Si oui, que faire des données en attente de validation ?
           - Les auteurs peuvent-ils y accéder ?
           - Peut-on les consulter ? Qui ?
           - Peut-on les exporter ? Qui ?
           - Que se passe t-il si elles restent longuement non validées parce que le validateur n'a pas le temps.
      - Sinon ???

Toutes ces questions si elles trouvent réponses conduisent à minima à la mise en place d'une usine à gaz quant à la gestion des droits et des différentes possibilités.

Nous partons des principes suivant (pour un contexte comme celui d'un parc national) :

 - l'observateur professionnel est généralement le plus à même de savoir si sa donné est valide (il saisit ou ne saisit pas).
 - une base sans erreur est une utopie
 - une donnée douteuse ou manifestement invalide peut donc être supprimée à posteriori (disons rendue inaccessible aux utilisateurs)
 - Le dire d'expert renforce la crédibilité d'une donnée

Ceci nous a conduit à :

 - Renoncer à la mise en place du mécanisme la plupart du temps
 - Quand c'est toutefois nécessaire préférer la notion de "relue/non relue" (booléen).
      - Il s'agit d'un simple statut d'information et non d'un jugement concernant la valeur de la donnée.
      - Du coup rien à gérer au niveau des droits d'accès.
      - La donnée peut rester longtemps non relue
      - Si un soucis est constaté, la donnée est supprimée

Je vous propose d'essayer de répondre à toutes ces questions avec vos thématiciens. Ensuite on en recause.

Il est possible de lui donner accès aux données contact flore via une vue complète sur le schéma contactflore.

[gildeluermoz]

Voir le commit principal : a5a78ff

[camillemonchicourt]

Vu avec le CDM flore du PNE qui souhaite déployer CFlore ici aussi.
Ça reste une BDD de contact qui ne permet pas de faire du suivi donc pour lui les champs abondance et phenologie ne doivent pas être obligatoires.