On Wed, Jun 21, 2017 at 11:54 AM, Moritz Lennert <[email protected]> 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 <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
