La BDD a été créée initialement dans l'objectif d'afficher les bouquetins équipés d'un collier en cours de fonctionnement.
L'affichage dans l'application se limite aux localisations d'un an maximum.
Ainsi il n'y avait pas d'objectif de stocker un historique des localisations, ni des bouquetins n'étant plus suivis.
Pour pouvoir centraliser et stocker l'ensemble des données il est désormais souhaité pouvoir archiver et stocker l'ensemble des localisations ainsi que l'historique des associations entre colliers et bouquetins.
Un même bouquetin pouvant avoir porté différents colliers. Un même collier pouvant avoir été posé sur plusieurs bouquetins.
Par ailleurs un travail a été commencé sur une base de données et une application permettant de saisir et gérer des observations visuelles de bouquetins marqués.
Ces données sont liées car lorsqu'un bouquetin est équipé d'un collier GPS, on lui pose en même temps un marquage auriculaire.
Cela permet de compléter les localisations GPS par les localisations visuelles et de pouvoir continuer à localiser le bouquetin visuellement une fois qu'il n'a plus de collier.
Une première application dédiée aux observations visuelles à été développée par le @PnMercantour : https://github.com/PnMercantour/app_bouquetin
Il a été envisagé de regrouper les observations visuelles et les localisations GPS dans une seule BDD.
Il a aussi été évoqué le fait d'avoir une BDD et une application générique qui puisse être utilisée pour d'autres suivis que les bouquetins.
Enfin il a été évoqué le fait de pouvoir ajouter des informations de protocoles spécifiques (reproduction, interactions, sanitaire...) en plus des localisations des animaux marqués.
Différents échanges ont eu lieu sur le sujet.
Voici un récapitulatif de ceux-ci :
2017-02 - Premier MCD
PNM :
Premier MCD pour les observations de bouquetins marqués sur https://github.com/PnMercantour/app_bouquetin
PNE :
- Ajouter des date_creation et date_update sur la table TaggedAnimal (géré par trigger)
- Dans la table TaggedAnimal, séparer oreille_droite et oreille_gauche, ajouter Sexe et Année de naissance. On utilise en effet ces infos pour l'appli FollowDem qui sert au portail http://bouquetins.ecrins-parcnational.fr (https://github.com/PnEcrins/FollowDem/tree/master/data)
- Toujours dans cette table, on a une date de début (catch_date) mais il faudrait aussi une date de fin (quand le bouquetin meurt ou n'est plus suivi)
Maintenant si on part sur l'idée que cette BDD contienne aussi les localisations GPS des Bouquetins marqués, il faudrait aussi ajouter le numéro de collier de chaque bouquetin (attention un collier peut être utilisé par des bouquetins différents à des périodes différentes, et un même bouquetin peut avoir des colliers différents à des périodes différentes), un date de fin de suivi GPS (bouquetin mort, collier cassé ou défaillant...).
Et ajouter une table avec les localisations GPS (id_tagged_animal, dateheure, X, Y, temperature, nb_satellites, altitude).
A voir si cela doit être stocké dans une autre table ou utiliser la même table Observations avec un type (GPS ou Contact visuel).
PNE :
En complément des remarques de Camille, voici une proposition de principe (pas le temps de dessiner le modèle)
Pour une généricité maximale, donc la possibilité de suivre d'autres animaux, sans oreille par exemple ! Voir autre chose que des animaux.
On suit des dispositifs de marquage (collier GPS, boucles auriculaires, autres...) = trackeddevices
Ces dispositif sont attachés à des animaux en n-n (avec une date début et une date fin et surtout un id unique car un dispositif peut comme le dit Camille servir successivement sur plusieurs animaux) = taguedobject + cor_object_device
On localise dans le temps et dans l'espace les dispositifs de marquage (observations) devices_locations
On attache à ces localisations (observations) des informations "spécifiques" au protocole de suivi (par exemple la notion de femelle suitée, de remarques, d'autres animaux en présence, etc...). Sauf bonne idée, la généricité s'arrête ici, à cause du mot "spécifique".
Le modèle doit permettre aussi :
- de qualifier les informations :
validité (basée sur le pdop GPS ou autre),
suppression (données test des colliers au bureau ou en fonction dans une voiture etc...)
id_protocole/programme
producteur/propriétaire des données
- de conserver l'historique et de distinguer facilement les dispositifs actifs des non actifs
- de séparer et d'isoler tout ce qui est spécifique à un protocole afin d'uniquement compléter le coeur du modèle : table(s) spécifique(s)
Quelques défis :
- réussir à mixer l'automatisation du recueil des informations (GPS) avec des observations visuelles (animaux marquées)
- automatiser la qualification des données du recueil automatisé
- modéliser la description des dispositifs de marquage de manière générique (marquage bouquetins différent du marquage de tortues ou de grenouilles). Voir si des tables spécifiques à chaque sujet peuvent être évitées.
L'application FollowDem du PNE (https://github.com/PnEcrins/FollowDem) couvre une partie seulement de cette problématique. Mais une partie quand même :
- Elle permet notamment le traitement automatique des données GPS et la localisation en ligne en temps réel des animaux équipés
- Par contre elle ne permet pas vraiment de conserver l'historique des localisations, ni de gérer les observations des animaux marqués.
- http://bouquetins.ecrins-parcnational.fr/
PNP :
Pour la gestion des données GPS, je pense qu’il serait judicieux de s’inspirer de ce qui existe, comme la BDD européenne du programme Eurodeer sur le chevreuil (il doit y avoir des milliers d’individus).
Pour faire simple, il suffit de faire une table ‘animal’ une table ‘Sensor’ et une table ‘anisensor’ qui fait correspondre les deux.
PNV :
Pour l'appli en général
Nous pensons qu'il serait bien de faire une appli générique suivi d'animaux marqués / équipés qui gère à la fois les contacts visuels ou autres (GPS, captage d'émetteurs).
La proposition de Gil d'avoir à la fois une table animal et device parait être la bonne. A voir si le contact pourrait alors avoir lieu sur le device ou sur l'animal (avec une table de relation n-n animal-observation pour pouvoir spécifier si des animaux sont vus ensembles et une table de relation device-observation qui permettra de spécifier la qualité de la réception radio/gps). En extrapolant le device aux boucles d'oreilles/autres marques, on pourrait raccrocher toutes les obs aux devices.
Pour le MCD au niveau Vanoise :
- table animal: pour les couleurs nous avons oreille droite, oreille gauche et collier (a voir si les infos de marquage vont dans le device ou pas). Ajouter année de naissance, date de capture, date de décès, id secteur
- Même si on reste sur une appli générique, il faudrait garder la possibilité de rattacher d'autres tables à l'observation visuelle. En Vanoise il y a le volet suivi de repro et le volet suivi sanitaire.
Pour le suivi repro, possibilité d'ajouter le statut suitée pour les femelles. En Vanoise: Certain/Probable/Possible/Absence/Absence probable/Gestante/Non gestante
Pour le suivi sanitaire des animaux: pour nous il s'agit de :
- Etat corporel : Très maigre/maigre/Bon Etat/Embonpoint
- Kerato : Atteint stade 1/Atteint stade 2/Atteint stade 3/Atteint stade 4/Guéri séquelles1/Guéri séquelles2/Guéri séquelles3/Attitude/Indemne
- Dyspnée : 0/1
- Jetage nasal : 0/1/2
- Toux : 0/1/2
Pour les obs, possibilité de spécifier animal capturé (1ere obs), animal trouvé mort
PNP :
Je ne sais pas si ça vous sera utile, mais pour compléter, voir le document (http://www.springer.com/gp/book/9783319037424 / 21 MB) qui décrit la façon dont sont montées les bases de données GPS wildlife avec des gros stocks de données (on arrive très vite à compter en millions)… C’est comme ça qu’on a monté la nôtre à l’INRA.
Ça ne concerne que la partie GPS évidemment… effectivement on suit des colliers GPS … après avoir mis un individu à l’intérieur…
1 bémol pour le généraliser au marquage visuel: dans toutes les études, on se retrouve (par erreur évidemment) avec des individus de la même population qui ont exactement et simultanément le même marquage (même couleur de boucle à gauche et à droite par exemple et pas de collier). En général on arrive à les différencier (car par exemple pas le même âge ou pour x raisons)… et on essaie de recapturer pour corriger le tir… voir si l’entrée device le permettrait.
Exemple classique : 2 bouquetins de la même population ont des colliers GPS de couleurs différentes et chacun une boucle rouge à chaque oreille. On fait tomber les deux colliers par drop off. Ils ont le même marquage !! coup de bol : ils sont dans des sites différents. On peut quand même les différencier en attendant de changer une boucle ou de mettre un autre tag.
Je vous envoie aussi un petit brouillon que j’avais fait concernant la partie ‘obs visuelle’ et ce qui nous intéressait de mettre dans une appli (web par exemple) de saisie et d’interrogation.
Champs pour les observations de bouquetins marqués :
- Date
- Heure
- Nom de l’observateur
- Longitude
- Latitude
- Altitude
- Secteur PNP
- Commune
- Type d’observation : visuelle/approximative
- Nb total groupe
- Nb cabris
- Nb Eterlous
- Etc…
- N° de suivi unique
- Nom de l’animal
- Sexe
- Autre infos liées à l’individu (date _capture, lieu capture etc…) -> Table individu
- Id_Suité : 0, 1, 2, 3
- Suité : Non Determiné, Certain, Probable, Non suitée
- Autre
2017-03 - Deuxième MCD
PNE :
PNE :
En complément, les tables protocoles1, protocoles2, devraient être des tables filles de la table des observations.
Dans observations tu as ce qui est commun et si possible ce qui va dans la synthèse, dans les tables filles, tu as tout ce qui est spécifiques à chacun des protocoles.
La table protocoles c'est de la métadonnée qui est liée à la table des observations, elle permet de savoir dans quelle table fille trouver les données d'observation complémentaires mais il me semble qu'il ne faut rien connecter dessus.
PNM :
Proposition MCD PNM
PNE :
Quelques remarques :
- On ne peut pas mettre la date de capture dans la table des objets car un objet peut être capturé plusieurs fois.
- On n'aurait fait qu'une table des observations, en sortant la partie GPS
Pour le reste je pense qu'on est similaire.
2017-06 - Echanges sur le périmètre, la généricité, les champs, protocoles, questions à intégrer ou non
2017-07 - Validation du projet par GTSSC et V2 du CCTP du PNP
Observation groupe :
- IdObs (Numérique)
- Date (date)
- Heure (heure)
- Longitude (Numérique)
- Latitude (Numérique)
- Espèce observée (Liste déroulante – Sélection du Taxref)
- Nom observateur(s) (Liste déroulante)
- Taille totale du groupe (Calculé)
- Nombre de cabris (Numérique)
- Nombre d’éterle/ou(Numérique)
- Nombre de femelles (Numérique)
- Nombre de jeunes mâles de moins de 6 ans (Numérique)
- Nombre de mâles de plus de 6 ans (Numérique)
- Nombre de mâles indéterminés (Numérique)
- Nombre d’individus indéterminés (Numérique)
- Précision de la localisation (liste déroulante – « Visuelle », « Approximative »),
- Remarques groupe (Texte long)
- Commune (Numerique)
- Secteur (Texte)
- Altitude (Numérique)
- Interaction avec d’autres espèces (texte Long)
Observation individu marqué :
- Nom Individu (Liste déroulante filtrée en fonction de l’espèce et de la date d’observation)
- Code marque (Automatique),
- Caractère suité ou non de l’individu (liste déroulante – « Non déterminé », « Certain », « Probable », « Non suité »)
- Remarques individu marqué (Texte long)
- Capture de l’individu (oui/non)
- Mortalité de l’individu (oui/non)
Individus marqués :
- Espèce (Liste déroulante – Selection du Taxref)
- Programme (Liste déroulante)
- Numéro unique (Automatique)
- Marquage visuel utilisé (Texte)
- Nom attribué à l’animal (texte)
- Sexe (Liste déroulante – « Mâle » ou « Femelle »)
- Date du marquage (Date)
- Circonstances du marquage ((Liste déroulante – « Première capture » ou « Lâcher »)
- Date de naissance (Date)
- Date de la mort (Date)
- Population (Liste déroulante)
- Sous-population (Liste déroulante)
- Remarques (Texte long)
- Photographie
Observateur :
- Code observateur (auto)
- Nom - Requis
- Prénom - Requis
- Structure - Requis
- Qualité
Espèce :
- CD_Nom (Numérique)
- Nom Scientifique (Texte)
- Nom Vernaculaire (Texte)
2017-09 - Discussion avec PNP pour rendre le MCD plus générique
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent