[Therion] Training Course Guide for Therion from the UK CaveSurveying Group

[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 at 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 at 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.