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 conjointement, à savoir PostgreSQL, PostGIS, QGIS et GDAL.

Je suis un utilisateur d'ArcGIS, Python et R de longue date et je souhaite également me diversifier dans l'écosystème SIG open source gratuit et Linux. Récemment, j'ai été très intéressé à utiliser 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 X200 avec un Core 2 de 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 (d'une valeur d'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 réussi à effectuer des importations uniques et par lots de petits fichiers geoTIFF et GRID, mais des rasters plus importants (disons, un fichier IMG ou TIFF de 15619 x 14655 cellules de taille 870 Mo sur le disque) prennent une éternité à se charger dans PostGIS. J'ai lu et configuré l'outil raster2pgsql pour créer des index spatiaux et charger des rasters par tuiles en utilisant ces paramètres:

raster2pgsql -s 3161 -C -I D:\PostGIS_data\dem.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 au mieux les petits rasters ou gelant 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 (quel est l'intérêt d'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 ESRI pour stocker, visualiser et analyser des rasters assez volumineux (~ 70 Go) rapidement et facilement, et ArcGIS 10.1 ne se fige ou ne ralentit jamais en raison de ces opérations de routine.

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 optimisé pour profiter des avantages de performances de PostGIS? Me manque-t-il une version de GDAL que je dois rechercher et compiler? Comment puis-je améliorer les performances PostGIS et la visualisation 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 cette question 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é le carrelage à 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_data\dem.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 utile et l'afficher dans QGIS sans ralentir ni planter l'application. Le temps de rendu n'est pas aussi vif que je m'y attendais, mais il est acceptable. Je lirai plus loin le paramètre -l pour l'utiliser correctement.

Par ailleurs, 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 plus étroit plage de valeurs résultant de l'agrégation à une résolution inférieure?

Je ne pense pas que le 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 déjà rencontré des problèmes de performances ( voir ici également ). 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 a sûrement d'autres utilisateurs de 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'enregistrements de ~ 4,7 m . 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 indices spatiaux pour les tables de géométrie et effectué un VIDE.
Le comportement de QGIS pour l'ouverture de grandes tables d'attributs (~ 4,7 millions d'enregistrements) semble essayer de lire tous les enregistrements plutôt que de renvoyer un sous-ensemble pour une visualisation instantanée. Cela conduit à de mauvaises performances.
Performance dans le rendu de grandes tables de géométrie PostGIS ne pas sembler être un problème.
Avec raster2pgsql, les rasters étaient indexés, tuilés et importés en tant que tables raster avec 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 d'attributs 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 n'est pas censé apporter beaucoup, sinon aucun, d'avantages au stockage des rasters. Cependant, à ce stade, je me demande pourquoi j'exécuterais QGIS + PostGIS pour mes besoins SIG, en particulier lorsque les ESG fileGDB activent des attributs raster, des mosaïques et d'autres opérations raster facilitées par la géodatabase. Alors peut-être que je manque vraiment quelque chose ou que QGIS et PostGIS ne répondent pas à mes besoins SIG. Je trouve ce dernier difficile à croire.

— mbcaradima
source

Les rasters doivent-ils être dans PostGIS? Quels avantages / fonctionnalités supplémentaires espérez-vous en retirer? J'ai trouvé que le vecteur PostGis était acceptable et offrait une édition multi-utilisateurs, mais le raster PostGis n'avait aucun avantage réel sur le raster basé sur fichier (stocké sur le serveur). Bonne question cependant; il est tout à fait possible qu'il y ait des avantages que j'ai ratés dans mon évaluation ...

— Michael Stimson

Je pensais que les rasters PostGIS permettaient des calculs raster plus rapides ainsi que de meilleures performances avec les opérations raster / vectorielles. Cela s'ajoute aux avantages d'une base de données spatiale: fiabilité, accessibilité, installations de sauvegarde, stockage plus compact, etc. Dans tous les cas, une approche fichier / mosaïque ne permet pas les fonctions de recherche, les pyramides prédéfinies, la mosaïque et d'autres capacités qui améliorent la façon dont le raster est utilisé et visualisé.

— mbcaradima

Je n'ai vu aucune mesure indiquant que les rasters PostGIS sont plus rapides lors des calculs de raster .. dans les deux cas avec un SSD de 240 Go (bon choix BTW, plus rapide que le RAID à une fraction du coût / effort), vous remplirez cela très rapidement avec les rasters ... ECW / JP2 pour 8 bits ou GeoTIFF avec compression LZW / Deflate coche la plupart de ces cases, pyramides prédéfinies, mosaïque (via VRT), sauvegarde sous forme de fichiers, etc. ... le seul avantage est la fonction de recherche. Je me rends compte que je m'éloigne légèrement du sujet, mais si le raster PostGIS ne fait pas ce que vous attendez, alors pourquoi ne pas vous en tenir au fichier raster pour l'affichage?

— Michael Stimson

Qui a dit que les rasters PostGIS étaient plus rapides qu'autre chose? Ils peuvent être plus pratiques (API d'accès SQL pratique) et ils peuvent être utiles pour l'analyse (raster et vecteur dans le même compartiment) mais plus rapidement ? Jamais.

— Paul Ramsey

Je travaille sur un livre sur PostGIS (PostGIS in Action, 2e éd.) Et il semblait naturel de supposer que les avantages du stockage de fichiers de formes dans une base de données spatiale s'étendraient également à un raster. Bien sûr, étant donné leurs différents modèles de données, je peux voir que cette hypothèse était purement intuitive. Pourtant, les rasters sont généralement stockés dans des géodatabases avec ArcGIS et permettent la construction de pyramides, un géotraitement plus rapide et la construction de mosaïques. Dans un flux de travail avec un logiciel open source, comment un utilisateur SIG est-il censé travailler avec des rasters alors? BTW, je vais me frapper au visage.

— mbcaradima

Réponses:

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 cela ne fonctionnera pas .

Si vous utilisez, par exemple, -l 2,4,8,16quatre 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: importez 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 exemple:

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

— jgrocha
source

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

shared_buffers = 5000MB work_mem = 100MB maintenance_work_mem = 100MB

Cependant, cela dit, je suis totalement d'accord pour dire que les performances des rasters PostGIS dans QGIS ne sont pas excellentes. J'ai affaire à 608 géotiff compressés qui se chargent bien en 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 devrai peut-être compter sur le système de fichiers pour servir des rasters au sein de mon organisation.

— Falaise
source

Merci pour ton commentaire, Cliff. J'ai appliqué certaines de vos modifications et je signalerai toute amélioration majeure des performances. Dans l'ensemble, je dois dire que les performances de QGIS sont décevantes pour la visualisation des rasters PostGIS et le chargement / interrogation des tables d'attributs. Les performances raster dans PostGIS sont également décevantes. Je n'ai aucun de ces problèmes avec les géodatabases fichier, donc je me demande ce qui ne va pas?

— mbcaradima

Exactement mes sentiments. J'ai passé la semaine à essayer de le faire fonctionner et je n'ai tout simplement pas pu le faire fonctionner. Je teste maintenant ma VM (Ubuntu Server) avec 10 processeurs et 10 Go de RAM. Si c'est encore lent, je dois faire autre chose de mal. Je ne comprends pas non plus pourquoi les couches WMS dans QGIS sont fondamentalement inutilisables en raison de leur vitesse de rendu lente. Nous devrions nous connecter davantage à ce sujet car nous sommes tous les deux dans le même bateau.

— Cliff

S'ils se chargent bien en VRT, pourquoi ne vous êtes-vous pas arrêté là? Quel gain attendez-vous de ce grand voyage matriciel?

— Paul Ramsey

Je suppose que ma réponse à cela, Paul, est exactement ce que OP a dit dans le prochain post: "Cependant, à ce stade, je me demande pourquoi j'exécuterais QGIS + PostGIS pour mes besoins SIG, en particulier lorsque les fichiers ESD fileGDB activent les attributs raster, les mosaïques et d'autres opérations raster facilitées par la géodatabase. Alors peut-être que je manque vraiment quelque chose ou que QGIS et PostGIS ne répondent pas à mes besoins SIG. Je trouve cela difficile à croire. "

— Cliff

De plus, je dirais qu'environ 70% de l'analyse que je fais concerne les rasters, et environ 40% des données que je souhaite fournir à mon organisation via QGIS sont des données raster. Il est tout à fait logique d'avoir toutes les données raster et vectorielles dans une base de données afin que les utilisateurs puissent configurer une connexion et avoir accès à la base de données de notre organisation dans son ensemble. Au lieu de cela, je devrais créer des crédits pour la base de données et des crédits pour le partage de fichiers. Alternativement, j'envisage sérieusement de mettre au rebut QGIS et de créer une application Web avec Geoserver (ps: toujours disposé à collaborer à ce sujet avec toute personne intéressée).

— Cliff

Je ne sais pas si c'était votre cas, mais j'ai découvert -Iqu'il ne fallait pas l'utiliser avec l'ajout de données -a.

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

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

— Raphael Jolivet
source