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>