October 2023 - Therion

kml color
by Philippe Vernant 25 Oct '25

25 Oct '25

Hi guys, I can’t find a way to change the light greyish color of the kml export except by going into the kml file and change it after it has been created. Is there a way to specify the color when creating the kml ? Thanks, Phil

3 3

Setting map border framethickness to zero (off)
by Bruce Mutton 30 Oct '23

30 Oct '23

Good morning Probably a simple tex question. I often use this code to create a border around an exported map: code tex-map \framethickness=0.5mm >From time to time (in the same compilation run) I insert one exported map into another using map-image and usually the inserted map should not have a border. To date I have always arranged my layouts so that \framethickness is undefined while the initial map is exported, THEN set to 0.5 mm for the second map export. It occurred to me that with my project arrangment it would be more convenient to set the border to 0.5 mm (in a global layout) and THEN reset it to zero or undefined in a layout specific to only one of the exports. I have tried these two options: code tex-map \framethickness={} code tex-map \framethickness=0mm The first causes error (pdftex exit code 1) and the second draws a 0.5 mm border around both maps. How should I 'turn off' a map border if \framethickness has already been set? Regards Bruce

1 0

-flip horizontal and line numbering
by alastair gott 23 Oct '23

23 Oct '23

Hi Therion people, I've just noticed that flipping an extended elevation scrap using “-flip horizontal” it changes the numbering of the lines points on the th2 file when the file is processed by the config file. I was trying to line join the top line of one elevation survey with the top line of another survey using "join linetop@normal:end linetop@flipped:0" as the “normal:end” line was accidentally drawn clockwise and “flipped:0” was drawn anti-clockwise it makes sense that end and zero were the join points However when the file was run it was necessary to change it to be "join linetop@normal:end linetop@flipped:end" to get the two lines to join, it's not a problem, just something I wasn't aware of. Regards, Alastair. Sent from Outlook for iOS<https://aka.ms/o0ukef>

3 2

Mac : Xtherion problems
by Martin Kern 21 Oct '23

21 Oct '23

Hi mac users, Do the Xtherion shortcuts work on your mac? Not on mine and it’s really annoying ! My Xtherion interface also has freeze problems when I click on the right pannel. I need to click on a other window to continue to work. So I use the right click options but it's not always the most convenient. Does anyone have a solution to these problems? Thank’s, Martin

3 2

Background map-header
by Yann Gardère 20 Oct '23

20 Oct '23

Hello therion users On Therion I would like to apply a particular background color for the "map-header" different from the background color of the map, does anyone have a tex-map or metapost code to send me to do this? I don't find this in therion's wiki Thanks [image: 🙂] Yann

3 3

Area water visibility inconsistent depending on scale
by Bruce Mutton 17 Oct '23

17 Oct '23

I eventually solved my problem by making sure the line segments overlapped, rather than joining at a single point. After checking that they did indeed join at a single point, as below. I presume the missing area was due to some kind of rounding error making Therion think that the area bounding lines did not form a closed area. Only manifesting at some scale(s). Bruce From: Bruce Mutton <bruce(a)tomo.co.nz> Sent: Monday, 16 October 2023 18:22 To: 'List for Therion users' <therion(a)speleo.sk> Subject: Area water visibility inconsistent depending on scale Hello again I'm wondering why my area water displays at scale of 1:1000 but if I compile at 1:500 just one of the area waters does not display? The two water areas are both defined in the same scrap, which I have highlighted in yellow in one of the images. The areas are defined by three lines - a single horizontal line for the water surface and two curved lines to bound each of the areas. All lines and areas have -clip off set. When the lower curved lines have -visibility on, I can see they are there, but the area water still does not display. Thinking that the label about the water supply might be somehow obscuring the area, I deleted it, but that had no effect Other area waters in the same compilation (indeed the same entire project) are OK as far as I know. Have never noticed behaviour like this before. Therion 6.1.8 Images below. I've checked the distortion with debug first and debug second, distortion looks OK, but there is no sign of the larger area. With lower area water boundaries set to -visibility on. I'm wondering if the morphing is shortening the top line at 1:1000 (making the area fail) but not at 1:500. I don't think this should happen, as I made the left-hand line points coincident, so both area boundary lines should join perfectly without a gap. It seems they do, as below. So any ideas as to why visibility of one of the area waters in this project should be scale dependant? Thanks Bruce

1 0

