Chapter 3 Gestion des données, des codes et du manuscrit pour une thèse et une science ouverte
Parler du fait qu’on a fait l’ensemble du travail en utilisant des logiciels libres et gratuits : Ubuntu, R, QGIS, OTB, Grass, Qfield, geopackage, etc. Dire qu’on a scripté toutes les analyses et qu’on les a exposées (transparence, reproductibilité, ouverture à la critique). Dire qu’on a fait des codes génériques et que cela a servi à d’autres: post doc de Denis, post doc de Christophe Dire qu’on a décrit les données, les codes Bien expliquer la différence entre logiciel libre, propriétaire, code source ouvert, etc;
3.1 Manuscrit
Dire que le manuscrit a été écrit en rmarkown. Dispo en pdf mais aussi en format html (via bookdown) ce qui permet de rendre la lecture dynamique.
3.2 Données
3.2.1 De l’intérêt de la bonne gestion des données
Un nombre important de jeux de données a été généré dans le cadre du projet REACT. Les données sont très souvent la base des travaux de recherche, en ce sens, elles sont un produit majeur dans les projets de cette envergure. Si traditionnellement la bonne gestion des données n’est pas nécéssairement valorisée par les porteurs de projet ou par les bailleurs de fonds, aujourd’hui, avec des projets générant des données toujours plus nombreuses, variées, volumineuses, et avec le mouvement croissant vers la science ouverte, elle revêt une importance particulière. Réfléchir à la gestion des données en amont du projet et assurer le suivi régulier tout au long de celui-ci permet d’optimiser de manière significative l’analyse des données, en équilibrant les temps dédiés à la mise en forme des données et aux analyses (et évitant par exemple ainsi la fameuse “règle des 80/20”: chez les scientifiques des données, 80% du temps est dédiée à la préparation des données et 20% uniquement à l’analyse). Par ailleurs, dans un futur proche et avec des initiatives telles le Plan national pour la science ouverte, la garantie de la bonne gestion et valorisation des données brutes sera un élément indispensable à l’obtention de financements pour de tels projets de recherche.
Il est donc important de réfléchir à la chaîne d’aquisition et de valorisation des données dès la phase de définition du projet, en se posant des questions sur la collecte, la documentation, les aspects éthiques et juridiques, le stockage et la sauvegarde, le partage et l’ouverture des données. Les réponses à ces questions sont idéalement formalisées dans un Plan de gestion des données. Des outils, tels DMP OPIDOR, proposent un cadre pour mettre en place un plan de gestion de données dans le montage d’un projet de recherche.
Dans le cadre de cette thèse nous avons utilisé de nombreuses données, de nature diverses et fournies dans des formats variés, pour les croiser entre elles : les données du projet REACT, des données environnementales ou climatiques recueillies sur internet, etc. Nous avons donc décidé de stocker et de décrire les données au sein d’une unique base de données relationnelle. Les codes d’analyses de données que nous avons écrits prennent en paramètres d’entrée exclusivement des données issues de cette base de données. Les codes de préparation des données permettent de générer les données et les intégrer dans la base.
Dans la section suivante, nous présentons l’intérêt d’utiliser une base de données relationnelle pour stocker les données d’un tel travail. La section d’après décrit les données présentes dans la base de données. Enfin, la dernière section montre comment explorer la base de données avec différents logiciels : sous QGIS, DB Browser for SQLite et R.
3.2.2 Les bases de données relationnelles
Lorsque de nombreux jeux de données sont utilisés, et à fortiori quand ils présentent un aspect relationnel - c’est-à-dire que certains jeux de données sont liés entre eux, les réunir au sein d’une base de données relationnelle plutôt que les conserver dans des dossiers “classiques” d’un ordinateur présente plusieurs avantages, parmi lesquels :
- Offre d’un “support” (point d’entrée) unique pour l’ensemble des jeux de données.
- Vérification des contraintes de relations entre les jeux de données via le modèle relationnel de la base de données implémenté au prélabable. Par exemple, si l’on décide dans le modèle relationnel de la base de données qu’un ménage (défini par un lot d’attribut stockés dans une table, une ligne par ménage) doit nécéssairement dépendre d’un village (défini lui aussi par son lot d’attributs dans une table dédiée), la base de données n’acceptera un nouveau ménage (i.e. une nouvelle entrée dans la table ménage) que si le village associé existe bien dans la table village. Dans le cas contraire, la base rejettera l’entrée en nous avertissant que la contrainte est violée. Ces contraintes permettent d’identifier et de corriger nombre d’erreurs dans les jeux de données.
- Capacité à utiliser le Standard Query Language (SQL) pour requêter la base de données. Le SQL est un puissant langage de requêtes de bases de données relationnelles. Certaines fonctions sont particulièrement efficaces sur des jeux de données volumineux.
- Capacité, pour certains systèmes de gestion de bases de données (SGBD), à gérer les données spatialisées (vectorielles et/ou rasterisées), avec de nombreux bénéfices associés, parmi lesquels :
- analyses spatiales via des fonctions SQL dédiées ;
- facilité d’utilisation de la base de données avec des logiciels de SIG (QGIS, ArcGIS, etc.) et d’analyses de données spatialisées (R, Python, etc.) ;
- compatibilité avec les géoservices (par exemple, ceux définis par l’Open Geospatial Consortium) qui permettent de rendre les données FAIR.
La nature des données du projet REACT justifie pleinement l’utilisation d’une base de données relationnelle : nombreux jeux de données, spatialisés pour beaucoup, liés entre eux (i.e. “imbriqués” les uns dans les autres, par exemple les individus recensés habitent dans des ménages qui eux mêmes se situent dans des villages, ces trois niveaux étant décrits respectivement dans des tables).
Lorsque l’on décide d’utiliser une base de données relationnelle pour stocker les données, la question du système de gestion de bases de données (SGBD) à utiliser se pose. Une base de données relationnelle est implémentée dans un système de gestion de bases de données relationnelles (SGBDR). Un SGBDR peut être vu comme un “logiciel” qui permet d’executer un langage normalisé de manipulation des bases de données (le plus connu est le SQL) : créer les tables de la base, les contraintes relationnelles entre les tables, manipuler les tables (les remplir, mettre à jour, supprimer, etc.), requêter les tables, etc. Il existe de nombreux systèmes de gestion de bases de données relationnelles. Ils diffèrent, entre autre, par leur type de license (propriétaire ou libre), leur coût, leur capacité à stocker et requêter des volumes importants de données, leur capacité à gérer les données spatialisées.
Nous avons décidé d’utiliser le SGBD GeoPackage (GPKG) pour stocker les données de nos travaux (et du projet REACT par extension). Geopackage est un SGBD relativement récent (créé en 2014), ouvert, non-propriétaire, embarqué (c’est à dire qu’il se matérialise par un fichier stocké dans l’ordinateur et portable - au contraire d’un sytème client-serveur) et spatialisé. Il peut être vu comme un “container” de données qui gère à la fois les données vecteur, raster et non spatialisées. Très concrêtement, il se matérialise par un fichier (extension *.gpkg), que l’on stocke dans un dossier de son ordinateur ou appareil mobile et que l’on peut s’échanger au même titre que tout fichier informatique. Le format GeoPackage est défini sur la base de standards de données (OGC ou autres), ainsi, bien que récent, de nombreux logiciels historiques permettent de l’ouvrir et de manipuler les données qui y sont contenues. Notons que le logiciel de SIG Quantum GIS en a fait son format par défaut à partir de la version 3, contre précédemment le format propriétaire d’ESRI, format de données phare des SIG : le Shapefile.
3.2.3 Les jeux de données présents dans la base de données
Le tableau suivant présente les jeux de données utilisés dans nos travaux et disponibles dans la base de données. Le tableau est lui-même issu de la base de données (table metadata). La base de données contient par ailleurs des jeux de données “bruts” non présentés dans le tableau mais stockés afin de conserver la trace des données non corrigées / transformées. Le nom des tables dans la base est indiqué dans le tableau par la colonne persistent_identifier.
| id_metadata | persistent_identifier | subject | title | description | format | relation |
|---|---|---|---|---|---|---|
| 1 | anc_westafricacountries | Données contextuelles | Limites administratives des pays de l’Afrique de l’Ouest | Couche géospatiale des limites administratives des pays de l’Afrique de l’Ouest. | geo / vecteur | |
| 2 | anc_boundproject | Données contextuelles | Limites géographiques des zones du projet REACT | Couche géospatiale des limites des deux zones du projet REACT | geo / vecteur | |
| 3 | anc_westafricacities | Données contextuelles | Villes majeures d’Afrique de l’Ouest | Couche géospatiale de la localisation des villes majeures d’Afrique de l’Ouest. | geo / vecteur | |
| 4 | ent_hlcmetadata | Données entomologiques | Captures sur sujet humain | Cette table contient les dates, coordonnées géographiques et horaires des enquêtes épidémiologiques (captures sur sujet humain) / données consolidées | geo / vecteur | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/hlc_dates_loc_times.R |
| 5 | ent_hlcmosquitoes | Données entomologiques | Comptes et identification des vecteurs issus des enquêtes épidémiologiques | Cette table contient les données d’identification des moustiques issus des campagnes épidémiologiques (captures sur sujet humain). Chaque ligne correspond à un moustique capturé. Le poste, l’heure de capture, le genre et l’espèce du vecteur sont systématiquement renseignés. Pour un sous-échantillonage des vecteurs, les informations sur l’état de l’abdomen et la parturité sont | table | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/mosquitoes.R |
| 9 | env_dictionary | Données environnementales | Conditions environnementales à proximité des points de CSH : métadonnées | Cette table contient la description des indices environnementaux, climatiques et paysagers calculés à proximité de chaque point de capture sur sujet humain. | table | |
| 10 | env_lsm | Données environnementales | Conditions environnementales à proximité des points de CSH : métriques paysagères (occupation du sol) | Cette table contient les valeurs des indices paysagers issus des cartes d’occupation du sol, calculés à proximité de chaque point de capture sur sujet humain. | table | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/vignettes/import_tidy_transform_envdata.Rmd |
| 11 | env_ts | Données environnementales | Conditions environnementales à proximité des points de CSH : séries temporelles (données climatiques) | Cette table contient les valeurs des indices climatiques calculés à proximité de chaque point de captures sur sujet humain recouvrant 40 jours avant la nuit de capture | table | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/vignettes/import_tidy_transform_envdata.Rmd |
| 12 | env_static | Données environnementales | Conditions environnementales à proximité des points de CSH : données non-temporelles | Cette table contient les valeurs des indices paysagers, environnementaux et sociologiques divers, calculés à proximité de chaque point de capture sur sujet humain. | table | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/vignettes/import_tidy_transform_envdata.Rmd |
| 13 | env_nightcatch | Données environnementales | Conditions environnementales à proximité des points de CSH : données recouvrant la nuit de capture | Cette table contient les valeurs des indices climatiques calculés à proximité de chaque point de captures sur sujet humain recouvrant la durée de la nuit de capture | table | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/vignettes/import_tidy_transform_envdata.Rmd |
| 14 | lco_cipedology | Données d’occupation du sol | Carte pédologique / zone Côte d’Ivoire | Carte de la pédologique sur la zone Côte d’Ivoire. Cette couche a été générée à partir d’une carte papier réalisée par l’IRD disponible ici : http://sphaera.cartographie.ird.fr/carte.php?num=942&pays=COTE+D%2527IVOIRE&iso=CIV | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/pedology.R |
| 15 | lco_bfpedology | Données d’occupation du sol | Carte pédologique / zone Burkina Faso | Carte de la pédologique sur la zone Burkina Faso. Cette couche a été générée à partir d’une carte papier réalisée par l’IRD disponible ici : http://sphaera.cartographie.ird.fr/carte.php?num=998&pays=BURKINA+FASO&iso=BFA | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/pedology.R |
| 16 | lco_bfL1 | Données d’occupation du sol | Carte d’occupation du sol / zone Bukina Faso : niveau 1 (2 classes) | Carte d’occupation du sol à fine échelle sur la zone Burkina Faso, incluant 2 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 17 | lco_bfL2 | Données d’occupation du sol | Carte d’occupation du sol / zone Bukina Faso : niveau 2 (5 classes) | Carte d’occupation du sol à fine échelle sur la zone Burkina Faso, incluant 5 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 18 | lco_bfL3 | Données d’occupation du sol | Carte d’occupation du sol / zone Bukina Faso : niveau 3 (11 classes) | Carte d’occupation du sol à fine échelle sur la zone Burkina Faso, incluant 11 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 19 | lco_bfL4 | Données d’occupation du sol | Carte d’occupation du sol / zone Bukina Faso : niveau 4 (17 classes) | Carte d’occupation du sol à fine échelle sur la zone Burkina Faso, incluant 17 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 20 | lco_bfL5 | Données d’occupation du sol | Carte d’occupation du sol / zone Bukina Faso : niveau 5 (22 classes) | Carte d’occupation du sol à fine échelle sur la zone Burkina Faso, incluant 22 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 21 | lco_ciL1 | Données d’occupation du sol | Carte d’occupation du sol / zone Côte d’Ivoire : niveau 1 (2 classes) | Carte d’occupation du sol à fine échelle sur la zone Côte d’Ivoire incluant 2 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 22 | lco_ciL2 | Données d’occupation du sol | Carte d’occupation du sol / zone Côte d’Ivoire : niveau 2 (6 classes) | Carte d’occupation du sol à fine échelle sur la zone Côte d’Ivoire incluant 6 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 23 | lco_ciL3 | Données d’occupation du sol | Carte d’occupation du sol / zone Côte d’Ivoire : niveau 3 (13 classes) | Carte d’occupation du sol à fine échelle sur la zone Côte d’Ivoire incluant 13 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 24 | lco_ciL4 | Données d’occupation du sol | Carte d’occupation du sol / zone Côte d’Ivoire : niveau 4 (16 classes) | Carte d’occupation du sol à fine échelle sur la zone Côte d’Ivoire incluant 16 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 25 | lco_ciL5 | Données d’occupation du sol | Carte d’occupation du sol / zone Côte d’Ivoire : niveau 5 (19 classes) | Carte d’occupation du sol à fine échelle sur la zone Côte d’Ivoire incluant 19 classes d’occupation du sol. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/workflow_object_based_data_analysis.R |
| 26 | lco_metadata | Données d’occupation du sol | Cartes d’occupation du sol : table de correspondance entre les valeurs des pixels et les noms des classes | Table de correspondance entre les valeurs des pixels des classes d’occupation du sol et les noms et descriptions des classes correspondantes. | table | |
| 27 | lco_bfbuiltup | Données d’occupation du sol | Carte des zones bâties (habitations) / zone Burkina Faso | Carte précise des zones bâties sur la zone Burkina Faso. Cette couche a été générée à partir d’une image satellitaire SPOT6/7 à 1,5 mètre de résolution spatiale. La couche d’occupation du sol réalisée dans le cadre du projet a permis d’affiner la classification finale. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/builtup.R |
| 28 | lco_cibuiltup | Données d’occupation du sol | Carte des zones bâties (habitations) / zone Côte d’Ivoire | Carte précise des zones bâties sur la zone Côte d’Ivoire. Cette couche a été générée à partir d’une image satellitaire SPOT6/7 à 1,5 mètre de résolution spatiale. La couche d’occupation du sol réalisée dans le cadre du projet a permis d’affiner la classification finale. | geo / raster | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/builtup.R |
| 35 | rst_individus | Données de recensement | Individus | Cette table contient les données de recensement des individus présents dans chaque ménage de chaque village enquêté dans le projet REACT. | table | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/raw_individus.R |
| 36 | rst_menages | Données de recensement | Ménages | Cette table contient les données simplifiées de recensement des ménages de chaque village du projet REACT. La table procure uniquement le nombre d’individus constitutifs de chaque ménage (issues des recensements REACT) et les coordonnées géographiques de l’habitation. Cette table a été constituée à partir des tables « Menages » et « Individus ». | geo / vecteur | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/villages_households_loc_pop.R |
| 37 | rst_villages | Données contextuelles | Villages | Cette table contient les données relatives aux village du projet : population (issues des recensements REACT) et coordonnées géographiques de chaque village. | geo / vecteur | script_dataset_generation@https://raw.githubusercontent.com/ptaconet/malamodpkg/master/database/villages_loc_pop.R |
| 40 | soc_llinuse | Données sociologiques | Enquêtes sociologiques | Cette table contient les données issues des enquêtes sociologiques (comportements humains). Pour un sous-échantillonage des ménages, cette table renseigne les habitudes comportementales des individus composants le ménage : horaires de présence dans l’habitation la nuit, horaires de sommeil et utilisation ou non de moustiquaire. | table |
3.2.4 Télécharger et ouvrir la base de données
La base de données est disponible en téléchargement à l’adresse suivante : . Le fichier zippé disponible au téléchargement contient la base de données (fichier react.gpkg) et un projet QGIS (react.qgs) (voir la partie Quantum GIS pour ouvrir le projet QGIS).
Comme indiqué dans la section précédente, le format GeoPackage est défini sur la base de standards de données (princiapelement OGC) gérés nativement par de nombreux logiciels. Ainsi, il existe de nombreux moyens d’explorer et manipuler les données présentes dans la base. Dans cette section, nous détaillons succintement comment ouvrir et explorer la base de données avec trois logiciels gratuits et multi-plateformes : DB Browser for SQLite, Quantum GIS et R.
3.2.4.1 DB Browser for SQLite
DB Browser for SQLite (DB4S) est un logiciel léger qui permet de manipuler les bases de données SQLite, SGBD sur lequel s’appuie le format GeoPackage. Le logiciel est téléchargeable à l’adresse suivante : https://sqlitebrowser.org/. Pour ouvrir la base de données dans DB4S, il s’agit simplement de double-cliquer sur le fichier contenant la base de données (à priori, l’ordinateur reconnaît DB4S comme logiciel par défaut pour ouvrir les fichiers au format *.gpkg). La figure suivante présente la base de données ouverte sous DB4S.
Figure 3.1: Capture d’écran de DB4S - onglet principal
Pour l’utilisateur de la base de données, l’onglet principal est Parcourir les données : à travers cet onglet, l’utilisateur se voit proposer la liste des tables présentes dans la base dans une liste déroulante. Il s’agit simplement de séléctionner la table d’intérêt pour qu’elle apparaisse
Figure 3.2: Capture d’écran de DB4S - onglet ‘Parcourir les données’
3.2.4.2 Quantum GIS
Quantum GIS (QGIS) est un logiciel désormais bien connu de SIG. Il permet de lire nombre de formats de données géospatiales, dont le GPKG, qui par ailleurs est le format par défaut du logiciel depuis sa version 3. QGIS est téléchargeable à l’adresse suivante : https://www.qgis.org/fr/site/forusers/download.html. Pour ouvrir la base de données, aller dans l’explorateur (Couche > Gestionnaire des sources de données > Explorateur) puis identifier le lien vers la base de données sous l’option GeoPackage. L’ensemble des données de la base (vecteur, raster et non-spatiales) est alors listé. Double-cliquer sur la table d’intérêt pour l’ouvrir et la visualiser.
Figure 3.3: Capture d’écran de QGIS - explorateur de données
Nous avons par ailleurs préparé un projet QGIS qui permet d’explorer une partie des tables de la base. Le projet QGIS est téléchargeable au même lien que la base de données (il est disponible dans le fichier zippé). Pour l’ouvrir, il faut placer le projet (fichier react.qgs) et la base de données (fichier react_db.gpkg) dans le même dossier sur l’ordinateur, puis ouvrir le projet en double-cliquant dessus.
Figure 3.4: Capture d’écran du projet QGIS react.qgs
3.2.4.3 R / RStudio
R est un langage de programmation ouvert pour le traitement de données et l’analyse statistique. C’est le langage de programmation que nous avons utilisé pour réaliser l’ensemble des analyses de ce travail de thèse. RStudio est un environnement de développement (autrement dit un logiciel qui facilite la programmation) pour R. R est téléchargeable à l’adresse suivante : https://cran.r-project.org/ et RStudio à l’adresse suivante : https://rstudio.com/.
Figure 3.5: Capture d’écran de RStudio
Le code suivant propose deux options pour ouvrir et explorer la base de données, avec les packages RSQLite ou sf :
# Lien en local vers la base de données (fichier react.gpkg)
path_to_db <- "/home/ptaconet/react/datasets/react_db.gpkg" # lien local vers la base de données (fichier au format *.gpkg)
#### Option 1 : avec le package RSQLite
if(!require(RSQLite)){
install.packages(RSQLite)
}
library(RSQLite)
con <- dbConnect(RSQLite::SQLite(),path_to_db)
# Ouvrir la table "rst_villages" de la base de données en tant que data.frame
tab<-RSQLite::dbReadTable(con,"rst_villages")
head(tab)
# Pour lister toutes les tables de la base :
tables_in_db<-RSQLite::dbListTables(con)
head(tables_in_db)
#### Option 2 : avec le package sf
if(!require(sf)){
install.packages(sf)
}
library(sf)
tab<-sf::st_read(path_to_db,"rst_villages") # L'avantage par rapport à RSQLite est que sf détecte l'aspect spatial des données (si présent) et l'ouvre dans R en tant qu'objet de classe sf (simple feature)
tab