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

[Markus Metz]

On Mon, May 28, 2018 at 6:16 PM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:
>
> 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 ?

I think not, because the Gaussian kernel is a general Gaussian function
with user-defined sigma = dmax / 4 [0]. The sum would be close to 1 only
for a normal function (special case of the Gaussian function) with sigma
determined from the observed distances. For the Gaussian kernel, the sum of
the output raster should increase with higher resolution and constant sigma.

Markus M


[0]
https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c#L434
>
> 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
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180529/bf4b6f64/attachment.html>