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

[Markus Metz]

On Thu, Jun 22, 2017 at 4:01 PM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:
>
> 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.

I have modified the description of v.univar regarding distance calculations
in r71210,1. Backport now?

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