The NODATA value in this raster format can be anything specified in
the file header; as far as I understand, it might not even be of the
same type of the raster itself. In this new patch the NODATA value is
read from the file header (the code was actually there already). In
case the file does not declare a NODATA value the property is left
The readIntegerBased and readDoubleBased methods are also new,
dispensing the try-catch block. Now no assumptions are made on the
type of the values in the grid. For integers, a NODATA value is
translated into Integer.MIN_VALUE; not an optimal solution but better
than the alternative null.
On 14 March 2015 at 19:10, Luís de Sousa <[log in to unmask]> wrote:
> Dear all,
> Inadvertently, I produced a raster with an extra row of empty values
> (marked with NODATA). The ArcInfoASCGridImporter class reads the
> raster cell by cell, requesting a double through java.util.Scanner.
> Since NODATA is not a double the Scanner class raises an
> InputMismatchException. I am attaching this rogue raster file.
> In this patch the NODATA value is hard coded. I am not certain if in
> this raster format NODATA can be something else. I will study this
> P.S.: we definitely need to get GDAL working ... I will look into it
> again one of these days.