Cave registry: Keld Head

[Pitlamp]

Just had a look around the Cave Registry Data Archive - good effort all concerned. I think a lot of the data from Keld Head originates from me and from Rupert Skorupka. It starts with this comment which someone has added:

;Water level at Keld Head resurgence is 252.36m altitude.
;KMC dive line belay is 1.2m above water level in diving data, but dry survey in KMC puts this at 267.37m (13.8m too high!).
;Adding vertical adjustment to link between diving data and dry data makes things worse as the
;bug in loop corrections with diving data in Survex actually pulls the depth of the deepest part
;of the sump down by over 20m as it is. Adding an adjustment for the upstream end just makes this worse.

Having surveyed all the way from KH to KMC I can reassure folk that the water level is the same at both ends! (One of the massive advantages of a diving survey over a dry cave survey is the levelling precision it offers.) As the originator of these data, if there's anything I can do to help sort out this anomaly, please PM me. However, it seems the problem must lie within the overland data, not the underwater data. Trying to sort this by altering the depths recorded in the underwater cave is not the solution; these were very carefully recorded with a precision instrument reading to +/- 10 cm.

Mods - this doesn't really belong here (sorry Badlad; wasn't trying to hijack your excellent topic). Probably better transferred to a new topic altogether?

 

[Badlad]

Just looked for method of splitting topic but can't work out how to do it on the new software. I'll need to investigate further. There is only a limited number of people who play with the archive data so best asking directly with them.

Loop errors, multiple loop errors, varying levels of accuracy are quite a nightmare to deal with without resurvey. There is the "solve" command in Survex which distributes error down just one side of a loop where say data is known to be less accurate. However, these sort of things can only really be attempted by people who are knowledgeable across the whole Kingsdale data set. I expect you have opened a Pandora's box of survey nasties.
😲

 

[Pitlamp]

Oops, sorry Badlad!

I just bring out the numbers and don't really understand what happens to them afterwards. However, all the underwater Keld data were dealt with by Ray Duffy, who ironed out any glitches.

As you say, best to liaise direct with those directly involved with the number crunching.

So . . . . am available to be PM'd.

 

[Rob]

,,,There is the "solve" command in Survex which distributes error down just one side of a loop where say data is known to be less accurate....

Ooo, that sounds good. I was not aware of that.

I've just researched it, for anyone else interested this is Olly's example use:

Example
*include 1997data
*solve
*include 1998data

Description
Distributes misclosures around any loops in the survey and fixes the positions of all existing stations. This command is intended for situations where you have some new surveys adding extensions to an already drawn-up survey which you wish to avoid completely redrawing. You can read in the old data, use *SOLVE to fix it, and then read in the new data. Then old stations will be in the same positions as they are in the existing drawn up survey, even if new loops have been formed by the extensions.

I'll probably use it to reduce the reliance of diving data in loops, i.e. :
*include ALL GOOD SURFACE DATA
*solve
*include ALL DODGY DIVING DATA

However in the KMC scenario (and most actually) the diving data is actually more accurate for altitude, but probably not for plan view. Therefore i'm not sure a *solve in either direction would work.

I'd be tempted to fix the upstream point, using the coordinates from the dry survey and the altitude of the resurgence. But then put a flag in to re-assess the fixed coordinates each time other loops are closed nearby. Unless it's possible to fix a point's altitude only!?

 

[Steve Clark]

Ooo, that sounds good. I was not aware of that.

I've just researched it, for anyone else interested this is Olly's example use:

I'll probably use it to reduce the reliance of diving data in loops, i.e. :
*include ALL GOOD SURFACE DATA
*solve
*include ALL DODGY DIVING DATA

However in the KMC scenario (and most actually) the diving data is actually more accurate for altitude, but probably not for plan view. Therefore i'm not sure a *solve in either direction would work.

I'd be tempted to fix the upstream point, using the coordinates from the dry survey and the altitude of the resurgence. But then put a flag in to re-assess the fixed coordinates each time other loops are closed nearby. Unless it's possible to fix a point's altitude only!?

You can fix just the altitude by using fix by specifying approximate x,y, accurate Z and large error values for the x & y coordinates. See survex manual section 4.5.15. I’ve not tested it, but it should work in theory.

