[Therion] Handling of tape and backtape in survey data

[Olly Betts]

On Sat, Dec 25, 2021 at 08:50:26AM -0600, Bill Gee wrote:
> 1) Does Therion also recognize the BACKTAPE data type?

It seems not - there's no match in the source code repo for:

git grep -i BACKTAPE

> 2) What does Survex do if both TAPE and BACKTAPE are given?  Does it
> average the two readings?  Does Therion do the same thing?

Survex warns if they differ by more than 3 standard deviations, and then
takes the mean of the readings.

> I understand that Therion will use Survex to reduce the centerline
> data - if Survex is installed.  In case Survex is NOT installed, then
> Therion reduces the centerline itself.  As a result they might handle
> this situation differently.

Also, Therion generates a .svx file behind the scenes, but not
necessarily the .svx file you'd write yourself given the same data.
For example, I think Therion collapses backsights to a single reading
itself before processing with Survex.

> As I write this, another related question occurred to me.  When either
> Therion or Survex averages a forward and backward reading, how many
> significant digits does it carry in the calculation?  Can the
> significant digits be changed?

Survex uses double precision for this:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

That has 15-17 significant decimal digits - i.e. many more than matter
here.

Using more precision seems overkill.

If you really want to use fewer it should be possible to build cavern
to use single precision, but I don't think anyone actually does this.
We made it an option as decades ago it seemed you might want to do this
to reduce memory usage (4 bytes per floating point number instead of 8)
but cavern's memory use is very modest by modern standards, and single
precision only gives 6-9 significant decimal digits, which isn't even
enough to reliably store a UTM Northing to the nearest metre so you'd be
limited in what coordinate systems you could use in such a build.

I don't see why you'd want to be able to dynamically force rounding to
fewer significant figures - what's the benefit?

Downsides of rounding are it would slow things down a bit, and it risks
introducing systematic biases - a dumb example to make the issue
clearer: if all readings are to the nearest inch and you round the
average to the nearest inch and always round 0.5 up, then then assuming
an even distribution there's an average bias of +0.25 inches on each
tape reading.  The problem with systematic biases is they accumulate
rather than tending to cancel.

There are other rounding schemes which try to address this sort of
issue (like rounding 0.5 to the nearest even number) but it's hard to be
certain they might not introduce a more subtle bias (some cave systems
have dominant direction passage develops along so the distribution is
may not uniform across odd and even) and there doesn't seem a compelling
reason to be rounding in the first place.

> And the same question applies to loop closure calculations.  How many
> significant digits are carried through the calculations?

The same.

The final results are then stored in the .3d file to the nearest cm
(that's 0.000049710 furlongs for our US readers).  That precision was
chosen so that coordinate values will fit in a 32 bit integer, and seems
adequate for the final results.

Cheers,
    Olly