Walls: "Corrected" (TYPEAB=C) fs/bs bearings are treated as "Normal" bearings wrt COMPASS vs BACKCOMPASS disagree warnings

[Joe Walko]

TYPEAB=C isn't get honored when checking for compass fs/bs disagree.. Am not sure if scope is limited to just the 'disagree warning', or if the fs/bs is incorrectly processed during remaining processing.

..\walls_test_data\fsbs.srv:25:14: warning: COMPASS reading and BACKCOMPASS reading disagree by 180dg

:a1 c2 10 90/90 0

See attached files for examples, specifically second set of shots, under #PREFIX AC section.

[Joe Walko]

walls test data and walls and cavern logs

[Olly Betts]

Based on a very brief look at the code it seems to set up the equivalent of *calibrate backcompass 180. I don't see existing test coverage for this, but a simple test works in .svx data - I get no backsight warnings for:

*calibrate compass 0  
*calibrate clino 0  
*calibrate backcompass 180  
*calibrate backclino 0 -1  
*data normal from to tape compass backcompass clino backclino  
1 5a 10.00 90 90 10 10

Thanks for the examples - I'll dig into them when I have a chance.

[Olly Betts]

The problem is that INCAB currently overwrites the change which TYPEAB=C,... made (and vice versa). Either should work by itself. A very similar problem likely affects clinos.

We just need to store whether the C flag is currently active and the current INCAB value and compute the backbearing zero calibration value based on both when either changes.

[Olly Betts]

That was indeed the problem and now the reported disagreements match the diff: values in your comments:

fsbs.srv:13:12: warning: COMPASS reading and BACKCOMPASS reading disagree by 10°
 :a1 b2a 10 90/270 0 ;Az FS/BS diff:   10.0 deg, a1 to b2a ; :COMPASS reading and BACKCOMPASS reading disagree by 10dg
            ^~~~~~
fsbs.srv:16:12: warning: COMPASS reading and BACKCOMPASS reading disagree by 10°
 :a1 b3a 10 90/270 0 ;Az FS/BS diff:   10.0 deg, a1 to b3a ; COMPASS reading and BACKCOMPASS reading disagree by 10dg
            ^~~~~~
fsbs.srv:20:12: warning: COMPASS reading and BACKCOMPASS reading disagree by 10°
 :a1 b4b 10 90/280 0 ; Az FS/BS diff:   10.0 deg, a1 to b4b ; COMPASS reading and BACKCOMPASS reading disagree by 10dg
            ^~~~~~
fsbs.srv:31:12: warning: COMPASS reading and BACKCOMPASS reading disagree by 10°
 :a1 c2a 10 90/90 0 ;Az FS/BS diff:   10.0 deg, :a1 to c2a ; COMPASS reading and BACKCOMPASS reading disagree by 170dg
            ^~~~~
fsbs.srv:34:12: warning: COMPASS reading and BACKCOMPASS reading disagree by 10°
 :a1 c3a 10 90/90 0 ; Az FS/BS diff:   10.0 deg, :a1 to c3a ; COMPASS reading and BACKCOMPASS reading disagree by 170dg
            ^~~~~
fsbs.srv:39:12: warning: COMPASS reading and BACKCOMPASS reading disagree by 10°
 :a1 c4b 10 90/100 0 ; Az FS/BS diff:   10.0 deg, :a1 to c4b ; COMPASS reading and BACKCOMPASS reading disagree by 170dg
            ^~~~~~
fsbs.srv:48:19: warning: CLINO reading and BACKCLINO reading disagree by 5°
 :a1 d2a 10 90/270 -5/+5 ; Vt FS/BS diff:    5.0 deg, :a1 to d2a ; CLINO reading and BACKCLINO reading disagree by 5dg
                   ^~~~~
fsbs.srv:51:19: warning: CLINO reading and BACKCLINO reading disagree by 5°
 :a1 d3a 10 90/270 -5/+5 ; Vt FS/BS diff:    5.0 deg, :a1 to d3a ; CLINO reading and BACKCLINO reading disagree by 5dg
                   ^~~~~
fsbs.srv:55:19: warning: CLINO reading and BACKCLINO reading disagree by 5°
 :a1 d4b 10 90/270 -10/+5 ; Vt FS/BS diff:    5.0 deg, :a1 to d4b ; CLINO reading and BACKCLINO reading disagree by 5dg
                   ^~~~~~
fsbs.srv:62:19: warning: CLINO reading and BACKCLINO reading disagree by 5°
 :a1 e2a 10 90/270 +5/+5 ; Vt FS/BS diff:    5.0 deg, :a1 to e2a ; CLINO reading and BACKCLINO reading disagree by 5dg
                   ^~~~~
