[AniMov] overlap

David Douglas ddouglas at usgs.gov
Sat Apr 25 02:23:49 CEST 2009



Clément Calenge-2 wrote:
> 
> Hi all,
> 
> Yes, you are right: kernel UDs are often computed as a basis for further 
> analysis, including kernel overlap, but not only... It would be more 
> sensible to estimate UD once, and then using them for other analyses. I 
> planned to upload a new version of adehabitat to CRAN before the end of 
> the week, and I will include, on the help page of kerneloverlap, a new 
> function accepting a "khrud" object to perform this computation."
> Many thanks for the suggestion,
> Regards,
> 
> Clément
> 
> 

Greetings,

I was taking the course described above to create a set of khrud objects for
input to kerneloverlaphr.
However, I was using kernelbb (rather than kernelud) to create the ud
objects, on a fixed-grid.

sig1a <- liker(trj1, sig2 = 1000, rangesig1 = c(10, 1000))
bbridge1 <- kernelbb(trj1, as.data.frame(sig1a[1])[1,1], sig2 = 1000,
grid=ascall )

sig1b <- liker(trj2, sig2 = 1000, rangesig1 = c(10, 1000))
bbridge2 <- kernelbb(trj1, as.data.frame(sig1b[1])[1,1], sig2 = 1000,
grid=ascall )

While I remain unsure of how to integrate 2 or more individual UD objects
(say, bbridge1 and bbridge2) into an object that is compatible with
kerneloverlaphr, it would seem that I'm up against a bigger problem:

kerneloverlaphr requires an object type = khr, subclass=khrud,
but kernelbb produces UD objects that have type=khr, subclass=kbbhrud.
It appears kerneloverlaphr will not accept a kbbhrud object.

Is there any way to change a kbbhrud object so it can be compatible with
kerneloverlaphr?
Or, are there reasons why Brownian Bridge UDs should not be candidates for
kerneloverlaphr?

David Douglas
 






-- 
View this message in context: http://www.nabble.com/overlap-tp21929181p23226781.html
Sent from the AniMov mailing list archive at Nabble.com.



More information about the AniMov mailing list