[Therion] Hopefully a bunch of new users
On Sat, Apr 19, 2008 at 4:52 AM, Bruce Mutton 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^
[Therion] Hopefully a bunch of new users; Optimum Data Managment
On Wed, 2008-04-23 at 08:11 +1200, Bruce Mutton wrote: > Thanks Wookie. > Can not believe paper is better, but then in the 6 months I've been learning > Therion, it has improved a lot... Any more information or examples > appreciated. > > At present it's only my thconfig files that I think are messy and confusing. > I'm working on making them very much more modular, a separate sub-thconfig > file for every task. > > A thought; being able to pass a variable between thconfig files or even from > .th files to thconfig files could make things easier by avoiding, for > example, changing the name of maps to match the cave name. See the > following example > > ... hi, i'm no expert about "data management", i can just tell what i tried for a cave that's more than a few surveys/scraps. it is still in a fuzzy shape, and it's just what i experienced (ie, tested on caves, a few km long). a directory for surveys, with a subdirectory for each survey (each with its own thconfig, more on this later). a second directory with subdirectories to group the surveys together (each group with its thconfig). finally other directories to put together the whole cave (with their thconfigs) different thconfigs for different tasks (pdf maps, 3d model, etc.) some "include thconfig" with the common layouts for the surveys and groups and cave thconfigs. maps hierarchies to organize the scraps, and select/unselect to specify what to export makefile to make what's needed. one could create thconfigs on the fly (never tried: never had the need). marco
[Therion] Hopefully a bunch of new users; Optimum Data Managment
Thanks Wookie.
Can not believe paper is better, but then in the 6 months I've been learning
Therion, it has improved a lot... Any more information or examples
appreciated.
At present it's only my thconfig files that I think are messy and confusing.
I'm working on making them very much more modular, a separate sub-thconfig
file for every task.
A thought; being able to pass a variable between thconfig files or even from
.th files to thconfig files could make things easier by avoiding, for
example, changing the name of maps to match the cave name. See the
following example
In thconfig file...
/code
#SELECT DATA MAPS
#
# selects all surveys/maps in 'sources' if not explicitly specified
# if is specified, prints 'title' in map legend
select MiddleEarthPlanMap # from MiddleEarthINDEX.th
select MiddleEarthxElevMap # from MiddleEarthINDEX.th
select MiddleEarthElev290Map # from MiddleEarthINDEX.th
#MAP/ATLAS IMAGE EXPORTS
#===
export map -projection plan \
-layout ThisCaveMapLayout \
-layout ThisMapPlanLayout \
-output ../Outputs/MiddleEarthPlan.pdf
export map -projection [elevation 290 deg] \
-layout ThisCaveMapLayout \
-layout ThisMapElev290Layout \
-output ../Outputs/MiddleEarthElev290.pdf
export map -projection extended \
-layout ThisCaveMapLayout \
-layout ThisMapxElevLayout \
-output ../Outputs/MiddleEarthExtendedElev.pdf
/endcode
In the above, if the text "MiddleEarth" was replaced with a variable that
represented the cave name defined in the file MiddleEarthINDEX.th, then that
would save quite a lot of fiddling about when dealing with multi-cave or
multi-part-of-cave datasets.
Regards
Bruce
-Original Message-
From: therion-bounces at speleo.sk [mailto:therion-boun...@speleo.sk] On Behalf
Of Wookey
Sent: Tuesday, 22 April 2008 10:53 p.m.
To: therion at speleo.sk
Subject: Re: [Therion] Hopefully a bunch of new users
On 2008-04-19 20:52 +1200, Bruce Mutton wrote:
> which brings me
> to the single biggest hurdle that continues to dog me with Therion - how
to
> arrange ones data? I realise there's probably about 50 good ways to do
> this, depending on ones needs and expectations, and some are described
very
> vaguely in the documentation. I think I'm heading towards a reasonable
> strategy that's scalable from single caves to 60km systems with numerous
> small surficial caves nearby. When I've got the bugs ironed out I'll see
if
> I can get something into the Wiki. Probably in the form of some actual
> data, suitably scrambled so that it does not reflect a real cave, and with
> commonly used statements pre-entered and commented and well documented.
>
> If anyone has already documented a Therion data management system I would
be
> most interested.
The mulu project considered this at length a couple of years ago and
came up with a couple of approaches. These were confined by the fact
that the base centreline data was entered as Survex data, not as
therion data, and this makes things much more finiky. We did get it
all working eventually, but the people who ran the project eventually
decided they didn't like therion ('too complicated') and have gone
back to paper drawing (!), so my efforts on it kind of stopped.
I'm not sure if our final conclusions are properly documented anywhere
other than as our existing dataset, although you can probably infer
some of it from threads on this list. What there is may be the 'vague'
stuff on the wiki.
The optimium method if exclusivley using Therion would be different
(and simpler).
Wookey
--
Principal hats: Balloonz - Toby Churchill - Aleph One - Debian
http://wookware.org/
___
Therion mailing list
Therion at speleo.sk
http://www.speleo.sk/mailman/listinfo/therion
