Hi GRASS users (and developers),
there's something strange in the results of r.describe (and r.report,
r.stats) when applied to a floating point map derived from a transformation
of an integer values map. The output is a list of range classes instead of
the actual floating point classes. An example (Spearfish data):
As the original map contain integer values from1 to 8, I suppose the correct
result should be 8 floating numbers from 1.0 to 8.0.
Please note:
a) The same results are obtained with r.stats and r.report, but d.what.rast
output the correct values (so the problem is not in the r.mapcalc).
b) I applied the operation to other maps (elevation.dem for example) with
the same results.
On Mon, Feb 10, 2003 at 11:58:39AM +0100, Aldo Clerici wrote:
Hi GRASS users (and developers),
there's something strange in the results of r.describe (and r.report,
r.stats) when applied to a floating point map derived from a transformation
of an integer values map. The output is a list of range classes instead of
the actual floating point classes. An example (Spearfish data):
As the original map contain integer values from1 to 8, I suppose the correct
result should be 8 floating numbers from 1.0 to 8.0.
Please note:
a) The same results are obtained with r.stats and r.report, but d.what.rast
output the correct values (so the problem is not in the r.mapcalc).
b) I applied the operation to other maps (elevation.dem for example) with
the same results.
"Categories" for floating point rasters are described via
ranges of values. Just because the ranges are not whole numbers does
not mean the underlying raster has values other than whole numbers.
If you want to change the ranges, see the 'nsteps' argument, and also,
r.quant.