[AniMov] Re: kNNCH code questions?

Sander Oom slist at oomvanlieshout.net
Tue Jan 25 17:40:25 CET 2005


Hi Clement,

(I run R on Windows and Linux!)

Thanks for the clear explanation of the thinking and history behind the 
current classes in Adehabitat. It very clear to separate the population, 
animal and relocation focuss of scientific questions and thus the 
methods developed. I can see how this influenced the development of 
Adehabitat. I'll keep you posted on how I perceive the methods and you 
can see what relevance it has to Adehabitat!

Much thanks for the code for the moving per time window method. However, 
I'm not sure if it works correctly. My data spans the following time 
period:

    DaTimCt
  Min.   :2003-09-05 04:55:55
  1st Qu.:2003-11-26 07:47:29
  Median :2004-02-26 16:33:53
  Mean   :2004-03-09 16:39:15
  3rd Qu.:2004-06-29 02:47:47
  Max.   :2004-11-17 07:52:14

When running the analysis with a window size of 7 days, I get the 
following output file:

                    date       area
1   2003-09-20 08:55:50 5657.46042
2   2003-09-20 13:56:05 5657.46042
3   2003-09-20 18:54:41 3623.76446
4   2003-09-20 23:55:31 3623.76446
5   2003-09-21 04:54:43 4668.71662
6   2003-09-21 09:54:42 4668.71662
7   2003-09-21 14:55:29 4668.71662
8   2003-09-21 19:54:40 4658.56291
9   2003-09-22 00:55:09 4661.80715
10  2003-09-22 05:54:41 4663.95660
11  2003-09-22 10:55:00 4293.08795
12  2003-09-22 20:54:35 3591.76940
13  2003-09-23 01:55:59 2427.27694
14  2003-09-23 06:54:39 2427.27694
15  2003-09-23 11:54:41 2427.27694
16  2003-09-23 16:54:30 2427.27694
17  2003-09-23 21:54:12 1857.58550
18  2003-09-24 02:54:35 2273.35975
19  2003-09-24 07:54:12 2273.35975
20  2003-09-24 12:56:02 2088.09259
21  2003-09-24 17:55:13 2088.09259
22  2003-09-24 22:54:42 2088.05671
23  2003-09-25 03:54:10 2087.20753
...
...
644 2004-08-02 19:23:12 1277.41873
645 2004-08-02 20:23:13 1277.41873
646 2004-08-03 18:23:54  947.36707
647 2004-08-03 20:23:20  946.69189
648 2004-08-03 22:24:13  946.69189
649 2004-08-04 00:55:13  946.69189
650 2004-08-04 01:55:41  946.69189
651 2004-08-04 02:56:30  946.69189
652 2004-08-04 20:23:28  829.67570
653 2004-08-04 21:23:08  829.67570
654 2004-08-04 22:24:45  829.67570
655 2004-08-04 23:23:49  829.67570
656 2004-08-05 23:23:03  829.67570
657 2004-08-06 01:23:19  829.67570

It seems that the moving window does not make it till the end.

Following my separate email, I also do miss a step size option now. I 
would like the moving window to move 1 day for each new window, not one 
record in the data set. Is it tricky to build in a step size as well?

Please note that I am currently running this on the whole data set, 
which is not controlled for a set relocation frequency, i.e. the number 
of points per day varies. Broader testing of the consequence of 
different approaches will follow later. Now I just need a graph to impress!

Hope you can help me out,

Sander.

Clément Calenge wrote:
> 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),
>                               percent=percent)[1,1]
>       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)))
>   return(ii)
> }
> 
> , where "width" is the width of the time period in seconds. For example,
> 
> data(puechcirc)
> 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,
> Sincerely,
> 
> 
> Clément
> 
> ======================================
> 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
> FRANCE
> tel. (+33) 04.72.43.27.57
> fax. (+33) 04.72.43.13.88
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> AniMov mailing list
> AniMov at faunalia.com
> http://www.faunalia.com/cgi-bin/mailman/listinfo/animov

-- 
---------------------------------------------------------
Dr. Sander P. Oom
Animal, Plant and Environmental Sciences
University of the Witwatersrand
Private Bag 3
Wits 2050
South Africa

Tel (work)      +27 (0)11 717 64 04
Tel (home)      +27 (0)18 297 44 51
Fax             +27 (0)18 299 24 64

Email   sander at oomvanlieshout.net
Web     www.oomvanlieshout.net/sander
---------------------------------------------------------



More information about the AniMov mailing list