
<html><body><div>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. </div><div><br></div><div>Map represents independent structure of particular maps created final map. With possibility to select smaller part of it.</div><div><br></div><div>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. </div><div><br></div><div>m.s.</div><div><br></div><div><br>On Jun 14, 2012, at 11:42 PM, Bruce <bruce@tomo.co.nz> wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><br> On 14/06/12 09:07, Bruce wrote:<br> > I have always tried to keep my map definitions OUTSIDE of surveys, as I've<br> > been following the dictum to keep surveys and maps as independent as<br> > possible. Having said that, Therion seems to think my maps are inside the<br> > survey one level up in the hierarchy, for example I need to specify items<br> > like;<br> > select bpwMP@BullPotFarm<br> <br> I wrote that before I thought hard enough about why therion thinks my maps<br> are inside the survey of the hierarchy level above.<br> Sorry, this is a ramble, perhaps it is relevant to the training guide,<br> perhaps not.<br> <br> This is what I do<br> <br> #File Survey1.th #one file per survey<br> survey surv1<br> centreline<br> endcentreline<br> endsurvey<br> <br> input Survey1.th2 #drawing file<br> map1<br> scrap1 #from drawing file<br> scrap2<br> endmap<br> #endfile<br> <br> At this level these maps are not associated with any survey hierarchy<br> (except of course the survey stations in the scraps are referenced to the<br> survey).<br> <br> At the next level I have<br> <br> #File INDEXCave.th<br> survey CaveA<br> centreline<br> input Survey1.th #here is where map1 becomes part of survey CaveA<br> <etc><br> equates...<br> endcentreline <br> endsurvey<br> <br> joins...<br> map CaveAPlan<br> map1@CaveA<br> <etc><br> endmap<br> #endfile<br> <br> So that is explained, I have a hybrid system where maps are incorporated<br> into the survey hierarchy 'one level up'.<br> <br> I don't know if this is good or not.<br> <br> A system where survey and map hierarchies might be completely independent<br> might be (untested but I think some of you were suggesting something like<br> this years ago)...<br> <br> #File Survey1.th #one file per survey<br> survey surv1<br> centreline<br> endcentreline<br> endsurvey<br> #endfile<br> <br> #File INDEXCave.th<br> survey CaveA<br> centreline<br> input Survey1.th #no maps to get caught up this time<br> <etc><br> equates...<br> endcentreline <br> endsurvey<br> #endfile<br> <br> #File Maps.th #collect together all the maps<br> input Survey1.th2 #drawing file<br> <etc><br> map1<br> scrap1 #from drawing file<br> scrap2<br> endmap<br> <etc><br> <br> joins<br> map CaveAPlan<br> map1 ##@CaveA no longer required(?)<br> <etc><br> endmap<br> #endfile<br> <br> The Maps.th file could become huge, so splitting it up in a similar manner<br> to the surveys might be better. I find it easier to navigate and edit<br> hundreds of small files than a few 1000+ line files.<br> This system requires all maps to have a unique name, but I think Therion<br> already requires all scrap names to be unique over any one dataset, so our<br> naming conventions probably already handle this.<br> <br> Not sure what this means for the training guide.<br> Ie relevant or not? Therion God input?<br> <br> I think regardless of the approach taken with survey and map hierarchies,<br> that users need to organise (plan) the survey network structure to be 'just<br> right' before drawing very much at all. Ie make sure the cave-list output<br> correctly recognises where one cave starts and another finishes, and it<br> seems we need to keep overland surveys separate at the moment (5.3.9) to<br> avoid survey statistics errors. The reason is that regardless of how<br> independent the hierarchies are, the stations in scraps are always<br> referenced to a survey, and if you rename that survey or split it in two<br> after you have done the drawings, you have a really confusing 'find and<br> replace' exercise to do.<br> <br> Perhaps all the training guide should say is... "Before you start drawing,<br> it pays to make sure you won't want to move survey stations from one survey<br> to another, as in the drawing process many linkages are made, and they can<br> be extremely tedious to modify once the map is complete. On the other hand,<br> Therion will morph the drawings to accommodate even gross changes (usually)<br> made at a later date to survey readings themselves, so you can afford to<br> final check the actual readings after the drawing is complete."<br> <br> :]<br> Bruce<br> PS: Martin Slukas tip on adding colour to highlight scrap outline errors is<br> a compulsory setting for me. <br> <br> _______________________________________________<br> Therion mailing list<br> <a href="mailto:Therion@speleo.sk" data-mce-href="mailto:Therion@speleo.sk">Therion@speleo.sk</a><br> <a href="http://mailman.speleo.sk/mailman/listinfo/therion" data-mce-href="http://mailman.speleo.sk/mailman/listinfo/therion">http://mailman.speleo.sk/mailman/listinfo/therion</a><br></div></div></blockquote></div></body></html>