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. _______________________________________________ AniMov mailing list [email protected] http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov
