O que fazer com os valores de -3.4e + 38 nodata?

17

Estou tentando processar alguns arquivos raster bioclimáticos, como os que podem ser baixados em http://www.worldclim.org/current (conjunto bioclim). Eles parecem ter valores nodata definidos de -3.4e+38acordo com o QGIS (olhando para a saída do gdalinfo, é -3.39999999999999996e+38).

Parece que as ferramentas gdal não são capazes de lidar com esse valor nodata, e o qgis também não parece reconhecê-lo. No estilo da camada, há uma entrada para -3,4e + 38 definida como 100% transparente, mas ainda exibe esses valores, mesmo que o seletor "Identificar recursos" mostre-os como tendo o valor -3,4e + 38.

Tentei criar um vrt para converter os valores de nodata para -9999, mas isso também não funcionou.

Como posso processar esses arquivos para terem valores de nodata utilizáveis?

valores nodata apanhados no arquivo definir transparência não tem efeito

qgis raster gdal rudivonstaden
fonte
Supostamente na nova versão, o qgis tem MUITO melhor suporte a nodata. Eu tive muitos problemas de "nodata" com o 1.8 (especialmente quando estava tentando calcular o histograma ou as médias dentro de uma área).
nickves

Respostas:

4

GDAL pode lidar com esses valores. De fato, o valor NoData padrão do GDAL é praticamente o mesmo que o seu. Eu acho que o problema é um erro de ponto flutuante no QGIS. Eu tenho o mesmo problema com valores NoData de ponto flutuante.

Se você quiser alterar o valor NoData usando GDAL, poderá usar gdalwarp ou talvez gdal_translate e definir o valor nodata como um número inteiro a partir daí (-dstnodata e -a_nodata, respectivamente). Para começar, tive sucesso ao definir meu NoData Value como -999 em uma varredura de 64 bits no passado. No entanto, considerando que estabelecemos que há um problema de ponto flutuante nesse sentido, não gostaria de garantir que isso funcione em todos os casos.

MappaGnosis
fonte
Obrigado pela sua resposta, Sylvester. Não consegui fazer o gdal_translate trabalhar, gdal_translate -a_nodata -9999 input.tif output.tifembora tenha gdalwarp -dstnodata -9999 input.tif output.tiffeito o truque. De um arquivo de entrada de 9 MB, minha abordagem resultou em um arquivo de 26 MB, enquanto o gdalwarp resultou em um arquivo de saída de 52 MB. No entanto, se a varredura contiver valores flutuantes, minha abordagem não funcionará onde esta.
Rudivonstaden
Você verificou se existe um ticket aberto no rastreador de erros do QGIS para isso?
Underdark
1
O inchaço dos dados pode ser devido ao uso de uma profundidade de pixel maior (63 bits vs. 16 bits, digamos) ou simplesmente devido ao original ser um JPEG e seu novo resultado ser um TIFF. @underdark - Desculpe! Não, não verifiquei se há um ticket aberto.
MappaGnosis
@underdark Não consegui encontrar um ticket que correspondesse a isso, então adicionei um relatório de erro ( hub.qgis.org/issues/6786 ).
Rudivonstaden
1
Para um tamanho de arquivo menor, basta adicionar -co COMPRESS=LZW.
J08lue 19/05
11

Consegui encontrar uma solução alternativa para esse problema convertendo o formato de dados para Int16 do Float32. O valor mínimo é então -32768 e pode ser processado como um valor nodata. O seguinte comando fez o truque:

gdal_translate -ot Int16 -a_nodata -32768 input.tif output.tif

Provavelmente existe uma solução melhor, mas isso resolve meu problema imediato, pelo menos.

nodata pegou corretamente

rudivonstaden
fonte
0

você pode tentar gdal_calc.py input.tif --outfile = output.tif --calc = "A * (A> 0)" --NoDataValue = 0

kmu2019
fonte