Dealing with PTT location error classes

[Matthew Butler]

I am currently working with data from a project that used PTTs equipped with a GPS antenna.  These GPS data have fix quality classes (Fix_qual = 1 thru 4 where 1 = 0-25 m, 2 = 26-50 m, 3 = 51-75 m, and 4 = 76-100 m).  Like other ARGOS type data, are these classes the same as the error classes that CTMM will automatically convert to error ellipses using calibration results from Vincent et al. (2002).  Or are calibration data needed for this type of data?  I was planning on renaming 'Fix_qual' as 'Argos.location.class' but I am not sure they are the same thing?  Any help would be much appreciated.

Best,

Matthew Butler

[Christen Fleming]

Hi Matthew,

You do not want to use the Argos Doppler-shift location class calibrations, as those are completely different (kilometer scale errors).

Because that scale is linear, I would actually rename that column "DOP" and calibrate from there. You either need calibration data or more specific knowledge of what those numbers correspond to (a quantile % or number of standard deviations).

Best,

Chris

[Matthew Butler]

Wow, thanks for the quick response Chris.  I believe the project has some calibration data.  How important is it to incorporate location error when it is on the order of 10s of meters and home ranges are on the order of 1000s of hectares?

Best,

Matthew Butler

[Christen Fleming]

Hi Matthew,

The more relevant comparison is to how far the animals travel between location fixes. If the data were very coarse as to be IID, then those scales would be the same and I would say that the location error is not important.

Best,

Chris

[Matthew Butler]

That makes good sense.

Thanks,

Matt

[Matthew Butler]

Chris,

The project has a data set from test transmitters placed at 15 different known locations.  From this test, there were 211 location fixes obtained which resulted in 211 estimates of absolute distances that fix locations were from known locations.

On average, transmitter fixes were 8.9 m from the known location with a SD of 5.7.  This can be broken down by fix_qual classes where class 1 was an average of 7.5 m from the known location with a SD of 3.8, class 2 was 10.1 m with a SD of 4.7,  and class 3 was 20.9 m with a SD of 10.5.  Only one fix was in class 4 with an error of 27.9 m.  These transmitters were on a large coastal bird with re-locations occurring between 4 and 6 hours.  The average distance between re-locations was 1075 m with a SD of 3322.

The help documentation suggests the error argument can be "an estimate of the error's standard deviation."  In this case we have multiple estimates for different fix_qual classes.  Can the error argument in the ctmm function be used to include error information for multiple error classes (i.e., multiple SDs for a given data set) or is it limited to using one SD value?

Best,

Matt

[Christen Fleming]

Hi Matt,

Do you have calibration data itself (and not just the results)? If so, you can use the functions described in vignette('error') to calibrate the data.

Otherwise, I would probably use metafor to fit a linear model to the results.

In either case, I would treat the location classes as DOP=1-4.

Best,

Chris

[Matthew Butler]

Thanks Chris,

I have the raw data. However, 3 of the tests return an error from as.telemetry() -- 'Error in if (sum((mu1 - mu2)^2) > sum((mu[1, ] - mu[2, ])^2)) { : missing value where TRUE/FALSE needed'

Not sure what is happening here but I have pasted the data for one of the tests that returns the error message.

ID	date	LAT	LON	DOP	edist
A6	9/12/2014 17:46	40.7945	-98.4619	1	2.870389
A6	9/12/2014 22:33	40.7944	-98.4618	1	11.27777
A6	9/13/2014 3:21	40.7944	-98.4618	2	11.27777
A6	9/13/2014 8:08	40.7945	-98.4618	1	6.238478
A6	9/13/2014 12:55	40.7944	-98.4618	1	11.27777
A6	9/13/2014 17:43	40.7945	-98.462	1	10.95018
A6	9/13/2014 22:36	40.7944	-98.4619	1	9.823883
A6	9/14/2014 3:24	40.7944	-98.4618	2	11.27777
A6	9/14/2014 8:11	40.7944	-98.4618	1	11.27777
A6	9/14/2014 12:59	40.7944	-98.4618	1	11.27777
A6	9/14/2014 17:46	40.7945	-98.4618	1	6.238478
A6	9/14/2014 22:37	40.7944	-98.4618	2	11.27777
A6	9/15/2014 3:25	40.7944	-98.4618	1	11.27777
A6	9/15/2014 8:12	40.7944	-98.4618	1	11.27777
A6	9/15/2014 12:59	40.7944	-98.4618	1	11.27777
A6	9/15/2014 17:47	40.7944	-98.4618	2	11.27777
A6	9/15/2014 20:39	40.7944	-98.4618	1	11.27777
A6	9/16/2014 1:27	40.7945	-98.4618	1	6.238478
A6	9/16/2014 6:14	40.7945	-98.4618	1	6.238478
A6	9/16/2014 11:02	40.7944	-98.4618	1	11.27777
A6	9/16/2014 15:49	40.7944	-98.4618	1	11.27777

Best,

Matt

--
You received this message because you are subscribed to the Google Groups "ctmm R user group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ctmm-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ctmm-user/0d5cb4b6-675a-451e-afd2-c70e04ff4884n%40googlegroups.com.

--

----------------------------------------------------------------------
Matthew J. Butler

806.786.6399

[Christen Fleming]

Hi Matt,

If you send me the file, I can take a look.

Best,

Chris

[Matthew Butler]

Thanks, I have attached a text file containing the problematic data.

error=read.delim("C:/Users/mbutler/Desktop/errorA6.txt")
error$date=as.POSIXct(error$date,tz="Etc/GMT-6",tryFormats=c("%m/%d/%Y %H:%M"))
error.telem=as.telemetry(error) # The Error message is generated here.

Best,

Matt

You received this message because you are subscribed to a topic in the Google Groups "ctmm R user group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ctmm-user/apvTPaMeJmk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ctmm-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ctmm-user/e35b298d-88e5-4338-84bf-444b13f3a5e9n%40googlegroups.com.

[Christen Fleming]

Hi Matt,

It should be fixed now on GitHub, which you can install via: devtools::install_github("ctmm-initiative/ctmm")

The code in median() didn't expect >=50% repeating locations in a dataset, which was here caused by this being a calibration dataset and the long-lat having a lot of truncation error.

Best,

Chris

[Matthew Butler]

Chris,

Thanks for debugging this and updating the package to accommodate data like this.

Best,

Matt

To view this discussion on the web visit https://groups.google.com/d/msgid/ctmm-user/77a1c21e-5792-4501-b41f-2a9fb19e376fn%40googlegroups.com.