[Therion] Hopefully a bunch of new users

[Jonathan Prouty]

On Sat, Apr 19, 2008 at 4:52 AM, Bruce Mutton
<bruce.mutton at paradise.net.nz> wrote:
>  If anyone has already documented a Therion data management system I would be
>  most interested.

My data management approach is similar to the method that Marco
described. I use a combination of filesystem organization and Therion
survey hierarchy to organize my data.

Filesystem organization consists of directories and sub-directories
(or folders and sub-folders, whichever nomenclature you prefer),
nested as deeply as is necessary to sufficiently handle my data.
Typically this consists of a directory representing the area of
interest, sub-directories for individual caves, and then
sub-sub-...-directories for distinct types of data.

Here are a few examples:
The path describing a scanned page of notes might be

'./fox_mountain/pen_fifteen/survey/notes/2006-09-21_a.png'

The path describing some Therion formatted survey data from that same
trip might be

'./fox_mountain/pen_fifteen/survey/therion/2006-09-21.th'

The path describing a picture that was taken on that trip might be

'./fox_mountain/pen_fifteen/pictures/2006-09-21/dusty_climbing_pen15_shaft.png'

Considering that using Therion is only one aspect of documenting a
cave, the filesystem hierarchy is designed to manage much more than
just Therion data. Having descriptive directory names is also very
useful when you are grepping through your data, looking for something
specific.

As far as the Therion data itself goes, I usually create a separate
.th file for each survey trip. This .th file consists of one parent
survey with several subordinate surveys. Centerline data goes in one
survey, splay shots or radiating legs (whatever you refer to them as)
go in a separate survey.

I've been using a single .th file to input and select/deselect
centerline data, splay data, and scrap data for each cave. I've been
doing all my joins and equates in this file, as well. This has worked
well for shorter caves that were surveyed in just a few trips, but the
master .th file quickly becomes unruly for caves that have had
numerous survey trips.

I would suggest having a single file to handle all your centerline and
splay data and a single file to handle all your scrap data. The master
.th file then does not become cluttered with hundreds of joins and
equates. I plan on reorganizing my data in this manner.

I generally have only one thconfig, as well.

Hope this helps!

-- 
-Jonny ^v^