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

[Calenge Clement]

> I have some questions regarding the kerneloverlap function within the
> adehabitatHR package, and must offer my apologies if they seem rather base:
>
> -I understand that the comparisons between the HR method for kerneloverlap
> and MCP overlap are often misleading. Why doesn't this method make for a
> good comparison to MCP area intersection?

I am not sure to understand what you mean here, but the function 
kerneloverlap implements exactly the approach described in Fieberg and 
Kochanny (2005, see the help page of the function for complete 
reference). Maybe this reference would help you to understand the 
differences with other approaches?


> -kerneloverlap function computes indices from sets of relocations, whereas
> kerneloverlaphr computes indices from estUDs. Why or in what scenarios might
> one be preferred over the other?

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.


> -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

-- 
Clément CALENGE
Cellule d'appui à l'analyse de données
Direction des Etudes et de la Recherche
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. (33) 01.30.46.54.14