21 votos

¿Qué hacer con -3,4e+38 valores nodata?

Estoy intentando procesar algunos archivos raster bioclimáticos, como los que se pueden descargar de http://www.worldclim.org/current (conjunto bioclimático). Parecen tener valores nodata establecidos en -3.4e+38 según QGIS (mirando la salida de gdalinfo, es -3.39999999999999996e+38 ).

Parece que las herramientas gdal no son capaces de tratar con este valor nodata, y qgis tampoco parece ser capaz de reconocerlo. En el estilo de la capa, hay una entrada para -3.4e+38 establecido en 100% transparente, pero todavía muestra estos valores, a pesar de que el selector "Identificar características" muestra que tienen valor -3.4e+38.

He intentado crear un vrt para convertir los valores nodata a -9999 en su lugar, pero tampoco ha funcionado.

¿Cómo puedo procesar estos archivos para obtener valores nodata utilizables?

nodata values picked up from file setting transparency has no effect

0 votos

Supuestamente en la nueva versión qgis tiene MUCHO mejor soporte de nodata. Tuve muchos problemas de "nodata" con 1.8 (especialmente cuando intentaba calcular el histograma o las medias dentro de un área).

12voto

rudivonstaden Puntos 1684

He encontrado una solución a este problema convirtiendo el formato de los datos de Float32 a Int16. El valor mínimo es entonces -32768 y puede ser procesado como un valor nodata. El siguiente comando hizo el truco:

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

Probablemente haya una solución mejor, pero al menos esto resuelve mi problema inmediato.

nodata picked up correctly

7voto

Nick Puntos 3115

GDAL puede manejar estos valores. De hecho, el valor NoData por defecto de GDAL es prácticamente el mismo que el tuyo. Creo que el problema es un error de punto flotante en QGIS sin embargo. Yo tengo el mismo problema con los valores NoData en coma flotante.

Si quieres cambiar el valor de NoData usando GDAL puedes usar gdalwarp o quizás gdal_translate y establecer el valor nodata a un número entero a partir de ahí (-dstnodata y -a_nodata respectivamente). Por ejemplo, en el pasado he tenido éxito estableciendo mi valor NoData a -999 en un raster flotante de 64 bits. Sin embargo, dado que hemos establecido que hay un problema de punto flotante en este sentido, no me gustaría garantizar que esto funcione en todos los casos.

1 votos

Gracias por su respuesta, Silvestre. No he conseguido que gdal_translate funcione utilizando gdal_translate -a_nodata -9999 input.tif output.tif aunque gdalwarp -dstnodata -9999 input.tif output.tif hizo el truco. A partir de un archivo de entrada de 9 MB, mi método dio como resultado un archivo de 26 MB, mientras que gdalwarp dio como resultado un archivo de salida de 52 MB. Sin embargo, si la trama contiene valores flotantes, mi método no funcionará mientras que éste sí.

0 votos

¿Has comprobado si hay un ticket abierto en el bug tracker de QGIS para esto?

1 votos

La sobrecarga de datos podría deberse a una mayor profundidad de píxeles (63 bits frente a 16 bits, por ejemplo) o simplemente a que el original es un JPEG y el nuevo resultado es un TIFF. @underdark - ¡Lo siento! No, no he comprobado si hay un ticket abierto.

0voto

JAL Puntos 11164

La respuesta a esta pregunta probablemente también resolvería este problema: Cambio de píxeles nodata de -3.40282347e+38 a un número diferente en QGIS

En resumen, puede utilizar r.null de la caja de herramientas de procesamiento para cambiar los valores.

0voto

Parrish Puntos 1

Puedes probar gdal_calc.py input.tif --outfile=output.tif --calc="A*(A>0)" --NoDataValue=0

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X