CTMM package for migration data?

[Ingo Miller]

Hi guys,

I'm currently analysing some sea turtle GPS tracks and I'm experiencing quite some challenges finding the right method for home range estimations. I would very much appreciate some help implementing ctmm for my data.

 

I first used the adehabitat package and created home ranges based on the ad hoc smoothing parameter which resulted in overestimated UDs. Thus I used LSCV instead which resulted in some errors ("did not converge"), so I moved on to a MKDE approach based on biased radom bridges. The latter works, however, the resulting UDs are very patchy. 

Therefore I wanted to implement the ctmm package for our data set as it sounds very promising. In your papers from 2016 and 2017 I read that you're working on implementing options for migration data. As we used migratory turtles for our study, my first question would be if ctmm is suitable for such data, or if ctmm has been updated for migration data or will be in the near future? The image below shows one of the turtles migrating from south to a foraging ground up north. (I don't want to exclude the 'migration' part of the data as some of the other turtles show some foraging behavior along the way, Hence I need to use the whole track). 

I tried the analysis for one of the turtles which resulted in an extreme overestimation of the home ranges (see figures below: KDE (left), weighted OUF AKDE (right)). I wonder if this is because the turtle is not residential/only residential in the northern part of the track? Plotting the best model also seems not to fit the data even though I used the silders to fit the GUESS object with variogram.fit (see below). 

I'm relatively new to this field and a bit overwhelmed by all the different methods and their pros and cons. Since this analysis is for a publication, I want to make sure to do it right and avoid emberassing myself :P. Is there a way to implement ctmm for migrating turtles or should I use another method/package? If the latter, which one would you recommend instead for migrating marine animals tracked with satellite telemetry (sea turtles in this case)?

I really hope it's okay to bother you with this and I would be very thankful for your (or anyone's) assistance! Just in case you want to look into it, I attached the move object for this example (turtle141738.RData) and the R script. 

Kind regards!

Ingo 

[Christen Fleming]

Hi Ingo,

I believe adehabitat's 'ad hoc' bandwidth is Silverman's rule of thumb, which does tend to be too big for IID data, but can actually be too small if the data are very autocorrelated. In general, I do not recommend LSCV bandwidth optimization, even for IID data, because it is slow and unreliable, as you have experienced. MKDE is not really a KDE method, as there is no bandwidth (or anything else) being optimized to minimize the discrepancy between the estimate and the truth, as is the case in KDE. In the 2015 and 2016 Ecology statistical reports, we pointed out that the IID methods like conventional KDE and MCP and the then newer Brownian-bridge based methods are really estimating two different target distributions, which we referred to as range distributions and occurrence distributions. Range distributions quantify the natural variability in the animal's locations, assuming that they continue the same movement behaviors. Occurrence distributions quantify our uncertainty in where the animal was located during the observation period, and limit to zero area when that information is perfect (high sampling rate + low location error = no uncertainty = zero area). So they do become small and patchy as this happens, because they are inherently sampling dependent.

So you first have to decide what distribution you are interested in (space-use prediction versus the unknown realized trajectory) and then choose a good estimator for that target distribution.

Migratory data are very much autocorrelated. They also tend to be very non-stationary. So they violate pretty much every assumption behind conventional KDE. In your turtle example, I see a migration and then a resident period. That's at least two different behaviors, which implies at least two different range distributions that you could potentially estimate. Also, ctmm is currently limited to stationary movement behaviors, so you can only estimate one distribution at a time, anyhow. Inputting multiple behaviors gives you an average behavior, which, in this case, I don't think makes much sense.

I took your turtle data and subset a more resident period with the cleave() function, checked the fit and asymptote, and everything looks okay for that portion of the data (figures attached), though there looked like some additional bi-monthly oscillation that I didn't get into. If you have a lot of turtle migrations to segment, I have heard good things about the segclust2d package.

Now you might also consider the range distribution for the migratory segment, but with only one migration the effective sample size will be ~1. In fact, I got for the fit summary()

$DOF
     mean      area     speed
 1.118727  1.167536 83.811972

The range distribution is trying to predict what future migrations will look like if similar migratory behavior persists, but you can't really estimate variability with a sample size of 1. The result will have massive confidence intervals and is much larger than the data due to severe non-independence. However, you can estimate things like distance and calculate an occurrence distribution, which is basically CIs on the unknown migratory trajectory.

Best,

Chris

[Ingo Miller]

Hi Chris,

I finally got around to work on that project again.

I followed your suggestion and used the segclust2d package (which works great BTW) to filter out the stationary phases of my tracks and used these to run ctmm. Now I get really nice home range estimations!

Thanks so much for your help and your detailed comment :)

Cheers

Ingo