[AniMov] positions from azimuths

Clément Calenge calenge at biomserv.univ-lyon1.fr
Tue Oct 14 11:07:35 CEST 2008


>> Sorry for the delay on this.  I contacted Gary White and asked if it
>> would be okay to simply integrate the TRIANG code into R and potentially
>> make it available in adehabitat or other software.  He said that was
>> fine. Since then, I simply haven't had as much time as I'd hoped to work
>> on this project.
>>
>> If no Python code is available, someone who knows FORTRAN and Python
>> could probably translate the TRIANG code fairly quickly.  It's not very
>> long.
>>
>>     
>
> Good news...
> As I've written before, I can brush up my almost forgotten FORTRAN and try a 
> porting...
>
> IMHO, a translation into R code might be more appealing, since can be 
> integrated easily into Clement (and others) adehabitat package, which seems 
> to be the real workhorse in free/open homerange calculations.
>
> As Anne did for the QGis Homerange plugin, I'm wondering if a good solution 
> could be making the engine in R, and use python for the bodywork... this way 
> one could stay in R for heavy-duty or automated homerange calculation (figure 
> out how to calculate overlaps among 200 animals in a pure GUI 
> environment...), and another can use a GUI (I mean QGis) for small amounts fd 
> data, or for a direct visual feedback and so on...
>
>
> Suggestions?
>   

Maybe the best solution would not be to translate the Fortran code in R, 
but to interface it with R. The execution of compiled code based on 
Fortran is faster than functions programmed in R, and the R environment 
provides a function allowing to make calls to compiled Fortran Code (the 
function .Fortran). I do not speak Fortran, but I often use the 
corresponding function to make calls to C code (function .C, used in 
many functions of adehabitat), and this results into very fast computation.

Porting an originally independent program into R is a common operation: 
this is the case of the package ade4 (which was originally the 
independent software ADE-4, 
http://pbil.univ-lyon1.fr/ADE-4-old/ADE-4.html), of the package gpclib 
(originally, the GPC library; 
http://en.wikipedia.org/wiki/GPC_General_Polygon_Clipper_Library), of 
the package randomForest (originally the software "Random Forests" 
programmed in Fortran by Breiman and Cutler, 
http://oz.berkeley.edu/users/breiman/Using_random_forests_V3.1.pdf), etc.

What about just making a "interfacing function" between R and this 
Fortran code? Then, the compiled Fortran code would be the engine, and 
use both R (for R calculation) and python (for QGIS calculations). And 
this would avoid a tedious Fortran -> R translation?
Cheers,

Clément Calenge.

-- 
Clément CALENGE
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. (33) 01.30.46.54.14



More information about the AniMov mailing list