Nabble - AniMov

Re: Brownian Bridge home range in Adehabitat - getvolumeUD issue

2009-11-13T12:44:24Z

You're not only a genius but I really appreciate the time you spend helping us!

It seems to work, your suggestion, I just changed the grid size so the UD's can all be summed and then plotted.
I used the code of someone else, sorry I don't remember the name, already posted in this forum:

xybox <- data.frame(x=c(min(mv.dat$x)-1000, max(mv.dat$x)+1000),
c(min(mv.dat$y)-1000, max(mv.dat$y)+1000))
asc <- ascgen(xybox, cellsize=30)

I'll be making some tests and let the forum know soon my results

Thanks for all!

F.

Clément Calenge-2 wrote:

It seems that liker greatly overestimates the parameter sig1 in this
case. Actually, the use of this method relies on the hypothesis that the
animal is moving according to a Brownian motion between two successive
relocations. Depending on the speed of the animal, the bridge may be
made more or less narrow, the parameter sig1 is controlling this width.
When the parameter sig1 increases, the movement of the animal between
two successive relocations is supposed to be more "diffuse". Given the
fast speed supposed when setting a large parameter sig1, the time lag
between the two relocations is long enough to allow the animal to make
large moves, i.e. moving far from the straight line connecting the two
relocations. The relocations then are no longer "attractors" of the
animal during the movements supposed by the model, and the probability
under this model to find the animal far from these relocations is not
negligible when sig1 is large. Consider the following example (just copy
and paste in R):

par(mfrow=c(2,1))
plot(simm.bb(1:1000,end=c(10,10)), addp=FALSE)
plot(simm.bb(1:1000,end=c(1000,1000)), addp=FALSE)

The upper graph shows a Brownian bridge characterized by an end
relocation (in red) close to the the start point (in blue). This is
similar to a large value of sig1 (i.e. fast animal). And the lower graph
shows a Brownian bridge characterized by an end point far from the start
point. This is similar to a very small value of sig1. In the latter
case, the movement is close to the line segment separating the two
relocations. You can see on the first graph that the animal may move far
from the start and end relocations during the time lag separating the
relocations. And this may even be far from the other relocations, i.e.
far from the "true" home range. This is caused by the hypothesis that
the animal is moving according to a Brownian motion between successive
relocations. This Brownian bridge is a useful model when sig1 is not too
large, because it allows to take into account the fact that the animal
is moving between relocations. Taking a too large sig1 reduces the
usefulness of this model...

So, now the question is: why the liker function does return a so large
result? By curiosity, I compared on your data the results of the
function liker from adehabitat and of the program provided by Horne et
al. (2007, Ecology): the two functions give fairly similar results for
sig2=100:

adehabitat, function liker: sig1 = 10.16
Horne et al, visual basic program: sig1 = sqrt(103.735) = 10.18

Actually, as indicated by Horne et al., the estimation procedure of sig1
strongly relies on the assumption of the Brownian bridge model. This may
be problematic given your data. Indeed, the function kernelbb does not
consider the partitioning of the trajectory of an animal into "bursts".
Have a look at your data:

> tr

*********** List of class ltraj ***********

Type of the traject: Type II (time recorded)
Irregular traject. Variable time lag between two locs

Characteristics of the bursts:
id burst nb.reloc NAs date.begin date.end
1 1 11 1 0 2008-05-25 00:39:00 2008-05-25 00:39:00
2 1 110 6 0 2008-08-02 01:40:00 2008-08-02 05:56:00
3 1 111 5 0 2008-08-12 01:50:00 2008-08-12 04:58:00
4 1 112 10 0 2008-08-13 00:28:00 2008-08-13 07:02:00
...

The first "burst" is made of only one relocation. Then a time lag of
more than two months occur. Then a burst of 6 relocations collected
every hour do occur. Then, two days after the last relocation of this
burst, there is a new burst of relocations collected every hour, etc.
The function kernelbb assumes that the movement between any pair of
successives relocations is generated by the *same* Brownian bridge
model, whatever the time lag between the relocations. Therefore, even if
sig1 is set so that the movement between two relocations separated by an
hour is nearly straight, when two days are separating the relocations,
using the same sig1, the probability that the animal moves far from the
relocations under the assumed model is high. This is similar to the
following situation:

star <- c(simm.bb(1:1000,begin=c(0,0), end=c(1000,1000), burst="A0"),
simm.bb(round(seq(1001, 10001000, length=1000)),begin=c(1000,1000),
end=c(2000,2000)))
plot(star, addp=FALSE)

This graph presents three relocations (in red and blue) together with a
simulated Brownian bridge supposed between the relocations. The first
two relocations are separated by 1000 seconds and the last two by
10,000,000 seconds. You can see that the animal can move far from the
relocations under the supposed model.

Therefore, you have to think about the time scale at which you want to
have an estimate of the home-range. The function kernelbb does not (yet)
offer the possibility to estimate the home-range using pairs of
successive relocations at most separated by an interval of X seconds.
One possibility would be to estimate a brownian bridge for each burst
separately, and then to combine them together, giving them a weight
corresponding to the number of relocations used for the estimation. That
is, something like:

## remove the first burst, because only one relocation
tr2 <- tr[-1]

## estimate the Brownian bridge kernel for each burst separately
hrBB <- kernelbb(tr2, sig1 = 6, sig2 = 100, grid = 40, byburst=TRUE)

## then combine the UDs
liUD <- lapply(1:length(tr2), function(i) {
hrBB[[i]]$UD * (nrow(tr2[[i]]) / sum(sapply(tr2, nrow)))
})

UDend <- liUD[[1]]
for (i in 2:length(liUD))
UDend <- UDend + liUD[[i]]

## Plot the result
image(UDend)
contour(getvolumeUDs(UDend), level=95, col="red", lwd=2, add=TRUE)

And for the sig1 selection:

ii <- liker(tr3, c(2,100), 100, byburst=TRUE)
hist(sapply(ii, function(x) x$sig1), ncla=20, col="grey")
median(sapply(ii, function(x) x$sig1))

Note that a value sig1 = 6 seems reasonable.
Hope this helps
Best regards,

Clément Calenge

--
Clément CALENGE
Cellule d'appui à l'analyse de données
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. (33) 01.30.46.54.14

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

Re: Brownian Bridge home range in Adehabitat - getvolumeUD issue

2009-11-13T12:00:20Z

It seems that liker greatly overestimates the parameter sig1 in this
case. Actually, the use of this method relies on the hypothesis that the
animal is moving according to a Brownian motion between two successive
relocations. Depending on the speed of the animal, the bridge may be
made more or less narrow, the parameter sig1 is controlling this width.
When the parameter sig1 increases, the movement of the animal between
two successive relocations is supposed to be more "diffuse". Given the
fast speed supposed when setting a large parameter sig1, the time lag
between the two relocations is long enough to allow the animal to make
large moves, i.e. moving far from the straight line connecting the two
relocations. The relocations then are no longer "attractors" of the
animal during the movements supposed by the model, and the probability
under this model to find the animal far from these relocations is not
negligible when sig1 is large. Consider the following example (just copy
and paste in R):

par(mfrow=c(2,1))
plot(simm.bb(1:1000,end=c(10,10)), addp=FALSE)
plot(simm.bb(1:1000,end=c(1000,1000)), addp=FALSE)

The upper graph shows a Brownian bridge characterized by an end
relocation (in red) close to the the start point (in blue). This is
similar to a large value of sig1 (i.e. fast animal). And the lower graph
shows a Brownian bridge characterized by an end point far from the start
point. This is similar to a very small value of sig1. In the latter
case, the movement is close to the line segment separating the two
relocations. You can see on the first graph that the animal may move far
from the start and end relocations during the time lag separating the
relocations. And this may even be far from the other relocations, i.e.
far from the "true" home range. This is caused by the hypothesis that
the animal is moving according to a Brownian motion between successive
relocations. This Brownian bridge is a useful model when sig1 is not too
large, because it allows to take into account the fact that the animal
is moving between relocations. Taking a too large sig1 reduces the
usefulness of this model...

So, now the question is: why the liker function does return a so large
result? By curiosity, I compared on your data the results of the
function liker from adehabitat and of the program provided by Horne et
al. (2007, Ecology): the two functions give fairly similar results for
sig2=100:

adehabitat, function liker: sig1 = 10.16
Horne et al, visual basic program: sig1 = sqrt(103.735) = 10.18

Actually, as indicated by Horne et al., the estimation procedure of sig1
strongly relies on the assumption of the Brownian bridge model. This may
be problematic given your data. Indeed, the function kernelbb does not
consider the partitioning of the trajectory of an animal into "bursts".
Have a look at your data:

> tr

*********** List of class ltraj ***********

Type of the traject: Type II (time recorded)
Irregular traject. Variable time lag between two locs

Characteristics of the bursts:
id burst nb.reloc NAs date.begin date.end
1 1 11 1 0 2008-05-25 00:39:00 2008-05-25 00:39:00
2 1 110 6 0 2008-08-02 01:40:00 2008-08-02 05:56:00
3 1 111 5 0 2008-08-12 01:50:00 2008-08-12 04:58:00
4 1 112 10 0 2008-08-13 00:28:00 2008-08-13 07:02:00
...

The first "burst" is made of only one relocation. Then a time lag of
more than two months occur. Then a burst of 6 relocations collected
every hour do occur. Then, two days after the last relocation of this
burst, there is a new burst of relocations collected every hour, etc.
The function kernelbb assumes that the movement between any pair of
successives relocations is generated by the *same* Brownian bridge
model, whatever the time lag between the relocations. Therefore, even if
sig1 is set so that the movement between two relocations separated by an
hour is nearly straight, when two days are separating the relocations,
using the same sig1, the probability that the animal moves far from the
relocations under the assumed model is high. This is similar to the
following situation:

star <- c(simm.bb(1:1000,begin=c(0,0), end=c(1000,1000), burst="A0"),
simm.bb(round(seq(1001, 10001000, length=1000)),begin=c(1000,1000),
end=c(2000,2000)))
plot(star, addp=FALSE)

This graph presents three relocations (in red and blue) together with a
simulated Brownian bridge supposed between the relocations. The first
two relocations are separated by 1000 seconds and the last two by
10,000,000 seconds. You can see that the animal can move far from the
relocations under the supposed model.

Therefore, you have to think about the time scale at which you want to
have an estimate of the home-range. The function kernelbb does not (yet)
offer the possibility to estimate the home-range using pairs of
successive relocations at most separated by an interval of X seconds.
One possibility would be to estimate a brownian bridge for each burst
separately, and then to combine them together, giving them a weight
corresponding to the number of relocations used for the estimation. That
is, something like:

## remove the first burst, because only one relocation
tr2 <- tr[-1]

## estimate the Brownian bridge kernel for each burst separately
hrBB <- kernelbb(tr2, sig1 = 6, sig2 = 100, grid = 40, byburst=TRUE)

## then combine the UDs
liUD <- lapply(1:length(tr2), function(i) {
hrBB[[i]]$UD * (nrow(tr2[[i]]) / sum(sapply(tr2, nrow)))
})

UDend <- liUD[[1]]
for (i in 2:length(liUD))
UDend <- UDend + liUD[[i]]

## Plot the result
image(UDend)
contour(getvolumeUDs(UDend), level=95, col="red", lwd=2, add=TRUE)

And for the sig1 selection:

ii <- liker(tr3, c(2,100), 100, byburst=TRUE)
hist(sapply(ii, function(x) x$sig1), ncla=20, col="grey")
median(sapply(ii, function(x) x$sig1))

Note that a value sig1 = 6 seems reasonable.
Hope this helps
Best regards,

Clément Calenge

--
Clément CALENGE
Cellule d'appui à l'analyse de données
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. (33) 01.30.46.54.14

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

Re: Brownian Bridge home range in Adehabitat - getvolumeUD issue

2009-11-13T08:04:08Z

Hi Clément,

thaks for the reply!

Yes, I'm using "liker" has you may see in the code below.

I'm sending some data if you which (mydata.csv)mydata.csv.
Or below I just copy paste it

Thanks again!

please take a look to my codes:

(script tinn-r:script.r)

#----------------------script-----------------------------------

mv.dat <- read.csv("mydata.csv",header=T)

xy <- data.frame(cbind(mv.dat$x, mv.dat$y))
dat <- paste(mv.dat$day,mv.dat$hour)
tm <- strptime(dat, format="%Y-%m-%d %H:%M:%S",tz = "GMT")
tmp <- as.POSIXct(tm)

sig2 <- 100 # mean telemetry error in meters

tr=as.ltraj(xy, tmp, id=mv.dat$ID, burst = mv.dat$IDPath, typeII = TRUE, slsp ="remove")
par(mfrow=c(1,2))

# Brownian Bride method

lik <- liker(tr, sig2 = sig2, rangesig1 = c(1, 200),le = 1000, plotit = FALSE)
hrBB <- kernelbb(tr, sig1 = lik[[1]]$sig1, sig2 = sig2, grid = 100)

image(hrBB[[1]]$UD, axes=FALSE, ylab="Longitude",xlab="Latitude",main="Brownian bridge home range")
contour(getvolumeUD(hrBB)[[1]]$UD, lev=95, col="red", add=TRUE)
points(xy, pch=19, cex=.1,col="blue")
box()

# Classic Kernel method

kud <- kernelUD(xy, grid = 100)

image(kud[[1]]$UD, axes=FALSE, ylab="Longitude",xlab="Latitude", main="Classical kernel home range")
contour(getvolumeUD(kud)[[1]]$UD, lev=95, col="red", add=TRUE)
points(xy, pch=19, cex=.1,col="blue")
box()

#------------------------------end script-----------------------------------------

####################################################################### my data#############################################################

Nome ID Year day hour night IDPath time_lag x y
1 Deolinda 1 2008 24/05/2008 22:39:00 1 11 NA 558528 4275703
2 Deolinda 1 2008 26/05/2008 21:06:00 2 12 22:27 557624 4276548
3 Deolinda 1 2008 26/05/2008 23:38:00 2 12 2:32 557781 4276344
4 Deolinda 1 2008 27/05/2008 0:37:00 2 12 0:59 557691 4276588
5 Deolinda 1 2008 30/05/2008 21:57:00 3 13 21:20 559964 4276341
6 Deolinda 1 2008 31/05/2008 0:42:00 3 13 2:45 558304 4276480
7 Deolinda 1 2008 01/06/2008 21:52:00 4 14 21:10 559075 4277254
8 Deolinda 1 2008 01/06/2008 23:04:00 4 14 1:12 557964 4276147
9 Deolinda 1 2008 01/06/2008 23:58:00 4 14 0:54 558164 4276065
10 Deolinda 1 2008 05/06/2008 22:33:00 5 15 22:35 558100 4277357
11 Deolinda 1 2008 05/06/2008 23:10:00 5 15 0:37 558437 4276900
12 Deolinda 1 2008 06/06/2008 0:37:00 5 15 1:27 559468 4275990
13 Deolinda 1 2008 17/06/2008 2:19:00 6 16 1:42 558513 4276776
14 Deolinda 1 2008 17/06/2008 2:53:00 6 16 0:34 558778 4277268
15 Deolinda 1 2008 17/06/2008 3:26:00 6 16 0:33 558848 4277159
16 Deolinda 1 2008 17/06/2008 3:57:00 6 16 0:31 558707 4276971
17 Deolinda 1 2008 17/06/2008 4:25:00 6 16 0:28 558628 4276877
18 Deolinda 1 2008 17/06/2008 4:57:00 6 16 0:32 558672 4277084
19 Deolinda 1 2008 17/06/2008 5:59:00 6 16 1:02 559026 4276123
20 Deolinda 1 2008 02/07/2008 0:16:00 7 17 18:17 558667 4277829
21 Deolinda 1 2008 02/07/2008 0:48:00 7 17 0:32 558695 4277639
22 Deolinda 1 2008 02/07/2008 1:19:00 7 17 0:31 557984 4277315
23 Deolinda 1 2008 02/07/2008 2:32:00 7 17 1:13 558063 4275766
24 Deolinda 1 2008 02/07/2008 3:01:00 7 17 0:29 558155 4276117
25 Deolinda 1 2008 02/07/2008 3:05:00 7 17 0:04 559952 4276263
26 Deolinda 1 2008 02/07/2008 3:23:00 7 17 0:18 558917 4277480
27 Deolinda 1 2008 03/07/2008 0:11:00 8 18 20:48 559287 4277101
28 Deolinda 1 2008 03/07/2008 0:46:00 8 18 0:35 559381 4276893
29 Deolinda 1 2008 03/07/2008 1:38:00 8 18 0:52 559620 4277242
30 Deolinda 1 2008 03/07/2008 2:14:00 8 18 0:36 559478 4277095
31 Deolinda 1 2008 03/07/2008 2:42:00 8 18 0:28 559060 4277262
32 Deolinda 1 2008 03/07/2008 3:13:00 8 18 0:31 559258 4277232
33 Deolinda 1 2008 03/07/2008 3:41:00 8 18 0:28 559182 4277316
34 Deolinda 1 2008 03/07/2008 4:11:00 8 18 0:30 559179 4277336
35 Deolinda 1 2008 03/07/2008 4:40:00 8 18 0:29 559653 4277057
36 Deolinda 1 2008 03/07/2008 5:12:00 8 18 0:32 559340 4277124
37 Deolinda 1 2008 03/07/2008 5:54:00 8 18 0:42 559351 4276645
38 Deolinda 1 2008 29/07/2008 23:25:00 9 19 17:31 557765 4275988
39 Deolinda 1 2008 30/07/2008 1:11:00 9 19 1:46 556983 4276929
40 Deolinda 1 2008 30/07/2008 1:52:00 9 19 0:41 556745 4276810
41 Deolinda 1 2008 30/07/2008 2:33:00 9 19 0:41 557036 4276752
42 Deolinda 1 2008 01/08/2008 23:40:00 10 110 21:07 559236 4276741
43 Deolinda 1 2008 02/08/2008 1:10:00 10 110 1:30 557197 4277107
44 Deolinda 1 2008 02/08/2008 1:50:00 10 110 0:40 557219 4277049
45 Deolinda 1 2008 02/08/2008 2:32:00 10 110 0:42 557048 4276725
46 Deolinda 1 2008 02/08/2008 3:20:00 10 110 0:48 557877 4277077
47 Deolinda 1 2008 02/08/2008 3:56:00 10 110 0:36 558222 4276747
48 Deolinda 1 2008 11/08/2008 23:50:00 11 111 19:54 559747 4277083
49 Deolinda 1 2008 12/08/2008 0:23:00 11 111 0:33 559679 4276881
50 Deolinda 1 2008 12/08/2008 1:47:00 11 111 1:24 559217 4275961
51 Deolinda 1 2008 12/08/2008 2:15:00 11 111 0:28 559086 4276086
52 Deolinda 1 2008 12/08/2008 2:58:00 11 111 0:43 558819 4275588
53 Deolinda 1 2008 12/08/2008 22:28:00 12 112 19:30 557293 4276092
54 Deolinda 1 2008 12/08/2008 23:02:00 12 112 0:34 557482 4275979
55 Deolinda 1 2008 12/08/2008 23:33:00 12 112 0:31 557783 4275736
56 Deolinda 1 2008 13/08/2008 0:00:00 12 112 0:27 557877 4275934
57 Deolinda 1 2008 13/08/2008 0:30:00 12 112 0:30 557369 4275896
58 Deolinda 1 2008 13/08/2008 1:00:00 12 112 0:30 557546 4275871
59 Deolinda 1 2008 13/08/2008 1:31:00 12 112 0:31 558013 4275551
60 Deolinda 1 2008 13/08/2008 2:03:00 12 112 0:32 557982 4275751
61 Deolinda 1 2008 13/08/2008 4:31:00 12 112 2:28 559442 4276780
62 Deolinda 1 2008 13/08/2008 5:02:00 12 112 0:31 559517 4277087
63 Deolinda 1 2008 14/08/2008 23:58:00 13 113 18:56 558292 4275663
64 Deolinda 1 2008 15/08/2008 0:27:00 13 113 0:29 558370 4275633
65 Deolinda 1 2008 15/08/2008 2:27:00 13 113 2:00 558674 4275784
66 Deolinda 1 2008 15/08/2008 2:57:00 13 113 0:30 558796 4275767
67 Deolinda 1 2008 15/08/2008 4:14:00 13 113 1:17 559893 4276610
68 Deolinda 1 2008 15/08/2008 4:52:00 13 113 0:38 559590 4276461
69 Deolinda 1 2008 15/08/2008 6:00:00 13 113 1:08 559821 4276233
70 Deolinda 1 2008 17/08/2008 1:01:00 14 114 19:01 559527 4276649
71 Deolinda 1 2008 17/08/2008 1:32:00 14 114 0:31 559271 4276537
72 Deolinda 1 2008 17/08/2008 2:15:00 14 114 0:43 558726 4276433
73 Deolinda 1 2008 17/08/2008 2:44:00 14 114 0:29 558572 4276566
74 Deolinda 1 2008 17/08/2008 3:15:00 14 114 0:31 558444 4276615
75 Deolinda 1 2008 17/08/2008 3:45:00 14 114 0:30 558274 4276780
76 Deolinda 1 2008 17/08/2008 4:41:00 14 114 0:56 558411 4276959
77 Deolinda 1 2008 17/08/2008 23:49:00 15 115 19:08 558634 4275463
78 Deolinda 1 2008 18/08/2008 0:21:00 15 115 0:32 559114 4275776
79 Deolinda 1 2008 18/08/2008 1:13:00 15 115 0:52 559603 4276847
80 Deolinda 1 2008 18/08/2008 1:56:00 15 115 0:43 559216 4277029
81 Deolinda 1 2008 18/08/2008 3:07:00 15 115 1:11 559778 4276839
82 Deolinda 1 2008 18/08/2008 3:42:00 15 115 0:35 559465 4277504
83 Deolinda 1 2008 18/08/2008 4:15:00 15 115 0:33 559570 4276962
84 Deolinda 1 2008 18/08/2008 4:45:00 15 115 0:30 559432 4277415
85 Deolinda 1 2008 18/08/2008 5:20:00 15 115 0:35 559221 4277741
86 Deolinda 1 2008 18/08/2008 5:50:00 15 115 0:30 559143 4277596
87 Deolinda 1 2008 25/08/2008 23:29:00 16 116 17:39 559319 4276635
88 Deolinda 1 2008 26/08/2008 0:00:00 16 116 0:31 559569 4276694
89 Deolinda 1 2008 26/08/2008 0:31:00 16 116 0:31 559425 4276619
90 Deolinda 1 2008 26/08/2008 1:06:00 16 116 0:35 559468 4276569
91 Deolinda 1 2008 26/08/2008 1:32:00 16 116 0:26 559999 4276244
92 Deolinda 1 2008 26/08/2008 2:00:00 16 116 0:28 559774 4276149
93 Deolinda 1 2008 26/08/2008 2:31:00 16 116 0:31 559667 4276006
94 Deolinda 1 2008 26/08/2008 3:04:00 16 116 0:33 559709 4276165
95 Deolinda 1 2008 26/08/2008 3:31:00 16 116 0:27 559827 4276569
96 Deolinda 1 2008 26/08/2008 4:01:00 16 116 0:30 559684 4276472
97 Deolinda 1 2008 26/08/2008 4:33:00 16 116 0:32 559428 4276627
98 Deolinda 1 2008 26/08/2008 5:06:00 16 116 0:33 559474 4276965
99 Deolinda 1 2008 26/08/2008 5:35:00 16 116 0:29 559853 4276932
100 Deolinda 1 2008 26/08/2008 22:31:00 17 117 16:56 559241 4276807
101 Deolinda 1 2008 26/08/2008 23:12:00 17 117 0:41 558660 4276852
102 Deolinda 1 2008 26/08/2008 23:45:00 17 117 0:33 558546 4276360
103 Deolinda 1 2008 27/08/2008 0:18:00 17 117 0:33 558309 4276224
104 Deolinda 1 2008 27/08/2008 1:32:00 17 117 1:14 557064 4276590
105 Deolinda 1 2008 27/08/2008 2:05:00 17 117 0:33 556928 4276879
106 Deolinda 1 2008 27/08/2008 2:32:00 17 117 0:27 557287 4276665
107 Deolinda 1 2008 27/08/2008 3:15:00 17 117 0:43 557301 4276442
108 Deolinda 1 2008 27/08/2008 4:08:00 17 117 0:53 557926 4276209
109 Deolinda 1 2008 27/08/2008 4:52:00 17 117 0:44 557454 4275804
110 Deolinda 1 2008 09/09/2008 21:25:00 18 118 16:33 560036 4276241
111 Deolinda 1 2008 09/09/2008 21:55:00 18 118 0:30 559863 4276218
112 Deolinda 1 2008 09/09/2008 22:25:00 18 118 0:30 559863 4276218
113 Deolinda 1 2008 09/09/2008 23:00:00 18 118 0:35 559863 4276218
114 Deolinda 1 2008 09/09/2008 23:30:00 18 118 0:30 559863 4276218
115 Deolinda 1 2008 10/09/2008 0:00:00 18 118 0:30 559417 4276367
116 Deolinda 1 2008 10/09/2008 1:00:00 18 118 1:00 558549 4276287
117 Deolinda 1 2008 10/09/2008 1:45:00 18 118 0:45 558211 4275739
118 Deolinda 1 2008 02/10/2008 22:38:00 19 119 20:53 558953 4277044
119 Deolinda 1 2008 02/10/2008 23:11:00 19 119 0:33 558915 4277446
120 Deolinda 1 2008 02/10/2008 23:42:00 19 119 0:31 558749 4277476
121 Deolinda 1 2008 03/10/2008 0:10:00 19 119 0:28 558749 4277476
122 Deolinda 1 2008 03/10/2008 0:31:00 19 119 0:21 558753 4277325
123 Deolinda 1 2008 03/10/2008 1:02:00 19 119 0:31 558170 4277404
124 Deolinda 1 2008 03/10/2008 1:31:00 19 119 0:29 558361 4277338
125 Deolinda 1 2008 03/10/2008 3:06:00 19 119 1:35 557510 4276104
126 Deolinda 1 2008 03/10/2008 3:30:00 19 119 0:24 557383 4276176
127 Deolinda 1 2008 03/10/2008 4:00:00 19 119 0:30 557358 4276198
128 Deolinda 1 2008 03/10/2008 4:31:00 19 119 0:31 557477 4276076
129 Deolinda 1 2008 13/10/2008 23:47:00 20 120 19:16 557881 4275647
130 Deolinda 1 2008 14/10/2008 0:23:00 20 120 0:36 557923 4275733
131 Deolinda 1 2008 14/10/2008 1:11:00 20 120 0:48 558058 4275674
132 Deolinda 1 2008 14/10/2008 1:42:00 20 120 0:31 558048 4275951
133 Deolinda 1 2008 14/10/2008 2:13:00 20 120 0:31 558452 4275685
134 Deolinda 1 2008 14/10/2008 2:42:00 20 120 0:29 558086 4276033
135 Deolinda 1 2008 14/10/2008 3:33:00 20 120 0:51 559120 4275807
136 Deolinda 1 2008 14/10/2008 4:11:00 20 120 0:38 559794 4275978
137 Deolinda 1 2008 14/10/2008 4:55:00 20 120 0:44 559674 4276332
138 Deolinda 1 2008 14/10/2008 5:36:00 20 120 0:41 559031 4276342
139 Deolinda 1 2008 14/10/2008 6:05:00 20 120 0:29 558658 4276425
140 Deolinda 1 2008 16/10/2008 22:45:00 21 121 16:40 558588 4277228
141 Deolinda 1 2008 16/10/2008 23:31:00 21 121 0:46 558560 4276861
142 Deolinda 1 2008 17/10/2008 0:04:00 21 121 0:33 557855 4276275
143 Deolinda 1 2008 17/10/2008 0:37:00 21 121 0:33 557943 4276698
144 Deolinda 1 2008 17/10/2008 1:03:00 21 121 0:26 557949 4276507
145 Deolinda 1 2008 17/10/2008 1:34:00 21 121 0:31 557834 4276526
146 Deolinda 1 2008 17/10/2008 2:04:00 21 121 0:30 557925 4276558
147 Deolinda 1 2008 17/10/2008 2:40:00 21 121 0:36 558157 4276499
148 Deolinda 1 2008 17/10/2008 3:09:00 21 121 0:29 557960 4276502
149 Deolinda 1 2008 17/10/2008 3:40:00 21 121 0:31 557960 4276502
150 Deolinda 1 2008 17/10/2008 4:10:00 21 121 0:30 557960 4276502
151 Deolinda 1 2008 17/10/2008 4:40:00 21 121 0:30 557960 4276502
152 Deolinda 1 2008 28/10/2008 20:20:00 22 122 15:40 559071 4277199
153 Deolinda 1 2008 28/10/2008 20:52:00 22 122 0:32 558991 4277070
154 Deolinda 1 2008 28/10/2008 21:24:00 22 122 0:32 559301 4277248
155 Deolinda 1 2008 28/10/2008 21:54:00 22 122 0:30 559058 4277513
156 Deolinda 1 2008 28/10/2008 22:24:00 22 122 0:30 558988 4277425
157 Deolinda 1 2008 28/10/2008 22:53:00 22 122 0:29 558946 4277412
158 Deolinda 1 2008 28/10/2008 23:25:00 22 122 0:32 558998 4277443
159 Deolinda 1 2008 28/10/2008 23:58:00 22 122 0:33 558146 4277541
160 Deolinda 1 2008 29/10/2008 1:05:00 22 122 1:07 556803 4276541
161 Deolinda 1 2008 30/10/2008 19:26:00 23 123 18:21 559025 4276313
162 Deolinda 1 2008 30/10/2008 21:13:00 23 123 1:47 557520 4276413
163 Deolinda 1 2008 30/10/2008 21:55:00 23 123 0:42 557914 4276839
164 Deolinda 1 2008 30/10/2008 22:38:00 23 123 0:43 558260 4275873
165 Deolinda 1 2008 31/10/2008 0:59:00 23 123 2:21 559587 4276477
166 Deolinda 1 2008 31/10/2008 1:34:00 23 123 0:35 559634 4276405
167 Deolinda 1 2008 31/10/2008 2:06:00 23 123 0:32 559459 4276579
168 Deolinda 1 2008 12/11/2008 20:15:00 24 124 18:09 559622 4276780
169 Deolinda 1 2008 12/11/2008 20:47:00 24 124 0:32 559676 4276726
170 Deolinda 1 2008 12/11/2008 21:19:00 24 124 0:32 559542 4276761
171 Deolinda 1 2008 12/11/2008 21:49:00 24 124 0:30 559516 4276748
172 Deolinda 1 2008 12/11/2008 22:20:00 24 124 0:31 559556 4276426
173 Deolinda 1 2008 12/11/2008 22:51:00 24 124 0:31 559860 4276264
174 Deolinda 1 2008 12/11/2008 23:28:00 24 124 0:37 559818 4276190
175 Deolinda 1 2008 12/11/2008 23:54:00 24 124 0:26 559926 4276297
176 Deolinda 1 2008 13/11/2008 0:23:00 24 124 0:29 559857 4276237
177 Deolinda 1 2008 13/11/2008 0:55:00 24 124 0:32 559903 4276174
178 Deolinda 1 2008 13/11/2008 1:22:00 24 124 0:27 559971 4276259
179 Deolinda 1 2008 13/11/2008 1:54:00 24 124 0:32 559927 4276206
180 Deolinda 1 2008 13/11/2008 2:23:00 24 124 0:29 559962 4276217
181 Deolinda 1 2008 13/11/2008 2:53:00 24 124 0:30 559976 4276603
182 Deolinda 1 2008 14/11/2008 19:40:00 25 125 16:47 559376 4276614
183 Deolinda 1 2008 14/11/2008 20:45:00 25 125 1:05 559198 4276801
184 Deolinda 1 2008 14/11/2008 21:41:00 25 125 0:56 559402 4277401
185 Deolinda 1 2008 14/11/2008 22:12:00 25 125 0:31 559384 4277482
186 Deolinda 1 2008 14/11/2008 22:44:00 25 125 0:32 559374 4277303
187 Deolinda 1 2008 14/11/2008 23:13:00 25 125 0:29 559384 4277371
188 Deolinda 1 2008 14/11/2008 23:46:00 25 125 0:33 559483 4277445
189 Deolinda 1 2008 15/11/2008 0:15:00 25 125 0:29 559279 4276912
190 Deolinda 1 2008 15/11/2008 0:46:00 25 125 0:31 559469 4277017
191 Deolinda 1 2008 15/11/2008 1:14:00 25 125 0:28 559621 4277064
192 Deolinda 1 2008 15/11/2008 2:06:00 25 125 0:52 559509 4276631
193 Deolinda 1 2008 26/11/2008 21:02:00 26 126 18:56 558789 4275543
194 Deolinda 1 2008 26/11/2008 21:35:00 26 126 0:33 558826 4275403
195 Deolinda 1 2008 26/11/2008 22:04:00 26 126 0:29 558712 4275401
196 Deolinda 1 2008 26/11/2008 22:35:00 26 126 0:31 558759 4275378
197 Deolinda 1 2008 26/11/2008 23:25:00 26 126 0:50 559252 4275808
198 Deolinda 1 2008 27/11/2008 0:00:00 26 126 0:35 560048 4276046
199 Deolinda 1 2008 27/11/2008 0:33:00 26 126 0:33 557248 4275626
200 Deolinda 1 2008 27/11/2008 2:25:00 26 126 1:52 559334 4276588
201 Deolinda 1 2008 27/11/2008 2:51:00 26 126 0:26 559337 4276558
202 Deolinda 1 2008 06/12/2008 23:48:00 27 127 20:57 560239 4276249
203 Deolinda 1 2008 07/12/2008 0:53:00 27 127 1:05 559674 4276157
204 Deolinda 1 2008 07/12/2008 19:46:00 28 128 18:53 557190 4276749
205 Deolinda 1 2008 07/12/2008 20:14:00 28 128 0:28 557190 4276749

Clément Calenge-2 wrote:

I am not sure, without the code describing what has been done...
However, it seems that one of the two smoothing parameters of kernelbb
are too large...
Probably sig1, actually, given that similar peaks are located with the
classical kernelUD. This short simulation illustrates the behavior:

## simulates a Brownian motion:
move <- simm.brown( seq(1,1000000, length=100) )

## show the trajectory:
plot(move)

## Use a too large sig1 for the estimation
## of the brownian bridge kernel:
ku <- kernelbb(move, sig1=500, sig2=50)
image(ku[[1]]$UD)
contour(getvolumeUD(ku)[[1]]$UD, levels=95, add=TRUE)

## The problem could be solved by diminishing sig1
ku <- kernelbb(move, sig1=5, sig2=50)
image(ku[[1]]$UD)
contour(getvolumeUD(ku)[[1]]$UD, levels=95, add=TRUE)

Did you use liker to find the value of lik1?
Regards,

Clément Calenge.

Fernucht wrote:
> Greetings,
>
> My question might be very simple: when using the Brownian Bridge
> (adehabitat) method to define the home ranges, the command getvolumeUD
> (lev=95) gives me a huge area, impossible to be true. Only if I restrict to
> ~lev=35 in getvolumeUD, I get a close estimate to classic kernel method
> (kernelUD).
>
> As you know, in the Horne et al. 2007 paper, top pag.4 , they compare both
> methods, and in both figures it's represented the 99% contour, so it
> shouldn't be because of the method. Has this happened to anyone of you?
>
> Thanks
>
> I send you an image comparing both methods:
> http://old.nabble.com/file/p26335986/example.jpg
>

