Estimating Flight Height Above Ground with ctmm — Best Practices?

33 views
Skip to first unread message

lisa king

unread,
Sep 19, 2025, 3:05:35 AMSep 19
to ctmm R user group

Hi Chris,

First off, thank you for such a well-documented and powerful package. I've been using ctmm to explore GPS data from our bat tracking projects and it's been incredibly helpful.

I'm currently trying to estimate flight height above ground (i.e., GPS altitude minus terrain elevation), but I'm running into challenges due to uncertainty in both telemetry and terrain data. Unfortunately, this is compounded by not being able to estimate UERE from tag calibration data (different tag settings to the survey data).

I’ve tried two approaches:

  1. Modeling flight height directly as GPS altitude – terrain height, but this often yields negative values — likely because only telemetry error is accounted for.
  2. Modeling GPS altitude and subtracting terrain height from the point estimates, but this still contains error from multiple sources and results in negative flight heights.

Is there a recommended best practice for handling this within ctmm? Or would I need to resort to a more customized method that accounts for terrain uncertainty — something I’d prefer to avoid due to time constraints?

Any guidance or suggestions would be greatly appreciated!

Thanks again for all your work on ctmm.

Best, Lisa

Christen Fleming

unread,
Sep 25, 2025, 10:41:49 AMSep 25
to ctmm R user group
Hi Lisa,

When using a unbounded model like the Gaussian one in ctmm, you should expect to get some negative point estimates, but these are okay if you keep the uncertainties and propagate those in further analyses. For an example of something more sophisticated, you can use a link function to transform the locations close to the boundary (ground) where the organism doesn't tend to fly: https://besjournals.onlinelibrary.wiley.com/doi/full/10.1111/1365-2664.12909

As for modeling height relative to the ellipsoid versus modeling height relative to the DEM, you can do both and compare AIC/BIC, because this is just a shift of the data.

Best,
Chris

lisa king

unread,
Sep 25, 2025, 8:05:02 PMSep 25
to ctmm R user group
Thanks Chris.

It seems to me then I'd do best to 
  1. fit ctmm (x,y) as well as ctmm (z), and
  2. PRED <- predict(DATA,CTMM=FIT,VMM=zFIT,complete=TRUE)
Then for each of my detections
  1. find DEM value range within predicted (x,y) error range
  2. propagate uncertainty in DEM due to uncertainty in (x,y), and uncertainty in DEM due to pixel size through to z estimates
To help with this, is there an easy way to extract the (x,y) error ellipses as polygons so I can find DEM values that fall within them?

And thanks for that ref. I've come across it before and found it so interesting for my project.
I even managed to get it working with some of my data...
but the hurdles I had were (i) I'd have to re-write to C++ code for alternative models when my data doesn't conform to OU-p process (not trivial for a C++ beginner like me)
(ii) I wasn't sure how to incorporate diagnostics for the template in this format

 Not a hurdle, but an observation, that my detections would also need to be regularised (these are night detections of a nocturnal species), this being a discrete time model rather than continuous time.

If you have any thoughts on the above I'd really appreciate it.

Kind regards,
Lisa

Christen Fleming

unread,
Sep 26, 2025, 1:42:56 PMSep 26
to ctmm R user group
Hi Lisa,

You can export the error ellipses. See help("export")

For the provided reference, you can apply its link function to your data before running ctmm models, and then run a nested optimization for its length parameter, though that will be fairly slow.

Best,
Chris
Reply all
Reply to author
Forward
0 new messages