What I need to do for GNP data

[klg-2016]

I'm just going to keep track of what I need to do for GNP data here.

It seems like the input detection/non-detection data belongs in a spreadsheet with a row for each site and a column for each day. So it'll be ~120 columns/days for each season (assuming we keep August-November late dry season) times the number of seasons (= years) we have. And I think it belongs in that order: day one of season one across to the last day of the last season.

the siteCovs are going to be things like distance to lake, termite mound density and tree cover (I think). Unless we think that those things are changing notably during the years we're planning to examine?

I don't understand what GNP yearlySiteCovs (Data frame containing covariates at the site-year level) and obsCovs (Data frame of covariates that vary within site-year-observation level) will be yet. (This relates to another issue, but I want to have the info here too)

numPrimary (Number of primary time periods (seasons in the multiseason model)) will be the number of seasons we use. So if we look at 2016-2019, it will be 4.

I also need to figure out what the different inputs are to colext/how to decide what formulas I think are appropriate for each

[klg-2016]

another colext example (http://www.seec.uct.ac.za/dynamic-occupancy-models) has the yearlySiteCovs as a matrix with the years listed, like in the example I'm working through. (so 2016 2017 2018 2019 as a row, repeated for every site)

[klg-2016]

Where would I put the wild dog and/or lion data--what type of variable? (even just presence/absence)

[klg-2016]

Do I need to convert dates to Julian dates?

[kaitlyngaynor]

I don't think you need to mess with Julian dates... Kendall didn't at all and his code seems to be working fine. I haven't gotten to that part of running yours yet, though

[klg-2016]

OK! I kind of assumed that the reason for doing it was to include the progression of time in the model, but if Kendall doesn't do it then maybe the model is able to get the necessary info from dates in other formats... (I'm not sure if that's right, I was just trying to come up with something that made sense for converting to Julian)

[kaitlyngaynor]

Oh interesting. Maybe you do need year in yearlySiteCovs like the two examples that you link to, to account for progression of time...

But I don't think the actual day really matters, though. It's dynamic year-to-year, but not day-to-day. Occupancy probability is static for a given year (as I understand it)

[klg-2016]

That's how I understand it as well. I wonder why they used Julian, then?

[kaitlyngaynor]

Were they perhaps using day as an observation-level covariate?

[klg-2016]

yes! obsCovs=list(date=DATE), #sets obsCovs (covariates that vary within site-year-observation level) to DATE

does that make it make sense to you?

[klg-2016]

(my notation after the code)

[kaitlyngaynor]

Oooh okay. Yes, so they WERE modeling dynamic occupancy day-to-day—Julian day was a covariate that ticked up slowly with every sampling event/observation. I don't think we need/want to do this for our purposes, since we are interested in interannual changes in extinction/colonization, but not intRAannual changes. We have already restricted our sampling period to a given season, so we are minimizing seasonal confounds.

[klg-2016]

Okay! That's starting to make more sense. For their data, they only have 2-3 observations per season/year, as opposed to our 122, so that makes more sense.

[klg-2016]

Hahahahah that means there's a bunch of code in my script that's completely useless >.< I did figure out how to convert mdy to Julian, though, for future projects!

[kaitlyngaynor]

Haha, every bit of coding is a learning experience! Did you use lubridate? I've recently started to use it for date stuff since it seems pretty good (I had previously just use the base R functions) https://lubridate.tidyverse.org/

[klg-2016]

lubridate looks very useful--I used a function called "julian", which I guess was just a base R function? I don't think I installed a package for it

[kaitlyngaynor]

Yeah, I think julian() is base. If you are ever curious, if you look at the help file for a function ?julian the name of the package will be in brackets at the top left of the file—in this case {base}

[kaitlyngaynor]

Will keep this issue open until you remove that bit of code but I think we can proceed without messing with Julian date (nice work figuring it out, though, ha)

[klg-2016]

Nice! I might have noticed the package name before but I didn't realize you could check like that--thank you!

[klg-2016]

removed the Julian code, going to keep this issue open as a reference for overall data prep