# [GRASS-dev] v.kernel: should the module take into account the resolution for default output ?

Moritz Lennert mlennert at club.worldonline.be
Mon May 28 09:16:06 PDT 2018

```Hi,

AFAIU kernel density calculations, one takes a number of points and
redistributes this total number across the entire region using a
specified kernel function as estimator as to the spatial pattern of this
redistribution. The total sum should correspond to the total number of
points in the input. Is this understanding correct ?

In v.kernel, this seems to be dependent on the resolution:

echo "4.5,4.5" | v.in.ascii in=- sep=comma out=testpoint

g.region n=9 s=0 w=0 e=9 res=1
v.kernel in=testpoint out=testrast  radius=5 kernel=gaussian --o
r.univar testrast
[...]
sum: 0.999544365566944

but
g.region n=9 s=0 w=0 e=9 res=2
v.kernel in=testpoint out=testrast  radius=5 kernel=gaussian --o
r.univar testrast
[...]
sum: 0.308567902849234

IMHO, the sum should always be close to 1, or ?

If we consider that the value per pixel is in points/squared map unit,
i.e. in a meter-projection, points/m2, then we would have to multiply
the output value, which can be done with the multiplier parameter. In
this case, a resolution of 2, means we have 4m2, so:

v.kernel in=testpoint out=testrast  radius=5 kernel=gaussian
multiplier=4 --o
r.univar testrast
[...]
sum: 1.23427161139693

So this is close, but not very precise.

So, do I understand correctly that the density calculated is by squared
map unit ? Would it make more sense to make the output by pixel ? If
not, and so if the multiplier option is the way to go, this should
probably go into the manual, which currently sounds as if this parameter
is only for the network version of v.kernel:

"The multiplier option is needed to overcome the limitation that the
resulting density in case of a vector map output is stored as category
(integer). The density result stored as category may be multiplied by
this number. "

Moritz
```