[GRASS-dev] r.out.gdal, again

[Glynn Clements]

Markus Metz wrote:

> >>> r.out.gdal nodata handling could be changed so that the user has to
> >>> provide a nodata value if there are NULLs in the raster, otherwise
> >>> r.out.gdal aborts with an error.
> >>>       
> >> That's reasonable for integer maps, but for FP maps it makes more
> >> sense to simply default to NaN as the no-data value (the two are
> >> essentially the same concept, so there is no information loss in using
> >> NaN).
> >>     
> >
> > Do other software packages understand 'Nan' ?
> 
> Do other file formats understand Nan? Reading a bit in GDAL API
> documentation lets me suspect that NaN is not allowed, because for
> GeoTIFF, you can specify a NoData value as in the current implementation
> or you can add an internal mask, no mentioning of writing NaN for
> Float32 or Float64 to a GDAL raster band. Did I overlook something?

Any code which deals with floating-point values would have to go out
of its way to avoid NaNs, i.e. actively check for them and flag an
error. Likewise for infinities. 

If code just passes floating-point values around without explicitly
classifying them, most of the time it will get the correct behaviour
without even trying.

I suspect that the most likely reason for code to handle NaN
incorrectly would be equality checks, i.e. "if (x == null_val)" won't
work if null_val is NaN (it will always be false, even if x is NaN). 
OTOH, floating-point equality checks have plenty of other problems
(e.g. x86 using 64 bits for a double stored in memory but 80 bits for
a register, meaning that "x = y; if (x == y) ..." won't necessarily
work for non-NaN values either).

-- 
Glynn Clements <glynn at gclements.plus.com>