<p>This page <i>is a checklist</i> who are helping the survey data reduction process during and after expo.
<p>All of these things should be checked <em>every week</em> for a couple of months after expo, and then every couple of months. Then again when preparing for the new expo in May.
<p>We do this regularly during software maintenance to check that everything is still working. See the <ahref="../troggle/trogimport.html">database reset</a> documentation. But it must be done:
<ul>
<li>Whenever anybody has uploaded anything directly to the repos using git, without using the online forms: drawings, survey data (in :loser: repo) or handbook updates (in :expoweb:),
<li>Every couple of months, to keep things clean and honest (and to check that the semiautomated OS updates on the server haven't broken anything).
<p>This is much less of a problem now that we have nearly all the file uploading done by troggle forms.
<p>The most common <ahref="https://en.wikipedia.org/wiki/UTF-8">UTF8</a> problem is with files uploaded containing German language umlaut characters which have been encoded using an extended-ASCII code such as ISO-8055-1 or Windows-1251. (All umlauts in webpages and logbook entries should be using &uml;. So this is an issue mostly with survex files and survey files such as topo or tunnel.)
<p>To fix EOL problems, use <var>dos2unix</var> to convert any uploaded Windows text files to the format expected by our software. e.g. <pre><code>cd expofiles/surveyscans
It needs 'tofrodos' package installed. 'unix2dos' can be used instead.
See <ahref="hbmanual1.html">manual</a> for more on encoding conventions for cave names, filenames and HTML formatting.
<h4>Cave names</h4>
Cave names do not have leading zeros
They are stored by number/ID in the dataset, not by name.
create them like this: <ahref="../survey/caveentry.html">Cave Entry</a> and <ahref="manual.html">Data Maintenance</a>.
<h3>Data entry TO-DO list</h3>
<p>A user-editable online to-do list for data management is now <ahref="todo-data.html">part of the expo online systems</a>. Review this regularly to see what needs doing, and please *delete* jobs that have been done.
<h3>Wallets and Surveyscans</h3>
<h4>2020#00</h4>
<p> The <b>#00</b> wallet directory (e.g. /2020/2020<b>#00</b>/ ) contains orphan files that have been found on the expo laptop in odd places, or have been scanned from bits of notebook found inside other documents. Keep an eye on it and re-file the contents as you discover what they are.
<p>As the caves get written up (i.e. as survex files are written), run the QM reports on the updated caves to check that the QM data appears correctly. Check the DataIssues page for import error messages. See the detailed <ahref="https://expo.survex.com/handbook/survey/qmentry.html">QM instructions</a>.
<strike>run <ahref="scriptsqms.html">svx2qm.py</a> and <ahref="scriptsqms.html">find-dead-qms.py</a> to check that the QMs have all be entered correctly into the svx files and that thecave descriptions have been updated with (a) the new open QMs and (b) the old closed QMs.</strike>
<p>You can now upload a <ahref="https://expo.survex.com/handbook/survey/newsurvex.html">new survex file</a> for an existing cave without doing any other preparations.
<p>
This is now obsolete<br/><strike>
Look at the <ahref="svxvalid.html">valid SVX refs</a> page to check that new svx files properly reference the wallet folders, and create the wallet folder link back to the svx if the contents.json file in the wallet folder needs updating.</strike>
<p>During prep. for the new expo the folklist will be updated with all the new people expected, but after expo the mugshots and blurb text for the new people will need to be added. See <ahref="folkupdate.html">folkupdate</a> for the procedure.
