Sortie de QGIS 2.16 « Nødebo »

Le projet QGIS a l’immense plaisir de vous annoncer la publication de la version 2.16 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 d’appliquer différents 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.16, nommée Nødebo, en hommage à la ville danoise éponyme, est disponible depuis le 8 juillet 2016 (pour information, les noms des versions de QGIS sont basés sur les noms des villes qui accueillent les rencontres annuelles des développeurs). Cette version est une version dite courante : elle sera supportée pendant quatre mois. La version LTR (Long Term Release : support à long terme) est la version 2.14 qui, à l’occasion de la sortie de la version courante, récupère un ensemble de corrections, intégrées dans la version 2.14.4. Nødebo sera sans doute la dernière version de la lignée 2.x, car le portage vers la version 3.0 avance correctement.

Dans la suite de la dépêche, un aperçu des nouveautés, issues des 2 447 commits depuis la dernière sortie, vous sera présenté plus en détail, 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…

Bonne lecture !

Sommaire

• Les nouveautés notables de QGIS 2.16
  • Du côté des outils de cartographie
    • Le dock de style
    • Nouveau moteur de rendu : aucun symbole
    • Nouveau type de symbole : lignes de flèches
    • Travail sur l’ergonomie de l’interface
  • Du côté de la table des attributs
    • Nouvelles options d'agencement de la table attributaire
    • Formulaire de recherche
    • Autres nouveautés de la table d'attributs
  • Fournisseurs de données
    • Création de couches au standard GeoPackage
    • Connecteur aux services ArcGIS REST
    • Refonte du connecteur WFS
    • Sauvegarde des styles des couches en base de données pour Oracle et MS-SQL Server
  • À propos des formulaires de saisie
    • Éditions multiples
    • Contraintes de saisie
  • Documentation
    • Toute la doc est faite ;-)
    • L'API d'authentification sécurisée est complètement documentée.
  • Rasters
    • Nouveau rendu pour les MNE
    • Classification basée sur les quantiles
  • Saisie géométrique
    • Couches en lecture seule (dans le projet)
  • Expressions
    • Utilisation de paramètres nommés
    • Amélioration des fonctions de calcul de dates et d'intervalles de temps
    • Fonctions d'agrégation
  • Traitements
    • Suppression de fTools
    • GRASS7
    • Gestion de l'écriture de tables sans géométries
    • Support des expressions dans les entrées des traitements
  • Composeur d'impression
    • Dessins de formes : polygones/polylignes
    • Géoréférencement des cartes en sortie d'impression par défaut
  • Plugins ou extensions
    • Refonte du plugin Globe
• Informations sur la version 3.0
  • Informations générales
  • Tester la version 3.0 de développement
  • Le mécanisme de conversion des plugins "core"
• Conclusions

Les nouveautés notables de QGIS 2.16

Voici une petite sélection des nouveautés de la version 2.16 de QGIS. Si vous voulez découvrir l’intégralité des évolutions, nous vous invitons à consulter la page des changements en images qui est vraiment très complète et qui a l’avantage d’être traduite en français (du moins, d'ici quelques temps).

Du côté des outils de cartographie

Le dock de style

Commençons par une nouvelle fonctionnalité qui va fortement améliorer la productivité des cartographes : le dock de style.
Jusqu’à présent, lorsque vous vouliez modifier le style d’une couche, vous deviez ouvrir la fenêtre des propriétés de la couche, aller dans l’onglet réservé aux styles et paramétrer vos options pour obtenir le rendu final. C’est une tâche relativement courante lorsqu’on fait de la cartographie et l’onglet des styles est probablement celui qui est le plus utilisé dans QGIS, avec ce qui permet de charger des couches dans le projet en cours.

Le problème majeur est que la fenêtre des propriétés de la couche est modale : il s’agit d’une fenêtre flottante qu’il faut valider (en appuyant sur le bouton Ok ou le bouton Appliquer) pour voir les résultats de vos travaux. Néanmoins, la fenêtre des styles a tendance à occuper une surface de plus en plus grande, du fait des très nombreuses options possibles et du grand nombre de moteurs de rendu existants dans QGIS. Ainsi, bien souvent, il faut fermer cette fenêtre pour voir les résultats et rien de ce que vous faites n’est visible en direct. Étant donné qu’il est assez rare de savoir comment représenter les données géographiques du premier coup, la création d’un style complet demande de nombreuses modifications ponctuelles (non, finalement, la couleur ne va pas ! Et si j’augmentais la largeur de la bordure ? En fait, je vais plutôt mettre un symbole de police plutôt qu’un symbole SVG, etc.) Cela revient à ouvrir et fermer la fenêtre de style très souvent ce qui fait perdre du temps.

Pour régler ce problème, QGIS 2.16 propose maintenant un dock de style. Ce dock est déplaçable où vous voulez sur votre écran, vous pouvez l’accrocher où bon vous semble, voire le déporter sur un autre écran. Il est physiquement toujours présent même si on peut le masquer complètement. Ainsi, plus besoin d’ouvrir et de fermer la fenêtre des propriétés de la couche. Un vrai gain de temps en perspective.

Autre avancée majeure : la mise à jour en direct. Cette option du dock permet de voir tout changement de style directement s’appliquer sur votre fenêtre de carte sans avoir besoin de cliquer sur le bouton Appliquer. Cela permet vraiment de voir l’impact de tout changement, même insignifiant, en direct.

Pour terminer le dock de style fonctionne également sur les styles multiples ainsi que sur les étiquettes. Il est bien entendu possible de revenir en arrière car le dock conserve l’historique de toutes les manipulations. Il est donc très facile de revenir plusieurs points en arrière et reprendre une création de style à partir d’un état précédent, sans devoir tout recommencer depuis le début.

Le dock de style va donc permettre aux cartographes de gagner un temps précieux et d’avoir une meilleure réactivité sur leur travail de composition. C’est une vraie avancée tant sur le plan de l’efficacité que de l’ergonomie. Pour ma part, je ne pourrais plus faire sans.

Pour vous en convaincre, voici un exemple de fonctionnement :

Nouveau moteur de rendu : aucun symbole

QGIS continue d'innover dans les moteurs de rendu. Cette désignation indique les grandes familles de rendu d’une symbologie de couches. Globalement, il s'agit des méthodes de base permettant d'appliquer un ou plusieurs styles différents à des couches de polygones/de lignes/de points ou de raster. C'est un des composants les plus utilisés dans QGIS puisque dès qu'on souhaite élaborer une carte, on passe par lui. On compte maintenant une petite dizaine de moteurs de rendus différents, allant de la représentation unique pour tous les objets de la couche à la carte de chaleur en passant par le rendu 2.5D (présenté dans la dernière dépêche sur QGIS 2.14). Ce qui fait de QGIS sans doute le SIG le plus riche pour la représentation cartographique.

Pour la version 2.16, le moteur de rendu dit "Aucun symbole" est très simple : il permet de ne pas représenter les objets de la couche sur laquelle il est appliqué. Quel est donc son intérêt alors ?

Ce moteur de rendu sert essentiellement pour gérer ce qu'on appelle des "couches d'étiquettes". En effet, en plus des symboles d'objets géographiques, on peut représenter également des étiquettes ainsi que des diagrammes qui sont des objets générés, quasi-indépendants des objets géographiques (ils sont généralement positionnés au-dessus de leur objet géographique respectif mais ce n'est pas forcément obligatoire). Ainsi, pour les couches sans symbologie, apparaîtront uniquement les étiquettes et les diagrammes. Cela peut être intéressant si vous avez constitué une couche de points, dédiée à l'affichage de certaines étiquettes (les étiquettes seront positionnées au-dessus des points) et que vous ne voulez pas représenter les points. Cette situation est parfois nécessaire lorsqu'on souhaite positionner manuellement des étiquettes dans l'objectif d'avoir un rendu vraiment parfait (à une échelle donnée), lorsque le placement automatique des étiquettes ne donne pas satisfaction.

Nouveau type de symbole : lignes de flèches

Les moteurs de rendu forment les familles de représentation. Chaque moteur de rendu propose de créer des styles spécifiques en utilisant des symboles qui peuvent prendre plusieurs types différents. Par exemple, pour styler une couche de polygones, on peut choisir d'utiliser un type de remplissage simple (formé à partir d'une couleur de remplissage ainsi que d'une bordure de largeur et de couleur données). On peut également utiliser un remplissage par motif (formé à partir d'une géométrie qui sert de motif) ou encore un remplissage dégradé, ou également choisir de ne représenter que la bordure pouvant elle-même être composée de plusieurs symboles de points différents. Ces ensembles de styles sont appelés types de symboles et ils sont bien entendu combinables entre-eux (jusqu'à quasiment l'infini).

