[R-sig-Geo] adehabitatHR: kerneloverlap and kernelUD etc.

[Mathieu Basille]

Le 07/04/2014 15:00, Calenge Clement a écrit :
>
> [...]
>
> Generally, the function kerneloverlap is to be preferred (simpler to use
> if you start from a set of relocations, see below), except if you
> already have an object of class estUD in suitable format (i.e. with the
> kernel estimation carried out on the *same grid* for all animals). The
> function kerneloverlaphr might be preferred if you work with
> "nonclassical" kernel approaches, such as BRB, kernelbb, etc., if you
> have built your own estUD object from UDs estimated with another
> software, etc.

Alternatively, I recently modified the 'kerneloverlap' function to accept 
either a `SpatialPointsDataFrame` or a `estUDm` object in a single function 
(no more need of 'kerneloverlaphr'). Essentially, the function reuses the 
code of the regular 'kerneloverlap' function when working on a SPDF, and 
the code of the regular 'kerneloverlaphr' function when working on a estUDm 
object.

It also allows to use several functions at once, e.g. 'c("PHR", "BA")', 
with a new summary function which can be pretty convenient. The modified 
function is available here:

http://ase-research.org/basille/hab/

Mathieu.


>> -I notice in working with the kerneloverlap function that the selected grid
>> size influences home range overlap. What is the best way to go about
>> selecting a biologically meaningful grid size?
>
> Normally, the effect of the grid size on the kernel estimates should be
> negligible. If it is not, it may be because the grid is way too coarse.
> Increase the resolution until no further noticeable change occurs.
>
>
>> -When trying to work with the kerneloverlaphr, I am given the warning "In vi
>> * vj : longer object length is not a multiple of shorter object length". I'm
>> afraid I can't say I really understand this statement (as each animal has
>> the same number of relocations) nor what the function is doing with the data
>> to account for it.
>
> Hard to say without any reproducible example... Just a guess: you try to
> use kerneloverlaphr with an estUD which is not in the correct format
> (i.e. the size and the resolution of the grid is not the same for all
> animals). The function kerneloverlap might be easier to use? If you
> really really want to use kerneloverlap on an estUD object generated by
> kernelUD, please use same4all=TRUE in the function estUD.
>
>
>> -I also realize that an issue with the kernelUD LSCV estimate is that the
>> cross-validation criterion sometimes fails to be minimized. But /why / is
>> this sometimes the case? i.e. what about the relocations might cause this?
>> And when LSCV method does fail to converge, I understand that the method can
>> no longer be reliably used. In such cases, is it best to default to another
>> hr estimate like MCP, or another method for selecting h (href or selective
>> h?)?
>
> Have a look at the following urls:
>
> http://lists.faunalia.it/pipermail/animov/2006-May/000137.html
> http://lists.faunalia.it/pipermail/animov/2006-May/000130.html
> http://lists.faunalia.it/pipermail/animov/2006-May/000165.html
>
> Best regards
> HTH,
>
> Clément Calenge
>

-- 

~$ whoami
Mathieu Basille, PhD

~$ locate --details
University of Florida \\
Fort Lauderdale Research and Education Center
(+1) 954-577-6314
http://ase-research.org/basille

~$ fortune
« Le tout est de tout dire, et je manque de mots
Et je manque de temps, et je manque d'audace. »
  -- Paul Éluard