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.