Jump to content
Ornithology Exchange

captaingriz

Society Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0

Profile Information

  • Location
    Norwich, VT
  • Country
    United States
  1. So I was playing around with this yesterday, and perhaps I'm walking myself back a bit from my suggestion. I'm analyzing data on a grassland bird species that spends most of its time on the ground (maybe my thoughts would be different if I were analyzing 'cleaner' data from a bird that perches in the open (e.g., a kestrel). Bottom line: my data aren't neat and pretty. If I measure the great-circle distance between the median lat/lon estimate for every twilight that falls between when the bird left the winter grounds and arrived on the breeding grounds, then I get a distance estimate that seems (to me) overly large. As Eldar pointed out, even when the bird is stationary my path/route length would be accumulating distance because the particles (and the associated median location for each twilight) are still moving around. Also, if you have any "unlikely locations" [e.g., the bird reverses direction for a short time] that survive the FlightR outlier routine, then the migration distance quickly becomes inflated. If your FlightR estimates make a nice simple path, then the below discussion probably won't be of interest to you. I think the uncertainty estimate, associated with the path distance, would be enormous with my data. I'm thinking about this approach by Arizaga ( Arizaga estimated the median lat/lon for stationary periods on spring migration, and then calculated the route distance between the wintering grounds, each stationary period during migration, and the breeding grounds. FlightR already has the tools to make this analysis easy. I see some limitations to this approach as well--especially if a bird flew around (not across) some large geographic feature [e.g., the Mediterranean Sea or the Gulf of Mexico]. Here's one approach based off of Arizaga: ########## # first, run the find.times.distribution function to ID the median date estimates of when the # bird left the wintering grounds and arrived on the breeding grounds # see Eldar's example here: https://github.com/eldarrak/FLightR/blob/master/examples/Black-Tailed_Godwit_FLightR_vignette/FLightR_analysis_workflow.Rmd # Note: instead of longitude (from Eldar's example), I used latitude and adapted the approach used by # Jahn et al. 2013 (http://www.bioone.org/doi/abs/10.1525/auk.2013.12077) to decide when the bird left # the breeding or wintering grounds # something like this for the wintering ground arrival time: Index.BIRD(winter.lat.BIRD+1)) #create imaginary line +1 degree north of the median latitude estimate # of the first stationary period on the wintering grounds Winter.arrival.BIRD # run the stationary.migration.summary BIRD.migration.summarysave(BIRD.migration.summary, file="BIRD.migration.summary.RData") # save results for later analysis # let's say that the migration summary identifies 6 stopover events that occurred between the time period # between departure from the wintering grounds and arrival on breeding grounds # in this fake example, those stationary periods correspond with the 5th-10th stationary periods # in the stationary.periods results BIRD.spring.migration.latlonsBIRD.spring.migration.latlons[1:6,1]BIRD.spring.migration.latlons[1:6,2] # row-bind them together (BIRD.spring.migration.path library(sp) # measure segments between locations and sum them to estimate route length sum(spDists(BIRD.spring.migration.path,segments=1,longlat=TRUE)) # this is one possible estimate of spring migration distance # now compare that estimate to the great-circle distance directly between wintering grounds and breeding grounds spDists(matrix(c(winter.lon.BIRD, winter.lat.BIRD,breeding.lon.BIRD,breeding.lat.BIRD),nrow=2,ncol = 2,byrow = T),segments=T,longlat=T) #Note: see the "TDR" statistic used by Arizaga et al. to compare the above two estimates library(raster) # save spring migration route as shapefile if so desired BIRD.spring.migration.routeshapefile(BIRD.spring.migration.route,"BIRD.spring.route") ########## I've tried these approaches with only one(!!) bird so far: preliminary results (for n=1, so interpret with caution please) Great-circle distance between wintering and breeding grounds = 3635.9 km [this is the shortest possible distance flown] Spring migration route distance based on my above code = 3921.192 "Connecting-all-of-the-twilights" distance method that I previously suggested = 5319.8 Distance estimate from FlightR's find.time.distribution = ~5252.1 km Just my preliminary thoughts, and of course, there's no way to determine (for my data) which one is most accurate
  2. Sorry, I wasn't clear there--yes you are right--one median. If you had an MCMC model that estimated lat/long at discrete time steps, and you saved 3000 iterations, then from the posteriors (out$sims.list) you could draw a sample of those 3000 estimates of each lat/long (or just use all 3000 of them, of course). I'll see what I can do. Thanks, Jason
  3. Thanks Eldar, Hmm, I appreciate that this is a challenging concept, especially given your point about the distance accumulating even when the animal is stationary (due to the particles mixing around). This is tough. I'm just not familiar enough with particle models. If I was running a standard MCMC Bayesian analysis in JAGS then I'd simply monitor the latitude & longitude median value for each twilight (so that the median for each twilight would have its own distribution of uncertainty). But we certainly don't want 1 million estimates of each median lat/long for each twilight! But if it was possible to save a random subset (e.g., 100?, 1000?) of those medians then I think it would be straight-forward to do something like this overly-simple example below, library(raster) path1 path2 path3 aaplot(aa,axes=TRUE,las=1) library(sp) median(c( sum(spDists(path1,segments=TRUE,longlat=TRUE)), sum(spDists(path2,segments=TRUE,longlat=TRUE)), sum(spDists(path3,segments=TRUE,longlat=TRUE)))) } But this idea fails to take advantage of the full power of your particle model approach. Thanks for your help Eldar, Cheers, Jason
  4. I would like to estimate (with uncertainty) the cumulative distance traveled by an organism between two specific time periods. Let's say that I used the find.times.distribution function to identify that a tagged bird most likely commenced spring migration on 1 April 2016 and most likely reached its breeding grounds on 23 April 2016. I would like to sum the distance traveled by that bird between every consecutive twilight from 1 April to 23 April. The ideal final result would be something like, "The cumulative spring distance traveled between 1 April and 23 April was median=1034.2 km (95% credible interval: 650.2 to 1840.2 km). Getting the median cumulative distance is easy: migration.longitude.values migration.latitude.values library(sp) sum(spDists(cbind(migration.longitude.values, migration.latitude.values),segments=TRUE,longlat=TRUE)) But I cannot figure out a 'good' way to estimate the uncertainty component. One (non-parsimonious) solution would be: 1) generate 95% isopleths (with the plot_util_distr function) for every twilight [or perhaps just every day] between 1 April and 23 April, 2) generate 1000 random points (assuming a uniform distribution) within the confines of each 95% isopleth, 3) create 1000 paths/polylines that run between all 23 isopleths (using a single point in each isopleth), 4) and finally measure the length of those 1000 paths and create summary statistics (median, mean, 0.25 and 0.975 percentile values). I had been trying to modify the get_ZI_distances function in FlightR to avoid my non-parsimonious solution, but I have so far failed miserably. Hopefully a better programmer than myself can provide some help. Thank you and cheers, Jason Hill
  5. Eldar, Definitely not a fault with FLightR but thank you very much for the offer of help. I think this is a Grid x ggmap x ggplot2 problem that I have worked around somehow. I have found that manually loading the grid graphics engine (library(grid)), before running the ggmap command, often makes these errors go away. I have no idea why. Problem solved for now.
  6. I'm getting a new-to-me error message now with the plot_util_distr and map.FLightR.ggmap commands using the newly-updated version of FLightR: devtools::install_github('eldarrak/FLightR') plot_util_distr(Result) or map.FLightR.ggmap(Result) produce the same error Error in get("f", environment(CoordMap$train)) : object 'f' not found Tried installing newest version of ggplot and ggmap devtools::install_github("dkahle/ggmap",force=T) devtools::install_github("hadley/ggplot2",force=T) Tried installing development version of those packages using library(devtools) dev_mode(on=T) No difference. This appears to be a known issue with ggmap https://github.com/dkahle/ggmap/issues/144 Solution: reinstall version 2.6.1, don't know why this fixes it. library(versions) available.versions('ggmap') installed.versions('ggmap') install.versions('ggmap', '2.6.1')
  7. #Package FLightR version 0.4.6 I have been using FlightR to analyze geolocator data for Grasshopper Sparrows, and I have been really pleased. I am wondering, however, if there is a way to export the kernel density results from the plot_util_distr command into ArcGIS. Exporting the median (w/ 95% CRI) lat/long values for use in ArcGIS (via "add XY data") is easy enough: write.csv(run.particle.filter.Results$Results$Quantiles,"GIS_import.csv") But what about exporting the utilization distributions to ArcGIS for replotting and further manipulation? plot_util_distr(particle.filter.results, dates=data.frame(as.POSIXct('2015-12-01'), as.POSIXct('2016-02-01')), percentiles=c(0.5,0.9), save.options = list(filename="winter.pdf")) I've tried saving or converting the plot object to a SpatialPolygonsDataFrame but I don't know of a way to coerce a 'list' into a SpatialPolygonsDataFrame. I suppose that I could draw the winter.pdf file with a blank background (then geo-reference the winter.pdf file) and bring that file into ArcGIS with the georeference toolbar. That would not be a parsimonious option for my 30+ birds and I still couldn't manipulate the results in ArcGIS (I could only view them). Thanks for your help and suggestions everyone, Jason
×
×
  • Create New...