Dive data with both depth and clino

[Footleg]

The depth measurements are absolute, so will not accumulate errors in the
way the clino measurements will over multiple legs. So a different
treatment would seem appropriate in managing errors. I don't think Survex
currently does this for diving data anyway, as a loop closure for a loop
which is partly diving and partly normal format data can cause the depths
of the diving section to be pushed above the water surface level of below
the deepest point on the dive. I have examples where this happens in the
Keld Head to Kingsdale Master Cave diving data when you fix the entrances
with GPS data and parts of the sump get pushed much deeper than the actual
depths recorded in the data (that data is in the cave registry if anyone
wants to play with this).

Footleg

On Fri, May 8, 2015 at 1:45 PM Andy Waddington (Cave Surveying mailbox) <
surveys at pennine.ddns.me.uk> wrote:

> Sometime before sending, Graham Mullan typed (and on Friday 2015-05-08 at
> 13:15:17 sent):
>
> > Might there be a clash here if the absolute depth readings differ
> drastically from
> > the relative ones arrived at using the clino reading? Which would be
> prioritised by
> > the algorithm and why?
>
> It is not necessarily the case that either would be prioritised.
>
> In the case of a drastic disagreement, what should be flagged is
> a blunder detection, and neither clino nor depths should be
> accepted without input form the surveyor to say which he/she
> believes is more likely to be correct.
>
> It ought to be possible to spot single erroneous depth readings
> as giving rise to a clino discrepancy in both survey legs leading to
> the point with the absolute depth which is in error. If only a single
> leg is affected, it is more likely that the clino is in error. But
> this stuff should not be just assumed algorithmically - the
> surveyor's attention needs to be drawn to the issue.
>
> If the leg which gives rise to the discrepancy is hanging (eg.
> to the end of a passage) then you can't do that deduction
> anyway...
>
> Andy
>
>
> --
> Survex http://lists.survex.com/mailman/listinfo/survex
>