[GRASS-dev] Re: [GRASS-SVN] r33673 - in grass/trunk/raster: .
r.statistics2
Glynn Clements
glynn at gclements.plus.com
Sun Oct 5 16:53:37 EDT 2008
Markus Neteler wrote:
> > Author: glynn
> > Date: 2008-10-04 18:40:43 -0400 (Sat, 04 Oct 2008)
> > New Revision: 33673
> ...
> > Added: grass/trunk/raster/r.statistics2/r.statistics2.html
> > ===================================================================
> > --- grass/trunk/raster/r.statistics2/r.statistics2.html (rev 0)
> > +++ grass/trunk/raster/r.statistics2/r.statistics2.html 2008-10-04 22:40:43 UTC (rev 33673)
> > @@ -0,0 +1,16 @@
> > +<h2>DESCRIPTION</h2>
> > +
> > +<em>r.statistics2</em> is intended to be a partial replacement for
> > +r.statistics, with support for floating-point cover maps at the
> > +expense of not support quantiles.
>
> ... could you elaborate on the limitations ("partial replacement")?
> Any reason to keep r.statistics?
r.statistics2 lacks quantiles, mode and diversity, as these can't be
calculated by accumulation (i.e. they require sorting and/or binning
of the cover values).
r.statistics relies upon the binning and sorting performed by r.stats,
but that relies upon quantisation to keep the number of bins down.
With unquantised FP maps, it's quite likely that you will end up with
approximately one bin per cell. For large maps, this may exceed
available memory, and sorting such large arrays will be slow.
Computing the missing attributes (without loading the maps into
memory) would require an approach similar to r.quantile, but with
fewer bins (you need one set of bins for each base category) and thus
more passes. That's really a job for a separate module, as its
structure would be entirely different to r.statistics2.
If there are only a few base categories, you could just run r.quantile
once for each category.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list