Jump to content
Ornithology Exchange

Eldar

General Members
  • Content count

    52
  • Joined

  • Last visited

Everything posted by Eldar

  1. 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)
  2. 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
  3. 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
  4. 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
  5. Hi Louise, datum should be wgs84, you are right. Cheers, Eldar
  6. 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
  7. 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
  8. 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!
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 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
  15. 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?
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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).
  22. Hi Cosme, 1. How do you know that the bird was still on migration? I would say that it is likely that bird had already arrived somewhere (maybe to check other breeding grounds before breeding). If surface is becoming less transparent you will see more or less even darkness, but not several short periods. 2. You should set known.last to TRUE only if you have the very last twilight at the breeding grounds. And you are right if confidence intervals disappear in the end known.last should be FALSE. 3. FLightR also has the find.stationary.location function, so you can try it on your tracks (but it was not tested on the mk tags as far as I know). It also works sometimes if you use calibration from a good track for other devices. Hope it helps
  23. You should definitely exclude twilights with sun being very high up. For FLightR you can also make a higher threshold while defining twilights - it usually works fine.
  24. Eldar

    FlightR Troubleshooting

    That was not an easy one. You had NAs in gl_twl, so somehow you created them there... I have updated FLightR, so now it will recognise the issue and will warn you at the import functions. The latest version is on GitHub. Hope it helps
  25. Eldar

    FlightR and dateline

    (-100, 100) is behavioural mask here and is not related to dateline at all. make.grid functions has following parameters: make.grid(left = -180, bottom = -90, right = 180, top = 90, distance.from.land.allowed.to.use = c(-Inf, Inf), distance.from.land.allowed.to.stay = c(-Inf, Inf), plot = TRUE, return.distances = FALSE, probability.of.staying = 0.5) So number 6 is distance.from.land.allowed.to.stay Hope this helps. Do not know why I specified it in the example above.
×