Tamanho do arquivo inflação normal com gdalwarp?


19

Depois de usar gdalwarppara projetar e alinhar à grade (via -tap) um número de rasters, notei que os rasters de saída eram significativamente maiores que os rasters originais. Uma pesquisa na Web bastante completa mostrou esse problema do Trac :

Frank Warmerdam explicou o motivo:

"Em uma revisão cuidadosa, a diferença no arquivo em questão é que o gdal_translate usa a interface TIFFWriteScanline () para gravar o arquivo de saída em GTiffDataset :: CreateCopy? (), E isso apenas grava a maior parte da 'faixa' final do necessário para completar a área da imagem. Mas o gdalwarp passa pela interface de bloqueio que grava a faixa final completa, mesmo a parte que cai no final do arquivo. "

No entanto, esse problema do Trac tem aproximadamente 7 anos e sei que algumas alterações nos utilitários GDAL, incluindo gdalwarpforam feitas desde então. Gostaria de saber se o raciocínio acima ainda se mantém e se a inflação do tamanho do arquivo que estou vendo é "normal". A palavra "normal" aqui pode ser considerada não surpreendente ou esperada , mas, mais importante: existe algo que pode ser feito para mitigar os efeitos, ou seja, reduzir o tamanho do arquivo raster de saída? Abaixo está uma tabela da inflação do tamanho do arquivo que estou enfrentando.

Input File Size (bytes)     Output File Size (bytes)    Inflation
1437380431                  1698334217                   18%
1428001178                  1698334433                   19%
  41683165                   137036637                  228%

Os arquivos TIFF de entrada foram criados no ArcGIS e, portanto, possuem arquivos Worldfiles, XML e DBF externos, mas eles não fazem a diferença no tamanho do arquivo. Aqui está um exemplo de gdalwarpchamada, como eu a usei em todos esses casos; a execução real foi tratada por um Python subprocess( subprocess.Popen):

$ gdalwarp -tap -tr 30 30 -t_srs "+proj=aea +lat_1=20 +lat_2=60 +lat_0=40 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs" -co "COMPRESS=LZW" input_file.tif output_file.tif

Entendo que, em casos raros, a compactação cria um arquivo maior, mas o efeito é o mesmo sem a compactação LZW. As proporções na tabela estão com compactação LZW.

Respostas:


30

É um problema conhecido e de longa data que o gdalwarp não lida bem com a compressão . A solução é gdalwarp sem compactação e gdal_translate com compactação.

Para evitar dois processos demorados, gdalwarp para VRT primeiro, é muito rápido e gdal_translate com a opção -co compress = lzw.

ie

$ gdalwarp -tap -tr 30 30 -t_srs "etc..." -of vrt input_file.tif output_file.vrt
$ gdal_translate -co compress=LZW output_file.vrt output_file.tif

Se você estiver usando o GDAL 2x, poderá combinar isso em uma única operação, escrevendo o VRT /vsistdoute canalizando-o para gdal_translatee especificando /vsistdincomo entrada. Por exemplo:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif

Obrigado pela sua solução, que usei com sucesso para evitar um erro de estouro inteiro. Mas enquanto ele resolve o erro, recebo um padrão estranho na minha colina. Eu postei uma pergunta separada aqui, seria ótimo se você pudesse dar uma olhada: gis.stackexchange.com/questions/292632/...
Tim Autin
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.