Movement between grids

[Bryan Hamilton]

My analyses are going pretty well for the most part. I've ran into a couple hitches that I wanted to share here.

I'm using sampling grids as a group to get grid specific density estimates by year. In other words, I'm, trying estimate density at each sampling location. This works really well except when individuals have the audacity to move between grids. Some of these inter-grid movements are real. Marked individuals were recaptured on another grid. Some of them are the result of tag redundancy.

So two questions here:

1. When a marked individual is recaptured on another grid (using grid as a group to get density estimates for each grid), the models break down and return an estimate of 'NA'. I don't think the models can handle movement between grids when grid is a group. If this is true, what should I do? Would it be OK to relabel the 'offending' individuals to remove the intergrid movements from the model?

Code: Select all

secr.fit(CH, model = list(D~g, g0~1, sigma~1) ,groups=c('Loc_Name'),buffer = 150,
                    trace = FALSE,start = list(D=0.5, g0=0.2, sigma=25) ) # null model

2. I'm using 'plot.capthist' with tracks=T to identify individuals that move between grids. This is a big help to identify the locations where the movements occur. If I figure out how to post images here I can give an example.Beyond this, is there a way to select individuals that move between grids? I don't really expect a detailed answer here. Just some general advice.

Thank you.

[murray.efford]

I think using groups to get grid-specific density estimates is likely to fail. Groups are for permanent population classes such as males and females. When you fit a grouped model you mean that all individuals in each group follow the overall population model i.e. they are located at random across the region. However by defining group by location you deliberately violate this assumption: all animals in one group live in a selected fraction of the landscape, and density is inferred to be mysteriously low (because of the absence of animals from this group on other grids). This would not apply if you aligned all the grids to have the same coordinates and trap numbering - then a grouped analysis might work as you expect. An individual that moved between grids would then just just show as an odd within-grid movement.

The better way to get grid-specific estimates when between-grid movements are rare is to define grids as sessions. There is no need to reassign the ID of an individual caught on two grids as each grid is separate in the analysis.

On your second question - The Windows program Density lets you click on extreme movements in a plot within a session to find out who made them, and it's the way I usually check these cases.

Otherwise the 'moves' function in secr gives you the detail. For instance, you can find animals with movements longer than 60 metres with

Code: Select all

sapply(moves(captdata), function(x) any(x>60))
    1   102   104   114   119   124   128   133   138   149   156   167   168
FALSE FALSE  TRUE  TRUE  TRUE FALSE  TRUE FALSE FALSE FALSE FALSE FALSE FALSE
etc.


Murray

[Bryan Hamilton]

The density estimates with location as a group did seem low. For example, some of the density estimates were around 0.1/hectare when I had captured 8 animals on the approximately 1 hectare grid.

Using location as a group, I could get unique estimates of D for each grid. Using location as a session, I get the same density estimate for each grid. Another issue is the number of detectors. Each grid consists of 49 traps but each session notes that there are 539 detectors.

Code: Select all

secr004 <- secr.fit(CH, model = list(D~1, g0~1, sigma~1) ,buffer = 150,
                    trace = FALSE,start = list(D=1, g0=0.2, sigma=25) ) # null model

The density estimates are still too low. There were 16 individuals captures on grid 09 and 8 on grid 10.

Code: Select all

 session = HabRest_Mam_009
       link   estimate SE.estimate        lcl        ucl
D       log  0.4326721  0.04699998  0.3499180  0.5349972
g0    logit  0.1850765  0.01829253  0.1518662  0.2236343
sigma   log 20.8834761  1.05666343 18.9130325 23.0592093

 session = HabRest_Mam_010
       link   estimate SE.estimate        lcl        ucl
D       log  0.4326721  0.04699998  0.3499180  0.5349972
g0    logit  0.1850765  0.01829253  0.1518662  0.2236343
sigma   log 20.8834761  1.05666343 18.9130325 23.0592093

Code: Select all

$HabRest_Mam_008
Object class      capthist
Detector type     single
Detector number   539
Average spacing   15 m
x-range           739320 741443 m
y-range           4321526 4322499 m
Counts by occasion
                    1   2   3   4 Total
n                  12  15  15  13    55
u                  12   4   2   2    20
f                   6   2   3   9    20
M(t+1)             12  16  18  20    20
losses              0   0   0   0     0
detections         12  15  15  13    55
detectors visited  12  15  15  13    55
detectors used    539 539 539 539  2156


Thanks for the other tips. Those will be helpful. I've found a few redundant tags but most of the between grid movements are real.

[murray.efford]

I think you need to split the traps object so there is a separate layout for each grid - at present it's assuming the non-focal traps were set but empty for each focal session, if that makes sense.

How best to get there from where you are depends on how you built 'CH'. Basically traps(CH) needs to be a multi-session object that you could have formed originally by having a separate file for each grid. Possibly this will work

Code: Select all

sessioncode <- rep(1:11, each = 49)
tmptraps <- split(traps(CH)[[1]], sessioncode)  ## a list, one component per grid
for (i in 1:11) traps(CH[[i]]) <- tmptraps[[i]]


where sessioncode is a vector that takes a different value for each session. I'm assuming the 'traps' for the first session contains all the locations, so we can split that to provide the location data for all the other sessions. Replacing parts of a multi-session capthist object is not as easy as it should be, hence the need for the 'for' loop here.
Murray

[Bryan Hamilton]

Thank you. I'll give this a try.

I think some the reasons my models have failed is that there is redundancy in the capture occasion. For example two grids were ran during separate weeks An individual moved between the grids, and was captured during two different weeks but the capture occasion was '2' for each capture. Would this make the model return 'NA' values?

It seems like I need to restructure my data. The way traps are set up, there are 539 unique detectors.

Thanks again.

[Bryan Hamilton]

I think you need to split the traps object so there is a separate layout for each grid - at present it's assuming the non-focal traps were set but empty for each focal session, if that makes sense.

Does a separate layout mean I'll need to do a separate 'read.capthist' for each grid? Or can I code the detectors by the location.

Right now my trap file looks like this, with the grid the first three numbers, and the trap location the letter/number. Can we tell secr that the first 49 detectors are session 1, second 49 session 2, ect? I think this might be what you were saying with the code above.

Code: Select all

HabRest_Mam_010
           x       y
001A1 741353 4321616
001A2 741368 4321616
001A3 741383 4321616
001A4 741398 4321616
001A5 741413 4321616
001A6 741428 4321616

[murray.efford]

I think I've reached about the limit of what I can offer in the way of R support.
Murray