Sortie de QGIS 2.14 LTR « Essen »

Le projet QGIS a l’immense plaisir de vous annoncer la publication de la version 2.14 de sa suite logicielle de Système d'Information Géographique (SIG) libre.

QGIS est une suite logicielle de traitement de l'information géographique. Elle permet de générer des cartes, d'analyser des données spatiales et de les publier, en ligne ou sur papier. Elle permet également de réaliser de nombreux traitements et algorithmes sur des données spatiales ou d'autres données liées. En d'autres termes, QGIS est un SIG ou Système d'Information Géographique, conçu pour recueillir, stocker, traiter, analyser, gérer et présenter tous les types de données spatiales et géographiques. C'est un projet officiel de la fondation Open Source Geospatial (OSGeo). Il est disponible sur les systèmes d'exploitation GNU/Linux, Mac OS X, Windows et Android.

La version 2.14 nommée « Essen » en hommage à la ville du même nom, est disponible depuis le 1er Mars 2016. Cette version est une "LTR", Long-Term-Release, et sera supportée pendant un an. Il s'agira de l'avant dernière version de la lignée 2.x, car il a été décidé de conserver une dernière version (2.16) qui sera suivie de la version 3.0. Depuis début avril 2016, une version 2.14.1 a été publiée. Elle corrige certains bugs de jeunesse de la version 2.14.

Dans la suite de la dépêche, un aperçu des nouveautés vous sera présenté plus en détails, ainsi que les plans actuels pour la future version 3. Pour le public non averti, nous vous invitons à lire le début de la dépêche sur la sortie de QGIS 2.10 pour avoir un petit rappel sur les SIG et sur QGIS…

Sommaire

• Les nouveautés d'intérêt de QGIS 2.14
  • Couches virtuelles
  • Moins de clics, plus d'efficacité
  • Contrôle de formulaire des ressources externes
  • Générateur de symbologie géométrique
  • Ordre de tracé des géométries
  • Moteur de rendu 2.5D
  • Amélioration de la gestion des unités
  • Modules v.net dans Processing
  • Métadonnées INSPIRE pour QGIS Server
• Et pour la version 2.16 ?
  • Syntaxe des étiquettes HTML
  • Intégration des algorithmes GRASS 7 dans QGIS
  • Refonte du fournisseur de données WFS
• Ce qu'on peut dire sur la version 3.0 de QGIS
  • Choix de la gouvernance du projet
  • Inclusions de Python3 et de Qt5
• Je veux aider le projet QGIS, que puis-je faire ?
• Conclusions

Les nouveautés d'intérêt de QGIS 2.14

Voici une petite sélection des nouveautés de la version 2.14 de QGIS. Si vous voulez découvrir l'intégralité des évolutions, nous vous invitons à consulter la page des changements en image qui est vraiment très complète et qui a l'avantage d'être traduite en français.

Couches virtuelles

Il s'agit d'un des points majeurs de la nouvelle version de QGIS. Pour faire simple, les couches virtuelles sont des vues dynamiques d'autres couches. Les vues sont des requêtes de sélection qui peuvent agir sur une ou plusieurs couches.

Grâce aux couches virtuelles, on peut maintenant disposer d'un système de vues dynamiques pour toutes les couches de type fichier, ce qui est une grande avancée. Le système de requête utilise la syntaxe de SQLite et les fonctions Spatialite pour la partie géographique. Elle permet donc de nombreux traitements, des résultats variés et ce même pour les formats qui ne gèrent pas de SQL. En plus de la syntaxe SQL, il est également possible d'utiliser le moteur d'expression de QGIS, ce qui enrichit encore plus le panel de fonctions.

Concrètement, vous pouvez créer une couche virtuelle en cliquant sur le bouton concerné. Une boîte de dialogue s'ouvre pour vous permettre de préciser le contenu de la requête, en fonction des couches qui sont actuellement ouvertes dans le projet QGIS. Tout changement dans les couches sources sera automatiquement et immédiatement répercuté dans la couche virtuelle. Ce mécanisme s'approche de celui de MapInfo avec son requêteur SQL interne.

