Le moyen le plus simple pour moi de résoudre ce problème était d'utiliser le format virtuel GDAL . Ce format m'a permis de traiter l'ensemble des images comme un seul objet image et de le transformer en trois étapes relativement simples.
Création de l'ensemble de données virtuel
GDAL (y compris les binaires GISInternals Windows de Tamas Szekeres et les versions récentes d' OSGeo4W ) comprend un utilitaire appelé gdalbuildvrt qui peut être utilisé pour créer un ensemble de données virtuel initial.
Une façon simple de l'utiliser consiste à ajouter toutes vos images à un fichier texte, puis à utiliser ce fichier texte comme entrée pour gdalbuildvrt. Voici un exemple (vous devrez remettre la deuxième commande sur une seule ligne):
dir /b *.tif > my_images.txt
gdalbuildvrt
-hidenodata
-vrtnodata "255 255 255"
-resolution highest
-input_file_list my_images.txt
my_image.vrt
Cela vous laissera un fichier XML que vous pouvez traiter comme une seule image pour toutes les opérations GDAL. Il représente également en interne les nodata en blanc, mais masque la définition des nodata aux outils qui y lisent.
Création de l'aperçu rééchantillonné
Ensuite, vous effectuerez le rééchantillonnage et la sortie de l'image d'aperçu. Vous pouvez le faire avec gdal_translate ou gdalwarp . Pour l'un ou l'autre, n'oubliez pas que la taille résultante sera width * height * 3(nombre de bandes de 8 bits) octets. Si cela doit être supérieur à 4 Go, vous voudrez regarder les options GeoTIFF pour la syntaxe pour spécifier BigTIFF comme sortie (-co "BIGTIFF = YES").
Pour gdal_translate, vous devrez déterminer les dimensions de l'image virtuelle à l'aide de la commande gdalinfo pratique . Prenez ces dimensions et divisez chacune par un facteur cohérent pour déterminer la largeur et la hauteur de sortie de votre fichier en pixels.
La commande ressemblera à quelque chose (sur une seule ligne):
gdal_translate
-outsize 53120 14000
-co "TILED=YES"
-co "PROFILE=GEOTIFF"
-co "BLOCKXSIZE=256"
-co "BLOCKYSIZE=256"
my_image.vrt
my_image.tif
Pour gdalwarp, vous devrez connaître la taille de pixel résultante; dans ce cas, j'utilise 0,5 mètre. Vous voudrez également faire un appel sur la méthode de rééchantillonnage. Je préfère cubicspline pour les aperçus orthophoto. C'est plus doux, mais vous n'allez pas les utiliser en pleine résolution et selon mon expérience, cela crée une image plus compressible si vous utilisez quelque chose comme JPEG ou ECW.
gdalwarp
-r cubicspline
-of GTiff
-dstnodata "255 255 255"
-tr 0.5 0.5
-co "PROFILE=GEOTIFF"
-co "BIGTIFF=YES"
-co "TILED=YES"
-co "BLOCKXSIZE=256"
-co "BLOCKYSIZE=256"
my_image.vrt
my_image.tif
Vous pouvez également envisager d'utiliser les options de compression JPEG pour ces aperçus GeoTIFF rééchantillonnés; il réduit considérablement le fichier de sortie avec ( selon Frank ) seulement une pénalité de performance marginale.
-co "COMPRESS=JPEG"
-co "JPEG_QUALITY=80"
-co "PHOTOMETRIC=YCBCR"
Aperçus
Vous voudrez également exécuter la commande gdaladdo pratique sur l'image résultante pour construire des "pyramides" internes, afin que les demandes de résolutions inférieures aux dimensions complètes de l'image puissent être satisfaites avec un sous-ensemble de données. L'augmentation des performances vaut largement l'espace disque dans la plupart des cas. Vous aurez envie de jouer avec les niveaux que vous utilisez ici; pour les très grandes images, vous pouvez en déposer quelques-unes. La commande gdaladdo ressemble à ceci:
gdaladdo
-r average
my_image.tif
2 4 8 16 32 64 128 256
Je suggère d'expérimenter ces niveaux pour des performances optimales. Vous constaterez peut-être qu'un intervalle de rééchantillonnage différent est préférable pour votre application ou, en fonction de la taille de votre image, que vous pouvez supprimer certains des nombres les plus élevés (ou que d'autres sont nécessaires)
De plus, si vous générez une vue d'ensemble externe (à l'aide de l'option -ro), pensez à ajouter les lignes de configuration de compression JPEG:
--config COMPRESS_OVERVIEW JPEG
--config PHOTOMETRIC_OVERVIEW YCBCR
--config INTERLEAVE_OVERVIEW BAND
(Je crois que ceux-ci sont hérités du parent GeoTIFF pour les aperçus intégrés)
Remarques
Face à ce problème, j'ai demandé sur la chaîne #gdal sur freenode.irc.net. Il s'agit d'une ressource incroyable, et je suis très reconnaissant à Howard Butler, Frank Warmerdam et Even Rouault de m'avoir aidé avec cela.
^d' insertion pour un saut de ligne qui sera joint lors de l'exécution (par exemple, ajoutez^à la fin de chaque exemple de ligne de code ci-dessus pour conserver à la fois la lisibilité et la capacité d'exécution). Mise en garde importante: ne terminez jamais un fichier ou une ligne de commande avec un curseur, sauf si vous souhaitez invoquer consommer toute la mémoireOui, mais par essais et erreurs, j'ai pu déterminer que -vrtnodata 255 a pour effet de signaler tout ce qui est blanc comme un nodata, pas seulement hors carte, que gdal2tiles traite ensuite avec une transparence alpha selon le drapeau -a.
Vous vous retrouvez donc avec une partie de votre image source définie sur transparent, dans mon cas, les parties blanches des routes en pointillés. Ce n'est pas un terminal mais ce serait bien de pouvoir spécifier à gdal2tiles la couleur "no src image", soit à cause de vides originaux dans le vrt, soit à cause de la déformation. Pour mon ensemble, une nuance de bleu pâle serait juste la chose.
Après encore plus d'essais et d'erreurs, il semble que les hidenodata soient la clé. Je ne sais pas pourquoi ces outils sont si peu documentés. Voici ce qui fonctionne pour moi, gdal 1.8.
la source
Je ne connais pas trop GDAL, mais je suppose qu'une méthode ou une commande est disponible où vous pouvez définir un pixel d'une certaine valeur avec une autre valeur?
Rien à voir avec ça, mais en clair SQL quelque chose comme (juste pour illustrer - c'est beaucoup plus de pseudo-code):
UPDATE raster SET pixel = 255 WHERE pixel = NoData;
J'aimerais connaître la réponse!
la source