<div dir="ltr"><br><br>On Tue, May 29, 2018 at 3:48 PM, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>><br>> Le Tue, 29 May 2018 15:19:39 +0200,<br>> Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> a écrit :<br>><br>> > On Tue, May 29, 2018 at 2:21 PM, Moritz Lennert <<br>> > <a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>> > ><br>> > > Le Tue, 29 May 2018 08:59:47 +0200,<br>> > > Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> a écrit :<br>> > > <br>> > > > On Mon, May 28, 2018 at 6:16 PM, Moritz Lennert < <br>> > > > <a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> wrote:<br>> > > > ><br>> > > > > Hi,<br>> > > > ><br>> > > > > AFAIU kernel density calculations, one takes a number of points<br>> > > > > and <br>> > > > redistributes this total number across the entire region using a<br>> > > > specified kernel function as estimator as to the spatial pattern<br>> > > > of this redistribution. The total sum should correspond to the<br>> > > > total number of points in the input. Is this understanding<br>> > > > correct ? <br>> > > > ><br>> > > > > In v.kernel, this seems to be dependent on the resolution:<br>> > > > ><br>> > > > > echo "4.5,4.5" | v.in.ascii in=- sep=comma out=testpoint<br>> > > > ><br>> > > > > g.region n=9 s=0 w=0 e=9 res=1<br>> > > > > v.kernel in=testpoint out=testrast  radius=5 kernel=gaussian --o<br>> > > > > r.univar testrast<br>> > > > > [...]<br>> > > > > sum: 0.999544365566944<br>> > > > ><br>> > > > ><br>> > > > > but<br>> > > > > g.region n=9 s=0 w=0 e=9 res=2<br>> > > > > v.kernel in=testpoint out=testrast  radius=5 kernel=gaussian --o<br>> > > > > r.univar testrastr s<br>> > > > > [...]<br>> > > > > sum: 0.308567902849234<br>> > > > ><br>> > > > > IMHO, the sum should always be close to 1, or ? <br>> > > ><br>> > > > I think not, because the Gaussian kernel is a general Gaussian<br>> > > > function with user-defined sigma = dmax / 4 [0]. The sum would be<br>> > > > close to 1 only for a normal function (special case of the<br>> > > > Gaussian function) with sigma determined from the observed<br>> > > > distances. For the Gaussian kernel, the sum of the output raster<br>> > > > should increase with higher resolution and constant sigma.<br>> > > > <br>> > ><br>> > > Thanks. I'll have to think about this a bit more when I have the<br>> > > time to fully understand. I imagine there should be a way to<br>> > > calculate the multiplier necessary to reach the correct sum <br>> ><br>> > I don't think there is something like "the correct sum".<br>><br>> You are right. Correct is not the right term. However:<br>><br>> ><br>> > v.kernel provides an estimate for each output cell, how evenly the<br>> > input points are distributed around this cell. The definition of<br>> > "evenly" depends on the kernel function and bandwidth.<br>><br>> I do not have the exact same understanding of kernel estimation: For me<br>> it distributes an existing population (defined in GRASS as one per<br>> point - others provide option to use a population attribute) across a<br>> space. How it is distributed depends on the kernel function and<br>> bandwidth. The idea being that for a series of observations in space<br>> the exact location of that observation is somewhat random and that you<br>> can thus distribute the actual observations across space.<br>><br>> If you only have a sample of observations, then you can use a<br>> multiplier to estimate total observations as long as your sample is<br>> well distributed. But if you have the total population, then you<br>> distribute this population in space and the sum across this space<br>> should correspond to your population.<br>><br>> Here's how they explain it in the ArcGIS manual (hardly a reference I<br>> know, but still):<br>><br>> "Conceptually, a smoothly curved surface is fitted over each point. The<br>> surface value is highest at the location of the point and diminishes<br>> with increasing distance from the point, reaching zero at the Search<br>> radius distance from the point. Only a circular neighborhood is<br>> possible. The volume under the surface equals the Population field<br>> value for the point, or 1 if NONE is specified. The density at each<br>> output raster cell is calculated by adding the values of all the kernel<br>> surfaces where they overlay the raster cell center."[1]<br>><br>> Often texts start by saying that the simplest form of the density<br>> estimation is the histogram. Kernel functions then allow to make this<br>> smoother, but IMU the surface beneath the curve should stay the same.<br>><br>> See also the answer by whuber at [2] using the sand analogy. And the<br>> reference mentioned in the next post [3], where it is said<br>><br>> "In Figure 4‑43, for each point (7,8,9,12 and 14) we have provided a<br>> Normal distribution curve with central value (the mean) at the point in<br>> question and with an average spread (standard deviation) of 2 units. We<br>> can then add the areas under each of these curves together to obtain a<br>> (cumulative) curve with two peaks, and then divide this curve by 5 to<br>> adjust the area under the curve back to 1 giving the lower red curve<br>> shown. When adjusted in this way the values are often described as<br>> probability densities, and when extended to two dimensions, the<br>> resulting surface is described as a probability density surface, rather<br>> than a density surface. We now have a density value for every position<br>> along the original line, with smooth transitions between the values,<br>> which is exactly what we were trying to achieve."<br>><br>> I guess the question is whether we are speaking about normalized or not<br>> normalized density ?<br><div><br></div><div>When you have a curve or a curved surface, you can normalize to 1. However, the output raster is a sample of the curved surface at discrete locations (cell centers). Therefore the sum should increase with higher resolutions, keeping everything else constant.</div><div><br></div><div>Markus M<br></div><div>></div>><br>> Moritz<br>><br>> [1]<br>> <a href="https://pro.arcgis.com/en/pro-app/tool-reference/spatial-analyst/how-kernel-density-works.htm#GUID-3BCBF5CA-CAC7-4547-A3CF-B5E30FDE584E">https://pro.arcgis.com/en/pro-app/tool-reference/spatial-analyst/how-kernel-density-works.htm#GUID-3BCBF5CA-CAC7-4547-A3CF-B5E30FDE584E</a><br>> [2]<br>> <a href="https://gis.stackexchange.com/questions/1553/how-to-interpret-grass-v-kernel-results">https://gis.stackexchange.com/questions/1553/how-to-interpret-grass-v-kernel-results</a><br>> [3]<br>> <a href="http://www.spatialanalysisonline.com/HTML/?density__kernels_and_occupancy.htm">http://www.spatialanalysisonline.com/HTML/?density__kernels_and_occupancy.htm</a><br><br></div>