Issues importing error ellipses with trilateralized data

[steveh...@gmail.com]

Hi Chris,

I am trying to import location data estimated from a UHF node array. I used a similar trilaterization method as described in this discussion. I created the Argos.semi.major, Argos.semi.minor, and Argos.orientation columns using the methods from code from that conversation.

When I try to import using as.telemetry() I get the following error:

Error in `$<-.data.frame`(`*tmp*`, "COV.minor", value = numeric(0)) : replacement has 0 rows, data has 220

When I remove the Argos columns, I can successfully import the data.

I've attached code and data that replicates the issue on my machine (using the Github package and R 4.4.1).

Thanks!

Steve

[Chris Tyson]

Hi Steve,

You are selecting 'Argos.semi.major' twice. If you change one of them to 'Argos.semi.minor' in select() then as.telemetry() will run.

Cheers,

Chris (Tyson)

[steveh...@gmail.com]

Ah thanks for noticing that!

I changed it, but I still get an error: Error in `[[<-.data.frame`(`*tmp*`, DOP.LIST$horizontal$VAR, value = numeric(0)) :

  replacement has 0 rows, data has 220

[steveh...@gmail.com]

So it looks like this was an issue with the github version of ctmm (1.2.1). 

The code works as intended for the CRAN version of the package (1.2.0).

[Jonathan Rutter]

Hi Chris (not sure which one!),

I encountered a similar error to Steve while trying to convert an Argos dataframe into a telemetry object with ctmm 1.3.0. My dataframe includes semi-major and semi-minor error plus ellipse orientation, and I have averaged error.radius available as well. When I ran the dataframe without error.radius, I received the same error as Steve:

Error in `[[<-.data.frame`(`*tmp*`, DOP.LIST$horizontal$VAR, value = numeric(0)) : replacement has 0 rows, data has 34

When I ran the dataframe with error.radius included, I produced a telemetry object with a new HDOP column and horizontal UERE = 1. My interpretation was that this object now included estimates of circular error, so it was useful but not as good as elliptical error. At this point I went to the source code of as.telemetry() on Github, and I found some interesting things that I would like to check with you. The relevant block of code is in lines 889-893, labelled here as 1-5:

1.     DATA[[DOP.LIST$horizontal$VAR]] <- pull.column(object,ATTRIBUTE$COV.mean)^2/2
2.     NAS <- is.na(DATA[[DOP.LIST$horizontal$VAR]])
3.     if(any(NAS))
4.     { DATA[[DOP.LIST$horizontal$VAR]] <- (DATA$COV.minor + DATA$COV.major)/2 }
5.     DATA$HDOP <- sqrt(2*DATA[[DOP.LIST$horizontal$VAR]])

My understanding here is that, when Error.radius is supplied, line 1 brings in COV.mean as the horizontal error. Then line 2 detects no NAs, so line 4 does not run and the error ellipse info is ignored. When Error.radius is not supplied, pull.column() in line 1 returns NULL (length 0), which I am assuming is the cause of the error that Steve and I saw.

From here, I thought that I could produce my own version of the function that set DATA[[DOP.LIST$horizontal$VAR]] to a vector of NAs, thereby allowing lines 3-5 to run. But I realised that even if I do run these lines, the major and minor elliptical error values are simply averaged in line 4, so I think this is effectively circular error (which explains why it has been coded to only fill in NAs of error.radius). I looked through the rest of the source code and it seems that this also happens elsewhere in the script - elliptical error in the dataframe is converted to circular error in the telemetry object. This will still work for my analysis, but it would be much better if I could incorporate elliptical error.

So my questions are as follows:

1. Is this a valid interpretation of the code? (Apologies if I've missed something obvious.)
2. If Argos error is indeed modelled as circular, is there a way to use uere()<- to manually set elliptical error of a telemetry object? The Telemetry Error vignette shows how to do this for a constant value, but I am not sure how to do this when elliptical error varies point by point.

Many thanks!

Jonathan