Jump to content
Ornithology Exchange


General Members
  • Content Count

  • Joined

  • Last visited

Community Reputation


Profile Information

  • Location
    Newark, Delaware
  • Country
    United States

Recent Profile Visitors

724 profile views
  1. Hi all, Following Eldars advice above I was able to get the other units to work using the calibration of another geo (Thanks again Eldar!). I'm still having difficulties with this one unit and i'm not really sure why. Whenever I run this unit through FlightR it appears that the bird never returned to the breeding ground in the 2010 season, which is possible since we never relocated or captured it, I just think that it's highly unlikely. My first thought was that this unit contains two years of data so I tried splitting it. Once the unit was converted into TAGS format I tried splitting the
  2. I am still having some difficulties analyzing some of the geolocators that have differences between slopes in dawn and dusk. I have tried using the find.stationary.location function, but it provides me with a location that is way different than the original coordinates. All of the geos i'm having difficulties with are females from 2012-2013 and i'm imagining the problem is a lot of shading events on the breeding site which I have been using for the calibration periods. Even when plotting the slopes with the derived location from the find. stationary.location there is still a lot of difference
  3. Hi Eldar, I double checked the start coordinates and they are correct. I went ahead and used the calibration from a tag that worked and I was able to get consistent results. The geos that I was having trouble with were attached to females. I was thinking that since the females spend the majority of their time on their nests during the times that I was using for the calibration period that it may cause extreme shading resulting in the unit believing that it was in another location leading to the calibration of the unit being wrong. Is this a viable hypothesis for these birds? Thanks a
  4. Hi all, I have a few geolocator files that I have not been able to process ( The location estimates are scattered all across the specified grid) and I believe it has something to do with the plot_slopes_by_location function. I know that this function is just to determine whenever the bird leaves the study site, however, in the graph it revealed that there are no dusk estimates after September (see attached picture). All of the geolocators that I have been unable to analyze have this similar problem. I'm not sure if that's actually the root of my problems or if its something else, this is
  5. Hi Simeon, Thank you that definitely helped make it a little more clear. When looking for twilights to exclude should I only be looking at the 2 hours after sunrise and the 2 hours before sunset or do I take into consideration the entire light profile when looking for shading? I'm assuming that light profiles that are constantly showing increases and decreases in light level before/after a twilight are experiencing a shading event. Just for clarification, the ideal light profile would have no light above the set threshold at night and then gradual climb to the max light level and level off
  6. Hi all, I am planning on using FLightR to analyze my data after processing my data in TWGeos, however , i'm still uncertain about when to edit or exclude a twilight. Please correct me if my understanding of this is incorrect, but when you are in stage 4 of editing the red parallel line on the bottom would be your threshold level that you set (Eldar recommended setting it at 1.5). If there are any peaks of light that exceed that threshold during the night the twilight should be excluded from the analysis? Simeon mentioned above that while using a template fit model it's not important to ha
  7. Hi Egow, I believe I received the same error whenever I was trying to process my .lig files. I think the error occurs because the preprocesslight function is looking for tagdata that only has a column for Date and Light, but the .lig files give you four columns. I was able to remedy the situation by using: Lig<-readLig("file.lig") Bird<-Lig[,c(-1,-3)] This way the .lig file that you are using for the preprocess light function only has the Date and Light column that is required. I'm not sure if you are having the same problem that i was having but this worked for me. Hope
  8. Hi Louise, Thank you for all of the advice it was extremely helpful. I am still confused however about when to accept or reject twilights but i'm hoping that I will become more confident with that over time. I'm not sure if this is because of the color palette that I chose was different than the one that you used but my twilights definitely don't have the same colors that you mentioned in your description. Are you aware of a way that I can alter my script in so my twilights align with your ddescription so I can become more clear on what exactly is going on? Thank you again fo
  9. Hello everyone, I have recently begun trying to process a .lig file using TwGeos( although I also have .lux files as well) and i have been having some general problems most likely due to my lack of experience with this software, so I apologize if i'm asking introductory level questions. The code that I have been using is: palette=c(5,2, 9, 3, 4, 1, 13) Twl<-preprocessLight(Bird, threshold = 1.5, offset = 17, lmax = 64, zlim = c(0,64), extend = 0, dark.min = 0, twilights = NULL, stage = 1, point.cex = 0.8, width = 12, height = 4, palette = palette ,gr.
  10. Hi Eldar, I am running my script with 1e6 particles. The lat_lon graph appears to be good to me but I am not confident in that assessment. Both the Lat and Long last locations taken were on the breeding ground. I tried attaching the image here but was unable to figure out how. I think I may be running into trouble before this step though, After running make.claibration() it pops up with 16 warnings (For this particular file. some birds are higher and some are less.) I have looked at the warnings and I am not exactly sure what they mean and how I would go about correcting them. Th
  11. Plotting the Median Lat/Long did prevent the points from falling into the ocean, thank you for that Hendrik. Out of curiosity I ran the same .lux file through the FLightR script 3 times using the same exact settings each time and the locations of the points varied considerably, sometimes moving the same point thousands of kilometers. I am aware that the geolocators have inherent risks with the accuracy, but I was expected a little more consistency in the analysis. Could the inconsistencies be an error in my script or are the units this erratic? \ ~Devin
  12. Hi Hendrik, I misspoke earlier when I said I had it “distance.from.land.to.use=c(-Inf, Inf)” I actually have it set to “distance.from.land.to.use=c(-Inf, 10)”. When viewing the grid in R it only shows the possible locations over land; however, I am still getting points that fall into the middle of the Gulf of Mexico. Any ideas? ~Devin
  13. While using FLightR I am still having a few points fall over the Ocean. I thought that establishing the grid within FLightR and setting the “distance.from.land.to.use=c(-Inf, Inf)” would prevent any points from falling into the Ocean? This is only occurring for a few of the geolocators that I have analyzed although I am still baffled to why this is occurring on the select few. Any advice on why this is happening and/or how to correct this problem would be greatly appreciated. Cheers, Devin
  14. I'm using FLightR to process my geolocator data. After performing the run.particle. filter I am able to plot it successfully using map.FLightR.ggmap, my issue comes after that, I would like to be able to plot those points in ArcMap. Is there a way in which I can export the Lat/Long data and its associated dates from the run.particle.filter to either a .csv or a shapefile? I'm aware that a previous post mentioned it being easy using the ("add xy data") but i couldn't figure it out. Any advice would be greatly appreciated. Thank you, Devin
  • Create New...