Faire des cartes d'analyse avec QGIS 1.3.0 et PostGIS 1.3 🔗

Posted by MĂ©dĂ©ric Ribreux 🗓 In blog/Qgis/

#GIS #QGIS

Introduction

Dans le monde des SIG libres, le choix des outils d'analyse est assez limité:

D'oĂč la question: existe-t-il un moyen simple et efficace de reprĂ©senter de l'information gĂ©ographique travaillĂ©e et non brute de dĂ©coffrage ? Ma tentative de rĂ©ponse vient Ă  la suite de cet article
 Pour faire simple, disons, que oui c'est possible avec un peu d'entraĂźnement et surtout une bonne base de travail.

Le contexte de ce travail est d'utiliser uniquement QGIS et PostGIS pour afficher des cartes d'analyses. Une carte d'analyse est une carte qui croise de l'information géographique avec des données alphanumériques. Elles sont trÚs utilisées en statistiques par exemple et en termes d'efficacité, avec un outil comme MapInfo Pro (utilisation des analyses thématiques) et des données correctes, ce genre de carte prend 15 minutes environ à créer.

Nous voulons effectuer des croisements d'informations simples. Par exemple, colorier une commune en fonction d'une valeur donnée. Cette valeur n'est pas située dans une table géographique mais dans une table simplement alphanumérique.

Les capacitĂ©s de traitement de QGIS sont vraiment trĂšs limitĂ©es. On peut utiliser certains plugins genre ftools mais leur utilisation est assez complexe et surtout pas rĂ©servĂ©e Ă  ce que nous voulons faire. En plus, ça ne fonctionne pas sur PostGIS. D'oĂč l'idĂ©e d'utiliser les capacitĂ©s de traitement de PostgreSQL et de PostGIS pour faire le travail. QGIS se contentera de l'affichage.

Tout est trùs simple


logo PostGIS logo QGIS

Prérequis

