Como solução alternativa para o processo de mosaico grande que está falhando?

Preciso criar mosaicos de cerca de 550 GB de imagens tif juntos e o software que eu tentei continua falhando. A área foi dividida em zonas para que o menor possua aproximadamente 200 peças.

Eu usei as versões mais recentes do ERDAS (Imagine e Mapper), ArcINFO e Global Mapper em um Intel Xeon E31245, DELL, RAM de 16 GB e 16 GB de RAM de 3,30 gigahertz, Win 7 Professional de 64 bits. Mullti-core (4 total), máquina Hyper-threaded (8 total). Meu C tem 700 GB grátis e D tem 1,5 TB.

Estou pensando em usar o Grass (nunca o fiz antes), mas o i.image.mosaic parece lidar apenas com 4 arquivos ... alguns dos meus têm 600 blocos. Alguma outra opção ou software de código aberto para tentar?

Lamentamos acrescentar que não podemos usar um conjunto de dados em mosaico (ou equivalente em outro software), pois precisamos criar zonas com áreas sem dados definidas como ecw's, para que possam ser abertas em qualquer software GIS e combinadas com menor resolução / mais antiga dados quando novos dados não existem perfeitamente.

Um exemplo de como alguns arquivos em mosaico aparecem em diferentes softwares. O Global Mapper / ERDAS está bem, mas não está correto nos arcgis.

--- INFO MAIS VELHO ---

Desculpe pelo desenho áspero. Portanto, ter as áreas coloridas como 5 zonas minimizará as áreas sem dados na AOI maior.

No arcgis, o código é o seguinte (isso é executado como modelo e não em python, pois não consigo levá-lo para a entrada 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")

onde tifList deve ser lido em um arquivo csv, mas isso não funcionou em python, por isso estou executando o acima em um modelo ...

Tenho 1,5 TB de espaço livre na unidade, mas o processo falha com um erro de 9999.

Processo de 100 peças? -é devemos olhar para quebrar ainda mais as zonas?

Vou precisar das sugestões do 2nd @ blah238 de usar outro método de acesso a dados que não seja a criação de uma única imagem em mosaico. Um palpite simples diria que não existe uma área de trabalho que possa lidar com a quantidade de dados que você teria que processar para fazer mosaico de todos esses blocos.
Para resumir, provavelmente há dois lugares em que você está ficando sem espaço.

1. O primeiro será no seu buffer de RAM. Para mosaico de dados, você está mesclando tudo em um único arquivo, o que significa, idealmente, que todo o arquivo seja mantido na memória. Você não possui 550 GB de RAM, o que significa que haverá leitura / gravação na memória virtual. Isso é suficiente para travar o processo ali.
2. O outro problema provavelmente é o espaço no disco rígido. Muitas das operações de varredura criam arquivos temporários no diretório "espaço de trabalho" que são bastante grandes. Pode haver 2 ou 3 ou mais deles antes que o conjunto de dados final seja gravado; portanto, é possível usar todo o espaço em disco durante o processamento.

Agora, para outras soluções. Conforme mencionado nos comentários acima, existe a opção de criar um conjunto de dados do mosaico . Esse conjunto de dados permitirá não apenas tratar todos os blocos individuais como uma única imagem uniforme, mas também manterá os metadados sobre os blocos individuais contidos. Também permite executar operações de varredura, como Hillshade .

A outra opção que eu recomendaria, com base no seu comentário sobre o desejo de separar as zonas, seria criar um Catálogo Raster . Um catálogo raster é essencialmente uma camada de grupo. Você pode adicionar vários conjuntos de dados de varredura a ele. Eles podem ser gerenciados em um geodatabase e importar os rasters, ou simplesmente criar um conjunto de dados não gerenciado, onde o Catálogo Raster mantém caminhos para os conjuntos de dados raster originais. Ao carregar essa camada no ArcMap, você pode definir as propriedades de exibição para carregar apenas um certo número de blocos de varredura de uma só vez ou definir a escala e a resolução da exibição.
Atualmente, estou usando um catálogo raster para agrupar um conjunto de fotos aéreas de mais de 100 GB. O desempenho é muito bom. Se você estiver procurando por um tipo diferente de armazenamento de dados simplesmente como meio de gerenciar um grande número de blocos, então eu realmente o recomendaria.

Aqui está o código que você pode usar para criar um Catálogo Raster e depois importar uma área de trabalho de blocos :

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")

Espero que isto ajude!

------------- Editar

Aqui está um gráfico das peças manuseadas pelo meu catálogo raster. Observe que você pode optar por exibir os wireframes ou os dados de varredura. O catálogo de varredura possui uma tabela de atributos à qual você pode adicionar campos, por exemplo, se desejar adicionar designações de zona como no seu gráfico. Em seguida, você pode optar por mostrar apenas os rasters em uma zona específica.
Ao imprimir em um gráfico a partir da exibição de layout, é usada a resolução total dos rasters, para que não haja perda de qualidade na impressão.

Aqui está o mesmo gráfico, mas mostrando alguns dados de varredura, junto com alguns wireframes.

Eu sei que estou atrasado para a festa. Mas aqui está minha sugestão.

1) tamanho da imagem
Se os originais de 550 GB não forem compactados, você deve convertê-los em arquivos tiff compactados em jpeg. Mantenha-os individualmente (não mesclados). Você pode comprimir usando arcgis, gdal, o que quiser. Compressão você chegará a cerca de 23 GB. Ainda não crie pirâmides / visões gerais. Para compactar você pode usar qualquer programa gis que desejar, mas eu gosto de usar gdal, então o comando é basicamente o seguinte:

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

