[GRASS5] r.average and FP maps

[Glynn Clements]

Markus Neteler wrote:

> > > I have tried to average elevations for selected zones
> > > with r.average but wasn't quite successful.
> 
> > The nature of r.stats is such that it doesn't make sense to use it on
> > FP maps; the behaviour would typically degenerate to "r.stats -1",
> > i.e. each FP value which actually occurred in the map would be output
> > with an associated count of 1 (or an associated area equal to the area
> > of a cell).
> > 
> > Programs such as r.statistics or r.average may as well use something
> > like:
> > 
> > 	r.stats -1 | sort -n -k 1 | uniq -c | awk '{print $2, $3, $1}'
> > 
> > for FP maps, and scale the cell counts by the area of a cell.
> > 
> > Note that this will be significantly slower than using r.stats. 
> > However, it will be more accurate, as no quantisation is occurring.
> 
> That's fine. Time is not an issue if it worked... at time it is
> sort of broken.

In what sense? r.average seems to work OK for FP maps, apart from the
warning and the fact that the results will contain inaccuracies due to
averaging the quantised values rather than the actual values.

r.statistics simply refuses to run if the cover map is an FP map. 
There isn't any inherent reason which it can't work with FP maps
although, again, the results will be inaccurate due to quantisation.

> > With the r.stats approach, increasing the quantisation granularity
> > would improve accuracy; OTOH it will also increase r.stats' memory
> > consumption. In the degenerate case, r.stats will end up with one
> > "bin" per cell, i.e. storing both maps in memory in a very inefficient
> > format (a 28-byte Node structure per cell in addition to the actual
> > cell values).
> 
> Isn't this somewhat related to the new r.univar implementation?
> The memory problem will be similar.

No. r.univar produces a single set of statistics for the entire map.
Also, it only computes the aggregates which can be produced by
accumulation (i.e. not median or mode).

-- 
Glynn Clements <glynn.clements at virgin.net>