[AniMov] Re: kNNCH code questions?

Clément Calenge calenge at biomserv.univ-lyon1.fr
Tue Jan 25 15:53:04 CET 2005

Hi Sander,

> From the first time I have looked at Adehabitat, I have been puzzled by
>your approach of having multiple animals in a single data set. I really
>can not see the advantage of this approach, apart from providing quick
>access to an overview of all data within a project. With methods
>becoming increasingly complex, such as the LoCoH analysis, output data
>will have an increasing number of dimensions. I think people will get
>completely lost if an initial animal dimension is put on top of all
>this. I could possibly see a function for the burst 'dimension',
>although I will not use it personally.
>The animal dimension also has disadvantages, as illustrated by my
>problems printing graphs. It would be much clearer to me if a plot
>command would provide a single graph for a single animal, leaving all 
>options open to the me to create plot matrices for different purposes.
>I realize that the animal dimension approach is embedded in many
>Adehabitat functions, but, in my humble opinion, I think the package
>would be stronger and easier to use if the animal dimension was removed.
>Please let me know what you think about this!?

I thank you for this remark. Indeed, it raises a central
question concerning the "niche" of adehabitat. This package
was primarily intended to provide tools to biologists to
analyse radio-tracking data.

Several authors have underlined that in the analysis of
radio-tracking data, the sampling unit is the animal and not
the relocation (Aebischer et al. 1993 - Ecology, Otis & White
1999 - JWM). Thus, to draw conclusion at the scale of the
population, several animals should be available.
Thus, other functions of adehabitat relies on the fact
that the animal is the sampling unit in most analyses in
ecology (here, it is not only a choice, it is a requirement
of the methods). See for example the functions compana,
as.sahrlocs, wiI, kselect, etc.

In addition, this package has been useful in other fields.
I used the functions of this package the geographical
zonation of tree species in South America (Spichiger et al.
2004 - journal of Biogeography). In this case, each species
is characterised by a point pattern of ocurrences, and this
dimension was again necessary.

However, I think you're right on one point. Though the
animal dimension should not disappear from adehabitat,
it should not be used when it is not of interest. Because
of the apparition of new technologies such as GPS, the
kind of data available to the biologist changes, and the
questions raised by these new data change as well.
GPS costs are high, and the number of animals monitored
is therefore generally low. On the other hand, the number
of relocations available for each animal is really considerable.
Thus, biologists generally focus on a lower scale, and have
to explore more deeply the spatial behaviour of the animals
considered individually.

However, it is difficult to change now all the classes
of objects returned by the functions. Thus, the function
mcp returns an object of class "area", with three columns:
the first one indicates the ID of the animal, the second
and third indicate the coordinates of the vertices of the
home range. If the function mcp is to be used on only one
animal, then the first column is no longer needed. What is
needed is a data frame with two columns (X and Y of the
vertices of the home range). Such an object would no longer
be of class "area". Thus, one has to define a new class for
this kind of data, and associated methods (for plotting, to
allow the rasterization, etc.). And this rationale also applies
to other methods (kernelUD, NNCH, schoener, etc.). This
would render the package more difficult both to program and to
learn (IMHO beginners would be lost in such a labyrinth of
functions). Therefore it seems difficult to change now
the structure of the package so deeply, but I acknowledge
that I need to think to this remark more profoundly.

On the other hand, what I can do is to change the functions,
so that they deal more easily with objects with only one
animal. I already changed the functions plot.NNCH and image.khr,
following our previous discussion, to allow a more plastic
handling of graphical parameters.

Now, note that many graphical functions in adehabitat are indeed here
only to provide quick access to an overview of all data within
a project (the user is encouraged to build his own functions -
especially for plotting).

