Jump to content
Ornithology Exchange

Mendez

General Members
  • Content count

    14
  • Joined

  • Last visited

Community Reputation

0

Profile Information

  • Location
    Newark, Delaware
  • Country
    United States

Recent Profile Visitors

331 profile views
  1. Mendez

    plot_slopes_by_location

    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 data in half to make it similar to a geo that had a single year of data. This seemed to work slightly better than trying to run it as a single unit, but the results were still scattered everywhere. All of these failed attempts I was using a different geo for the calibration, I cant run the calibration otherwise. I'm not sure what else to do, any advice would be greatly appreciated!
  2. Mendez

    plot_slopes_by_location

    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 differences between the slopes. In the tool help it says that it does not work well with shaded data which i believe is the case. Eldar recommended above to use the calibration extracted from a tag that worked. Should I try using a calibration file that was extracted from the same year? Also while using the calibration file from another geo i'm still not confident that i'm doing it correctly. I took the proc.data from a working geo and calibrated it normally. I would then plug in the proc.data from the geo that did not possess a calibration period into make.prerun.object with the calibration file from the working geo. Is this the correct workflow? I used this method with one of the problem geos and it appeared to work, but upon closer observation the dates did not align at all with the units previously analyzed.
  3. Mendez

    plot_slopes_by_location

    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 again, Devin
  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 just my best guess. Is anybody aware if this could be the problem and if it is is there anyway to correct for this problem? Thanks, Devin
  5. Mendez

    General TwGeos questions

    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? Has there been an article that describes/shows examples of the criteria for rating and transitions or deleting twilights as suggested in Eli Bridges paper Advances in tracking small migratory birds: a technical review of light-level geolocation? Devin
  6. Mendez

    General TwGeos questions

    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 have the exact twilight time, therefore is it worthwhile to edit the twilight at all? Lastly is there any other criteria in which a twilight should be excluded from analysis? any examples of this would be greatly appreciated. Thanks, Devin
  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 this helps, Devin
  8. Mendez

    General TwGeos questions

    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 for all of your help, Devin
  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.Device = "default") Stage 1: Is the point of the subset function to remove the twilights that occured before and after the geo was attached? Stage 2: I don't think I have been performing this stage right, I'm not exactly even sure what i'm supposed to be doing.. Stage 3: I believe that this step is dependent on the previous one, but regardless I'm not sure how to identify whether a twilight is missing or if one has to be added. Stage 4: My light profiles do not show sunrise and sunset in one screen, is there a mistake in my code that would fix this? I'm also not sure what a bad twilight looks like and which ones should be marked for deletion. I have gone through this process several times trying different methods and settings to familiarize myself with it but have been unsuccessful. After accepting the twilights that I believed were acceptable i saved my edits and exited out of the window, this provided me with a subset of data and 8 warning messages that are as follow: Warning messages: 1: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 2: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 3: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 4: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 5: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 6: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 7: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. 8: In structure(xx, class = c("POSIXct", "POSIXt"), tzone = tz) : Calling 'structure(NULL, *)' is deprecated, as NULL cannot have attributes. Consider 'structure(list(), *)' instead. I'm not sure if these warnings are due to me performing one of the previous stages wrong or are normal errors associated with the package. Any help relating to these problems would be greatly appreciated. Thank you, Devin
  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. The warnings are as follows: Warning messages: 1: In log(cur.slope$slope) : NaNs produced 2: In log(All.slopes$Slopes$Slope) : NaNs produced 3: In log(cur.slope$slope) : NaNs produced 4: In log(All.slopes$Slopes$Slope) : NaNs produced 5: In log(all.slopes$Slopes$Slope) : NaNs produced 6: In log(Slope) : NaNs produced 7: In log(Slope) : NaNs produced 8: In log(Slope) : NaNs produced 9: In log(Slope) : NaNs produced 10: In log(cur.slope$slope) : NaNs produced 11: In log(All.slopes$Slopes$Slope) : NaNs produced 12: In log(all.slopes$Slopes$Slope) : NaNs produced 13: In log(Slope) : NaNs produced 14: In log(Slope) : NaNs produced 15: In log(Slope) : NaNs produced 16: In log(Slope) : NaNs produced
  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
×