[Therion] What is going on with these survey legs?

[Bill Gee]

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