In un messaggio del Monday 02 August 2010, Corrie Curtice ha scritto: > On Mon, Aug 2, 2010 at 12:40 PM, Corrie Curtice <[email protected]> wrote: > > 2010/7/28 Damiano G. Preatoni <[email protected]>: > >> In un messaggio del Wednesday 28 July 2010, Corrie Curtice ha scritto: > >>> On Wed, Jul 28, 2010 at 2:35 AM, Anne Ghisla <[email protected]> wrote: > >>> > On Tue, 2010-07-27 at 15:27 -0400, Corrie Curtice wrote: > >>> >> Hello, > >>> >> > >>> >> I am trying to export the home range for a single individual animal. > >>> >> I'm getting the error "Error in re[[i]] : subscript out of bounds" > >>> >> -- I looked on the archive and found my own posting of this > >>> >> question for the 100% isopleth. :) So now I'm wondering, why does > >>> >> the error occur at lower isopleth levels? Ideally I would like the > >>> >> 95% KHRE to show the "home range" of each animal, and this works > >>> >> with all other individuals. The answer to my last posting noted > >>> >> that the isopleth went beyond the grid limits. I'm not passing in > >>> >> an underlying grid. Here's my call: > >>> >> > >>> >> ud <- kernelUD(xy, grid=100, h="href") > >>> >> kvtmp <- getverticeshr(ud, lev = 95) > >>> >> > >>> >> Levels up to 85 work fine. Is there anything I can do to fix this, > >>> >> if not what is the proper way to report the result for this animal? > >>> >> If you need more code or output I can send. > >>> > > >>> > Hi Corrie, > >>> > > >>> > it sounds like the issue reported here: > >>> > > >>> > https://trac.faunalia.it/animove/ticket/13 > >>> > > >>> > does your dataset show anisotropy? The one attached to the ticket is > >>> > a narrow cloud of points along a horizontal line. The default grid > >>> > created by kernelUD is likely not able to encompass the whole UD. If > >>> > the case, I would try creating a wider grid and providing it to > >>> > kernelUD. > >>> > > >>> > hope this helps! > >>> > >>> Yes, that's exactly it. I tried increasing the value passed into the > >>> grid parameter -- is this right? Is there some way to determine what > >>> the correct value would be? > >> > >> There is no "correct" value for the grid parameter. > >> It it a known "feature" of adehabitat. > >> > >> That is, passing "grid=<some integer value>" means that kernel > >> calculations (see e.g. Worton classical text) start with superimposing > >> your point locations a mesh with <integer value> x <integer value> > >> _cells_. Worton's default is 40x40. > >> > >> Problem is that is more meaningful having the possibility to supply the > >> _cell size_ insteda of the _number of cells_. > >> > >> This means that if your points cloud covers a _wide_ extent, say, half a > >> state, you will have in your case a 100x100 cells mesh, and a single > >> cell side will be some tenths of kilometers! > >> > >> To overcome this problem, one should use "grid=<a kasc object>" (look > >> into kernelUD source...). > >> > >> I normally do like this: > >> - using my favorite GIS package, I create a raster with the cell size I > >> want, making it so that covers my study area. This way I'll have for > >> instance a raster with 100 m cells, with a size of such and such rows > >> and columns (I say 'such and such' since we're not interested in how > >> many squares we have, but in how long is a square side!). > >> - I export that raster in ASCII GRID format. > >> - back into R I use read.asc function and create a kasc object that then > >> I will use as my "reference grid" in home range calculations, like > >> this: > >> > >> my.reference.grid <- read.asc('refgrid.asc') > >> ud <- kernelUD(xy, grid=my.reference.grid, h="href") > > > > Thanks Damiano, this is helpful information. I have a follow up question. > > > > It sounds like from what you say, that the smaller cell size is > > better. ie: 100m vs 1000m or greater. I've read quite a bit of > > background lit, but until I try this on my own I don't fully > > understand all the implications. I am not able to find much that > > discusses the impact of cell size during kernel calculation. More > > focus is on the smoothing parameter. > > > > I created a grid of 100m cells, and re-ran the kernelUD for one set of > > animals in my study (at one island). The UDs in this home range are a > > bit smaller and more detailed than the ones created with 100x100 grid, > > pretty close but I do like it a little better. > > > > So, is there a process to decide on the best cell size, related to the > > data? Would I be safe to pick 100m for each of my sites and > > individuals? These are marine mammals that range over wide areas, > > some as far as almost 300km, but mostly w/in 100km. > > I retract that comment: the UDs created are exactly the same -- I was > looking at a wrong image when comparing the first time, apologies. > Thanks for the guidance.
Whew... I was frightening... Actually, UD's should be relatively grid-size independent, given that the cell size has a meaningful dimension. There is no silver bullet to choose the "right" cell size. The grid issue originates from the fact that it is impossible to interpolate point locations as they are: in fact, kernel home ranges are just a geospatial interpolation technique (using gaussian kernels) but each point location has exactly 1 as a value, so any interpolator would yield a nice horizontal plane. The trick is then to interpolate _point location density_. To have a density one superimeposes a gris, than counts points falling inside each cell, and last, each grid centroid is used as a point location to calculate the kernel: now their "z-values" are the number of points. This explains the strange behaviour when the 40x40 standard grid results in having cells far too wide. The getverticeshr behaviour is a consequence of that. As a rule of thumb, I use almost always 100 m wide cells, except for animals with very fine-grained movement petterns or in very fragmented habitats. IIRC, I used 500 m for elephants, ibex and chamois, 100 m for snowshoe hare and squirrels, 50 m for bats and small passerines. I can pass along a script I routinely use to make batch home range calculations, starting from a point shapefile and ending with polygons. In fact it's the evolution of the R "engine" behind the Quantum Gis Home Range Plugin by Anne. HTH -- Our comedies are not to be laughed at. -Samuel Goldwyn ----------------------------------------------------------- Damiano G. Preatoni, PhD Unità di Analisi e Gestione delle Risorse Ambientali Dipartimento Ambiente-Salute-Sicurezza Università degli Studi dell'Insubria Via J.H. Dunant, 3 - 21100 Varese (ITALY) tel +39 0332421538 fax +39 0332421446 http://biocenosi.dipbsf.uninsubria.it/ ICQ: 78690321 jabber: [email protected] skype: prea.net ----------------------------------------------------------- Please consider the environment before printing this email Please do not send attachments in proprietary formats http://www.gnu.org/philosophy/no-word-attachments.html Use the UNI CEI Standard ISO/IEC 26300:2006 ----------------------------------------------------------- O< stop html mail - http://www.asciiribbon.org
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ AniMov mailing list [email protected] http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov
