August 2021 - Therion

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

Graphic tablet with XTherion
by Bruce Mutton 09 Aug '21

09 Aug '21

After many many years XTherioning with a mouse, I think I might try a graphic tablet for drawing with XTherion, and maybe soon, Inkscape. Do I need anything fancy, or will the simplest do? One of these? https://www.huion.com/pen_tablet/Inspiroy/H430P.html Bruce

4 3

Therion map colour specification hierarchy
by Bruce Mutton 05 Aug '21

05 Aug '21

Hi Maybe with this morning's message I was tackling the task of specifically colouring certain maps from the wrong perspective. >From Therion Book. colo[u]r <color> . set the map colour; this option overrides the automatic choice when the layout specifies colour map-fg [map]. So I expect colour map-fg to set the typical colour scheme for a map in a layout, and if I want exceptional override colours I specify these with selects in my thconfig. In thconfig select 97-HectorsWetPlan@MiddleEarth -colour [100 0 0] #red select 90-ToPoolPlan@MiddleEarth -colour [0 70 0] #green In layout colour map-fg [97 86 38] # yellow brown So for this 'fixed' map-fg the selects govern, as suggested by The Therion Book and as below, and I get exactly the effect I want. But with colour map-fg altitude, the selects are overridden. Although the selected coloured submaps appear on their own pdf layer, when the other layers are turned off, the submaps have the 'altitude' colours as seen below (and not the red or green colours that I might have hoped). Same thing happens with colour map-fg explo-date. So I think the behaviour suggested by the Therion Book is inconsistently implemented. I would prefer it if setting a colour for a particular map always overrode a general layout specification. Bruce

1 0

using revise to set a map colour, and
by Bruce Mutton 04 Aug '21

04 Aug '21

Hello I'm trying to force the colour of a particular submap, either from a thconfig or from within a layout. The thconfig route gives an error - unknown configuration command The layout route gives an error - unknown option Tried using these two syntax, and variously swapping '-colour' and 'colour' to no avail. revise 97-HectorsWetPlan@MiddleEarth colour [5] endrevise revise 97-HectorsWetPlan@MiddleEarth -colour [5] I see here <https://therion.speleo.sk/wiki/develop?s%5b%5d=revise> that a revise bug was fixed in 5.4.1 that prevented it working outside of a survey context, but maybe something has reverted? More likely I am missing something? I can do this. select 97-HectorsWetPlan@MiddleEarth -colour [100 0 0] #red .and it works in part - the map is exported, but it is not coloured red. Instead it is coloured according to a banded altitude lookup that I have activated. My understanding is that colouring a map explicitly should override 'colour map-fg' specifications, including lookups. I tried changing the order of selects to see if that would place one map over top of the other, but no change. I have previously coloured specific maps successfully (possibly without lookups), although I have not gone back to see exactly how I set those up. So is there a problem with some lookup colour palettes overriding explicit map colour specification? BTW, there is a diagram somewhere that shows the contexts/object model hierarchy of a therion dataset. Can someone point it out to me? (Perhaps it should be in the Therion Book). Bruce

1 0

Better manipulation with background images
by Martin Sluka 03 Aug '21

03 Aug '21

Stacho added two more buttons to manipulate order of background images. M.S.

1 0

3D viewer CaveView
by Martin Sluka 02 Aug '21

02 Aug '21

OpenSource 3D viewer for Therion, Survex and Compass 3D models, where you may view your remote files (Settings/File). https://therion.speleo.sk/cv/ <https://therion.speleo.sk/cv/?fbclid=IwAR3AmEt2ki6ZIotf-LWHNfSD0XMH9qa1uVVp…> Source - https://aardgoose.github.io/CaveView.js/ <https://aardgoose.github.io/CaveView.js/>

3 2