Hi,
what is the right replacement for r.sum? The NewFeatures [1] (1) page says:
r.sum: merged into G7:r.statistics, G7:r.statistics2, G7:r.statistics3
However, it seems to me that r.univar is the replacement. But on the other hand, r.univar always computes all statistics, so there is certainly some overhead and also reading requires some additional time. This might be significant if you use r.univar in loop, for example with temporal data.
What do you think?
Vaclav
[1] https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures
(1) which needs update anyway, once everything is clear
Vaclav Petras wrote:
what is the right replacement for r.sum? The NewFeatures [1] (1) page says:
r.sum: merged into G7:r.statistics, G7:r.statistics2, G7:r.statistics3
However, it seems to me that r.univar is the replacement. But on the other
hand, r.univar always computes all statistics, so there is certainly some
overhead and also reading requires some additional time. This might be
significant if you use r.univar in loop, for example with temporal data.
r.univar is the replacement for r.sum.
r.statistics and r.stats.zonal (which is the new name for
r.statistics2) create a new map which is a copy of the base map but
with the categories replaced by the aggregate value computed over the
corresponding cells from the cover map.
You could get a similar result to r.univar by using r.stats.zonal with
the -r switch and a base map where all cells contain the same category
value (created using e.g. r.mapcalc "basemap = 1"), then extracting
the value from the reclass table.
But that's inefficient, due to the additional I/O overhead (even for a
1x1 cell map, it will still perform the decoding and rescaling for
each row).
The calculation of additional aggregates by r.univar shouldn't have a
noticeable effect upon performance so long as -e isn't used. The
calculations are trivial compared to the I/O overhead.
--
Glynn Clements <glynn@gclements.plus.com>