Petite réalisation qui date un peu (encore) : le plugin GéoPicardie pour QGIS. Je l’ai développé initialement pour la plateforme du même nom, en 2013 approximativement. Depuis, il n’a cessé d’être adopté et adapté. Un projet simple, mis en place par des passionnés, avec peu de moyens, et qui rencontre un succès inattendu au-delà de son périmètre géographique initial.
WMS et WFS, faciles à utiliser ?
Lorsque j’étais administrateur et animateur de GéoPicardie, j’ai vite pris conscience de la frustration qui peut être induite par la technicité des standards de l’OGC, en particulier par les protocoles WMS et WFS (principaux moyens d’accès aux données de la plateforme).
Au premier abord, pas besoin d’être un génie pour afficher une couche WMS ou WFS avec un outil SIG comme QGIS. Après tout, il suffit de l’URL du service, puis de choisir une couche et de l’ajouter à la carte, hein ? Bah, pas forcément, en fait. Si c’était aussi simple, QGIS ne proposerait pas autant de paramètres pour configurer la connexion au service et le chargement d’une couche.
Certains de ces paramètres sont simplement des options du protocole d’accès, d’autres sont là pour contourner des erreurs d’implémentation ou des ambigüités du standard et d’autres pour essayer d’optimiser son usage. Pour bien les maitriser, il vaut mieux bien comprendre ces protocoles, connaitre l’histoire de leur standardisation, savoir comment ils sont implémentés et comment les données sont exploitées du côté des serveurs. Je passe rapidement sur le fait que les interfaces graphiques de QGIS ont tendance à regrouper des protocoles différents : WMS avec WMTS, WFS avec l’API Features. La solution parfaite pour perdre tout le monde.
Comment éviter cette complexité ?
En tant qu’animateur et administrateur d’une plateforme diffusant très largement ses données, j’avais besoin que les utilisateurs accèdent aux données sans qu’ils se trompent dans la configuration des couches. Deux raisons à cela :
- montrer que la plateforme de données partenariale peut leur faciliter le quotidien ;
- éviter que les utilisateurs mettent en place le plan B : télécharger toutes les données plutôt que d’exploiter les services en ligne.
Pour atteindre cet objectif, la première solution envisagée a été de produire un fichier projet pour QGIS pour chaque jeu de données vedettes de la plateforme. L’utilisateur aurait juste eu à le télécharger depuis le catalogue et à le charger dans QGIS.
Néanmoins, j’ai retenu une autre solution qui m’avait été donnée par l’administrateur de données de Picardie Nature : créer un plugin pour QGIS. L’intérêt était multiple :
- ajouter une couche par un simple clic dans n’importe quel projet QGIS ;
- donner de la visibilité aux jeux de données essentiels (en ne présentant qu’une sélection de données utiles à tous) ;
- en faciliter la recherche à l’aide d’une organisation thématique et arborescente (un travail éditorial qui nécessite de comprendre les attentes des utilisateurs).
Évolutions et forks du plugin
Le plugin pour GéoPicardie existe depuis plus de 10 ans. Il a été récupéré naturellement par Géo2France. Il a connu le passage à QGIS 3. Et, ces toutes dernières années, il a été forké de nombreuses fois : DataGrandEst, GéoBretagne, indigeo, CRAIG… La dernière plateforme à l’avoir repris à son compte est la RGD Savoie Mont Blanc.
Même si le plugin a été conçu pour être facilement adapté (juste une URL à changer dans son panneau de configuration), le fork a souvent été privilégié pour 2 raisons principales :
- pour donner au plugin une image qui correspond à la source de données : avoir un plugin nommé « Géo2France » pour accéder aux données de Nouvelle Aquitaine, ce n’est pas idéal en matière de communication…
- pour ajouter des fonctionnalités : recherche, authentification…
L’inconvénient majeur des forks réside dans la difficulté à les maintenir et à reverser leurs évolutions au projet initial. Cela a été d’autant plus difficile que la plupart des forks ont été réalisés de manière maladroite sans garder l’historique des commits et sans en informer les auteurs initiaux.
Et maintenant ?
Trop de forks, trop de code spécifique à droite et à gauche.
… il est temps de passer à autre chose, ou presque, pour essayer de mettre en place un projet plus fédérateur, exploitant au mieux les capacités de QGIS et donnant accès aux données de plusieurs plateformes depuis un même outil : le plugin IDG. Jetez-y un œil.
Un grand merci aux administrateurs des plateformes qui ont adopté cet outil et particulièrement aux contributeurs des projets suivants : plugin IDG, Layers menu from project et QGIS Plugin Templater.