- Therion - speleo.sk

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

Loop problem in extended elevation
by Christophe Salti 13 Aug '21

13 Aug '21

Hi all, Hope that someone will be able to help me during this summer vacation, knowing that it's the perfect timing for exploring and surveying caves (but also to do the synthesis of past surveys)... So, I'm working on an extended elevation map of a small but complex cave in the South of France (+/- 1500m length & +20/-40m high). Survey was done with a DistoX2 and Auriga (13 surveys were done if I remember but I haven't attached all of these). Most of the cave is made of boulders (énorme éboulis), probably from tectonic origin; so there are plenty of loops (it's a nightmare) and at least 5 or 6 levels. I haven't been working yet on the plan map but I guess it's not going to be a piece of cake (from a loop point of view). Sketches were done by hand to help me during the synthesis. I created an XVI file and I use it as background image. I'm working on PC an my therion version is : So my problem is the following (screenshots below): station 3.2 is unique but there are at least 2 side passages going to different locations of the caves (see screenshots 1a & 1b). During the survey, Auriga was displaying a unique 3.2 station and different paths (one going to 5.1, then 5.2 and the other one going to 3.11 then 3.16 and so on; see screenshot 3 below). But when exported from Auriga into a Therion format and then openned in Therion, I get two 3.2 shifted stations (scale is 1m x 1m), one for each path, as seen in the screenshot 2a. Screen shot #1a (sketch: cross section & plan views) _Screenshot 1b (sketch: cross section view)_: The 2 stations were surveyed at different times (but from the same station/point as stated earlier). There are other stations with the same 'shift' problem (I'm only at the begining of the synthesis process). For instance, station 5.2 -which comes just after 3.2- is also shifted as seen on the screen shot #2b. Is there something wrong I did ? Something I should do instead? I've tried to "equate" stations 3.2 and 5.2 (I renamed them before inserting the equate in the survey: first 3.2 in survey #1 is kept as 3.2 but second 3.2 in survey #2 was renamed 3.2bis; same for 5.2). Station was shifted/merged of course but I was not able to shift my second 3.2 branch to the 1st one.. I have checked the very usefull "Therion by example", by Marco Corvi, in the /4.4.2 Loops in extended elevation/ paragraph but I was not able to make it... Am I clear enough in my explanations? _Screenshot 2a below:_ _Screenshot 2b below:_ Why does Auriga is correctly displaying this sort of survey (see screenshot #3 below) and not Therion, by default I mean ? I'm not criticising, of course, it's just a remark from a beginner. -from station 3.2, there are 3 different paths going to 3.11, 5.1 and 3.3 -from station 5.2, there are at least 2 different paths going to 5.47 & 5.3 (there are probably other ways I haven't check) _Screenshot #3 below:_ _Screenshot #4 below_: full extended elevation screen as seen in Auriga Would someone be kind enough to explain me how to deal with it, please? then i should be able to solve most of the others shift problems I'll face during this synthesis... Cheers Christophe Salti Groupe Speleo de Vence ps: I've attached the therion files in case someone could help me...

3 3

Plan gridline colour changes unpredictably
by Bruce Mutton 12 Aug '21

12 Aug '21

Curious I have in my layout some metapost code to redefine the plan gridlines, used without apparent problem for perhaps 10 years. It includes a colour specification. withcolor 0.1black+0.5white; Mostly they come out like this, very light grey. This example is exported using colour-model cmyk, but most of the time using colour-model rgb it looks exactly the same, in my current project (only variables are colour map-fg, some map previews on or off and the colour model). For some reason, in my current project, if I use colour-model rgb for a particular output variant, I get a much darker gridline, as below. Other variants with rgb, the colour of the gridline matches the first example. Any hints as to why the difference? I might have expected this to occur with the new cmyk colour model, but it does not. So far it has only happened with in a single specific case when using the rgb colour model. I'll watch for more cases. Bruce

3 4

Install on Mac OS 11.4
by Andrea Corna 12 Aug '21

12 Aug '21

Hi Guys, I’m trying ti install on Mac OS 11.4 but I’m failing. Following this https://therion.speleo.sk/wiki/os-tips:osx <https://therion.speleo.sk/wiki/os-tips:osx> it fail Compiling fron GitHub also fail: ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [loch] Error 1 make: *** [loch/loch] Error 2 Anyone is able to install? Thanks for help Andrea

3 5