Régulièrement, QGIS introduit de nouveaux types de symboles. C'est le cas pour cette version avec le type lignes de flèches qui permet de générer des flèches dans des styles variés pour tout objet linéaire (donc les polylignes mais également les bordures de polygones).

Deux modes sont présents :

• Les flèches linéaires: elles permettent de dessiner une flèche en suivant les segments d'un objet linéaire.
• Les flèches courbes: elles permettent de dessiner une flèche entre deux points avec une forme incurvée.

Ce type de symbole permet de simplifier la représentation des segments linéaires avec un sens de direction. C'est très pratique pour générer des cheminements avec un sens (représenter les rues en sens unique par exemple). On peut bien entendu également disposer d'une seule flèche linéaire pour l'objet linéaire.
Les flèches courbes peuvent être utilisées pour représenter des flux d'un point à l'autre, sans forcément suivre une ligne droite. C'est très pratique pour représenter des flux entre deux points, dont la largeur de flèche est proportionnelle à la masse déplacée.

En outre, il est combinable avec l'ensemble des autres type de symboles de QGIS ainsi qu'avec des expressions car les flèches sont des objets surfaciques. On peut donc par exemple dessiner des flèches avec un gradient de couleur en guise de remplissage, dont la taille de la pointe est dépendante de la valeur d'un attribut.

Voici un exemple de réalisation où on voit bien les différentes formes possibles, ainsi que les options disponibles :

Travail sur l’ergonomie de l’interface

Quelques nouveautés permettent d'améliorer l'ergonomie de l'interface sur la partie cartographie de QGIS.

Comme premier point, on peut noter une amélioration de la finesse de zoom lorsqu'on utilise la molette de la souris (utilisée pour zoomer/dézoomer) en appuyant sur la touche Ctrl. Cela permet de zoomer/dézoomer "moins vite" en diminuant l'écart entre les deux échelles.

Par ailleurs, il existe maintenant une fonction de loupe qui permet de grossir l'image du rendu de carte à une échelle donnée. Cela permet de grossir certains éléments ; par exemple, des étiquettes avec une taille de police basse pour pouvoir mieux les placer manuellement. L'intérêt de la loupe est qu'elle ne modifie pas l'échelle et donc il n'y a pas besoin d'effectuer un rendu graphique lorsqu'on l'utilise. Si vous avez une carte avec de nombreux détails, vous pouvez agrandir l'image sans devoir relancer de lourds calculs qui prendraient du temps.

Du côté de la gestion des rampes de couleur (utilisées pour les gradients de couleur), QGIS présentait déjà une boîte de dialogue vraiment complète, permettant de créer ou de modifier des rampes de couleur de manière interactive. La boîte de dialogue présente maintenant une meilleure ergonomie avec la possibilité de déplacer directement les arrêts de couleur, de les supprimer directement, de les créer par un simple double-clic.

En ce qui concerne les écrans à très grande résolution (4k), QGIS utilise maintenant uniquement des icônes SVG pour ses barres d'outils. L'intérêt est de pouvoir les représenter avec une dimension adaptée à l'écran (auparavant certaines icônes étaient uniquement en bitmap, avec une taille fixe, paramétrable mais sans doute pas assez grosse pour les écrans à haute résolution).

Enfin, on notera une amélioration des options de sélection des entités géographiques sur le canevas de carte:

• Sur les sélections à un seul clic, maintenir Shift ou Ctrl permet de sélectionner/désélectionner l'entité.
• Sur les sélections par emprise (cliquer + déplacer):
  • Maintenir Shift permet d'ajouter à la sélection courante.
  • Maintenir Ctrl permet de retirer de la sélection courante.
  • Maintenir Alt permet de sélectionner les entités qui sont situées en intégralité dans l'emprise de sélection (si vous sélectionnez un objet qui intersecte une partie de l'emprise de sélection, il ne sera pas sélectionné).

Ces mécanismes sont également intégrés au composeur de cartes.

Voici une illustration de la boîte de dialogue des rampes de couleur :

Du côté de la table des attributs

Un des principes de base du SIG est de combiner formes géographiques et attributs alphanumériques. Ces attributs permettent de qualifier les objets spatiaux représentés sur la carte. Par exemple, si vous avez une couche d'arbre, vous pouvez stocker l'espèce de l'arbre dans un attribut de la table ou encore, sa hauteur dans un autre attribut. Comprenez que la géométrie d'un objet n'est qu'un attribut parmi tant d'autres qui a la particularité d'être représenté différemment d'un texte ou d'un chiffre.

Dans cette version de QGIS, de nombreuses améliorations ont été ajoutées dans la table des attributs. C'est ce que nous allons voir dès maintenant…

Nouvelles options d'agencement de la table attributaire

C'est une fonctionnalité longtemps attendue dans QGIS : on peut maintenant manipuler la table attributaire comme dans n'importe quel logiciel de tableur (comme LibreOffice Calc) :

• Il est possible de masquer/afficher certaines colonnes.
• On peut effectuer des tris multiples sur une ou plusieurs colonnes.
• On peut changer l'ordre d'affichage des colonnes.
• QGIS conserve (dans le fichier de projet) la largeur de colonne que vous avez configurée (pour chaque colonne).

Formulaire de recherche

La table d'attributs présente maintenant trois modes d'affichage :

