-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refondre la BDD pour gérer l'historique des données #48
Comments
Un travail a été amorcé dans une branche dédiée : https://github.com/PnEcrins/FollowDem/blob/genericDB/data/FollowDem_DataBase.sql Après une nouvelle réflexion, voici la proposition de MCD pour la refonte de la BDD. Explications :
|
A voir si il est possible/pertinent de faire une vue ou vue matérialisée |
Voici une proposition d'implémentation du dernier MCD avec des changements sur la table 't_gps_data'. Pour les contraintes faut-il que les propriétés :
soient uniques ? |
|
OK merci ça me semble bon. |
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 :
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 :
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
Quelques défis :
L'application FollowDem du PNE (https://github.com/PnEcrins/FollowDem) couvre une partie seulement de cette problématique. Mais une partie quand même :
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 :
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 :
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 :
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 :
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 :
Observation individu marqué :
Individus marqués :
Observateur :
Espèce :
2017-09 - Discussion avec PNP pour rendre le MCD plus générique
The text was updated successfully, but these errors were encountered: