This is a classic problem, and since I ran foul of it in my own cave data processing software ( http://wscc.darkgem.com/caveconverter/ ) I have heard of two other cases of cave survey software falling into the same trap. The answer is to treat the bearings as vector forces and average the vectors. This works for all cases. I have written a function (averageCompassBearings) to implement this angle averaging in the UtilityFunctions.java source file in my Cave Converter (released under GNU General Public License).
See this article for a discussion of the problem and the maths: http://stackoverflow.com/questions/491738/how-do-you-calculate-the-average-of-a-set-of-angles This will give you very similar results to just averaging the bearing angles when there is no wrap around the 360=0 boundary when the angles are all within a degree or so of each other. But you get quite different answers when the angles are well spaced apart. I believe the average vectors answer is more applicable in the case of bearings. It is not an issue either way for cave survey cases where I hope the bearings being averaged are all of very similar values. But in the case of vector forces pulling on an object, if three equal forces were pulling at angles of 0, 5, and 180 degrees, then the 0 and 180 vectors would cancel each other out, and the remaining vector at 5 degrees would be dominant giving a vector average of 5 degrees. But the simple mean of the 3 numbers is around 61 degrees, which shows how different the results of these two averaging methods can be. Footleg On 8 September 2014 19:47, Bill Gee <bgee at campercaver.net> wrote: > Hello everyone - > > I did some skull time on this problem. I have an idea that might work. Many > numbers need to be run on this to prove that it works in all cases. Would > some of you take a glance and render an opinion? > > This algorithm depends on a floating-point MODulus (or remainder) operation > which I am not sure exists in most languages. Also, I use degree measures > here, but in a real program it would have to be adjusted to (1/2 circle) and > (1 circle) ... 200 grads or pi radians or whatever. > > The starting point is two azimuth readings. Call them FOR1 and BACK1. > > 1) FOR2 = BACK1 + 180 > 2) FOR2 = FOR2 MOD 360.0 > 3) If (FOR1 - FOR2) > 180 then FOR2 = FOR2 + 360.0 > 4) FINAL = ((FOR1 + FOR2) / 2) MOD 360.0) > > Thanks - 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 > > _______________________________________________ > Therion mailing list > Therion at speleo.sk > http://mailman.speleo.sk/mailman/listinfo/therion