Pour terminer sur le sujet, retenez qu'on peut également exécuter des requêtes SQL virtuelles sous forme de géotraitements, grâce à l'outil Executer SQL, présent dans le fournisseur de traitements QGIS.

Voici une capture d'écran représentant la fenêtre permettant de créer une couche virtuelle :

Moins de clics, plus d'efficacité

Du point de vue de l'utilisateur, la version 2.14 de QGIS amène un grand nombre de nouvelles fonctionnalités qui facilitent l'utilisation au quotidien de QGIS. Avec le temps, QGIS fait de plus en plus de choses et même si des efforts sont faits pour conserver une ergonomie utile et cohérente, certaines opérations impliquent d'ouvrir plusieurs fenêtres, ne serait-ce que pour accéder aux éléments de configuration. Il en résulte un parcours d'accès qui peut être parfois assez contraignant pour changer quelques éléments simples.

Dans QGIS 2.14, quelques corrections permettent néanmoins d'aller beaucoup plus vite pour certaines opérations. C'est ce que nous allons voir en détails dans les points qui suivent.

D'abord, on peut maintenant changer la couleur d'une classe directement depuis la légende (l'arbre des couches), sans devoir passer par l'onglet Style des propriétés de la couche. Un simple clic-droit sur la classe concernée ouvre un menu contenant un sélecteur de couleur permettant de choisir directement la couleur concernée (cf illustration suivante). Difficile de faire plus direct !

Ça n'a l'air de rien, mais c'est au moins 5 clics de souris en moins et deux boîtes de dialogue en moins ! C'est également une méthode plus interactive pour voir directement sur la carte ce qu'un changement de couleur peut avoir sur une classe. Le sélecteur de couleur fonctionne aussi pour les styles gradués.

On peut également avoir accès directement à un éditeur de symbole complet depuis la classe d'une couche, dans la légende. Cela permet de modifier plus que la couleur du symbole, dans une boîte de dialogue dédiée. Pour y avoir accès, il suffit de double-cliquer sur le symbole ou de faire un clic-droit suivi de Modifier le symbole.... Auparavant (cette méthode d'accès reste valide), il fallait aller dans les propriétés de la couche, onglet style et double-cliquer sur le symbole qu'on souhaitait modifier. Cet accès rapide permet également d'avoir une meilleure interaction avec la représentation sur la carte, à l'issue du changement du symbole.

Toujours sur les classes, il est possible de désactiver/activer toutes les classes d'une couche en une seule opération. Il suffit de se placer dans une classe et de faire un clic-droit pour avoir l'accès à cette fonctionnalité directement depuis le menu contextuel. L'interêt est ici de pouvoir désactiver toutes les classes pour pouvoir facilement en activer une seule ou quelques-unes. Auparavant, il fallait décocher une à une toutes les classes ce qui était très fastidieux pour les couches avec de nombreuses classes. Bien entendu, cela fonctionne également pour les classes des styles gradués.

Au niveau du gestionnaire de compositions (les mises en page destinées à être imprimées ou exportées en PDF), on peut maintenant en supprimer ou en ouvrir plusieurs. C'est également quelques clics d'économisés.

Enfin, il est possible de charger un projet directement depuis le panneau d'exploration de QGIS. Cela permet de passer d'un projet à l'autre sans se fatiguer.

Contrôle de formulaire des ressources externes

Un nouveau contrôle de formulaire vient de faire son apparition. Il concerne principalement les fichiers et vise à remplacer les contrôles déjà existants de sélection de fichiers et d'affichage d'image même si ces deux contrôles ont été conservés.

Dans QGIS, les contrôles de formulaire sont les éléments qui permettent de personnaliser le formulaire de saisie des attributs. À chaque fois que vous créez un objet géographique dans QGIS, ce dernier vous propose de saisir directement ses attributs via le formulaire. C'est une fonctionnalité très intéressante qui permet de relier facilement géométrie et champs d'information. Sur ce point, QGIS est un des SIG les plus avancés, notamment par la richesse des contrôles proposés.

Le contrôle resource externe permet aux champs qui contiennent des liens vers des fichiers d'être mieux gérés. D'abord, on peut maintenant indiquer un ou plusieurs filtres de fichiers pour encadrer la saisie. Par exemple, vous ne voulez ajouter dans un champ que des liens vers des fichiers PDF. Le contrôle resource externe le permet. Il emprunte la syntaxe de filtre à Qt.

Par ailleurs, il permet de paramétrer un chemin par défaut. C'est très utile lorsqu'on sait que tous les fichiers à référencer sont situés dans des répertoires présents sous une racine commune : l'utilisateur a moins de clics à faire pour trouver son fichier. Le stockage des chemins de fichier dans le champ peut être fait en mode relatif (on ne stocke que ce qui est nécessaire), à partir du chemin par défaut ou du chemin du fichier de projet. C'est intéressant lorsqu'on souhaite enregistrer des noms de fichier dans des champs avec un nombre de caractères limités (les fichiers Shape ne permettent que des champs de moins de 255 caractères de long).

Parmi les nombreuses améliorations apportées par ce contrôle, on peut maintenant présenter les chemins vers les fichiers sous forme de liens cliquables. Cela permet de pouvoir ouvrir le fichier directement depuis QGIS. Voilà de quoi faciliter la vie des utilisateurs qui n'auront plus besoin de faire un copier/coller du chemin pour ouvrir le fichier.

Enfin, les pages HTML et les images peuvent directement être affichées depuis l'interface de QGIS grâce à un visualiseur interne.

Voici un exemple d'affichage sous forme de lien :

Générateur de symbologie géométrique

Comme chaque nouvelle version de QGIS, la version 2.14 amène de nouvelles fonctions dans le moteur d'expression. Pour rappel, ce moteur d'expression permet de manipuler l'ensemble des données attributaires d'une couche, ligne à ligne pour constituer un résultat final. On peut par exemple extraire le premier mot d'un champ contenant du texte. Vous pouvez utiliser le moteur d'expression dès qu'une variable peut être gérée par les données.

Depuis quelques versions (2.12 et 2.14), QGIS dispose d'un grand nombre de fonctions d'expression qui travaillent sur la géométrie. On peut donc utiliser ces dernières pour extraire et modifier des géométries. C'est cet élément qui est utilisé dans le générateur de symbologie. Ce dernier gère les derniers niveaux de couche de symbole (là où on trouve les styles de base comme le remplissage simple, la ligne simple, le motif de points, etc.).

L'intérêt majeur de cette nouvelle fonctionnalité est de pouvoir modifier à la volée la géométrie d'une couche sans toucher aux données source. On peut y avoir accès dans n'importe quel moteur de rendu (symbole unique/gradué/catégorisé/basé sur des règles), via une couche de symbole, dans l'arbre des symboles qui permet de créer le style de représentation des objets de la couche. Il suffit de choisir une couche basse et de changer son type (type de symbole) et choisir Générateur de géométrie.

À partir de ce moment, vous avez accès à une boîte de dialogue d'expression (contenant $geometry par défaut, ce qui renvoie la géométrie de chaque objet) et vous pouvez renseigner une expression générant de la géométrie. Pour ajouter un tampon de 0,5 mètre, utilisez buffer($geometry, 0.5). Comme le générateur de géométrie se situe au niveau des couches de base de symbologie, on peut bien entendu ajouter d'autres couches ce qui donne des représentations uniques quasi-infinies.

Quelques exemples d'utilisation :