I’ve noticed survex doing odd things with diving data when I use survex processing within therion to do loop closures. With a single fix at one end, survex can make the vertical error diverge over long distances, despite all the Z values being absolute. This doesn’t happen if I use therion to do the loop closures.

 

[Pitlamp]

Rob; in the case of the Keld Head to KMC traverse, The misclosure with the dry surveyors' (overland) data was of the order of 0.7%. It's not necessarily the case that an underwater survey is less precise than a dry cave survey.

The 1.9 km of data took some getting; certain of the dives lasted over 4 hours and great care was taken (including the use of a non stretch surveying tape for every leg).

The detail of how this level of accuracy was obtained was discussed in an article somewhere (I think the Compass Points publication, IIRC). Some of it also appears in the current Cave Diving Group Manual.

 

[andrew]

There have been various reports of bugs in diving data in survey. The best place to report these is the survex email list, where they are far more likely to get actioned. Especially if there is some data that fixes it

Survex - Mailing List

survex.com

As for solutions, both the fix and the solve sort of work, but could cause problems later. Out of the two, the fix is a better option, if real data is used. Fixes are generally used already. Solve was really there in the days when we might have wanted to add a bit to an already printed survey.

However please remember fixes also have errors. In survex adding a fix without standard deviation, is treated as perfect, which is far from ideal. Therefore it is a good idea to set the SD.

*fix <station> [reference] [ <x> <y> <z> [ <x std err> <y std err> <z std err> [ <cov(x,y)> <cov(y,z)> <cov(z,x)> ] ] ]


The SD can be set for the legs or component of the legs. So for diving data the depth can be set as very good and the rest less so.

*sd <quantity list> <standard deviation>

Not sure dive deplth data is 10cm acuate my dive computers differ by more than that, although the difference tends to be the same so if you calibrated to zero you have a chance and can calibrate the depth.

*calibrate <quantity list> <zero error> [<scale>]

*calibrate <quantity list> <zero error> <units> [<scale>]

*calibrate default

However then you hit the problem of salt or fresh water. The EN standard use to esencially split the difference. So to get accurate dept readings you need to know what yours is set to and how to compensate for that.

All that said the zero should be pretty damn good, which is really all that is needed for tying into surface data.

 

[Duncan Price]

There have been various reports of bugs in diving data in survey. [SNIP]

However then you hit the problem of salt or fresh water. The EN standard use to especially split the difference. So to get accurate depth readings you need to know what yours is set to and how to compensate for that.

All that said the zero should be pretty damn good, which is really all that is needed for tying into surface data.

I have not noticed problems with SURVEX and diving data.

My depth gauges/computers are set to fresh water though on the rare occasion that I've worn more than one I have noticed that they don't read the same. Since for surveying purposes you are only interested in the difference then so long as you stick to the same depth gauge over the course of the survey it does not cause a problem.

When we did the accurate survey from Chambers 9 to 19 in Wookey Hole for the purposes of blasting a tunnel to 20 we used a tape measure for distance and a DistoX in an underwater housing. It's primary purpose was to get accurate bearings since non-electronic diving compasses are very difficult to read to high accuracy underwater. We did however record the clinometer readings and compared the survey done using both methods for measuring changes in elevation and found them to be in good agreement. A tape measure was laid along the dive line was used for distance and read to the nearest cm as the laser range finder function of the DistoX was not reliable over longer distances (even taking into account the correction due to the refractive index of water). Some of the later survey work was done when the blasting was in progress and the dam at the entrance had been opened meaning that some of the sump was now dry...

The dry connection between Chamber 20 and 24 was facilitated by some careful survey work to inform us where to dig and the closure error when the connection was made was less than 1% despite some of the surveyed cave being not particularly amenable to accurate measurements (we put a tape measure through one of the static sumps between 23 and 24 and took a bearing on it, for example).

 

[andrewmcleod]

Probably a silly question, but could the issue be as simple as a dodgy fixed altitude for either Keld Head or (presumably the closest surface station) Valley Entrance? An overland centreline from Keld Head to Valley Entrance might tie everything together?

 

