[GRASS-dev] Re: GRASS 7 status overview

[Michael Barton]

Thanks much for the explanations. A few responses below.


On Feb 13, 2010, at 7:25 PM, Glynn Clements wrote:

> 
> Michael Barton wrote:
> 
>> Should r.statistics simply be replaced with r.statistics2?
> 
> You need both r.statistics2 (accumulator-based statistics) and
> r.statistics3 (quantiles) to get most of the functionality of
> r.statistics.
> 
> Neither module can calculate the mode, although I'm not sure that's
> meaningful for FP data (in the absence of quantisation in the original
> data, you would expect each value to be unique).
> 
>> No explanation of difference, for example, between kurtosis and kurtosis2. 
> 
> The methods whose descriptions begin with "(2-pass)" use a two-pass
> algorithm. The first pass calculates the mean, the second pass
> calculates the aggregate from the deviations.
> 
> The single-pass algorithms can have very poor accuracy if the standard
> deviation is small relative to the mean. You end up calculating:
> 
> 	(mean^N + a) - (mean^N + b)
> 
> where mean^N swamps a and b, leading to excessive relative error in
> the result.
> 
>> It seems that r.statistics3 should be renamed to something more
>> descriptive as it differs functionally from r.statistics
> 
> It can be used as a substitute for r.statistics method=median, but can
> calculate arbitrary quantiles. It's derived from r.quantile.
> 
> r.statistics relies upon r.stats, which doesn't work with FP data and
> which performs poorly with large numbers of categories.

So it sounds like r.statistics2 and r.statistics3 are significant improvements over r.statistics.

> 
>> r.external.out and r.colors.out do not generate the GUI when run from
>> the command line.
> 
> Both generate a GUI when run with --ui. r.external.out doesn't have
> any required arguments (mainly due to -f), while r.colors.out has a
> bug:

It is unclear how r.external.out works. Does it make a GDAL-compatible file appear as a GRASS raster in a mapset? If so, shouldn't this be r.external.in? (i.e., it makes an external raster usable by GRASS)

> 
>> r.colors.out generates a segmentation fault if run
>> without arguments.
> 
> Right; map= should be a required option; fixed in r40984.

Thanks.

> 
>> Trying to run ximgview generates the following error: ERROR:
>> Incompatible library version for module. You need to rebuild GRASS
>>      or untangle multiple installations.
> 
> Either it failed to compile and you're trying to run an old version
> with a newer library, or the -L flags for wxWidgets caused it to pick
> up an old version of the libraries.

I compiled after an svn up, followed by make distclean. So I don't know how I could be trying to run an old version. I don't know about the -L flags in wxWidgets. I'm using a Mac where wxWidgets is wrapped in wxPython.

> 
> Also, ximgview should be superseded by wximgview (except, wximgview
> currently doesn't build on Windows, for the same reason as xganim and
> the vdigit and nviz modules, i.e. trying to link against wxWidgets
> crashes "ld").

OK wximgview works. I guess I misunderstood what this did. So it's to offer a way to view graphics created by d.* commands?

Michael