[GRASS-dev] Re: v.kernel output question

Isaac Ullah isaac.ullah at asu.edu
Tue Jan 26 18:04:25 EST 2010


Well, I just realized that I was using the wrong module for what I wanted to
do. v.neighbors does exactly what I want. However, the man page fro v.kernel
is still quite spare, and if I made the mistake of thinking it would make a
normal density map, then I think others may do so too? I'm still not
entirely sure what v.kernel is actually calculating. Since it's listed as
"Generate Gaussian Kernel Density Surface" in the "generate surfaces"
portion of the raster menu in the GUI, and v.neighbors is listed as
"Neighborhood Points" in the 'Neighborhood Analysis" portion of the raster
menu in the GUI, it seems at a casual glance that v.kernel would be the one
to make density maps, and not v.neighbors, even though it is, in reality,
vice versa. And there is no info in the man page of v.kernel that suggests
otherwise. I hope other's read this and don't make the same mistake I did!
:)

Cheers,

Isaac


On Tue, Jan 26, 2010 at 12:18 PM, Isaac Ullah <isaac.ullah at asu.edu> wrote:

> Hi all,
>
> I'm running an experiment to simulate the distribution of microartifacts
> (less than 1mm sized artifacts) on ancient housefloors. The simulations
> essentially produce vector point files where each point is the location of a
> single microartifact. These are arranged as clusters across a rectangular
> space (region extents), and there are several hundred thousand points in
> each vector point file. To simulate archaeological recovery of these
> microartifacts, I am using v.kernel to create density maps of the points at
> different resolutions. My question here concerns the output of v.kernal. Do
> the numbers in an output v.kernal density map represent density over some
> standard unchanging unit (ie. map unit), or is it density per the current
> resolution? The reason I'm asking is that the actual numbers in the output
> maps do not seem to be changing even though the resolution is different. For
> example, if I set the resolution to 10cm (0.1m), I get values ranging from 0
> to over 2000. When I then change the resolution to 1m, I still get values
> ranging from 0 to 2000. The pattern of distribution between the maps is
> similar, so that seems to be working. This all makes me think that v.kernel
> is calculating the density of points *per some standard unit* rather than
> just counting the number of points in one cell given the current raster
> resolution (set in g.region). If the later was occurring, then I would
> expect an output map with raster resolution of 1m to have much higher counts
> per cell than one with resolution of only 10cm. The man page for v.kernel
> does not mention anything about this (and in fact pretty mentions very
> little at all). So I guess my question is: Can anyone confirm for me that
> v.kernel output will be density per map unit, or density per current
> resolution settings? I just need to know so that I can quantify my results
> properly. And while we are on it, can anyone also explain to me what the
> "standard dev" option in v.kernel actually does? Like I said before, the man
> page is lacking in these details...
>
> Any help will be greatly appreciated!
>
> Cheers,
>
> --
> Isaac I Ullah, M.A.
>
> Archaeology PhD Candidate,
> ASU School of Evolution and Social Change
>
> Research Assistant,
> Mediterranean Landscape Dynamics Project
> ***************************************************
> isaac.ullah at asu.edu
> ullah at archaeologist.com
>
> http://www.public.asu.edu/~iullah <http://www.public.asu.edu/%7Eiullah>
> ***************************************************
>



-- 
Isaac I Ullah, M.A.

Archaeology PhD Candidate,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project
***************************************************
isaac.ullah at asu.edu
ullah at archaeologist.com

http://www.public.asu.edu/~iullah
***************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20100126/06519d65/attachment.html


More information about the grass-dev mailing list