Skip to content
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

Open
camillemonchicourt opened this issue Dec 11, 2017 · 6 comments
Open

Refondre la BDD pour gérer l'historique des données #48

camillemonchicourt opened this issue Dec 11, 2017 · 6 comments
Labels

Comments

@camillemonchicourt
Copy link
Member

camillemonchicourt commented Dec 11, 2017

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 :

2017-03-21-mcd-bouquetins-cm

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

2017-03-21-pnm-mcd_bouquetins_beta

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

2017-07-mcd-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

2017-09-25-pnp-modele marques proposition

@camillemonchicourt
Copy link
Member Author

camillemonchicourt commented Jul 17, 2018

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.

2018-07-17-mcd-followdem

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.
  • t préfixe les tables, lib préfixe les bibliothèques de valeurs, cor pré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_device dans la table gps_data ou 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_animal est 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 tables t_animals et t_devices pour facilement identifier les animaux et colliers qui ne sont plus suivis.
  • Dans la table t_devices, c'est le champs ref_device qui permet de faire le lien avec les données brutes importées, mais ensuite on utilise plutôt le champs id_device pour faire référence à un device en temps que clé étrangère et ainsi assurer l'intégrité des données.
  • La table lib_attributes permet de définir des attributs additionnels pour chaque animaux. Leur type permet de définir leur affichage dans l'admin (select, radio, text...). Le champs value_list permet de prédéfinir une liste pour les attributs de type select. Le champs order permet de définir leur ordre d'affichage dans l'admin.

@camillemonchicourt
Copy link
Member Author

A voir si il est possible/pertinent de faire une vue ou vue matérialisée v_gps_animal comme indiqué ci-dessus ne listant que les positions valides des animaux actifs (animaux avec un collier actif sur la période en cours) à afficher sur le portail public.

@cdcvidal
Copy link
Contributor

Voici une proposition d'implémentation du dernier MCD avec des changements sur la table 't_gps_data'.
La relation avec le ‘Device’ se fait avec la table 't_devices' à l’aide de la propriété 'ref_device'.
Se baser sur la clé primaire nous semble dangereux pour l’intégrité des données. A vous de nous dire.

Pour les contraintes faut-il que les propriétés :

  • 'device_type' de la table 'lib_device_type',

  • 'attribute' de la table 'lib_attributes,

  • 'name' de la table 't_animals',

  • 'ref_device' de la table 't_devices'

soient uniques ?

Capture d'écran de 2020-02-12 08-33-52

@camillemonchicourt
Copy link
Member Author

  • OK, en effet t_gps_data est à brancher sur t_devices et non pas cor_animal_devices, c'était une erreur de notre part.
  • Mieux vaut par contre rester sur t_devices.id_device (champs serial unique) comme clé étrangère dans t_gps_data
  • Les champs x, y et longitude, latitude et geom_mp sont redondants. Ne garder que longitude, latitude
  • Il y a une typo, le champs hadop est à renommer hdop
  • OK pour les contraintes d'unicité que tu proposes. Cela évitera des doublons dans les données.

@cdcvidal
Copy link
Contributor

Le MCD corrigé
Capture d'écran de 2020-02-12 12-36-53

@camillemonchicourt
Copy link
Member Author

OK merci ça me semble bon.

cdcvidal added a commit that referenced this issue Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants