[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