Training Course Guide for Therion from the UK Cave Surveying Group
Over the past couple of years the UK based Cave Surveying Group (CSG) have run a number of training courses to teach DistoX Paperless surveying and drawing up with Therion. I have now written the first draft of a training guide based on the data gathered on one of these courses. The CSG also have a new website where we are starting to publish online. The CSG homepage is http://cp.cavesurveying.org.uk/ The training course and example data can be found here: http://cp.cavesurveying.org.uk/index.php/articles/3-therion-tutorial I would welcome any feedback on the content of the tutorial as it is an on going project to improve the content to cover more features of Therion, and to correct any mistakes in the parts I have written so far. Perhaps someone with wiki editing permissions could add a link to this training material to the therion wiki too? Footleg
On 13/06/12 14:33, Footleg wrote:
Perhaps someone with wiki editing permissions could add a link to this training material to the therion wiki too?
Done http://therion.speleo.sk/wiki/doku.php?id=start Andrew
That is looking great Footleg. Clear and concise documentation with non-essential stuff stripped away. Fantastic! It should be placed above my similar entry on the Therion wiki page, and not below! A minor quibble. "Note that the team members names are only allowed to contain one space character, so use hyphens for double barrelled names or your project will generate an error when you try to compile it."
From the Therion Book " person ◃ a person’s first name and surname separated by whitespace characters. Use ‘/’ to separate first name and surname if there are more names."
So perhaps rephrase to "Note that the team members names are only allowed to contain one space character. You can use a forward-space character, /, to emulate the second and subsequent spaces in a name. If you don't, your project will generate an error when you try to compile it." I'll keep reading... Bruce
From the Therion Book " person ◃ a person’s first name and surname separated by whitespace characters. Use ‘/’ to separate first name and surname if there are more names."
Thanks for that tip Bruce. I've updated the training material to reflect this. Footleg
I would welcome any feedback on the content of the tutorial as it is an on going project to improve the content to cover more features of Therion, and to correct any mistakes in the parts I have written so far.
Hi, one thing more: we use for control of walls and joins or colour map-fg or colour map-bg. One may see all uncorrect joins very easy: check it with your pit sample. Martin s.
Already I was unhappy with the way I introduced additional scraps in this training guide because it is not a simple case, and jumps in too much at the deep end. This was constrained by the actual example data the course was based on. Really I need to generate some more useful example data to illustrate concepts in a more gentle way. I've not covered joining scraps for example because my data did not fit well with that. I've also learned a lot more since writing this guide about joining scraps along features where the cave changes altitude to give better joins at pitch boundaries etc. So the plan is to split off this guide on starting from actual DistoX data to cover the workflow of getting the data from PocketTopo into Therion, and write a more general Therion Tutorial starting with some more illustrative data and building up from the basics to more advanced concepts. The first guide will lead into the second to turn the beginner into an expert! I am learning Therion myself along the way, so at each stage I learn something new I am trying to explain it in simple terms so that a new user can understand it from my guide, without needing to ask a load of questions on this mailing list first! Keep the suggestions coming, and especially any corrections to my novice understanding of some aspects of Therion. It will make for a better overall tutorial guide. Footleg On 14 June 2012 06:58, Sluka Martin <martinsluka@me.com> wrote:
I would welcome any feedback on the content of the tutorial as it is an on going project to improve the content to cover more features of Therion, and to correct any mistakes in the parts I have written so far.
Hi,
one thing more: we use for control of walls and joins or colour map-fg or colour map-bg. One may see all uncorrect joins very easy: check it with your pit sample.
Martin s. _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
Already I was unhappy with the way I introduced additional scraps in this training guide because it is not a simple case, and jumps in too much at the deep end. ...
So the plan is to split off this guide on starting from actual DistoX data to cover the workflow of getting the data from PocketTopo into Therion, and write a more general Therion Tutorial starting with some more illustrative data and building up from the basics to more advanced concepts. The first guide will lead into the second to turn the beginner into an expert!
Footleg, I really like the pace and style of your initial guide. In a straight forward way it gets the student to a real map and model in only a few steps. For me it is the key point of difference to what we have already. So don't make your revision too detailed or too comprehensive in the introductory lessons. (Subject to live testing on Therion novices of course) Bruce
footleg, i read your tutorial three times, and i agree with bruce. i'm probably not completely new to therion, so i'm sort of biased judging it, but,to me it is a very good intro to therion. there is an emphasis of getting the cave data from distox. this means to skip talking about the data-entry in xtherion, for instance. as well as other things. but it's in the title that it is about therion AND distox, ... and it makes sense, as it is something for the course you have mentioned. one thing in your tutorial made me think about: you define a map even when there is one single scrap. from therion book, this is not necessary, as therion outputs the scraps of the survey if there is no map. i must say that i use to do the same: whenever i have a scrap i define a map for it. next you add the second scrap to the map and must put in the "break". following my habits i would have defined a new map with the two scrap' maps ... and i found that with the two scraps the break is needed, with two maps there is no need for it. and much more about map arrangements which is beyond this mail topic. now i have a question (for anyone, not just footleg): when is it better to use a map with two scraps, and when a map with twp maps? by the way, footleg, it's really a great tutorial. looking forward to see it complete. marco ________________________________ From: Bruce <bruce@tomo.co.nz> To: 'List for Therion users' <therion@speleo.sk> Sent: Saturday, June 16, 2012 12:20 AM Subject: Re: [Therion] Training Course Guide for Therion from the UK Cave Surveying Group
Already I was unhappy with the way I introduced additional scraps in this training guide because it is not a simple case, and jumps in too much at the deep end. ...
So the plan is to split off this guide on starting from actual DistoX data to cover the workflow of getting the data from PocketTopo into Therion, and write a more general Therion Tutorial starting with some more illustrative data and building up from the basics to more advanced concepts. The first guide will lead into the second to turn the beginner into an expert!
Footleg, I really like the pace and style of your initial guide. In a straight forward way it gets the student to a real map and model in only a few steps. For me it is the key point of difference to what we have already. So don't make your revision too detailed or too comprehensive in the introductory lessons. (Subject to live testing on Therion novices of course) Bruce _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
The training course and example data can be found here: http://cp.cavesurveying.org.uk/index.php/articles/3-therion-tutorial
I would welcome any feedback on the content of the tutorial as it is an on going project ...
I have a question for the Therion Gods. I notice the example uses a data format with the map definition INSIDE the survey like this... survey bpw input bpw.th2 map bpwMP bpwSP1 break bpwSP2 endmap centreline date 2011.12.03 <etc> endcentreline endsurvey I have always tried to keep my map definitions OUTSIDE of surveys, as I've been following the dictum to keep surveys and maps as independent as possible. Having said that, Therion seems to think my maps are inside the survey one level up in the hierarchy, for example I need to specify items like; select bpwMP@BullPotFarm (assuming, hypothetically that the example project is developed to include a few more caves, and collects them into survey called BullPotFarm), instead of just select bpwMP which is what I normally get for a single level survey like the one in the example. It has always confused me a little, as there seems to be no reason, based on my inputs, that the maps should be part of any survey. Theoretically they should be a completely independent hierarchy (I think). And the Xtherion map structure window places them in their own hierarchy (independent of surveys), but in the lower levels therion puts them in a survey like @BullPotFarm when it is double clicked to produce a 'select' statement. Everything compiles fine, so I just accept it and put it down to one of life's little mysteries. So enlighten me. Is Footlegs example with the map defined within a survey the preferred way to define maps? (because therion will force them into a survey if you have more than one level of surveys anyway?) Or are there more ways to do things, with various pros and cons? Bruce
On 14/06/12 09:07, Bruce wrote:
I have always tried to keep my map definitions OUTSIDE of surveys, as I've been following the dictum to keep surveys and maps as independent as possible. Having said that, Therion seems to think my maps are inside the survey one level up in the hierarchy, for example I need to specify items like; select bpwMP@BullPotFarm
Interesting interpretation, which had not crossed my mind, which is why I arrange the maps as it is in Footlegs example.
From my point of view (although I am very interested in what the 'gods' had in mind) I had interpreted it that the maps would probably be better if they did not equate to survey trip into caves not the survey-endsurvey nest. Now I understood this was because surveys trips tend to finish at junctions, which is the worse place to join maps. Also side passages are inevitably junctions. So I just slightly altered my surveying method, to one that I should have been doing before Therion. I just made sure that every side passage had a leg down it, now with the distoX this is really easy, you do not even have to go into the passage, the point just becomes temporary until you go back and survey the passage, but it removes the map join from the junction. In reality we should have always done this, as it show leads on the centreline and their direction, which has lead to a few links been discovered that in the past we would have ignored until much latter.
For older data where survey trips do not correspond to maps, I still put maps in survey-endsurvey nests to get something like this survey 1 map 1a endmap map 1b endmap endsurvey survey 2 map 2 endmap endsurvey survey a centreline endcentreline endsurvey Although generally I have moved to put them into one survey-endsurvey which I find gives better naming control survey cavename map 1a endmap map 1b endmap map 2 endmap centreline endcentreline endsurvey Anyway it works for me, although I am always interested in more efficient/clear systems Andrew
On 14/06/12 09:07, Bruce wrote:
I have always tried to keep my map definitions OUTSIDE of surveys, as I've been following the dictum to keep surveys and maps as independent as possible. Having said that, Therion seems to think my maps are inside the survey one level up in the hierarchy, for example I need to specify items like; select bpwMP@BullPotFarm
I wrote that before I thought hard enough about why therion thinks my maps are inside the survey of the hierarchy level above. Sorry, this is a ramble, perhaps it is relevant to the training guide, perhaps not. This is what I do #File Survey1.th #one file per survey survey surv1 centreline endcentreline endsurvey input Survey1.th2 #drawing file map1 scrap1 #from drawing file scrap2 endmap #endfile At this level these maps are not associated with any survey hierarchy (except of course the survey stations in the scraps are referenced to the survey). At the next level I have #File INDEXCave.th survey CaveA centreline input Survey1.th #here is where map1 becomes part of survey CaveA <etc> equates... endcentreline endsurvey joins... map CaveAPlan map1@CaveA <etc> endmap #endfile So that is explained, I have a hybrid system where maps are incorporated into the survey hierarchy 'one level up'. I don't know if this is good or not. A system where survey and map hierarchies might be completely independent might be (untested but I think some of you were suggesting something like this years ago)... #File Survey1.th #one file per survey survey surv1 centreline endcentreline endsurvey #endfile #File INDEXCave.th survey CaveA centreline input Survey1.th #no maps to get caught up this time <etc> equates... endcentreline endsurvey #endfile #File Maps.th #collect together all the maps input Survey1.th2 #drawing file <etc> map1 scrap1 #from drawing file scrap2 endmap <etc> joins map CaveAPlan map1 ##@CaveA no longer required(?) <etc> endmap #endfile The Maps.th file could become huge, so splitting it up in a similar manner to the surveys might be better. I find it easier to navigate and edit hundreds of small files than a few 1000+ line files. This system requires all maps to have a unique name, but I think Therion already requires all scrap names to be unique over any one dataset, so our naming conventions probably already handle this. Not sure what this means for the training guide. Ie relevant or not? Therion God input? I think regardless of the approach taken with survey and map hierarchies, that users need to organise (plan) the survey network structure to be 'just right' before drawing very much at all. Ie make sure the cave-list output correctly recognises where one cave starts and another finishes, and it seems we need to keep overland surveys separate at the moment (5.3.9) to avoid survey statistics errors. The reason is that regardless of how independent the hierarchies are, the stations in scraps are always referenced to a survey, and if you rename that survey or split it in two after you have done the drawings, you have a really confusing 'find and replace' exercise to do. Perhaps all the training guide should say is... "Before you start drawing, it pays to make sure you won't want to move survey stations from one survey to another, as in the drawing process many linkages are made, and they can be extremely tedious to modify once the map is complete. On the other hand, Therion will morph the drawings to accommodate even gross changes (usually) made at a later date to survey readings themselves, so you can afford to final check the actual readings after the drawing is complete." :] Bruce PS: Martin Slukas tip on adding colour to highlight scrap outline errors is a compulsory setting for me.
The original idea of Therion is that "survey" represents one survey trip. With all the data connected with this trip. Date, persons, instruments, comments in each point, trip report as comment etc. etc. It could have no any relations to a final map. So it is not the best idea to manipulate with surveys. Map represents independent structure of particular maps created final map. With possibility to select smaller part of it. I use index structure for definition of maps. So at the end I may simply include another map.index to create different map from data. I never tried a nested structure of this index files. m.s. On Jun 14, 2012, at 11:42 PM, Bruce <bruce@tomo.co.nz> wrote: On 14/06/12 09:07, Bruce wrote:
I have always tried to keep my map definitions OUTSIDE of surveys, as I've been following the dictum to keep surveys and maps as independent as possible. Having said that, Therion seems to think my maps are inside the survey one level up in the hierarchy, for example I need to specify items like; select bpwMP@BullPotFarm
I wrote that before I thought hard enough about why therion thinks my maps are inside the survey of the hierarchy level above. Sorry, this is a ramble, perhaps it is relevant to the training guide, perhaps not. This is what I do #File Survey1.th #one file per survey survey surv1 centreline endcentreline endsurvey input Survey1.th2 #drawing file map1 scrap1 #from drawing file scrap2 endmap #endfile At this level these maps are not associated with any survey hierarchy (except of course the survey stations in the scraps are referenced to the survey). At the next level I have #File INDEXCave.th survey CaveA centreline input Survey1.th #here is where map1 becomes part of survey CaveA <etc> equates... endcentreline endsurvey joins... map CaveAPlan map1@CaveA <etc> endmap #endfile So that is explained, I have a hybrid system where maps are incorporated into the survey hierarchy 'one level up'. I don't know if this is good or not. A system where survey and map hierarchies might be completely independent might be (untested but I think some of you were suggesting something like this years ago)... #File Survey1.th #one file per survey survey surv1 centreline endcentreline endsurvey #endfile #File INDEXCave.th survey CaveA centreline input Survey1.th #no maps to get caught up this time <etc> equates... endcentreline endsurvey #endfile #File Maps.th #collect together all the maps input Survey1.th2 #drawing file <etc> map1 scrap1 #from drawing file scrap2 endmap <etc> joins map CaveAPlan map1 ##@CaveA no longer required(?) <etc> endmap #endfile The Maps.th file could become huge, so splitting it up in a similar manner to the surveys might be better. I find it easier to navigate and edit hundreds of small files than a few 1000+ line files. This system requires all maps to have a unique name, but I think Therion already requires all scrap names to be unique over any one dataset, so our naming conventions probably already handle this. Not sure what this means for the training guide. Ie relevant or not? Therion God input? I think regardless of the approach taken with survey and map hierarchies, that users need to organise (plan) the survey network structure to be 'just right' before drawing very much at all. Ie make sure the cave-list output correctly recognises where one cave starts and another finishes, and it seems we need to keep overland surveys separate at the moment (5.3.9) to avoid survey statistics errors. The reason is that regardless of how independent the hierarchies are, the stations in scraps are always referenced to a survey, and if you rename that survey or split it in two after you have done the drawings, you have a really confusing 'find and replace' exercise to do. Perhaps all the training guide should say is... "Before you start drawing, it pays to make sure you won't want to move survey stations from one survey to another, as in the drawing process many linkages are made, and they can be extremely tedious to modify once the map is complete. On the other hand, Therion will morph the drawings to accommodate even gross changes (usually) made at a later date to survey readings themselves, so you can afford to final check the actual readings after the drawing is complete." :] Bruce PS: Martin Slukas tip on adding colour to highlight scrap outline errors is a compulsory setting for me. _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
<Martin wrote
The original idea of Therion is that "survey" represents one survey trip. . So it is not the best idea to manipulate with surveys.
I agree Martin, one survey file, one trip. However we just did a survey of three small multi-entrance caves and overland surveys over a couple of days. In hindsight we were a bit messy in practice as we surveyed into one cave and out of another entrance and into another cave, then back out to the first cave etc etc. What I found was that Therion could not (or I could not get Therion to) adequately resolve the statistics for the caves individually until I split some of those surveys into two or three. It also would not separate surface survey statistics from cave statistics (but I think that is a bug). Statistics are resolved correctly for maps but not for survey-list. So as a last resort I cut the survey trips into multiple surveys/files. If I had drawn the scraps before doing this I would have had a difficult job patching it all back together. An unusual situation perhaps, but one where manipulation of the survey files was able to lay a better foundation on which to build scraps and maps. Bruce
You are right, Bruce. This is good example. But in fact there were 3 or better 4 surveying trips in this surveying trip. I such case it is natural to divide one day survey trip to particulate surveys. ;) m. On Jun 15, 2012, at 09:57 AM, Bruce <bruce@tomo.co.nz> wrote: <Martin wrote
The original idea of Therion is that "survey" represents one survey trip. … So it is not the best idea to manipulate with surveys. I agree Martin, one survey file, one trip. However we just did a survey of three small multi-entrance caves and overland surveys over a couple of days. In hindsight we were a bit messy in practice as we surveyed into one cave and out of another entrance and into another cave, then back out to the first cave etc etc. What I found was that Therion could not (or I could not get Therion to) adequately resolve the statistics for the caves individually until I split some of those surveys into two or three. It also would not separate surface survey statistics from cave statistics (but I think that is a bug). Statistics are resolved correctly for maps but not for survey-list. So as a last resort I cut the survey trips into multiple surveys/files. If I had drawn the scraps before doing this I would have had a difficult job patching it all back together. An unusual situation perhaps, but one where manipulation of the survey files was able to lay a better foundation on which to build scraps and maps. Bruce
Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
Better: "cave" or "surface" is superior to survey. m. On Jun 15, 2012, at 10:10 AM, Martin Sluka <martinsluka@mac.com> wrote: You are right, Bruce. This is good example. But in fact there were 3 or better 4 surveying trips in this surveying trip. I such case it is natural to divide one day survey trip to particulate surveys. ;) m. On Jun 15, 2012, at 09:57 AM, Bruce <bruce@tomo.co.nz> wrote: <Martin wrote
The original idea of Therion is that "survey" represents one survey trip. … So it is not the best idea to manipulate with surveys. I agree Martin, one survey file, one trip. However we just did a survey of three small multi-entrance caves and overland surveys over a couple of days. In hindsight we were a bit messy in practice as we surveyed into one cave and out of another entrance and into another cave, then back out to the first cave etc etc. What I found was that Therion could not (or I could not get Therion to) adequately resolve the statistics for the caves individually until I split some of those surveys into two or three. It also would not separate surface survey statistics from cave statistics (but I think that is a bug). Statistics are resolved correctly for maps but not for survey-list. So as a last resort I cut the survey trips into multiple surveys/files. If I had drawn the scraps before doing this I would have had a difficult job patching it all back together. An unusual situation perhaps, but one where manipulation of the survey files was able to lay a better foundation on which to build scraps and maps. Bruce
Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
http://www.fluke.com/Fluke/usen/Laser-Distance-Meters/Fluke-424D.htm?PID=742... Only add a USB module. m.
Hi, Have anyone made a metapost symbol of a cave diving line arrow? (I believe I've seen it somewhere, but can't find it any more) br, Robert
participants (7)
-
Andrew Atkinson -
Bruce -
Footleg -
Marco Corvi -
Martin Sluka -
Robert Staven -
Sluka Martin