Light-Level geolocator analysis using the GeoLight package
Michael T. Hallworth
Smithsonian Conservation Biology Institute
Migratory Bird Center
Introduction to Archival light-level geolocators
The following document outlines the steps for analyzing data from archival light-level geolocators (hereafter geolocators). Geolocators have been used to track individuals since the early 1990s but were restricted to large organisms because of their large size. Recently, with the miniturization of geolocators, researchers are now able to deploy geolocators on smaller and smaller species. Geolocators are devices that record ambient light levels every 2, 5, or 10 min depending on the model. Geolocators are attached to individuals which then migrate with the device while it records ambient light-levels throughout the year. Once recovered, the data are downloaded and analyzed to determine the time of sunrise and sunset. From the sunrise/sunset data the time of relative noon and midnight are determine. Geographical cooridnates are then derived from the relative ‘noon’ and ‘midnight’ times to give an approximate location of where the individual was throughout the year.
This tutorial uses geolocator data from a male Ovenbird (Seiurus aurocapilla) breeding at Hubbard Brook Experimental Forest, NH and a Wood Thrush (Hylocichla mustelina) breeding in Indiana and is part of an ongoing study modeling regional source-sink dynamics of a migratory songbird. Click here for more information regarding the Wood Thrush project. The geolocators used for the two projects were purchased from British Antarctic Survey (BAS) and Lotek (LightBug). These models operate in the same manner but format the data differently. In order to use GeoLight to analyze the data, the data needed to be formatted correctly so GeoLight can read the data.
Analysis of geolocator data using the GeoLight package in R
The following R packages are needed to conduct the tutorial
library(GeoLight)
library(raster)
library(ks)The data format of geolocators purchased from different vendors are slightly different and need to be converted into a file format that is recognized by GeoLight
OvenRaw<-read.csv("data/2391_68559_000.lig",sep=",",skip=1,header=FALSE,col.names=c("Valid","Date","Julian","Light"))
WothRaw<-read.table("data/0309_RAW.txt",sep="\t",header=TRUE)Ovenbird Raw data from British Antarctic Survey (.lig file)
## Valid Date Julian Light
## 1 ok 10/06/11 22:37:30 40704.94 64
## 2 ok 10/06/11 22:39:30 40704.94 64
## 3 ok 10/06/11 22:41:30 40704.95 64
## 4 ok 10/06/11 22:43:30 40704.95 64
## 5 ok 10/06/11 22:45:30 40704.95 64
## 6 ok 10/06/11 22:47:30 40704.95 64Wood Thrush Raw data from Lotek LightBug (.txt file)
## time date light
## 1 00:07 27/07/11 236
## 2 00:14 27/07/11 236
## 3 00:21 27/07/11 236
## 4 00:28 27/07/11 236
## 5 00:35 27/07/11 236
## 6 00:43 27/07/11 234The following functions were created to convert the different raw data formats into the format needed to process light data in GeoLight. The functions need to be added to your R console to use the function. The source function is used to read in a function stored as an R file in your working directory.
source("source/sourceRead_lig.R") # function written by Simon Wotherspoon accessed from GitHUB
source("source/sourceRead_Lightbug.R") # read_lig function modified by M.T.Hallworth to read in LightBug dataImport .lig file using read.lig fucntion to convert dates that GeoLight recognizes
GL_68559<-read.lig("data/2391_68559_000.lig")
head(GL_68559)## Valid Date Julian Light
## 1 ok 2011-06-10 22:37:30 40704.94 64
## 2 ok 2011-06-10 22:39:30 40704.94 64
## 3 ok 2011-06-10 22:41:30 40704.95 64
## 4 ok 2011-06-10 22:43:30 40704.95 64
## 5 ok 2011-06-10 22:45:30 40704.95 64
## 6 ok 2011-06-10 22:47:30 40704.95 64Now that the data are formatted - you can use GeoLight to determine transitions (sunrise/sunset)
In this example - a threshold of 5 was used - a larger or smaller value can be used but it will decrease/increase the number of transitions that need to be scored.
LightThreshold - determines light levels over 5 as “sun has risen/set” and asks you to accept/reject them.
Note - determining the transitions in this file took approx. 45mins - 1hr
The following code produces an interactive plot which asks the user to either accept or reject each light transition that passes over the threshold specified in the code. This document does not support interactive plots but the plot you will see should look similar to the one below. The blue line identifies the threshold level set in the code.
GL_68559_transitions<-twilightCalc(datetime = GL_68559[,2],
light= GL_68559[,4],
LightThreshold=1, # Here is where you set the threshold level
ask=FALSE) # Here you can go through every twilight
Exercise: Go through and assign a few twilights.
* How did you decide to either accept or reject twilight events?
* How do you think accepting / rejecting twilight events would influence the end result? * Change the threshold to a higher value - how does that change the number of shading events?
Once you have gone through the process of accepting or rejecting the transition events the data will look like this. tFirst and tSecond correspond to the time of the transitions and type illustrates whether the location will be dervied from relative ‘noon’ or ‘midnight’ locations.
head(GL_68559_transitions)## tFirst tSecond type
## 1 2011-06-11 00:19:30 2011-06-11 08:51:30 2
## 2 2011-06-11 08:51:30 2011-06-11 23:59:30 1
## 3 2011-06-11 23:59:30 2011-06-12 08:53:30 2
## 4 2011-06-12 08:53:30 2011-06-13 00:27:30 1
## 5 2011-06-13 00:27:30 2011-06-13 08:45:43 2
## 6 2011-06-13 08:45:43 2011-06-14 00:13:18 1Sun-elevation angle
The next step is to calculate the sun-elevation angle of a known capture location. The sun-elevation angle is the angle of the sun with respect to the horizon at the time the geolocator light data passed the threshold set by the user. Thus, the sun-elevation angle is unique to the threshold used in the analysis.