Jump to content
Ornithology Exchange


Society Members
  • Posts

  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

1,088 profile views

ebridge's Achievements


Newbie (1/14)




Community Answers

  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.
  • Create New...