expoweb/handbook/survey/qmentry.html

192 lines
9.5 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>.
<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.
<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>Svx 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/V/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>
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/V/X) nearest-station resolution-station description
;[ QM1 A surveyname.3 - description of QM ]
;[ QM2 B surveyname.5 - description of QM ]
;TICKed off QMs
; in the past, if another survey existed, the resolution-station
; field was filled in, e.g.
;[ QM2 B surveyname.5 anothersurvey.7 description of QM and description of progress ]
; or we can use the trial format
;Serial number TICK date resolution description
;[QM2 TICK 2022-07-20 This is an example ticked QM]
</pre></code>
<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>
<p>Since 2015 we have had no generally-agreed, well-documented or widely-practiced way of recording whether a QM has been ticked-off or not.
<p>In the past, this was done 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>This meant that a QM
could only be ticked-off if there was, in fact, surveyable passage beyond it, and if it was worth surveying, and if
someone did so.
<p>In 2022 we had a proposal 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>