Hi Olly - Yep, I figured there was something in the wrap-around that is causing this. As I see it, there are two things to figure out ... 1) What are the edge cases? Is this a problem with 358/180, for example? 355/179? I think some experimenting needs to be done to figure out where the algorithm breaks down. 2) Can an algorithm be devised which is correct for all combinations of forward and backward azimuth readings? Even pathological cases such as 90/91 should be handled in a sane manner. I don't know any survey which would allow the forward and backward shots to differ by a single degree. However, there are probably occasions when a 5 or 10 degree difference has to be allowed. I don't think Therion should determine when the forward and backward shots are too far apart. That is up to the survey team and the person entering the data. Therefore Therion should provide sane handling of all possible cases. It would also be interesting to see if this is still a problem when measuring azimuth in something other than degrees. Does it also happen when using grads? It should ... but it is worth checking. I will try to find some spare time to run a bunch of trial cases. Regards - Bill Gee On Saturday, August 16, 2014 04:38:36 Olly Betts wrote:
On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote:
I am struggling with a couple of survey shots that Therion is not interpretting correctly. It might be a bug in how Therion averages forward and backward compass when the readings are near 360 and 180 degrees.
There's a bit of a gotcha when averaging compass readings, due to the wrap-around at 360/0 degrees.
For example, if we try to average two readings: 359 and 003, then the correct answer (at least assuming we believe them to be equally accurate) would be 001. But if we naively sum and divide by the number of readings, we get (359+003)/2 = 362/2 = 181.
The same issues affects averaging forward and back sights - the only different is that the back sights get altered by 180 degrees before averaging.
I've not tried to find where in therion this is implemented, but it appears to explain what you are seeing here - assuming therion subtracts 180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 = 180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the second.
One of the shots (B11-B12) has compass readings of exactly 0 and 180. This shot displays correctly on the map.
In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this case also fits my hypothesis.
Survex is careful to get these cases right, but unfortunately it seems that when therion uses Survex to process the centreline data, it does the backreading averaging itself before it passes data to Survex, so that doesn't provide a way to work around this problem.
You could put the centreline data in a .svx file, and tell therion to process that and use the .3d file.
Cheers, Olly