overlap

[Paolo Cavallini]

Hi all.
In the process of building up the randomHR QGIS plugin[1], we stumbled
across a more general question: which is the most appropriate metric for
measuring overlap among HRs?
Should it be:

1) area of overlapping / area occupied by at least one HR
2) area of overlapping / sum of areas of all HRs
3) N x area of overlapping / sum of areas of all HRs
      (where N = number of overlapped HRs in given place)
4) something else

In the attached file, let's assume each square is 1ha big, so each range
is 2ha
big.

example A:
method 1)  1 / 3 = 33%
method 2)  1 / 4 = 25%
method 3)  2 / 4 = 50%

example B:
method 1)  1 / 4 = 25%
method 2)  1 / 6 = 17%
method 3)  3 / 6 = 50%

Opinions and suggestions welcome.
All the best.
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *

[1] https://www.faunalia.it/dokuwiki/doku.php/public/animove_qgis_plugins


_______________________________________________
AniMov mailing list
AniMov@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/animov

[Damiano G. Preatoni]

In un messaggio del Tuesday 10 February 2009, Paolo Cavallini ha scritto:

> Hi all.
> In the process of building up the randomHR QGIS plugin[1], we stumbled
> across a more general question: which is the most appropriate metric for
> measuring overlap among HRs?
> Should it be:
>
> 1) area of overlapping / area occupied by at least one HR
> 2) area of overlapping / sum of areas of all HRs
> 3) N x area of overlapping / sum of areas of all HRs
>       (where N = number of overlapped HRs in given place)
> 4) something else

We usually evaluate overlap on a "per animal/per HR" basis, i.e. we start with
a set of homeranges, either belonging to each individual, or to each valid
cartesian product of animal x 'season'.

next we evaluate overlap as follows:
- pick homerange of animal i (HRi)
- for each homerange j <> i calculate 'HRi/HRj'

'HRi/HRj' is just an oversimplification, see [1] for the gory details.

The result is a non-symmetric distance matrix, which eventually can be
aggregated to have, say, average overlaps between sexes, seasons, etc..

In practice, all that is done with a slightly modified version of Clément's
kerneloverlap. the modification consists in commenting put the first rows
that call kernelUD, and making function kerneloverlap work on already
calculated UDs.

This raises another point, i.e. a suggestion to Clément: since often the 40x40
cells approach gives undesirable results, we prefer to prepare as a
preliminary step, a raster (of course using exclusively ESRI software, duh!)
with cells of suitable size, that encompassess an extent slightly wider than
the study area, an then calculate once all the UDs.
This 'single point of homerange truth' [2] guarantees a consistency between
subsequant calculations, i.e. 'getvoumes + polygon extraction', compana,
kerneloverlapd etc.

This also saves lots of time, since UD calculation, moreover with a 'fine'
grid, takes some time: UD processing can be done on a fast number crunching
machine [3], and the result can be saved (as part of a sahrlocs structure)
and retrieved on a less performant host to do other postprocessing.


Well... my 2 eurocents, of course!



[1] Fieberg, J. and Kochanny, C.O. (2005) Quantifying home-range overlap: the
importance of the utilization distribution. Journal of Wildlife Management,
69, 1346–1359.

[2] Credits to Anne Ghisla for the name :)

[3] About 8 min for 119 snowshoe hare homeranges ('Hadj' method, 3 calls to
kernelUD for each animal) on a Core Duo  T8100, 2GHz, 3GB RAM.

--
La realta' e' brutta quanto basta, perche' dovrei dire la verita'?
                -- Patrick Sky
-----------------------------------------------------------
Damiano G. Preatoni, PhD

Unità di Analisi e Gestione delle Risorse Ambientali
Dipartimento Ambiente-Salute-Sicurezza
Università degli Studi dell'Insubria
Via J.H. Dunant, 3 - 21100 Varese (ITALY)

tel [phone] fax [phone]
http://biocenosi.dipbsf.uninsubria.it/
ICQ: 78690321 jabber: prea@... skype: prea.net
-----------------------------------------------------------
Please consider the environment before printing this email
Please do not send attachments in proprietary formats
http://www.gnu.org/philosophy/no-word-attachments.html
Use the UNI CEI Standard ISO/IEC 26300:2006
-----------------------------------------------------------
O< stop html mail - http://www.asciiribbon.org


_______________________________________________
AniMov mailing list
AniMov@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/animov

[Damiano G. Preatoni]

...of course any reference to ESRI software in my previous post was a joke!
The trick is in fact performed with g.region/v.in.region and similar obscure
magic spells :)

--
Invitato a leggere il Nuovo Testamento, Mike Buongiorno ha chiesto:
"Perche', sono compreso tra gli eredi?".
                -- Amurri & Verde
-----------------------------------------------------------
Damiano G. Preatoni, PhD

Unità di Analisi e Gestione delle Risorse Ambientali
Dipartimento Ambiente-Salute-Sicurezza
Università degli Studi dell'Insubria
Via J.H. Dunant, 3 - 21100 Varese (ITALY)

