Jump to content
Ornithology Exchange
  • 0
Mendez

Points being estimated in the Ocean

Question

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

Share this post


Link to post
Share on other sites

8 answers to this question

Recommended Posts

  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

  Completely agree with Hendrik, and would also suggest plotting these specific twilights separately to see how the probabilities are distributed. Something like:

plot_util_distr(Result, dates=data.frame(as.POSIXct(‘2013-12-01’),
                               as.POSIXct(‘2014-01-31’)),
                               add.scale.bar=TRUE, percentiles=c(0.25, 0.5, 0.75)) 

  Eldar

Share this post


Link to post
Share on other sites
  • 0

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

 

Share this post


Link to post
Share on other sites
  • 0

  Hi Devin,

 1. Check whether you run your script with one million (1e6) particles.

 2. Check whether you are loosing uncertainties during the run. They are best to see on the lat_lon graph. If you are loosing them in the end of the track, switch known.last to FALSE in the run.particle.filter().

 You can post the lat_lon graph here if you are not sure wheter it is good,

    Eldar

Share this post


Link to post
Share on other sites
  • 0

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

Share this post


Link to post
Share on other sites
  • 0

  Hi Mendez,

 The warnings are not a problem, just ignore them.

 Send image to me privately and I will have a look. The assessment of the quality is based on the amount of uncertainties in the end of the track. Ideally it should be comparable with the other parts and if you loos it (and have just lie without uncertainties) it means something went wrong. 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×