A Importation des données raster dans PostGIS
AA Préparer l’environnement
Nous utiliserons pour les RASTER la même installation de PostGIS documentée dans un module précédent ainsi que la même base de données formation .
Sous Windows, il est recommandé de modifier la variable système nommée
Pour le configurer, ouvrir le menu démarrer et chercher « propriétés système » puis l’ouvrir. Dans l’onglet « Paramètres systèmes avancés », cliquer sur « Variables d’environnement... ». Puis trouver la variable
Il faut alors ajouter dans la valeur le chemin vers les binaires exécutables de PostgreSQL en séparant par un point virgule. Mais comment connaître le chemin ? Les captures ci-dessous font état de « C:\Program Files\PostgreSQL\9.3\bin » mais la version peut être différente et il n’est pas exclus que l’installation soit dans un autre répertoire.
L’astuce consiste à chercher pgAdmin via la recherche du menu démarrer pour identifier son emplacement, qui est normalement le même que les autres utilitaires comme raster2pgsql.exe et psql.exe dont nous avons besoin.
Quand pgAdmin est trouvé, cliquer avec le bouton droit de la souris puis Propriétés . Il faut alors copier le répertoire indiqué par « Démarrer dans ».
Puis coller le répertoire dans la valeur de la variable Path après un point-virgule pour séparer des chemins pré-existants. Attention à bien enlever les guillemets.
Créons à présent notre répertoire de travail pour l’importation des rasters. Dans les captures suivantes, il s’agit de C:\Rasterwork , mais tout autre emplacement convient également. Une fois le dossier créé, il faut copier le raster des données sources QGIS\BCD_ALTI\MNT\MNT_25M_asc.asc en le renommant en mnt_25m.asc (avec l’explorateur Windows, faire un copié-collé ou bien un glissé-déplacé avec le bouton du milieu, pour copie et non déplacement).
AB Lancer raster2pgsql
Raster2pgsql est l’utilitaire fourni avec PostGIS pour importer un jeu de données raster dans la base PostgreSQL.
À l’instar de shp2pgsql, raster2pgsql ne se connecte pas directement à la base, mais produit les requêtes SQL qui créent le(s) raster(s) selon les options paramétrées. Ces requêtes SQL peuvent être enregistrées dans un fichier .sql qui sera ensuite exécuté par un client tel que psql ou pgadmin.
Pour commencer, ouvrir l’interpréteur de commandes (shell). Sous Windows, il s’agit d’un programme nommé cmd.exe qu’on peut lancer en utilisant le menu démarrer puis exécuter et taper cmd .
Dans l’invite de commande, faire « cd C:\Rasterwork » (ou autre chemin) pour se placer dans le répertoire de travail, puis exécuter dir pour lister les fichier et vérifier qu’on a bien notre fichier raster mnt_25m.asc .
Il faut ensuite appeler le programme raster2pgsql.exe qui a été installé avec PostGIS. Si la variable Path n’a pas été modifiée (comme indiqué plus précédemment), il faudra l’appeler par son chemin complet, qu’on obtiendra en faisant une recherche dans « C:\Program Files ».
Depuis l’invite de commande, on lance tout d’abord raster2pgsql sans argument pour vérifier que la commande est bien trouvée, et obtenir de l’aide sur son utilisation.
À présent, nous allons utiliser raster2pgsql pour importer le modèle numérique de terrain de la commune de la flèche nommé mnt_25m.asc du répertoire de travail. Pour générer le fichier SQL, exécuter : « raster2pgsql mnt_25m.asc >mnt_25m.sql ».
Pour effectuer l’importation proprement dite dans la base PostGIS, il faut ensuite exécuter le SQL dans la base concernée. On peut théoriquement utiliser pgadmin et ouvrir le fichier SQL dans la fenêtre SQL (fichier → ouvrir ), mais cette approche se révèlera limitée pour des fichiers SQL trop lourds, ce qui sera souvent le cas : pour un fichier raster donné, le fichier SQL pèse en général 2 à 3 fois plus lourd, soit 100 Mo ou 200 Mo pour un raster de 50 Mo telle que l’orthophoto 0468_6739-2040.tif . Pour cette raison, on utilisera le client psql.exe en ligne de commande.
Il faut donc appeler le client psql pour la base de données formation en indiquant le fichier mnt_25m.sql , comme ceci :
psql.exe -h localhost -U postgres -W -d formation -f mnt_25m.sqlUn mot de passe est demandé : c’est toujours celui de l’utilisateur postgres , c’est-à-dire postgres s’il n’a pas été changé.
La commande ne doit retourner aucune erreur. On peut alors vérifier avec pgAdmin que la table mnt_25m a bien été créée dans la base.
AC Vue raster_columns et contrainte raster
Se rendre dans pgAdmin et afficher le contenu
de la vue raster_columns
qui doit contenir une seule ligne, représentant le raster importé.
Cette vue est l’équivalent de la vue geometry_columns pour les rasters.
Pour l’instant, la plupart des colonnes sont vides concernant le raster importé, ce qui empêche son exploitation avec des outils externes tels que gdalinfo ou QGIS. De plus, l’identifiant de référence spatiale (SRID) n’a pas été précisé lors de l’import et n’est donc pas renseigné, ni dans les contraintes, ni dans le raster lui-même (colonne rast de la table mnt_25m ).
Nous allons utiliser la fonction UpdateRasterSRID pour mettre à jour le SRID. Le système de projection du MNT est le Lambert93, qui porte le numéro 2154 d’après la table spatial_ref_sys .
Dans la fenêtre SQL de pgAdmin, nous exécutons donc :
SELECT UpdateRasterSRID(’mnt_25m’, ’rast’, 2154)
À présent, nous allons ajouter toutes les contraintes pour rendre le raster exploitable par les outils externes. La fonction AddRasterConstraints fait cela automatiquement. Nous devons l’appeler comme ceci :
SELECT AddRasterConstraints(’mnt_25m’, ’rast’)
Retournons alors dans la vue raster_columns et rafraîchissons-la (F5). On obtient les valeurs suivantes :
- r_table_catalog = formation : c’est nom de la base de données
- r_table_schema = public : c’est le nom du schéma dans lequel la table se trouve
- r_table_name = mnt_25m : nom de la table
- r_raster_column = raster : nom de la colonne portant le raster
- srid = 2154 : identifiant de référence satiale du raster
- scale_x = 25 et scale_y = -25 : taille du pixel en coordonnées de projection géographique (largeur et hauteur, respectivement). La hauteur est négative car ici comme pour de nombreux rasters, la coordonnée Y en pixel évolue positivement de haut en bas quand la coordonnée Y géographique évolue positivement de l’origine vers le nord
- blocksize_x = 401 et blocksize_y = 401 : taille de chaque tuile, sujet que nous aborderons plus loin via la question du tuilage
- same_alignment = TRUE
- regular_blocking = FALSE
- num_bands = 1 : il n’y a qu’une seule bande car il s’agit d’un MNT simple
- pixel_types : comme chaque pixel est codé (2 bits, 4 bits, 8 bits, nombre à virgule flottante, etc., pour chaque bande
- nodata_values : valeurs interprétées comme « pas de données » (no data) pour chaque bande
- out_db : indique si le raster est stocké en interne ou en fichier externe, pour chaque bande (qui ont toutes la même valeur, TRUE ou FALSE, pour un raster stocké)
- extent : géométrie polygone représentant l’enveloppe géographique du raster
AD La question du tuilage
Contrairement aux données vecteurs qui sont unitaires (un vecteur est un objet en soi et chaque enregistrement d’une table vecteur a son vecteur spécifique, même s’il peut s’agir d’un MULTI-vecteur), la donnée raster peut se répartir en dalles pour des traitements plus efficaces. Le raster est ce qu’on appelle un « raster coverage », en Français « couverture raster », qui peut éventuellement comporter des trous.
C’est pourquoi, pour un raster d’une certaine taille, comme ceux qu’on manipule dans ce chapitre, un importera le raster sous forme de dalles qui font chaun l’objet d’un enregistrement spécifique dans la table. C’est la table toute entière qui représente le raster.
Grâce à la fonction ST_Tile (fournie à partir de PostGIS version 2.1), il est possible de générer une couverture raster avec tuilage régulier à partir d’un raster non-tuilé. Ceci n’est pas couvert par ce module d’introduction : on utilisera à la place l’option -t de l’utilitaire d’importation raster2pgsql pour générer un raster tuilé directement à l’import.
AE Vue raster_overviews et miniatures de rasters
Un raster est une grille de points régulièrement alignés dans une étendue géographique donnée. La résolution représente le nombre de points par unité géographique. Plus la résolution est grande, plus les calculs sont détaillés et plus l’affichage pourra être fin
(non pixellisé).
Or la résolution a un coût : un grand nombre de points signifie un poids important de données pour l’échange, ce qui peut être inutile lorsqu’on manipule le raster à petite échelle.
Pour cette raison, il est d’usage pour les rasters en général, d’utiliser des miniatures conjointement au raster d’origine. Le logiciel SIG saura sélectionner la miniature la plus adaptée pour ses traitements, ou le raster d’origine si nécessaire.
On parlera alors de structure pyramidale, où le raster donné est accompagné de ses miniature ½, ¼, 1/8, etc. Cette façon de faire est habituelle pour le format TIFF qui peut contenir ses miniature à l’intérieur du même fichier. D’autres stratégies offertes par les SIG consiste à générer des miniatures externes
: un .png
par exemple sera décliné en plusieurs fichiers.png
dans le même répertoire, représentant chacun une miniature donnée.
PostGIS RASTER permet de gérer des miniatures à l’intérieur de la base de données. La convention est la suivante : pour une table raster donnée, on maintient une table nommée o_N_raster , où raster est le nom de la table raster source et N le facture de miniature (2 pour ½, 4 pour ¼, etc.).
La vue raster_overviews liste pour chaque raster les miniatures disponibles. Ceci est possible car chaque miniature de raster (qui est elle-même un raster) définit une contrainte nommée enforce_overview_rast qui indique de quel raster source il est une miniature.
C’est grâce à cette vue raster_overviews que les outils externes savent comment exploiter les miniatures pour un raster donné.
À partir de la version 2.2 de PostGIS, la fonction ST_CreateOverview permet de générer des miniatures automatiquement (avec les bonnes contraintes) pour un raster existant. Nous n’allons pas l’utiliser ici. À la place, nous allons utiliser l’option -l de l’utilitaire raster2pgsql pour générer les miniatures directement à l’import.
AF Paramétrer l’import
Nous allons ré-importer notre modèle numérique de terrain en tenant compte des remarques précédentes :
- Définir la référence spatiale (identifiant 2154) : option « -s 2154 »
- Définir les contraintes de raster : option -C
- Importer en tuiles régulières et non pas un raster monolithique : option « -t auto »
- Générer les miniatures ½ et ¼ : option « -l 2,4 »
De plus, il nous faut supprimer le raster existant pour le ré-importer : nous pourrons le faire manuellement dans pgAdmin, mais l’option -d le fera pour nous.
Dans l’invite de commande de Windows (cmd.exe), nous allons donc exécuter :
raster2pgsql -d -s 2154 -C -t auto -l 2,4 mnt_25m.asc >mnt_25m.sqlLe fichier SQL ainsi généré est prêt à être exécuté dans la base formation , comme précédemment :
psql -h localhost -U postgres -W -d formation -f mnt_25m.sql
AG Renommer et supprimer des jeux de données
Renommer un raster dans la base se fait de la même façon que pour les vecteurs : en renommant la table SQL :
- soit à l’aide de la souris sous pgAdmin : clic droit sur la table puis propriétés
: changer le nom de la table et cliquer sur
OK; - soit en SQL :
ALTER TABLE table_name RENAME TO new_table_name
Supprimer un raster se fait de la même façon, comme pour toute table PostgreSQL :
- avec pgAdmin : clic droit sur la table puis supprimer ;
- ou en SQL :
DROP TABLE table_name
