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
