PgVersion est un plugin QGIS disponible dans le dépôt Kappasys Repository. Le plugin est encore en développement, sa version actuelle est la 0.9.3. Ce dernier vous permet de versionner des couches géographiques c'est à dire de garder des états antérieurs de la couche (appelés révision) aussi bien concernant la géométrie et les attributs.
Personnellement, j'ai longtemps cherché comment gérer des couches géographiques qui sont mises à jour très régulièrement. S'il n'y a que des ajouts, je pourrai jouer avec les tables mères et enfants dans PostGreSQL mais comment gérer le cas de figure de la suppression d'un objet ou d'une modification attributaire d'un objet existant.
Jusqu'à présent, je m'inspirais de CorineLandCover : avoir des états complets à une date et une couche mutation des changements entre deux dates mais imaginez la confusion à moyen terme pour des informations mises à jour très fréquemment (mensuelle, semestrielle, etc).
Dans cet exemple, je créerai une couche versionnée pour gérer le potentiel foncier issu des zones à urbaniser des PLU. Le but est de n'avoir qu'une couche avec des états annuels que nous pourrons comparer.
Installation
Sous Linux, vous aurez besoin de dépendances spécifiques à Qt4 et PostGreSQL, installez les si vous ne les avez pas déjà :
- Ubuntu - libqt4-sql libqt4-sql-psql python-qt4-sql
- openSUSE – libqt4-sql libqt4-sql-postgresql python-qt4
Présentation du plugin
Le plugin se présente dans le menu Base de Données de la barre de menu mais aussi avec une barre d'outils. Elle est moins complète que le menu contextuel mais conserve les fonctions essentielles dont vous avez besoin.
Les fonctions principales de cette barre d'outils sont :
- Préparer une couche au versionnement
- Charger une couche versionnée
- Appliquer les changements (en créant une nouvelle révision)
- Revenir à la version principale (version précédente validée)
- Afficher l'historique et par la même occasion charger un précédent état dans QGIS
Par le menu contextuel, il est possible d'annuler la fonction de versionnement sur une couche, ce qui peut s'avérer nécéssaire si vous voulez apporter une modification dans sa structure.
A présent, ouvrons la table à versionner et préparons là avec la première icône de la barre d'outils.
La première fois, le plugin vous demandera d'installer les fonctions adéquates sur votre base, vous devez avoir les droits appropriés sinon demandez à votre admin BDD d'exécuter le fichier SQL
Une fois cette action effectuée, réessayez :
Voilà c'est fait ! Retirez la couche et chargez la par l’icône de la barre pgversion . Assurez vous que votre utilisateur va bénéficier des droits nécessaires pour utiliser cette fonction.
Architecture PostGreSQL / PostGIS
Voyons comment cela se traduit coté BDD : le script créé un schema versions dans votre base où seront référencées toutes les couches versionnées ainsi que les historiques de modifications.
En revanche, les couches restent bien dans leur schéma d'origine, le versionnement créé une vue avec un suffixe _version sur lequel nous reviendrons plus tard.
Etude de cas : le versionnement dans un observatoire foncier
Sur la carte ci-dessous figure en rose les zones disponibles à l'urbanisation selon les documents d'urbanisme en 2007. Supposons que les deux zones sélectionnées en jaune vont muter. L'une va changer de type et l'autre va voir son périmètre réduit. Je vais modifier ces deux zones en ouvrant une session de mise à jour comme avec n'importe quelle couche.
Lorsque j'ai terminé et enregistré ma couche, on remarque qu'elle est annotée comme (modified). En fait, vous avez opéré des modifications qui n'ont pas été validées dans un état (donc une révision). En réalité, vous êtes sur la requête avec le suffixe _version que nous avions repérée précédemment. Si un utilisateur charge la couche postGIS sans passer par PgVersion, il verra la dernière révision s'afficher sans les modifications que nous venons d'opérer (très intéressant pour des projets non approuvés ou demandant vérification).
Vous pouvez fermer QGIS et revenir plus tard sur la couche (modified) cela ne pose pas de problème, vos modifications restent « en attente ». Pour créer un nouvel état (par exemple 2011), cliquez sur Commit Changes et saisissez le commentaire désiré, la notification (modified) disparait et vous avez alors un nouvel état.
Attention : il peut arriver que le statut reste sur (modified). La révision ne se créera pas même si le message dit le contraire, annulez en revenant à la version principale (HEAD). Vous avez du avoir un bug.
Les disfonctionnements que j'ai pu identifier lors de mes tests sont :
- lorsque vous essayez de changer vous même la clé primaire d'un objet. Même si cela peut parfois fonctionner, les attributs des objets risquent de se mélanger
- en copiant collant des entités provenant d'un shape (même s'il a la même structure)
- en copiant collant des entités n'ayant pas le même structure attributaire
Pour charger un nouvel état, passez par le menu Log :
Pour consulter un ancien état de la couche, sélectionnez la révision (ici la 1 pour revenir en 2007) et cliquez sur checkout revision to memory layer pour la charger dans QGIS.
Je retrouve bien mon ancien zonage. Coté attributs, la zone à l'est a été modifiée en zone Agricole, pourtant si j'interroge la couche rev_1 je retrouve bien l'information comme quoi ma zone était en Activité. On remarque que la couche nous indique également que l'attribut a été modifié (statut delete).
Voici donc un premier aperçu de ce plugin très prometteur, je vous invite à ouvrir l'aide pour voir les explications lors de saisie sur une même couche par plusieurs opérateurs et la fonction permettant de valider un tracé plutôt qu'un autre. Par ailleurs le développeur aurait besoin d'aide pour implémenter la fonction Diff qui permettrait d'afficher automatiquement les changements entre deux révisions. N'hésitez pas à le contacter si vous pouvez/voulez contribuer !
Au delà des fonctions encore en développement, le plugin est déjà opérationnel et utilisable en production. A la différence de l'option versionning de l'excellent PostGIS Manager (autre plugin à posséder absolument) ce dernier reconstitue automatiquement les états antérieurs grâce à son interface.
Conclusion
Essayons de synthétiser un bilan sur PgVersion à partir de ce tour d'horizon :
Les Moins :
- Installation Windows ? - non testée -
- Pas de possibilité de purger certains logs (si vous faites un retour arrière, l'historique le stock) . Pour nettoyer les différentes révisions, il faudrait passer en manuel par les tables ?
- Quelques bugs lors de copier coller, cela peut être ennuyeux pour transférer plusieurs historiques sans avoir à tout retracer.
Les Plus :
- Un système intuitif clair et une barre d'outil ergonomique
- Une traduction française bientôt disponible
- Une gestion des révisions par une interface graphique
- La notion de modification approuvée évitant aux utilisateurs de publier une carte avec des données erronées ou non officielles.
- La gestion des conflits dans le cadre d'une saisie multi-utilisateurs - non testée -
Site officiel : Site de Dr. Horst Düster
licence Creative Commons Paternité-Pas d'Utilisation Commerciale-Partage des Conditions Initiales à l'Identique Commerciale 2.0 France
Commentaires
Traduction dans les bacs !
Mettez à jour votre plugin de 0.9.3 vers 0.9.4 pour bénéficier de la version française. Pour aider à améliorer la traduction, postez ce qui vous chargine sur le forum : http://www.forumsig.org/showthread.php?t=32173
Poster un nouveau commentaire