Comment contourner le grand processus de mosaïque qui échoue?

J'ai besoin de mosaïquer environ 550 Go d'imagerie tif ensemble et le logiciel que j'ai essayé échoue toujours. La zone a été divisée en zones afin que la plus petite ait environ 200 tuiles.

J'ai utilisé les dernières versions d'ERDAS (Imagine and Mapper), ArcINFO et Global Mapper sur un Intel Xeon E31245 3,30 gigahertz, DELL, 16 Go de RAM, Win 7 Professional 64 bits. Machine Mullti-core (4 au total), hyper-filetée (8 au total). Mon C a 700 Go de libre et D a 1,5 To.

Je cherche à utiliser Grass (jamais auparavant) mais i.image.mosaic ne semble gérer que 4 fichiers ... certains des miens ont 600 tuiles. D'autres options ou logiciels open source à essayer?

Désolé, nous devons ajouter que nous ne pouvons pas utiliser une mosaïque (ou l'équivalent dans d'autres logiciels) car nous devons créer des zones avec des zones sans données définies comme ecw afin qu'elles puissent être ouvertes dans n'importe quel logiciel SIG et combinées avec une résolution inférieure / ancienne données lorsque les nouvelles données n'existent pas de manière transparente.

Un exemple de l'apparence de certains fichiers mosaïqués dans différents logiciels. Global Mapper / ERDAS sont corrects mais ce n'est pas correct dans arcgis.

--- INFOS ANCIENNES ---

Désolé pour le dessin approximatif. Donc, avoir les zones colorées en 5 zones minimisera les zones sans données dans la plus grande AOI.

