Rolf Turner wrote:
'ppp' objects used by 'spatstat' have an annoying structure
SNIP
Annoyance is in the mind of the beholder I think. Personally I
find the structure of ppp objects absolutely *delightful*! :-)
Also, they are simple, intuitive, easy to work with, and easy to
Next time do not spend so much time looking for a window :-)
ppp(x,y, xrange=range(x), yrange=range(y))
This is based on the extent / bounding box of the data.
By the way, there is not *default* window,
And I also find the structure of ppp objects definitely *delightful*!
Cheers,
On Tue, Oct 19, 2010 at 11:58 AM, Karl Ove Hufthammer k...@huftis.org wrote:
And though the ‘window’ element of ‘ppp’ objects may be of use to some
people, I haven’t had any use for it. The annoying thing here is that the
constructor doesn’t generate the window automatically, based on the
@stat.math.ethz.ch
Subject: Re: [R-sig-Geo] Creating density heatmaps for geographical data
On Tue, Oct 19, 2010 at 11:58 AM, Karl Ove Hufthammer k...@huftis.org wrote:
And though the 'window' element of 'ppp' objects may be of use to some
people, I haven't had any use for it. The annoying thing here
The spatstat package is designed for the analysis of spatial point
patterns. In this context the existence of a window --- the
*observation* window --- is absolutely crucial. You have to know where
points have been *looked for*, because there is information in where
the points aren't, as well
On Wed, 20 Oct 2010, Rolf Turner wrote:
The spatstat package is designed for the analysis of spatial point
patterns. In this context the existence of a window --- the
*observation* window --- is absolutely crucial. You have to know where
points have been *looked for*, because there is
Michael Sumner wrote:
Just answering your first question, you could call sm.density for each
point individually, then trim back to whatever level you want. Sum each
grid for each point and you might get a better trim.
Otherwise, you'd need to hack the density functions in kde2d or
On 19/10/2010, at 12:43 AM, Karl Ove Hufthammer wrote:
SNIP
'ppp' objects used by 'spatstat' have an annoying structure
SNIP
Annoyance is in the mind of the beholder I think. Personally I
find the structure of ppp objects absolutely *delightful*! :-)
Also, they are simple,
Karl Ove Hufthammer wrote:
However, since the ‘heatmap’ is really a density estimate, it integrates
to 1. I would instead want the heatmap colours to correspond to real
frequencies (of course, they do, but the actual mapping is not visible on
the colour scale).
I have been thinking a bit
Karl,
Thank you for that - some interesting ideas there. While not a solution for
you - I'm working on a similar problem and I've discovered mapserver(.org)
for the display side of things. It will handle rasters and shape files and
display them quickly on a google map background. It will also
Just answering your first question, you could call sm.density for each point
individually, then trim back to whatever level you want. Sum each grid for
each point and you might get a better trim.
Otherwise, you'd need to hack the density functions in kde2d or sm.density,
or maybe in KernSmooth to
Sean O'Riordain wrote:
Thank you for that - some interesting ideas there. While not a solution
for you - I'm working on a similar problem and I've discovered
mapserver(.org) for the display side of things. It will handle rasters
and shape files and display them quickly on a google map
Dear list members,
Does anybody have suggestions for the best way of creating density heatmaps
for geographical data? With ‘density heatmaps’ I’m not thinking of heatmaps
as in R’s ‘heatmap’ function, but more along the lines of
http://www.heatmapapi.com/
or
13 matches
Mail list logo
