burst function in liker and kernelbb

[Andrea Maxie]

I am trying to use the burst function to create Brownian bridge home ranges based on time of day (day and night).  I have posted a sample of the R command script and output below to help illustrate my issue.  I have numbered each day (or night – I have separated days and nights into separate files for each animal) with a unique, consecutive value.  

When running the script, I get the error “Error in plot.new() : figure margins too large” after the Liker function, presumably because a plot is created for each Sig1 function.  By setting ‘plotit’ to FALSE in the Liker function I could move past that point, but it continues to be a problem when plotting the kernelbb, which in turn causes problems with outputting (see sample output below sample script).  

I tried using a small number of bursts (3) with success, but still have problems when using many bursts.  When using three bursts, only one plot is created, so I am unsure why increasing the number of bursts should create a figure margin problem.

I would very much appreciate any insight anyone can offer.

Andrea

Andrea Maxie
M.Sc. Candidate
Environmental & Life Sciences Graduate Program
Trent University
Peterborough, Ontario



Sample BBMM script using the burst function:

data<-read.csv("data.csv")
data[1:10,]
x<-data$x
y<-data$y
xy<-cbind(x,y)
datetime<-data$datetime
id<-data$id
brst<-data$burst
da<-as.POSIXct(strptime(as.character(data$datetime), tz="GMT", "%d/%m/%Y %T"))
trj<-as.ltraj(xy, da, id, burst=brst, typeII=T, slsp="remove")
sig2<-data$error
liker(trj, sig2, byburst=T, rangesig1=c(0, 30))

xybox <- data.frame(x=c(min(na.omit(data$x))-2500, max(na.omit(data$x))+2500),
                        y=c(min(na.omit(data$y))-2500, max(na.omit(data$y))+2500))
asc <- ascgen(xybox, cellsize=25)

bb<-kernelbb(trj, sig1=1.8619, sig2, byburst=T,grid=asc)
save(bb, file="test.rdata")
image(bb[[1]]$UD)
contour(getvolumeUD(bb)[[1]]$UD, level=99, add=T, col="red", lwd=2)
udvol<-getvolumeUD(bb)
export.asc(udvol[[1]]$UD, "test3b.asc")
ver99<-getverticeshr(bb, lev=99)
sh99<-kver2shapefile(ver99, which=names(ver99))
write.shapefile(sh99,"test3b_ctr99")
rm(list=ls(all=TRUE))

Sample output:

> bb<-kernelbb(trj, sig1=1.8619, sig2, byburst=T,grid=asc)
> save(bb, file="test3b.rdata")
> image(bb[[1]]$UD)
Error in plot.new() : figure margins too large
> contour(getvolumeUD(bb)[[1]]$UD, level=99, add=T, col="red", lwd=2)
Error: NA/NaN/Inf in foreign function call (arg 1)
>
> udvol<-getvolumeUD(bb)
Error: NA/NaN/Inf in foreign function call (arg 1)
> export.asc(udvol[[1]]$UD, "test3b.asc")
Error in inherits(x, "asc") : object "udvol" not found
>
> ver99<-getverticeshr(bb, lev=99)
Error: NA/NaN/Inf in foreign function call (arg 1)
> sh99<-kver2shapefile(ver99, which=names(ver99))
Error in inherits(kv, "kver") : object "ver99" not found
> write.shapefile(sh99,"test3b_ctr99")
Error in is.vector(object) : object "sh99" not found
 

[Paolo Cavallini]

Andrea Maxie ha scritto:
> I am trying to use the burst function to create Brownian bridge home ranges
> based on time of day (day and night).  I have posted a sample of the R
> command script and output below to help illustrate my issue.  I have
> numbered each day (or night – I have separated days and nights into separate
> files for each animal) with a unique, consecutive value.  

