[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


More information about the grass-dev mailing list