Glynn Clements wrote:
Markus Metz wrote:
I think I slowly begin to understand. You suggest to use
(GDT_Int32)0x80000000 for both the GDAL metadata info and the GDAL
raster data although GDAL metadata nodata is double?
Yes; for the latter, the value would be:
(double) (GDT_Int32) 0x80000000
IOW, -2147483648.0.
Note that this isn't the same as atof("0x80000000"), which would be
positive.
Obviously. Because of the request for a -f flag I was fixed on leaving
r.out.gdal parameters as they are, also leaving default nodata as
double, no prior cast to the GDAL datatype. My confusion, it's clear now
what you want for the default nodata value.
Further on, I understand you suggest to interpret the user given nodata
option by writing to metadata (double) (GDAL datatype) <nodata value>.
No more objections from my side, but I would print a warning if (nodata
!= (double) (GDAL data type) nodata), telling the user what the nodata
value will be after GDAL converted it. I would suggest to keep writing
(double) <nodata value> with the -f flag, no prior cast. In case of the
-f flag and a mismatch (nodata != (double) (GDAL data type) nodata), a
message/warning could be printed with both the nodata value written to
metadata and the value assigned to NULL cells.
I was assuming that not only CELL, but also FCELL and DCELL maps may be
exported as GDT_UInt32. Then 2^31 can occur in the raster to be
exported. Actually, I was assuming that any GRASS raster type may be
exported as any GDAL data type.
Right. But exporting FCELL or DCELL as GDT_UInt32 is inherently lossy.
Just to make it clear: I don't insist on exporting to GDT_UInt32, but
this is supported by r.out.gdal for all GRASS raster types, so this
possibility must be considered IMHO, unless GDT_UInt32 becomes disabled.
For DCELL, every possible GDT_UInt32 value may occur in the source
data, so there isn't any "ideal" default no-data value.
That's why I first want to check the range of the raster map(s) to be
exported.
What if the user asks for a nodata value to be out of range, i.e. really
wants it to be out of range, leading to a mismatch between the nodata
value in the metadata and the value assigned to NULL cells in the GDAL
export? I understood that this was requested to be possible.
Hmm. To allow that, you can't cast to the source or destination type,
Exactly. That's why I was thinking about e.g. (double) 2147483648 to be
written to metadata, and not (double) (GDT_Int32) 2147483648. BTW, I can
still not see why a user would want that, but it can be allowed.
so the user will have to understand the conversion issues even if they
never use an out-of-range value. Ultimately, its either usability or
flexibility.
Without the -f flag I would opt for usability, with the -f flag for
flexibility.
If r.out.gdal should support out of range nodata values, and the nodata
value is read with atof(), 2^31 should stay 2^31and not be cast to
-2^31. The GUI description of the nodata option says that it is of type
float (actually it's a double), i.e. suggesting that any value that is
representable as floating point is ok.
That's a limitation of the parser. If the input is CELL, then the
nodata value which the input data uses isn't any kind of float. It
might be more correct to have separate int/float nodata options.
OTOH, GDAL's no-data value is always a double, even for integer data.
I would rather stick to GDAL's method of handling nodata options and try
to mimic that in r.out.gdal.
I don't have any preference, although I suspect that users will
regularly get bitten by the conversion issues.
As above, by default r.out.gdal could write (double) (GDAL datatype)
<nodata value> to metadata, with the -f flag no cast to GDAL datatype?
The GDAL API documentation says "To clear the nodata value, just set it
with an "out of range" value." This is currently possible with the -f
flag, but r.out.gdal then does not give any information on what value is
assigned to NULL cells, only what nodata value is written to the metadata.
Right. There's only one nodata= option, and it's performing a dual
function: what to store for null cells and what to set GDAL's no-data
value to. If you want to allow a mismatch, you really need two
options.
I thought in this case (allow mismatch) it would be enough to write it
as double to metadata without prior cast to the selected GDAL datatype.
I don't see the point in treating range limits differently to
precision limits. Either the output type is a superset of the input
type (lossless export) or it isn't (lossy export).
Easy to change, with feedback to the user as warning in case of lossy
export.
When exporting to FP types, the default should probably be NaN (if
supported), regardless of whether the source is integer or FP.
Exporting CELL to GDT_Float32 should print a warning if the range of
the input data exceeds +/- 2^24, as it cannot be stored exactly.
OK.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
