Suite

Mauvaises performances avec le stockage de rasters volumineux dans PostGIS et la visualisation dans QGIS

Mauvaises performances avec le stockage de rasters volumineux dans PostGIS et la visualisation dans QGIS


ma question concerne l'utilisation et les performances de plusieurs outils logiciels en conjonction, à savoir PostgreSQL, PostGIS, QGIS et GDAL.

Je suis un utilisateur de longue date d'ArcGIS, Python et R qui souhaite se diversifier dans l'écosystème SIG open source gratuit et Linux également. Récemment, j'ai été très intéressé par l'utilisation de QGIS (ver 2.8) avec PostgreSQL (ver 9.4) et PostGIS (ver 2.1), et j'ai installé le logiciel sur un ordinateur avec Windows 8.1 x64 (les spécifications de l'ordinateur en bref : ThinkPad X200s avec un Core 2 à 2,1 GHz, 8 Go de RAM et un SSD de 240 Go). Une fois que j'aurai appris à gérer mes données spatiales (environ 100 Go), j'aimerais exécuter Ubuntu sur cette machine.

Pour le moment, j'essaie simplement de stocker et de récupérer de manière fiable des fichiers de formes et des rasters. Jusqu'à présent, j'ai réussi à charger des fichiers de formes dans PostGIS, mais les rasters s'avèrent plus problématiques. J'ai effectué avec succès des importations uniques et par lots de petits fichiers geoTIFF et GRID, mais les rasters plus volumineux (par exemple, un fichier IMG ou TIFF de 15619x14655 de 870 Mo sur le disque) prennent une éternité à charger dans PostGIS. J'ai lu et configuré l'outil raster2pgsql pour créer des index spatiaux et charger des rasters par tuiles à l'aide de ces paramètres :

raster2pgsql -s 3161 -C -I D:PostGIS_datadem.img -t auto raster.dem | psql -h localhost -U postgres -p 5432 -d postgres

Les performances d'importation sont encore très médiocres et le matériel n'est pas le problème. La visualisation des rasters PostGIS dans QGIS est encore pire, chargeant lentement les petits rasters au mieux ou se figeant complètement. Les grands rasters comme celui que j'ai mentionné sont impossibles à visualiser dans QGIS. D'après la documentation et les discussions du forum, cette lacune semble être due au pilote raster PostGIS de GDAL et non à QGIS lui-même. Les discussions du forum mentionnent brièvement ce problème et certains suggèrent même que les rasters ne devraient pas être stockés dans PostGIS (à quoi bon une base de données spatiale qui ne gère pas les rasters en douceur ?). Pourtant, j'utilise régulièrement la géodatabase fichier d'ESRI pour stocker, visualiser et analyser des rasters assez volumineux (environ 70 Go) rapidement et facilement, et ArcGIS 10.1 ne se bloque ou ne ralentit jamais en raison de telles opérations de routine. Ces obstacles aux performances sont décevants et ne me laissent pas impressionné par FOSS GIS.

Y a-t-il quelque chose qui me manque ici, un goulot d'étranglement que je n'ai pas résolu ? PostgreSQL a-t-il besoin d'être ajusté pour profiter des avantages de performances de PostGIS ? Me manque-t-il une version de GDAL que je dois rechercher et compiler ? Comment améliorer les performances et la visualisation de PostGIS dans QGIS des fichiers de formes et des rasters en particulier ? Comment puis-je profiter de la gloire d'une gestion complète et rapide des données spatiales via un terminal Linux ? Toute aide sur ce problème serait la bienvenue !


J'ai suivi ce guide par un Duncan Golicher : https://duncanjg.wordpress.com/2012/11/20/the-basics-of-postgis-raster/

J'utilisais des tuiles avec un paramètre automatique à l'origine, mais j'ai réinitialisé la tuile à 100x100 cellules par ligne, puis j'ai inclus les pyramides comme indiqué dans le guide comme suit :

raster2pgsql -s 3161 -d -C -I -M -l 4 D:PostGIS_datadem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

J'ai pu importer avec succès le raster IMG de 870 Mo en temps voulu et l'afficher dans QGIS sans ralentir ni bloquer l'application. Le temps de rendu n'est pas aussi rapide que prévu, mais il est acceptable. Je vais lire plus loin le paramètre -l pour l'utiliser correctement.

Incidemment, lors de l'importation du fichier dem.img en tant que table dem100, une autre table raster a été créée appelée "o_4_dem100". Lorsque je l'importe en tant que couche dans QGIS, elle a une plage de valeurs comprise entre 201 et 524, tandis que la couche dem100 a une plage de 36 à 524. Ai-je raison de supposer que cette table supplémentaire est la table pyramidale qui a un plage de valeurs résultant de l'agrégation à une résolution inférieure ?


Je ne pense pas qu'un matériel inadéquat soit le problème. Voici un bref résumé de ce que j'ai trouvé jusqu'à présent.

