Jump to content
Ornithology Exchange

Eldar

General Members
  • Content count

    56
  • Joined

  • Last visited

Everything posted by Eldar

  1. Eldar

    plot_slopes_by_location

    Hi Devin, Plug calibration from the working tag into all.in<-make.prerun.object(proc.data, Grid, Calibration=Calibration) Hope this helps, Eldar
  2. Eldar

    plot_slopes_by_location

    Hi Devin, Yes, this happens often. In many cases (e.g. swifts) calibration twilights could be completely missing due to behaviour. Eldar
  3. Eldar

    plot_slopes_by_location

    Hi Devin, Absence of the slopes after start of migration is normal, so no worries here. But what I see in the graph is difference between slopes during dusk and dawn yo have in the summer. THis could happen because (1) the start coordianates are not correct, (2) bird moved to a new place (and thus you do not know where to calibrate you tag), (3) there is a specific bird behaviour, that makes this difference. I would suggest you double check the calibration location and if it was correct try try with calibration extracted from a tag that worked. For Intigeo tags that works well. Eldar
  4. This happens sometimes, no worries. Just do library(grid) before running this line. Cheers, Eldar
  5. We are looking for a venue in Vancouver as it seems we cannot have our workshop at the congress centre. Let us know, please, if you have any suggestions. Eldar
  6. Our apologies for the late notice but we want to announce that there will be a 1.5 day short course in geolocation analysis in association with the International Ornithological Congress in August. We have been unable to come to terms with the IOC organizers about the location of this course, but one way or another we will have it in Vancouver on August 19 (Noon to 6pm) and August 20 (8am to 5pm)—just before the conference. It is uncertain as to whether this course will be listed on the IOC website, so we wanted people to be aware of it as they make travel plans. Please share this announcement with anyone who may be interested. We have no intention of excluding anyone. For more details on the contents of the course, please see the attached description. If you are interested in attending the course please visit this signup page to provide your contact information and to answer a few quick questions about your coding background: https://goo.gl/forms/SduJiuMsJrpta2462 We will probably ask for a $20 fee at some point to cover any room rental fees and other expenses (and to discourage no-shows). We have limited the course size to 40 attendees. If you have any questions, feel free to contact any of the organizers. For those of you going to IOC we look forward to seeing you there. To everyone else, please excuse the intrusion. Sincerely, Eldar Rakhimberdiev (Author of FLightR) Simeon Lisovski (Author of GeoLight) Eli Bridge (Head Cheerleader)
  7. You can try automating it. Let's say left is replaced with right for the cases when right crosses 0 meridian. You can do then something like Left_corrected<-Left Right_corrected<-Right Left_corrected[condition when right is not correct]<-Right Right_corrected[condition when right is not correct]<-Left Hope this helps. Eldar
  8. Hi Cosme, I am not sure I can fully imagine what you are talking about, but expect you see some strange plotting around 0 meridian. This can definitely happen but it is likely not an error but incorrect assignment of Left and right CI while near 0 meridian. You can try to correct it by hand by swapping left and right CI for specific points. If it does not help, send me your result object and code by mail and I will have a look. Eldar
  9. Hi Louise, datum should be wgs84, you are right. Cheers, Eldar
  10. Hi Tara, You have created an object called GeoLight2TAGS and it is function name in FLightR. Try removing this object and everything will go through. rm(GeoLight2TAGS) Cheers, Eldar
  11. Hi Louise, I do not think this is common, as I have seen many birds wintering around equator where geolocator inferred positions did not do jump. At the same time I have also seen many migrations within Africa during wintering from gps data, so it is common. The only suspicious thing is symmetrical movements in relation to autumn and spring equinoxes, if you have those - send me the lat-lon plots, please. Cheers, Eldar
  12. Hi Tara, Looks strange, could you, please, save the workspace and email it to me? save.image('image.RData') Eldar PS - I would recommend TwGeos but not GeoLight for initial data annotation - saves a lot of time!
  13. Eldar

    Weird results

    Hi Ana, I looked at your data and it looks like you have some problems with the calibration times: try Calibration.periods<-data.frame( calibration.start=as.POSIXct(c(NA, "2014-10-20")), calibration.stop=as.POSIXct(c("2014-04-10", NA)), lon=-74.51644, lat=4.36459) This will create you following data.frame: calibration.start calibration.stop lon lat 1 <NA> 2014-04-10 -74.51644 4.36459 2 2014-10-20 <NA> -74.51644 4.36459 First line makes first calibration period and second line second. Results look ok in this case but some outliers still remain. Hope it helps, Eldar
  14. Hi Louise, You should have deleted second NA, something like: Calibration.periods<-data.frame( calibration.start=NA, # start of the second calibration period calibration.stop=as.POSIXct("2013-08-05") # end of the first calibration period lon=-4.37, lat=58.38) Cheers, Eldar
  15. Eldar

    Weird results

    Hi Ana, Could you please send me your script, TAGS formatted csv and the Result file (through wetransfer or googledrive)? I will have a look then.
  16. Eldar

    Error with map.FlightR.ggmap function

    All looks good to me and still cannot reproduce the error. Try save(Result, file='Result.RData') and send it to me via e.g. wetransfer
  17. Eldar

    LightImage function error

    Hi Louise, Check the last value in your file: tail(d.lux) it is likelyt that there is NA value somehow. If not send me and Simeon your file and the code you have before the error. Eldar
  18. Eldar

    Error with map.FlightR.ggmap function

    Hi Louse, I cannot reproduce the issue could you please type sessionInfo() and send results to me. You can also send your result object and I will try it. Cheers, Eldar
  19. Eldar

    Issue with loading Geosphere

    Hi Sabina, What is your FLightR version? Try installing the latest from github. devtools::install_github('eldarrak/FLightR') and what happens if you run install.packages('geosphere') before running the plotting function?
  20. Eldar

    Issue with loading Geosphere

    Hi Sabina, I am not sure there can be geosphere issue, at least I do not use it in FLightR. You can always run library(geosphere) before running the function. Sometimes seasonal donut does not work. For that you should try library(grid) before running the function. But how many maps you expect there? Regards, Eldar
  21. Eldar

    overlapping stationary periods

    Hi Ana, This was not a bug this is just how function works. So I would not weight these resutls too high. When bird moves slowly points overlap a lot and function produces strange results. It is possible that there were additional stops on the way, but it is hard to tell for sure as there is strong overlap in locations. I would suggest you exclude all these short stops from the results, or make inference with 50% particles crossing some latitude. For the breeding you can just select the area and find arrival times with find.times.distribution(Result, Spatial.Index) Hope it helps And - if you have ideas on how to implement summary in a better way - let me know. Cheers Eldar
  22. Hi Louise, Sorry, super busy times... Correct. You can always check defaults by looking at the help file for function: ?run.particle.filter It is currently 1500 km. You can also change it to any value you like. 'a' is 45 as FLightR estimates positions on a grid and minimum distance between grid cells is about 50 km. I would not pay too mch attention to 'a' as it is only a way to estimate the model. Have never done experiments with making a higher let me know what results are if you go for it. You are right. This is how it is currently programmed. I will think of including time instead of number of twilights. Function plots medians and they overlay (because of the grid). Another potential source of problems is automated zooming. Try zooming out to check whether there is not points outside the plotted area (this should not happen but just in case..) There is no difference. These are 95% and 50% credible intervals. Cheers, Eldar PS - You better ask short questions - it is hard to find time for such a long reply
  23. Sure, that what I was talking about - it could be that positions are just estimated wrongly. It happens especially close to equinoxes. This is why I would say that the bird likely already arrived to the breeding grounds but the estimates you get are in Sahara. And you are right this happens when surface gets opaque. If you will get some results with find stationary location function for wintering period, you can do calibration with model.ageing=TRUE. That might help. Eldar
  24. Eldar

    FLightR outlier detection

    Hi Luke, I do not think it is well documented, so I will try to explain it here. Imagine we are at time point (twilight) A, particle filter simulates new positions for point B and from those for point C. After it checks 1. If AB average movement was more than 50 km AND ( 2. AB average distance was > AC.distance*1.3 OR 3. AB.distance>AC.distance AND angle ABC<100 degrees If this condition is satisfied it exclude point B. I know it is not very smart filtering, so I am not a big fan of it. I will be happy if someone programmes something better, e.g. Douglas filter
  25. Eldar

    overlapping stationary periods

    Hi Ana, looks like a bug in the stationary.migration.summary(). Could you please send me the result object and I will try to debug the package (PS I am almost offline now, so do not expect much before early August).
×