>I am currently running the moving window analysis for LoCoH as a
>preliminary analysis for a presentation later this month. Thus, I don't 
>have much time to do fancy things. However, your comments on the moving 
>window method are spot on! I would indeed prefer a choice of options in 
>the moving window method to set the window size by 1) a fix number of 
>points (as is now the case), or 2) a time period, or 3) using the burst 
>id. My GPS data is collected at reasonably fixed intervals, but still time 
>between fixes varies. I also think a time period might be more 
>ecologically relevant and thus help users to understand the results. Of 
>course the burst variable might contain a relevant window size predefined 
>by the user.
>I was about to edit the moving window code, but soon realized that I would 
>struggle a lot. Would you consider providing the above functionality in a 
>moving window function? I will be happy to test new versions and think 
>about how the introduce some sort of weighting approach.

To apply a moving window function using a fiwed time period, use this one:

movingWindowNNHCdate <- function(data, date, width, k, units, percent) {
   dateb <- date
   class(date) <- NULL
   multiNNCH <- 0
   out <- 0
   m <- 1
   for (i in 1:length(date)) {
     liminf <- date[i]-width/2
     limsup <- date[i]+width/2
     datab <- data[(date>liminf)&(date<limsup),]
     if (nrow(datab)>k) {
       multiNNCH[m]<-NNCH.area(NNCH(datab, k=k, unin=units),
       out<-c(out, i)
       m <- m+1
   out <- out[-1]
   dateb <- unlist(lapply(out, function(i) dateb[i]))
   class(dateb) <- c("POSIXt", "POSIXct")
   ii <- as.data.frame((list(date=dateb, area=multiNNCH)))

, where "width" is the width of the time period in seconds. For example,

u <- getburst(puechcirc, burst="CH930824")
xy <- u[,c("x","y")]
class(xy) <- "data.frame"

## For example, a time interval of three hours
## (60 seconds * 60 minutes * 3 hours)
ii <- movingWindowNNHCdate(xy, u$date, 60*60*3, 5,"m", 95)
plot(ii[,1], ii[,2], ty="b", ylab="Home range size", xlab="Time")

If you want to compute NNCH using the burst ID,
then just use the function NNCH by setting the
argument id equal to the burst id.

But we have two limitations here:
* a mathematical limitation: the NNCH home range is
   probably affected by the number of relocations used to
   estimate the home range
* a biological limitation: the home range is defined for a
   given period.
If the home range is estimated within a moving window analysis,
and if the time interval between relocations is not constant, then
one of the two limitations arise. We work either on a fixed number
of relocations, and period length differ, or we work on a fixed time
period and the number of relocations differ. As you noted,
a time period might be more ecologically relevant. However, it
seems that NNCH is very sensitive to the number of points used (pers.
obs.). So that the validity of such an approach is still to be tested.
Because of all these uncertainties, I don't think I can include such a
function in adehabitat yet, though it seems promising. Do you know
whether this approach has already been used in an article ?

> From replies to a query to the GRASS mailing list I so far distilled that 
> a lot of GIS functionality is possible within R. Thus, there might not be 
> a need to export the LoCoH neighborhoods to a GIS. Would it be possible 
> to sample other point patterns or rasters with the LoCoH polygons, all 
> within R?

Yes, it is! these functions are even available in adehabitat.
Raster maps can be imported with import.asc. The (new)
function NNCH.rast allows to rasterize home ranges (it is
based on the function mcp.rast). You can then use the function
setmask to determine the value of habitat variables within the
home range. If you have a point pattern and that you want to
know which points are inside or outside the polygons, you can use
the function inout or inpip of the package splancs. But this
will be complex to do, as NNCH home ranges may contain holes.
So you may also first rasterize the home range with NNCH.rast,
and then use the function join.asc to determine which points are
inside or outside the home range. Adehabitat does allow the
handling of raster maps.

>I look forward to receiving the new version of Adehabitat. My mailbox will 
>be able to handle it just fine!

I send you the package off-list (for windows ? unix? mac ?)
Thank you again for your message,


UMR CNRS 5558 - Equipe "Ecologie Statistique"
Laboratoire de Biométrie et Biologie Evolutive
Université Claude Bernard Lyon 1
43, Boulevard du 11 novembre 1918
69622 Villeurbanne Cedex
tel. (+33)
fax. (+33)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.faunalia.com/pipermail/animov/attachments/20050125/1b950515/attachment.htm

More information about the AniMov mailing list