<!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>