--
Clément CALENGE
Cellule d'appui à l'analyse de données
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. (33) 01.30.46.54.14

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

Re: Brownian Bridge home range in Adehabitat - getvolumeUD issue

2009-11-13T07:46:12Z

I am not sure, without the code describing what has been done...
However, it seems that one of the two smoothing parameters of kernelbb
are too large...
Probably sig1, actually, given that similar peaks are located with the
classical kernelUD. This short simulation illustrates the behavior:

## simulates a Brownian motion:
move <- simm.brown( seq(1,1000000, length=100) )

## show the trajectory:
plot(move)

## Use a too large sig1 for the estimation
## of the brownian bridge kernel:
ku <- kernelbb(move, sig1=500, sig2=50)
image(ku[[1]]$UD)
contour(getvolumeUD(ku)[[1]]$UD, levels=95, add=TRUE)

## The problem could be solved by diminishing sig1
ku <- kernelbb(move, sig1=5, sig2=50)
image(ku[[1]]$UD)
contour(getvolumeUD(ku)[[1]]$UD, levels=95, add=TRUE)

Did you use liker to find the value of lik1?
Regards,

Clément Calenge.

Fernucht wrote:

> Greetings,
>
> My question might be very simple: when using the Brownian Bridge
> (adehabitat) method to define the home ranges, the command getvolumeUD
> (lev=95) gives me a huge area, impossible to be true. Only if I restrict to
> ~lev=35 in getvolumeUD, I get a close estimate to classic kernel method
> (kernelUD).
>
> As you know, in the Horne et al. 2007 paper, top pag.4 , they compare both
> methods, and in both figures it's represented the 99% contour, so it
> shouldn't be because of the method. Has this happened to anyone of you?
>
> Thanks
>
> I send you an image comparing both methods:
> http://old.nabble.com/file/p26335986/example.jpg
>

--
Clément CALENGE
Cellule d'appui à l'analyse de données
Office national de la chasse et de la faune sauvage
Saint Benoist - 78610 Auffargis
tel. (33) 01.30.46.54.14

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

Brownian Bridge home range in Adehabitat - getvolumeUD issue

2009-11-13T04:39:11Z

Greetings,

My question might be very simple: when using the Brownian Bridge (adehabitat) method to define the home ranges, the command getvolumeUD (lev=95) gives me a huge area, impossible to be true. Only if I restrict to ~lev=35 in getvolumeUD, I get a close estimate to classic kernel method (kernelUD).

As you know, in the Horne et al. 2007 paper, top pag.4 , they compare both methods, and in both figures it's represented the 99% contour, so it shouldn't be because of the method. Has this happened to anyone of you?

Thanks

I send you an image comparing both methods:

Re: [Qgis-user] Ecological toolbox for QGIS - collecting ideas

2009-11-10T09:23:43Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all, and sorry for top and cross posting,

first of all, thanks for feedback and enthusiasm about the topic.
I've tried to collect in this wiki page [0] what came up in the thread,
and I'm looking forward for more contribution!

best regards,
Anne

