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

[Moritz Lennert]

Le 23 juin 2017 08:38:43 GMT+02:00, Markus Metz <markus.metz.giswork at gmail.com> a écrit :
>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?

+1

But traveling so can't do it before next week.

Moritz


>
>Markus M