tel [phone] fax [phone]
http://biocenosi.dipbsf.uninsubria.it/
ICQ: 78690321 jabber: prea@... skype: prea.net
-----------------------------------------------------------
Please consider the environment before printing this email
Please do not send attachments in proprietary formats
http://www.gnu.org/philosophy/no-word-attachments.html
Use the UNI CEI Standard ISO/IEC 26300:2006
-----------------------------------------------------------
O< stop html mail - http://www.asciiribbon.org


_______________________________________________
AniMov mailing list
AniMov@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/animov

[Clément Calenge-2]

Hi all,

> The result is a non-symmetric distance matrix, which eventually can be
> aggregated to have, say, average overlaps between sexes, seasons, etc..
>
> In practice, all that is done with a slightly modified version of Clément's
> kerneloverlap. the modification consists in commenting put the first rows
> that call kernelUD, and making function kerneloverlap work on already
> calculated UDs.
>
> This raises another point, i.e. a suggestion to Clément: since often the 40x40
> cells approach gives undesirable results, we prefer to prepare as a
> preliminary step, a raster (of course using exclusively ESRI software, duh!)
> with cells of suitable size, that encompassess an extent slightly wider than
> the study area, an then calculate once all the UDs.
>  

Note that controlling the grid can be done with kerneloverlap: this
functions accepts all the arguments of kernelUD. For example, using the
puechabon dataset:

data(puechabon)

## With 200x200 grid
kerneloverlap(puechabon$locs[,c("X","Y")], puechabon$locs$Name,
                        grid=200, meth="VI", conditional=TRUE)

## With a map available in R
map <- getkasc(puechabon$kasc,1)
kerneloverlap(puechabon$locs[,c("X","Y")], puechabon$locs$Name,
                        grid=map, meth="VI", conditional=TRUE)


> This 'single point of homerange truth' [2] guarantees a consistency between
> subsequant calculations, i.e. 'getvoumes + polygon extraction', compana,
> kerneloverlapd etc.
>
> This also saves lots of time, since UD calculation, moreover with a 'fine'
> grid, takes some time: UD processing can be done on a fast number crunching
> machine [3], and the result can be saved (as part of a sahrlocs structure)
> and retrieved on a less performant host to do other postprocessing.
>  

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

--
Clément CALENGE
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. [phone]

_______________________________________________
AniMov mailing list
AniMov@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/animov

[David Douglas]

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
 

[Mathias Tobler]

Dear David,

I run into the same problem when trying to calculate HR overlap with UDs from the brownian bridge. I ended up modifying the existing kerneloverlap function. The parameters are the same as for kerneloverlaphr only that x is an UD object. It would be nice to  add this more generic function to adehabitat. I also had to write my own getarea function to make it work with UDs from brownian bridges.

##Generic HROverlap function

hroverlap<-function (x, method = c("HR", "PHR", "VI", "BA",
    "UDOI", "HD"), lev = 95, conditional = FALSE, ...)
{
    method <- match.arg(method)
    vol <- getvolumeUD(x)
    res <- matrix(0, ncol = length(x), nrow = length(x))
    for (i in 1:length(x)) {
        for (j in 1:i) {
            if (method == "HR") {
                vi <- vol[[i]]$UD
                vj <- vol[[j]]$UD
                vi[vi <= lev] <- 1
                vi[vi > lev] <- 0
                vj[vj <= lev] <- 1
                vj[vj > lev] <- 0
                vk <- vi * vj
                res[i, j] <- sum(vk)/sum(vi)
                res[j, i] <- sum(vk)/sum(vj)
            }
            if (method == "PHR") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[j, i] <- sum(vi * aj) * (attr(vi, "cellsize")^2)
                  res[i, j] <- sum(vj * ai) * (attr(vi, "cellsize")^2)
                }
                else {
                  res[j, i] <- sum(vi * aj) * (attr(vi, "cellsize")^2)
                  res[i, j] <- sum(vj * ai) * (attr(vi, "cellsize")^2)
                }
            }
            if (method == "VI") {
                vi <- c(x[[i]]$UD)
                vj <- c(x[[j]]$UD)
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[i, j] <- res[j, i] <- sum(pmin(vi, vj)) *
                    (attr(x[[i]]$UD, "cellsize")^2)
                }
                else {
                  res[i, j] <- res[j, i] <- sum(pmin(vi, vj)) *
                    (attr(x[[i]]$UD, "cellsize")^2)
                }
            }
            if (method == "BA") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[j, i] <- res[i, j] <- sum(sqrt(vi) * sqrt(vj)) *
                    (attr(vi, "cellsize")^2)
                }
                else {
                  res[j, i] <- res[i, j] <- sum(sqrt(vi) * sqrt(vj)) *
                    (attr(vi, "cellsize")^2)
                }
            }
            if (method == "UDOI") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  ak <- sum(ai * aj) * (attr(vi, "cellsize")^2)
                  res[j, i] <- res[i, j] <- ak * sum(vi * vj) *
                    (attr(vi, "cellsize")^2)
                }
                else {
                  ak <- sum(ai * aj) * (attr(vi, "cellsize")^2)
                  res[j, i] <- res[i, j] <- ak * sum(vi * vj) *
                    (attr(vi, "cellsize")^2)
                }
            }
            if (method == "HD") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[j, i] <- res[i, j] <- sqrt(sum((sqrt(vi) -
                    sqrt(vj))^2 * (attr(vi, "cellsize")^2)))
                }
                else {
                  res[j, i] <- res[i, j] <- sqrt(sum((sqrt(vi) -
                    sqrt(vj))^2 * (attr(vi, "cellsize")^2)))
                }
            }
        }
    }
    rownames(res) <- names(x)
    colnames(res) <- names(x)
    return(res)
}


