mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-23 07:41:56 +00:00
59 lines
3.1 KiB
HTML
59 lines
3.1 KiB
HTML
|
<html>
|
||
|
|
<head>
|
||
|
|
<title>CUCC Expo Handbook - Data Management</title>
|
||
|
|
<link rel="stylesheet" type="text/css" href="../css/main2.css" />
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<h2 id="tophead">CUCC Expedition Handbook - Data Management</h2>
|
||
|
|
|
||
|
|
<h1>Why cavers need effective data management</h1>
|
||
|
|
|
||
|
|
<div style="text-align:left">
|
||
|
|
<!-- Comment
|
||
|
|
Justified text is hard to read:
|
||
|
|
https://designshack.net/articles/mobile/the-importance-of-designing-for-readability/
|
||
|
|
https://designforhackers.com/blog/justify-text-html-css/
|
||
|
|
-->
|
||
|
|
|
||
|
|
<p>
|
||
|
|
Cave exploration is more data-intensive than any other sport. The only way to "win" at this
|
||
|
|
sport is to bring back large quantities of interesting survey, and possibly photos or scientific
|
||
|
|
data. Aside from the data collection requirements of the game itself, setting up a game (an
|
||
|
|
expedition) of cave exploration often involves collection of personal information ranging from
|
||
|
|
dates available to medical information to the desire to purchase an expedition t-shirt.
|
||
|
|
<p>
|
||
|
|
If an expedition will only happen once, low-tech methods are usually adequate to record
|
||
|
|
information. Any events that need to be recorded can go in a logbook. Survey notes must be
|
||
|
|
turned into finished cave sketches, without undue concern for the future expansion of those sketches.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
However, many caving expeditions are recurring, and managing their data is a more challenging
|
||
|
|
task. For example, let us discuss annual expeditions. Every year, for each cave explored, a list
|
||
|
|
of unfinished leads (which will be called "Question Marks" or "QMs" here) must be maintained to
|
||
|
|
record what has and has not been investigated. Each QM must have a unique id, and information
|
||
|
|
stored about it must be easily accessible to future explorers of the same area. Similarly, on
|
||
|
|
the surface, a "prospecting map" showing which entrances have been investigated needs to be
|
||
|
|
produced and updated at least after every expedition, if not more frequently.
|
||
|
|
|
||
|
|
<p>
|
||
|
|
These are only the minimum requirements for systematic cave exploration on an annual expedition.
|
||
|
|
There is no limit to the set of data that would be "nice" to have collected and organized
|
||
|
|
centrally. An expedition might collect descriptions of every cave and every passage within every
|
||
|
|
cave. Digital photos of cave entrances could be useful for re-finding those entrances. Scans of
|
||
|
|
notes and sketches provide good backup references in case a question arises about a finished
|
||
|
|
survey product, and recording who did which survey work when can greatly assist the workflow,
|
||
|
|
for example enabling the production of a list of unfinished work for each expedition member. The
|
||
|
|
expedition might keep an inventory of their equipment or a catalog of their library. Entering
|
||
|
|
the realm of the frivolous, an expedition might store mugshots and biographies of its members,
|
||
|
|
or even useful recipes for locally available food. The more of this information the expedition
|
||
|
|
wishes to keep, the more valuable an effective and user-friendly system of data management.
|
||
|
|
|
||
|
|
</div>
|
||
|
|
<p><em>From "<a href="../../troggle/docsEtc/troggle_paper.odt" download>
|
||
|
|
Troggle: a novel system for cave exploration information management</a>", by Aaron Curtis, CUCC.</em>
|
||
|
|
<hr />
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|