[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

[Glynn Clements]

Markus Metz wrote:

> >> Considering this, rather use e.g. raster_min - 1 as default nodata value 
> >> for GDAL floating point datatypes?
> >
> > If fabs(raster_min) is large, raster_min - 1 won't be exactly
> > representable, and may be rounded to raster_min. You would need to
> > subtract a value which depends upon the exponent.
> >
> > Also, the input data may contain -DBL_MAX. For FCELL, if the map is
> > large enough, it's possible that *all* finite values occur in the
> > data.
> I was (honestly! I was listening to you:-)) thinking about something like
> 
> if (raster_min > type_min) {
> unsigned int i = 0;
> while ((float)(raster_min - ++i) == raster_min);

If fabs(raster_min) is large enough, even subtracting 2^32 may not be
enough to produce a distinct value. Try:

	double i = 1
	while ((float)(raster_min - i) == (float)raster_min)
		i *= 2;

Except, I'm not sure that a simple cast to float is sufficient. In the
absence of -ffloat-store, the values and the comparions may be 80-bit.

I would suggest using frexp() and ldexp(), e.g.:

	int exp;

	frexp(raster_min, &exp);
	nodataval = raster_min - ldexp(1.0, exp - 23);
	
> > The question is: is GDAL's no-data value allowed to be any FP value,
> > or must it be finite? I'm guessing that the GDAL documentation doesn't
> > say (similarly, I don't think it's documented whether GRASS
> > FCELL/DCELL values are allowed to be infinite).
> >
> > Actually, this may depend upon the format. If a format supports FP,
> > the format's specification may dictate whether or not NaN and/or
> > inifinities are considered valid.
> 
> Hmm. I thought the point of using GDAL is that r.out.gdal does *not* 
> have to bother about the format's specifications. IMHO, if there is 
> reason to assume that NaN and/or infinities are not valid for any of the 
> formats supporting FP, r.out.gdal should not use NaN and/or infinities. 
> OTOH, NaN and infinities are described in the IEEE FP standard. I would 
> avoid format-specific code in r.out.gdal, considering the large number 
> of supported formats and the number of creation options for each format 
> (for each format sometimes differing between datatypes, e.g. GeoTIFF).

By that reasoning, r.out.gdal shouldn't write floats, as many of the
formats only support integers.

If you don't use NaN, what will you do when presented with data which
contains both -FLT_MAX and FLT_MAX (or DBL_*)?

Also, NaN has the advantage that software will tend to treat it as
"null" by default (it isn't coincidence that GRASS' nulls behave like
NaN).

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