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

[Moritz Lennert]

On 22/06/17 15:25, Moritz Lennert wrote:
> On 22/06/17 14:21, Markus Metz wrote:
>>
>>
>> On Thu, Jun 22, 2017 at 10:53 AM, Moritz Lennert
>> <mlennert at club.worldonline.be <mailto: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>
>> <mailto: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>
>> <mailto: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.
>
> Right.
>
>>>
>>> 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.
>
> Ok.
>
>>
>> v.db.univar uses db.univar, not db.select, that's an error in the
>> existing manual.
>
> But db.univar uses db.select to access the data, so I don't consider
> this an error in the manual...
>
>>
>> I suggest to update the manuals first, then decide if the modules should
>> be modified.
>
> Ok. See r71207 and r71208. Please check and tell me if I can backport.

Plus a further attempt at a better formulation for v.db.univar in r71209.

Moritz