Dans arcgis, le code est le suivant (il est exécuté comme un modèle et non en python car je ne peux pas le faire prendre l'entrée tifList).

arcpy.MosaicToNewRaster_management(tifList+";" +mask,RootOutput,"Tile1.tif","PROJCS['GDA_1994_MGA_Zone_55',GEOGCS['GCS_GDA_1994',DATUM['D_GDA_1994',SPHEROID['GRS_1980',6378137.0,298.257222101]],PRIMEM['Greenwich',0.0],UNIT['Degree',0.0174532925199433]],PROJECTION['Transverse_Mercator'],PARAMETER['False_Easting',500000.0],PARAMETER['False_Northing',10000000.0],PARAMETER['Central_Meridian',147.0],PARAMETER['Scale_Factor',0.9996],PARAMETER['Latitude_Of_Origin',0.0],UNIT['Meter',1.0]]","16_BIT_UNSIGNED","0.5","3","MAXIMUM","#")

# Replace a layer/table view name with a path to a dataset (which can be a layer file) or create the layer/table view within the script
# The following inputs are layers or table views: "test2"

arcpy.CopyRaster_management(OutputFile,RootOutput+"Tile1b.tif","#","256","256","NONE","NONE","16_BIT_UNSIGNED")

où tifList devrait être lu à partir d'un fichier csv mais cela n'a pas fonctionné en python donc j'exécute ce qui précède dans un modèle à la place ...

J'ai 1,5 To + d'espace libre sur mon lecteur mais le processus se bloque avec une erreur 9999.

100 carreaux seraient-ils traités? -devrions-nous envisager de diviser davantage les zones?

Je devrai aux suggestions de 2nd @ blah238 d'utiliser une autre méthode d'accès aux données que de créer une seule image mosaïquée. Une simple supposition dirait qu'il n'y a pas de bureau qui pourrait gérer la quantité de données que vous auriez à traiter afin de mosaïquer toutes ces tuiles.
Pour le décomposer, il y a probablement deux endroits où vous manquez d'espace.

1. Le premier va être dans votre tampon RAM. Afin de mosaïquer les données, vous fusionnez tout en un seul fichier, ce qui signifie idéalement que tout le fichier serait conservé en mémoire. Vous n'avez pas 550 Go de RAM, ce qui signifie qu'il y aura lecture / écriture à partir de la mémoire virtuelle. C'est suffisant pour faire planter le processus là-bas.
2. L'autre problème est probablement l'espace disque dur. De nombreuses opérations raster créent des fichiers temporaires dans votre répertoire "workspace" qui sont assez volumineux. Il peut y en avoir 2 ou 3 ou plus avant même l'écriture de l'ensemble de données final, il est donc concevable d'utiliser tout votre espace disque pendant le traitement.

Maintenant, pour d'autres solutions. Comme mentionné dans les commentaires ci-dessus, il existe la possibilité de créer un jeu de données Mosaic . Cet ensemble de données vous permettra non seulement de traiter toutes les tuiles individuelles comme une seule image transparente, mais il conserve également des métadonnées sur les tuiles individuelles contenues à l'intérieur. Il vous permet également d'effectuer des opérations raster telles que Hillshade .

L'autre option que je recommanderais, sur la base de votre commentaire sur le fait de vouloir séparer les zones, serait de créer un catalogue d'images . Un catalogue d'images est essentiellement une couche de groupe. Vous pouvez y ajouter plusieurs jeux de données raster. Ils peuvent être gérés dans une géodatabase et importer les rasters, ou simplement créer un jeu de données non géré dans lequel le catalogue d'images conserve les chemins d'accès aux jeux de données raster d'origine. Lorsque vous chargez cette couche dans ArcMap, vous pouvez définir les propriétés d'affichage pour ne charger que dans un certain nombre de tuiles raster à la fois, ou définir l'échelle et la résolution d'affichage.
J'utilise actuellement un catalogue d'images pour assembler un ensemble de photos aériennes de 100 + Go. La performance est très bonne. Si vous recherchez un autre type de stockage de données simplement pour gérer un grand nombre de tuiles, je le recommanderais vraiment.

Voici le code que vous pouvez utiliser pour créer un catalogue d'images et ensuite y importer un espace de travail de tuiles :

import arcpy
import os

newdir = r"c:\data"
dbname = "Aerialphotos.gdb"
gdbdir = os.path.join(newdir, dbname)
rcat = "AerialCatalog"

arcpy.CreateRasterCatalog_management(gdbdir, rcat,
                                     "NAD 1983 StatePlane California VI FIPS 0406 (US Feet).prj", 
                                     "NAD 1983 StatePlane California VI FIPS 0406 (US Feet).prj",
                                     "MAX_FILE_SIZE_4GB", "1000", "3000", "9000",
                                     "UNMANAGED", "")

#Load all raster datasets in workspace to Raster Catalog
rcatdir = os.path.join(gdbdir, rcat)
rastertiledir = os.path.join(newdir, "tiles")

arcpy.WorkspaceToRasterCatalog_management(rastertiledir, rcatdir,
                                          "INCLUDE_SUBDIRECTORIES",
                                          "PROJECT_ONFLY")

J'espère que cela t'aides!

------------- Éditer

Voici un graphique des tuiles traitées par mon catalogue d'images. Notez que vous pouvez choisir d'afficher les images filaires ou les données raster. Le catalogue d'images a une table attributaire à laquelle vous pouvez ajouter des champs, par exemple si vous souhaitez ajouter des désignations de zone comme dans votre graphique. Ensuite, vous pouvez choisir d'afficher uniquement ces rasters dans une zone particulière.
Lors de l'impression dans un graphique à partir de la vue de mise en page, la pleine résolution des rasters est utilisée, il n'y a donc aucune perte de qualité dans l'impression.

Voici le même graphique, mais montrant certaines des données raster, ainsi que quelques wireframes.

Je sais que je suis en retard à la fête. Mais voici ma suggestion.

1) taille de l'image
Si vos originaux de 550 Go ne sont pas compressés, vous devez les convertir en fichiers tiff compressés au format jpeg. Gardez-les individuellement (non fusionnés). Vous pouvez compresser en utilisant arcgis, gdal, tout ce que vous voulez. La compression vous amènera à environ 23 Go. Ne créez pas encore de pyramides / aperçus. Pour compresser, vous pouvez utiliser n'importe quel programme gis que vous aimez, mais j'aime utiliser gdal donc la commande est essentiellement la suivante:

