Multiseason site occupancy estimation

[Jeffrey]

Hello fellow members,

[dhewitt]

I had to look up photos of agile gibbon - what a cool animal. Luckkkyyyy...

Your questions:

1.) Yes, if you detected an animal in every survey of occupied patches. You should have some sense of this from looking at your encounter histories (all 111 111 and 000 000, e.g.).

2.) Not sure, but it sure looks fishy if this is a multi-season model.

3.) Can't help; I use MARK.

4.) Dunno.

5.) This is a tough topic, but a recent paper by the great Doherty sheds some light. Journal of Ornithology, EURING PROCEEDINGS, 2010, "Comparison of model building and selection strategies", Doherty, White, and Burnham [I suspect Paul will send you a copy if you don't have access.]

- Dave

[bacollier]

1) See Dave's response, only way I know that could happen is if you had a '1' (detected) for every survey occasion. If so, then modeling occupancy is likely not needed as they are apparently falling out of the trees on you as you walk by.

2) I think that looks correct, if I remember right presence does not use the diagonal structure in a multi-season model that MARK would use so Darryl or Jim will have to chip in. Why do you have 2 extra columns at end?

3) Currently Presence (last I visited with Jim) does not do any model averaging for you, so you will need to do it by hand using the full model set and the VCV matrix.

4) In the output .txt file, you will see a section labeled something like: Untransformed estimates of coefficients for covariates. Note that under the model you are using occupancy for year t+i as i goes from 1...n is a derived parameter based on Psi1, gamma, and epsilon. On your covariate values for each parameter intercept, since you ran a constant model for Psi, gamma, and epsilon, there aren't any covariates, there is only one for 'p (rainfall) and I suspect, but am not sure, that any predictions from that are based on the mean rainfall value for each occasion.

5) I suspect you can use whatever you want for a model selection approach as it does tend to vary with little consistency in the literature; the paper Dave suggested is a good one for you to read.

You might want to spend a bit of time in the help files and the literature to better familiarize yourself with where parameters and such are located and how they can be used.

Bret

[darryl]

1) do you have an estimated value of p=1 for each and every survey? With rainfall as a covariate then PRESENCE should be giving you more than 1 value. Like Dave says, if p really =1 that should be obvious from your raw data.
2) Unlike MARK, PRESENCE splits the design matrix up by parameter type. Otherwise, how you use the design matrices is very MARK-like. The design matrices you've included say that you don't have any covariates that allow first year occupancy, colonization or extinction to vary amongst sampling units (ie sites). For detection you don't have an intercept term in there which creates a very restrictive relationship that will force the regression line to go through the origin of an plot, ie you're forcing logit(p) = 0 when rainfall = 0, with logit(p) = 0 evaluating to p = 0.5. Hence, by not including the intercept you're assuming that when there's no rainfall, your detection probability is exactly 0.5. Generally you're going to want to have a column of 1's in the design matrix, or at least one 1 somewhere along each row depending how you want to interpret some of the estimates.
3) Jim Hines is starting to add some model averaging capability into PRESENCE, and it appears in the menu of the latest version, but it's still a work in progress. By hand is the main option at the moment.
4) See Bret's reply for where. You don't have an intercept term in your model for detection so you won't be able to find one. Don't understand the second part of your question, by definition intercepts relate to covariate values of 0. The real parameters that get reported use the covariates values that are in the data file.
5) Personally, with no claims its the right thing to do, if I'm thinking about using a 2-step approach then rather than having the other parameter types as simple constants, I'd make them fairly general by including the covariates of interest for those parameters. My logic is that this gives the model some flexibility in case there really is variation amongst units that wouldn't be getting represented if you just assumed the parameters were constant. If you're inappropriately assuming the other parameters are constant, then you may get misleading results for which covariates are important for detection.

[Jeffrey]

Thanks for the suggestions it really helping me a lot, thanks so much, best wishes..