Logbook Entry | Caves | QMs | Survex | All Survex | Scans | Upload Scans | Drawings | Upload Drawings | Upload Photos | Upload GPX |
Data Issues | tasks to do | ents | expoers | survey lengths | statistics | Wild Survex(2025) | Wallets(2025) | Expo(2025) | Control panel

Lengths of Caves

How we measure and record the lengths of our discoveries

This needs to be reformatted and turned into proper documentaiton. 

Re: SMK length and depth over time / at the end of each Expo
_EXPO-2025

Wookey 
Attachments
Fri, 25 Oct 2024, 03:16
to Rebecca, me

On 2024-10-24 10:58 +0100, Rebecca Lawson wrote:
> Do we have this saved anywhere?

We have alll the years since 2012 recored in this spreadsheet: loser/.git/tree/docs/smklengths.ods

There isn't a handy web-page with historical info SFAIK. We did used to have a 'longanddeep' page which I think had this info on, but I think it's gone, and maybe it only ever had the current info (and our place in world tables)? 

> I've seen various graphs in talks where it
> has been used, taken I guess just from the survex data and I know Wookey
> usually reports this data each year to the Austrians but it isn't
> necessarily that easy to extract out just SMK.

This is the main reason its important to keep it possible to process subsets of the loser dataset, so that we can process 'smk-system.svx' to easily get the length for that subset, and also the individual caves.

For getting the lenght there are two ways to run at it:

  1. process smk-system.svx, or
  2. process all the caves that are part of smk.svx and add them up.
They should produce the same number give or take a couple of metres, but I've not checked to see how many years that's actually true for, and right now it turns out they differ by 39m for 2024.

smk-system doesn't get as much use as it used to so is prone to bitrot, but it is currently working and says 138802 adjusted. Whilst smklengths all added up says 138763, which is pretty close (39m) but not exactly the same. That's usually what happens and it takes a bit of detective work to find out what's out of whack.

In practice '2' is more useful because when there are discrepancies (and in my experience there usually are) it's easier to work out where when you do it cave by cave, than when you just have the whole thing with an unexplained difference 'somewhere'

There is a script to help with this: 

https://expo.survex.com/repositories/loser/.git/tree/docs/smklengths

and also this which just gets the length of any given cave::
https://expo.survex.com/repositories/loser/.git/tree/docs/cavelength
either
./cavelength 258
or
./cavelength 359 1626
to run it on the non-default area (new for last year that feature).

(for all this stuff, if using Windows or MacOS do it in a terminal/Windows-on-Linux console)

> Wookey, how easy is it to generate SMK and non-SMK finds per year?

It's pretty easy to just run smklengths:
cd loser/docs
./smklengths
in a loser checkout for any year.

And you can use the tags to get the 'right' checkouts for each 'the data has been sorted out for the year by now' point:
post-2017
post-2023
etc
https://expo.survex.com/repositories/loser/.git/refs/

so to get the answer for 2017 you do:
cd loser
git checkout post-2017
cd docs
./smklengths
git switch -           (to get back from 'detached head' state to whatever you had checked-out before.

You could do the same thing with immense amounts of pointing and clicking, but it would be very tedious.

I've just done this for current head and updated the smklengths.ods sheet for 2024, but that 39m discrepancy needs resolving before it can be considered 'final'. Also the ARGE data was never merged for 2023 (nor 2024 yet) so the length is very likely wrong for that reason too.

You can also just run: 

cavern smk-system.svx

and compare the difference post-2023 to 'latest' with
git checkout post-2023
cavern smk-system.svx
git switch -
cavern smk-system.svx
And see what the difference is.

To get 'a' non-smk length is basically the same, but you need to subtract the smklength numbers you just got above, to get the 'all the other finds' number
git checkout post-2023
cavern 1623-and-1626
git switch -
cavern 1623-and-1626

The script docs/lengthdiff is an old pre-git script to automate this. That could be updated to make this a bit less manual.

The catch with this process is that it won't include any caves which have been surveyed but not properly connected into the dataset.

All of this really boils down to the fact that cavern only reports the length of a processed dataset, and only when you process it. It's not recorded in the .3d file so aven can't show you, nor can it have a cumulative tally for all displayed caves. If we had that functionality then there would be a relatively painless point-and-click way to get current lengths. (You'd still need to check out a historical version as well to get _differences_ from one year to the next.

Presumably you are asking this because you think the dataset is 'done' for 2024 now? In which case we can check lengths look good, tidy up a few things and tag 'post-2024'. We can move that along if we find issues later. I should also sort out the ARGE stuff with Thomas.
Hope all that makes sense.
Wookey
--
Principal hats: Debian, Wookware
http://wookware.org/