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,
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], sig2 = 1000,
sig1b <- liker(trj2, sig2 = 1000, rangesig1 = c(10, 1000))
bbridge2 <- kernelbb(trj1, as.data.frame(sig1b)[1,1], sig2 = 1000,
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
Or, are there reasons why Brownian Bridge UDs should not be candidates for
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