OC Small Grants Applications
Grants & Awards
AOU/COS 2015 Travel & Presentation Award Applications
Everything posted by ebridge
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().
Solved it by uninstalling the sp package and reinstalling. Note that just updating the package did not work.
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...
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.
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?
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.
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.
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?
ebridge replied to Hendrik's topic in Geolocator Discussion & Support's Geolocator Discussion & SupportInteresting 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.