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

2014-09-09 Thread Footleg
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  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



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

2014-09-09 Thread Olly Betts
On Mon, Sep 08, 2014 at 01:47:57PM -0500, Bill Gee wrote:
> 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)

For 1 and 179, that gives me 180, rather than 0.

What Survex does is more complex, as the foresight and backsight may
have different standard deviations specified, and it's working in
radians at this point, but in the case where the two instruments are the
same specified accuracy (which seems likely to be by far the most
common), it boils down to this (fabs() is the absolute floating point
value - i.e. drop any minus sign):

backcomp -= 180;
diff = comp - backcomp;
adj = fabs(diff) > 180 ? 180 : 0;
final = (comp + backcomp) / 2 + adj;

You can see the full version here:

https://github.com/ojwb/survex/blob/master/src/datain.c#L893

That's pretty close to what you have - I think the key difference is
the fabs() on the wrap-around check.

I believe I proved that the averaging algorithm Survex uses was correct
back when I implemented this, though unhelpfully I didn't add the proof
as a comment in the code.

Though looking at the code now, I think it should be wrapping the
two bearings to the range [0,360) after it corrects for zero errors
and declination and before it does the actual averaging.  I'll take
a look at that.

Footleg's idea of averaging vectors is interesting - I'd not thought
about that before.  One nice feature is that it naturally extends to
more than 2 bearings.  It also helpfully gives "invalid" for trying to
average bearings which completely oppose (whereas feeding the same
bearing in as foresight and backsight above will give you a bearing
that's 90 degrees away to one side or the other, arbitrarily).

Cheers,
Olly