Jump to content
Ornithology Exchange

Hendrik

General Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0

Profile Information

  • Location
    Auckland
  • Country
    New Zealand
  1. Hendrik

    plot_slopes_by_location

    Hi Mendez, how did you call dawn and dusk times before loading the data into FlightR. Have you used the BAStag package? If yes, were the missing dusk events correctly selected by the package for these tags? Did you possibly subset the data before using plot_slopes_by_location? Maybe something went wrong there? All the best and have a nice day! Hendrik
  2. Hi Devin, are you plotting the "mean" or "median" locations? If I recall right from another post, only the median will stick to the landmask. Try to plot median locations and see whether the problem is fixed. Let me know how it goes :-) Hendrik
  3. Hi Devin, "inf" stands for infinity, so, as far as I understand it, using “distance.from.land.to.use=c(-Inf, Inf)” will allow the locations to fall on the ocean. Try :“distance.from.land.to.use=c(-Inf, 0)”. It is all described in detail in the Cran pdf for Flight R. See description from the package below: distance.from.land.allowed.to.use - define how far from the shoreland animal could occur. Unit - km, negative values are for inland and positive for offshore directions. Inf stays for infinity. Hope that helps! Hendrik
  4. Hi Devin, I am using FlightR, too. You can access the data like this: write.csv(Result$Results$Quantiles, file="Nameofyourfile.csv",quote=FALSE, row.names=FALSE) The file contains means, medians of lon and lat as well as time stamps and confidence estimates. I hope that helps! :-) All the best, Hendrik
  5. Thanks Eldar, map.FLightR.ggmap works fine for me now. The plot_util_distr only caused me trouble on my macOS machine, turned out it works fine on windows. Thank you very much for your help Eldar, very much appreciated! Hendrik
  6. Hendrik

    dealing with calibration periods

    Dear Luke, I am also using FlightR to analyze Light Data from Migrate Technology, however I used them on skua and not on burrow nesting seabirds. I am not a modelling expert, but let me share my experience with you. For calibration, I have put all retrieved loggers post deployment in an open space for rooftop calibration. Ideally you have pre and post deployment calibrations, but the post calibration only seems to work fine for me. Ideally, you perform the calibration on each logger that was actually on the bird. However, I have tried using other logger's for calibration where only few or poor calibration data from the actual logger was available. The results do not differ much in most instances. The way I understand it, it does not really matter where you perform your calibration as long as you enter the correct calibration location into FlightR. The way I understand it, the calibration is used to compare the actual light curves measured by the logger with theoretical light curves for that specific location. So it should not matter at all where your birds were at the time of calibration, since you know where your calibration loggers were at the time. Please let me know if I got something wrong. I hope I could help you, but lets see what Eldar says! PS: Maybe just try and create a calibration object with one of your calibration loggers. then load the light data of one of your birds (create a Proc.data object), and subsequently create a pre-run object with those. Run the model and see whether the results make sense! From my experience (skuas data is very shady during breeding) it is best to exclude very shady data and only use actual migration periods (i.e, times the birds were pelagic) for analysis. Hendrik
  7. Dear Eldar, I am sorry for the double post, but I think this got lost in the end of a previous post that was already answered. I receive two error messages when using the functions map.FLightR.ggmap and plot_util_distr: 1. map.FLightR.ggmap map.FLightR.ggmap(Result) Error: longitude of center must be between -180 and 180 degrees. note ggmap uses lon/lat, not lat/lon. In addition: Warning message: In min(Result$Results$Quantiles$Medianlon[twilights.index][Result$Results$Quantiles$Medianlon[twilights.index] > : no non-missing arguments to min; returning Inf Interestingly this only happens when either using certain grid boundaries for the spatial extent or if the bird under investigation uses certain areas, I am not quite sure what the pattern is. So far I could trigger the error as soon as I extended the right boundary above lon -160 e.g., Grid<-make.grid(left=160, bottom=-80, right=-140, top=-10, distance.from.land.allowed.to.use=c(-Inf, Inf), distance.from.land.allowed.to.stay=c(-Inf, Inf)) will trigger it while Grid<-make.grid(left=160, bottom=-80, right=-160, top=-10, distance.from.land.allowed.to.use=c(-Inf, Inf), distance.from.land.allowed.to.stay=c(-Inf, Inf)) does not produce an error. UPDATE: It actually seems to occur when a position with longitude >-160 (e.g., -140) is plotted! However, it also occurs sometimes if e.g., longitude >-140 is used. My feel is that this is also a ggmap related issue and may once again have to do with the dateline. 2. running plot_util_distr error I don't think it is related as it is a sp error, but I get an error message when running plot_util_distr: plot_util_distr(Result, + dates=data.frame(as.POSIXct('2016-03-03'), as.POSIXct('2016-08-07')), + add.scale.bar=TRUE, percentiles=0.5) function will plot 308 twilights Error in sp::CRS(aeqd) : major axis or radius = 0 or not given I am very thankful about your comments on this. All the best and keep up the great work Eldar!, Hendrik
  8. Dear Eldar, I have a possibly related error message when running the plotting function: map.FLightR.ggmap(Result) Error: longitude of center must be between -180 and 180 degrees. note ggmap uses lon/lat, not lat/lon. In addition: Warning message: In min(Result$Results$Quantiles$Medianlon[twilights.index][Result$Results$Quantiles$Medianlon[twilights.index] > : no non-missing arguments to min; returning Inf Interestingly this only happens when using certain grid boundaries for the spatial extent. So far I could trigger the error as soon as I extended the right boundary above lon -160 e.g., Grid<-make.grid(left=160, bottom=-80, right=-140, top=-10, distance.from.land.allowed.to.use=c(-Inf, Inf), distance.from.land.allowed.to.stay=c(-Inf, Inf)) will trigger it while Grid<-make.grid(left=160, bottom=-80, right=-160, top=-10, distance.from.land.allowed.to.use=c(-Inf, Inf), distance.from.land.allowed.to.stay=c(-Inf, Inf)) does not produce an error. UPDATE: It actually seems only to occur when a position with longitude >-160 (e.g., -140) is plotted! My feel is that this is also a ggmap related issue. I don't think it is related as it is a sp error, but I get an error message when running plot_util_distr: plot_util_distr(Result, + dates=data.frame(as.POSIXct('2016-03-03'), as.POSIXct('2016-08-07')), + add.scale.bar=TRUE, percentiles=0.5) function will plot 308 twilights Error in sp::CRS(aeqd) : major axis or radius = 0 or not given I am very thankful about your comments on this. All the best and keep up the great work Eldar!, Hendrik
  9. Hendrik

    Deleting Twilights in BAStag

    HI Eli and Amelie, I just had a look at this post and have a question myself. As previously discussed, BasTag only marks deleted twillights as "deleted", but keeps them in the output file. Once converted into TAGS format, these twilights are marked as excluded = TRUE. Now my question is, will FlightR automatically exclude these twilights marked as "excluded" from the analysis? Thanks a lot for clarifying and have a good start in 2017! All the best, Hendrik
  10. I think I solved the problem already. I managed to edit the existing function "readMTdeg" the following way: readMTdeg2 <- function(file,skip=20) { ## Read csv file and add column names d <- read.table(file,header=FALSE,skip=skip, sep="\t",col.names=c("Date","Activity"), colClasses=c("character","numeric")) #Parse date # Use %I, since the Intigeo time data are provided as decimal hours (12 hour) d$Date <- as.POSIXct(strptime(d$Date,"%d/%m/%Y %I:%M:%S %p",tz="GMT")) #Return data frame. d } That seems to work well in case someone else comes across this issue. Hendrik
  11. Hi there and a belated merry Christmas, I was just looking into importing ".deg" files (immersion count data as provided by Intigeo loggers) into BAStag and was delighted to see that a function ("readMTdeg") has recently been added. However, something seems to be off, the description of the function states "Read Temperature data from a Migrate Technologies tag", which basically resembles the description of "readMTsst" which serves to importing ".SST" files (which contain temperature and conductivity data). Importantly, ".deg" files contain immersion count data only. When executing "readMTdeg" I get: Error in scan(file = file, what = what, sep = sep, quote = quote, dec = dec, : line 1 did not have 6 elements These six elements are almost certainly referring to the six elements found in the readMTsst function. I am therefore wondering whether the wrong code may have accidentally slipped into the new "readMTdeg" function. A function to import .deg files (immersion count data) into Bastag would be extremely helpful. My (tedious) workaround at the moment is to manually convert them into the more common ".act" format as provided by Bastag loggers. I will post this issue on the appropriate Github page as well: https://github.com/SWotherspoon/BAStag/issues/7 Any comments or help would be very much appreciated! thank you very much and have a good start into the new year! Hendrik
  12. Thank you Eldar, your help is much appreciated! All the best, Hendrik
  13. Hi Eli and Eldar, I have a question about FlightR that I was hoping you may help me with. I found in your 2015 movement ecology paper that the FlightR includes a spatial/behavioural mask that prevents a stationary state on over large water masses. This makes sense when studying most shorebirds, but I was wondering whether that applies when a seabird is the study species, which may sit on the water for a long time e.g., during moult. I was therefore wondering whether a stationary state above sea is prevented by default and if that's the case, whether there is a way to allow stationary states on large water masses? My concern was that say a stationary state is prevented on water that this may cause artificial movement in a seabird that is sitting in one area on the ocean for several days. Thank you very much in advance for your help on this topic, your help is very much appreciated. All the best and have a nice weekend! Hendrik
  14. Hendrik

    FlightR and dateline

    Hi Eli and Eldar, thank you very much for your support with this, Eldar has solved the problem and its working perfectly fine now. Thank you both for your support! All the best, Hendrik
  15. Hi there, I am new to this forum. I am a phd student at Auckland University, New Zealand. One of my chapters is on wintering patterns of brown skua from the Chatham Islands using light-level geolocation. I was delighted to see Eldar's publications on FlightR early this year and started try and re-analyse my tracks using the FlightR package. Unfortunately, I ran into a potential problem with some of the tracks. My study site, the Chatham Islands, are as close as you can get to the international dateline (it runs right between the Chathams (Lon -176) and New Zealand (lon +170). I think I ran into a potential problem when a bird crosses the dateline: when setting up the spatial extent for the model, I would want to set the left boarder of the grid at a positive longitude in New Zealand (e.g., lon +170 ) . The right boarder would be a negative longitude (roughly –150, east of the Chathams). Unfortunately, when setting the grid in the spatial extent, R won’t let me do that. Has anyone encountered this problem before and do you know a way around it by any chance? I was hoping that the problem can be fixed by changing the central meridian within the model. Thank you very much for your support! All the best, Hendrik
×