Multiple readings from one but not all instruments

[Olly Betts]

On Tue, Nov 15, 2022 at 03:30:02PM +0000, Andrew Atkinson wrote:
> In the ukcaving thread
> 
> https://ukcaving.com/board/index.php?threads/therion-for-divers.30044/
> 
> It has been brought up that people are taking two compass readings per
> leg and also two depths for each station (the stations depths been taken
> on the way in and the way out.)
> 
> This has got me thinking, the original SAP only did compass and clino,
> so it would have been reasonable to take more than one shot with that
> but only have one tape reading.
> 
> So Survex was kindly updated by Olly to not count multiple legs as loops
> of the distoX, hopefully it would not be that difficult to amend that to
> be able to miss out a reading. eg
> 
> data normal from to tape compass clino
> 
> 1	2	3.22	178	-3
> 1	2	-	179	-4
> 
> It would seem reasonable to accept this type of grouping so long as one
> of the group was a valid leg, guess it would also be reasonable to
> expect the first one to be valid. This notation would show that tape was
> only read once, conveying some information about reliability, maybe one
> day that can be used.

I don't think this can easily be extended in this way.  This feature
averages the vectors for each of the legs, but with an omitted reading
we don't have a full vector for that leg.  Filling in the blank from the
first leg doesn't seem satisfactory as it effectively attributes
additional accuracy to that reading (and it doesn't easily extend to
having 3 repeat legs, two of which have a tape reading).

I'd suggest just handling the extra compass and/or clino here as
backcompass/backclino suitably calibrated so they actually work
in the same direction as the forward instruments:

*calibrate backclino 0 -1
*calibrate backcompass 180 

Survex also supports backtape (since 1.2.25) so you can take your pick
of which instruments you have a secondary for (backtape doesn't need a
special calibration for this use, since distance is the same whichever
way round you measure it).

> There would be a question about the use of more than one instrument, say
> 2 compasses, especially if they had different calibration amount. People
> are doing this, although it is not stated in the above thread, I expect
> the dual compass readings come from the Nemo and another compass. If
> this is a standard dive compass, taking the average is probably the
> wrong thing to do as most are hard to read better than 5°. Maybe a data
> format along the lines of

You can specify a separate accuracy for backcompass and compass, so this
is supported via the backsight approach.  Averaging will take into
account the accuracies specified via *sd so you'll get an average heavily
weighted towards the better compass here.

The main thing that isn't possible is more than two instruments of the
same sort.  If people really need that we could perhaps extend the
backsight handling to support this (and to more explicitly support
additional forward instruments).

There is actually some unfinished support for repeat readings - I think
the sketched out syntax for multiple readings was:

*data normal from to tape compass clino

1	2	3.22	{ 178 179 }    { -3 -4 }

I don't remember why this didn't get finished, but maybe lack of anyone
actually asking for it back then.  The code there is for this assumes
the same SD for each reading inside the {...} though.

> The depths on the way in and way out is slightly different sort of like
> another traverse, but without the full information. Maybe this is the
> same solution as what was proposed for the water level at different ends
> of sumps, we do need to be able to connect stations without the full
> information.

If I follow, we have a tape/compass/depth survey with an additional set
of depth readings.  I'm not sure being able to "vertically equate"
stations would help here as we can't simply represent this as two
traverses as we lack full data for the return traverse (reusing the
tape and compass readings would effectively treat them as having extra
accuracy).

We don't have "BACKFROMDEPTH", etc so this isn't currently possible by
creative use of the backsight support, but perhaps that's the natural
way to handle this.

Cheers,
    Olly