[Pitlamp]

Fair comment. But as I remember the Keld Head entrance station and VE entrance station had their altitudes fixed, very accurately, by Kevin Dixon.

I think Badlad was involved, so he might be able to chip in here?

 

[aricooperdavis]

That should be a relatively easy thing to check given their locations and freely available LIDAR DTMs.

 

[Badlad]

Keld was accurately fixed as were a number of entrances across the Three Counties as far as Top Sink. I don't think KMC was done - or not at that time anyway. Accuracy was by professional GPS kit to about 10cms or less if i remember correctly.

 

[Steve Clark]

I have not noticed problems with SURVEX and diving data.

My depth gauges/computers are set to fresh water though on the rare occasion that I've worn more than one I have noticed that they don't read the same. Since for surveying purposes you are only interested in the difference then so long as you stick to the same depth gauge over the course of the survey it does not cause a problem.

When we did the accurate survey from Chambers 9 to 19 in Wookey Hole for the purposes of blasting a tunnel to 20 we used a tape measure for distance and a DistoX in an underwater housing. It's primary purpose was to get accurate bearings since non-electronic diving compasses are very difficult to read to high accuracy underwater. We did however record the clinometer readings and compared the survey done using both methods for measuring changes in elevation and found them to be in good agreement. A tape measure was laid along the dive line was used for distance and read to the nearest cm as the laser range finder function of the DistoX was not reliable over longer distances (even taking into account the correction due to the refractive index of water). Some of the later survey work was done when the blasting was in progress and the dam at the entrance had been opened meaning that some of the sump was now dry...

The dry connection between Chamber 20 and 24 was facilitated by some careful survey work to inform us where to dig and the closure error when the connection was made was less than 1% despite some of the surveyed cave being not particularly amenable to accurate measurements (we put a tape measure through one of the static sumps between 23 and 24 and took a bearing on it, for example).

It may already be in common use in the UK, but one of the tips we picked up from the guys in Mexico to improve compass readings underwater was to use a pencil, cable-tied to the compass through tiny holes drilled in the body. Particularly for lines that are changing depth (diagonal up/down), you can hold the compass horizontal/level above the line and sight directly down through the pencil, superimposed over the line. It's a longer object and easier to align the two ends of the pencil with the line. Then set the bezel to match the arrow. You can then take the compass away, closer to your eye to read the bearing.

It's also one thing to hold (or drop), rather than two.

 

[Pitlamp]

Something similar was used for the Keld to KMC traverse; the compass was screwed to an A4 survey board to allow more accurate alignment of the dive line with the edge of the board. Made a big difference to the compass accuracy. The survey board would also fit conveniently onto a photocopier afterwards. (That's less important now of course, with high quality digital cameras on smart phones.)

Badlad - thanks for the benefit of your memory (above).

 

[Steve Clark]

Looking through the data, it may be worth investigating :

In /kdgps.svx at Valley Entrance the GPS antenna [station 3c20ae] was at 268.392 with the actual entrance about 1.04m lower = 267.0m

In /KMC/ValleyEntrance.svx the commented out fix line has Valley Entrance station ValleyEntrance.0 at 279.0m

The main survey (West_Kingsdale_System.svx) includes both files, but will be using the fix in kdgps.svx, since the other is commented out.

If you run /KMC/ValleyEntrance.svx in isolation with the commented-out fix line reinstated, it will return an altitude for the KMC sump end 12.0m higher than it would be using the proper GPS survey value. That may account for a chunk of the 13.8m difference.

 

[Steve Clark]

If you take the raw data from Ray Duffy's 1997 survey (Roof_Tunnel.svx), the height difference between the Valley Entrance drum to the knot in the diver's line at the KMC sump is -11.6m. (Imported and using crude trig maths in Excel)

So, take the accurate GPS of ~267m at Valley Entrance, take off the -11.6m difference down the roof tunnel and pitch, the diver's line knot is at 255.4m, say 1.2m above the water, gives water level at 254.2m

Keld Head is apparently at 252.36m and the sump level will be almost identical under normal/low flow.

That's only 1.8m difference.

The problem may be as simple as running a single survey in isolation with an approx fix on the entrance altitude.