At 19:23 24.04.2009, David Douglas wrote:

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 AniMov@... http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

[Mathias Tobler]

Dear David,

I run into the same problem when trying to calculate HR overlap with UDs from the brownian bridge. I ended up modifying the existing kerneloverlap function. The parameters are the same as for kerneloverlaphr only that x is an UD object. It would be nice to  add this more generic function to adehabitat. I also had to write my own getarea function to make it work with UDs from brownian bridges.

##Generic HROverlap function

hroverlap<-function (x, method = c("HR", "PHR", "VI", "BA",
    "UDOI", "HD"), lev = 95, conditional = FALSE, ...)
{
    method <- match.arg(method)
    vol <- getvolumeUD(x)
    res <- matrix(0, ncol = length(x), nrow = length(x))
    for (i in 1:length(x)) {
        for (j in 1:i) {
            if (method == "HR") {
                vi <- vol[[i]]$UD
                vj <- vol[[j]]$UD
                vi[vi <= lev] <- 1
                vi[vi > lev] <- 0
                vj[vj <= lev] <- 1
                vj[vj > lev] <- 0
                vk <- vi * vj
                res[i, j] <- sum(vk)/sum(vi)
                res[j, i] <- sum(vk)/sum(vj)
            }
            if (method == "PHR") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[j, i] <- sum(vi * aj) * (attr(vi, "cellsize")^2)
                  res[i, j] <- sum(vj * ai) * (attr(vi, "cellsize")^2)
                }
                else {
                  res[j, i] <- sum(vi * aj) * (attr(vi, "cellsize")^2)
                  res[i, j] <- sum(vj * ai) * (attr(vi, "cellsize")^2)
                }
            }
            if (method == "VI") {
                vi <- c(x[[i]]$UD)
                vj <- c(x[[j]]$UD)
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[i, j] <- res[j, i] <- sum(pmin(vi, vj)) *
                    (attr(x[[i]]$UD, "cellsize")^2)
                }
                else {
                  res[i, j] <- res[j, i] <- sum(pmin(vi, vj)) *
                    (attr(x[[i]]$UD, "cellsize")^2)
                }
            }
            if (method == "BA") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[j, i] <- res[i, j] <- sum(sqrt(vi) * sqrt(vj)) *
                    (attr(vi, "cellsize")^2)
                }
                else {
                  res[j, i] <- res[i, j] <- sum(sqrt(vi) * sqrt(vj)) *
                    (attr(vi, "cellsize")^2)
                }
            }
            if (method == "UDOI") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  ak <- sum(ai * aj) * (attr(vi, "cellsize")^2)
                  res[j, i] <- res[i, j] <- ak * sum(vi * vj) *
                    (attr(vi, "cellsize")^2)
                }
                else {
                  ak <- sum(ai * aj) * (attr(vi, "cellsize")^2)
                  res[j, i] <- res[i, j] <- ak * sum(vi * vj) *
                    (attr(vi, "cellsize")^2)
                }
            }
            if (method == "HD") {
                vi <- x[[i]]$UD
                vj <- x[[j]]$UD
                ai <- vol[[i]]$UD
                aj <- vol[[j]]$UD
                ai[ai <= lev] <- 1
                ai[ai > lev] <- 0
                aj[aj <= lev] <- 1
                aj[aj > lev] <- 0
                if (conditional) {
                  vi <- vi * ai
                  vj <- vj * aj
                  res[j, i] <- res[i, j] <- sqrt(sum((sqrt(vi) -
                    sqrt(vj))^2 * (attr(vi, "cellsize")^2)))
                }
                else {
                  res[j, i] <- res[i, j] <- sqrt(sum((sqrt(vi) -
                    sqrt(vj))^2 * (attr(vi, "cellsize")^2)))
                }
            }
        }
    }
    rownames(res) <- names(x)
    colnames(res) <- names(x)
    return(res)
}


At 19:23 24.04.2009, David Douglas wrote:

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 AniMov@... http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

[Clément Calenge-2]

Dear David,

As noted by Matthias, when the aim is to use the function
kerneloverlaphr, you can still use this function on objects of class
"kbbhrud". You just have to remove the following two lines at the
beginning of the function kerneloverlaphr:

if (!inherits(x, "khrud"))
        stop("x should be of class khrud")


The next version of adehabitat (submitted in a couple of days) will
allow the use of this function on objects of class "kbbhrud".
Many thanks for the suggestion,
Regards,

Clément.


David Douglas writes:
 >
 >
 > 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
 > AniMov@...
 > http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov
--
Clément CALENGE
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. [phone]
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov