¿Qué hacer con los valores de nodata -3.4e + 38?

17

Estoy tratando de procesar algunos archivos ráster bioclimáticos, como los que se pueden descargar desde http://www.worldclim.org/current (conjunto bioclim). Parecen tener valores de nodata establecidos de -3.4e+38acuerdo con QGIS (mirando la salida de gdalinfo, es -3.39999999999999996e+38).

Parece que las herramientas de gdal no pueden manejar este valor de nodata, y qgis tampoco parece poder reconocerlo. En el estilo de capa, hay una entrada para -3.4e + 38 establecida en 100% transparente, pero aún muestra dichos valores, aunque el selector "Identificar entidades" muestra que tienen un valor -3.4e + 38.

Intenté crear un vrt para convertir los valores de nodata a -9999, pero tampoco funcionó.

¿Cómo puedo procesar dichos archivos para tener valores de nodata utilizables?

valores de nodata recogidos del archivo establecer la transparencia no tiene efecto

qgis raster gdal

— rudivonstaden
fuente

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

— nickves

4

GDAL puede manejar estos valores. De hecho, el valor predeterminado de NoData de GDAL es prácticamente el mismo que el tuyo. Sin embargo, creo que el problema es un error de coma flotante en QGIS. Tengo el mismo problema con los valores de NoData de punto flotante.

Si desea cambiar el valor NoData usando GDAL, puede usar gdalwarp o quizás gdal_translate y establecer el valor nodata en un entero desde allí (-dstnodata y -a_nodata respectivamente). Por inastance, he tenido éxito al establecer mi valor NoData en -999 en un ráster flotante de 64 bits en el pasado. Sin embargo, dado que hemos establecido que hay un problema de coma flotante a este respecto, no me gustaría garantizar que esto funcione en todos los casos.

— MappaGnosis
fuente

Gracias por tu respuesta, Sylvester. No pude hacer que gdal_translate funcionara, gdal_translate -a_nodata -9999 input.tif output.tifaunque gdalwarp -dstnodata -9999 input.tif output.tiffuncionó. Desde un archivo de entrada de 9 MB, mi enfoque resultó en un archivo de 26 MB, mientras que gdalwarp resultó en un archivo de salida de 52 MB. Sin embargo, si el ráster contiene valores flotantes, mi enfoque no funcionará donde este lo hará.

— rudivonstaden

¿Ha verificado si hay un ticket abierto en QGIS bug tracker para esto?

— oscuro

1

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

— MappaGnosis

@underdark No pude encontrar un ticket que coincidiera con esto, así que agregué un informe de error ( hub.qgis.org/issues/6786 ).

— rudivonstaden

1

Para un tamaño de archivo más pequeño, solo necesita agregar -co COMPRESS=LZW.

— j08lue

11

Logré encontrar una solución para este problema al convertir el formato de datos a Int16 desde Float32. El valor mínimo es -32768 y puede procesarse como un valor de nodata. El siguiente comando hizo el truco:

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

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

nodata recogida correctamente

— rudivonstaden
fuente

0

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

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

— stu
fuente

0

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

— kmu2019
fuente