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

[Markus Metz]

On Tue, May 29, 2018 at 2:21 PM, Moritz Lennert <
mlennert at club.worldonline.be> wrote:
>
> Le Tue, 29 May 2018 08:59:47 +0200,
> Markus Metz <markus.metz.giswork at gmail.com> a écrit :
>
> > 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.
> >
>
> Thanks. I'll have to think about this a bit more when I have the time
> to fully understand. I imagine there should be a way to calculate the
> multiplier necessary to reach the correct sum

I don't think there is something like "the correct sum".

v.kernel provides an estimate for each output cell, how evenly the input
points are distributed around this cell. The definition of "evenly" depends
on the kernel function and bandwidth.

Markus M


> using some
> combination region extent, radius and resolution... But no time for
> such thinking right now.
>
> BTW, in my previous mail I wrote:
>
> > g.region n=9 s=0 w=0 e=9 res=2
> [...]
> > 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.
>
> This was wrong as the g.region call leads to a region with res=1.8 and
> so the v.kernel call should have used multiplier=3.24 which does lead
> to a sum of 0.99.
>
> But when I reduce or increase the radius this doesn't work anymore.
> Don't know if this is linked in any way to the fact that extent of 9
> divided by radius of 5 equals 1.8 which is exactly the resolution, or
> whether this is pure chance... ;-)
>
> Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180529/d607ca32/attachment.html>