• le mode table qui permet de présenter les données sous forme tabulaire (comme dans LibreOffice Calc).
• le mode formulaire qui permet de présenter les données sous forme de formulaire rempli avec les données (un seul objet est affiché).
• il existe maintenant un nouveau mode : le formulaire de recherche qui permet d'utiliser le formulaire pour faire des recherches.

Avant ce mode formulaire de recherche, il fallait passer par le moteur d'expression (cette fonctionnalité est toujours disponible) et créer une « requête d'expression », bien plus complexe (mais plus puissante) pour les utilisateurs débutants. Maintenant, ils disposent d'un formulaire simple leur permettant de sélectionner les objets qui correspondent à un ou plusieurs attributs.

Autres nouveautés de la table d'attributs

• Vous pouvez paramétrer la table d'attributs pour qu'elle s'affiche dans le mode de votre choix (stocké dans les paramètres de QGIS).
• Le mode formulaire permet maintenant de faire des filtres (sur n'importe quelle colonne), ce qui permet de limiter les objets listés à votre choix
• Autre point en évolution : auparavant, pour copier la valeur d'un attribut, il fallait se mettre en mode édition (modification des données) et faire un copier. Maintenant, il suffit de faire un clic-droit et de sélectionner l'entrée de sous-menu : Copier le contenu de la cellule.

Fournisseurs de données

Les fournisseurs de données sont les éléments de base de QGIS permettant de lire et écrire les données depuis divers formats. On en dénombre maintenant une quinzaine ce qui fait de QGIS l'un des SIG les plus interopérables qui soit. Par ailleurs, et c'est là une particularité de QGIS par rapport aux autres SIG (propriétaires et libres) : QGIS ne dispose pas d'un format interne pour stocker des données (QGIS dispose de formats « internes » pour tout le reste : projets/styles/métadonnées/etc.) et c'est tant mieux. D'abord, cela permet de dire que QGIS ne suit pas la règle XKCD sur les formats. En outre, cela permet de se focaliser sur les méthodes de connexion et non sur la maintenance d'un nouveau format.

Car il faut bien retenir que le nombre de formats SIG existants est au moins aussi grand que ce qu'on peut rencontrer dans les formats bureautiques. Un exemple flagrant est que très tôt (il y a plus de quinze ans), une bibliothèque dédiée à la gestion des formats SIG existants a été développée. Il s'agit de GDAL (avec son compagnon OGR pour les objets vectoriels). Cette bibliothèque gère aujourd'hui un peu plus de 220 formats différents ! (WTF !!!??? OMG Ponies 11!!1111!!!)

Création de couches au standard GeoPackage

Dans le monde des SIG, il existe un standard de fait, assez ancien qui se nomme ESRI Shapefile. C'est un format propriétaire dont les spécifications sont à peu près ouvertes. Il a été créé par ESRI, l'actuel leader mondial des solutions SIG avec son produit ArcGIS si cher, mais pas seulement… De nombreux logiciels de SIG sont capables de lire et écrire dans ce format. Néanmoins ce dernier présente plusieurs inconvénients :

• Il est assez ancien (bon, on s'en fout, tant que ça marche) !
• Les noms de champs ne peuvent pas avoir une longueur supérieure à 10 caractères (une vraie limite en 2016).
• Les champs de type texte ne peuvent pas contenir plus de 255 caractères (une autre vraie limite).
• Les polygones sont forcément orientés dans le sens des aiguilles d'une montre.
• ESRI propose un autre format (GéoDatabase fichier) depuis près d'une dizaine d'années.
• Il ne permet de stocker qu'une seule couche.
• Il ne gère que des vecteurs.

Pour améliorer la situation, l'OGC a lancé une étude d'un nouveau format pour remplacer ce standard de facto par une alternative ouverte et plus moderne. Cette étude a conclu à la création du format GeoPackage qui présente les particularités suivantes :

• La spécification est ouverte.
• Il permet de stocker une archive de couches.
• Il est basé sur SQLite.
• Il gère des couches vecteurs et rasters.
• Il peut évoluer dans le temps grâce à un mécanisme d'extensions.

QGIS 2.16 facilite la création de fichiers GeoPackage en gérant ce format directement depuis l'interface d'enregistrement des couches: par la barre d'outils des couches ou par le sous-menu Couche -> Enregistrer sous…

Je vous invite fortement à utiliser ce format plutôt que le traditionnel Shape pour toutes les bonnes raisons évoquées plus haut.

Connecteur aux services ArcGIS REST

QGIS permet maintenant de se connecter à des services de cartes ArcGIS. Ces services sont l’équivalent des services web OGC WMS Web Map Service, et WFS Web Feature Service, dans le standard propriétaire de l’éditeur ESRI. Les deux types de services suivants sont gérés :

• ArcGIS Map Service : service qui sert des rasters depuis un serveur Web.
• ArcGIS Feature Service : service qui sert des entités géométriques (vectorielles) depuis un serveur Web (équivalent à WFS).

À partir de QGIS, il est donc maintenant possible d’attaquer ces services, en lecture seule pour le moment. Cette fonctionnalité permet d’envisager plus sereinement la migration d’une infrastructure ESRI vers QGIS. En effet, on peut déployer QGIS sur les postes bureautique sans devoir abandonner tout de suite les services web qui ont forcément pris du temps à être élaborés, donnant un peu plus de temps pour envisager la migration de la partie serveur (par QGIS Server ou un autre serveur de cartes comme MapServer ou GeoServer).

Refonte du connecteur WFS

QGIS gère les services WFS depuis de nombreuses années. Ces services web permettent de récupérer des couches géographiques vectorielles (points/lignes/polygones) depuis un serveur situé sur le web et qui gère le protocole WFS. Ce dernier est un protocole normé par l'OGC.

WFS est très souvent mis en place par des structures institutionnelles pour faciliter la diffusion de leurs données publiques en accès direct (par exemple le Centre Régional Auvergnat de l'Information Géographique a des flux WMS/WFS publics). Grâce à ce protocole on gagne souvent beaucoup de temps car il n'y a plus besoin de télécharger une couche sur sa station de travail pour en utiliser les données. Tout se passe directement depuis le client qui va chercher les données pour vous. De plus, les données sont souvent directement à jour : pas besoin de s'embêter de savoir si on a bien la donnée la plus à jour possible (et refaire le téléchargement manuel).

Néanmoins, avec le temps, le connecteur natif de QGIS est resté tel quel, avec de nombreux bugs. Par ailleurs, le standard WFS a évolué avec le temps, notamment avec la publication des versions 1.1 et 2.0 du protocole, en ajoutant des fonctionnalités. Il était donc temps de le mettre au goût du jour, sachant que de plus en plus de données sont disponibles via les plate-formes WEB SIG.

Voici la liste des évolutions apportées dans la version 2.16 de QGIS :

• Autodétection de la version du protocole WFS.
• Mise en cache des entités téléchargées sur disque.
• Prise en charge de l'interface de connexion sécurisée pour les accès requérant un login/mot de passe (les informations de connexion sont stockées dans une base de données locale sécurisée et chiffrée par un mot de passe principal).
• Téléchargement en tâche de fond et rendu progressif (ne bloque pas l'interface graphique pendant le chargement).
• Gestion des protocoles WFS 1.1 et 2.0 (auparavant, seul le protocole WFS 1.0 était géré).
• Gestion de la pagination des requêtes WFS 2.0 GetFeature.
• Ajout de tests unitaires sur le fournisseur de données (le pilote WFS).
• Gestion des jointures de couches/tables (fonctionnalité de WFS 2.0).
• Paramètres de l'URI pour gérer les clauses SQL SELECT / FROM / JOIN / WHERE / ORDER BY.
• Gestion des champs stockant des données de date.
• Activation de l'option « Requêter uniquement les entités qui intersectent la vue courante » par défaut.settings.
• Gestion de types géométriques particuliers : CurvePolygon (polygones courbes) et CompoundCurve (courbes multiples).
• Amélioration de la gestion des serveurs WFS non conformes (qui ne respectent pas 100% du standard).

Le connecteur gère également le cache des entités ce qui évite de recharger toutes les entités lors du déplacement sur la carte.

C'est donc plutôt une bonne avancée qui va permettre aux utilisateurs de QGIS d'utiliser de plus en plus de flux de données, issus de différents partenaires, d'une manière plus simple que la méthode traditionnelle de téléchargement manuel d'archives compressées.

Sauvegarde des styles des couches en base de données pour Oracle et MS-SQL Server

Dans un SIG, la manière de représenter une donnée n'est généralement pas stockée en même temps que les données. En règle générale, le style de chaque couche a tendance à changer pour chaque projet cartographique donc il n'est généralement pas pertinent de stocker ce style dans autre chose que le conteneur du projet cartographique. De plus, stocker le style dans les données amène une certaine confusion chez les utilisateurs débutants qui peuvent être amenés à ne pas utiliser les fonctions de représentation automatique du moteur carto du logiciel de SIG mais de styler individuellement chaque objet géographique (ce qui est MAL !).

Néanmoins, dans certaines situations, on peut vouloir créer un style par défaut ou une collection de styles pré-définis pour une couche si on sait qu'on doit souvent faire la même chose avec les données. QGIS permet de stocker des styles dans des fichiers externes :

• les fichiers QLR englobent référence vers la donnée et style
• et QML stocke un style pur, indépendamment de la couche.

Depuis la version 2.0, QGIS offre la possibilité de stocker les styles des couches PostGIS directement en base de données à l'aide d'une table spécifique, propre à QGIS.

Avec la version 2.16, QGIS offre cette fonctionnalité pour les bases Oracle Spatial (qui double généralement le prix de l'instance) et MS-SQL Server. Le principe est le même que pour PostGIS : une table dédiée doit être créée en base de données. Une fois référencée, on peut alors choisir d'enregistrer un ou plusieurs styles suivant le nom de la couche géographique dans la base de données. L'interface de QGIS récupère automatiquement ces styles et propose à l'utilisateur une liste de choix (l'utilisateur reste bien entendu libre de créer son propre style de zéro (from scratch) et indépendamment des styles stockés en base de données).

À propos des formulaires de saisie

Les formulaires de saisie permettent de saisir/modifier les données attributaires une fois que vous avez ajouté un objet géométrique. C'est l'un des fleurons de QGIS tant la richesse de cette partie de QGIS est riche. Avec de bons formulaires de saisie, on peut tout à fait créer une véritable application de saisie métier complètement assistée et pertinente par rapport au contexte. QGIS 2.16 continue encore d'améliorer les formulaires avec les nouveautés qui suivent…

Éditions multiples

Une autre nouveauté d'ampleur va permettre un gain substantiel de productivité pour les utilisateurs qui doivent saisir des données qui se répètent fréquemment pour certains attributs: QGIS 2.16 permet l'édition multiple de données attributaires.

Il existe maintenant un outil spécifique de "saisie attributaire multiple" qui ouvre un formulaire de saisie spécial. Ce dernier applique les valeurs d'attributs saisies à l'ensemble des entités sélectionnées.

Concrètement, si vous avez une couche d'arbre, vous pouvez sélectionner tous les points dont vous savez qu'ils sont des chênes (manuellement ou avec une requête adaptée) et modifier la valeur du champ "caduque" à True pour l'ensemble de la sélection. Cela permet de gagner vraiment du temps (on n'est pas obligé de passer chaque objet en revue) et de s'assurer que la saisie attributaire est homogène.

Contraintes de saisie

Ce nouvel élément permet de s'assurer que la saisie des attributs sera conforme à une ou plusieurs règles. D'abord, il est possible d'indiquer qu'un champ doit être non nul, indépendamment de ce qui est indiqué dans le stockage sous-jacent (une contrainte NOT NULL dans une base de données par exemple).

Pour aller plus loin, il est maintenant possible d'indiquer pour chaque champ une contrainte de saisie. La grammaire des contraintes est basée sur les expressions QGIS, ce qui permet une richesse de contrainte quasiment infinie. On peut donc indiquer qu'une valeur numérique doit être comprise entre telle et telle valeur ou que le contenu d'un texte doit satisfaire une expression rationnelle.

Lorsque le champ n'est pas conforme à la contrainte, la couleur de fond de l'élément de saisie est en rouge ce qui permet à l'utilisateur d'identifier facilement et visuellement que sa saisie n'est pas conforme (l'affichage est bien sûr dynamique). Chaque élément de saisie dispose d'un conseil (ToolTip) indiquant ce qui ne va pas. On peut même faire afficher un message personnalisé pour décrire ce qui ne va pas.

Enfin, il y a une barre d'affichage en haut du formulaire qui récapitule ce qui ne va pas. Voici un exemple de formulaire avec contrainte:

Documentation

Pour une fois, parlons d'autre chose que du code ou de nouvelles fonctionnalités : parlons de la documentation ! Comme vous avez pu le remarquer au cours des dernières dépêches, QGIS est un logiciel complet, complexe et qui fait face à un grand nombre de publications de nouvelles fonctionnalités. C'est justement pour toutes ces raisons qu'un logiciel de ce type gagne à être bien documenté, ne serait-ce que pour que ses utilisateurs ne soient pas pris au dépourvu.

Voyons quelles sont les évolutions sur ce point…

Toute la doc est faite ;-)

L'équipe en charge de la documentation s'est bien déchirée sur cette version 2.16. En effet, elle a réussi, via un système de création de tickets automatiques (via GitHub) pour chaque nouvelle fonctionnalité à fournir suffisamment de travail pour documenter chaque point lié à chaque ticket. On peut maintenant dire que la documentation de la version LTR (la version 2.14) est complète, tout du moins quasiment exhaustive. Le choix de se focaliser sur la version LTR est facilement compréhensible: autant se concentrer sur la version qui a le plus de chances d'être déployée en environnement de production…

Vous pouvez consulter la documentation du manuel de l'utilisateur à partir de cette page. Attention, il est vraisemblable qu'elle ne soit pas traduite complètement en français (mais il n'y a aucun problème pour que votre participation soit bien prise en charge…)

Rendons-donc hommage à la vénérable équipe en charge de la documentation qui a réalisé un travail d'un grand intérêt pour les utilisateurs finaux qui pourront enfin disposer d'une documentation complète de chaque fonctionnalité introduite dans QGIS depuis la version 2.10, jusqu'à la version 2.14.

L'API d'authentification sécurisée est complètement documentée.

Introduite dans la version 2.12 de QGIS, l'authentification sécurisée permet de stocker de manière sécurisée l'ensemble des comptes/mots de passe ou certificats clients utilisés pour se connecter à diverses bases de données ou à divers services web. L'authentification sécurisée fonctionne un peu à la manière de celle de Firefox où un mot de passe principal permet de sécuriser un registre contenant toutes les données d'authentification.

Jusqu'à présent, en dehors des changements visuels et du code, il n'existait pas de documentation utilisateur sur cette partie importante pour la sécurité des utilisateurs. C'est un point délicat car l'authentification sécurisée reste finalement assez complexe à expliquer et à utiliser car il faut comprendre de nombreux concepts pas forcément clairs pour des géomaticiens plus cartographes qu'administrateurs système. Avec la version 2.16, c'est maintenant corrigé dans le manuel utilisateur. Vous n'avez maintenant plus d'excuse à continuer de stocker vos mots de passe en clair (dans les fichiers de configuration de QGIS)…

Rasters

Parlons un peu du parent pauvre de QGIS (même s'il les gère déjà assez bien) : les rasters. Pour information, il s'agit de fichiers bitmap géoréférencés, utiles pour afficher des images comme des orthophotos ou des représentations de plans (style le SCAN25 de l'IGN). Un raster est également une grille contenant une valeur précise pour chaque cellule.

Nouveau rendu pour les MNE

Les Modèles Numériques de Terrain sont des couches rasters un peu particulières : au lieu de stocker une valeur ou un pixel, il stocke l'altitude (ou l'élévation par rapport à un niveau zéro) dans chaque cellule. Suivant sa résolution, on a donc une représentation plus ou moins fine de l'altitude du terrain couvert par l'emprise de la couche.

Traditionnellement, un des usages basiques des MNE est de représenter une couche d'ombrage suivant la hauteur et la position du soleil pour donner un rendu plus facilement interprétable pour l'utilisateur final. C'est ce que vous pouvez lire facilement sur une carte SCAN25 de l'IGN qui affiche les versants nord plus sombres que les versants sud exposés au soleil. Cela permet de se rendre compte plus facilement du relief.

Pour faciliter cet affichage, QGIS 2.16 propose un rendu tout prêt dénommé "Ombrage". Il suffit de le sélectionner et de paramétrer la position du soleil pour obtenir rapidement et efficacement une couche d'ombrage.

Classification basée sur les quantiles

Pour les rasters disposant d'une seule bande et utilisant la représentation en pseudo-couleur, il existe un nouveau mode de classification automatique, basé sur les quantiles (auparavant, il n'y avait que les modes continus et intervalles égaux).

Saisie géométrique

Couches en lecture seule (dans le projet)

Cette nouvelle fonctionnalité permet au créateur du projet cartographique qui n'est pas forcément l'utilisateur final d'indiquer quelles sont les couches/tables qui ne doivent pas être modifiées (lecture seule) et ce, indépendamment des droits d'écriture de l'utilisateur final.

Cette option est disponible dans les propriétés du projet -> identification des couches. Si une couche est marquée comme étant en lecture seule, l'utilisateur final du projet ne pourra pas la modifier, à dessein ou par inadvertance (plutôt ce qui est l'objectif de cette nouvelle fonctionnalité). Cela permet de s'assurer qu'aucune opération de modification n'aura lieu.

Bien entendu, l'utilisateur final garde la possibilité de modifier le fichier de projet (s'il en a les droits d'écriture ou en dupliquant le fichier de projet) pour désactiver ces options mais l'intérêt principal est bien d'éviter les modifications par mégarde qui peuvent se produire dans certains cas (nombreuses couches disponibles, couches avec des noms proches, etc.).

Expressions

Les expressions sont un peu le moteur SQL de QGIS. Elles permettent de paramétrer l'affichage (taille, position, couleurs, etc.) de pratiquement n'importe quelle partie de QGIS à l'aide du contenu d'un ou de plusieurs champs ou à l'aide de fonctions d'expressions présentes dans le moteur (elles sont très nombreuses: on en compte plus de 200 !). Pratiquement tout ce qui est paramétrable dans QGIS peut recevoir une valeur fixe ou une expression.

Comme chaque nouvelle version, de nouvelles expressions font leur entrée ainsi que de nouveaux mécanismes.

Utilisation de paramètres nommés

Jusqu'à présent, lorsque vous utilisiez les fonctions d'expression (comme la fonction substr qui effectue des découpages de chaînes de caractères), vous deviez en respecter la syntaxe et notamment l'ordre des paramètres. Parfois, cette syntaxe n'est pas facilement compréhensible sans lire l'aide en ligne (disponible dans l'éditeur d'expression, par défaut). De même, il fallait absolument respecter l'ordre des paramètres.

La nouvelle version de QGIS introduit les paramètres nommés (un peu comme ce qu'on peut trouver avec les paramètres nommés de Python). Ainsi, au lieu d'écrire l'expression suivante : substr('QGIS rocks !', 0, 4), vous pouvez écrire substr(input_string:='QGIS rocks !', startpos:=0, length:=4) ou encore substr(startpos:=0, input_string:='QGIS rocks !', length:=4).

Cela permet de mieux comprendre quels sont les paramètres utilisés et de modifier leur ordre d'apparition comme bon vous semble.

Amélioration des fonctions de calcul de dates et d'intervalles de temps

QGIS dispose d'une panoplie conséquente de fonctions qui gèrent les dates et les intervalles de temps (environ une douzaine plus les opérateurs).
Maintenant, les opérateurs sont plus "intelligents" :

• Il est possible d'ajouter une heure (une heure sans date) à une date (une date sans heure) pour former une date complète (date+heure) sous la forme: date + heure.
• L'opérateur - retourne maintenant des intervalles au lieu de dates/heures ou date complète, ce qui est plus simple à interpréter.

Fonctions d'agrégation

Un des derniers points qui manquait dans la gestion des expressions était les fonctions/opérateurs d'agrégation. En SQL, il s'agit d'opérateurs permettant d'effectuer des "calculs" selon un groupe de données (géré avec une clause GROUP BY). Comme le moteur d'expression s'apparente à un moteur SQL, il n'est pas surprenant de voir arriver des fonctions spécifiques permettant de gérer ces regroupements. L'intérêt est de pouvoir effectuer des calculs sur des données qui ne sont pas stockées dans des bases de données (des fichiers ShapeFile par exemple).

Prenons quelques exemples simples d'agrégations:

• count("especes"): permet de compter toutes les valeurs de l'attribut "especes" dans la couche sur laquelle s'applique l'expression.
• sum("population", "région"): on utilise la couche des départements avec un champ "population" par département et une colonne "région" qui indique à quelle région le département appartient et le résultat sera une liste de sommes de population par région.

La liste des fonctions d'agrégation simple est finalement assez fournie et devrait répondre à la majorité des besoins : compter, faire la somme, calculer la moyenne l'écart-type ou la médiane, trouver le minimum/maximum, concaténer, etc.

Une fonction d'agrégation plus généraliste est dédiée aux tables qui disposent de relations entre elles (définies au niveau de QGIS et non au niveau de la base de données). Elle se nomme relation_aggregate et se charge de réaliser l'agrégation sur une couche fille, à partir du nom de la relation.

Il existe enfin une fonction générique qui permet de réaliser une opération d'agrégation sur une couche différente de la couche sur laquelle s'applique l'expression. Il est alors possible de la combiner avec des données de la couche courante pour réaliser des calculs spécifiques. Par exemple, si vous désirez réaliser un filtre d'une couche sur un champ dont la valeur doit être supérieure à la moyenne d'un champ d'une autre couche.

Cette fonction se nomme simplement aggregate et s'utilise avec la syntaxe: aggregate("autre couche", "opération d'agrégation (sum/count/etc.)", "attribut/expression sur laquelle se porte l'agrégation").

Enfin, sachez que tous les calculs réalisés avec des agrégations sont mis en cache, si vous utilisez un regroupement plusieurs fois, un seul calcul sera effectué.

Traitements

Les outils de traitements ou de géo‐traitements permettent de réaliser des manipulations chaînées sur des données, par exemple, retourner une couche de centroïdes sur une couche en entrée ou de calculer des bassins versants à partir d’une ou plusieurs couches rasters.

D'un point de vue interne, les traitements de QGIS sont intégralement gérés par une extension de cœur de projet (core) dénommée Processing et écrite en Python.

Suppression de fTools

fTools est le nom donné à une extension de cœur de projet (core) qui avait pour objet de proposer des outils de traitements spatiaux sur des couches vectorielles. Sa réalisation était assez ancienne et son usage est très répandu chez les utilisateurs de QGIS qui ont l'habitude de l'employer à travers le menu 'Vecteur'.

Néanmoins, avec le temps, son usage faisait vraiment doublon avec les géo-traitements de QGIS : depuis quelques versions, la majorité des traitements de fTools étaient disponibles dans le panneau des traitements et l'utilisateur pouvait alors être un peu dérouté par la présence de deux outils situés à deux endroits différents mais réalisant (à peu près) la même chose.

Du point de vue de la maintenance du code, c'était aussi beaucoup d'effort : il fallait maintenir et synchroniser des algorithmes semblables dans deux endroits différents du code. Pire, il arrivait parfois qu'un bug affecte l'un des deux outils mais pas l'autre. Il était donc temps de mettre fin à ce problème.

C'est donc le cas pour cette version : fTools a été retiré de QGIS. Néanmoins, comme son usage était très répandu, le menu Vecteur a été conservé pour ne pas dérouter les habitudes des utilisateurs de QGIS. Les entrées du menu redirigent simplement vers un géo-traitement précis. Les icônes de fTools ont également été reprises comme icônes spécifiques pour chaque traitement disponible (encore une fois, pour perturber le moins possible les utilisateurs).

Voilà un problème à peu près réglé (il peut rester quelques bugs de "migration"). Un autre module va sans doute connaître le même sort dans l'avenir : l'extension GdalTools qui réalise des géo-traitements rasters avec les utilitaires de GDAL et qui sont également présents sous forme de géo-traitements dans Processing.

GRASS7

La dernière version de QGIS disposait de quelques traitements GRASS7 supplémentaires (notamment les modules v.net gérant les couches vectorielles de réseau). Pour QGIS 2.16, c'est l'intégralité (il doit manquer un seul traitement sur la totalité de ce que GRASS7 propose) des traitements de GRASS7 qui ont été portés dans Processing mettant ainsi à disposition des utilisateurs plus de 300 traitements portant sur des couches rasters, vecteurs ou d'images. Il faut noter que GRASS reste une référence en matière de traitements sur les couches rasters.

Dans ce cas de figure, Processing agit comme une interface d'accès aux traitements GRASS en réalisant en arrière plan la création d'une base de données GRASS temporaire, l'injection des données à traiter, le lancement des traitements via des commandes internes GRASS (ce sont donc vraiment les binaires GRASS qui font le travail) et l'export des données à récupérer dans QGIS depuis la base de données GRASS temporaire.

Ces ajouts ne concernent que les traitements de GRASS dans sa version 7 et non dans sa version 6, simplement pour des raisons de coût de maintenance. Par ailleurs, la version stable actuelle de GRASS est la version 7 (même si on rencontre encore la version 6 dans de nombreuses distributions GNU/Linux stables, Debian Jessie pour ne pas la citer).

En plus de ces ajouts de modules, un premier jet de tests unitaires ont été intégrés pour les traitements GRASS7 (principalement sur les modules i.* et r.*). Au total, ce sont près de 115 modules qui disposent d'un test unitaire. Cela devrait permettre de mieux détecter les problèmes d'interaction entre Processing et GRASS lors des évolutions de GRASS. Ces tests unitaires sont très basiques : ils se contentent de lancer le traitement avec un jeu de données réduit et avec des paramètres par défaut. Mais, il faut bien commencer par quelque chose ! À l'avenir, on peut penser que chaque traitement GRASS7 de Processing disposera au moins d'un test unitaire.

Gestion de l'écriture de tables sans géométries

Processing gère maintenant l'écriture dans des tables sans géométrie. Cela permet de remplir des fichiers CSV par exemple. Pour l'instant, seul le traitement 'Refactoriser les champs' (qui permet de modifier la structure et le contenu d'une table attributaire en entrée) en bénéficie mais d'autres traitements devraient pouvoir utiliser facilement cette fonctionnalité, inscrite dans les classes de base de Processing.

Support des expressions dans les entrées des traitements

Jusqu'à présent, les expressions n'étaient pas disponibles dans Processing. C'est maintenant fait pour au moins quelques types de paramètres d'entrée (chaîne de caractères, nombre) ou de sortie. Dans ce cas, les expressions serviront à déterminer la valeur du paramètre. Cela peut être utile pour, par exemple, formater le nom du fichier de sortie de manière dynamique en fonction de la valeur d'un champ.

À vous la puissance des expressions dans vos géo-traitements !

Composeur d'impression

Le composeur d'impression de QGIS est l'interface graphique qui permet de gérer la mise en page d'une carte. En effet, QGIS présente essentiellement une vue cartographique qui est faite principalement pour interagir avec les données ce qui est très souvent incompatible avec les opérations de mise en page (qui affichent d'autres choses que la carte). Ce module très complet permet de créer facilement des cartes destinées à être imprimées sur papiers (ou en image/PDF).

Dessins de formes : polygones/polylignes

Dans cette version, le composeur permet de tracer des polygones et des polylignes directement dans la mise en page. Jusqu'à présent, on pouvait ajouter des formes (rectangle/cercle/ellipse), des fichiers SVG ou bitmaps, ou encore des flèches. On peut maintenant tracer des formes plus libres. Cela permet de mettre en valeur certaines données plus facilement : vous pouvez dessiner un polygone plus complexe pour mettre en valeur une zone précise sur une carte à imprimer (même s'il y a d'autres techniques pour le faire automatiquement).

Géoréférencement des cartes en sortie d'impression par défaut

QGIS permet de géoréférencer une impression de carte. Concrètement, les fichiers créés par le composeur d'impression peuvent être géo-référencés: les coordonnées de la d'emprise de la carte qu'ils représentent sont stockées directement dans le fichier (pour les formats TIFF et PDF). Cela permet d'ouvrir ces fichiers (dans QGIS mais également dans d'autres logiciels SIG) comme s'il s'agissait de couches rasters.

Auparavant, QGIS proposait de stocker les informations de géo-référencement dans un fichier dédié (world file). Maintenant, par défaut, la donnée est stockée dans les métadonnées du fichier en sortie (le fichier world est produit uniquement si l'option relative est cochée). Pas de révolution de ce côté mais une meilleure intégration de l'emprise spatiale dans toute carte produite par QGIS.

Plugins ou extensions

Les plugins ou extensions de QGIS sont des parties fonctionnelles supplémentaires qui s'appuient sur l'API de QGIS et qui offrent des fonctionnalités non couvertes par le cœur de projet (core), suivant le principe de Firefox et de ses greffons. L'API permet de (pratiquement) tout modifier dans QGIS au niveau de l'interface homme-machine ainsi que de lancer n'importe quelle action sur des données lisibles par QGIS. Le potentiel est donc très important.

Certaines extensions prennent de l'ampleur et finissent par être intégrées et gérées par l'équipe de développement de QGIS (comme Processing ou DBManager). Les autres extensions sont développées sur des dépôts tiers mais sont listées sur le dépôt officiel. Plus de 1000 greffons sont disponibles et sont directement installables depuis QGIS.

Refonte du plugin Globe

Pour cette version de QGIS, le greffon Globe a été revu. Il permet d'apporter une fenêtre de globe terrestre permettant d'avoir un rendu en (pseudo) 3D des données présentes dans le projet cartographique en cours sur un globe terrestre. C'est un peu le Google Earth en local de QGIS. Avec le temps, le plugin semblait prendre un peu d'âge et n'évoluait plus. Il a donc été remis au goût du jour.

Au menu des nouveautés :

• Remise à niveau technique avec incorporation d'une nouvelle version de OSgEarth.
• Adoption du nouveau moteur géométrique de QGIS (qui date d'il y a quelques versions maintenant).
• Extrusions des objets de couche avec une dimension Z ou avec une expression.
• Ajout d'un onglet de configuration dans les propriétés de la couche : cela permet de paramétrer la représentation de la couche dans le greffon (si ce dernier est activé) et de stocker ces paramètres dans le projet QGIS.

Informations sur la version 3.0

Informations générales

Comme nous l'avions déjà présenté dans les précédentes dépêches sur QGIS, l'objectif de la version 3.0 de QGIS est la migration vers la version 5 de Qt et la version 3 de Python.

Sachez qu’il est maintenant tout à fait possible de compiler QGIS avec Qt5 et Python3. Le résultat n'est, pour le moment, pas garanti en termes d’absence de bugs mais, depuis quelques mois, on peut avoir un binaire QGIS équipé de ces options qui fonctionne dans les grandes lignes.

Du point de vue du code, le dépôt Git présente dès maintenant 2 branches master:

• master qui est la version 3.0.
• master_2 qui contient des évolutions uniquement destinées à la version 2.x de QGIS (pour des corrections de bugs principalement).

On voit bien que tout est axé sur la version 3.0: c'est la branche par défaut !

Tester la version 3.0 de développement

Voici quelques instructions pour pouvoir disposer d'un QGIS sous Qt5 et Python3 avec la prise en charge de GRASS7 sous Debian Stretch.

Il vous faudra d'abord installer de nombreuses dépendances (oui, QGIS est un logiciel complexe qui fait beaucoup de choses en se reposant au maximum sur ce qui existe déjà):

# apt install build-essential cmake flex bison pyqt5-dev qttools5-dev qtpositioning5-dev libqt5svg5-dev libqt5webkit5-dev libqt5gui5 libqt5scripttools5 qtscript5-dev libqca-qt5-2-dev grass-dev libgeos-dev libgdal-dev libqt5xmlpatterns5-dev libqt5scintilla2-dev pyqt5.qsci-dev python3-pyqt5.qsci libgsl-dev txt2tags libproj-dev libqwt-qt5-dev libspatialindex-dev pyqt5-dev-tools qttools5-dev-tools qt5-default python3-future python3-pyqt5.qtsql python3-psycopg2 python3-yaml python3-pygments python3-owslib python3-nose2 python3-six python3-markupsafe python3-dateutil python3-jinja2 python3-httplib2 python3-tz grass grass-dev grass-doc

Il vous faut ensuite récupérer les sources de QGIS. Vous pouvez le faire simplement en clonant le dépôt git hébergé sur Github (attention, il est assez lourd):

$ git clone git://github.com/qgis/QGIS.git
$ cd QGIS
$ mkdir build-master
$ cd build-master

Ensuite, reste à préparer la compilation, effectuer la dite compilation puis l'installation. QGIS repose sur CMake:

$ ccmake -D ENABLE_QT5:BOOL=TRUE \
         -D PORT_PLUGINS:BOOL=TRUE \
         -D CMAKE_INSTALL_PREFIX:PATH=/usr/local/ \
         -D WITH_ASTYLE:BOOL=TRUE \
         -D WITH_INTERNAL_QWTPOLAR:BOOL=TRUE \
         -D WITH_INTERNAL_YAML:BOOL=FALSE \
         -D WITH_INTERNAL_PYGMENTS:BOOL=FALSE \
         -D WITH_INTERNAL_OWSLIB:BOOL=FALSE \
         -D WITH_INTERNAL_NOSE2:BOOL=FALSE \
         -D WITH_INTERNAL_SIX:BOOL=FALSE \
         -D WITH_INTERNAL_MARKUPSAFE:BOOL=FALSE \
         -D WITH_INTERNAL_DATEUTIL:BOOL=FALSE \
         -D WITH_INTERNAL_JINJA2:BOOL=FALSE \
         -D WITH_INTERNAL_HTTPLIB2:BOOL=FALSE \
         -D WITH_INTERNAL_QEXTSERIALPORT:BOOL=TRUE \
         -D WITH_INTERNAL_PYTZ:BOOL=FALSE \
         ..

Cette commande ouvre une interface ncurses qui vous permet d'affiner les options de compilation et de vérifier que vous disposez de toutes les dépendances. Confirmez avec la touche 'c' puis générez les Makefile avec la touche 'g'. L'option PORT_PLUGIN de CMake permet de déclencher le mécanisme de conversion des extensions en Python actuellement codées en Python2. Ce mécanisme est présenté dans le paragraphe ci-dessous. Les autres options (WITH_INTERNAL à FALSE) permettent d'utiliser les bibliothèques Python3 de votre distribution plutôt que celles qui sont livrées avec le code de QGIS.

On peut ensuite lancer la compilation et l'installation:

$ make -jX # X variable suivant le nombre de cores de votre CPU
$ sudo make install

La compilation prend un temps non négligeable: compter environ 10 à 20 minutes sur une machine récente.

Ensuite, pour lancer QGIS, il vous faudra peut-être modifier la variable d'environnement LD_LIBRARY_PATH et y ajouter l'emplacement des bibliothèques partagées de QGIS (normalement dans /usr/local/lib) puis taper qgis.

Le mécanisme de conversion des plugins "core"

En ce qui concerne la conversion des scripts Python de Python2 vers Python3, un mécanisme de conversion automatique a été mis en place : lors de la compilation, le code des ensembles de QGIS sous Python2 (principalement les plugins de cœur d’application "core") est passé à la moulinette de l'outil 2to3. Il en résulte une cible sous Python3 directement utilisable. Pour utiliser ce mécanisme, il suffit de cocher l'option CMake PORT_PLUGINS (qui est automatiquement activée lorsqu'on compile avec l'option WITH_QT5 d'ailleurs).

Mais il n'y a pas que la conversion de Python2 vers Python3 à gérer : il y a également l'évolution de PyQt4 vers PyQt5 !

En utilisant la bibliothèque Python future et un peu de code, on obtient un ensemble de conversions automatiques qui gèrent également la transition PyQt4 vers PyQt5. Pour l'instant, le script fix_pyqt gère correctement le renommage des modules ainsi que le nom des méthodes.

Néanmoins, ce mécanisme n'est pas parfait (il faut bien laisser un peu de travail aux devs quand-même !) : lorsque des méthodes ou des fonctions changent de paramètres ou de retour, fix_pyqt ne gère rien. Il en résulte un résiduel assez important de bugs pas nécessairement faciles à trouver car, dans la majorité des cas, l'ensemble du plugin va se lancer correctement (pas de plantage au lancement) mais c'est uniquement l'activation d'une option précise qui va tout vraquer. Même avec de bons tests unitaires, c'est assez difficile à diagnostiquer… C'est cet ensemble de bugs qu'il faudra gérer et c'est pour cela qu'il y a de fortes chances que le calendrier de la version 3.0 soit décalé par rapport au rythme de publication habituel (qui n'est que de 4 mois).

Pour terminer sur ce port, disons-nous que passer à Python3 va sans doute nous permettre de mettre fin au problème majeur des plugins Python de QGIS : la gestion de l'unicode (mon petit doigt me dit que le simple fait d'avoir un nom de logiciel comme "Nødebo" devrait entraîner une bonne série de commits correctifs :-)) !

Conclusions

Cette version 2.16 continue à consolider le rôle de QGIS comme leader des SIG bureautiques libres. Les nouvelles fonctionnalités sont très nombreuses, sans parler des traditionnelles corrections de bugs. QGIS se place sans problème au niveau des meilleurs SIG (propriétaires et libres) et les professionnels y retrouveront des fonctionnalités qui faciliteront grandement leur travail. Signe qui ne trompe pas: la page des sponsors montre que le financement de QGIS se renforce de version en version et que les acteurs qui contribuent au projet sont de plus en plus nombreux et prêts à mettre un peu d'argent sur la table. Bien entendu, le budget n'a rien à voir avec celui d'un grand groupe mais cela démontre qu'on peut tout à fait financer un gros projet comme QGIS à plusieurs et ce, peu importe sa provenance géographique.

L'avenir s'ouvre également sur de bons auspices avec la version 3.0 qui prend un chemin sérieux. Il y a de grandes chances qu'elle devienne la prochaine version de QGIS et que la version 2.16 soit la dernière de la série 2.x même si un décalage de calendrier est fort probable (publication d'une version officielle tous les 4 mois). La version 3.0, en plus de la remise à niveau de l'environnement technique introduit également des modifications profondes dans l'API de QGIS. Mais ces modifications vont dans le bon sens: nous allons pouvoir nous débarrasser de tout le vieux code qui était nécessaire pour garantir une compatibilité de la chaîne QGIS dans la branche 2.x et nous appuyer sur des objets et des méthodes plus simples à utiliser et offrant un accès plus rapide aux dernières fonctions avancées des différents composants de QGIS. Par ailleurs, la version 3.0 ne sera pas seulement une mise à jour des principales bibliothèques de base (Qt5) mais elle présentera également de nombreuses nouvelles fonctionnalités, comme d'habitude.

Souhaitons aux développeurs que toutes leurs nouvelles implémentations fonctionnent du premier coup et que le code soit fluide sous le clavier !

Malgré les 200 contributeurs sur GitHub, le projet a toujours besoin de contributions dans différents secteurs. Venez nous rejoindre en fonction de vos compétences, vos talents ou votre volonté de nous aider !

• 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. Si vous n'y connaissez rien en SIG, vous pouvez nous aider en vous concentrant sur la qualité du code ou en écrivant des tests unitaires.
• 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 étudiant en informatique ou dans les SIG: pour l'été prochain, si vous n'avez pas grand chose de prévu, sachez que QGIS bénéficie du programme Google Summer of Code. Je vous recommande de trouver un "mentor", membre du projet. Sachez que vous pouvez nous aider sur pas mal de points, y compris en dehors du code ou du domaine des SIG. Ainsi, par exemple pour cette année, un des projets QGIS du Summer of Code consiste à monter une bibliothèque partagée de styles de couches, permettant aux utilisateurs de QGIS de disposer d'une banque commune de représentations graphiques pour leurs projets.
• 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.
• Je ne suis rien de tout ça !: pas de problème, vous pouvez nous aider sur de nombreux points. D'abord, vous pouvez faire un don au projet Votre argent ira abonder le financement de nouvelles fonctionnalités ou encore le programme de corrections de bugs. Si vous êtes DSI/décideur ou référent technique, n'hésitez pas à demander une étude d'évaluation de QGIS en interne si vous avez des projets informatiques qui intègrent de la géographie. Si vous êtes enseignant/scientifique, n'hésitez pas à faire la promotion de ce SIG libre que vos étudiants pourront installer facilement (et gratuitement) sur leurs machines personnelles. etc.

Aller plus loin

• Principales évolutions en images depuis la dernière version (en cours de traduction) (455 clics)
• Page de téléchargement du projet QGIS (209 clics)
• Site principal de QGIS (335 clics)
• Dépôt git officiel des sources de QGIS (119 clics)
• Dépôt git officiel de la migration vers la version 3.0 (109 clics)
• Dépêche précédente pour la sortie de QGIS 2.14 LTR « Essen » (110 clics)