March 2022 - 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

Colour leakage from point station-names
by Bruce Mutton 27 Apr '22

27 Apr '22

If I change the colours like this: symbol-colour point station-name [00 100 100] then the colour leaks into some of the debug scrap-names, but not all of them. So I deduce there is a problem with the coding for point station-names (not clearing the colour properly) or with the debug scrap-names (not setting it's colour properly). There was a similar conversation and subsequent fix in relation to line rock-border or rock-edge some years back (metapost code I think). I cannot find the thread now. I have also had apparently similar issues (about 3 years back) with point station colouring when plotting surface surveys. It is not too important as (in the case pictured) it only affects debug outputs, but might point to something inconsistently applied when coding. (Hoping it is not related to customisations I have made). Bruce

2 1

new Therion 6.0.6
by Therion 31 Mar '22

31 Mar '22

Hi, there is a new release 6.0.6 of Therion. Check https://github.com/therion/therion/releases/tag/v6.0.6 for more details. Best regards, Therion team

2 2

new Therion 6.0.6
by Therion 30 Mar '22

30 Mar '22

Hi, there is a new release 6.0.6 of Therion. Check https://github.com/therion/therion/releases/tag/v6.0.6 for more details. Best regards, Therion team

1 0

new Therion 6.0.6
by Therion 26 Mar '22

26 Mar '22

Hi, there is a new release 6.0.6 of Therion. Check https://github.com/therion/therion/releases/tag/v6.0.6 for more details. Best regards, Therion team

1 0

Extended elevation direction opposite to sketch (TopParser and PocketTopo export to Therion)
by Bruce Mutton 08 Mar '22

08 Mar '22

Has anyone come across this issue with changes in direction of extended elevations, when PocketTopo files are processed with TopParser or exported to Therion? ie, the centreline developing in the opposite direction to the original sketch? The extended elevation is OK in PocketTopo, but regardless of the method used to parse it to Therion, the second part of the survey extends the wrong way in the xvi file. In this file, station 1.0 is where the survey started, first downstream, then we went back to station 1.0 and continued upstream. The second part of the survey has the legs 'flipped' so that they extend left. I eventually worked around this by deleting the downstream legs. Now the second set of legs starting from station 1.0 correctly extend left. I'm wondering if this behaviour is due to having two 'branches' of survey legs extending from the first station in the survey, 1.0, with one extending right, and the other left? Perhaps this is a limitation or bug with the code that parses from .top to .xvi (for both TopParser and 'Therion method')? Bruce

2 1