Jump to content
Ornithology Exchange


Society Members
  • Content Count

  • Joined

  • Last visited

 Content Type 








OC Small Grants Applications

Journal Indexes

Grants & Awards

AOU/COS 2015 Travel & Presentation Award Applications

Everything posted by ebridge

  1. I went around the block with google maps for a couple of hours and could not get past this cryptic error message when trying to download a simple example map: ggmap::register_google(key = APIkey) map <- get_map(location = "texas", zoom = 6, source = "stamen") Source : https://maps.googleapis.com/maps/api/staticmap?center=texas&zoom=6&size=640x640&scale=2&maptype=terrain&key=xxx Error in aperm.default(map, c(2, 1, 3)) : invalid first argument, must be an array In addition: Warning message: In get_googlemap(center = location, zoom = zoom, filename = filename) : HTTP 400 Bad Request Others have had this issue and some have solved it--there are some suggestions on stackoverflow--but not me. I tried a bunch of enabling and management options for static maps API, but nothing worked. Maybe something has changed recently with google or ggmap?? Anyway, I'm now building my maps from scratch using get_stamenmap(). Might be a better future option for map.FLightR.ggmap().
  2. Meelyn, can you please list all the batteries you've tried and the results you got. I think people will want to know what does not work as well as what does.
  3. Solved it by uninstalling the sp package and reinstalling. Note that just updating the package did not work.
  4. I'm getting an error when running make.prerun.object in FLightR: > all.in Error in .C("sp_dists", x, y, xx, yy, n, dists, lonlat, PACKAGE = "sp") : "sp_dists" not available for .C() for package "sp" Looking at the sp package there is a function called spDists, so maybe the name got updated. Any thoughts...
  5. Dear Alec, The RFID reader will only work with FAT-16 formatted SD cards. The 64GB card is almost certainly FAT-32, and so the RFID reader won't work with it. I know less about what is compatible with iPads. Obviously your mac is compatible with fat16 which will allow it to read smallish SD cards. It could very well be that the iPad will not read Fat16 and that's all there is to it. You could test this idea by taking one of the 2GB cards and reformatting to FAT32 (use disk utility on your mac). If the IPad comms with the reformatted card, then there's your answer. Of course that card will no longer work with the RFID reader. It might be that the lightening interface device is not FAT16 compatible, but I doubt it. You could test that by plugging it into your mac with the FAT16 card attached.
  6. Chuck, Sorry you haven't gotten any answers. Maybe it's because you have a problem that is hard to replicate. Is there a way to make it happen without 30-40 minutes of work? Can you confirm that it freezes with no error message?
  7. I would go back and baby-step through this analysis. Are you getting reasonable results from a threshold analysis? If not you might want to solve that problem first before going on to FLightR. And ditto what Eldar said about clock drift. That can give you large and directional longitudinal errors.
  8. Just subset the data: twl_d or something like that. But I'd recommend carrying on with the full data set if possible. If you publish or share the data with lines deleted your work is not really repeatable.
  9. I've not looked, but I wonder if the "deleted" twilights are actually just flagged somehow and not actually deleted. Can you show us some of the actual data in twl?
  10. One of the the things SGAT does is essentially take an estimate of twilight error (derived from calibration data) and translate it into location error for the entirety of a tag deployment. So if the same bias you mention is in your calibration data, SGAT might help eliminate it. If the point estimates move ever farther eastward over the course of the deployment period, there may be a clock drift issue. You could also have a "mountainside effect" where one twilight experiences shading but not the other. I suggest you look closely at your calibration data and plot the difference between known and estimated twilights. Do this separately for sunrise and sunset and for before and after calibration periods (if you have both).
  11. Hi Amélie As a general approach you could find upper and lower quantiles for the posterior probability for longitude (stored in the output object fit$x) and latitude (fit$y) for each day and plot them along with the means or medians. Are you looking for more of a "how to" guide? Eli
  12. I think start_no_polar has something to do with correcting twilights when the tag is near the poles. I guessing this sort of thing should not apply to your data set, but just for fun you could try setting a lower latitude value and see what happens. The make-rerun-objects function is a wrapper that is calling several other functions. the error you see is probably due to a missing parameter in one of those internal functions. I don't think you can set "start_no_polar" in the make-rerun-objects function. But why that error occurs I do not know. Sorry not a very helpful answer. If Eldar does not chime in at some point, then maybe thing about posting your code and data on Github so we can try to replicate your problem.
  13. Thanks for pointing this out. I think I will definitely be making some contributions here. Cheers, Eli
  14. Interesting problem. As a work around can you just shift all of your times forward 5 hours and calibration locations east 60 degrees? Just avoid the dateline altogether. Let me see if I can get Eldar to chime in.
  15. Here's a question that came as an email: I've heard about antenna's being vulnerable to water from other sources too. To waterproof them I'll usually dip them in epoxy or in plastidip (tool dip). In both cases it's a messy job. A colleague of mine uses expoxy putty that you can mold with your fingers. That might be a neater option, but I haven't tried it.
  16. Hi Alan, A likely problem is that the file is too big. TAGS was established when data at 10-minute intervals was the norm. If you have data a 2-minute intervals it is probably more that TAGS can handle (it tries to plot all the data). One thing to try is to cut the data up into smaller chunks. You can also get rid of repeated data (instances where the light level data are the same over and over).
  17. Here's a link to a $1 coupon from Airport Express in Oklahoma City: http://www.airportexpressokc.com/#!aoucos2015/c4ep
  18. The 2015 AOU/COS conference will be on the University of Oklahoma campus, which is about 20 miles and 40 minutes from the nearest airport (OKC). To reduce costs, we recommend you seek out other conference attendees arriving to OKC around the same time and share rides in rental cars or taxis. The recommended taxi service is Airport Express. They will transport groups of five to the OU campus for $50 ($38 for the first person and $3 for each additional). There may also be a $1 off coupon posted online soon (check back here or on the meeting website for updates). Reservations are not required for Airport Express if you are leaving from the airport (they always have a bunch of vehicles waiting). However you do need to make arrangements for a ride from OU to the airport (405-681-3311 or 877-688-3311, www.airportexpressokc.com) Anyway, If you are looking to share a ride or find riders to/from the OKC, please post your name, the date and approximate time, whether you are going to or from OKC, and any other pertinent info like whether you will have a rental car. You should probably exchange phone numbers and such afterward by email.
  19. The recommended service is Airport Express. To the OU campus it's $38 for the first person, plus $3 for each additional person. So it will behooves folks to group up (five per vehicle). There are other options (taxis, limos, etc), but this seems like the best. We'll send out an announcement soon. Cheers, Eli
  20. Sorry to bogart the forum, but I wanted to make another plug for a workshop at AOU/COS 2015. Jeff Buler is leading an all-star cast* in a RADAR ORNITHOLOGY workshop. There is a 20+ year archive of Nexrad radar data just sitting there at the National Severe Storms Lab. This archive could be a tremendous resource for examining regional- to continental-scale phenomena relating to birds aloft. There are about 10 people in the country who have the knowhow to use these data to their fullest, and more than half of them are going to be in the same room to share their methods with the rest of the ornithology community. The techniques they will impart and the software they will give away could be a major addition to your analysis toolbox. More info and a link to sign up are here: http://aoucos2015.ou.edu/?page_id=1030 * Robert Diehl, Jaci Smolinsky, Kyle Horton, Dan Sheldon, and Andrew Farnsworth P.S. We have lots of cool radar stuff here at OU too.
  21. I am pleased to announce a free instructional workshop on geolocator analysis that will be held in association with the 2015 joint meeting of the American Ornithologists Union and the Cooper Ornithological Society in Norman Oklahoma (http://aoucos2015.ou.edu). The two-day workshop entitled, "Light-level geolocation with open source tools," will convene on the morning of 27 July, 2015 and will end the following Tuesday at about 5pm. Thanks to the support of the Cooper Ornithological Society, there is no enrollment fee for this workshop. The workshop will be led by Nat Seavy of Point Blue Conservation Science with assistance from Renee Cormier (also from Point Blue), myself, and others. The workshop will demonstrate the implementation of a number of R packages that can be used to derive location estimates from light-level geolocation data loggers. We will begin with simple thresholding methods and accessory analyses that might be familiar to some of you (e.g. GeoLight and KFtrack) and progress through some recent, more advanced analysis packages that are (we presume) new to the vast majority of geolocator users (e.g., SGAT and FlightR). The workshop will enable you to make the most of your geolocator data and derive not just location estimates but also uncertainty metrics for those estimates. We will also present helpful techniques for assessing migration phenologies, categorizing stationary and migratory periods, and presenting your results. We hope you will bring your data to work on during the workshop. I am confident that this workshop will change how we do business. I hope that you will be able to attend or send a representative from your lab. I also hope that you will pass this news on to any potential attendees who may not know about it. A few more details: To sign up: Visit the AOU/COS 2015 website (http://aoucos2015.ou.edu) and follow the "WORKSHOPS" link at the top to the workshops page. Near the bottom is a link to a google sign-up service where you can register for the workshop. NOTE THE DEADLINE AND ATTENDEE LIMIT: Abstract submission and early registration (reduced fee) for the meeting must be done by May 3, 2015. Registration for the workshop will remain open until we reach our maximum attendance of 35 people. At that point you will be able to join a waiting list from which we will fill any spots that become vacant. Do you have to attend both days? Not necessarily. The first day will be concerned with installing R packages, manipulating and evaluating light level data, and conducting analyses with well established R packages. If you are an advanced R user and an experienced analyst of geolocator data, you can probably pick up the thread on day two when we delve into the newer and more advanced analysis packages. Please contact me with any questions. Dr. Eli S. Bridge Assistant Professor Oklahoma Biological Survey University of Oklahoma 111 E Chesapeake St Norman, OK 73019 (405) 325-2658 ebridge@ou.edu
  22. Hi Danifreund. Thanks for using the forum. I Don't use excel much anymore unless I really need to pour through the data line by line. My typical routine now is to decompress data using a loop in R, visualize the data for a sanity check, and then proceed with whatever analysis. The result of decompression is a simple text file that's pretty easy to store. I used to use Excel to do the decompression but the spreadsheets would get unwieldy.
  23. The first possibility that comes to mind is a bad connection between the sd card socket and the circuit board. But that would not explain the odd date you are getting (did it really say jan 01, or was the clock not yet set?). If you get an SD card error then you will not get any logging activity. I would first try going over all the connections on the SD card socket with a soldering iron (remelt all solder and look out for bridges). That failing, I would try reprogramming the reader with the boot loader. After that there comes the decision to do further troubleshooting or just toss the board out.
  24. First you get the data into a text file. You can set up Termite to log to a text file or you can just download all the data, select it all (cntl - A), copy it (cntl - c), and paste it into a text doc or word doc (cntl - v). Edit the file if you wish (delete the non-data stuff), and save the data as a text doc. Open a blank excel document (or if you are appending data, open an existing file). Select the cell where you want the data to go. From the top menu, select through Data - Get External Data - Import Text File. Then select the txt file and tell excel that you have a space delineated file. That's one way to do it. Thanks for using the forum.
  • Create New...