Cosa fare con i valori di nodata -3,4e + 38?

17

Sto cercando di elaborare alcuni file raster bioclimatici, come quelli che possono essere scaricati da http://www.worldclim.org/current (set di bioclim). Sembrano che i valori dei nodati siano impostati -3.4e+38secondo QGIS (guardando l'output di gdalinfo, è -3.39999999999999996e+38).

Sembra che gli strumenti di gdal non siano in grado di gestire questo valore di nodata e nemmeno qgis è in grado di riconoscerlo. Nello stile del livello, c'è una voce per -3,4e + 38 impostata su trasparente al 100%, ma mostra ancora tali valori, anche se il selettore "Identifica caratteristiche" mostra che hanno un valore -3,4e + 38.

Ho provato a creare un vrt per convertire i valori di nodata in -9999 invece, ma non ha funzionato neanche.

Come posso elaborare tali file per avere valori di nodata utilizzabili?

valori di nodata prelevati dal file l'impostazione della trasparenza non ha alcun effetto

qgis raster gdal

— rudivonstaden
fonte

Presumibilmente nella nuova versione qgis ha MOLTO supporto nodata migliore. Ho avuto molti problemi di "nodata" con 1.8 (specialmente quando stavo cercando di calcolare l'istogramma o i mezzi all'interno di un'area).

— Nicks il

4

GDAL può gestire questi valori. In effetti il valore NoData predefinito di GDAL è praticamente uguale al tuo. Penso che il problema sia un errore in virgola mobile in QGIS. Ho lo stesso problema con i valori NoData in virgola mobile.

Se vuoi cambiare il valore NoData usando GDAL puoi usare gdalwarp o forse gdal_translate e impostare il valore nodata su un intero da lì (rispettivamente -dstnodata e -a_nodata). Per inerzia, in passato ho avuto successo impostando il mio valore NoData su -999 in un float raster a 64 bit. Tuttavia, dato che abbiamo stabilito che esiste un problema in virgola mobile a questo proposito, non vorrei garantire che funzionerà comunque in tutti i casi.

— MappaGnosis
fonte

Grazie per la tua risposta, Sylvester. Non sono riuscito a far funzionare gdal_translate usando gdal_translate -a_nodata -9999 input.tif output.tifsebbene gdalwarp -dstnodata -9999 input.tif output.tifabbia funzionato. Da un file di input da 9 MB, il mio approccio ha prodotto un file da 26 MB, mentre gdalwarp ha prodotto un file di output da 52 MB. Tuttavia, se il raster contiene valori float, il mio approccio non funzionerà dove questo sarà.

— rudivonstaden,

Hai verificato se esiste un ticket aperto nel bug tracker QGIS per questo?

— underdark

1

Il gonfiamento dei dati potrebbe essere dovuto all'utilizzo di una maggiore profondità di pixel (63 bit contro 16 bit, diciamo) o potrebbe essere semplicemente dovuto al fatto che l'originale è un JPEG e il tuo nuovo risultato è un TIFF. @underdark - Siamo spiacenti! No, non ho verificato se esiste un biglietto aperto.

— MappaGnosis,

@underdark Non sono riuscito a trovare un biglietto corrispondente a questo, quindi ho aggiunto una segnalazione di bug ( hub.qgis.org/issues/6786 ).

— rudivonstaden,

1

Per file di dimensioni inferiori, è sufficiente aggiungere -co COMPRESS=LZW.

— j08lue,

11

Sono riuscito a trovare una soluzione alternativa per questo problema convertendo il formato dei dati in Int16 da Float32. Il valore minimo è quindi -32768 e può essere elaborato come valore nodata. Il seguente comando ha funzionato:

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

Probabilmente c'è una soluzione migliore, ma questo risolve almeno il mio problema immediato.

nodata raccolto correttamente

— rudivonstaden
fonte

0

La risposta a questa domanda probabilmente risolverebbe anche questo problema: cambiando i pixel dei nodati di -3.40282347e + 38 in un numero diverso in QGIS

In breve, è possibile utilizzare r.null dalla casella degli strumenti di elaborazione per modificare i valori.

— stu
fonte

0

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

— kmu2019
fonte