Outil de versionnement des données géographiques à code source ouvert pour des environnements multi-contributeurs (partie 1)
Note des éditeurs : Cet article a été écrit conjointement par Nicolas Gignac, Dami Sonoiki (eHealth Africa) et Samuel Aiyeoribe (eHealth Africa). Ces auteurs aimeraient remercier Yves Moisan, Vincent Mora (Oslandia) et Vincent Picavet (Oslandia) pour leur support et leur contribution pour la rédaction de cet article.
This article is also available in English.
Dans notre monde de l’information centré sur le numérique, les organisations tentent de travailler le plus efficacement possible à produire et diffuser des données géomatique les plus à jour et de la meilleure qualité possible. Si une organisation veut rester compétitive dans le marché, ses données se doivent donc de faire l’objet d’un suivi temporel rigoureux afin d’identifier les multiples changements des différentes révisions publiées et ce, dans une courte période de production. Dans ce contexte, le défi posé aux organisations est de dénicher le meilleur outil sur le marché, de l’adapter aux processus de production de données internes et d’en limiter les coûts, la complexité et le temps d’implantation.
Or, avoir à faire une gestion des données géographiques au sein d’une vaste équipe d’éditeurs dans un environnement de travail devenant de plus en plus distribué et mobile peut s’avérer ardu, spécialement quand vient le temps de gérer des situations de conflits de géométries ou d’attributs modifiés dans le même horizon temporel. En fait, quand une organisation doit gérer une base de données centralisée ou en relation avec un environnement d’externalisation ouverte (ex. données ouvertes publiques, OpenStreetMap), les producteurs de données vont vouloir assurer un suivi très rigoureux des changements. Ils vont vouloir minimiser les contraintes et souvent l’exécuter dans une optique d’être déconnecté à la base de données centrale en utilisant des outils de suivi et de contrôle des différentes révisions, comme cela existe pour l’historisation de code source de programme informatique.
Il existe bien sur le marché plusieurs outils génériques pour gérer les différentes versions de données produites, comme par exemple dans le monde d’ESRI avec ArcGIS et son versionnement de bases de données, mais cette option requiert l’achat de plusieurs licences de SIG bureautique et serveurs.
Dans l’environnement d’OpenStreetMap, des requêtes dans l’historique par l’outil Overpass peut être une autre avenue. Par contre, cet outil d’OSM ne peut être utilisé pour la production de base de données internes. Il y aussi les projets GeoGig et PGversion dans le domaine des logiciels gratuits, libres et ouverts en géomatique, mais ces outils sont souvent incomplets dans le contexte expliqué plus haut. C’est pourquoi il y avait de la place à développer un outil plus complet avec une interface d’utilisation simple permettant de gérer le versionnement au sein d’une base de données libre et centralisée comme PostgreSQL-PostGIS. Par la même occasion, l’outil doit répondre au besoin grandissant de faire des modifications aux données dans un secteur géographique précis sans être connecté en simultané avec une base de données centrale et ce, tout en n’ayant pas à produire une ligne de code pour l’éditeur des données.
Développement de la solution
Afin de répondre à ce besoin tout en voulant réduire ses coûts de licences, deux organisations : le comté de Valcea en Roumanie et l’ONG américaine eHealth Africa (eHA) au Nigéria ont décidé d’utiliser des logiciels gratuits, libres et ouverts en géomatique (Free and Open Source Software for Geospatial : FOSS4G) et de financer le développement d’une nouvelle extension de versionnement dans QGIS en 2015 (https://plugins.qgis.org/plugins/qgis_versioning/). Ce nouvel outil de versionnement pour QGIS a été amélioré et est maintenant simple d’utilisation puis intégré dans des environnements de production depuis 2016.
Figure 1. Processus voulu de l’extension de versionnement.
Les contributions au code source sont venues en deux phases de développement. L’extension a été initialement développée en 2014 par la société française Oslandia pour le département de géomatique d’Apavil, dans le comté de Valceo en Roumanie. De nouveaux développements ciblés sur les processus d’affaire d’eHA ont été ajoutés en 2015 et 2016 supportés par l’équipe géomatique d’eHA et le développeur en géomatique, Yves Moisan de Sherbrooke (Canada) engagé par eHA comme travailleur autonome. Le but était donc de développer une extension permettant de gérer efficacement l’historique des données géomatique modifiées au sein d’une base de données PostGIS centrale en utilisant QGIS et ce, en effectuant des filtres géographiques dans des fichiers de travail pour l’édition en format SpatiaLite en mode déconnecté. Cette extension est fondée principalement sur des commandes ogr2ogr (GDAL) et SQL.
Définition du processus
L’usage le plus courant couvert par l’extension est qu’un ou plusieurs éditeurs extraient (checkout) une copie de travail de la base de données centrale afin de modifier les données localement (dans un fichier SpatiaLite) sur son poste de travail ou sur un appareil mobile, puis en synchronise les changements (commit) vers la base de données centrale PostGIS. Tous ces changements doivent donc être suivis chronologiquement et accessibles ouvertement, comme cela est fait depuis plusieurs années dans les systèmes de gestions de versions de code (ex. CVS), mais appliqués aux données géographiques. De cette façon, les gestionnaires de données peuvent suivre l’évolution des changements, l’ampleur du travail accompli, les conflits potentiels et les différences entre les versions des données.
Initialement, avant d’enclencher le développement par la firme Oslandia, les partenaires ont bien documenté les cas d’utilisation (user story) et analysé les différentes solutions déjà présentes sur le marché. Par la suite, ils ont décidé que la seule avenue était de produire cette nouvelle extension de versionnement pour QGIS afin de répondre au besoin identifié par le comté de Valcea et d’eHealth Africa (qui détient l’un des départements de géomatique les plus actifs en Afrique de l’Ouest). Les fonctionnalités présentes ont été intégrées dans l’optique d’une simplicité d’utilisation, d’une gestion efficace des changements et des conflits, d’un suivi chronologique des modifications et d’un contrôle des révisions des données. L’extension qui est rendue à sa version 0.7 (en date d’avril 2017) peut être utilisée selon le processus suivant :
- D’abord, activer le schéma cible de la base de données centrale PostGIS afin d’y préparer l’environnement qui devrait accueillir les modifications et ce, en fonction des permissions et des privilèges des différents usagers
- Sélectionner dans QGIS les éléments d’un secteur géographique selon une étendue précise (ex. une municipalité, une région, etc.) qui seront à modifier, avant d’en faire l’extraction (checkout) vers une nouvelle copie locale prête pour l’édition en format SpatiaLite
- Modifier les éléments du secteur géographique choisi dans le fichier SpatiaLite directement dans QGIS ou avec une application mobile
- Comparer et visualiser le différentiel (delta ou diff) de la version modifiée complétée, avant d’envoyer le travail accompli vers la base de données centrale PostGIS
- Synchroniser (commit et push) la version modifiée complétée de la copie locale de travail (fichier SpatiaLite) vers la base de données centrale PostGIS et ainsi enregistrer une nouvelle révision (#) en identifiant automatiquement le nom de l’usager ayant fait les modifications et y apposant la date précise de ce nouveau numéro (#) de version créée.
Figure 2. Schéma du processus de l’extension QGIS de versionnement.
Ce processus de production de données ainsi que la genèse de cette nouvelle extension de versionnement de QGIS ont notamment été présentés par Dami Sonoiki, chef du département de géomatique à eHA, lors de la conférence annuelle internationale FOSS4G 2016 qui a eu lieu en août dernier à Bonn, en Allemagne.
En fait, le département de M. Sonoiki, qui est composé de plus 20 techniciens et professionnels en géomatique, utilisait un environnement totalement propriétaire pour le versionnement avant et a migré avec succès vers une solution hybride en logiciel libre, gratuit et ouvert durant l’année 2016. Cette phase de migration a été planifiée de façon itérative avec des “champions” de l’organisation et a terminé son implantation complète à l’ensemble des employés en géomatique au milieu de l’année 2016.
Photo 1. Le département de géomatique d’eHealth Africa en action durant leur phase de production.
Récemment, l’extension a été testée avec succès sur une mise à jour massive de données d’eHealth Africa mettant en cause des millions de polygones à corriger avec des géométries complexes sur plus d’une trentaine de tables.
Comment faire pour l’utiliser ou contribuer ?
Pour plus d’information sur cette nouvelle extension de versionnement, vous pouvez l’installer directement dans QGIS (Menu : Extension = Installez/Gérez les Extensions : Versioning) ou aller sur ce site de documentation : http://qgis-versioning.readthedocs.io/en/latest/ ou télécharger le code source disponible dans GitHub: https://github.com/Oslandia/qgis-versioning. Vous pouvez également soumettre des contributions au code ou rapporter des bogues.
