Markus Metz wrote: > > 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.
Having -f affect the interpretation of nodata= also harms usability. > >> 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. Yeah, but what are you going to write for nulls in the input data? Suppose the user specifies a CELL input map (which contains at least 0-255 and null), byte (GDT_UInt8) output, -f, and nodata=9999. So you use 9999.0 as GDAL's no-data value, but how will you treat null values in the input data? -- Glynn Clements <gl...@gclements.plus.com> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev