#410 Bug in Sextante 1.0

[Giuseppe Aruta]

Description of the bug in Sextante
In a output raster layer (derived from Sextante process) the value of nodata tag is automatically reset to -3.40282346639e+38 after written output nodata cell to right value (eg. -9999).
This causes the output raster to be displayed completely black, instead of nofill, original nodata cells value is read as minimum value and may impact further processing of the file.

[Giuseppe Aruta]

Further experiences.
In the class OpenJUMPRasterLayer I checked that No_Data value was set to a defind value (DEFAULT_NO_DATA_VALUE = -99999). So I modified it to proper RasterLayer.nodata value.

This solves a part of the problem.
a) I load into OJ an elevation raster DEM where some cells have a specific no_data value (say -999)
b) I open Sextante Toolbox and use Raster Basic Statatistics or Histogram
Sextante corretly eliminate these no_data cells from the the count
Before the patch no_data value was taken into account as a valid value

What is not solved:
if I apply a raster algorithm on such DEM (like aspect or slope, for instance) no_data cells (with value -999) are correctly removed from any calculation BUT raster no_data is reset to -3.40282346639e+38. So this original no_data value (-999) is considered by OpenJUMP as min value.

PS) Also Kosmo and GvSIG CE Sextante have the same bug

[mentaer]

Hola Peppe,

I think this is related somewhere to 32 bit float limit???

https://chortle.ccsu.edu/java5/Notes/chap11/ch11_2.html

Perhaps some conversion problem (variable definition) or memory
management problem???

cheers from Stgo,
stefan

On 4/24/16 07:53, Giuseppe Aruta wrote:

Further experiences.
In the class OpenJUMPRasterLayer I checked that No_Data value was set to a defind value (DEFAULT_NO_DATA_VALUE = -99999). So I modified it to proper RasterLayer.nodata value.

This solves a part of the problem.
a) I load into OJ an elevation raster DEM where some cells have a specific no_data value (say -999)
b) I open Sextante Toolbox and use Raster Basic Statatistics or Histogram
Sextante corretly eliminate these no_data cells from the the count
Before the patch no_data value was taken into account as a valid value

What is not solved:
if I apply a raster algorithm on such DEM (like aspect or slope, for instance) no_data cells (with value -999) are correctly removed from any calculation BUT raster no_data is reset to -3.40282346639e+38. So this original no_data value (-999) is considered by OpenJUMP as min value.

PS) Also Kosmo and GvSIG CE Sextante have the same bug

---

** [bugs:#410] Bug in Sextante 1.0**

Status: open
Created: Sun Nov 01, 2015 07:58 AM UTC by Giuseppe Aruta
Last Updated: Sun Nov 01, 2015 07:58 AM UTC
Owner: nobody

Description of the bug in Sextante
In a output raster layer (derived from Sextante process) the value of nodata tag is automatically reset to -3.40282346639e+38 after written output nodata cell to right value (eg. -9999).
This causes the output raster to be displayed completely black, instead of nofill, original nodata cells value is read as minimum value and may impact further processing of the file.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/jump-pilot/bugs/410/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Giuseppe Aruta]

Hi Stefan,
thanks for the link, again.
Another possible solution:let postProcess() method into OpenJUMPRasterLayer to write original layer nodata value as TIFFField in TIFFEncodeParam. Should this rewrite float limit number?
I will do some tests

PS GvSIGImageDataAccesor class used by into Kosmo (and probably by GvSIG CE) gives back the double value -1.7E+308 as no-data
Peppe

[Giuseppe Aruta]

Solved on OJ rev 5048