Incorporating error from trilateration locations

[Christopher Tyson]

Hi Chris,

I would like to incorporate errors from locations that are estimated via trilateration. (This is sort of a follow-up and elaboration on my recent post about getting the error ellipse features.)  As a bit more background, I am using an automated radio tracking system where we have ~80 receiver nodes spaced ~100 m to track passerines. From field calibrations, we know that the error is considerable in some areas of the node network (e.g. if a tag is far away from any nodes). Conversely, it is much lower when tags are close to a node. Overall the median error is ~26 m.

My question is what would be the best way to go about incorporating error? I see a few possibilities. 

1) Use a fixed value based on the median error from field calibration.

2) Model the error of a given localization using features of the localization, such as the RSSI values, and then assign each localization a predicted error. This would also use the field calibration data we have. 

3) Use the 'error ellipse' from the estimated locations. Locations are estimated using this method, roughly. This would not use the calibration data though, but would use the error from each localization. In the error vignette, however, I thought it was stated not to use uere.fit() on animal tracking data. So then is it appropriate to assign the error this way? Hope I'm not misunderstanding this point... 

Probably there are more and better options? Also, would you ultimately recommend trying each and comparing? 

Thank you very much in advance for your time and for developing the ctmm package. It is a tremendously powerful tool to be able to use!

Best,

Chris

[Christen Fleming]

Hi Chris,

The simplest solution would be to import the estimated error ellipses and just set error=TRUE in the ctmm.guess object before fitting.

When you say that the errors are larger in some areas of the network, my question is whether or not this is captured by the estimated error ellipses. If the error ellipses capture this, then there really isn't an issue. And if it's just a matter of the tag being far away from any nodes, then the error ellipse estimates should have that modeled already.

Calibration data is more necessary for GPS data when the device only provides a DOP value, which is only proportional to an error circle. Calibration data then provides the proportionality constant to calculate the error circle. This is not the problem that you are faced with here. I actually do not have code in place to calculate error ellipses from calibration data, because I have not run into a data/device type that only provides a relative error ellipse and requires calibration data to complete that calculation.

Best,

Chris