gdalwarp -multi -wm 512 --config  GDAL_CACHEMAX 512 -co compress=jpeg -co tiled=yes -co jpeg_quality=70 -co PHOTOMETRIC=YCBCR -co INTERLEAVE=PIXEL uncompressed.tif compressed.tif

Vous pouvez facilement créer un fichier bat qui passe par tous vos tiffs non compressés. J'aime utiliser gdalwarp pour compresser mes images au lieu du gdal_translate habituel, car il est plus rapide (en utilisant l'option multi pour le multicœur et -wm pour beaucoup de mémoire).

2) manipulation comme une seule image
Vous pouvez créer une mosaïque "virtuelle" en utilisant le format gdal vrt. Ceci est compatible avec arcgis, qgis, mapserver, etc. Je ne suis pas sûr du mappeur global et de mapinfo. Le format .vrt n'est qu'un seul fichier xml répertoriant vos images. C'est une seule commande pour créer:

gdalbuildvrt nameofmosaic.vrt compressed_tif_folder\*.tif

Ce fichier fait quelques ko.

3) accélérer la visualisation
Vous devez construire des pyramides / aperçus. Utilisez simplement votre logiciel préféré pour cela. En utilisant les outils gdal, vous pouvez:

gdaladdo -ro -r average --config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 70 nameofmosaic.vrt 2 4 8 16 32 64 128

Cela prendra du temps. Soyez prêt à attendre 2 à 3 jours de traitement continu.

4) Utilisation de la mosaïque
Chargez la mosaïque virtuelle dans votre programme SIG. Ce sera rapide car il lit les aperçus qui sont juste dans 1 fichier comme un ecw. Lorsque vous effectuez un zoom avant sur la résolution réelle de vos images, seules les rares images visibles des images compressées seront lues, ce qui est également très rapide.

5) gérer vos zones sans données qui affichent du noir
Vous avez 3 solutions pour cela: i) utiliser un format de fichier qui gère les nodata, ce qui va être compliqué; ou ii) utiliser une bande alpha ou iii) un fichier masque. Vous pouvez créer une bande alpha automatiquement à l'étape 2 en disant à GDAL que vous voulez que les zones nodata soient dans la bande alpha - il vous suffit d'ajouter l'option -addalpha:

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

Le problème avec les bandes alpha est qu'elles se compressent mal. Vos vues d'ensemble seront donc plus grandes. Si cela vous convient, vous avez terminé.

Si vous voulez créer un fichier de masque, c'est un peu plus compliqué. Et je trouve que cela ne rentre pas dans la présente question.

J'espère donc que cela vous aidera. Vous pouvez trouver des informations sur les outils gdal en recherchant sur Google. Beaucoup de choses intéressantes autour.

550 Go de données TIF en entrée sont facilement gérées par un seul fichier ECW. Nous avons de nombreux clients qui compressent des ensembles de données beaucoup plus volumineux que cela, alors ne pensez pas que le format n'est pas compatible dans ce domaine.

Votre stratégie de diviser le projet en petits carreaux pour minimiser la zone nulle est également une bonne approche à adopter avec la version actuelle du format car elle réduira le temps de compression

Votre exemple inclut une référence aux données d'entrée 16 bits non signées. Je recommanderais de redimensionner à 8 bits si possible (en fonction de vos besoins)

Veuillez expliquer pourquoi vous n'avez pas pu traiter votre projet avec IMAGINE ou ERMapper, car sans ces informations, je ne peux pas vous aider. Ou mieux encore, contactez l'équipe d'assistance locale

