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

[Markus Metz]

On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:
>
> On 21/06/17 22:19, Markus Metz wrote:
>>
>>
>> On Wed, Jun 21, 2017 at 4:30 PM, Moritz Lennert
>> <mlennert at club.worldonline.be <mailto: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 <mailto: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.
>
>
> Right. Didn't think about this. So they are actually complementary.
>
[...]
>
> However, in the case of multiple cat values per feature, it seems that
v.univar actually reads the attribute once for every geometry/category
combination, not only for each feature:

According to the source code, yes.

[...]
>
> I don't know if this is the desired feature or if each geometry should
only be taken into account once, whatever its number of categories. I
personally would have expected the latter, if we consider v.univar to be
geometry-based.

If each geometry should be taken into account only once, a corresponding
category / attribute value would need to be randomly picked. Therefore I
would prefer to consider all categories for each geometry.
>
> All this definitely needs clearer documentation in the man page. Attached
an attempt to amend the two respective man pages. MarkusM, is this correct
? However, the above question concerning v.univar probably should be
checked before I commit this.

According to the source code, v.univar reads attributes for all categories
of a geometry.

v.db.univar uses db.univar, not db.select, that's an error in the existing
manual.

I suggest to update the manuals first, then decide if the modules should be
modified.

Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170622/f732b8d2/attachment.html>