remove the 2022 TICK procedure as it is too complicated - online edit of handbook/survey/qmentry.html

This commit is contained in:
Expo on server 2024-07-20 10:34:53 +01:00
parent aa95e67c0d
commit a53d7e2727

View File

@ -138,29 +138,28 @@ real content replaces template text):</p>
;[ QM2 B surveyname.5 - description of QM ] ;[ QM2 B surveyname.5 - description of QM ]
;TICKed off QMs ;TICKed off QMs
; in the past, if another survey existed, the resolution-station ; if another later survey exists, the resolution-station
; field was filled in, e.g. ; field is filled in, e.g.
;[ QM2 B surveyname.5 anothersurvey.7 description of QM and description of progress ] ;[ QM2 B surveyname.5 anothersurvey.7 description of QM and description of progress ]
; or we can use the trial format ; or if there is no survey, but the QM is dead tehn repeat the original survey station:
;Serial number TICK date resolution description ;[ QM2 B surveyname.5 surveyname.5 description of QM resolution DATE and description of results ]
;[QM2 TICK 2022-07-20 This is an example ticked QM]
</pre></code> </pre></code>
<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 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>In the past, this was done by <p>We now do this by
<ol> <ol>
<li>surveying into the passage beyond the QM, <li>surveying into the passage beyond the QM,
<li>creating a new survex file for that survey, <li>creating a new survex file for that survey,
and then 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. <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 </ol>
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 <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 satstion 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 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): easily on-line (and the version control happens invisibly and automatically):
<code> <code>
@ -175,7 +174,7 @@ in <a href="/survexfile/caves-1623/258/flashhard2.svx">258/flashhard2.svx</a>. <
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> 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. <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> <h3>Programming note</h3>
<p>Better handling of historic QMs is a current, occasionally active, area of <p>Better handling of historic QMs is a current, occasionally active, area of