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

[Moritz Lennert]

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.

Just to illustrate:

g.copy vect=urbanarea,ua

v.category ua op=report
Layer/table: 1/ua
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid     657          1        108
area           0          0          0
face           0          0          0
kernel         0          0          0
all          657          1        108


v.info -t ua
nodes=828
points=0
lines=0
boundaries=1311
centroids=657
areas=666
islands=183
primitives=1968
map3d=0

v.db.addcolumn ua col="testval integer"
v.db.update ua col=testval val=1

v.db.univar ua col=testval
[...]
Sum: 108

v.univar ua col=testval
[...]
sum: 657


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:

v.in.ascii in=- out=testpoints <<EOF
640000|220000
640100|220000
EOF
v.db.addtable testpoints
v.buffer -t testpoints out=testbuffer dist=150

v.category testbuffer op=report
Layer/table: 1/testbuffer
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid       4          1          2
area           0          0          0
face           0          0          0
kernel         0          0          0
all            4          1          2

v.info -t testbuffer
nodes=4
points=0
lines=0
boundaries=6
centroids=3
areas=3
islands=1
primitives=9
map3d=0

v.db.addcolumn testbuffer col="testval integer"
v.db.update testbuffer col=testval val=1

v.db.univar testbuffer col=testval
[...]
Sum=2

v.univar testbuffer col=testval
[...]
sum: 4

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.

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.

Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v.univar.html.diff
Type: text/x-patch
Size: 1805 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170622/56234a72/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v.db.univar.html.diff
Type: text/x-patch
Size: 1393 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20170622/56234a72/attachment-0003.bin>