May 2018 - Therion

Therion drawing file, scrap advice
by Bruce Mutton 24 May '18

24 May '18

My thought’s on Martin’s advice… >Try to create small scraps (max 100 m?). And try to create new .th2 file for each one scrap. This will reduce opening time much! Small scraps are good, and fast to load and render, but one scrap per file would seem to be excessive unless you are dealing with extra large scraps. By limiting to one scrap per file, you are removing the significant advantage of automatic scrap joins that Therion enforces when points and line points from adjacent scraps are snapped to the same location. And in addition you will have many more ‘input drawing.th2’ statements and ‘join scrap1 scrap2’ statements. I am looking at a small cave I surveyed two weeks ago, just under 130m in length. Parts of it are a little bit complex, and I am drawing at 1:250 instead of my usual 1:500 or 1:1000, so scraps have been broken into smaller pieces than would be typical and so I have more of them. It is much more detailed than my typical effort. * I made 3 PocketTopo files, because the plan and elevation complexities made it expedient to start new files (in other cases 500-1000m per PocketTopo would be a typical upper limit). * That led to 3 survey.th files, 3 plan.th2 files and 3 elev.th2 files. * Between the plan and elevation projections, the drawing files have 32 scraps (5-6 scraps per file, 4 of them are cross sections), and total 2800 lines (292-790 lines per file). * By maximising scraps per file, I estimate I have saved myself 24 input statements, and 20 - 25 join statements, and in addition, I am mostly drawing with the context of adjacent scraps in full view. If this was part of a large cave drawn at 1:1000, there might have been less than one third the number of scraps (still a lot, but required to avoid single scraps passing over or under themselves). The general point is, in a large cave system, one scrap per file would seem to create a lot of unnecessary work and input/join statements. And I doubt the number of scraps per file is what actually causes the reduction in performance. I would expect it is more related to the number of entities or number of lines within the th2 file, and the size of any xvi or image files loaded. From memory the rendering starts to become noticeably slower at 1000-1500 lines per th2 file, and intolerable at 3000 lines per th2 file (assuming a minimal xvi image). This will vary from computer to computer, and your tolerance to waiting. My rules of thumb are; * Minimise the size of survey trip files (limits size of and delay due to xvi and sketch files) I find 200 - 600m is good - same as Martins advice, we just have different thresholds. * Make as many scraps as you want or need in each th2 file, and avoid more than one th2 file per survey trip file if you can help it – differs from Martins advice – almost opposite! * Once your th2 file reaches about 1500 lines, start considering another th2 file. Having said that, I don’t think there are any absolute limits, it’s just a matter of preference. Bruce

2 1

Re: [Therion] Help with huge survey file. Therion Digest, Vol 149, Issue 21
by Dave Clucas 23 May '18

23 May '18

Nick, email or dropbox the data to me and I'll have a look. Dave Clucas dave.clucas(a)icloud.com <mailto:daveclucas@icloud.com> Exploring the World - One cave at a time > On 23 May 2018, at 11:14, therion-request(a)speleo.sk wrote: > > Send Therion mailing list submissions to > therion(a)speleo.sk > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.speleo.sk/listinfo/therion > or, via email, send a message with subject or body 'help' to > therion-request(a)speleo.sk > > You can reach the person managing the list at > therion-owner(a)speleo.sk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Therion digest..." > > > Today's Topics: > > 1. Help With Huge Survey File (Nick Bairstow) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 23 May 2018 10:12:08 +0000 > From: Nick Bairstow <Nick(a)pff.uk.com> > To: List for Therion users <therion(a)speleo.sk> > Subject: [Therion] Help With Huge Survey File > Message-ID: <6fb82daaed4646028b533423dcabbe2b(a)PFF-EXCH1.pff.local> > Content-Type: text/plain; charset="utf-8" > > Somebody has sent me a project folder which contains one huge survey (6k+) made with Pocket Topo. It seems they had only partial knowledge on how to survey a cave of this size and only limited experience of Therion so the whole thing is a bit weird. I said I would attempt to sort it out. Andrew fixed one issue with the data which has moved us forward but my question now is how to proceed. > If I compile I can get .3d and .lox output which seems to work fine but the pdf output fails with a load of complaints. Looks like a size thing to me but having never seen this before I'm not sure. > To me the survey needs breaking up but again I am not sure of the best way to do this, can some of you clever chaps have a look and possibly offer advise please. > Be warned the th2 is difficult to handle my machine takes 3-4 mins just to load it and 2mins to refresh if I adjust the zoom. > The guys who collected the data spent an awful long time doing so and are obviously keen to use this data as redoing the survey is not an option. > It is quite an interesting problem and a very good example of how not to do things. > Any comments or involvement would be appreciated. > > Nick > >

1 0

Wrong average calculation from compass/backcompass data
by Evaristo Quiroga 18 May '18

18 May '18

Hi, I have data from a survey with fore/back sight compass and clino. I have detected a Therion bug calculating the average data, comparing with the error loops with Auriga, Visualtopo, Compass and Therion. See the next compare. Example from the data in .th file: > data normal from to length compass backcompass clino backclino left > right up down > 279.0 - 0.00 0.00 0.00 0.00 0.00 > 0.00 0.00 0.00 0.00 > 279.0 279.0A 2.33 236.8 56.8 -11.4 11.4 > 0.00 0.00 0.00 0.00 # .superficie > 279.0A 279.1 4.51 163.2 343.2 -32.2 32.2 > 0.00 0.00 0.00 0.00 # .superficie hasta anclaje desviador > 279.1 279.2 12.41 1.5 181.5 -77.7 77.7 > 0.00 0.00 0.00 0.00 > 279.2 279.3 1.95 212.2 33.1 -17.7 16.6 > 0.00 0.00 0.00 0.00 Data transferred to Survex by the "data.svx" file > *data normal from to tape compass clino > 1 2 0.000000 268.348831 0.000000 > 1 3 2.330000 235.148831 -11.400000 > 3 4 4.510000 161.548831 -32.200000 > 4 5 12.410000 359.848831 -77.700000 > 5 6 1.950000 210.998831 -17.150000 You can see Therion do a wrong fore/back sight compass average calculation. The good data average are: 1 3 236.8 -11.4 3 4 163.2 -32 4 5 1.5 -77.7 5 6 212.65 -17.15 The clino average seems OK. Searching in the mail-list I have found the bug was reported before. I think is not corrected since then. https://www.mail-archive.com/therion@speleo.sk/msg04660.html Regards, Evaristo.

4 8

Suggestions on how to write several new symbol type in metapost
by Rodrigo Severo 14 May '18

14 May '18

Hi, I want to write several new symbols for Therion. Is there any kind of editor where I could do it? Maybe something more interactive than writing Metapost code and recompiling a test map? How do you create/edit symbols for Therion? Regards, Rodrigo Severo

3 4

walls off
by Vasily Vl. Suhachev 12 May '18

12 May '18

Hello How to turn off walls for the whole cave? === this not work === source centerline walls off endcenterline input cave endsource export map cave.pdf ====================== -- WBR, Vasily

3 4

Therion Map Header Overrides
by Bruce Mutton 10 May '18

10 May '18

Nick > The override below is to change the Therion default team, cave length, cave depth data on the map output. Used in this case because a short surface survey needed to be shown on the map but the data was skewing the actual cave length and depth. I'm not sure that is a very good way to deal with the issue. In the screenshot below I have a surface survey shown (green dots), designated surface by use of 'flags surface', 'flags not surface' interleaved with the survey data as appropriate. No need to fudge the cave length or depth because Therion does not include surface data in the cave length. There is some complexity around it, but you can show or hide the cave and surface centrelines using; symbol-show group surface-centreline symbol-hide group cave-centreline Bruce

3 5

Therion Map Header Overrides
by Nick Bairstow 09 May '18

09 May '18

To follow on from Bruce's section on Therion header overrides in his Map Definitions thread it seems a good idea to split overrides off into a separate topic.. Survey and map definitions also give you control over the title that appears on the drawing. It can be complicated, but I once figured it out, and made this bit of code to put in layouts used for plan outputs. I prefer to allow Therion to decide the output title based on the information I have entered in surveys, maps and selections, but sometimes an override is required. Note that Therion assumes a survey or map title is the same as its id, unless you specify -title "name" to override the id. My preference is to always give surveys or maps likely to be a primary selection for output a title that I would like to see on a finished pdf output (and use a concise id). The code, as below, only has effect if due to the users choices, Therion cannot deduce a unique name for the output. #PLAN Cave Map Details #-------------------- # Define Map title overrides code tex-map % Output map title as determined by Therion 5.3 is stored in cavename. % It will be empty if there are multiple maps selected for any one projection % AND there are multiple source surveys identified in the thconfig file % ie Therion can not infer a unique title from the input data given. % This code allows you to define an output map title {cavename} if it happens to be empty \edef\temp{\the\cavename} % cavename from Therion \edef\nostring{} % empty string \ifx\temp\nostring % test if cavename is empty % if empty reassign cavename to describe selected maps as a group \cavename={Project Area Caves} \else % if not empty keep the value set by therion, or assign an override cavename here \fi endcode I have been using this in my layouts to give me multiple lines on my map titles with the added ability to adjust the font size. Size[30 or whatever size you need] medskip can be changed to bigskip or smallskip to alter the spacing between the lines of text. ###############THERION OVERIDES############## ##Override Therion Map Header Data### #------------------------------------------------------ code tex-map \cavename={\size[20] Tom Taylors Cave\medskip \size[30] How Stean Gorge\medskip \size[30]North Yorkshire} endcode The override below is to change the Therion default team, cave length, cave depth data on the map output. Used in this case because a short surface survey needed to be shown on the map but the data was skewing the actual cave length and depth. ##Override cave length and depth to remove surface leg data## #------------------------------------------------------------------------------------ code tex-map \topoteam{BSD} \cavelength{164m} \cavedepth{12m} #endcode Both these overrides I borrowed from one of Andrews configs in the BCA data archive which I find a great resource. No point reinventing the wheel, even if I could. Nick

1 0

Map Definitions discussion
by Bruce Mutton 08 May '18

08 May '18

Here is a conversation that Nick and I had recently, about using map definitions. Bruce From: Nick Bairstow Sent: Saturday, 5 May 2018 12:03 AM To: Bruce Mutton Subject: RE: Map Definitions Bruce, thanks for that explanation, I now think I understand things a little better. You descriptions are once again very clear and understandable. I will grab some data next week and play around with the various scenarios. I do appreciate your spending time to give advice it is a great help. Cheers, Nick From: Bruce Mutton Sent: 03 May 2018 21:03 To: Nick Bairstow Subject: Map Definitions Hi Nick Yes, your folder structure seems normal and appropriate. Believe it or not (my understanding is that) Therion is designed to automatically produce the 'best' pdf output that it can, based on what has been input, with minimal effort on the users part. But if the user wants to have more control, then they can (I always want .). That control starts in a thconfig file with the choice to 'select' 'surveys' and or 'maps' for output. Then extends to defining 'maps' that can contain either surveys, scraps or other maps. Usually you don't include surveys, except that personally I prefer to while I am progressing through the drawing process**. Have a look at this page https://therion.speleo.sk/wiki/bds#concepts and scroll down a bit. "select selects particular surveys and or maps to export. If you do not select a survey, all surveys are selected by default. If you do not select a map, all scraps and maps are selected by default. Optional. " This explains why, with no maps defined or no maps selected, you get everything that you have drawn. You should also notice that if you have no scraps drawn, your default output will have all of the cave centrelines present. As soon as you have one scrap, centrelines vanish from the output, and you only get your scrap. If by chance you want to produce an output with only some of what you have drawn (at and below the current level of hierarchy), or you want to offset parts of the drawing, then you MUST define maps, and select them for output appropriately. Also, if you want to see a combination of scrap drawing AND CENTRELINE outside of the drawn scraps extent, or with splays visible, then you must include the relevant surveys in map definitions. See my ** comment above. Survey and map definitions also give you control over the title that appears on the drawing. It can be complicated, but I once figured it out, and made this bit of code to put in layouts used for plan outputs. I prefer to allow Therion to decide the output title based on the information I have entered in surveys, maps and selections, but sometimes an override is required. Note that Therion assumes a survey or map title is the same as its id, unless you specify -title "name" to override the id. My preference is to always give surveys or maps likely to be a primary selection for output a title that I would like to see on a finished pdf output (and use a concise id). The code, as below, only has effect if due to the users choices, Therion cannot deduce a unique name for the output. #PLAN Cave Map Details #-------------------- # Define Map title overrides code tex-map % Output map title as determined by Therion 5.3 is stored in cavename. % It will be empty if there are multiple maps selected for any one projection % AND there are multiple source surveys identified in the thconfig file % ie Therion can not infer a unique title from the input data given. % This code allows you to define an output map title {cavename} if it happens to be empty \edef\temp{\the\cavename} % cavename from Therion \edef\nostring{} % empty string \ifx\temp\nostring % test if cavename is empty % if empty reassign cavename to describe selected maps as a group \cavename={Project Area Caves} \else % if not empty keep the value set by therion, or assign an override cavename here \fi endcode This page on what input data Therion draws on to produce outputs may well be cryptic, but the bottom rows in the table may help. It is based on my deductions and experiments only. https://therion.speleo.sk/wiki/exportselectionformat Hope this helps. Good luck Bruce From: Nick Bairstow Sent: Friday, 4 May 2018 3:19 AM To: Bruce Mutton Subject: Map Definitions Hi Bruce, as I am supposed to be tutoring folk in Therion I thought it wise to clear up some of "my" questions. I see in the mailing list you have spoken about this over the years so maybe you can help. I have a cave that has been surveyed with a total of 6 separate surveys. i.e. I have 6 topo files. I process each topo file though TopParser and the outputs file fly off into their relevant folders in the hierarchy. MainCaveName Survey1 Survey1.th Survey1.th2 Thconfig Pocket Topo folder Survey2 Survey3 etc. Also in MainCaveName folder I tend to put:- Output Survey1Output Survey2Output etc. Index.th thconfig Nothing unusual and I think a quite normal structure which works well for me. My question is in the index.th I have always used a map definition but I notice if I do not use one I still get the same output. As long as I have in the index.th, as in this case:- input Survey1/Survey1.th input Survey2/Survey2.th etc. I get the same result. After reading all I can find I am still confused. I suppose I am making quite straight forward maps so maybe it does not matter which way I do it. What situation would require me to use a map definition in the index or should I use one all the time? I have various idea's as to how/why I do this but I am just not clear. Also looking in our UK BCA data archive which I find really useful for help I see both methods are used so I think I'm not the only one confused. I think this subject warrants a really simple wiki article, once I fully understand it I may have a go at one. Cheers, Nick

1 0

Fwd: Extended elevation discussion
by Marco Corvi 08 May '18

08 May '18

here is a short mail exchange with bruce about "extend" i played a little with the extend command. there are many variations (1 and 2 are stations) - placing it before the data or after them - "extend ??? 1 2" or "extend ??? 2 1" - with an "extend ???" in the data or not - combining with "extend ??? 1" not considering the variations on the theme when there are crossways and loops and the interaction with "flip horizontal" maybe someone with plenty of time (and patience) will go thru the analysis of how therion handles these commands . . . personally i use "absolute" extends the data. and it's been years now since i used "flip" (in therion). we moved from lrud to splay. what about going from L/R to fractional extend (including nil to break loops) ? marco ---------- Forwarded message --------- From: Bruce Mutton <bruce(a)tomo.co.nz> Date: Wed, May 2, 2018, 21:48 Subject: Extended elevation discussion To: Marco Corvi <marco.corvi(a)gmail.com> Hi Marco Glad you are spending time caving. And is good to be disconnected sometimes! Yes, extend is mysterious. Your commentary is insightful and appreciated. 1. *Separating extend data from survey data:* choice will depend on what is important to the map author. *Advantages* = like information is kept together, dissimilar information is kept separate; able to have many different extend elevation shapes for one survey. *Disadvantages* = you have duplication of survey leg enumeration for each extended elevation. Sometimes every leg needs to be duplicated, but sometimes only at changes of extend ‘state’, so duplication can either be minimal or extensive, depending on the project. Enumerating extend stations and legs in the opposite direction (2 1) to what they are enumerated in the survey data (1 2) is usually OK. It often requires more explicit enumeration than if both progress in the same direction. I have done it a number of times. Sometimes ignores will only work in one direction, as I noted in the web page. 1. Yes, I think *extend left/right may behave like revise*, I have thought that. Pretty sure I have had cases where I have conflicting directions on the same leg, and the last one read will take precedence. I tend to weed these out, as extend is unpredictable enough without leaving such things in the data! 1. *Flip and left right normal reverse*: Good point, I had not thought of that. However, I am always explicitly left and right myself. While I have had some issues with flip, I don’t expect they are related to explicit extend directions. What I do suspect is that some symbol alignments to not respond well to flip, and I suspect that implied joins of scraps (where line end points are snapped together within the same file) might tend to wreck flipped scraps. That would be obviously user error if one scrap is flipped but not the other. The attached example from a few years ago shows what can happen if scraps are flipped. I should go back and see if both scraps where flipped or only one! This conversation might be useful to have on the forum. Feel free to forward it to the forum if you like. Bruce *From:* Marco Corvi <marco.corvi(a)gmail.com> *Sent:* Wednesday, 2 May 2018 11:05 PM *To:* Bruce Mutton <bruce(a)tomo.co.nz> *Subject:* Re: Extended elevation page hi bruce, sorry for the late answer; i was off caving in an area with no connection. i looked at the extend page. that''s fine with me. recently i have been just following therion news, without spending much time to check out things with examples, except in a few cases. about extend: 1) i think it's not a good idea to separate leg data from leg extend, because you have to write the leg "name" (the stations) twice. what happen if you have "1 2" with data and "2 1" with extend ? i do not know, i have to check when i get home. 2) i think that the syntax "extend right 1 2", might be a sort of revise, ie, it overrides the previous value. again i have to check this too 3) normal/reverse may be better than left/right, when you use flip that said i tend to use absolute extend (left/right), but maybe it's time that i go relative. extend is a diffucult topic, and your page is a good idea. there are many different situations for "extend"; you may add the examples in subpages. marco On Mon, Apr 30, 2018, 12:25 Bruce Mutton <bruce(a)tomo.co.nz> wrote: Hi Marco I sent this message to the Therion forum a few hours ago, and have not received a mail back yet, so I am wondering if it is broken in some way, I notice the website has been responding very slowly all day. However I could edit the wiki just fine. Anyway, reason for this email is to let you know about the new Extended Elevations <https://therion.speleo.sk/wiki/extend> page, and checking that you are happy with what I have written, and references to your altervista pages. And perhaps you have further insights into extended elevations! Hope you are well. Regards Bruce Mutton *From:* Bruce Mutton <bruce(a)tomo.co.nz> *Sent:* Monday, 30 April 2018 6:01 PM *To:* 'List for Therion users' <therion(a)speleo.sk> *Subject:* Extended elevation page Good morning all I have just put together a Therion Extended Elevations <https://therion.speleo.sk/wiki/extend> page, having convinced myself that I have almost figured out how to make them work. You can navigate there from the wiki start page <https://therion.speleo.sk/wiki/start>, via the ‘Data Organisation’ link. Thanks and apologies to Marco Corvi, for the inspiration and words I have borrowed from his page. Marco, is it OK? It is not quite complete yet (I have a history of not completing projects) however if someone can direct me to the centreline and drawing data for the famous Therion Extended Elevation Control <https://therion.speleo.sk/samples.doc/25.html> sample, then I might remain inspired enough to generate a more comprehensive set of examples. Enjoy your caves Bruce

1 0

Rename legend symbol "water-flow"
by Bruce Mutton 08 May '18

08 May '18

Yes, for example here is what I have sometimes redefined (in English) text en "point water-flow:paleo" "paleo water flow (scallops)" Bruce <https://www.mail-archive.com/search?l=therion@speleo.sk&q=from:%22Evaristo+ Quiroga+via+Therion%22> Evaristo Quiroga via Therion <https://www.mail-archive.com/search?l=therion@speleo.sk&q=date:20180508> Tue, 08 May 2018 01:06:54 -0700 Hi, It's possible you have to specify what water-flow type you want, lyke this: text es "point water-flow:permanent" "curso de agua permanente" text es "point water-flow:intermittent" "curso de agua temporal" Regards, Evaristo El 08/05/2018 a las 8:56, Torsten Schnitter via Therion escribió: Hi I'm trying to rename a text in the legend. All parts are working except one: point water-flow Within thconfig I use this: text es "point water-flow" "flujo de agua" But the text in the legend is not changing from it's original "curso agua" Any help is appreciated. Thanks. Torsten

1 0