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 get non-Gaussians, or otherwise to ensure the density is only calculated for a smaller local region around the point. KernSmooth package may well have more control over this stuff. Cheers, Mike. On Thu, Oct 14, 2010 at 1:30 AM, Karl Ove Hufthammer <k...@huftis.org>wrote: > 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 > http://blog.spatialkey.com/2010/02/comparing-thematic-maps-with-density- > heatmaps/ > > (Yes, basically, itâs just a 2D density estimate overlain a map.) > > I *have* managed to create an OK heatmap using âsm.densityâ to get a > density > estimate, converting it a format âlevelplotâ understands, plotting it with > âlevelplotâ, with the âpanelâ function set to include a > âsp.polygonâ > function to first draw a simple map before drawing the actual density with > âpanel.levelplotâ. > > Iâm not entirely happy with this approach, though. First note that the main > reason I use âsm.densityâ instead of âkde2dâ is that âsm.densityâ > accepts a > âweightsâ arguments. Since each of my observations contains > frequency/weight > information, I need this, and âsm.densityâ seems to handle it well. > > 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). It would also be nice if I could set the range used for > the colour scale directly, so that maps created at different times would be > comparable in terms of their visual appearance (e.g., dark red would always > correspond to a value of 1000). Right now I use the bpy.colors palette, but > other suggestions are very welcome. > > Another problem is that âsm.densityâ uses a Gaussian kernel. This means > that > my *entire* map is coloured, even areas far from any observations (and of > course overlapping the background map). My solution to this is to change > small values of the density estimate to NA values, but selecting the right > threshold is a rather manual procedure, and a value that works for one > density map may not work for a map for a different place, or at a different > time. The best solution would be a function that used a kernel with finite > support, so that any areas with a distance greater than the bandwidth from > the nearest observation would be transparent (have NA values). > > Also, any special issues I should be aware of since this is *geographical* > data? Iâm planning to use a UTM projection to avoid the problem with the > length of longitudes varying with the latitude. My data cover a rather > large > area, so this is not a perfect solution, but should be good enough. (But if > there are any functions that can calculate heatmaps taking into account the > shape of the Earth, this would of course great). > > So, any suggestions or experience with this type of plotting problem? > Perhaps Iâm missing something obvious? :) > > -- > Regards, > Karl Ove Hufthammer > > _______________________________________________ > R-sig-Geo mailing list > R-sig-Geo@stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > -- Michael Sumner Institute for Marine and Antarctic Studies, University of Tasmania Hobart, Australia e-mail: mdsum...@gmail.com [[alternative HTML version deleted]]
_______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
