expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-12-22 16:32:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Expo on server 2024-07-20 10:34:53 +01:00
parent aa95e67c0d
commit a53d7e2727
1 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
handbook/survey/qmentry.html
View File

@ -138,29 +138,28 @@ real content replaces template text):</p>
;[ 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.
; 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 we can use the trial format
;Serial number TICK date resolution description
;[QM2 TICK 2022-07-20 This is an example ticked QM]
; or if there is no survey, but the QM is dead tehn repeat the original survey station:
;[ QM2 B surveyname.5 surveyname.5 description of QM resolution DATE and description of results ]
</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>
<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.
</ol>
<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):
<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>
<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