expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2026-02-27 22:55:20 +00:00
Code Issues Packages Projects Releases Wiki Activity

new documn. - online edit of handbook/troggle/cavelengths.html

Browse Source
This commit is contained in:
Philip Sargent
2025-02-10 01:22:46 +00:00
committed by Expo on server
parent b1529f0918
commit befa837bdf
1 changed files with 143 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

143
handbook/troggle/cavelengths.html Normal file
View File

@@ -0,0 +1,143 @@
<html><head><title>Cave lengths</title></head><body>
<h1>Lengths of Caves</h1>
<h2>How we measure and record the lengths of our discoveries</h2>
<p>This needs to be reformatted and turned into proper documentaiton.
<pre>
Re: SMK length and depth over time / at the end of each Expo
_EXPO-2025
Wookey <wookey@wookware.org>
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?
</pre>
<p>
We have alll the years since 2012 recored in this spreadsheet:
<a download href="https://expo.survex.com/repositories/loser/.git/tree/docs/smklengths.ods">loser/.git/tree/docs/smklengths.ods</a>
<p>
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)?
<pre>
> 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.
</pre>
<p>
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.
<p>
For getting the lenght there are two ways to run at it:
<ol>
<li>process smk-system.svx, or
<li>process all the caves that are part of smk.svx and add them up.
</ol>
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.
<p>
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.
<p>
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'
<p>
There is a script to help with this:
<pre>
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.
</pre>
<p>
You could do the same thing with immense amounts of pointing and clicking, but it would be very tedious.
<p>
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.
<p>
You can also just run:
<pre>
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
</pre>
<p>
The script docs/lengthdiff is an old pre-git script to automate this. That could be updated to make this a bit less manual.
<p>
The catch with this process is that it won't include any caves which
have been surveyed but not properly connected into the dataset.
<p>
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.
<p>
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.
<br>
Hope all that makes sense.
<br>
Wookey<br>
--<br>
Principal hats: Debian, Wookware<br>
http://wookware.org/<br></body></html>