AKDE() processing time under different CRS

71 views
Skip to first unread message

Amelia J

unread,
Mar 21, 2025, 9:46:43 AM3/21/25
to ctmm R user group
Hi there,

I ran my code for an individual's home range and checked the UD in QGIS and noticed the outputs were slightly off from where I'd expect based on the points (i.e. the 'rearing season' UD to the right of where I'd expect it given knowledge about the individual's den). I tried to correct this by giving the Albers Equal Area projection during as.telemetry() – the choice of this projection is because eventually I'll be rolling this out to all individuals, and they are scattered across Australia.

However, I noticed once I specified this projection I'm having trouble producing the UD – I'm not sure if it is just taking an extremely long time for some reason related to the CRS, or if there is something wrong with the code but it isn't throwing up any errors.

My code:
# Data into MOVEBANK format
data <- data %>%
  select(individual.local.identifier = id, timestamp = date_aest, latitude, longitude, HDOP = hdop, site)

# I separate data into "breeding" season and "whelping" season datasets using filter()
# Convert to telemetry
breeding <- as.telemetry(breeding, projection = "EPSG:3577")
whelping <- as.telemetry(whelping, projection = "EPSG:3577")

# Check projection (is the same for both)
projection(breeding)
[1] "+proj=aea +lat_0=0 +lon_0=132 +lat_1=-18 +lat_2=-36 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs"
I notice that using EPSG:3577 gives a GRS80 ellipsoid which seems strange.

# I create the fits - I would note in this code the breeding & whelping data going into fits were made before I tried to adjust the CRS, so they aren't in EPSG:3577, but rather the azimuthal equidistant projection. I didn't see why this would matter but perhaps it does.
seasons <- list(
  breeding  = breeding,
  whelping  = whelping)
numCores <- 4
cl <- makeCluster(numCores)
registerDoParallel(cl)
fits <- foreach(season_name = names(seasons), .packages = 'ctmm') %dopar% {
  telemetry_data <- seasons[[season_name]]
  guess <- ctmm.guess(telemetry_data, CTMM = ctmm(error = 10), interactive = FALSE)
  fit <- ctmm.select(telemetry_data, guess, method = "ML", verbose = FALSE)
  list(season = season_name, fit = fit, guess = guess)}
stopCluster(cl)

# The fit output is assigned to it's respective season (so fit_breeding, fit_whelping)
# AKDE:
AKDE_breeding <- akde(breeding, fit_breeding, weights=FALSE)
AKDE_whelping <- akde(whelping, fit_whelping, weights=FALSE)

And it doesn't work - but no error, and I've waited a few hours before stopping the processing. On the other hand, if I ignore the projection = "EPSG:3577" and use the standard method below, then the AKDEs are produced within 1-2 minutes (but has the original problem I mentioned, and I'd like it to be in Albers anyway, for comparison with environmental rasters etc):

seasons <- list(breeding, whelping)
projection(seasons) <- median(seasons)
breeding <- seasons[[1]]
whelping <- seasons[[2]]
projection(breeding) (same for both)
"+proj=aeqd +lat_0=-32.6043534399407 +lon_0=152.243436037461 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs"
AKDE_breeding <- etc.

Any advice would be really appreciated!
Best,
Amelia

Christen Fleming

unread,
Apr 30, 2025, 4:16:56 AM4/30/25
to ctmm R user group
Hi Amelia,

Sorry for the delayed response.

https://epsg.io/3577 says that EPSG:3577 is in the GRS 1980 datum.

The data & model fit objects need to be in the same projection in meters. You seem to be saying that they are not? This should cause an error, and if it doesn't then I will double check the code.

I suspect the original issue is from the datum. When you import long-lat data, you need to supply the datum if it is not the default WGS84, and GRS80 is not the default WGS84.

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