Eldar
-
Content Count
73 -
Joined
-
Last visited
Recent Profile Visitors
843 profile views
-
Hi Ana, these cut-off probs just measure how many particles movet between time t and t+1. 0.1 will say that there was movement between two periods if at least 10% of particles moved >25 km. 0.5 would mean 50% chance. Generally you better make it higher than lower. There is so far no established approach on how to select a proper value here. Hope this helps, Eldar -
So you can install it directly from there with the install.packages(). 0.4.9 version introduces FLightR2Movebank( ) function that saves result formovebank upload. The latest version is on GitHub, as always.
-
Hi Jenny, 1. You could try increasing the distance they are allowed to fly. The maximum distance can be fixed in particle.filter and the mean and sd in make.prerun.object. 2. Try running first without any spatial constrains. It sometimes happen that particle filter just cannot find a proper solution if bir migrated to far every day for a long period. Hope this helps, Eldar
-
bug in FLightR 0.4.8
Eldar replied to Eldar's topic in Geolocator Discussion & Support's Geolocator Discussion & Support
This is strange. I have just tried installing from GitHub and got the 0.4.9... It is not on CRAN yet, so do not try there. Eldar -
Please note that there was a bug in FLightR 0.4.8 that creared weird resuls with point jumping all over the place - Please update FLightR to 0.4.9: devtools::install_github('eldarrak/FLightR') Eldar
-
Hi Dan, I have discovered a bug in FLightR 0.4.8. Please reinstall from Grithub with devtools::install_github('eldarrak/FLightR') and report whether you still have problems. Sorry for the inconvenience. Eldar
-
Hi Dan, rtools is not a package, so you should download it from here https://cran.r-project.org/bin/windows/Rtools/ and install manually. Hope this helps, Cheers, Eldar
-
This problem is solved in FLightR >=0.4.8 .
-
Hi Don-Jean, Looks like a bug... Could you please send me the RData and the script? I will have a look. Eldar
-
Hi Don-Jean, I would suggest you reread the original file starting from the deployment date and plug the already created calibration into it. Hope this helps! Eldar PS Note that in many cases you get too clean results in case of rooftop calibration, so you might want to find the wintering site and recalibrate there to get reasonable uncertainty estimates.
-
Hi Hendrik, Yes, we had this issue already with some other roof top calibrations. I must admit that on bird works better. The calibration consists of the two main parameters - slope (mean+- sd) of measured irradiance vs expected irradiance. Mean should be the same, but the sd differs between the roof top and the on bird. Hope this helps, Eldar
-
Hi Allison, I can add a tag to FLightR to make it processing yur tags automatically. DO you have on bird calibration data from several tags? If so, sould you sent me those together with the calibration coordinates? I will try to have a look. Cheers, Eldar
-
There was a bug in FLightR causing this error for tagging location above 65 but below 66 degrees N. Fixed now in FLightR >=0.4.8 (at the moment GitHub only).
-
Hi Louise, There was a minor bug in FLightR. Fixed now, so install the latest version with devtools::install_github('eldarrak/FLightR') And go ahead. BUT note, that with the cutoff probability of 0.8 you are setting quite a high border probability and many small movement and stops may just disappear.
-
Unfortunately this results of the new google rules for use of google maps. They want everyone to get the api key for google maps. In order to do this you should 1. go to https://cloud.google.com/maps-platform/?apis=maps get the key there 2. update you ggmap devtools::install_github("dkahle/ggmap") 3. then in each session in R try ggmap::register_google('your_api_key') Now FLightR ggmap related functions should work.