[GRASS-dev] v.univar vs v.db.univar

[Markus Neteler]

On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> Do we really need v.db.univar ? Does it provide anything else/better than
> v.univar ?
>
> Just to avoid module bloat and maybe rationalize when possible.

+1 but mayI cite you... :-)

https://lists.osgeo.org/pipermail/grass-dev/2008-January/035102.html
(copy below)

Since sime time passed, we may indeed want to revisit the topic.

ciao, Markus


On Mon, Jan 28, 2008 at 1:50 PM, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 27/01/08 20:30, Michael Barton wrote:
>>
>> v.univar only works with points. But since it is calculating stats on a
>> field in the attributes table, it should work the same for all vector
>> objects. Can we get rid of the limitation that it only works with points?
>
> There was some debate [1] about the statistical validity of working with the
> other types, as the way it was programmed, the statistics were calculated
> with weights which corresponded to line length / area surface .
>
> I guess we might want to distinguish between a v.univar which works on the
> actual vector objects from a v.db.univar which works on any arbitrary
> attribute (or combination of attributes). We could write a C-replacement of
> the current v.db.univar script on the base of the code I have for the
> classification algorithms used in v.class.
>
> As mentioned earlier, it might be better that I move the code from v.class
> into a library which can then be accessed by different modules...
>
> Currently, I have defined the following statistics:
>
> typedef struct
> {
>     double count;
>     double min;
>     double max;
>     double sum;
>     double sumsq;
>     double mean;
>     double var;
>     double stdev;
> } STATS;
>
>
> But this could easily be extended according to needs and v.db.univar could
> also use the quantile classification algorithm to extract percentiles.
>
> What are the statistics most people need ?
>
> Moritz
>
> [1] http://lists.osgeo.org/pipermail/grass-dev/2004-July/014976.html