Je manipule et traite des rasters globaux à une résolution de 30 m. Les tailles de trame totales sont généralement de [1 440 000 560 000]. J'ai accès à un superordinateur, j'ai donc écrit du code qui me permet de diviser les rasters globaux en morceaux gérables, d'effectuer des calculs en parallèle et de les écrire sur le disque assez rapidement.
J'ai heurté un mur quand il s'agit d'afficher des résultats. Je construis généralement un raster virtuel de tuiles couvrant le globe et le tire dans QGIS. Mais c'est incroyablement lent (minutes à charger, si c'est le cas). Et si j'essaye de faire un panoramique ou un zoom, c'est encore plusieurs minutes. Ma première approche pour résoudre ce problème a été de créer des aperçus à l'aide de gdaladdo. Cependant, cela prend une éternité à construire (comme en jours), ce qui n'est pas propice au développement d'algorithmes. Voici une liste des choses que j'ai essayées et pourquoi / comment elles ont échoué.
construire des aperçus sur le vrt. Comme mentionné ci-dessus, cela prend plus de 2 jours pour terminer 8 niveaux. C'est inacceptable à mes fins.
créer des aperçus sur les tuiles individuelles, puis fusionner en quelque sorte dans un vrt qui contient les aperçus. Je suis capable de construire des aperçus sur les tuiles assez rapidement (supercalculateur), mais je n'ai pas pu les refaire surface. J'ai essayé:
2a. gdal_merge sur les tuiles avec des aperçus, mais les aperçus n'étaient pas conservés (ou du moins pas reconnus par QGIS) dans le tiff de sortie.
2b. gdalbuildvrt sur les tuiles avec des vues d'ensemble, mais comme ci-dessus, les vues d'ensemble n'ont pas été conservées. [Ce n'est pas correct, voir modifier.]
2c. J'ai également essayé un hybride de vues d'ensemble de construction pour les tuiles pour les niveaux 1-6 et les niveaux de construction 7-8 directement sur le vrt (essentiellement l'option 2b), mais cela prend toujours une éternité pour ces deux niveaux. J'ai fait quelques tests et j'ai vu que les aperçus de tuiles sont en fait utilisés pour construire des aperçus vrt, mais il est toujours de l'ordre d'une journée pour terminer les aperçus sur le vrt.
J'espère donc que quelqu'un ici aura quelques suggestions sur la prochaine étape. Voici quelques options que j'envisage:
Créer manuellement les pyramides globales moi-même. Je me méfie de les recombiner dans un fichier .ovr car je suppose que ce sera délicat.
Utilisez un serveur de carte (Geoserver). J'en sais très peu à ce sujet et je crains que cela ne surmonte pas les obstacles temporels tout en ajoutant de la complexité à mon processus.
Divisez le domaine par continents ou par une autre région. Je veux vraiment éviter cette option.
Vous pourriez vous demander "pourquoi avez-vous besoin de voir le globe entier à une résolution de 30 m?" Un exemple: je prends un masque de pixels d'eau (globalement) et le squelette pour trouver des rivières et effectuer des mesures. Mon algorithme de squelettisation nécessite un peu de réglage (pour l'élagage des branches, la suppression des boucles, le nettoyage général, etc.), et la sortie est nécessairement à 30 m. Comme les rivières et les paysages sont divers à travers le monde, je dois être en mesure de voir les effets de tous les changements que j'ai mis en œuvre.
J'ai également parcouru QGIS pour m'assurer qu'il n'y avait pas de paramètres avec lesquels je pouvais jouer pour rendre des rasters énormes plus rapidement, mais je n'ai rien vu. À moins d'acheter des disques SSD, je pense que le démarrage est aussi rapide que possible. (Mes disques durs ont des E / S de ~ 250 Mo / s).
J'ai découvert que la création de vues d'ensemble sur des tuiles individuelles, puis la construction d'un vrt maintient apparemment les vues d'ensemble - la section "Pyramide" de QGIS dans les métadonnées du fichier est vide, mais dans la section "Dimensions" il y a une entrée pour chaque niveau de vue d'ensemble (par exemple X 720000, Y 140; X 360000, Y 70, etc.). Donc j'avais tort sur 2b.
Je trouve également que si je tire juste toutes les tuiles dans QGIS, cela rend en moins d'une minute, tandis que si je tire le vrt qui fait référence aux tuiles, cela prend> 5 minutes (je ne sais pas combien de temps exactement depuis que j'ai tué le processus).
J'ai fait des tests sur un ordinateur avec un SSD, et j'ai trouvé que je pouvais charger, afficher et rendre les vrts globaux (sans aucun aperçu) avec succès et à un taux acceptable. J'ai commandé un SSD PCIe 1 To dans l'espoir qu'il me permettra de faire de même sur mon ordinateur. Mettra à jour avec les résultats.
I also tried a hybrid of building overviews for the tiles for levels 1-6 and building levels 7-8 directly on the vrtce qui ressemble à la commande que vous recommandez et c'est naturellement la bonne. Moi-même, je ne calculerais pas 2 4 8 ... des aperçus pour le VRT si des tuiles individuelles les ont pour économiser du temps et de l'espace disque. Un petit retour sur investissement trouverait alors des aperçus à partir de quelques tuiles et cela devrait être assez rapide.Réponses:
Vous semblez avoir deux préoccupations principales: VRT id lent avec la navigation et il est lent de construire des aperçus globaux.
Bien que je sois sûr que GDAL VRT était lent pour moi et mon MapServer il y a plusieurs années, il se peut que la situation ait changé. J'ai fait une couche de test avec 10000 images aériennes (taille d'image / tuile de 10000x10000 à 12000x12000 pixels) et maintenant GDAL VRT est en fait plus rapide que l'index de fichier de formes MapServer natif et sert avec l'ordinateur de test 6 tuiles (256x256) par seconde dans un test simple avec 1 thread où GetMaps atteint toujours le premier niveau de vue d'ensemble. La mosaïque avec 10000 images est encore assez petite et je suppose que dans mon test, Linux avait tout le fichier VRT dans la mémoire cache. Combien d'images avez-vous dans votre VRT?
Le chapitre suivant peut contenir des informations anciennes, lues de manière responsable:
Il existe des preuves que la VRT est lente lorsqu'elle contient un grand nombre d'images. Ce n'est pas parce que VRT est un index au format XML et qu'il ne prend pas en charge l'index spatial, ce qui conduit à une analyse complète de l'ensemble du fichier XML à chaque fois. Il n'y a rien que vous puissiez faire pour améliorer cela avec GDAL ordinaire, même s'il y a eu des discussions sur la mise en œuvre de l'index spatial pour VRT http://osgeo-org.1560.x6.nabble.com/gdal-dev-Don-t-we- avoir-des-idées-pour-GSoC-2017-td5309810.html .
Si vous souhaitez installer un nouveau logiciel, la solution la plus simple pourrait être d'utiliser MapServer avec tileindex http://www.mapserver.org/optimization/tileindex.html . Si vous créez un tileindex avec gdaltindex http://www.gdal.org/gdaltindex.html et créez également un index pour le tileindex avec shptree http://www.mapserver.org/utilities/shptree.htmlalors MapServer devrait pouvoir accéder très rapidement à tous les fichiers image dont vous disposez. Créez des vues d'ensemble pour les tuiles individuelles et diffusez la couche via WMS pour QGIS et vous avez résolu la première partie du problème, mais pas le problème des vues d'ensemble globales. Même si vous avez créé des aperçus pour les tuiles individuelles, il sera lent d'ouvrir des milliers de fichiers d'image pour couvrir une grande zone et vous devez donc limiter le nombre de fichiers en créant des images d'aperçu qui couvrent une plus grande zone. C'est ce que vous avez déjà essayé de faire en créant des aperçus pour le trou VRT avec gdaladdo.
Je ne connais aucun outil prêt à l'emploi dans le monde GDAL / MapServer pour créer automatiquement des pyramides globales. Vous pouvez convertir les tuiles de la VRT globale en un ensemble d'images avec une plus grande taille de pixels en écrivant un script qui exécute gdal_translate http://www.gdal.org/gdal_translate.html avec un glissement -prowjin ou -srswin. Ensuite, vous pouvez combiner les tuiles résultantes dans une nouvelle couche d'aperçu avec gdalbuildvrt ou gdaltindex.
Parce que vous envisagez également d'utiliser GeoServer, je recommanderais d'avoir un butin sur le script gdal_retile http://www.gdal.org/gdal_retile.html qui est écrit pour gérer votre cas. Il pourrait également être possible d'utiliser les tuiles que gdal_retile crée directement comme des aperçus avec QGIS en construisant VRT dessus. Cependant, le premier problème avec les énormes fichiers VRT lents resterait.
la source
D'accord, j'ai résolu mes deux problèmes ... principalement en achetant un SSD NVMe. Mon disque en lecture / écriture est passé de 125 Mo / s à 1200 Mo / s.
Par programme, il y a quelques choses que vous pouvez faire pour améliorer votre vitesse de lecture / écriture. Tout d'abord, considérez la taille de bloc de votre tiff. Si vous utilisez un tiff rayé, lorsque vous zoomez sur une région particulière, le logiciel SIG devra lire chaque ligne complète de la région, y compris les parties du tiff qui ne seront pas affichées, afin d'afficher la région. Par exemple, si vous zoomez dans une région de 256 x 256 pixels, si vous avez un tiff rayé, le logiciel devra lire au moins 256 blocs (un par ligne). Si vous avez un tiff en mosaïque (en mosaïque à 256 x 256), le nombre maximal de blocs qui doivent être lus est de 4 (et un minimum de 1). Donc la première chose que vous pouvez faire est de vous assurer que vous utilisez un tiff en mosaïque (option de création TILED = YES dans gdal),
Deuxièmement, une approche hybride des aperçus semble bien fonctionner. Si vous pouvez paralléliser vos opérations, vous pouvez ajouter des aperçus aux tuiles individuelles assez rapidement, mais cela ne vous sera utile que pour des résolutions inférieures à votre taille de tuile. J'ai créé des aperçus internes des niveaux 2 4 8 16 32 et 64 sur les tuiles individuelles. Ensuite, créez un VRT et créez des aperçus des niveaux 128, 256 et 512 sur le VRT (gardez à l'esprit qu'il s'agit de jeux de données globaux à une résolution de 30 m - vos niveaux changeront en fonction du nombre de pixels de votre tiff). Le temps total pour créer des aperçus individuels est de l'ordre des minutes (dépend du nombre de threads que vous pouvez exécuter et du nombre de tuiles que vous avez), mais la création d'aperçus sur le VRT est toujours de l'ordre d'une heure. L'amélioration de l'exécution par rapport à mon message initial est due au SSD et à la création de moins de niveaux sur le VRT.
Troisièmement, vous pouvez jouer avec l'option GDAL_MAX_DATASET_POOL_SIZE lors de la création de vrts comme décrit au bas de cette page . Il définit le nombre maximum de tiffs à garder en mémoire à la fois.
Quatrièmement, j'ai trouvé que la compression avec PACKBITS fournit les temps d'affichage les plus rapides. Les fichiers ne sont pas aussi petits que LZW, mais c'est un compromis que vous voudrez peut-être faire.
Le résultat est un VRT qui se charge rapidement et effectue un panoramique / zoom presque sans couture.
la source