Report multiple matching 'triplet' legs where readings are too divergent

[Wookey]

Survex will concatenate repeat legs between the same stations, as is typical for paperless surveying (3 similar-enough readings makes a leg). However it currently assumes that the legs have already been checked for similarity, but of course it's possible for them to have significantly divergent readings and that should be reported as at least a warning.

This leads to questions about what tolerances to accept. Pockettopo, Sexytopo, Topodroid, DistoX2 and SAP6 all have slightly different criteria for matching legs. Survex already has defined SDs for the readings and should probably use those to derive 'close enough' criteria.

An example of a dataset containing repeat legs that do not actually match is 'cathedralchasm2.svx' in the Austria loser dataset: ​https://expo.survex.com/repositories/loser/.git/tree/caves-1623/264/cathedralchasm2.svx

[Olly Betts]

A check based on the specified SDs makes sense.

Do we know the criteria for at least some of those instruments? It would be irritating for users if Survex's thresholds with non-custom SDs were stricter than the instruments apply, since then even if you take care to repeat any readings the instrument flagged you could get a warning from Survex which there's probably not a good way to resolve short of going back into the cave.

Perhaps if two readings are close and one isn't you would just comment out the odd one out (especially if most readings match but once distance is longer as that suggests the disto missed the target).

That also makes me wonder what we should do to the readings in case of mismatch - we could take the largest subset of the legs which match within the threshold which is like an automatic "comment out the odd one" - for 3 legs that would be 2 of 3), or we could subset for each instrument separately, or we could take the median value for each reading. The first one is nice in that the user can replicate it by commenting out that leg to get the same effect without the warning. All these require at least 3 readings though whereas the current averaging works for any number 2 and up. There's also the situation where we have more legs but no subset is in tolerance (taking the median at least does something that's probably reasonable there).

I think being able to do such checks will require temporarily storing the data for all the legs in the current group until we have all of them (currently we just update the average as we read each leg so we only need the leg structure we create anyway, the from and to station names, and a counter for how many legs we've averaged so far so we can scale the next average appropriately if there's another leg). That's possible to do but means this is a rather more involved change than just adding a threshold check might seem to be.

[Olly Betts]

Crofton just quoted this in chat in reply to something not directly related:

Triple Shot Check

If the triple shot check option is turned on, the device checks for three nearly identical measurements in a row. If a triple is detected the device beeps twice and shows an ‘identical’ sign ( ≡ ) to the right of the measured values. Three shots are considered nearly identical if the pairwise comparison results in a distance difference < 5cm and a directional difference < 3% (1.7°). PocketTopo uses the same measure to distinguish survey shots from splay shots. A small triangle ( ) is shown a in the lower left corner of the display if the check is switched on.

(apparently) from ​https://paperless.bheeb.ch/download/DistoX2_UserManual.pdf

Similar info for other devices/software would be useful.

[Wookey]

From the SAP6 manual at ​https://stic.readthedocs.io/en/latest/ we have: If three successive readings are similar they are interpreted as a leg rather than a splay and the device will give a success beep (rising) and flash the laser twice. Similar means that, for each of the three pairwise comparisons between the three readings, the angular difference is less than 1.7 degrees and the change in distance is less than 5cm.

The sexytopo docs say nothing relevant, but the class control/util/SurveyUpdater.java has a function 'areLegsAboutTheSame' which checks that distance and both angles are within a specified delta which are defined elsewhere as: control/util/SurveyUpdater.java: private static final float DEFAULT_MAX_DISTANCE_DELTA = 0.05f; control/util/SurveyUpdater.java: private static final float DEFAULT_MAX_ANGLE_DELTA = 1.7f;

Bric 5 manual: ​https://www.bricsurvey.com/s/BRIC5_user_manual_revB.pdf says: Azimuth: <0.20° precision, <0.5° accuracy o Inclination: <0.1° precision, <0.2° accuracy o Distance: 1 mm precision, 3mm accuracy

Error Sensitivity: 0.2 – 1.5 degrees This setting controls the overall error sensitivity of the instrument. This is the threshold for the 3-shot triple-beep feedback. This is also used to determine thresholds for generating an error due to discrepancies between the sensors and axis magnitudes. A value of 0.5 degrees works well in practice. If errors are generated often with this setting, a re-calibration is needed;

The DistoX manual doesn't say: ​https://www.gsg.org.uk/sites/default/files/uploaded-documents/DistoX_UserManual.pdf

Topodroid manual: ​https://sites.google.com/site/speleoapps/home/topodroid/user-manual says: Leg tolerance: the angle tolerance (percent) between consecutive shots of a leg [default 0.05, min 0]. The length tolerance is the product of the angle tolerance and the length.

and Leg tolerance: tolerance among the shots of same leg > 0%. [0.05, ie, 5%]

and Accuracy Acceleration tolerance: percent tolerance for the shots acceleration > 0. [1%] Magnetic field tolerance: percent tolerance for the shots magnetic field > 0. [1%] Magnetic dip tolerance: tolerance over the shots magnetic dip > 0. [2.0°] Sibling threshold: threshold for sibling shots tolerance > 0. [5%] [this doesn't actually make sense - formatting issue? check the HTML or source?]

So I think that means that, at least by default, DistoX2, SAP6, Sexytopo (and probably DistoX too) all use the same numbers. Topodroid might be - it's not clear. Bric5 (and thus maybe Bric4) are different. Fricken Cave Laser doesn't say. I could only find videos for Qave, not a manual. Life is too short.

[Olly Betts]

Thanks.

I'm unclear why in the distox2 docs it says "3%" is "1.7 degrees" - if 1.7 is 3% then 100% is 56 and 2/3?!? I guess I can just ignore the 3% here and know it's 1.7 degrees, which matches some other devices too, but Topodroid also talks about a percentage for angles.

It makes no sense for it a percentage of the angle measured since 3% of 000 would be 0° but 3% of 300 would be 9°. A percentage of 180° seems the most logical definition since then 100% wrong is the opposite direction.

I wonder if it's 100%*sin(angle)? If so 3% -> 1.719131320877811 degrees (and 1.7 degrees -> 2.9666244085110757%). 100% wrong is then 90° out (but the percentage decreases again beyond 90° until 180° out is 0% wrong!)

Or could be tan(angle) - that's very similar for a small angle like this. But then 100% wrong is 45° out and the percentage tends to infinity at 90° out which seems unhelpful.

I tried to find where this is handled in the topodroid code (as I found I had that checked out) but I failed to work out where it happens.