La nouvelle version 2.12 de QGIS « Lyon » est à présent disponible.

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.

 

Source : http://linuxfr.org/news/sortie-de-qgis-2-12-lyon