[0] http://www.qgis.org/wiki/Ecology_Tools

Rainer M Krug ha scritto:

> On Sun, Nov 8, 2009 at 10:00 PM, Micha Silver <micha@...> wrote:
>
>> Anne Ghisla wrote:
>>
>>> Hi all, and sorry for cross-posting,
>>>
>>> during QGIS hackfest the idea of an ecological toolbox has popped up,
>>> thanks mainly to Johannes Signer.
>>> Among currently available standalone bundles, we thought about Hawth's
>>> tools [0] and some other Arc* plugins; other tools, like Conefar [1]
>>> and Circuitscape [2], are dedicated GIS clones and could not cover all
>>> analysis requirements, therefore obliging the user to switch among
>>> different programs.
>>> We'd like to ask ecology researchers, teachers and students what are
>>> the most common analyses you run, and if you'd like to have the
>>> related tools available for QGIS in a toolbox just like for example
>>> GRASS toolbox.
>>>
>>>
> I think this is a brilliant idea. A friend of mine is using Diva GIS for
> teaching, as it has a very good toolbox for ecological GIS work (according
> to him - I haven't used it yet) - but Diva is one reason, why he still needs
> Windows in a virtual machine.
>
> So it might be an option, to look into Diva to see what they have, and
> include those into QGIS.
>
> I like that idea of ecological analysis tools that much, that I would
> suggest an approach which enables the use of these tools from other programs
> as well (I am thinking in particular about R and GRASS). I guess, it would
> be more work, but I think it would be worth.
>
> A set of tools for spatial ecological analysis - like GDAL and OGR are for
> raster and vectors IO - that would be BRILLIANT.
>
> Rainer
>
>
>
>
>> I'd like to see a simple set of tools for patch analysis: patch density,
>> perimeter to area ratio, std. dev of patch sizes etc. Similar to what's
>> available from the GRASS r.le.* modules.
>> Then that might lead to tools for connectivity analysis, like the
>> circuitscape example you sited.
>> Regards,
>> Micha
>>
>> Thanks for feedback, and feel free to forward the message to relevant
>>> people and mailing lists!
>>> Anne Ghisla
>>>
>>> [0] http://www.spatialecology.com/htools/tooldesc.php
>>> [1] http://www.conefor.org/
>>> [2] http://www.circuitscape.org/Circuitscape/Welcome.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkr5oZ4ACgkQzZ3g4YwFFgbKegCeK5zG0SQjgI+PGavZ5DuGNrh2
7OgAn1EV5qXOIIaADftp0T3NPYo/hdCV
=k6lE
-----END PGP SIGNATURE-----
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

Re: Home Range Plugin - Projection and map units

2009-09-18T02:36:25Z

In un messaggio del Friday 18 September 2009, Max Ringler ha scritto:

> Are there any known issues with projections and/or map units and the home
> range plugin?
>
> When running MCP and kernel analyses, the original point coordinates of my
> data seem to get rounded to the next lower meters (decimal digits are
> discarded). Accordingly the MCP shapes are "somewhat" correct in shape, but
> positioned way off the orignal points - same for kernels.
>
> My project has meters as map unit and the projects and shapefiles
> projection is +proj=utm +zone=22 +ellps=WGS84 +datum=WGS84 +units=m
> +no_defs.
>

AFAIK (Clement, any feedback?), since the home range plugin uses adehabitat as
backend, there should be no issues both with projection (adehabitat is
somewhat of "projection-agnostic") and "decimals".

Keep in mind that, since you're working with a metric CRS (i.e. UTM zone 22)
the figures are in meters, and the "decimals" you're losing are in fact
_centimeters_, and normally (either with VHF or GPS) a spatial resolution
level at the tenth of meters is normally accepted.
Such a precision (down to the centimeter) should be necessary if you're
working on small species (insects? shrews?), but normally one doesn't look at
decimals in a metric CRS...

About the "way off" effect... I smell datum shift problems. Are you
visualizing the results in some GIS that handles projection poorly or there is
some flaw in how you specify your CRS?

Hope this Helps

--
Cum tacent, clamant. When they are silent, they shout. -Cicero
-----------------------------------------------------------
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 +39 0332421538 fax +39 0332421446
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://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

signature.asc (204 bytes) Download Attachment

Home Range Plugin - Projection, map units

2009-09-18T02:18:13Z

Are there any known issues with projections and/or map units and the home range plugin?

When running MCP and kernel analyses, the original point coordinates of my data seem to get rounded to the next lower meters (decimal digits are discarded). Accordingly the MCP shapes are "somewhat" correct in shape, but positioned way off the orignal points - same for kernels.

My project has meters as map unit and the projects and shapefiles projection is +proj=utm +zone=22 +ellps=WGS84 +datum=WGS84 +units=m +no_defs.

Please contact me if you want the shapefiles to check.

Kind regards

Max Ringler
Department of Evolutionary Biology
University of Vienna

OT? MultiBuffer, Intersect and Dissolve Tool in R?

2009-09-18T00:22:21Z

In un messaggio del Friday 18 September 2009, Breitbach, Nils ha scritto:
> Dear Community,
>
> I am looking for a R-function (or if there is none directly in R in GRASS
> or QGIS) that works just like the MulitBuffer Tool from the Toolbox in
> ESRIs ArcGIS. Furthermore I would like to use an equivalent to the ArcGIS
> Tools Intersect and Dissolve. Since I am just starting to do geographical
> analyses with R I just do not know where to look for equivalent functions
> in R (Grass or QGIS).

If what you need is some tool "to do topological overlay", perhaps the best
way is to use either GRASS (v.overlay & family) or QGis fTools plugin (very
very similar to the good old "swiss army knife" XTools for ArcView GIS[1]).

If you need to work interactively, IMHO QGis (and its GRASS plugin) is the
best tool. Should you prefer an easily programmable tools, maybe GRASS along
with some bash scripting will do.

Of course, these are my 2 Eurocents...

[1] Rats! I mentioned ESRI software... My apologies ot the list, but who needs
ESRI anymore? :)

--
E' meglio essere stimati che sovrastimati.
-- Dalle Leggi di Murphy sul Sesso
-----------------------------------------------------------
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 +39 0332421538 fax +39 0332421446
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://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

signature.asc (204 bytes) Download Attachment

Re: radiotracking data advice

2009-09-15T09:10:08Z

In un messaggio del Tuesday 15 September 2009, andrea santangeli ha scritto:

> Hi all,
>
> my name is Andrea Santangeli and I´m doing a PhD in Finland on the
> Tengmalm´s owl. Hi have a lot of radiotracking data to deal with and am
> asking for some practical advice: 1) extract the real position
> (coordinates) of the owl from one observer position (in geogr. coord of the
> type: lat: 62.98851 and long: 23.06411), distance and bearing (degrees
> from 0 to 360), either with a fomula to apply in excel or with another
> program; 2) extract the real position (coordinates) of the owl from two
> observer positions (in geogr. coord of the type: lat: 62.98851 and long:
> 23.06411), and bearing (degrees from 0 to 360), basically a triangulation
> issue here.

Hi Andrea
first, perhaps diong something to your point locations - such as projecting
them into a cartesian coordinate space - should be a first pass. To accomplish
that, any GIS software will do, ranging from Quantum GIS to R geographical
information system functions.

Once you have your location + bearing + distance or pair of location +
bearings, then is simple trigonometry.

The second case is covered by the code in the triang.R script (still in
development, look for the publicly available repository at
svn://home.prea.net/svn), the first is a trivial conversion from polar to
cartesian systems, again, you can find something in triang.R sourcecode.

By the way, choose your number crunching tool (i.e. a true GIS or a GIS-
capable data analysis environment) depending on what you have to do _next_,
i.e. once your location + bearing + distance or triangulation have been
transformed into owls positions... what happens? Home range calculations? (=>
R) Buffering and land use clip? ( => QGis with R in the backoffice).

Hope this help!

--
You plan things that you do not even attempt because of your extreme caution.
-----------------------------------------------------------
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 +39 0332421538 fax +39 0332421446
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://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

signature.asc (204 bytes) Download Attachment

Intersection of two coordinates (triangulation)

2009-09-09T10:47:27Z

Hi Community,

I am new to this forum and I am starting to analyse my telemetry data trying to be independent from commercial software. So far all I wanted to do was possible with R. Now I am looking for a function that is able to do triangulation. The structure of my data is as follows:

- two consecutive rows with coordinates (lat and long in separate columns; at the moment in WGS1984 and decimal degrees) and in a further column a corresponding direction in degrees from 0 to 359
- each of the two consecutive rows has an identifier (T1 and T2)

I now want to calculate the intersection point of these two consecutive rows (T1 and T2) getting one coordinate in long and lat of the intersection point in WGS1984 and decimal degrees.

Do you know of any function/package that is able to perform such a triangulation or at least one that does a similar operation?

Thank you!

Nils

Home Range plugin for qgis

2009-07-24T04:45:33Z

Now updated on the server - enjoy!
Thanks Anne.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

Re: Clipping area from home range estimates

2009-07-13T00:49:17Z

In un messaggio del Sunday 12 July 2009, Tim Clark ha scritto:

> Dear List,
>
> I am trying to use Adehabitat to analyze the home range and movement
> patterns of fish (manta rays, sharks, and various species of reef fish) in
> Hawaii, but have not found a way to clip land area out of the animals home
> range. Most of the fish I study stay fairly close to shore, moving along a
> sinuous coastline. I have used adehabitat to estimate their home range (I
> am mostly interested in kernel HR's), but need to either limit the
> calculations to only include water areas during the calculation or clip out
> the land area after the kernel has been calculated. Is there a way to use
> a shapefile or other projected map file to either limit the kernel or to
> clip out the area post-processing? I am fairly new to R and adehabitat,
> and am working in Windows.

First, Paolo's suggestion is perhaps the straightforward way: usually, home
range polygons are clipped in a post-processing phase.

An interesting way I'm testing is to exploit the "grid=" parameter in kernelUD
(and similar commands).
In fact, since we often have to deal with batch home range calculation on
several animals scattered on wide study areas, the classical 40x40 squares
grid is too coarse, resulting in poorly defined polygons.
We overcome this limitation first building a grid (that is a raster) with a
cell size adequate to the species under study (say, 50x50 m for snowshoe hare
or bats, 100 to 250 m for ungulates) and supplying that grid (loaded into R
via import.asc) to the kernelUD command.

On these premises, my suggestion is to prepare a grid already clipped, in your
case for land against sea. We're trying such a 'trick' to exclude some small
Alpine lakes in home range calculations on our snowshoe hare dataset.

Hope This Helps

--
Fallo solamente col migliore.
-- Dalle Leggi di Murphy sul Sesso
-----------------------------------------------------------
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 +39 0332421538 fax +39 0332421446
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://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

signature.asc (204 bytes) Download Attachment

Re: Averaging consecutive locations closer than GPS error

2009-07-02T06:37:18Z

In un messaggio del Thursday 02 July 2009, Roland Kays ha scritto:
> Hi, I'm working on some GPS data at 15min intervals. I'd like to take any
> consecutive locations that are closer than GPS error (say 25m) and average
> them together to get one location for all time steps. For example, when an
> animal is resting in a tree for an hour the locations might still bounce
> around due to GPS error.
>
> I just ran through the adehabitat trajectory tools and didn't see anything
> in there - any other suggestions? thanks

Two suggestions:
1) given that you have GPS data, a first solution could be to process
incrementally time-adjacent fixes (say, in a while loop) and once a given
threshold is reached (e.g. all the points examined are well under 15 m, or all
the point fall insida a reasonably small time slot, or both...) do the
averaging.
I'm using such an approach (the while loop point accumulator, I mean) to
preprocess data for a triangulation module we're deveolping here, if you want
to have a peek at the code, you can access the svn repository at
svn://home.prea.net/svn/triang/trunk

2) adehabitat ltraj class can be used to do some trajectory resampling: if
you've managed to convert your data into a ltraj it should be easy to extract
(resampling) some already averaged pseudo-locations

As you can see, I'm strongly biased towards R at present... like Python, it
just works (and you _can_ go back to Pytho+Rpy to build some QGis interfaces).

HTH

--
"I will make no bargains with terrorist hardware."
-- Peter da Silva
-----------------------------------------------------------
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 +39 0332421538 fax +39 0332421446
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://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

signature.asc (204 bytes) Download Attachment

randomHR: minor improvement

2009-07-01T09:27:14Z

Hi all.
The plugin is now improved (version 0.2.1): it prints not only the
overlap matrix for all the simulations, but also for the observed HR.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

new site

2009-06-09T22:54:58Z

Hi all.
We have now a new web site for faunalia (www.faunalia.it).
In theory if you connect with a browser set to any language except
Italian you should get an English home page.
Please check that everything is ok with http://www.faunalia.it/en/animove
Your suggestions will be much appreciated.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

Re: overlap

2009-04-27T04:23:42Z

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. (33) 01.30.46.54.14
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

Re: overlap

2009-04-25T08:15:43Z

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

Re: overlap

2009-04-25T08:15:43Z

##Generic HROverlap function

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

Re: overlap

2009-04-24T17:23:45Z

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

potentially interesting paper

2009-04-14T22:54:30Z

http://www.publish.csiro.au/nid/144/paper/WR08032.htm
all the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

[Fwd: Re: [Qgis-user] HomeRange plugin updated]

2009-04-10T02:27:16Z

-------- Messaggio Originale --------
Oggetto: Re: [Qgis-user] HomeRange plugin updated
Data: Fri, 10 Apr 2009 11:26:18 +0200
Da: Anne Ghisla <a.ghisla@...>
A: John C. Tull <john.tull@...>
CC: cavallini@..., qgis-user <qgis-user@...>
Referenze: <49DC4439.5060700@...>
<11762C2B-A9B2-4D8D-A50F-E5B29C0B5A84@...>
<49DDB26E.1030108@...>
<055EEDAE-0298-4A19-8C2A-B31B4F3BB664@...>

John C. Tull ha scritto:
> In addition to the last error, when I quit and restart qgis after
> loading and installing the HomeRange plugin, I get this error during
> startup. Afterwards, the HomeRange plugin cannot be loaded:
>
> Couldn't load plugin "HomeRange_plugin" from
[snip]
> Traceback (most recent call last):
[snip]
> File "/Library/Python/2.5/site-packages/rpy2/rinterface/__init__.py",
> line 6, in
> R_HOME = os.popen("R RHOME").readlines()
> IOError: [Errno 4] Interrupted system call

The same error is given by manageR [0], therefore I guess it is a rpy2
issue.
You can try the function that returns this error alone in a Python
shell. On my WinXp machine it returns the correct path to R installation.
If it succeeds, try in the Python shell each function of the traceback
stepping backwards.
Consider also filling a ticket on RPy2 bugtracker on SourceForge [1].

thank you for testing and best regards,

Anne

[0] http://www.mail-archive.com/qgis-user@.../msg02601.html
[1] http://sourceforge.net/tracker/?atid=453021&group_id=48422&func=browse

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

[Fwd: Re: [Qgis-user] HomeRange plugin updated]

2009-04-10T02:26:59Z

-------- Messaggio Originale --------
Oggetto: Re: [Qgis-user] HomeRange plugin updated
Data: Fri, 10 Apr 2009 10:58:39 +0200
Da: Anne Ghisla <a.ghisla@...>
A: John C. Tull <john.tull@...>
CC: cavallini@..., qgis-user <qgis-user@...>,
Animal Movement <animov@...>
Referenze: <49DC4439.5060700@...>
<11762C2B-A9B2-4D8D-A50F-E5B29C0B5A84@...>
<49DDB26E.1030108@...>
<BF6A87C1-D5FF-4D9E-857E-5AC39008AF16@...>

John C. Tull ha scritto:
> Here is an error I get now using a shapefile with a set of points
> creating home ranges on field 'ID'. There is only one ID for all the
> points, so it should create a single home range estimate for each method.
>
> An error has occured while executing Python code:
>
> Traceback (most recent call last):
[cut]
> RRuntimeError: Error in writeOGR(khr.polygons, dir, name, "ESRI
> Shapefile") :
> GDAL Error 1: Failed to create file .shp file.

Bad thing. GDAL is the dependency I know (and care) less, assuming it
works independently of HR_plugin installation.

I would ask if you can run a pure R test, to check if the error comes
out from rgdal package or GDAL itself, like this one:

cities <- readOGR(system.file("vectors",package="rgdal")[1],"cities")
writeOGR(cities,tempdir(),"cities",driver="ESRIShapefile")

and see if it raises a similar error.
If the test above succeeds, you can comment line 102 of
HRplugin_algorithm.py and uncomment line 101, choosing suitable dir
parameter.

I'll look for more details about this issue - moreover, please fill a
ticket on AniMove Trac [0] if the problem persists.

thanks for testing,

Anne

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

[Fwd: Re: [Qgis-user] HomeRange plugin updated]

2009-04-10T02:01:10Z

-------- Messaggio Originale --------
Oggetto: Re: [Qgis-user] HomeRange plugin updated
Data: Thu, 09 Apr 2009 10:31:42 +0200
Da: Anne Ghisla <a.ghisla@...>
A: John C. Tull <john.tull@...>
CC: cavallini@..., qgis-user <qgis-user@...>,
Animal Movement <animov@...>
Referenze: <49DC4439.5060700@...>
<11762C2B-A9B2-4D8D-A50F-E5B29C0B5A84@...>

John C. Tull ha scritto:
> I've worked out the OS X linking issues. When I run on a modest dataset,
> I now receive the following error. I'd be happy to test with another
> shapefile of points if it will help.
>
> An error has occured while executing Python code:
>
> Traceback (most recent call last):
[cut]
> RRuntimeError: Error in kernelUD(dd[, c("X", "Y")], dd[, "ID"], h =
> "LSCV", grid = grid) :
> At least 5 relocations are required to fit an home range

this is a normal R error - to compute homeranges, subsets of points
determined by the attribute in the colum you chose (for esample animal
ID, month, year...) must contain at least 5 points. Even one subset with
<5 points raises this error.
I suggest to group points by another column.
On my side, I will change the code to avoid Python error, and raise a
info window instead.

many thanks and best regards,

Anne

> _______________________________________________
> Qgis-user mailing list
> Qgis-user@...
> http://lists.osgeo.org/mailman/listinfo/qgis-user

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

[Fwd: Re: [Qgis-user] HomeRange plugin updated]

2009-04-10T02:00:50Z

-------- Messaggio Originale --------
Oggetto: Re: [Qgis-user] HomeRange plugin updated
Data: Thu, 09 Apr 2009 10:22:07 +0200
Da: Anne Ghisla <a.ghisla@...>
A: John C. Tull <john.tull@...>
CC: cavallini@..., qgis-user <qgis-user@...>,
Animal Movement <animov@...>
Referenze: <49DC4439.5060700@...>
<63DB487A-B74F-4264-BF74-9DAFBB621C83@...>
<49DCCC8B.6000103@...> <C727745F-F453-4ABD-948D-ADA1FDE23C0A@...>

John C. Tull ha scritto:
> This might be related to OS X weirdness with library linking. I can
> reproduce this problem in ftools also. I'll report back if I it working.

thanks for testing. I can send you previous vesion of the plugin to
check if it works - but I haven't changed a line of the code that raises
the error.
let us know further details of this issue.

best regards,

Anne

> On Apr 8, 2009, at 9:10 AM, Paolo Cavallini wrote:
>
>> John C. Tull ha scritto:
>>> The plugin fails to recognize loaded point layers on OS X with rpy2, R
>>> 2.8.1 and qt-4.5.
>>
>> Anne: should I revert to previous version, or can you check this?
>> All the best.
>> --
>> Paolo Cavallini: http://www.faunalia.it/pc
>> _______________________________________________
>> Qgis-user mailing list
>> Qgis-user@...
>> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user@...
> http://lists.osgeo.org/mailman/listinfo/qgis-user

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

Re: [Qgis-user] HomeRange plugin updated

2009-04-08T09:10:51Z

John C. Tull ha scritto:
> The plugin fails to recognize loaded point layers on OS X with rpy2, R
> 2.8.1 and qt-4.5.

Anne: should I revert to previous version, or cau you check this?
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

HomeRange plugin updated

2009-04-07T23:29:13Z

Hi all.
Thanks to Anne, the HomeRange plugin is now updated. It should show off
automagically the next time you open QGIS.
All the best.
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

KernelUD error or R code error ... :S

2009-03-24T05:59:14Z

Hello.
I've started recently using the adehabitat package with R 2.8.1 and i've been facing a strange error.

My main goal is to calculate kernelUD from shapefiles and send the results as a surface/shapefile so using this shapefile with random points here (http://www.yousendit.com/transfer.php?action=batch_download&batch_id=UmNMMWZPK3gwMEd4dnc9PQ) i've been trying to run this code and i get an error on the last line.

The code is:

## load lbs
library(adehabitat)
library(shapefiles)

## load shapefile
shpobj <- read.shp("C:/Temp/2008.shp")
## convert it to simple X,Y
cds <- convert.to.simple(shpobj)

## get assure the XY coordinates are in here
xy <- cds[,1:2]

## run kernelud
hr<-kernelUD(xy, h="LSCV", grid=100)
------------> "Error in df[, 1] : incorrect number of dimensions" <------------

Any help on this would be appreciated.

Regards.

Re: burst function in liker and kernelbb

2009-03-19T07:13:11Z

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

Re: burst function in liker and kernelbb

2009-03-19T06:31:40Z

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

Re: burst function in liker and kernelbb

2009-03-18T10:40:35Z

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

Re: [AniMove] #11: resulting shapefiles not added to Canvas

2009-03-10T08:16:02Z

AniMove ha scritto:

> #11: resulting shapefiles not added to Canvas
> -------------------------------+--------------------------------------------
> Reporter: anne | Owner: anne
> Type: defect | Status: closed
> Priority: minor | Milestone:
> Component: HomeRange_plugin | Version: 1.0
> Resolution: fixed | Keywords: shapefiles Canvas
> -------------------------------+--------------------------------------------
> Changes (by anne):
>
> * status: new => closed
> * resolution: => fixed
>
>
> Comment:
>
> resolved in r145 of SVN and version 1.2.5 on Faunalia repo.

Fixed on the repo now. We are switching server just now, so due to DNS
propagation some of you may still see the old version for the next 24 h.
Please let us know if everything is ok.
All the best.
pc
--

Ok, it should work either way now.
Please let us know of any problem.
pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

Re: [AniMove] #11: resulting shapefiles not added to Canvas

2009-03-10T07:26:29Z

AniMove ha scritto:

Fixed on the repo now. We are switching server just now, so due to DNS
propagation some of you may still see the old version for the next 24 h.
Please let us know if everything is ok.
All the best.
pc
--
Paolo Cavallini: http://www.faunalia.it/pc
_______________________________________________
AniMov mailing list
AniMov@...
http://lists.faunalia.it/cgi-bin/mailman/listinfo/animov

Re: burst function in liker and kernelbb

2009-03-04T15:24:23Z

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

Re: burst function in liker and kernelbb

2009-03-04T06:40:05Z

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. (33) 01.30.46.54.14
_______________________________________________
AniMov mailing list
AniMov@...
http://www.faunalia.com/cgi-bin/mailman/listinfo/animov