Hi Andrea.
Once you have your script running, I would suggest you to publish it
through the AniMove web site: it wouold be a great addition for many.
Hopefully this could lead to an extension of the HomeRange QGIS plugin
for easy use by non-R-gurus :).
All the best.
pc
--
Paolo Cavallini, see: * http://www.faunalia.it/pc *
_______________________________________________
AniMov mailing list
AniMov@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/animov

[Clément Calenge-2]

Hello Andrea,

Andrea Maxie wrote:

> I am trying to use the burst function to create Brownian bridge home ranges
> based on time of day (day and night).  I have posted a sample of the R
> command script and output below to help illustrate my issue.  I have
> numbered each day (or night – I have separated days and nights into separate
> files for each animal) with a unique, consecutive value.  
>
> When running the script, I get the error “Error in plot.new() : figure
> margins too large” after the Liker function, presumably because a plot is
> created for each Sig1 function.  By setting ‘plotit’ to FALSE in the Liker
> function I could move past that point, but it continues to be a problem when
> plotting the kernelbb, which in turn causes problems with outputting (see
> sample output below sample script).  
>
> I tried using a small number of bursts (3) with success, but still have
> problems when using many bursts.  When using three bursts, only one plot is
> created, so I am unsure why increasing the number of bursts should create a
> figure margin problem.
>  

The following example may give you an illustration of why this problem
occurs (just copy and paste in R):

## For example consider this graph
plot(1:10)

## Now "repeat" this graph 16 times:
par(mfrow=c(4,4))
for (i in 1:16)
plot(1:10)

## As you can see, the margins occupy a larger proportion of the figure
## and the information is less clear
## increase again the number of graphs
par(mfrow=c(5,5))
for (i in 1:25)
plot(1:10)

## You cannot see anything on these graphs!
## Increase it again:
par(mfrow=c(10,10))
for (i in 1:100)
plot(1:10)

### end of code

R indicates:
Error in plot.new() : figure margins too large

With such a large number of figures, R is unable to display correctly
the information. Explaining the error. The only solution is to perform
the analyses for subset of bursts... Now, concerning your script it is
difficult to identify the errors without data allowing to reproduce the
analyses. Looking at your results:

>> bb<-kernelbb(trj, sig1=1.8619, sig2, byburst=T,grid=asc)
>> save(bb, file="test3b.rdata")
>> image(bb[[1]]$UD)
>>    
> Error in plot.new() : figure margins too large
>  

I explained above why this error occurs. However:

>> udvol<-getvolumeUD(bb)
>>    
> Error: NA/NaN/Inf in foreign function call (arg 1)
>  

This error is strange, but it is unlikely that the "margin" error caused
this problem. In my opinion, your data have another problem, difficult
to identify since you did not provide any data allowing to reproduce
your example... Maybe a burst characterized by an immobile animal led to
a UD=0 everywhere? (i.e. all coordinates are identical)? Maybe a burst
built up only by missing data? hard to say... but you should look at
your data closely. Try

plot(trj, perani=FALSE)

Because you have a lot of bursts, you will probably have to do (to avoid
the "margin error"):

plot(trj[1:12], perani=FALSE)
plot(trj[13:24], perani=FALSE)
plot(trj[25:36], perani=FALSE)
etc.

and have a look to each burst to identify the problem.


>> export.asc(udvol[[1]]$UD, "test3b.asc")
>>    
> Error in inherits(x, "asc") : object "udvol" not found
>  

Yes, this is expected: the command getvolumeUD failed, so udvol does not
exist.

>> ver99<-getverticeshr(bb, lev=99)
>>    
> Error: NA/NaN/Inf in foreign function call (arg 1)
>  

Again, difficult to know why it fails (probably for the same reason as
getvolumeUD above).


>> sh99<-kver2shapefile(ver99, which=names(ver99))
>> Error in inherits(kv, "kver") : object "ver99" not found
>>    

This is expected: the command getverticeshr failed, so ver99 does not exist.

