Sortie de QGIS 2.12 "Lyon"

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.

La version 2.12 nommée « Lyon » en hommage à la ville du même nom, est disponible depuis le 26 octobre 2015.

Dans la suite de la dépêche, un aperçu des nouveautés vous sera présenté plus en détails ainsi qu'une esquisse des développements à venir. Pour le public non averti, je vous invite à 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

• Présentation
• Nouveautés par rapport à la dernière version
  • Système d'authentification
  • Affichage stylisé des cellules des tables attributaires
  •  Éditeur avancé de paramètres
  • Améliorations de DBManager
    • Export vers d'autres formats de fichiers depuis DBManager
    • Gestion d'Oracle Spatial
    • Import des entités sélectionnées dans DBManager
    • Fenêtre de requête en onglet
  • Plugin de vérification géométrique
  • Améliorations des outils d'édition de données
    • Création de polylignes circulaires
    • Table de nœuds
  • Interface utilisateur
    • Nouvel écran d'accueil
    • Gestion des thèmes d'interface utilisateur
  • Nouvelles fonctions dans les expressions
  • Étiquettes
    • Amélioration du moteur d'étiquettes
    • Étiquettes basées sur des règles
    • Affichage sélectif des étiquettes
• Pour l'avenir
  • Rythme des publications de version
  • Passage à Qt5 et Python3
  • Améliorations du pilote PostgreSQL
  •  Évolution des accès réseau
  • Modification de l'interface de création de fonctions d'expressions
• Conclusions

Présentation

QGIS est un SIG convivial distribué sous licence publique générale GNU. 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 et intègre de nombreux formats vecteur, raster, base de données et fonctionnalités.

QGIS est développé en C++ avec la bibliothèque Qt (en version 4 pour le moment). Son architecture lui permet également d'utiliser des extensions codées en Python (version 2) et la très grande majorité des classes du cadriciel de QGIS sont disponibles sous Python.

QGIS est une des applications majeures qui utilisent Qt. Actuellement, l'arborescence des sources (tout confondu) occupe près de 350 Mo. Les contributeurs recensés sur GitHub sont au nombre de 169.

Par ailleurs QGIS s'interface avec de nombreux autres logiciels, que ce soit des bases de données spatiales comme PostgreSQL/PostGIS ou Oracle Spatial, mais également avec un grand nombre de logiciels de SIG libres comme GRASS, SAGA ou encore Orfeo.

Même s'il reste un logiciel libre, QGIS assure en grande partie le financement de son développement via des sponsors divers qui vont d'entreprises ayant besoin de SIG comme des compagnies aériennes à des organisations gouvernementales (y compris le gouvernement français) en passant par des universités et également des particuliers.

Nouveautés par rapport à la dernière version

Système d'authentification

Jusqu'à présent, QGIS avait une gestion trop simple de l'authentification. Il était possible de conserver les mots de passe de connexion aux serveurs (SGBDRS comme PostGIS ou Oracle Spatial, ou aux serveurs web WMS/WFS) dans les paramètres de connexion, stockés en clair dans le fichier de projet ou dans la configuration globale de QGIS. Effectivement, cette situation qui dure depuis des années était loin d'être satisfaisante pour les utilisateurs travaillant avec des services imposant une authentification.

En effet, dans ces environnements, les utilisateurs doivent souvent se connecter à des bases de données ou des services web avec des comptes différents. Dans ce genre de situation, la tentation est de cocher la case "Enregistrer le mot de passe" pour éviter de s'authentifier toutes les 2 minutes. Cette pratique pose des vrais problèmes de sécurité et la seule solution était de transmettre la gestion des mots de passe à d'autres logiciels (comme Keepass par exemple).

Avec QGIS 2.12, le problème est en partie réglé avec une première intégration d'un système d'authentification qui permet de garantir un minimum de sécurité au sein de QGIS. Pour faire simple, ce système est proche en termes de fonctionnement de celui de Firefox/Iceweasel qui repose sur un mot de passe principal qui protège les autres.

En termes d'implémentation, une base de données locale d'authentification est utilisée (au format SQLite) et toute la gestion du chiffrement repose sur la bibliothèque Qt Cryptographic Architecture pour la partie bas niveau. Des classes spécifiques pour QGIS ont été également implémentées pour faciliter la gestion de l'authentification. Ces dernières sont également disponibles sous Python et permettent aux extensions de QGIS d'en bénéficier.