Area water visibility inconsistent depending on scale
by Bruce Mutton 16 Oct '23

16 Oct '23

Hello again I'm wondering why my area water displays at scale of 1:1000 but if I compile at 1:500 just one of the area waters does not display? The two water areas are both defined in the same scrap, which I have highlighted in yellow in one of the images. The areas are defined by three lines - a single horizontal line for the water surface and two curved lines to bound each of the areas. All lines and areas have -clip off set. When the lower curved lines have -visibility on, I can see they are there, but the area water still does not display. Thinking that the label about the water supply might be somehow obscuring the area, I deleted it, but that had no effect Other area waters in the same compilation (indeed the same entire project) are OK as far as I know. Have never noticed behaviour like this before. Therion 6.1.8 Images below. I've checked the distortion with debug first and debug second, distortion looks OK, but there is no sign of the larger area. With lower area water boundaries set to -visibility on. I'm wondering if the morphing is shortening the top line at 1:1000 (making the area fail) but not at 1:500. I don't think this should happen, as I made the left-hand line points coincident, so both area boundary lines should join perfectly without a gap. It seems they do, as below. So any ideas as to why visibility of one of the area waters in this project should be scale dependant? Thanks Bruce

1 0

Fixed station visibility inconsistent in offset map
by Bruce Mutton 16 Oct '23

16 Oct '23

Good afternoon (or morning) I'm wondering why station visibility is inconsistent when maps are offset? Below is an example where all survey stations of type fixed are shown in both the previewed (grey) passage and in the offset passage. Except that one of the stations is not shown in the offset passage (circled in red). Why should that one be different? Using Therion 6.1.8 There are a number of sub-maps in the image. All are maps-of-scraps except one is a map-of-centrelines, which explains why the stations are visible in the (grey) previewed passage. If I remove the map-of-centrelines, the previewed stations are not displayed (as is to be expected). Regards Bruce

1 0

'Colour by error' is not displayed by Aven if 'flags duplicate' is applied to leg in Therion
by Bruce Mutton 09 Oct '23

09 Oct '23

Not sure if this is a Survex Aven issue or an issue with the way Therion parses data to a *.3d file, or indeed whether it is because Im using an old version of Aven. I was surveying fore-sight back-sight pairs, first time in a cave for ages... so initially made a naïve oversight: - forgot to make the backsight legs duplicate, thereby almost doubling the calculated cave length. In the entrance area of this (tourist) cave there is a big steel gate and overhead 240 v power wires some 15 20 m away. This led to 10-15 deg errors when outside the cave or some 4 m inside of the gate. We abandoned any hope of a compass survey outside the cave. Interestingly the powered-down cables in the cave seemed to have minimal if any effect on bearings. So I was using Aven to visually characterise the degree of misclosure on each fore-sight back-sight pair. ie Colour by error gave me nice dark blue 1x sd errors inside and lighter blue 3x sd errors near the entrance and outside. So far, so good. Then I realised that I needed to make the back-sight legs duplicate. But now Aven does not display the duplicate legs as being part of a loop, so I lose the very useful ability to quickly visualise all of the loops and their relative quality. In hindsight I have noticed that Aven misses plotting of loop closure sd of isolated legs for years, and I could not figure out why. I wonder if that is also related to a flags issue? And wondering if this is considered a bug? ie display of loop status by Aven should override Therion flags status (duplicate, approximate, surface etc) therion 6.1.8 (2023-06-14) Survex 1.4.1 > Im using this cos the next version broke display of colour by error for Therion exported 3d files (I forget the reason now maybe its been fixed since) Regards Bruec

1 0

Therion error - a software BUG is present
by Bruce Mutton 05 Oct '23

05 Oct '23

Oops I attempted to equate a pair of stations to close a large loop in an otherwise well behaved but complex model, and suddenly Therion reports a software BUG. About to post this message, and noticed that I had this same issue 11 years ago https://www.mail-archive.com/therion@speleo.sk/msg03641.html although that time the culprit was thdb1d.cxx:2290. I think it was associated with some 'no-survey' statements, but I am not sure. Any ideas? Bruce >From therion.log . 2024.1.1 22.6293 scanning centreline tree ... done searching for centerline loops ... done calculating station coordinates ... C:\Program Files (x86)\Therion\therion.exe: error -- a software BUG is present (D:/a/therion/therion/thdb1d.cxx:2418) writing xtherion file ... done

1 0