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

[Moritz Lennert]

On 21/06/17 14:57, Markus Neteler wrote:
> 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)

It's always good to be reminded of the things one said in the past. ;-)

However, the module has evolved quite a lot since that discussion, and 
in the direction contrary to what I said in terms of distinguishing the two.

At this stage, I don't see anything in v.db.univar that is not also 
provided by v.univar, but v.univar provides more options than 
v.db.univar. And since v.univar is C, I would suggest keeping that module.

Its man page needs some love, however, as I have the feeling that not 
all info is correct. Notably:

"When using the -d flag, univariate statistics of vector geometry are 
calculated. Depending on the selected vector type, distances are 
calculated as follows:

     type=point: point distances are considered;
     type=line: the first point of each line is considered;
     type=area: the centroid of each area is considered."

but type=area actually creates a fatal error. You have to explicitely 
ask for type=centroid.

It might be interesting, in the long run, to output some general 
statistics on geometries (e.g. on area and perimeter for areas, on 
length for lines), but that would mean duplicating some of v.to.db's code...


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

+1

Moritz