>> write.shapefile(sh99,"test3b_ctr99")
>>    
> Error in is.vector(object) : object "sh99" not found
>  

This is expected: the command getverticeshr failed, so ver99 does not exist.
HTH

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

[Andrea Maxie]

Dear Clement,

Thank you for your reply.  I investigated the data I was using and a single value in a burst caused the “NA/NaN/Inf in foreign function call (arg 1)” error.  

I have looked at the structure of the kernelbb output when using the byburst function, and have realized that it was not providing the output I had expected.  ie. kernelbb with byburst=T creates individual UDs for each burst, whereas I am hoping to create a single BB UD using multiple bursts.  For my data, the purpose of using a burst is to eliminate the estimation of a probability distribution between 2 points (at the end and start of consecutive bursts), between which a series of locations was removed (ex. Creating a UD for ‘day’ by removing all ‘night’ locations, and not calculating a Brownian bridge between each day).

Is it possible to compute this through the adehabitat package?  

Another useful possibility could be to set an upper limit on the possible time lapse between fixes (ie. a brownian bridge won't be computed between any two locations that are greater than, say, 6 hours apart).  

 have again included the script I have used as well as a small sample data set (attached, but copied below in case the attachment doesn't work), which includes data for 3 consecutive nights, each labelled as a separate burst.

Sample script:

data<-read.csv("burst_test.csv")
x<-data$x
y<-data$y
xy<-cbind(x,y)
datetime<-data$datetime
id<-data$id
brst<-data$burst
da<-as.POSIXct(strptime(as.character(data$datetime), tz="GMT", "%d/%m/%Y %T"))
trj<-as.ltraj(xy,da,id,burst=brst,typeII=T,slsp="remove")
sig2<-10
liker(trj, sig2, byburst=T, rangesig1=c(0, 30))

xybox <- data.frame(x=c(min(na.omit(data$x))-2500, max(na.omit(data$x))+2500),
                        y=c(min(na.omit(data$y))-2500, max(na.omit(data$y))+2500))
asc <- ascgen(xybox, cellsize=250)

bb<-kernelbb(trj, sig1=1.8619, sig2, byburst=T,grid=asc)
save(bb, file="test.rdata")
images<-image(bb[[1]]$UD)
contour(getvolumeUD(bb)[[1]]$UD, level=99, add=T, col="red", lwd=2)
udvol<-getvolumeUD(bb)
export.asc(udvol[[1]]$UD, "test.asc")
ver99<-getverticeshr(bb, lev=99)
sh99<-kver2shapefile(ver99, which=names(ver99))
write.shapefile(sh99,"test_ctr99")

Sample data:  

sampledata.csv

id datetime x y burst
10_2007_Spring 09/05/2007 21:32:04 700980 5054554 1
10_2007_Spring 09/05/2007 22:00:28 700923 5054584 1
10_2007_Spring 09/05/2007 22:30:54 700923 5054575 1
10_2007_Spring 09/05/2007 23:02:14 700925 5054573 1
10_2007_Spring 10/05/2007 00:02:28 700921 5054585 1
10_2007_Spring 10/05/2007 00:31:15 700922 5054614 1
10_2007_Spring 10/05/2007 01:30:53 700924 5054589 1
10_2007_Spring 10/05/2007 02:01:14 700924 5054576 1
10_2007_Spring 10/05/2007 02:30:36 700921 5054576 1
10_2007_Spring 10/05/2007 03:01:03 700933 5054576 1
10_2007_Spring 10/05/2007 03:32:11 700912 5054566 1
10_2007_Spring 10/05/2007 04:33:00 700922 5054580 1
10_2007_Spring 10/05/2007 05:01:24 700923 5054580 1
10_2007_Spring 10/05/2007 21:30:44 699095 5055290 2
10_2007_Spring 10/05/2007 22:00:23 699114 5055316 2
10_2007_Spring 10/05/2007 22:32:14 699114 5055299 2
10_2007_Spring 11/05/2007 00:03:05 699116 5055317 2
10_2007_Spring 11/05/2007 01:00:54 699126 5055303 2
10_2007_Spring 11/05/2007 01:33:06 699118 5055309 2
10_2007_Spring 11/05/2007 02:03:01 699117 5055347 2
10_2007_Spring 11/05/2007 02:31:51 699102 5055280 2
10_2007_Spring 11/05/2007 04:02:12 699150 5055323 2
10_2007_Spring 11/05/2007 04:31:20 699090 5055342 2
10_2007_Spring 11/05/2007 05:01:45 699125 5055301 2
10_2007_Spring 11/05/2007 21:30:37 701211 5056080 3
10_2007_Spring 11/05/2007 23:01:23 701187 5056040 3
10_2007_Spring 12/05/2007 00:02:37 701166 5056047 3
10_2007_Spring 12/05/2007 00:32:41 701241 5056118 3
10_2007_Spring 12/05/2007 02:01:47 701176 5056061 3
10_2007_Spring 12/05/2007 02:31:50 701176 5056068 3
10_2007_Spring 12/05/2007 03:02:23 701192 5056057 3
10_2007_Spring 12/05/2007 03:31:28 701190 5056072 3
10_2007_Spring 12/05/2007 04:03:05 701209 5056052 3
10_2007_Spring 12/05/2007 05:01:18 701190 5056068 3

[Clément Calenge-2]

Dear Andrea,

> I have looked at the structure of the kernelbb output when using the byburst
> function, and have realized that it was not providing the output I had
> expected.  ie. kernelbb with byburst=T creates individual UDs for each
> burst, whereas I am hoping to create a single BB UD using multiple bursts.
> For my data, the purpose of using a burst is to eliminate the estimation of
> a probability distribution between 2 points (at the end and start of
> consecutive bursts), between which a series of locations was removed (ex.
> Creating a UD for ‘day’ by removing all ‘night’ locations, and not
> calculating a Brownian bridge between each day).
>
> Is it possible to compute this through the adehabitat package?
>
> Another useful possibility could be to set an upper limit on the possible
> time lapse between fixes (ie. a brownian bridge won't be computed between
> any two locations that are greater than, say, 6 hours apart).
>  

There is no possibility presently to indicate the presence of "breaks"
in the trajectory when computing the UD with kernelbb (except if you
want to modify the C code on which this function relies).

However, why do you want to set byburst=TRUE? setting byburst to FALSE
will allow you to compute one UD per animal (per ID in fact). If the
time lag between the end location of one burst and the beginning
location of the next is long enough, this will not affect the estimate,
because the Brownian bridge connecting these two relocations will be
more "diffuse".

To illustrate this point consider the following function. This function
computes a Brownian bridge between two fixed relocations (coordinates
0,0 and 1,1) separated by "diffdate" seconds (to be specified), with
fixed smoothing parameters (sig1=0.4, sig2=0.1):

testdiffdate <- function(diffdate, title)
{
    xx <- c(0,1)
    yy <- c(0,1)
    date <- c(0, diffdate)
    class(date) <- c("POSIXt", "POSIXct")
    tr <- as.ltraj(data.frame(x = xx,y = yy), date, id="a")

    ## Use of two ad hoc smoothing parameters
     sig1 <- c(0.4)
     sig2 <- c(0.1)

     y<-kernelbb(tr, sig1, sig2)[[1]]$UD
     image(y, main=title, axes=FALSE)
     points(xx, yy, pch=16, col="red")
     box()
}


When the time lag "diffdate" gets larger, the brownian bridge between
the two fixed relocations gets less noticeable. In the limit, the
estimator is similar to a classical kernel smoother:

opar <- par(mar = c(0,0,2,0), mfrow = c(5,5))
lapply(1:25, function(i) {
    testdiffdate(i, title=paste(i, "seconds"))
})
par(opar)


Hope this helps,


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

[Andrea Maxie]

Dear Clement,

Clément Calenge-2 wrote:

However, why do you want to set byburst=TRUE? setting byburst to FALSE
will allow you to compute one UD per animal (per ID in fact). If the
time lag between the end location of one burst and the beginning
location of the next is long enough, this will not affect the estimate,
because the Brownian bridge connecting these two relocations will be
more "diffuse".

Thank you for your reply.  Your comments have been very helpful so far!  I understand from your example that at a larger time lag, there is virtually no 'bridge' created between the two points.  However, I do think that these extra bridges will affect the overall results for my data set.  Looking at the example data I posted earlier (attached again for convenience; fix rate of 30 minutes, with "night" clusters separated by about 16 hours), using the following script (simplified from my earlier post):

data<-read.csv("burst_test.csv")
attach(data)
xy<-cbind(x,y)
da<-as.POSIXct(strptime(as.character(data$datetime), tz="GMT", "%d/%m/%Y %T"))
trj<-as.ltraj(xy,da,id,typeII=T,slsp="remove")
sig1<-1.0
sig2<-10
asc <- ascgen(xybox, cellsize=25)
bb<-kernelbb(trj, sig1, sig2, byburst=T,grid=asc)
images<-image(bb[[1]]$UD)

the bridge between each cluster is still apparent, and I believe that this could skew results, particularly when compounded over many days/nights.  I think this is of most concern when looking at the outer contours of the UD with low probabilities of use, where flattened individual bridges created between points with lengthy time lags can cause increased spread and misleadingly extend the outer contours.

What do you think?

Thanks again,

Andrea

[Clément Calenge-2]

Dear Andrea,

> Thank you for your reply.  Your comments have been very helpful so far!  I
> understand from your example that at a larger time lag, there is virtually
> no 'bridge' created between the two points.  However, I do think that these
> extra bridges will affect the overall results for my data set.  Looking at
> the example data I posted earlier (attached again for convenience; fix rate
> of 30 minutes, with "night" clusters separated by about 16 hours), using the
> following script (simplified from my earlier post):
>
> data<-read.csv("burst_test.csv")
> attach(data)
> xy<-cbind(x,y)
> da<-as.POSIXct(strptime(as.character(data$datetime), tz="GMT", "%d/%m/%Y
> %T"))
> trj<-as.ltraj(xy,da,id,typeII=T,slsp="remove")
> sig1<-1.0
> sig2<-10
> asc <- ascgen(xybox, cellsize=25)
> bb<-kernelbb(trj, sig1, sig2, byburst=T,grid=asc)
> images<-image(bb[[1]]$UD)
>
> the bridge between each cluster is still apparent, and I believe that this
> could skew results, particularly when compounded over many days/nights.  I
> think this is of most concern when looking at the outer contours of the UD
> with low probabilities of use, where flattened individual bridges created
> between points with lengthy time lags can cause increased spread and
> misleadingly extend the outer contours.
>
> What do you think?
>  

If you really want to "remove" the movement of the animal between
patches from the estimation of the UD, the only solution, to my
knowledge, is to "do it yourself" (no function for that, sorry). From a
technical point of view, using your sample dataset:

### Load the data
library(adehabitat)
data<-read.csv("sampledata.csv")
x<-data$x
y<-data$y
xy<-cbind(x,y)
datetime<-data$datetime
id<-data$id
brst<-data$burst
da<-as.POSIXct(strptime(as.character(data$datetime), tz="GMT", "%d/%m/%Y
%T"))

## the object "ltraj"
trj<-as.ltraj(xy,da,id,burst=brst,typeII=T,slsp="remove")

## kernelbb estimation with byburst=TRUE
sig2<-10
sig1 <- 1
bb<-kernelbb(trj, sig1, sig2, byburst=T,grid=asc)


## You will have to compute this for each animal (your sample dataset
contains
## only one animal, so I do this only once):
## First, get the UD for each burst.

UDs <- lapply(1:length(bb), function(i) bb[[i]]$UD)


## Note that each UD integrates to 1 over the plane
## We will have to sum these UDs together. However, the sum of these UDs
## will no longer integrate to 1. We have to weight each UD_i estimated
## for animal i before summing, that is finding weights w_i such that:
## UD_tot = sum( w_i * UD_i)
## with sum(w_i) = 1
##
## Actually, we have to correct the UDs by the number of relocations
## used to estimate each UD:

## the number of relocations for each burst:
nlocs <- unlist(lapply(1:length(trj), function(i) nrow(trj[[i]])))

## The weight wi:
wi <- nlocs/sum(nlocs)

## And the UD is:
UDt <- UDs[[1]]
for (i in 2:length(UDs))
    UDt <- UDt+wi[i]*UDs[[i]]

image(UDt)

## Then, if you want to compute the volume:
UDv <- getvolumeUDs(UDt)


You will have to repeat the process for each animal. Is this what you want?
HTH,


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]

Dear Clement,

You previsously wrote:

"
## Note that each UD integrates to 1 over the plane
## We will have to sum these UDs together. However, the sum of these UDs
## will no longer integrate to 1. We have to weight each UD_i estimated
## for animal i before summing, that is finding weights w_i such that:
## UD_tot = sum( w_i * UD_i)
## with sum(w_i) = 1
"

Your dialogs and replies to Andrea have been very useful and informative for me.  I'm hoping you could clarify, or comment, on a point that confuses me, however.

You advised Andrea that to calculate a pooled UD for an animal, from a set of multiple UDs that were generated from a set of bursts, that the pooled UD should be weighted by the burst sample sizes, so the pooled UD would sum to 1 when integrated over the plane:

In Adrea's case, it seemed the goal was to generate a single UD (for one animal) from a set of UD samples derived from multiple bursts.

My intent is to generate a single UD (for one population) from a set of UDs derived from multiple animals (individuals).

It would seem by analogy that I should also weight each UD_i (animal) by its sample size to generate a single "population" UD (?).

However, in Horne et al. (Ecology, 2007), they present an analysis of 11 caribou.  They stated: "We estimated each individual’s probability of occurrence along the migration route using the BBMM. As an estimate of the population-level migration route, we calculated a mean probability of occurrence across the 11 individuals that were monitored."

It would seem that Horne et al. simply averaged the 11 individual caribou UDs (?) to estimate a population-level UD, without making any adjustment to address different sample sizes (n locations) among the 11 caribou.

I'm probably missing something.  Is it appropriate to simply average a set of individual BBMM UDs to estimate a population UD, or should different sample sizes among animals be addressed as you described to Andrea?

kind regards,

David Douglas
Wildlife Biologist, USGS Alaska
[e-mail]

[Clément Calenge]

Dear David,



 > You advised Andrea that to calculate a pooled UD for an animal, from a set
 > of multiple UDs that were generated from a set of bursts, that the pooled UD
 > should be weighted by the burst sample sizes, so the pooled UD would sum to
 > 1 when integrated over the plane:
 >
 > In Adrea's case, it seemed the goal was to generate a single UD (for one
 > animal) from a set of UD samples derived from multiple bursts.


This is the key point, see below.


 > My intent is to generate a single UD (for one population) from a set of UDs
 > derived from multiple animals (individuals).
 >
 > It would seem by analogy that I should also weight each UD_i (animal) by its
 > sample size to generate a single "population" UD (?).


Actually, your situation is different. The aim of Andrea was to
generate a single UD from a set of UD samples derived from multiple
bursts *of the same animal*, whereas you want to estimate a single UD
from a set of UD derived from the monitoring of *several animals*.

The UD of an animal gives an index of the proportion of its time
spent in the various areas of its home range. If the sampling rate is
constant (generally the case in GPS studies), and if a burst A
contains 30 relocations while a burst B contains 60 relocations, this
means that  the duration of burst B was twice as long as the duration
of burst A. If a UD is calculated for both burst A and burst B,
combining them into a single UD should take into account the fact that
the duration of the second burst was longer than the duration of the
first (so that the resulting UD reflects the time spent by the animal
on the various areas of its home range).

In your case, you have estimated the UD of several animals, and
the desired resulting UD is supposed to reflect the *spatial
distribution* of the animals on the area, i.e. the variation in
animals density over the area. In your case, it does not make sense to
give different weights to the animals (this would lead to larger
estimated densities in areas where the animals have been monitored for
a longer time). Indeed, in your case, a simple average seems a better
choice.
HTH,


Clément Calenge
--
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 wrote:

In your case, you have estimated the UD of several animals, and
the desired resulting UD is supposed to reflect the *spatial
distribution* of the animals on the area, i.e. the variation in
animals density over the area. In your case, it does not make sense to
give different weights to the animals (this would lead to larger
estimated densities in areas where the animals have been monitored for
a longer time). Indeed, in your case, a simple average seems a better
choice.

Dear Clement Calenge,

Thank you for your clear and prompt reply.  Your inisghts give me reason to pause and think clearly about the intended purpose of pooling UDs among different animals.  In the case of estimating a population's home range, averaging UDs among different animals makes sense, as you described.  For other purposes, however, weighting by sample size might(?) make sense.  Specifically, I'm thinking about a scenario that would use the Brownian bridge method to characterize migration corridors of birds.  Some birds might make the migration over relatively short periods, while other birds might take much longer.  If research questions were being asked regarding the transfer or inoculation of disease along the migration route, then the differences among individuals in the amount of time they are in migration status might be reflected in the UD if their different sample sizes were weighted (i.e., the duration of their migration -- assuming equitable temporal sampling among all individuals).

Lots to think about.  Thanks again.  David

[Andrea Maxie]

Dear Clement,

Sorry for the long delay in my reply - I was out doing field work and did not have time to investigate the code you provided.  But, yes, that is exactly what I was hoping for.  It seems to work great for my data, however I do have a small problem when trying to get the UD volume.

You wrote:

Clément Calenge-2 wrote:

## Then, if you want to compute the volume:
UDv <- getvolumeUDs(UDt)

Using the data I provided previously and the code you provided, I get the following output when running

####
UDv <- getvolumeUD(UDt)   ##is think the 's' in getvolumeUDs(UDt) above was a typo?


Error in getvolumeUD(UDt) :
  x should be an object of class "khrud" or "kbbhrud"
#####

I'm not sure how do deal with this. Do you know why this error is caused and how to correct for it?

Thanks again for all of your help!

Andrea

[Andrea Maxie]

Dear Clement,

The error I described actually occurs when using the corrected function (getvolumeUD) to get the volume of the weighted averaged UD (UDt).

Andrea Maxie wrote:

Using the data I provided previously and the code you provided, I get the following output when running

####
UDv <- getvolumeUD(UDt)

Error in getvolumeUD(UDt) :
  x should be an object of class "khrud" or "kbbhrud"
#####

Best regards,

Andrea

[Andrea Maxie]

Dear Clement,

Unfortunately I get this error  "Error: could not find function "getvolumeUDs"" using that function.  I had tried this before, and so thought the 's' was just a typo...  Is there something else I need to install to get that function to work?

Thanks again,

Andrea

Andrea Maxie wrote:

Dear Clement,

The error I described actually occurs when using the corrected function (getvolumeUD) to get the volume of the weighted averaged UD (UDt).

Andrea Maxie wrote:

Using the data I provided previously and the code you provided, I get the following output when running

####
UDv <- getvolumeUD(UDt)

Error in getvolumeUD(UDt) :
  x should be an object of class "khrud" or "kbbhrud"
#####

Best regards,

Andrea