Pour faciliter le développement, le système d'authentification de QGIS est développé de manière modulaire. La base de l'architecture est déployée dans la version 2.12 et elle est accompagnée de quatres modules d'authentification. Ce développement modulaire permettra d'ajouter de nouvelles méthodes d'authentification, en fonction des besoins et des évolutions. Pour l'instant, les deux modules sont les suivants:

• Le module "basic" gère l'authentification de base sous forme identifiant/mot de passe/domaine. Ce module est disponible pour les connecteurs PostgreSQL et OWS (WMS, WFS, WCS). Pour ce module, l'utilisateur enregistre son identifiant, le mot de passe et un domaine de connexion (si utile). Avec ces informations il est effectivement possible de se connecter à une base de données PostgreSQL et à des services web OGC.
• trois modules d'authentification via IGC (plusieurs méthodes d'identification par certificat ou de stockage des certificats). Ces modules permettent d'attaquer les services Web OGC qui reposent sur les mécanismes d'authentification d'HTTP, utilisant les certificats. Pour ces modules, QGIS propose de stocker les certificats directement dans la base d'authentification SQLite, protégée par le mot de passe principal.

Attention, cette nouvelle architecture d'authentification cohabite avec l'ancienne. Concrètement, il faut que la gestion du pilote de donnée intègre les nouvelles méthodes d'authentification (ainsi qu'un moyen graphique de choix de l'authentification). Voilà pourquoi, seuls les pilotes de données PostgreSQL et OWS utilisent cette nouvelle solution d'authentification. Dans les prochaines versions de QGIS, d'autres pilotes de données devraient suivre (il reste Oracle Spatial, MySQL, MS-SQL server, etc.).

Il est donc fort probable que ce premier travail d'incorporation se poursuive dans les futures versions de QGIS et que cette nouvelle solution d'authentification rencontre des bugs ou des failles de sécurité. Néanmoins, cette nouvelle fonctionnalité est un travail d'intérêt qui peut fortement améliorer la partie sécurité de QGIS quand on sait à quel point les logiciels de SIG bureautiques sont souvent à la traîne sur le sujet. Pour l'instant, en plus des interfaces des connecteurs, tout se déroule dans les paramètres de QGIS avec un nouvel onglet dédié à l'authentification:

Affichage stylisé des cellules des tables attributaires

Comme déjà abordé dans la dépêche précédente, il est maintenant possible d'affecter des styles aux cellules de la table attributaire. Cette dernière permet de consulter, de trier, de modifier et de faire des calculs/traitements sur les données alphanumériques d'une couche.

Pour faire simple, il existe maintenant un nouveau panneau (masqué par défaut) dans la table d'attributs qui permet de créer des règles d'affichage. Ces règles permettent de gérer la couleur de fond, la police de caractère (et tout ce qui va avec comme la couleur, la taille, le type de police, etc.) ainsi que de permettre d'afficher une icône dans la cellule. Les règles s'appliquent en fonction du contenu de chaque cellule et elles utilisent le système d'expression de QGIS ce qui permet une grande variété de traitements. Il est possible de créer des règles qui s'appliquent à toutes les lignes et des règles qui s'appliquent uniquement sur une seule colonne.

Les règles sont établies pour une couche et elles sont stockées dans le fichier de projet QGIS (le fichier qui contient tous les paramètres de votre "document" QGIS). Elles s'appliquent donc dès l'ouverture du fichier de projet. Comme ces règles sont dynamiques, si vos données ont été modifiées (par exemple, si elles proviennent d'une table d'un SGBDRS très souvent mise à jour), le style s'appliquera aux nouvelles valeurs.

A quoi peut bien servir cette fonctionnalité ? L'intérêt le plus immédiat est sans doute de commencer à mettre en place une brique permettant d'améliorer l'aspect visuel de la table attributaire qui, il faut bien le reconnaître est assez peu accueillante même si elle reste vraiment très fonctionnelle. L'autre point qui vient naturellement est que cette fonctionnalité permet de repérer plus facilement les valeurs qui dépassent ou qui franchissent un seuil, et ce, d'un simple coup d’œil. Pour certaines utilisations, c'est vraiment très pratique.

 Éditeur avancé de paramètres

Cet éditeur est un peu le about:config de Firefox/Iceweasel. Concrètement, QGIS stocke ses paramètres internes dans le mécanisme des QSettings de Qt.
Avec l'éditeur de paramètres, il est possible d'attaquer tous les paramètres internes de QGIS via une interface graphique. Bien entendu, ces manipulations peuvent entraîner un comportement modifié de QGIS ou encore, vous pouvez perdre certaines configurations (celle des configurations vers les bases de données spatiales par exemple). L'éditeur est assez simple pour le moment: pas de recherche de valeur ou de clef pour l'instant. Son intérêt est de pouvoir modifier le comportement de QGIS sans devoir modifier des fichiers de configuration ou des bases de registre.

Améliorations de DBManager

Export vers d'autres formats de fichiers depuis DBManager

Jusqu'à présent, lorsque vous faisiez une requête (géographique ou attributaire) sous DBManager (le gestionnaire/requêteur de bases de données Spatiale aux formats PostGIS/Spatialite/Oracle Spatial), vous ne pouviez exporter vos résultats que directement dans QGIS ou vers un fichier externe forcément au format SHP (ShapeFile, format propriétaire d'ESRI et un des standards de fait de fichiers géographiques). Avec la version 2.12 de QGIS, on peut maintenant choisir un autre format parmi ceux qui sont gérés par la bibliothèque OGR (qui gère un nombre de formats assez conséquent).

QGIS sait bien entendu ouvrir tout fichier géré par OGR depuis des lustres mais cette fonctionnalité permet de moins dépendre du format pivot SHP et de supprimer la majorité du travail de conversion postérieure lorsqu'on souhaite extraire le résultat d'une requête créée avec DBManager.

Gestion d'Oracle Spatial

Comme annoncé dans la dernière dépêche, DBManager gère maintenant les connexions Oracle. Vous pouvez donc réaliser facilement des requêtes spatiales ou attributaires sur une base de données Oracle. Cette fonctionnalité permet également d'amener un outil de gestion directement intégré à QGIS pour les bases de données Oracle. Vous pouvez en effet créer des tables (si vous avez les droits qui vont bien naturellement), modifier certains champs.

Cette fonctionnalité gère les vues et les vues matérialisées: pour ces "tables" un peu spéciales, des informations supplémentaires sont affichées, notamment la définition de la vue/vue matérialisée ce qui peut être utile en cas de débogage. Vous pouvez également rafraîchir vos vues matérialisées (si vous en avez le droit) directement depuis QGIS (table par table via l'interface graphique ou via une requête SQL). Vous pouvez également définir ou supprimer des index ainsi que mettre à jour l'emprise de la couche (cette information étant stockée dans les tables de métadonnées Oracle Spatial) de manière dynamique.

Import des entités sélectionnées dans DBManager

Autre petite modification qui a son importance, on peut maintenant importer uniquement les entités sélectionnées dans des couches via DBManager. Auparavant, il était indispensable de faire un import global, d'ouvrir la table dans le canevas de carte de QGIS, de faire une sélection, de l'inverser et de supprimer les objets. Voilà pas mal de clics d'économisés !

Fenêtre de requête en onglet

Autre petite modification qui va ravir les "requêteurs" chevronnés: les fenêtres de requête sont maintenant des onglets qui s'ajoutent à la suite des onglets d'information sur la table/vue, l'aperçu des données de la table et l'aperçu géographique. Auparavant, les fenêtres des requêtes étaient flottantes et il était vraiment pénible d'en gérer plus d'une seule. Avec QGIS 2.12, on peut empiler plusieurs fenêtres et passer de l'une à l'autre sans aucun souci.

Plugin de vérification géométrique

QGIS avait déjà un outil de vérification géométrique (Vérification de la validité des géométries) mais maintenant, il en dispose d'un autre (Vérifier les géométries). Les deux outils vont sans doute cohabiter pendant plusieurs versions car ils sont différents dans leurs interfaces et leurs contrôles. Le nouveau plugin "Vérifier les géométries" présente une interface assez complète pour configurer un ensemble de règles à vérifier. Par exemple, vous pouvez vérifier que la géométrie ne contient que des polygones ou qu'elle ne contient pas de géométries qui se superposent. Les options à vérifier sont assez complètes et répondent à la majorité des besoins de vérification.

L'autre outil de vérification géométrique est beaucoup plus simple dans son interface car il ne permet pas de choisir ce qui est à vérifier. Il se contente de lancer une batterie de tests et d'annoncer les résultats, sans possibilité de choisir les tests qui seront réalisés. Il y a eu une petite discussion sur la liste de diffusion des dévéloppeurs sur le sujet à propos de la redondance des deux outils.

Améliorations des outils d'édition de données

Création de polylignes circulaires

Dans la version précédente de QGIS, le moteur géométrique de QGIS a été revu pour intégrer la gestion des géométries curvilignes. Ces dernières permettent de définir une géométrie non pas comme une suite de x/y mais comme la définition d'un centre et d'un rayon. Néanmoins, malgré cet apport, QGIS ne pouvait qu'afficher ces géométries et il n'était pas possible de les créer directement dans le canevas de carte. Ce point est maintenant corrigé: toutes les couches dont le pilote de données gère les géométries courbes (pour l'instant les couches postgreSQL et les couches en mémoire) peuvent être modifiées pour ajouter des géométries courbes via la création de polylignes courbes. QGIS propose pour l'instant deux modes de création: soit en définissant le rayon à la souris, soit en le définissant manuellement via une fenêtre dédié.

Table de nœuds

Lorsque vous éditez la géométrie d'un objet avec l'outil de modification de noeuds, QGIS présente maintenant un panneau avec la liste des points et leurs coordonnées. Ce panneau permet de sélectionner et de se déplacer avec précision sur le n-ième point ainsi que de modifier manuellement ses coordonnées (pour avoir plus de précision par exemple).

Cet outil qui a l'air assez anodin est pourtant particulièrement utile lors de la gestion des erreurs géométriques. En effet, c'est un cas assez courant lorsqu'on utilise des SGBDRS d'importer des géométries de divers fichiers qui sont assez laxistes par rapport aux standards du SGBDRS en question. Certains formats de fichiers géographiques admettent par exemple des polygones qui se superposent à eux-mêmes, formant ce qu'on appelle dans le milieu autorisé: un "papillon". Dans la plupart des SGBDRS, ces géométries sont invalides et si elles sont "importables", on ne peut généralement pas réaliser de traitements dessus (requêtes spatiales par exemple). Bien souvent, il faut effectuer des corrections manuelles car certains problèmes ne peuvent pas être automatiquement corrigés. Tout ce que fait le SGBDRS c'est dire: le point n°X dans le polygone P pose problème. Grâce à la table de nœuds de QGIS, on peut facilement retrouver ce point pour le modifier…

Interface utilisateur

Nouvel écran d'accueil

Avant la version 2.12 de QGIS, quand on ouvrait QGIS, on avait droit à un projet vierge: pas de couches chargées, pas de styles chargés, pas de paramètres personnalisés. Il était (c'est encore le cas) possible d'ouvrir les fichiers de projet récents via le menu Fichier.

QGIS 2.12 présente maintenant une page qui récapitule avec une illustration et des informations, les derniers projets sur lesquels vous avez travaillé récemment. Cela permet d'ouvrir plus rapidement les projets récents simplement en visualisant leur aspect général. Un clic d'économisé pour les utilisateurs, c'est toujours bon à prendre et c'est quand même moins austère que la plage blanche !

Gestion des thèmes d'interface utilisateur

Depuis très longtemps maintenant, QGIS propose plusieurs styles pour l'interface graphique (Windows, CDE, Motif, Plastique, etc.). Ces styles sont appliqués aux widgets Qt et modifient l'apparence des boutons, des entrées, des contrôles de formulaire, etc. Avec la version 2.12, QGIS utilise maintenant les feuilles de style Qt qui permettent d'appliquer des règles de couleur, de taille, d'aspect aux widgets; le tout venant en plus des styles de widget Qt. Pour illustrer cette nouvelle fonctionnalité, un nouveau thème d'interface a été créé. Il se nomme "Night Mapping" et présente une apparence sombre.

Si vous voulez créer un thème, pas de problème, il vous suffit de créer un fichier .qss (l'équivalent d'un CSS pour Qt) en utilisant la référence sur le sujet. Voici l'apparence du thème d'interface "Night Mapping":

Nouvelles fonctions dans les expressions

De nouvelles fonctions font leur apparition dans le moteur des expressions. Les expressions de QGIS permettent de manipuler les valeurs de certains champs pour obtenir des filtres plus complexes. Pour cette version, on trouve des nouveautés du côté des fonctions qui s'occupent de la géométrie des objets:

• num_points(geometry) permet de calculer le nombre de noeuds d'une géométrie.
• les fonctions area(geom), length(geom) and perimeter(geom) permettent de calculer la surface, la longueur et le périmètre de n'importe quelle géométrie. Auparavant, il n'était possible d'utiliser ces fonctions que sur la géométrie en cours de traitement.
• start_point(geom), end_point(geom), point_n(geom) permettent de retrouver le premier, le dernier et le nième point d'une géométrie.
• La fonction make_point(x,y) permet de créer manuellement une géométrie de type point.
• Enfin, les fonctions x(geom) et y(geom) retournent les coordonnées x et y des géométries ponctuelles ou bien les coordonnées x et y du centroïde pour les géométries qui ne sont pas ponctuelles.

On peut également noter l'arrivée de nouvelles fonctions d'expression qui travaillent sur la couleur. Grâce à ces dernières, il est possible d'affecter précisément une couleur donnée en fonction de la valeur de certains champs ou du résultat d'autres fonctions d'expression:

• La fonction project_color permet de récupérer les valeurs de couleur en fonction d'une classification stockée dans le fichier de projet (.qgs). Car il est maintenant possible de définir une palette de couleur spécifique au projet (dans les propriétés de ce dernier). Il sera alors possible d'y faire référence par un simple nom (et non sa définition complète qui implique de connaître les valeurs RGBA).
• La fonction color_part permet de retrouver une seule composante d'une couleur.

Étiquettes

Amélioration du moteur d'étiquettes

Une des nouveautés importantes de cette version est l'amélioration de la gestion des étiquettes. Ces dernières sont des éléments de texte (issus des données attributaires de la table) qui sont affichés au dessus des couches vectorielles. Cela permet d'afficher le nom des rues sur une carte par exemple. QGIS gère les étiquettes depuis très longtemps maintenant et le moteur d'étiquettes a subi une grosse refonte lors du passage à la version 2.0, rendant l'étiquetage beaucoup plus facile à gérer et proposant plus d'options pour gérer le maximum de cas de figure.

Néanmoins, il restait encore des cas particuliers qui avaient tendance à revenir de plus en plus souvent de la part des utilisateurs. La version 2.12 tente de répondre à ces problèmes avec notamment les deux points qui sont présentés en détails ci-dessous (parmi d'autres améliorations apportées par cette version). Ces évolutions ont également été répercutées au niveau de l'API dédiée aux étiquettes.

À ce stade de développement, il ne manque plus guère que la possibilité de gérer la mise en forme des étiquettes via une expression (pour permettre d'afficher le premier mot d'une étiquette en rouge et le troisième mot en bleu avec une police différente par exemple)…

Étiquettes basées sur des règles

De la même manière que QGIS permet de gérer le style d'affichage des couches en fonction de règles, on peut maintenant utiliser ces mêmes règles pour les étiquettes. Concrètement, cette fonctionnalité permet de désactiver l'affichage à certains seuils d'échelle ou de n'afficher les étiquettes que pour certains objets géographiques d'une couche, en fonction d'une expression. Vous pouvez également affecter un style aux étiquettes en fonction des règles (genre afficher le nom des rues principales en gras avec une police différente des rues secondaires).

Avec cette fonctionnalité, on peut répondre à vraiment beaucoup de cas d'usages différents simples ou complexes et les possibilités d'affichage des étiquettes sont presque sans limite.

Affichage sélectif des étiquettes

Un des problèmes qui restait à gérer dans les étiquettes était le positionnement de ces dernières. Dans des cas simples, on souhaite juste placer des étiquettes pour qu'elles soient visibles. Donc, il faut les afficher au dessus de toutes les couches. Mais comment fait-on si on souhaite qu'elles ne s'affichent pas lorsqu'elles sont au-dessus d'un polygone d'une autre couche (qui sert à masquer certaines étiquettes) ? Comment fait-on pour gérer l'affichage des étiquettes avec plusieurs couches (est-ce que les étiquettes des noms de rues doivent être affichées au dessus des étiquettes des numéros de rue ?) ?

QGIS vous permet maintenant de répondre à ces points particuliers grâce aux options qui suivent:

• On peut maintenant choisir de ne plus afficher les étiquettes qui débordent du polygone étiqueté. Cela permet d'éviter que des étiquettes débordent d'une couche et aillent "polluer" les étiquettes d'une autre couche.
• Il est également possible de définir la priorité d'affichage de l'étiquette de chaque objet en fonction d'une valeur ou d'une expression. En règle générale, lorsqu'on affiche une couche, on utilise un algorithme de placement qui affiche les étiquettes suivant la place disponible (c'est l'option par défaut). De fait, certaines étiquettes sont ainsi non affichées pour ne pas surcharger l'affichage (de toute manière, on n'y voit plus rien). Jusqu'à présent, QGIS ne permettait pas de définir la priorité d'affichage de chacun des objets au sein d'une même couche. C'est maintenant corrigé. Concrètement, on peut utiliser une expression ou la valeur d'un champ pour indiquer la priorité d'affichage de chaque objet d'une couche. Bien entendu, cette priorité est également en concurrence avec les priorités des objets des autres couches. Par exemple, si vous souhaitez afficher en priorité les noms des villes qui ont le plus d'habitants, il vous suffit de faire varier la priorité d'affichage en fonction de la population (moyennant une petite mise à l'échelle linéaire).
• On peut aussi paramétrer des couches d'obstacles. Il s'agit de couches sur lesquelles les étiquettes doivent éviter de recouvrir la couche. J'ai bien employé les mots "doit éviter" car, s'il n'y a pas moyen de faire autrement, l'étiquette recouvrira l'objet de la couche d'obstacle. Cette fonctionnalité permet d'améliorer le rendu des étiquettes en évitant le plus possible de recouvrir des objets dont l'affichage est important. Vous pouvez par exemple l'utiliser pour éviter que les numéros des habitations ne soient affichés sur les linéaires des rues. Attention, si vous avez une couche de polygone, il sera impossible de ne pas la recouvrir d'étiquettes. Les couches d'obstacle sont plus des couches d'évitement pour les étiquettes et cet évitement n'est pas absolu.
• Chaque couche d'obstacle dispose de son niveau de priorité. Entre deux couches qui ont un niveau de priorité d'obstacle différent, celle qui aura le niveau le plus élevé aura moins de chance d'être recouverte par une étiquette.
• Enfin, en combinaison avec les couches d'obstacles, les couches de polygones peuvent être paramétrées pour décourager l'affichage des étiquettes sur les limites des polygones. Cela permet d'encourager que les étiquettes des autres couches s'affichent au maximum à l'intérieur des polygones et non à cheval sur leurs limites. Cela permet généralement un affichage plus net où la géométrie des polygones est bien visible. Néanmoins, il ne s'agit que d'un encouragement : s'il n'y a pas le choix, les limites des polygones seront recouvertes.

Pour l'avenir

Rythme des publications de version

Comme depuis longtemps sur la liste de diffusion des développeurs QGIS, et ce, à chaque publication d'une nouvelle version, de nombreux développeurs font remonter que le rythme est un peu trop soutenu. En effet, tous les 4 mois, le projet crée une nouvelle version. Le processus est lui-même découpé en deux phases:

• introduction des nouvelles fonctionnalités (3 mois).
• gel des fonctionnalités et correction des bugs (1 mois).

Pourtant, dans la pratique, voici ce qu'on peut constater:

• De nombreux développeurs n'ont pas assez de temps pour introduire de nouvelles fonctionnalités pendant les 3 mois.
• Bien souvent, des développeurs demandent une à deux semaines de délai pour le gel des fonctionnalités dans le but d'incorporer correctement leurs pull-requests.
• Certaines pull-requests n'ont pas le temps d'être revues ni fusionnées dans le dépôt avant la publication officielle de la branche principale.
• Lors de sa sortie, QGIS publie généralement (c'est le cas depuis au moins 3 versions consécutives), une version 2.xx.1 qui corrige des bugs majeurs qui n'avaient pas été testés lors de la phase de gel.

Donc, à chaque publication, on a droit à ce genre de messages ! Pour prendre des décisions plus éclairées et éviter le flamewar inhérent à ce genre de problème (certains sont satisfaits du rythme actuel, d'autres voudraient revenir à deux publications par an), des membres du PSC (Direction du projet) ont lancé un questionnaire en ligne pour les utilisateurs de QGIS afin de leur demander ce qu'ils attendent en termes de publication de versions et leurs utilisations des dernières versions ou de la version LTR. Le questionnaire étant maintenant clos, vous pouvez néanmoins consulter les résultats pour les utilisateurs français qui ont répondu.

Il reste à voir comment les résultats vont être interprétés et si une décision va être prise sur le sujet. En cas de stagnation, je pense qu'on aura droit aux même messages récurrents sur la durée entre les publications…

Passage à Qt5 et Python3

Récemment, une QEP est sortie sur la transformation technique la plus importante dans l'avenir de QGIS: le passage à Qt5 et à Python3. Dans le projet QGIS, une QEP est une QGIS Enhancement Proposition (une proposition d'amélioration de QGIS en bon français). Normalement, lorsqu'un point de développement demande discussion entre développeurs, une QEP est produite. Ce document détaille l'objectif du changement proposé et raconte comment y parvenir sans rentrer trop loin dans les détails de l'implémentation. Un vote a ensuite lieu et la fonctionnalité est intégrée ou non en fonction du résultat. Par exemple, le système d'authentification a fait l'objet d'une QEP en amont de son intégration dans la version 2.12 de QGIS.

Cette fois, une proposition de QEP est sortie sur la programmation de l'intégration de Qt5 et de Python3 dans la future version 3.0 de QGIS. Globalement, elle indique qu'il ne devrait pas y avoir de version 2.16 de QGIS mais une version 3.0 qui intégrerait obligatoirement Qt5 et si possible Python3. Cette version autoriserait le cassage de l'API 2.0 en cas de besoin. L'avenir nous dira si cette QEP passe du stade de projet au stade validé. Vous pouvez retrouver les discussions de la liste de diffusion des développeurs sur le sujet.

Améliorations du pilote PostgreSQL

La Pull-Request suivante apporte quelques modifications sur le pilote de données PostgreSQL/PostGIS pour mieux gérer les couches polyhédrales et les TIN stockées dans PostGIS. Un TIN est un modèle numérique de terrain vectoriel. Jusqu'à présent, QGIS sait gérer des MNE ou des MNT au format raster (chaque cellule/pixel contient la donnée d'élévation ou de terrain).

 Évolution des accès réseau

En consultant les Pull-Requests de QGIS sur github, on voit qu'un certain nombre d'extensions Python sont en train de migrer vers le système de gestion réseau interne de QGIS. L'intérêt de cette transition est de pouvoir utiliser ces extensions dans des environnements où la configuration réseau repose sur l'utilisation d'un serveur mandataire (proxy). QGIS gère la configuration réseau en interne (il peut utiliser celle du système d'exploitation). La plupart des pilotes de données qui ont besoin d'accéder à Internet (WMS/WFS/WCS/etc.) utilisent une classe de QGIS pour accéder au réseau (QgsNetworkAccessManager qui est une surcouche de la classe Qt QNetworkAccessManager. L'intérêt d'utiliser cette classe est de disposer d'un accès réseau sans devoir en gérer les paramètres, ces derniers étant intégrés au niveau de l'application QGIS elle-même.

Mais la plupart des extensions Python qui avaient besoin d'accéder au réseau utilisaient encore urllib2 où la configuration du proxy est certes possible mais dont la préparation implique de nombreuses lignes de codes pour récupérer la configuration réseau dans les paramètres de QGIS. Néanmoins, plusieurs extensions ou parties d'extension commencent à migrer vers QgsNetworkAccessManager ce qui permet leur utilisation dans des environnements d'entreprises ou d'administrations ou encore pour des entités utilisant un serveur mandataire. Ainsi par exemple, on peut dès maintenant récupérer l'aide des géo-traitements depuis Internet. On devrait sans doute pouvoir récupérer les scripts de géo-traitement du dépôt GitHub ainsi que consulter un catalogue CSW derrière un proxy.

Modification de l'interface de création de fonctions d'expressions

Les expressions de QGIS permettent de faire des tris, des sélections et des traitements de données attributaires et géographiques. Elles constituent le coeur de toute la logique utilisateur pour travailler avec les données gérées dans QGIS, en plus des géo-traitements qui réalisent des opérations un peu complexes. Quasiment tous les éléments de contrôle et d'affichage dans QGIS peuvent être modifiés par une expression ce qui permet des réalisations quasiment infinies. Vous pouvez par exemple définir la dimension de chaque point représenté sur la carte en fonction d'une règle complexe (ex: convertit deux champs en entier, fait la moyenne et multiplie par 5 pour déterminer la taille du symbole utilisé pour représenter le point).

Avec le temps, les fonctions disponibles dans les expressions se sont globalement enrichies. Au début, on ne pouvait faire que quelques opérations mais maintenant, il existe même des fonctions qui calculent un score de similarité entre deux chaînes de caractères ou qui réalisent des mises à l'échelle en fonction d'une plage. Chaque nouvelle version de QGIS voit arriver son lot de nouvelles fonctions.

Néanmoins, ce n'est pas suffisant dans certains cas où aucune fonction ou combinaison de fonctions d'expression ne peut vous faire obtenir le résultat escompté. Pour répondre à ce problème, QGIS permet depuis la version 2.8 de créer des fonctions en Python qui seront utilisées par le moteur d'expression. Ainsi, si vous avez besoin d'un algorithme qui n'existe pas (encore) dans QGIS, vous êtes libre de le coder.

L'ergonomie de l'interface d'édition de code des fonctions d'expression va sans doute être revue dans la prochaine version de QGIS car il faut bien reconnaître qu'elle peut être améliorée. Il devrait y avoir un panneau permettant d'appeler les derniers fichiers Python utilisés pour construire la fonction d'expression. Un système de test de la fonction devrait être mis en place pour tester rapidement le résultat de la fonction (ce qui permet un développement plus simple). A voir si la PR passe ou pas dans les 3 mois à venir…

Conclusions

Encore une fois, la nouvelle version de QGIS est pleine de nouvelles fonctionnalités. Espérons que cette dépêche vous permettra d'y voir plus clair. Ceux qui veulent plus de détails peuvent se tourner vers le changelog visuel qui est bien plus complet. Merci d'ailleurs à l'équipe de développement de QGIS de faire l'effort de publier en images les principaux changements de chaque version (c'est un vrai travail).

Même si avec le temps QGIS devient un logiciel de SIG mûr, il reste encore pas mal de secteurs de l'application à renforcer. Par exemple, les géo-traitements (Processing) sont quand même beaucoup moins nombreux que ceux d'ArcGIS et il arrive souvent que certaines implémentations d'algorithmes plantent ou retournent des résultats erronés. Il faudra encore un peu de temps (et de code) pour arriver au niveau des meilleurs outils de SIG sur le sujet. Par ailleurs, la documentation des géo-traitements est vraiment minimale. Il faudrait veiller à l'améliorer fortement pour ne plus avoir à se demander à quoi sert tel ou tel traitement.

Autre exemple d'amélioration possible: la mise à niveau des fonctionnalités des différents pilotes d'accès aux SGBDRS. Pour l'instant, on peut sans mal affirmer que le pilote de données PostgreSQL est celui qui présente le plus de fonctionnalités (gestion de l'authentification QGIS, gestion des géométries courbes, simplification de la géométrie du côté serveur, gestion des expressions du côté serveur, etc.). C'est sans doute normal car PostgreSQL et PostGIS sont très facilement déployables sur toute machine (y compris machine de dev) en quelques lignes de commandes. Néanmoins, il serait bon que les autres pilotes de données ne soient pas trop à la traîne (dans l'ordre des fonctionnalités: Oracle Spatial, MySQL et MS-SQL Server). Le support renforcé et à iso-fonctionnalités de ces SGBDRS par QGIS serait un facteur important de migration. Mais, effectivement, maintenir le code pour ces 3 autres bases de données prend du temps que la communauté des développeurs QGIS n'est sans doute pas capable de fournir. Des volontaires ?

Si vous souhaitez contribuer à l'essor de QGIS voici quelques idées d'action:

• Si vous êtes un scientifique habitué à travailler avec des géo-algorithmes, lancez vous dans la documentation des géo-traitements de QGIS car cette dernière est vraiment à la traîne comparée à d'autres.
• Si vous êtes bon en C++, vous pouvez vous plonger dans le code principal de QGIS pour voir s'il n'y aurait pas quelques améliorations à apporter.
• Si vous êtes bon en Python, vous pouvez travailler sur Processing. Il s'agit du moteur des traitements géographiques. Vous pouvez en améliorer le cœur mais aussi (et surtout) créer ou corriger tous les algorithmes présents.
• Si vous ne savez pas coder, vous pouvez nous aider à maintenir la traduction française à 100% sur transifex, notamment après le gel des fonctionnalités afin de nous assurer d'avoir une version complètement traduite en français.
• Si vous êtes bon en matière de formation, n'hésitez pas à proposer des améliorations sur la documentation QGIS, elle en a bien besoin.
• Dans tous les autres cas, vous pouvez simplement installer la dernière version de QGIS (si possible la dernière version de développement) et faire du triage de bugs (il y en a un peu plus de 2700 à suivre).
• Enfin, n'hésitez pas à faire découvrir QGIS à votre entourage…

Rendez-vous dans 4 mois pour la prochaine version !

PS: si vous souhaitez participer à la rédaction de la future dépêche, n'hésitez pas à venir traîner sur la partie rédaction collaborative de linuxfr après le gel des fonctionnalités (dans 3 mois). Cela permettra de réduire la charge de travail sur la dépêche et de mettre en avant des éléments qui vous tiennent à cœur.

Aller plus loin

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