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

[Markus Metz]

On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:
>
> 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 ?

The main difference between v.univar and v.db.univar is that v.univar works
with geometries while v.db.univar works with the attribute table. If vector
geometries share the same category value, or if some vector geometries have
more than one category value, the results of v.univar and v.db.univar for
the same column will be different. If you want results with category (or
class) as unit, use v.db.univar, if you want results with vector geometry
as unit, use v.univar.

v.univar can also compute statistics on the distances between vector
geometries. There is no explanation in the manual what this should be good
for. Markus N, you wanted this feature many years ago, do you remember why?

Markus M

>>>
>>> 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
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170621/de7d1cf1/attachment.html>