Aperçus: aux tuiles ou .vrt, ou les deux?

Lors de l'utilisation vrtPour mosaïquer à la volée de grandes collections d'images, est-il préférable d'ajouter des vues d'ensemble (pyramides) aux rasters individuels ou au .vrt final, ou les deux? (Où "mieux" signifie trouver le point d'équilibre entre ne pas utiliser plus de stockage que nécessaire tout en offrant une expérience fluide pour utiliser et parcourir l'image finale.)

vrt image-pyramids raster-catalog

— Matt Wilkie
source

je veux demander quelle est la raison d'utiliser la mosaïque

— luka tumba

Cela dépend principalement de l'échelle minimale pour afficher votre couche d'image.

La création de vues d'ensemble pour des rasters individuels est plus flexible lorsque vous mettez à jour partiellement votre couche. Supprimez simplement l'ancienne image et mettez une nouvelle image avec des aperçus en place. Si vous avez créé des aperçus pour le .vrt, vous devez le recréer après la mise à jour. Cependant, les aperçus individuels ne fonctionnent pas bien à petite échelle. Si vos images originales couvrent 10 x 10 km chacune et que vous souhaitez afficher à l'écran une zone de 100 x 100 km, le système doit ouvrir 100 fichiers individuels pour lire les aperçus. Si vous avez créé des aperçus pour le .vrt, il n'y a qu'un seul fichier à ouvrir et ce sera plus rapide.

Vous pouvez également utiliser un modèle hybride: créez quelques niveaux de vue d'ensemble internes (2 4 8), puis créez un nouveau fichier physique à partir de .vrt avec la taille de pixel de la vue d'ensemble suivante (16). Créez des aperçus internes pour l'image sous-échantillonnée et enfin combinez-les tous dans un groupe dépendant de l'échelle. Lorsque des images individuelles sont remplacées par des images plus récentes, le fichier de présentation physique ne nécessite souvent pas de mise à jour car les modifications ne sont de toute façon pas visibles.

En ce qui concerne le besoin d'espace disque, c'est la même chose dans les deux cas. Mais n'oubliez pas de compresser vos aperçus. Avec les images aériennes, vous pouvez économiser plus de 90% de l'espace disque en compressant les vues d'ensemble avec la méthode JPEG et l'interprétation photométrique.

Comme vous posez votre question, je dirais que créer des aperçus compressés pour votre .vrt. Cela prend la même quantité d'espace disque et l'expérience de navigation sera bonne à n'importe quelle échelle. Rappelez-vous toujours ce que j'ai écrit sur la mise à jour.

— user30184
source

l'idée hybride est très intéressante! Je suis curieux de savoir pourquoi un fichier physique au niveau 16. Est-ce que cela offre quelque chose gdaladdo foo.vrt 16 32 64non? ... cela me vient aussi à l'esprit: des aperçus en mosaïque et en vrt peuvent être souhaités dans les cas où des tuiles individuelles sont accessibles ainsi que la mosaïque virtuelle.

— matt wilkie

gdaladdo foo.vrt 16 32.64crée un fichier physique mais si vous l'avez fait gdaladdo foo.vrt 2 4 8auparavant, vous avez déjà un fichier foo.vrt.ovr. Eh bien, le fichier .ovr est vraiment juste un tiff et vous pouvez le renommer et créer des niveaux de vue d'ensemble à la main avec un nouveau fichier .vrt qui est un peu compliqué. Voulez-vous dire que vous avez foo_1234.tif dans une mosaïque virtuelle all_foo.vrt, mais certains utilisateurs peuvent avoir besoin d'accéder directement à ce tiff unique? Alors vous avez raison, aucun logiciel ne peut deviner de prendre des aperçus de all_foo.vrt.ovr.

— user30184

Oh, peut-être que vous vouliez écrire 2 4 8 aperçus pour les images individuelles et 16 32 64 ... pour le vrt. Excellente idée en effet.

— user30184

oui à la 2ème réponse, 2 4 8 pour les tuiles et 16 32 64 pour vrt.

— matt wilkie

Le problème discuté est un problème que j'essaie souvent de contourner et c'est constamment une cause d'agonie. J'ai une énorme quantité de fichiers disposés dans des dossiers de 10 km2. Pour chaque dossier, je génère un vrt et j'ajoute des aperçus (2 4 8 16). J'agrège ensuite les fichiers vrt en un (gdalbuildvrtgreg.vrt * .vrt). La création d'une vue d'ensemble pour l'agrégat.vrt (32 64 128 256) est pénible. Je soupçonne que gdalbuildvrt va directement aux fichiers source au lieu des fichiers ovr déjà construits ... Est-ce correct? Et si oui: existe-t-il une solution?