camillemonchicourt
commented
5 years ago 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. Le volet "Observations visuels de bouquetins marqués" est mis de côté et pourra être ajouté sous la forme d'une table dédiée reliée à la table des animaux.
Explications :
- La base de données est en anglais.
- Elle est dans un schéma dédié pour pouvoir être intégrée dans une BDD existante.
tpréfixe les tables,libpréfixe les bibliothèques de valeurs,corpréfixe les tables de correspondance- Les identifiants des tables sont auto-incrémentés grâce à leur type
serial - Une interrogation est à lever sur le fait de stocker en dur le
id_cor_animal_devicedans la tablegps_dataou de calculer l'association d'une donnée GPS à un animal à la volée ou de le stocker dans une vue matérialisée (v_gps_animal) v_gps_animalest une vue qui remet à plat les infos à afficher. Elle ne garde que les localisations correctes (répondant aux règles sur le hdop, altitude, ....gps_data.accurate = true). Elle peut être une vue ou une vue matérialisée rafraîchie toutes les heures par un cron.- A voir si les règles de validité d'une gps_data doivent être stockées dans une table dédiée ou dans un fichier de configuration au niveau de l'application.
- A voir si il ne faut pas ajouter un champs
active(boolean) dans les tablest_animalsett_devicespour facilement identifier les animaux et colliers qui ne sont plus suivis. - Dans la table
t_devices, c'est le champsref_devicequi permet de faire le lien avec les données brutes importées, mais ensuite on utilise plutôt le champsid_devicepour faire référence à un device en temps que clé étrangère et ainsi assurer l'intégrité des données. - La table
lib_attributespermet de définir des attributs additionnels pour chaque animaux. Leur type permet de définir leur affichage dans l'admin (select, radio, text...). Le champsvalue_listpermet de prédéfinir une liste pour les attributs de typeselect. Le champsorderpermet de définir leur ordre d'affichage dans l'admin.
cdcvidal
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 :
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