Você pode criar facilmente um arquivo bat que passa por todas as suas frases não compactadas. Eu gosto de usar o gdalwarp para compactar minhas imagens em vez do usual gdal_translate, porque é mais rápido (usando a opção múltipla para vários núcleos e -wm para bastante memória).

2) manipulação como uma única imagem
Você pode criar um mosaico "virtual" usando o formato gdal vrt. Isso é compatível com arcgis, qgis, mapserver, etc. Não tem certeza sobre o mapeador global e o mapinfo. O formato .vrt é apenas um único arquivo xml que lista suas imagens. Esse é um único comando para criar:

gdalbuildvrt nameofmosaic.vrt compressed_tif_folder\*.tif

Este arquivo tem alguns kb de tamanho.

3) visualização rápida
Você precisa criar pirâmides / visões gerais. Basta usar o seu software preferido para isso. Mantendo as ferramentas gdal, você pode:

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

Isso levará muito tempo. Esteja pronto para aguardar 2 a 3 dias de processamento ininterrupto.

4) usando o mosaico
Carregue o mosaico virtual no seu programa gis. Vai ser rápido porque está lendo as visões gerais que estão em apenas um arquivo como um ecw. Quando você aumenta o zoom para a resolução real de suas imagens, somente os poucos visíveis das imagens compactadas serão lidos, e isso também é muito rápido.

5) lidando com suas áreas sem dados que mostram preto
Você tem 3 soluções para isso: i) use um formato de arquivo que lide com nodata, o que será complicado; ou ii) use uma banda alfa ou iii) um arquivo de máscara. Você pode criar uma banda alfa automaticamente na etapa 2 dizendo ao GDAL que você deseja que as áreas nodata estejam na banda alfa - basta adicionar a opção -addalpha:

gdalbuildvrt -addalpha nameofmosaic.vrt compressed_tif_folder\*.tif

O problema com as bandas alfa é que elas se comprimem mal. Portanto, suas visões gerais serão maiores. Se está tudo bem com você, está pronto.

Se você deseja criar um arquivo de máscara, é um pouco mais complicado. E acho que isso não se encaixa na presente pergunta.

Então, espero que isso ajude. Você pode encontrar informações sobre as ferramentas gdal pesquisando no Google. Muitas coisas interessantes por aí.

550GB de dados TIF de entrada são facilmente manipulados por um único arquivo ECW. Temos muitos clientes compactando conjuntos de dados muito maiores do que isso; portanto, não pense que o formato não é capaz nessa área.

Sua estratégia de dividir o projeto em pequenos blocos para minimizar a área nula também é uma boa abordagem a ser adotada na versão atual do formato, pois reduzirá o tempo de compactação

Seu exemplo inclui referência a dados de entrada não assinados de 16 bits. Eu recomendaria o redimensionamento para 8 bits, se possível (dependendo de seus requisitos)

Por favor, explique por que você não conseguiu processar seu projeto usando IMAGINE ou ERMapper, pois sem essas informações eu não posso ajudá-lo. Ou melhor ainda, entre em contato com a equipe de suporte local

Esteja ciente de que, usando o formato de conjunto de dados de mosaico da ESRI, o que as respostas acima não mencionam é o requisito para gerar a camada de pirâmide / visão geral. Sem ele, o desempenho sofrerá consideravelmente. É provável que você possa criar os arquivos equivalentes à ECW na mesma quantidade de tempo, mas tenha melhorado a qualidade da imagem e requisitos de armazenamento de saída significativamente menores.

Embora seja claramente melhor usar uma das outras opções mencionadas, você pode tentar o seguinte:

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

Isso cria um formato virtual GDAL e depois converte em um único GeoTiff.

Isso me parece bastante familiar, também produzimos grandes arquivos ECW únicos de 500 também 1 TB de arquivos TIF. Mas eu não duraria no ArcGIS (ArcObjects e o Geoprocessing Engine), pois ele não é capaz de mosaico dessa quantidade de maneira confiável. Se você deseja permanecer no mundo da ESRI, eu recomendaria mosaicos de pedaços de cerca de 50 GB ou menos ao mesmo tempo para um conjunto de dados raster armazenado em um banco de dados geográfico de arquivos. A ferramenta mosaico tende a travar após um tempo, portanto, é uma boa idéia deixar o ArcGIS liberar memória após alguns GigaBytes.

Outra possibilidade é usar um banco de dados geográfico SDE da empresa ou do grupo de trabalho. Com o SDE, você obtém as antiquadas ferramentas de linha de comando do SDE, construídas em uma arquitetura C ++ robusta que não seja o material não confiável do ArcObjects. Com o comando "sderaster -o mosaic ...", você pode fazer o mosaico para um RasterDataset até que o armazenamento do banco de dados esteja cheio. Também existem comandos para criar pirâmides e estatísticas para o RasterDataset, caso contrário, não é muito útil, porque a maioria dos clientes não pode reter as imagens na memória ao lê-las, como blah238 mencionado acima. Mas as pirâmides (na verdade, indexação espacial) devem resolver esse problema.

Mas essas soluções não ajudam você com o MapInfo, com certeza. Você mencionou que já tentou o ERDAS Mapper. Essa também é a ferramenta que eu preferiria. Já fizemos o mosaico de 16000 arquivos TIF, cada um com 50 MB de tamanho, com 800 GB. Depois, compactamos em um único ECW com uma taxa de compactação de 1:20, o que resultou em um arquivo ECW de 30 GB. Gostaria de saber que isso não está funcionando para você ...

Pelo menos todo o processo estava sendo executado em um único núcleo Pentium 4 1,6 GHz com 2 GB de RAM, portanto o hardware não deve ser o problema. Estamos usando o Windows Server 2003 (ou outro sistema operacional de servidor) porque ele usa melhor os recursos de harware. Lembre-se de que todo o processo de compactação precisa de muito tempo. Nossa máquina estava trabalhando cerca de 5 semanas nesse arquivo único e, como às vezes também travava, tivemos que fazer isso várias vezes, mas no final obtivemos nosso arquivo ECW.

Não conheço outro sistema ou mecanismo para armazenar grandes quantidades de rasters de maneira neutra ao fornecedor. Todas as formas acima mencionadas são muito específicas para ESRI. Pelo menos com o Oracle RASTER e uma implementação bastante semelhante no PostGIS, existem duas variantes baseadas em banco de dados que também não são neutras em relação ao fornecedor, mas abertas pela interface SQL / MM.

Espero que isso ajude um pouco.