I demonstrated Therion to our local caving club a couple of days ago...

Fantastic! I've been thinking of doing the same thing with my club. If you don't mind my asking, how exactly did you give your presentation? Did you just show how it's used, or did you go more in depth? -Jonny ^v^

Started with showing a bunch of outputs for the cave system I've been working on; -Loch model with 3 caves, terrain model & surface image -SQL and 'continuations' outputs -A bunch of pdf map and atlases including surveyed caves, old scanned cave map and surface image. Then went very broadly and briefly through the process demo-ing the actual input files for the above outputs, 'scan data format', xvi-draw or print_atlas-sketch-scan-trace_scraps drawing alternatives, drew a new bit of passage, had a compile error I couldn't solve on the fly, INDEX files to link it all together and thconfig files to obtain output, and answered questions. A couple of people have taken away my data for the cave system, and hope to use it as a template to draw up some projects they have... 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. There was nothing specific enough on the Wiki when I looked a few months ago - may be better now, I notice there is some nice content on surfaces added recently. Bruce

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@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Wookey Sent: Tuesday, 22 April 2008 10:53 p.m. To: therion@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@speleo.sk http://www.speleo.sk/mailman/listinfo/therion

On 23.4.2008, at 10:32, marco corvi wrote:

maps hierarchies to organize the scraps, and select/unselect to specify what to export

Two section regarding organization of data from therion book: m. How to enter centreline? The basic building block is the centreline command. If the cave is larger than a few meters it's a good idea to split data in more les and separate centreline data from map data. We usually use one *.th le containing centreline per survey trip. It's handy to start with an empty template le as shown bellow, where dots will be replaced with appropriate texts. 37 encoding ISO8859-1 survey ... -title "..." centreline team "..." team "..." date ... units clino compass grad data normal from to compass clino length ... ... ... ... ... endcentreline endsurvey To create a unique namespace the centreline command is enclosed in survey ... end- survey command. It's useful when the survey has the same name as the le which contains it.38 The points will than be referenced using @ character| see the survey command description. For really large caves it's possible to build a hierarchical structure of directories. In such a case we create one special le called INDEX.th which includes all other *.th les from given directory and contains equate commands to de ne connections between surveys. How to draw maps? The most important thing is to devise division of the cave into scraps. Scrap is the basic building block of the map. It's almost always a bad idea to try to t each scrap to corresponding *.th le with centreline from one survey trip. The reason is that connections between scraps should be as simple as possible. Scraps in general are independent on centreline hierarchy so try to forget the survey hierarchy when drawing maps and choose best scrap joins. We usually insert maps in the last-but-one level in survey hierarchy. 39 Each scrap may than contain arbitrary part of any survey in the last level of hierarchy. For example, there is a survey main which contains surveys a, b, c and d. Surveys a { d contain centreline data from four survey trips and each of them is in a separate le. There is a map main_map which contains scraps s1 and s2. If the main_map is located in the main survey, scrap s1 may cover part of the centreline from survey a, complete survey b and part of c; s2 will cover part of the a and c surveys and a complete d survey. The survey stations names will be referenced using @ symbol (e.g. 1@a) in the scraps.40 Scraps are usually stored in *.th2 les. Each le may contain more scraps. To keep data well organized, we have some naming conventions: in the le foo.th2 all scraps are named foo_si, where i is 1, 2 an so on. Cross-sections are named foo_ci, lines foo_li etc. This helps a lot with large cave systems: if some scrap is referenced, you immediately know in which le it had been de ned. Similar to *.th les, there may be one le INDEX.th2 per directory which includes all *.th2 les, de nes scrap joins and maps. When drawing scraps you should check if the outline is properly de ned: all lines creating the outer border should have -outline out option; all lines surrounding inner pillars - outline in option. Scrap outlines can't intersect themselves| otherwise the inner side of the scrap can't be determined. There are two simple tests that scrap outline is correct: there is no METAPOST warning \scrap outline intersects itself" when you set passage ll to any color (color map-fg <number> option in layout), you may see what Therion considers to be inside of the scrap. 38 E.g. survey entrance in the le entrance.th. 39 Remember that surveys create namespaces, so you may reference only objects in the given survey and all subsurveys. 40 If you include maps in the top-level survey, you may reference any survey station in any scrap, which is very flexible. On the other side you have than use longer names in stations references, like 3@dno.katakomby.jmn.dumbier