fsbs.srv:65:19: warning: CLINO reading and BACKCLINO reading disagree by 5°
 :a1 e3a 10 90/270 +5/+5 ; Vt FS/BS diff:    5.0 deg, :a1 to e3a ; CLINO reading and BACKCLINO reading disagree by 5dg
                   ^~~~~
fsbs.srv:69:19: warning: CLINO reading and BACKCLINO reading disagree by 5°
 :a1 e4b 10 90/270 0/+5 ; Vt FS/BS diff:    5.0 deg, :a1 to e4b ; CLINO reading and BACKCLINO reading disagree by 5dg
                   ^~~~

A very similar problem likely affects clinos.

They don't suffer from the same problem since INCVB sets the zero error but TYPEVB=C,... sets the scale to -1 (which flips the order), whereas for the compass both INCAB and TYPEAB set the zero error and so overwrite one another's changes.

I should double check that the order the clino corrections are applied in matches what we actually need for Walls though.

[Joe Walko]

The problem is that INCAB currently overwrites the change which TYPEAB=C,... made (and vice >>versa). Either should work by itself. A very similar problem likely affects clinos

Ah; so same root cause as #162. I didn't make the connection between TYPEAB vs INCAB in this one (161), and didn't think to re-test it once I saw TYPEAB affecting INCAB in 162 (which took me longer than it should have to narrow down - too much data in my dataset).

In a bit of irony, I resorted to having claude crank out a parser for the cavern Walls parser logfile :-), to make it easier to compare your parser warnings against shot-data output from the parser in my screener. I then noticed lots of, um, disagreements between reported fs/bs disagreements.

Most all our surveys have INCA/INCAB - standard practice, set based on "compass course" readings. And, several hundred surveys with TYPEAB, multiple shots per survey, for course, probably equaling around ~1,000 inflated cavern fs/b disagreement warnings.

[Olly Betts]

Fixed by 96eb727729b78170da97419001931c91bc22b1d8.

I thought I could just compare the Survex-computed station coordinates from your testcase with those Walls gives to check that TYPEVB and INCVB work together correctly, but I'm failing to work out how to get Walls to give me a list of stations and their coordinates. Is there a way?

[Olly Betts]

The Walls manual says INCVB "specifies a correction that the program will add to the corresponding measurement entry when it is processed", and we calculate (backclino + INCVB) * sc where sc=-1 if TYPEVB=C,... and sc=1 otherwise.

So that seems right, but checking that the coordinates match would be reassuring.

[Joe Walko]

...how to get Walls to give me a list of stations and their coordinates. Is there a way?

Walls' option to export list of station coordinates is in a non-obvious place; after data compilation, select "Review Tab", then "Segments" in the next window, then "Details / Reports" button under "Branch Totals".

In the next popup Window are buttons to select "Shapefile" or "Coordinates" exports; the latter will display stations w/coordinates on-screen, which are also written to *.LST file.

Shapefiles (*_s set for stations, *_v set for shots) contain the coordinates as well, and can be converted to csv via ogr2ogr.

[Olly Betts]

Thanks.

The coordinates don't exactly agree, but they don't for the case which doesn't involve INCVB or TYPEVB either so that may be down to a different IRSG model version, or minor differences in the coordinate conversions.

I'll try to a few one-leg microtests to try to work out what Walls actually does with them.

Also annoying for running many of the testcases with Walls itself is that Walls complains if the .srv name is more than 8 characters. They seem to process OK but there are length checks which block some things (e.g. opening the "Geographical Reference" tab). I guess I need to go through and rename some testcases to more cryptic names...

[Olly Betts]

I'll try to a few one-leg microtests to try to work out what Walls actually does with them.

These confirm that Walls and Survex handle INCVB and TYPEVB the same way - all the stations except X get the same coordinates in both, and they're the same as each other:

#units reset m
X	A1	100	90/270	+60/-60
#units reset m typevb=C,0
X	C1	100	90/270	+60/+60
#units reset m typevb=C,0 incvb=0
X	C2	100	90/270	+60/+60
#units reset m incvb=10
X	I1	100	90/270	+60/-70
#units reset m typevb=C,0 incvb=10
X	B1	100	90/270	+60/+50

I'll slot this into the testsuite.

(This also triggers a bug in the implementation of reset which causes a crash because it incorrect clears the next pointer when it resets the settings - I'll fix that.)

The bug reported is fixed so closing.

[Joe Walko]

Adding confirmation that this seems resolved with my large dataset.