Le pilote raster PostGIS de GDAL a eu des problèmes de performances dans le passé (voir ici aussi). Bien que ces problèmes aient été notés en 2012, je me demande si GDAL 1.11.2 trouvé dans QGIS 2.8 a toujours ce problème. Il y en a sûrement d'autres qui utilisent QGIS et PostGIS pour la visualisation et le stockage raster ?

Sur une note connexe possible, j'ai également eu des problèmes de performances avec l'ouverture des tables d'attributs PostGIS dans QGIS avec des tables d'environ 4,7 millions d'enregistrements. Après quelques suggestions dans ce fil et sans résoudre le problème, j'ai finalement déposé un rapport de bogue avec QGIS qui a finalement été fermé et lié au rapport de bogue similaire suivant. Bien que le rapport de bogue soit fermé, il ne semble pas être corrigé…

Pour résumer mes efforts jusqu'à présent:

  • J'ai optimisé le serveur PostgreSQL pour les données spatiales.
  • J'ai construit des index spatiaux pour les tables de géométrie et effectué un VIDE.
  • Le comportement de QGIS pour l'ouverture de grandes tables attributaires (~ 4,7 millions d'enregistrements) semble essayer de lire tout enregistrements plutôt que de renvoyer un sous-ensemble pour une visualisation instantanée. Cela conduit à de mauvaises performances.
  • Les performances de rendu de grandes tables géométriques PostGIS ne ne pas semble être un problème.

  • Avec raster2pgsql, les rasters ont été indexés, tuilés et importés sous forme de tables raster avec des pyramides dans PostGIS.

  • Les rasters de toute taille raisonnable sont toujours incroyablement lents à importer dans PostGIS, sans parler de s'ouvrir et de se déplacer dans QGIS.

Il convient également de noter que lors de l'importation de grands rasters ou de l'ouverture de grandes tables attributaires avec PostGIS, la consommation de mémoire pour raster2pgsql et qgis-bin est supérieure à 1 Go. Comme @Michael et @Paul l'ont mentionné en réponse à ma question initiale, il semble que PostGIS ne soit pas censé apporter beaucoup, voire aucun avantage, au stockage des rasters. Cependant, à ce stade, je me demande pourquoi j'exécuterais QGIS + PostGIS pour mes besoins SIG, en particulier lorsque les fichiers GDB ESRI activent les attributs raster, les mosaïques et d'autres opérations raster facilitées par la géodatabase. Alors peut-être que je suis vraiment il manque quelque chose ou QGIS et PostGIS ne répondent pas à mes besoins SIG. Je trouve ce dernier difficile à croire.


Si vous souhaitez afficher de grands rasters dans QGIS, vous devez créer des pyramides, soit pour une image tif sur le système de fichiers, soit pour une image enregistrée dans Postgis.

La différence de performances dans le rendu QGIS entre un grand raster dans le système de fichiers ou dans Postgis est minime. Les utilisateurs ne remarqueront pas la différence. Mais - si et seulement si - vous construisez les pyramides avec l'option-l.

Si vous importez simplement l'image sans l'option -l, ou avec juste-l 4ça ne marchera pas.

Si vous utilisez, par exemple,-l 2,4,8,16, quatre niveaux de pyramides seront créés, comme dans le calque ci-dessous :

Si vous voulez avoir une meilleure expérience utilisateur, vous devez ajouter plus de niveaux de pyramides, comme-l 2,4,8,16,32,64,128,256. Cela créera huit niveaux de pyramides.

Pour résumer, la réponse à cette question est : importer le raster avec l'option-let utilisez le même nombre de niveaux de pyramide que vous utilisez pour le même raster sur le système de fichiers.

Par example:

raster2pgsql -s 3161 -d -C -I -M -l 2,4,8,16,32,64,128,256 D:PostGIS_datadem.img -t 100x100 raster.dem100 | psql -h localhost -U postgres -p 5432 -d postgres

J'ai exactement les mêmes problèmes avec le rendu des rasters dans QGIS à partir de PostGIS (voir ma question récente). J'ai trouvé cet article utile et j'ai légèrement augmenté le rendu raster amélioré suivant :

shared_buffers = 5000 Mo work_mem = 100 Mo maintenance_work_mem = 100 Mo

Cependant, cela dit, je suis tout à fait d'accord pour dire que les performances des rasters PostGIS dans QGIS ne sont pas excellentes. J'ai affaire à 608 géotiffs compressés qui se chargent très bien en tant que VRT mais sont essentiellement inutilisables dans PostGIS. Essayez d'augmenter les performances du serveur dbase, mais au-delà, je ne peux pas être trop utile. Moi aussi, je devrais peut-être compter sur le système de fichiers pour fournir des rasters au sein de mon organisation.


Je ne sais pas si c'était ton cas, mais j'ai découvert-JEne doit pas être utilisé avec l'ajout de données-une.

J'importais de nombreux fichiers TIF dans une base de données, et-JEcrée à nouveau l'index et exécuteanalysersur la table pour chaque fichier, ce qui prend 10 fois plus de temps.

-JEne doit être utilisé que lors de la création de la table, avec-poption.


Voir la vidéo: Usare PostGIS con QGis: connessione e import shapefile OSGEO