search

DistanceDevelopment / spatial-workshops

Distance sampling workshop content
http://distancesampling.org/workshops/
2 stars 0 forks source link

1-process-geodata.Rmd uses the segments, but we won't have created them yet #32

Closed jjrob closed 8 years ago

jjrob commented 8 years ago

I presume that https://github.com/DistanceDevelopment/spatial-workshops/blob/master/exercises/1-process-geodata.Rmd is the first R exercise we will do, in the afternoon of the first day. In the morning of that day we will have populated Analysis.gdb with Sightings but not with Segments_Centroids yet. (That will happen the second day in the morning.) But 1-process-geodata.Rmd loads the Segments_Centroids.

We're about to chat on the phone. Let's discuss this then.

dill commented 8 years ago

As discussed yesterday I think we need to switch practicals 1 and 2 (numberwise).

I propose:

The processing geodata practical should be a case of participants hitting "Knit HTML" in RStudio if we are pushed for time, otherwise they can run the code chunk-by-chunk.

What I had not anticipated (and this is down to my own stupidity) was that there would be no covariates at this point so their exploratory plots are only x and y.

We'll have to have them re-run this to import all the data 1:15 – 2:45pm Thursday too, so they have the correct covariates before they run their multi-smooth models (so they have the covariates associated with the segment table).

Does that make sense?

jjrob commented 8 years ago

We are generally on the same page but should chat. Does 3:00 work for you? I have to leave today at 4:30.

2-detection-functions.Rmd as of 44509e7 looks good for executing Tuesday 3:00-4:30. In fact, it might be sensible to execute the very first few lines of code, through the first call to head(distdata) in the Tuesday 10:45-12:15 session. We will have just finished my slides that discuss exchanging data between ArcGIS and R. To execute that first call to readOGR would be a good way to immediately apply what we discussed. Of course, we do not necessarily need to go so far as to load up the .Rmd at that point, if you don't want to. Instead I could just have them start RStudio and type in three lines of code, e.g.

library(rgdal)
distdata <- readOGR("Analysis.gdb", layer="Sightings")
summary(distdata)

That would demonstrate that yes, we can load the points into R. Then we would break for lunch and in the afternoon pick up with the detection functions lecture and exercise, perhaps saving the discussion of .Rmd and knitr for that point.

What to do with 1-process-geodata.Rmd is more complicated. I agree it should come after 2-detection-functions.Rmd. But as we both now understand, Wednesday afternoon we have to read the sightings again in addition to the segments, and then on Thursday afternoon we have to read the segments again (to get the covariates).

RIght now 1-process-geodata.Rmd is written as kind of a one-time thing, with exploratory code etc., rather than a little utility script designed to run over and over. I think it would be best to move the exploratory part into 3-simple-dsms.Rmd and 4-advanced-dsms.Rmd as appropriate, and move a lot of the explanatory text into 2, 3, and 4. This would leave 1-process-geodata.Rmd as just a small script that we just use when we need to reload the sightings and segments.

Because this is funky, we should talk it over, just to be sure.

dill commented 8 years ago

3pm works for me. I'll take a look at the rest of your comments now...

On 22/10/2015 14:31, Jason J Roberts wrote:

We are generally on the same page but should chat. Does 3:00 work for you? I have to leave today at 4:30.

|2-detection-functions.Rmd| as of 44509e7 https://github.com/DistanceDevelopment/spatial-workshops/commit/44509e7f0b7e16c27038a2d8987912b6d2dbda4a looks good for executing Tuesday 3:00-4:30. In fact, it might be sensible to execute the very first few lines of code, through the first call to |head(distdata)| in the Tuesday 10:45-12:15 session. We will have just finished my slides that discuss exchanging data between ArcGIS and R. To execute that first call to |readOGR| would be a good way to immediately apply what we discussed. Of course, we do not necessarily need to go so far as to load up the .Rmd at that point, if you don't want to. Instead I could just have them start RStudio and type in three lines of code, e.g.

library(rgdal) distdata <- readOGR("Analysis.gdb",layer="Sightings") summary(distdata)

That would demonstrate that yes, we can load the points into R. Then we would break for lunch and in the afternoon pick up with the detection functions lecture and exercise, perhaps saving the discussion of .Rmd and knitr for that point.

What to do with |1-process-geodata.Rmd| is more complicated. I agree it should come after |2-detection-functions.Rmd|. But as we both now understand, Wednesday afternoon we have to read the sightings again in addition to the segments, and then on Thursday afternoon we have to read the segments again (to get the covariates).

RIght now |1-process-geodata.Rmd| is written as kind of a one-time thing, with exploratory code etc., rather than a little utility script designed to run over and over. I think it would be best to move the exploratory part into |3-simple-dsms.Rmd| and |4-advanced-dsms.Rmd| as appropriate, and move a lot of the explanatory text into 2, 3, and 4. This would leave |1-process-geodata.Rmd| as just a small script that we just use when we need to reload the sightings and segments.

Because this is funky, we should talk it over, just to be sure.

— Reply to this email directly or view it on GitHub https://github.com/DistanceDevelopment/spatial-workshops/issues/32#issuecomment-150315114.

dill commented 8 years ago

Jason's proposal:

dill commented 8 years ago

This re-ordering is all done by 0e879e7.

Again, leaving this open and assigned to me until I run on fresh machine.

dill commented 8 years ago

New process-geodata.Rmd (nee 1-), works fine with Exercise_Day2.zip on a new machine.