mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-12-23 08:52:29 +00:00
remove the 2022 TICK procedure as it is too complicated - online edit of handbook/survey/qmentry.html
This commit is contained in:
parent
aa95e67c0d
commit
a53d7e2727
@ -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
|
||||||
|
Loading…
Reference in New Issue
Block a user