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

Footleg drfootleg at gmail.com
Tue Sep 9 11:36:46 CEST 2014


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



More information about the Therion mailing list