Je suppose que vous avez QGIS (l'exemple fonctionne avec la version 1.3.0 sous Debian Squeeze, compilée à la main, car le paquet disponible sur gfoss.it est buggé) et un serveur PostgreSQL sous la main avec l'extension PostGIS. Si ce n'est pas le cas, Google est votre ami et il vous donnera des tonnes de sites qui expliquent comment on fait pour mettre en place l'infrastructure.

Pour simplifier le sujet serveur PostgreSQL, on va dire qu'il est situé sur localhost, que la base de données utilisée sera nommée "GEOBASE_LOCALE" et que l'utilisateur qgis a tous les droits dessus, y compris celui de créer des tables.

Je suppose aussi que vous disposez de l'outil ogr2ogr (pour le chargement des données).

Une modélisation light

Voyons maintenant ce que ça donne sur un exemple concret:

La table DEPARTEMENT est une table contenant le dessin géométrique des communes du département. Elle est composée des champs suivants:

La table UTILISATEUR_LINUX contient des informations alphanumériques sur les utilisateurs de GNU/Linux. Une ligne correspond non pas à une commune mais à un utilisateur.

Pour chaque ligne, on a les champs suivants:

Le lien entre la table géographique et la table alphanumérique est le code INSEE (champ INSEE dans les deux tables).

Pour la table UTILISATEUR_LINUX, on aurait pu choisir un modĂšle plus simple (genre une ligne par commune) mais le modĂšle de cette table va nous permettre de faire quelques agrĂ©gations
 Ça ne fait jamais de mal de voir ce qu'on peut faire comme calculs avec un peu de SQL.

Au final, nous allons créer une table géographique nommée LINUX qui contiendra les objets géographiques et les données alphanumériques qui nous intéressent à savoir:

Récupérer les données

Pour les données géographiques, j'ai utilisé la couche GEOFLA des départements produite par l'IGN. Ces données sont non libres (pas d'exploitation commerciale) mais gratuites au format Shapefile (lien pour les télécharger) . Je vous conseille de télécharger dans la projection RGF93 car la suite des manipulations utilise cette projection.

Les données sont au format shapefile. Il faut donc les convertir et les charger dans le serveur PostGIS, ce que nous allons faire avec shp2pgsql comme suit:

$ shp2pgsql -s 2154 -d DEPARTEMENT DEPARTEMENT | psql -h localhost -U qgis -W GEOBASE_LOCALE

L'option -s 2154 permet de spécifier la projection (2154 correspond à RGF93) et -d permet d'effacer la table si elle existe déjà.

Pour les données de la table UTILISATEUR_LINUX, j'ai créé une table remplie avec des valeurs aléatoires dont vous pouvez disposer ici. Il s'agit d'un script SQL contenant des valeurs aléatoires. Pour injecter les données, il suffit de faire:

$ psql -h localhost -U qgis -W GEOBASE_LOCALE -f UTILISATEUR_LINUX.sql

Quelques précautions techniques

Avant de crĂ©er une table gĂ©ographique, il ne faut pas oublier que QGIS impose certaines rĂšgles lors de la crĂ©ation de tables. D'abord, pour que QGIS liste la table LINUX, il est indispensable que les colonnes gĂ©ographiques soient renseignĂ©es dans la table "geometry_columns". C'est le comportement normal de PostGIS aussi, mais pas de PostgreSQL. L'ajout de cette information dans la table peut ĂȘtre effectuĂ© de deux maniĂšres. La technique utilisĂ©e est l'emploi de la requĂȘte suivante:

De plus, QGIS exige que la table dispose d'un champ d'identification qui doit ĂȘtre de type int et disposer d'une contrainte de clef unique. Enfin, QGIS travaille avec des valeurs plutĂŽt en rĂ©el (float8) qu'en entier (integer). Cette contrainte impose que les rĂ©sultats de requĂȘte soient convertis avant de pouvoir travailler avec.

Créer une couche avec des valeurs de référence et une donnée géographique

L'objectif est de créer une couche en utilisant une jointure pour lier un objet géographique à une ou plusieurs valeurs. Ensuite, on utilisera QGIS pour affecter la couleur et gérer les classes.

Cette requĂȘte permet de crĂ©er la table gĂ©ographique LINUX en croisant les donnĂ©es gĂ©ographiques de la table DEPARTEMENT et les donnĂ©es alphanumĂ©riques de la table UTILISATEUR_LINUX en effectuant une agrĂ©gation d'informations (Nombre d'utilisateurs, nombre de machines, densitĂ© d'utilisateurs et densitĂ© de machines). Cette couche rĂ©pond aux exigences de QGIS.

Visualiser le résultat

Le travail est centré sur les onglets de propriétés de la couche dans QGIS:

C'est dans cet onglet que l'on peut régler la représentation de la couche. QGIS nous propose 4 modes de représentation:

densités réglages

Dans notre cas, seules les densités sont représentables avec les objets surfaciques des départements. Nous allons donc utiliser le symbole gradué. La représentation qui utilise ce mode est trÚs intéressante dans QGIS car elle permet de créer des classes de maniÚre assez simple:

Voici ce qu'on obtient:

Densité Linux

Créer une carte avec des points de couleur

Le principe est le mĂȘme que prĂ©cĂ©demment. Toutefois, au lieu de prendre l'objet gĂ©ographique, on va utiliser son centroĂŻde pour y positionner un symbole. Nous allons donc avoir besoin de la fonction PostGIS: ST_Centroid().

Cette requĂȘte permet de crĂ©er quasiment la mĂȘme table qu'auparavant mais gĂ©nĂšre des points et non des surfaces. Pour faire une carte digne de ce nom, il convient d'utiliser Ă©galement les surfaces, histoire d'amĂ©liorer le support visuel. On a donc intĂ©rĂȘt Ă  ouvrir les couches LINUX_POINT et LINUX (ordre des calques Ă©galement). La couche LINUX sert uniquement de fond de carte, on va donc l'ouvrir et choisir une couleur neutre.

Travaillons maintenant sur la couche LINUX_POINT:

nombre de réglages

Voici le résultat final:

Nombre de machines Linux

Utiliser des vues

Notre mode opĂ©ratoire permet de publier assez rapidement des cartes. Toutefois, si les donnĂ©es de la table UTILISATEUR_LINUX changent, il faut supprimer les couches (par la requĂȘte SELECT dropgeometrytable('COUCHE')) et relancer les requĂȘtes de croisement. Cela peut se rĂ©vĂ©ler assez fastidieux si la table change rĂ©guliĂšrement. Heureusement, PostgreSQL peut nous aider grĂące Ă  son concept de vue: une vue est une requĂȘte SELECT qui se lance Ă  chaque fois qu'on interroge la vue. Donc si la requĂȘte est longue, le rĂ©sultat met du temps Ă  s'afficher.

Pour utiliser des vues, il suffit d'employer le terme CREATE VIEW au lieu de CREATE TABLE dans les requĂȘtes de croisement d'information. L'intĂ©rĂȘt des vues c'est que l'on ne stocke rien en dur et que les donnĂ©es sont toujours Ă  jour par rapport Ă  la table de rĂ©fĂ©rence. Le plus important est bien d'affecter la colonne gĂ©omĂ©trie dans la table de rĂ©fĂ©rence.

Si on utilise ensuite QGIS, on ne verra aucune diffĂ©rence: la table est prĂ©sente et rien n'indique que c'est une vue. En revanche, le premier affichage est plus long: c'est Ă  ce moment que la requĂȘte est lancĂ©e. Dans notre cas, c'est assez rapide tout de mĂȘme.

Une idée: "Travailler avec des tables temporaires" ?

PostgreSQL supporte le concept de tables temporaires. Toutefois, ces derniĂšres se suppriment automatiquement Ă  la fin du pool de requĂȘte. Je n'ai pas trouvĂ© comment les utiliser concrĂštement. Les vues me semblent mieux adaptĂ©es Ă  notre objectif.

Références: