August 2021 - Therion

Re: [Therion] Point altitude/deph, Help !
by Xavier Robert 28 Jun '22

28 Jun '22

Hi all, I think I have found a trick. The other Xavier led me to the right tracks, thanks a lot ! Finally, this is quite simple with the point altitude, and no need to change anything inside the : - If we use the point altitude only with the option -align, we get the altitude - If we use the point altitude with the options -align and -value [-1004 m] where 1004 is the altitude of the main entrance, we print the depth only for that point (Do not forget the " - " before the altitude of the main entrance), and thus, we do not erase the classic point altitude. The only (small) limits are : * If the main entrance changes, we need to manually update ALL the points that print the depth. But that should not be be everyday, and not a big issue to do that. * the symbology of the two points is the same. I will have a look for a way to modify that and let you know if I find a trick (If I copy the code of the point Altitude, and call it p_u_depth(expr pos, R, S, A), it crashes...). Cheers, Xav

4 4

How to calculate the volume of a cave
by Bill Gee 31 Jan '22

31 Jan '22

Hello everyone - What tools can be used to calculate the volume of a cave based on center line and LRUD data? I found an email from Martin Sluka from about 4 years ago describing how to use Loch to export a .lox file in other formats, then run that file through CloudCompare or ParaView. The process looks very complex to me, and besides - Loch does not run on my computers, so there is no way for me to generate an export. As far as I can tell, Survex does not have a way to calculate volume. Could it be done with a KML file and Google Earth? -- Bill Gee

8 11

Minimum symbol scale
by Tarquin Wilton-Jones 28 Oct '21

28 Oct '21

Hi folks, There is a setting: min-symbol-scale M That allows you to hide all symbols of S or XS scale. That's useful when you want to show only the most important symbols in a low resolution survey. But is there a way to control this differently only for certain symbols? Eg. I want to be able to hide all "point label" symbols of scale M-XS but I don't want all my cave walls or breakdown choke symbols to disappear (which are at the default M scale). Essentially I want something like this: min-symbol-scale point label L min-symbol-scale point anchor:foo M Some of this I can of course do with MetaPost. But labels (the thing I care most about) don't allow you to easily redefine the MetaPost macro ... or at least the syntax is so weird that I don't understand it. Thanks for any advice. Tarquin

2 4

Therion 6.0.1 colour processing problem
by A.M. van Rosmalen 26 Aug '21

26 Aug '21

Hi there, Since I upgraded to the last version of Therion (6.01) on Windows my maps refuse to compile even though they used to compile just fine before and still compile under the previous version (on a Linux machine) Specifically this piece of code in LayoutStandards.thc drafted by Bruce Mutton found here: https://therion.speleo.sk/wiki/_media/templates:layoutstandards.txt code metapost %these colours affect fills, not the linework !color colour_water_bg; %! forces interpretation as metapost colour_water_bg := (0.82,.93,.95); %light blue !color colour_sump_bg; %! forces interpretation as metapost def_transparent_rgb (tr_color_sump_bg, .44, .81, .92) %transparent version colour_sump_bg := (.44,.81,.92); %dark blue %these colours affect the linework !color colour_rope; %! forces interpretation as metapost colour_rope := (0.35,0.75,1.0); %blue endcode Gives the following error message: >> def_transparent_rgb ! Isolated expression. <to be read again> ( l.6979 def_transparent_rgb ( tr_color_sump_bg, .44, .81, .92) %transparent ve... I couldn't find an `=' or `:=' after the expression that is shown above this error message, so I guess I'll just ignore it and carry on. ! Extra tokens will be flushed. <to be read again> ( l.6979 def_transparent_rgb ( tr_color_sump_bg, .44, .81, .92) %transparent ve... I've just read as much of that statement as I could fathom, so a semicolon should have been next. It's very puzzling... but I'll try to get myself back together, by ignoring everything up to the next `;'. Please insert a semicolon now in front of anything that you don't want me to delete. (See Chapter 27 of The METAFONTbook for an example.) I tried adding some := and =, but this just leads to the following error message: >> def_transparent_rgb >> (tr_color_sump_bg,0.44,0.81,0.92) ! Equation cannot be performed (numeric=cmykcolor). <to be read again> colour_sump_bg l.6980 colour_sump_bg := (.44,.81,.92); %dark blue I'm sorry, but I don't know how to make such things equal. (See the two expressions just above the error message.) ! Extra tokens will be flushed. <to be read again> colour_sump_bg l.6980 colour_sump_bg := (.44,.81,.92); %dark blue I've just read as much of that statement as I could fathom, so a semicolon should have been next. It's very puzzling... but I'll try to get myself back together, by ignoring everything up to the next `;'. Please insert a semicolon now in front of anything that you don't want me to delete. (See Chapter 27 of The METAFONTbook for an example.) Any ideas how to fix this? Cheers, Anton

3 5

Elevation scrap distortion with survex 3.d import
by wookey＠wookware.org 25 Aug '21

25 Aug '21

I am getting strange (and very annoying) results with a new survey. This is my first real fully-digital project (using sexytopo/android) which may be a factor. So we have a ~1km cave system with two vertical entrances: Pollnatagha 'Natagha' and Pollpruglish 'Pruglish'. Attached is a tarball of the current files: (look at ee.pdf and natagha/blackarrow-ee.pdf to see what's broken. You'll need to edit natagha/paris/paris.th and natagha/blackarrow/blackarrow.th to process those two surveys on their own (see below) And underlying survex dataset, (which is all lovely and working nicely) is here: (I can't upload them somewhere sensible instead as 'the internet' here is HTTP(s) only so no scp, ssh, imap, etc) The fundamental issue is the plans are coming out fine, but the (extended) elevations are severely distorted. After some hours staring at it last night I worked out that the 'paris' survey was considered by therion to be upside down so adding a '-flip vertical' to the scrap definition made things look way better, and then making sure one leg was reversed took out the rest of the distortion. However this does not seem to work for blackarrow, which is all twisted over itself, and not really any better if I flip vertically. And the question remains - why does therion think my elevation sketches are upside down? Is this actually a bug in the 'therion' export from sexytopo? Or am I being dim about something? They look the right way up in the therion editor. I've spent quite a lot of time checking that the stations are numbered as expected. I think there is something more significant about the extending process, or possibly the import -surveys use process. (The log file note a lot of 'unused fixed points' which are therion's made-up station numbers for the survex data in the thTMPdir). Not sure if this is relevant or not. Also, I've noticed that whilst I have the right 'import -surveys use' runes for both the top level (whole cavesystem) and single-survey (paris). If I leave them both in then a big distortion re-appears (stations 7,8,9 are moved ~30m along). What is going on there? Importing the same set of stations twice should actually matter should it? (it would be nice to be able to leave the 'single survey' import in place because then you can check that alone without having to edit the 'singlesurvey.th' each time to add/remove the import). The plan still works fine with the double-import. I am currently in Northern Ireland with very limited internet (I've come to the local show-cave visitor centre to send this), but will be back in civilisation in Friday evg. If anyone replies to this today I'll be back here about 5pm to check. I can't really draw up any more elevation at the moment because I can't check it's not gone crazy (because it's already crazy :-) So the structure is: top-level NataghaPruglish.th (and thconfig) with natagha and pruglish surveys. I am using the 'import -surveys use' with corresponding empty therion survey structure so that the individual scrap station names as just '1' '2' etc. There are about 12 surveys in total but you can ignore everything except 'paris' and 'blackarrow', two largely horizontal linear surveys under 'natagha'. So this is now working: import NataghaPruglish.3d -surveys use survey natagha survey paris #import ../../NataghaPruglish.3d -surveys use -filter natagha.paris input "paris-ee.th2" endsurvey endsurvey But if you comment that 2nd filtered import back in (in natagha/paris.th) then paris.7,8,9 move 30 to the right. import NataghaPruglish.3d -surveys use survey natagha survey paris import ../../NataghaPruglish.3d -surveys use -filter natagha.paris input "paris-ee.th2" endsurvey endsurvey If you have both paris and blackarrow input in natagha/natagha.th then you get a different pair of large distortions (in ee.pdf) (plan.pdf is fine). import NataghaPruglish.3d -surveys use survey natagha survey paris #import ../../NataghaPruglish.3d -surveys use -filter natagha.paris input "paris-ee.th2" #import ../../NataghaPruglish.3d -surveys use -filter natagha.blackarrow input "blackarrow-ee.th2" endsurvey endsurvey One last question. If I wanted to try a projected elevation (to remove the extra complexity of the extending process) how do I specify the projection angle? An angle seems to be a parameter in a scrap '-proj elevation' definition, but what determines what angle the _centreline_ is viewed from? I cannot specify an angle in the top level 'export map' command: export map -proj elevation -layout local -o "elv.pdf" OK, there is a lot there - I hope I have explained it adequately, and that someone can work out what on earth is going wrong here. -- Wookey

3 3

Linux xtherion will not load thconfig
by Wookey 25 Aug '21

25 Aug '21

There is a bug in xtherion 5.5.7, at least in the debian build I am using (therion 5.5.7ds1-2). If you try to open a thconfig file, you get an error: "thconfig.thcfg does not exist". Fortunately you can run 'xtherion thconfig' and that works, otherwise xtherion would be completely broken unless you renamed all your thconfig files. This seems a fairly fundamental bug - I'm surprised it's not come up before. This is now in the version in Debian stable, so people will be getting it for the next 2 years, which is somewhat embarassing. Hopefully we can declare it bad enough to get a fix in. I've not looked into the code yet for a fix, but can someone confirm this is not just me? -- Wookey

2 1

cannot load thconfig in xtherion
by Wookey 23 Aug '21

23 Aug '21

If you run xtherion then try to load a thconfig file you get this error: <path>/thconfig.thcfg does not exist It works if you run xtherion thconfig (or otherwise specifying the correct path to the thconfig file) So something in the codebase seems to have decided that thconfig files must now be called thconfig.thcfg or thconfig.thconfig. This seems quite broken. -- Wookey

6 5

Colour legend labels poorly aligned if more than single line
by Bruce Mutton 21 Aug '21

21 Aug '21

The alignment of labels is set towards the top of the colour swatch for the colour legend. This is probably perfect for the banded colour lookup shown below. However where there are multiline labels, the first line for each swatch is set too high. May I suggest that the insertion point/alignment for each text label be set at the top of each swatch, rather than above the centre of each swatch as currently appears to be the case? Bruce lookup altitude:FloodLower -title "Passage coloured by Inundation Hazard" #these colours work best with higher opacity (70-100) [430 500] [098 100 098] [Above 430 m inundation not observed] #greeny white [420 430] [086 100 100] [430 m - 10 yr return period<br> 90 cumec, Riuwaka at Littles] #water blue [400 420] [043 060 090] [420 m - 5 yr return period<br>70 cumec, Riuwaka at Littles] [300 400] [000 020 080] [400 m frequent flooding assumed] #dark blue endlookup

2 6

Take 2 - Offsets and map-connection lines
by Bruce Mutton 16 Aug '21

16 Aug '21

OK, some progress. I dredged up an old revision that I thought was working, and sure enough it still works. It seems that offsetting a map by referring to it this way '7-LaghuPlan-midP3@Laghu' gives the result I want. But inserting that map inside another map, with no other additions, referring to it now as 'LaghuPlanMap-2' breaks the offset map-connection hierarchy. I feel like this should offer me some insight, and a path to some solution. But it is not hitting me yet, unless it is somehow associated with map-levels? It seems to make it difficult to generate a pattern that allows unlimited levels of offsetting, preferring instead to terminate at two levels, as in the Therion Book example. Or is there a creative solution? Details below. Offset of offset - map-connection is submap to submap - looks good so far - rev 47.1.1 map LaghuPlanMap -title "Laghu Cave Plan, Mt Arthur" 9-LaghuPlan-surface@Laghu #entrance pit LaghuPlanMap-1 [-050 000] below #top level offset map Laghu endmap LaghuPlanMap map LaghuPlanMap-1 9-LaghuPlan-underground@Laghu 7-LaghuPlan-upperP1P2@Laghu 7-LaghuPlan-midP2P3@Laghu 7-LaghuPlan-midP3@Laghu [000 020] below #same as LaghuPlanMap-2, but with correct map-connections # LaghuPlanMap-2 [000 020] below #referring to it this way breaks the map-connections # if both above lines uncommented, then the map is unchanged, it still plots correctly endmap # map LaghuPlanMap-2 # 7-LaghuPlan-midP3@Laghu # endmap Offset of offset - selected map to submap - breaks map-connection map LaghuPlanMap -title "Laghu Cave Plan, Mt Arthur" 9-LaghuPlan-surface@Laghu #entrance pit LaghuPlanMap-1 [-050 000] below #top level offset map Laghu endmap LaghuPlanMap map LaghuPlanMap-1 9-LaghuPlan-underground@Laghu 7-LaghuPlan-upperP1P2@Laghu 7-LaghuPlan-midP2P3@Laghu # 7-LaghuPlan-midP3@Laghu [000 020] below #same as LaghuPlanMap-2, but with correct map-connections LaghuPlanMap-2 [000 020] below #referring to it this way breaks the map-connections endmap map LaghuPlanMap-2 7-LaghuPlan-midP3@Laghu endmap Thanks Bruce

1 0

Offsets, map-connection lines and previews
by Bruce Mutton 16 Aug '21

16 Aug '21

I have this idea that map-connection lines should originate within the map that they are defined in, and end within the submap that is offset. In other words, that they should follow the vector that describes the offset local to the map that they are defined in. Similarly, previews (explicitly defined as well as when the result of an offset). Exactly as shown in the Therion Book. What I am finding is that the map-connection lines originate in the map that is selected in the th-config, and end within the submap that is offset. When there is more than one level of offset this means that they follow the sum of all offset vectors. In addition, previews that are the result of an offset are not local to the map they are defined in, but appear in the selected map (explicitly defined previews seem to be OK though). Quite possibly I am doing something wrong, but it escapes me. The above is the gist of mu dilemma really. What follows is just more tedious detail. I am trying to create a plan map of a vertical cave, where each of the submaps have a map-connection line between them. I am planning to export them to a map (I'm not thinking of atlas at this stage). Juraj Halama showed us an example last year And explained how to get the submap to submap map-connection lines, as well as the overall (radial selected map to submap) map-connection lines in this post. https://www.mail-archive.com/therion@speleo.sk/msg08318.html It seems to have about the right level of complexity to achieve two sets of map-connections, but too much for a typical single set of map-connection lines. I am looking for only submap to submap map-connections, as shown in the Therion Book, and the example suggests that this is the norm. And so I am using syntax that I hope is like this. and And select m123 in my thconfig. But alas I am only getting radial offsets from the 'selected' map. My hope is that the pattern shown in the Therion Book can be nested without limit, but I have only ever been able to nest it two levels successfully as with the Therion Book (although just now I cannot even do that for some reason - but it did work a year ago when I last tried) Once a third level is introduced the offsets go radial from the selected map, and not submap to submap. The diagram below shows my map names with three levels of offsets (offset of offset of offset). It also compares the map-connection lines that I get, compared with what I expect. In all cases the thconfig only selects LaghuPlanMap. When I am done, I think this particular project will require 8 to 10 levels of offset, so I am hoping there will be an easy pattern to follow. An example: Offset of offset - These definitions produce the maps below. map LaghuPlanMap -title "Laghu Cave Plan, Mt Arthur" like m123 in Therion Book example #select this map when exporting a pdf plan with offset maps 9-LaghuPlan-surface@Laghu #entrance pit like m1 in Therion Book example Laghu #survey centreline LaghuPlanMap-1over2 [-050 000 m] below #top level offset map like m23 in Therion Book example endmap LaghuPlanMap map LaghuPlanMap-1over2 #next level down, midP3 like m23 in Therion Book example LaghuPlanMap-1 like m2 LaghuPlanMap-2 [000 020 m] below # next offset level like m3 endmap map LaghuPlanMap-1 #top level offset map like m2 preview above 9-LaghuPlan-surface@Laghu 9-LaghuPlan-underground@Laghu # point map-connection in here plots correctly in offset level one 7-LaghuPlan-upperP1P2@Laghu 7-LaghuPlan-midP2P3@Laghu preview below LaghuPlanMap-2 like m3 endmap map LaghuPlanMap-2 #next level down, midP3 like m3 7-LaghuPlan-midP3@Laghu # point map-connection plots incorrectly in offset level two endmap I can see that select xxx -map-level 1, 2 and 3 etc have an incremental and negative effect on the display of passage previews, but I don't understand the guidance in the Therion Book on this. "preview <above/below> <other map id> will put the outline of the other map in the specified preview position relative to the current map. Preview is displayed only if the map is in the map-level level as specified by the select command. Use the revise command if you want to add maps from higher levels to the preview." So I am not using -map-level in these examples, and it seems to interfere with the offsets anyway. I'm not sure if revise would help, or how to use it, but expect it might have some use with previews that appear in the wrong position. Any insights appreciated. Bruce

1 0