• J'ai une couche de polygones qui est souvent modifiée et je souhaite systématiquement afficher un tampon de 2m autour des polygones. La couche n'est pas dans une base de données (et je ne peux pas utiliser une vue dans le SGBDRS). Pas de problème, il suffit d'utiliser le générateur avec une expression de type buffer.
• Je souhaite faire une anamorphose négative (réduisant la surface d'un polygone) variable selon la valeur d'un champ, j'ai juste à employer la fonction buffer avec un résultat négatif issu d'un champ (ou d'une formule).
• Je veux intégrer un motif pour la bordure de mes polygones. La seule solution consiste à créer une géométrie surfacique à partir de ma bordure en faisant la différence entre deux tampons de la géométrie de départ. L'expression sera du type: difference( buffer( $geometry , 250 ), buffer( $geometry, -250 ) ). Ensuite, il suffit d'appliquer un motif de lignes ou de points et le tour est joué !

Bien entendu, il ne s'agit que de visualisation : la donnée source n'est jamais modifiée. QGIS est l'un des seuls logiciels de SIG à permettre ces manipulations directement lors du rendu, de manière dynamique, tout en tenant compte des classes. C'est un grand pas en avant en matière de rendu cartographique. Cette fonctionnalité reste également intéressante pour les SGBDRS car si ces derniers peuvent modifier des géométries à la volée, il est fort probable qu'ils ne puissent pas tenir la charge d'un grand nombre de connexions qui feraient appel à des fonctions de génération de géométrie dynamique. À l'inverse, QGIS permet de déporter le travail sur le client SIG.

Ordre de tracé des géométries

Il arrive parfois qu'une couche contienne des objets qui se superposent. Oui, ce n'est pas une bonne pratique SIG mais ça arrive. Dans ce cas de figure, comment gérer l'affichage correctement ? QGIS 2.14 dispose d'une fonctionnalité permettant de gérer ce problème assez facilement. Il suffit d'utiliser une expression pour gérer un index Z. Ce paramètre intitulé « Contrôle de l'ordre de rendu des entités » est disponible dans le bas de l'onglet style.

Il permet de renseigner une ou plusieurs expressions pour gérer l'ordre d'affichage des géométries d'une même couche. Chaque expression permet de gérer un ordre de classement. On peut donc avoir plusieurs champs qui permettent le classement. Cela permet des combinaisons de tri quasiment infinies et finalement, assez simple à renseigner.

Moteur de rendu 2.5D

Issu d'un financement collectif (plusieurs collectivités européennes), le moteur de rendu 2.5D permet la simulation de la 3D dans QGIS. On parle de simulation car QGIS ne dispose pas (encore) de module de rendu en 3D qui utiliserait les fonctions 3D des cartes graphiques. C'est donc le moteur de rendu classique qui est utilisé pour déformer les polygones initiaux en objets à l'apparence 3D.

Pour y parvenir, on utilise le générateur de symbologie géométrique (décrit plus haut dans cette dépêche) pour créer les géométries supplémentaires de l'extrusion en hauteur du polygone, pour créer le toit ainsi que l'ombre portée. Bien entendu, on peut faire varier la hauteur selon une expression. Voici à quoi ressemble l'interface qui permet de le créer :

En fait, le moteur de rendu 2.5D n'est pas un véritable moteur de rendu à part entière. L'interface présentée est plus un assistant qui se charge de créer un style de symbole unique qui s'articule autour de 3 symbologies générées (toit, mur, ombre). Pour s'en rendre compte, il suffit de configurer le moteur 2.5D puis de basculer vers le moteur de rendu Symbole unique. Vous pourrez alors voir et étudier les 3 styles imbriqués :

Une des limites de ce mode de fonctionnement est que ce rendu peut être assez consommateur de ressources machine (temps CPU) car contrairement à un symbole simple, QGIS va générer en interne toutes les géométries supplémentaires (3 géométries) ce qui prend forcément plus de temps que de générer un simple polygone. Encore une fois, même si le moteur de rendu de QGIS travaille sur plusieurs fils d'exécution (multi-thread), il ne tire pas parti de l'accélération des cartes 3D (mais les autres SIG bureautique ne le font pas non plus).

Néanmoins, ce mode de fonctionnement par exploitation du moteur 2D classique de QGIS a quand même un avantage majeur : vous pouvez utiliser les moteurs de rendus gradués, catégorisés par un ensemble de règles pour représenter des éléments en 2.5D avec des styles différents, avec des classes différentes. Il vous suffit de basculer dans un de ces modes pour avoir accès aux éléments de configuration habituels mais qui porteront sur une symbologie générée. Donc, pas besoin de retenir les expressions de génération 3D, QGIS s'en occupe pour vous.

Voici un exemple de rendu de bâtiments en 3D par QGIS 2.14 avec des hauteurs différentes selon les bâtiments et une classification de ces derniers par la couleur :

Amélioration de la gestion des unités

C'est une petite évolution mais qui a un intérêt important : QGIS 2.14 gère mieux les unités, du moins de manière plus homogène. Auparavant, chaque outil avait plus ou moins son système d'unité indépendant. Un travail de refactorisation a été entrepris pour corriger ce point.

D'abord, la gestion des unités et de la représentation des coordonnées a été relocalisée dans les propriétés du projet. Ensuite, de nouvelles unités ont fait leur apparition (comme par exemple les hectares pour les mesures de surface) aussi bien pour les mesures de longueur, de surface ou angulaires. Les fonctions d'expression de calcul de longueur, de surface et d'angle renvoient le résultat selon l'unité indiquée dans les paramètres du projet. Enfin, l'affichage des coordonnées dans les différents endroits de QGIS est maintenant unifié et on peut indiquer le nombre de décimales utilisées.

Modules v.net dans Processing

Processing est le module des géotraitements de QGIS. Il propose un ensemble de traitements qui reposent sur les fonctions de QGIS mais également sur d'autres SIG ou d'autres outils SIG tels que GRASS, SAGA, GDAL, Orfeo, etc. L'intégration de ces outils externes est une vrai avancée car cela évite de recréer des algorithmes ou des traitements qui sont déjà éprouvés dans d'autres logiciels. D'un point de vue de développeur, cela permet aussi d'intégrer beaucoup plus de traitements sans devoir ré-implémenter du code pour reproduire ces algorithmes. QGIS 2.14 propose donc environ 300 traitements si on inclue GRASS et GDAL et plus de 500 traitements si on ajoute SAGA.

En ce qui concerne les différents types de traitements disponibles, il manquait de quoi travailler sur des réseaux et de graphes. GRASS propose de nombreux algorithmes travaillant sur ce type de données, via un ensemble de traitements regroupés sous le module v.net. Ces traitements fonctionnent sur des couches linéaires de réseau (ou de graphe) qui sont des couches linéaires où les segments sont interconnectés entre eux par un seul point (un noeud) et ne s'entrecroisent pas.

QGIS 2.14 donne accès à l'ensemble des traitements v.net de GRASS via Processing. Vous aurez besoin de la version 7 de GRASS d'installée sur votre station de travail, en sachant que c'est la version qui est déployée dans l'installeur pour MS-Windows de QGIS. Pour les utiliser, rien de plus simple : il suffit de disposer d'une couche linéaire de réseau et d'une (ou plusieurs ou pas du tout suivant le traitement employé) couche de points puis de choisir votre traitement dans l'arbre de la boîte à outils de traitements. Ils sont situés dans les commandes GRASS 7, dans la partie Vecteur.

Vous pourrez ainsi réaliser des cartes isochrones, des cartes de répartition de secteur, résoudre les problèmes du voyageur de commerce, calculer les chemins les plus courts entre deux séries de points, etc.

Métadonnées INSPIRE pour QGIS Server

Si QGIS Desktop est souvent mis en avant, QGIS Server continue à évoluer. Ainsi, il peut maintenant renvoyer des métadonnées INSPIRE aux clients WMS et WFS. Attention, toute la norme INSPIRE n'est pas gérée par QGIS. En effet, vous pouvez pour l'instant juste indiquer la langue officielle du service (parmi les 24 langues de l'union européenne) ainsi qu'indiquer une URL permettant l'accès à une fiche de métadonnées externe ou alors les dates de mise à jour des métadonnées.

Ces éléments se configurent dans la partie OWS des paramètres du projet.

Et pour la version 2.16 ?

La phase de développement n'a débuté que depuis un mois mais certaines nouvelles fonctionnalités sont déjà apparues dans quelques pull-requests ou quelques commits. Voici quelques éléments d'intérêt qui devraient intégrer la prochaine version (2.16 de QGIS).

Syntaxe des étiquettes HTML

C'était une grande demande de la part des utilisateurs et un des derniers points du moteur d'étiquettes à revoir, mais c'est en bonne voie d'intégration. Dans la version 2.16 de QGIS, il sera possible de bénéficier d'une syntaxe de style pour les étiquettes. L'intérêt immédiat de ce point est de permettre de styler indépendemment chaque partie de la chaîne de caractères qui compose l'étiquette.

Ainsi, si votre étiquette est composée de plusieurs mots, vous pourrez mettre le premier en gras et en couleur alors que le second sera simplement en noir. La syntaxe des styles d'étiquettes permet d'utiliser le moteur d'expression de QGIS ce qui donne des combinaisons très étendues, voire quasi infinies (on peut concaténer plusieurs champs, changer de style si la valeur d'un champ est supérieur à une valeur).

Cette fonctionnalité devrait permettre plus de richesse dans l'affichage des étiquettes, ne serait-ce que pour changer la couleur d'une étiquette composée de plusieurs mots, ce qui est un cas d'utilisation finalement assez fréquent et qui manquait dans QGIS.

Voici le lien vers la pull-request pour les plus curieux. Et une petite image d'aperçu de ce que ça pourrait donner :

Intégration des algorithmes GRASS 7 dans QGIS

Dans la version 2.14 de QGIS, les géotraitements (appelés aussi algorithmes) v.net de GRASS7 ont été intégrés. Avec eux, a été introduit un mécanisme de code permettant de gérer les traitements de GRASS qui implique des vérifications et des pré-traitements amonts avant que GRASS puisse les dérouler correctement. Ainsi, potentiellement, tous les traitements GRASS sont maintenant intégrables dans Processing.

Ne reste plus qu'à tous les intégrer et c'est en partie réalisé. L'objectif est ici de disposer de tous les algorithmes de GRASS7 directement dans QGIS, sans passer par l'extension GRASS. Pour l'instant, tous les modules raster (r.*) et vecteurs (v.*) ont été intégrés. Il reste les modules dédiés aux traitements sur image satellite (i.*) mais on peut espérer que ces derniers soient publiés avant la phase de gel des nouvelles fonctionnalités (qui commence dans 2 mois).

Refonte du fournisseur de données WFS

Ce commit (ainsi que ceux qui vont suivre) améliore grandement le fournisseur de données WFS. Pour les néophytes, WFS est un service web permettant de transmettre des données vectorielles à un client. C'est un standard de l'OGC qui permet de télécharger à la volée des données vecteur depuis un serveur gérant ce protocole via HTTP. Jusqu'à présent, QGIS avait connu peu d'évolution sur le client WFS interne actuel. Il existait également une extension qui permettait la gestion de la version 2.0 de ce protocole mais elle n'était pas intégrée dans le cœur du projet.

C'est donc maintenant chose faîte avec les fonctionnalités suivantes :

• Support des protocoles WFS 1.0, 1.1 et 2.0 (toute la norme n'est pas implémentée).
• Auto-détection du protocole (évite au client de paramétrer tout ça à la main).
• Implémentation d'un cache d'entités pour gérer les couches volumineuses.
• Des tests unitaires pour tout ça bien sûr !

Ce qu'on peut dire sur la version 3.0 de QGIS

Choix de la gouvernance du projet

QGIS dispose d'un comité de projet. Ce dernier prend des décisions majeures sur l'orientation de QGIS. Depuis quelques versions maintenant, on parle de la future version 3.0 de QGIS qui devrait permettre de casser la compatibilité avec la branche 2.x tout en améliorant les fonctionnalités. En effet, un certain nombre de nouveautés impliquent de modifier fortement les API pour être implémentées et QGIS essaye de ne rien casser dans la branche 2.x.

Le PSC a donc pris une résolution générale qu'on peut résumer aux conclusions suivantes:

• Le développement de QGIS v3.0 se fera dans une branche dédiée.
• Cette branche accueillera les évolutions techniques qui s'imposent : migration vers Qt5, utilisation de PyQt5 et passage à Python3.
• La publication de la version 3.0 de QGIS utilisera le mode de publication : « ça sortira quand ce sera prêt ! ».
• Le développement « traditionnel » continue dans la branche 2.x qui conserve son cycle de publication par objectif de temps.
• Il y aura une version 2.16.

Le mot d'ordre est d'essayer de commencer dès maintenant à coder dans la branche 3.x les nouvelles fonctionnalités impossibles à intégrer dans la branche 2.x. Le fait de laisser une version 2.16 permet de continuer à faire évoluer QGIS sur les points qui n'ont pas besoin d'un saut technologique majeur tout en permettant de se laisser du temps pour faire une migration propre (qui marche) vers Qt5/Python3.

Inclusions de Python3 et de Qt5

Depuis quelques semaines maintenant, Python3 et Qt5 sont de la partie dans QGIS. Pour l'instant, ils ne permettent pas de disposer de l'ensemble des fonctionnalités de QGIS avec ces composants techniques mais on peut maintenant dire que l'infrastructure est là.
Il y a pas mal de commits pour effectuer des corrections (notamment les choses qui coincent avec Python3) et on peut dès maintenant compiler QGIS avec Qt5 ainsi qu'intégrer Python3).

Par ailleurs, QGIS utilise Travis-Ci pour effectuer son intégration continue et des évolutions permettent maintenant de compiler (et tester) automatiquement des builds avec Qt5. Tout ça prend une bonne direction même s'il reste du chemin à parcourir tant les fonctionnalités à tester sont nombreuses.

Je veux aider le projet QGIS, que puis-je faire ?

Passons maintenant au moment propagande… QGIS n'est plus depuis quelques années un logiciel libre développé dans son coin par quelques développeurs disparates. Le nombre de sponsors peut donner quelques pistes sur le sérieux du développement de QGIS. Ainsi, pour la version 2.14, on peut compter plus de 31 sponsors cités, ce qui est loin d'être négligeable. Néanmoins, QGIS reste un projet ouvert où tout le monde peut participer. Si vous consultez le bugtracker, vous vous rendrez-compte assez facilement qu'il reste beaucoup de place pour améliorer QGIS : il reste 1300 bugs à corriger et 1300 demandes d'évolution à implémenter. Ce chiffre est d'ailleurs en stagnation depuis au moins 6 mois, ce qui montre que même si des bugs sont corrigés et des nouvelles fonctionnalités amenées dans QGIS, il y a vraiment besoin de ressources pour continuer à améliorer le projet.

Selon votre profil, vous pouvez nous rejoindre sur les points qui suivent:

• Je suis développeur C+/Qt : c'est parfait, venez nous aider à améliorer le code et les algorithmes internes de QGIS. Le développement se déroule sur GitHub et n'oubliez pas de lire la documentation de développement.
• Je suis développeur Python : c'est très bien, QGIS regorge de modules Python et d'extensions internes codées dans ce langage. Par exemple, venez nous aider à corriger les bugs de Processing, cela permettra de répondre aux besoins des utilisateurs de géotraitements. À ce propos, vous pouvez également nous aider sur la création des tests unitaires pour Processing qui ont été publiés avec QGIS 2.14. Sinon, vous pouvez travailler également sur le module DB Manager qui vous permettra de proposer de meilleurs services aux utilisateurs SIG avancés qui veulent faire des requêtes ou gérer leurs bases de données.
• Je suis un utilisateur courant de QGIS : même si vous ne savez pas coder, vous pouvez facilement nous aider. Pour commencer, retenez que nous avons besoin de réaliser des tests approfondis lors de la phase de gel des fonctionnalités qui commence au bout de 3 mois de développement. À ce stade, les nouvelles fonctionnalités doivent être fortement testées avant que nous puissions publier la future version de production. Par ailleurs, il faudra également veiller à ce que ces nouvelles fonctionnalités ne cassent pas quelque-chose qui fonctionnait auparavant. Et pour cet ensemble de tests, rien ne vaut les vraies données, basées sur des cas concrets. Il vous faudra installer les versions compilées toutes les nuits et travailler sur vos données habituelles tout en faisant remonter tout problème via le bugtracker. Plus nous aurons d'utilisateurs pendant cette phase, moins il y aura de problèmes dans la publication de la nouvelle version (nous ne serons donc pas forcément obligés de publier une version corrective en un mois après la sortie de la nouvelle version). Votre rôle ici est très important car les développeurs n'ont forcément que des jeux de tests limités et ils sont concentrés sur la résolution de bugs pendant cette phase qui dure un seul mois. Merci pour votre implication dans les tests. Si vous avez de l'expérience métier, vous pouvez aider les utilisateurs QGIS qui posent des questions, notamment sur StackOverFlow.
• Je suis bon en anglais technique (SIG et/ou informatique) : venez rejoindre l'équipe de traduction de QGIS. Nous sommes nombreux à être inscrits mais nous avons toujours besoin de forces vives pour faire en sorte que QGIS Desktop soit toujours 100 % traduit en français ou que le site web et la documentation restent à jour par rapport à la version en langue anglaise. Ceci est particulièrement vrai lors de la phase de gel des fonctionnalités. Les nouvelles fonctionnalités amènent souvent de la documentation interne ou des chaînes de caractères à traduire. Il faut de plus rester sur le qui-vive pendant toute cette phase car des modifications de texte peuvent intervenir même quelques heures avant la compilation finale. Il serait en effet bon d'atteindre régulièrement les 100 % de traduction de l'application bureautique (ce qui permet de dire à la communauté que QGIS est complètement traduit en français). Mais une fois que la version officielle est compilée et distribuée, il nous faut également beaucoup d'aide pour traduire correctement la page web des changements en image. Cette page est très importante pour les utilisateurs francophones de QGIS car elle permet de leur présenter toutes les nouvelles fonctionnalités dans leur langue maternelle, ce qui leur permet d'avoir une information plus claire sur ce que le nouveau QGIS peut leur apporter. Plus nous serons nombreux à être des traducteurs actifs, plus le travail lourd et fastidieux de traduction sera réparti et plus QGIS sera facilement traduit.

Dans tous les cas, nous saluerons vos contributions par un grand merci et vous pourrez apporter votre pierre à l'édifice QGIS !

Conclusions

Encore une fois, QGIS respecte son rythme soutenu d'intégration de nouvelles fonctionnalités, en continuant à sortir une nouvelle version tous les 4 mois, ce qui est d'autant mieux pour les utilisateurs.

Sur la partie bureautique, on peut maintenant dire que le niveau de QGIS est assez proche des meilleurs outils SIG non libres disponibles sur le marché. Le moteur de rendu est l'un des plus avancés en ce qui concerne les fonctionnalités cartographiques et ses performances sont d'un très bon niveau comparativement à ce qu'on peut trouver pour d'autres logiciels de ce type. Le générateur de symbologie géométrique est une fonctionnalité qui n'existe pas ailleurs. Le moteur d'étiquette continue également à s'améliorer avec le temps. QGIS offre de plus en plus de géotraitements qui permettent de manipuler beaucoup plus facilement les données, même avec des requêtes complexes.

Pourtant, il reste toujours des défis techniques à gérer, notamment, le passage à Qt5 et à Python3. On peut constater (dans le code, il n'y a que ça de vrai) que les développeurs principaux du projet y investissent pas mal de temps et c'est tant mieux pour l'avenir. Avec 191 contributeurs recensés sur GitHub, l'équipe de développement s'étoffe, ce qui montre une certaine forme de vitalité pour le projet.

Souhaitez-nous de construire une excellente version 3.0, en attendant de vous retrouver pour la sortie de QGIS 2.16 dans 3 mois…

Aller plus loin

• Site principal de QGIS (840 clics)
• Page de téléchargement du projet QGIS (234 clics)
• Principales évolutions en images depuis la dernière version (229 clics)
• Dépôt git officiel des sources de QGIS (108 clics)