mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-22 07:11:55 +00:00
190 lines
9.9 KiB
HTML
190 lines
9.9 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
<title>Handbook - survex - QMs</title>
|
|
<link rel="stylesheet" type="text/css" href="/css/main2.css" />
|
|
</head>
|
|
<body>
|
|
<h2 id="tophead">CUCC Expedition Handbook - New Cave - QMs</h2>
|
|
<h1>Adding QMs (Question Marks)</h1>
|
|
|
|
<h2>QM data and cave descriptions</h2>
|
|
|
|
<p>
|
|
This document describes how to include Question Marks (QMs) and cave descriptions in .svx files.
|
|
|
|
<p>This is the current list of <a href="/cave/qms/1623-290">QMs for 1623-290</a><br />
|
|
These are the current <a href="qm.html">QM naming and numbering rules</a>.
|
|
|
|
|
|
<p>There
|
|
are dedicated fields in the template.svx file for this purpose, but there has been laxness recently on filling them in.
|
|
It seems to be an unknown resource among too many expo-goers despite the manifold benefits.
|
|
|
|
<h3>Why do we want to do this?</h3>
|
|
<p>
|
|
We need to store Question Marks (QMs) and cave description data in an easy-to-use format for setting objectives and planning trips. As of the end of the 2022 expo, we have 1,374 QMs tracked in our records.
|
|
|
|
<p>When planning an expo, it is necessary to work out where leads are in each cave before
|
|
arriving in Austria to make effective use of time and equipment. The most readily
|
|
accessible place for such information is in .svx files, because this is more efficient
|
|
compared to including QMs only in survey drawings in Tunnel or writing a cave
|
|
description then putting it on the expo website.
|
|
|
|
<p>Survex files are a very stable place to store the data long-
|
|
term: there is no need to rely on a 'master file' of any kind, which can be problematic if not everyone
|
|
on expo has the same level of computer literacy, and requires just basic text entry to create and update
|
|
the data after a trip.
|
|
|
|
<h3>How it's done:</h3>
|
|
<p>
|
|
So, you've got your .svx file started (if entering new data), or located and opened (if updating a
|
|
previously surveyed bit of cave after checking out some QMs again), and it looks a bit like this (visual
|
|
format will change depending on your preferred text editor):
|
|
<p>
|
|
<img src="wob-svx-edit-pic.jpg" width=900>
|
|
|
|
<p>
|
|
If you don't understand what is in front of you here, then you need to read the <a href="newsurvex.html">survey handbook guide on svx files</a> which will lead you to the survex documentation, or ask
|
|
someone about basic entry of survey leg and station data into the .svx file format.
|
|
<p>
|
|
Near to the end of the text in the file, you will see a section that looks like this:
|
|
<p>
|
|
<img src="wob-svx-edit-pic2.jpg" width=900>
|
|
<p>
|
|
This is where the action is! You literally just follow the instructions in the file to create QM and cave
|
|
description data, replacing the template text with your own as you would with the cave passage data.
|
|
<p style="margin:4%">
|
|
<em>Technical Note:</em> The syntax for a QM includes a leading semi-colon. So it is syntactically a "comment" so far
|
|
as the survex software is concerned. But we have other software and scripts in the Expo online system which inderstand
|
|
just fine that these are QMs.
|
|
|
|
<p>
|
|
Here is an example from the last bit of bipedalpassage.svx in 264. Note that each QM description is all on one line.
|
|
<pre><code>;-----------
|
|
;Question Mark List ;(leave commented-out)
|
|
<em>;Serial number grade(A/B/C/D/X) nearest-station resolution-station description</em>
|
|
;QM1 A bipedalpassage.1 - Very good. 50m+ (?) deep pit below start of 13 bolt bipedal traverse - rather slanted, large ongoing rift glimpsed below. very good.
|
|
;QM2 A bipedalpassage.3 - Very good. 50m+ (?) deep pit below end of 13 bolt bipedal traverse. best approched via station 4 (?) and looks ok to rig. May connect to first deep pit.
|
|
;QM3 C bipedalpassage.1 - Poor c lead, across thin rock bridge over abyss (!) leads to blind aven, but small tube for thin person on left.
|
|
;QM4 A bipedalpassage.10 - Good. Ongoing big phreatic passage forms pitch dropped in Bipedal Passage4 by Ben, then continued by Mike and Elain on Aug 6th.
|
|
;QM5 C bipedalpassage.9 - Speculative - climb up needs short 5-10m rope - could be tube in roof.
|
|
;QM6 C bipedalpassage.31 - Very good location where main phreatic passages and enlarges - but far side of chamber choked. One part of choke was not accessed as needs 2m climb up to poke nose in it. A good free climber could do this or needs one bolt to be sure no way on. Very strong draft in choke! Interesting southerly trend at margin of known system
|
|
</code></pre>
|
|
|
|
<p>
|
|
The format for question mark lists is <br>
|
|
<ul>
|
|
<li>QM identifier,
|
|
<li><a href="qm.html">Quality Grade</a>,
|
|
<li>nearest survey station, (which should be in the same survex file)
|
|
<li>resolution survey station, initially a "-", explained in <a href="#tick">Ticking off a QM</a> below
|
|
<li>description of QM.
|
|
</ul>
|
|
<p>The QM numbers themselves used to be in the format <br>
|
|
<ul>
|
|
<li><a href="qm.html">Discoverer identifier</a>, <li>Year of discovery, <li>Cave identifier, <li>serial number.
|
|
</ul>
|
|
but today, with the QMs inside the survex files, the identifiers are QM1, QM2 etc.
|
|
<p>This format is <a href="qm.html">documented in the original QM conventions</a> page.
|
|
|
|
|
|
<style>figure {font-weight: bold; font-size: small; font-family: sans-serif;font-variant-caps: small-caps;}</style>
|
|
<div class="onright">
|
|
<figure>
|
|
<a href="cavedescription.html">
|
|
<img src="../t/svx-cave-descript.jpg"></a>
|
|
<figcaption style="font-variant-caps: small-caps;">
|
|
<em>Cave description in survex file (click for more)</em>
|
|
</figcaption>
|
|
</figure>
|
|
</div>
|
|
<h3>Cave Descriptions</h3>
|
|
<p>The description of the passage is written in the same way as you write QMs, but as free text without
|
|
formatting. See the single line at the bottom of the figure below and
|
|
in more detail on the <a href="cavedescription.html">Cave Description"</a> handbook page.
|
|
|
|
<h3 id="example">Full QMs example - initial data entry</h3>
|
|
<p>
|
|
The example below demonstrates correct and effective use of the QM list referring back to earlier elements in the svx
|
|
file. Cave descriptions are done in a similar way, see the <a href="cavedescription.html">Cave Description"</a>
|
|
handbook page.
|
|
<p>
|
|
<img src="wob-svx-edit-pic3.jpg" width=900>
|
|
<p>
|
|
<p>
|
|
If these data are not entered along with the rest of the survey data, it is as if you decided not to enter
|
|
some of the actual passage data you surveyed: information is being lost and someone will have to
|
|
trawl back through all the survey data at a later time to keep it up-to-date, a very tedious task which
|
|
is a very inefficient use of time.
|
|
<p>Also if the person reading it hasn't been to the bit of cave (which is, like, <em>the whole point</em>, then the
|
|
data has a higher chance of being incorrect. It is not always easy to interpret Tunnel or Therion drawings correctly
|
|
with this sort of thing.
|
|
<h4 id="tick">Ticking off a QM</h4>
|
|
|
|
Below is part of the current template file (square brackets must be removed as
|
|
real content replaces template text):</p>
|
|
<code><pre>;-----------
|
|
;Question Mark List ;(leave commented-out)
|
|
; The nearest-station is the name of the survey and station which are nearest to
|
|
; the QM. The resolution-station is either '-' to indicate that the QM hasn't
|
|
; been checked; or the name of the survey and station which push that QM. If a
|
|
; QM doesn't go anywhere, set the resolution-station to be the same as the
|
|
; nearest-station. Include any relevant details of how to find or push the QM in
|
|
; the textual description.
|
|
;Serial number grade(A/B/C/D/X) nearest-station resolution-station description
|
|
;[ QM1 A surveyname.3 - description of QM ]
|
|
;[ QM2 B surveyname.5 - description of QM ]
|
|
|
|
;TICKed off QMs
|
|
; if another later survey exists, the resolution-station
|
|
; field is filled in, e.g.
|
|
;[ QM2 B surveyname.5 anothersurvey.7 description of QM and description of progress ]
|
|
|
|
; or if there is no survey, but the QM is dead then repeat the original survey station:
|
|
;[ QM2 B surveyname.5 surveyname.5 description of QM resolution DATE and description of results ]
|
|
</pre></code>
|
|
|
|
|
|
<p>In 2015 we had had no generally-agreed, well-documented or widely-practiced way of recording whether a QM has been ticked-off or not.
|
|
|
|
<p>We now do this by
|
|
<ol>
|
|
<li>surveying into the passage beyond the QM,
|
|
<li>creating a new survex file for that survey,
|
|
and then
|
|
<li>editing the original survex file using the name of one of those new survey stations as the "resolution-station", replacing the "-" previously there.
|
|
</ol>
|
|
|
|
<p>If the new QM is explored but is not worth surveying (e.g. a snow-filled drop which in a later year is seen to be just a pile of snow), then edit the original survex file to repeat the same survey station as the "resolution station" and put a comment with the <em>date</em> this was done and a reference to the logbook entry or wallet.
|
|
|
|
<!--<p>In 2022 we had a proposal (which was coded into troggle) to add an extra line to the original survex file, now that survex files can be edited
|
|
easily on-line (and the version control happens invisibly and automatically):
|
|
|
|
<code>
|
|
QM<em>nn</em> TICK <em>date comment</em>
|
|
</code>
|
|
e.g.<code>
|
|
QM15 TICK 2022-07-20 This is a dummy ticked QM</code>
|
|
|
|
<p>as illustrated in
|
|
<a href="/cave/qms/1623-258/2015-15Aflashh2">2015-15A</a>
|
|
in <a href="/survexfile/caves-1623/258/flashhard2.svx">258/flashhard2.svx</a>. <br>
|
|
The TICKed QM appears at the end of the report <a href="/cave/qms/1623-258">/cave/qms/1623-258</a> at the bottom of the page.</p>
|
|
|
|
<p>The <var>date</var> field is sufficient to tie the tick-off event to one of a small number of logbook entries and survex files, which is where the actual exploration would be documented. If it was a rapid dead-end, or if later parties can't find it at all, then there should be just a logbook entry.
|
|
-->
|
|
|
|
<h3>Programming note</h3>
|
|
<p>Better handling of historic QMs is a current, occasionally active, area of
|
|
development in our online systems. The current status is <a href="../troggle/scriptsqms.html">documented here</a>.
|
|
|
|
<h3>Conclusion</h3>
|
|
<p>Survey data recorded in .svx files is incomplete if there is no QM List data and
|
|
cave description data!
|
|
|
|
<hr />
|
|
<p>Return to "<a href="newsurvex.html">Survey handbook - survex format</a>".</p></body>
|
|
</html>
|