Sachez qu'en utilisant le format ESRI Mosaic Dataset, les réponses ci-dessus ne mentionnent pas l'exigence de générer la couche pyramide / vue d'ensemble. Sans cela, les performances en souffriront considérablement. Il est probable que vous puissiez créer les fichiers équivalents ECW dans le même laps de temps mais avec une qualité d'image améliorée et des exigences de stockage de sortie nettement plus petites.

Bien qu'il soit clairement préférable d'utiliser l'une des autres options mentionnées, vous pouvez essayer ce qui suit:

gdalbuildvrt index.vrt *.tif
gdal_translate -of "GTiff" -co "COMPRESS=LZW" -co "TILED=YES" -co "BIGTIFF=YES" index.vrt out.tif

Cela crée un format virtuel GDAL, puis convertit en un seul GeoTiff.

Cela me semble assez familier, nous produisons également de gros fichiers ECW uniques sur 500 trop 1 To de fichiers TIF. Mais je ne voudrais pas durer sur ArcGIS (ArcObjects et le moteur de géotraitement), car il n'est pas en mesure de mosaïquer ce montant de manière fiable. Si vous souhaitez rester dans le monde ESRI, je recommanderais de mosaïquer des morceaux d'environ 50 Go ou même plus petits à la fois dans un ensemble de données raster stocké dans une géodatabase fichier. L'outil de mosaïque a tendance à se bloquer après un certain temps, c'est donc une bonne idée de laisser ArcGIS libérer de la mémoire après quelques gigaoctets.

Une autre possibilité consiste à utiliser une géodatabase SDE d'entreprise ou de groupe de travail. Avec SDE, vous obtenez les outils de ligne de commande SDE à l'ancienne, qui sont construits sur une architecture C ++ robuste autre que les trucs ArcObjects peu fiables. Avec la commande "sderaster -o mosaic ...", vous pouvez créer une mosaïque vers un RasterDataset jusqu'à ce que votre magasin de base de données soit plein. Il existe également des commandes pour construire des pyramides et des statistiques pour le RasterDataset, sinon ce n'est pas très utile, car la plupart des clients ne peuvent pas conserver les images en mémoire lors de leur lecture, comme blah238 mentionné ci-dessus. Mais les pyramides (en fait l'indexation spatiale) devraient résoudre ce problème.

Mais ces solutions ne vous aident certainement pas avec MapInfo. Vous avez mentionné que vous avez déjà essayé ERDAS Mapper. C'est aussi l'outil que je préfère. Nous avons déjà mosaïqué 16000 fichiers TIF, chacun d'une taille de 50 Mo, soit 800 Go, puis nous l'avons compressé en une seule ECW avec un taux de compression de 1:20, ce qui a donné un fichier ECW de 30 Go. Je me demande que cela ne fonctionne pas pour vous ...

Au moins, tout le processus fonctionnait sur un Pentium 4 1,6 GHz à cœur unique avec 2 Go de RAM, donc le matériel ne devrait pas être le problème. Nous utilisons Windows Server 2003 (ou un autre système d'exploitation de serveur) car il utilise mieux les ressources matérielles. Gardez à l'esprit que l'ensemble du processus de compression nécessite beaucoup de temps. Notre machine travaillait environ 5 semaines sur ce fichier unique, et parce qu'il se bloquait parfois, nous devions le faire plusieurs fois, mais à la fin nous avons obtenu notre fichier ECW.

Je ne connais pas d'autre système ou mécanisme pour stocker de grandes quantités de rasters d'une manière essentiellement indépendante des fournisseurs. Tous les moyens mentionnés ci-dessus sont très spécifiques à ESRI. Au moins avec Oracle RASTER et une implémentation assez similaire dans PostGIS, il existe deux variantes basées sur des données qui ne sont également pas neutres vis-à-vis des fournisseurs mais ouvertes via l'interface SQL / MM.

J'espère que cela aide un peu.