mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2025-12-08 14:54:28 +00:00
144 lines
5.2 KiB
HTML
144 lines
5.2 KiB
HTML
<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>
|