On 27.4.2008, at 23:08, Bruce Mutton wrote:

As a new user a diagrammatic illustration of the ‘structure’ and perhaps itemized lists of what goes where, with some comprehensive example batch file contents would have helped me, and still would.

Bruce, only short answer. We all have experience with our particular cave system or areas. They are very very different. Therion was developed for documentation of quite complicated cave with many levels overlapping each other. It works in many other cases depending on imagination of its user. The main principle is that the map itself is divided into small pieces - scraps. The scraps are absolutely independent from survey structure created more or less historically. You may use in one scrap data from several surveys made historically in very long interval by different surveyors. Only condition is all the data are accessible in survey which include the map structure with that particular scrap. The main rules to create such structure is to divide the system into horizontal layers (in case of map) which the atlas will be able to recognize and shows in enough simple way. There one may see the importance of idea of scraps -you may reorganize your structure anytime in the future. The main problem is organize the maps and submaps. The structure of survey data itself is existing more or less automatically. I hope MartinB or Stacho may add more. Martin

On 2008-04-28 09:08 +1200, Bruce Mutton wrote:

I still haven't seen anything written about Walls or Tunnel that would make me try them... Well, I would try Walls, but it wouldn't download, and now I like Therion for its conceptual simplicity, even if user error detection can be a bit complex.

From the Tunnel website...

The disadvantages of Tunnel's way are as follows:

1. You have to do a lot of extra editing just to join in a new piece of the survey.

2. You wind up with multiple copies of the same piece of cave in your workspace.

3. You lose the connection to the original drawings so you can't correct them in the original state and see the changes in the final drawing.

4. It's not known how many times a survey could be copied and morphed before unexpected errors of distortion would become a problem.

5. The files for a large survey can become rather large.

The above is correct, but I think doesn't do justice to Tunnel. It has significant advantages too, and thus is worth looking at. It produces nicer output than Therion, because it is possible to edit the final version, e.g. arranging labels in the context of the whole map, not just the current scraps (this is a _major_ problem with the current Therion implementation that pretty-much killed my work with until I get a faster computer). You can also do everything graphically, rather than editing mysterious text files, which is a big deal for the less-nerdy. Being able to use SVG symbols rather than write them in metapost is nice too. I avoided it for years because it was java, but that's less of a problem than it used to be, and I have been very impressed by the quality of the output: http://cucc.survex.com/expo/smkridge/204/surveys/plan2006.png Now that you've learned Therion there is not much point jumping ship, but I just thought I should correct theimpression given above. I will package Tunnel for Debian/Ubuntu when I get a chance so it will be a that bit easier to try it out. Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/

On 22.4.2008, at 12:52, Wookey wrote:

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.

The map attached was drew by Jan Tulis, 65 years old traditional caver. The reason is they have to redraw documentation of quite long and complicated system of Stratenska cave (Slovakia) connected to cave Psie diery and many other caves in that region to receive complete documentation of area. Not only separate paper maps. Martin 

On 2008-04-25 10:20 +1200, Bruce Mutton wrote:

Martin I abandoned involvement in cave map production early 1990s when it became obvious that centerline software and paper map development had outlived it's usefulness.

I have a similar story. I was overwhelmed at about 20km of cave circa 1996, and decided digital was the way forward. I then spent quite a few years rejecting all the schemes that involved propritary drawing packages, fearing putting hundreds of hours of work into some format I might never get my data out of again. Therion is indeed the 'right' answer (in many ways), although I do have issues with the time that the process/view/adjust round-trip takes with its (somewhat old-fashioned) compile/view approach. There are also some limitations introduced by the way the high-level code (therion) has limited control over the low-level stuff (metapost/PDF) (e.g. hatching when joining areas of water). However overall the system is the best currently available, so far as I can tell. One day I'll get back to the 1996 Kaninchenhohle map and therionise it, adding the 97 and 98 finds and producing the first elevation since about 1992 (when that got too hard to draw!) Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/

On Sat, Apr 19, 2008 at 4:52 AM, Bruce Mutton <bruce.mutton@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^