- Therion - speleo.sk

Building Therion on Centos 8 (stream)
by Þórir Már Jónsson 20 Aug '20

20 Aug '20

I am building Therion for the first time and getting one Proj related error when running make: ------------------------------------------------------------------------------- projections: EPSG label -------------------------------------------------------------------------------utest-proj.cxx:77............................................................................... utest-proj.cxx:78: *FAILED:* CHECK( (epsg_labels.count(32634) > 0 && strcmp(epsg_labels[32634],"WGS 84 / UTM zone 34N") == 0) ) with expansion:* false* *====*=========================================================================== test cases: 18 | 17 passed | *1 failed* assertions: 44 | 43 passed | *1 failed* make: *** [Makefile:184: tests] Error 1 Is this an error I can ignore or something I need to fix? If so, do you have any pointers to how I might do that? Best regards, Þórir Már

4 9

Staion point should not go to the calculated lenght of the cave
by Markus Boldt 17 Aug '20

17 Aug '20

Hi, hopefully someone can give me an idea, what I have to do in therion, when I have a point station, which should not go to the calculated length of the cave. But this point station should shown in the In my sample there is a doline in the near of my cave entrance with a point station. Thanks! Best Markus

3 3

Difference between Therion and Survex when calibrating tape
by Tarquin Wilton-Jones 15 Aug '20

15 Aug '20

Hi folks, Think I may have uncovered a bug in Therion's parsing of the "calibrate tape" command. Survex: *calibrate tape 0 0.5 *calibrate tape 0 1 2 10 0 0 *calibrate tape 0 1 2 3 10 90 0 Therion: calibrate tape 0 0.5 calibrate tape 0 1 2 10 0 0 calibrate tape 0 1 2 3 10 90 0 In Survex, both legs are 10 m long. In Therion, the first leg is 5 m long and the second is 10 m long. Therion book: "The syntax is borrowed from Survex with minor modifications; the Survex manual may be useful as an additional reference for the user." Survex manual does not say what happens to the scale value when it is omitted, but it does say "By default, the zero error is 0.0 and the scale factor 1.0 for all quantities." This implies that the scale value should reset to 1 whenever it is omitted. Assuming Survex is "right" with this behaviour, does that mean Therion is wrong? Or is this one of those "minor differences"? Or if I just messed up, someone please shout at me ;) Cheers, Tarquin

3 4

Extended elevations - development snapshot (commit c7d41d9)
by Bruce Mutton 13 Aug '20

13 Aug '20

Thanks Stacho, fast work. The extend logging works, the scaled legs stand out nicely. My current project behaved exactly the same with c7d41d9 so I don’t think it broke anything. Moving the scaled legs from in-line with the survey data, out to a separate centreline using… extend <ratio> <from> <to> extend <ratio> <station> …also worked perfectly. I got a slight surprise in that ‘extend <ratio> <station>’ scales both the incoming and outgoing legs to and from that station, but then I realised that this is consistent with Therion’s treatment of other extend options ie as described in /wiki/extend <https://therion.speleo.sk/wiki/extend#summary_of_all_extend_options_for_sur…> ‘important note’ part way down the page. I have not tried extend ignore <3 station path> yet, but otherwise I think all the recent changes are sound. I only noticed one slight change in ‘breaking’ behaviour when checking a sample of old projects. It is an unfinished project, so it is not too late for me to tidy up the change. I may be out in a Therion desert for the next 10 days, but some time after that I should update the wiki extend page. Prod me if I forget. Bruce From: Therion <therion-bounces(a)speleo.sk> On Behalf Of Stacho Mudrak Sent: Thursday, 13 August 2020 08:50 To: List for Therion users <therion(a)speleo.sk> Subject: Re: [Therion] Extended elevations - development snapshot (commit 6860f82) Hi Bruce, thanks a lot for your feedback. I have added logging of extend ratio, when it is not 100%. Also I hope, I have enabled specification of ratio for given station/shot: extend <ratio> <from> <to> extend <ratio> <station> Allowing the form extend [left <ratio>] would be much more parsing. I have also changed the allowed range to 0 - 200%. Extend ratios are applied to splays also - but in this case - extend ratio of nearest shot is taken for splay. I think, this way it is OK. Could you please check whether it is working now as expected (commit c7d41d9 <https://github.com/therion/therion/commit/c7d41d96ebc47a652243711489813635e…> )? Thanks, S. On Wed, 12 Aug 2020 at 12:25, Bruce Mutton <bruce(a)tomo.co.nz <mailto:bruce@tomo.co.nz> > wrote: And it looks like the extend ratio is not reported when ‘log extend’ is set. It would be nice to have that if it is possible. Bruce From: Therion <therion-bounces(a)speleo.sk <mailto:therion-bounces@speleo.sk> > On Behalf Of Bruce Mutton Sent: Wednesday, 12 August 2020 22:18 To: 'List for Therion users' <therion(a)speleo.sk <mailto:therion@speleo.sk> > Subject: [Therion] Extended elevations - development snapshot (commit 6860f82) Stacho > there is a possibility to specify reduction ratio for extended elevation (0 = vertical, 100 = normal left/right) - just use "extend <number>" I have made this work, by placing ‘extend <number>’ statements in-line with the survey data, but that seems to be the only way it will work. Every combination I could think of with the extend controls in a separate centreline or block results in an error. For an example I have managed to make this extended centreline… …into this by using strategically placed ‘extend 50’, ‘extend 100’, and ‘extend 75’, as well as an ‘extend vertical’. It now matches more closely what one would expect by looking at the plan view. So it works very well, but the difficulty I have is that to make the extended elevation control manageable, it needs to be separated out (in one place) from the survey data, but now any control of the extend ratio must be in-line with the data. This makes it very confusing and difficult to manage. Is there any chance that the ratio could be controlled by statements in separate centrelines, as with left/right/vertical etc? Maybe by allowing the form ‘extend [left <ratio>] <station1> <station2>’ as an equivalent to the in-line statements ‘extend <ratio>’ and then ‘extend left’? (I am thinking of similar syntax to ‘export map -projection [elevation 290 deg]’ where the square brackets are required if the default is not what is wanted). The extend ratios are applied to splays as well as to legs, which is usually desirable, except sometimes where the ratio approaches zero. If the user is to control splay ratios separately to the legs, then I guess the only option is to put the extend ratio statements in-line. And one more thing. The range is limited from 0 to 100%. If we are going to allow distortion of the extended elevation, then I think the upper limit should be something like 150% or 200%. Bruce _______________________________________________ Therion mailing list Therion(a)speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion

1 0

Extended elevations - development snapshot (commit 6860f82)
by Bruce Mutton 12 Aug '20

12 Aug '20

> there is a possibility to specify reduction ratio for extended elevation (0 = vertical, 100 = normal left/right) - just use "extend <number>" I have a project that is just perfect for this, but have not been able to make it work. I expect I have not understood how the syntax is intended to be used. The statements below relate to only a small part of the selected survey centreline, and cause this error ":\Program Files (x86)\Therion\therion.exe: error -- Extend-DwarfsDoorElevEXT.th [120] -- station doesn't exist - 1" If I remove the group endgroup pair, the project compiles just fine, however this branch (and the whole extended elevation) is compiled full size without the 85% reduction specified. The 'extend 85' statement is ignored. Also there seems to be a problem in that a group block is somehow cancelling the station-names specification (whether or not it is moved inside or outside of the group block). I have never really used group blocks, so am not familiar with their limitations. centreline group station-names []@D-K6 #DwarfsD-K6-Stream.th # now foreshorten this passage so station 13 appears near to station 2 (the red branch in the diagram below) # they could have been a loop, but the surveyor did not close to the same locations extend 85 extend left 1 endgroup endcentreline If I try extend 85 left 1 then I get the error "C:\Program Files (x86)\Therion\therion.exe: error -- Extend-DwarfsDoorElevEXT.th [120] -- unknown extend flag - 85" BTW I assume the reduction and the three-station path ignores will be reported when log extend is added to the thconfig? Bruce

3 5

Extended elevations - development snapshot (commit 6860f82).
by Bruce Mutton 01 Aug '20

01 Aug '20

Thanks Stacho This is much appreciated. Might take me a while to work through testing it. Regarding ‘extend <number>’, can this be used as ‘extend <number> [<station> | <leg>]’? Or can it only be used in-line with the survey data? Or can it apply to groups of extend statements defined in a block separate to the survey data? Just starting to compare before and after (extend splay and loop bugs resolution) by looking through my datasets. A sample of one with no loops suggests the splay fix is good, or at least credible. A sample of one other with some loops that caused me pain when originally drawn, suggests that the difficult loops may have remained unchanged, but there is at least one unexpected change as illustrated below. There is an unexpected and unwanted display of station 6.3 The extend control for this part of the cave follows. This is how Aven interprets the loops (shown in (projected) elevation) ie a loop within a loop within a loop. Curious how Aven does not seem to recognise the two ignored legs within the loop, as being within a loop ie they are coloured grey, and not blue to reflect the std deviation of the closure error. Therion original incorrect extended splay behaviour New Therion 5.5.1+9860f82 splay behaviour PocketTopo extended drawing and splays PocketTopo drawn and TopParser generated xvi on which above drawings are based Station 6.15 has the same map-connection line in each Therion export, but station 6.3 pops up with a spurious map-connection in 6860f82. Notice how the xvi splays are different in all of the above. It has long been my suspicion that each application produces quite different extended splay interpretations, so I am not surprised or necessarily troubled by this. When drawing in a cave I often think that PocketTopo gets it quite wrong (and it changes splays dynamically when the next leg is surveyed – which is disturbing at the time, but is adhering to the paradigm whereby splays are allocated to the leg with the closest bearing). It looks like the new Therion 6860f82 extended splays are quite similar to PocketTopo but not so much like the xvi. I presume the xvi is incorrect. Bruce From: Therion <therion-bounces(a)speleo.sk> On Behalf Of Stacho Mudrak Sent: Thursday, 30 July 2020 22:45 To: List for Therion users <therion(a)speleo.sk> Subject: Re: [Therion] Splays - Revisiting Breaking extended elevations I have tried to fix all the extended elevation issues in the latest development snapshot (commit 6860f82 <https://github.com/therion/therion/commit/6860f82e616edb5e0fc7b35120cfc68eb…> ). 1. splay shots should be extended relatively to survey shot with closest (horizontal) bearing 2. there is a possibility to specify reduction ratio for extended elevation (0 = vertical, 100 = normal left/right) - just use "extend <number>" 3. extend ignore via path of 3 points should now work -- use "extend ignore <s1> <s2> <s3>". I think this should allow all crazy loop configurations to be solved, but I am not still 100% sure. Unfortunately (but not surprisingly :/), there was a bug with the extended elevation algorithm. In the case there were loops present in the centerline, it caused some random behaviour. I have tried to fix this bug, but it required quite a deep change to the code. My data seems to work, but I suppose, there may be some cases when it still can fail. Could you please try your datasets? Thanks, S

1 0

context related hide with custom point
by Axel 31 Jul '20

31 Jul '20

2 1

Selecting parts of a survey with the "select" statement
by Tarquin Wilton-Jones 31 Jul '20

31 Jul '20

Hi folks (and particularly Stacho), Just trying to revive an idea we had last year, which solves a significant problem; drawing cross sections through multiple passages/stations. The idea is to be able to select a subset of legs and splays from a survey, for export (eg. as an XVI). https://github.com/therion/therion/issues/156 group foo 2 3 2.706 351.41 -77.19 3 - 0.440 232.38 13.38 3 - 0.824 193.77 56.68 3 - 0.648 149.94 47.91 endgroup And in .thconfig: source "cave.th" select foo(a)survey1.cave select bar(a)survey1.cave select baz(a)survey2.cave export map -projection [elevation 180] -fmt xvi -output "sections_a.xvi" Can anyone see any better ways to do this with existing stuff, or should I keep trying to persuade someone to implement it? Stacho, would you be able to say if such a thing would actually be possible to implement? Cheers, Tarquin

1 0

Splays - Revisiting Breaking extended elevations
by Bruce Mutton 30 Jul '20

30 Jul '20

Another random observation on extend control. Extending left and right using a block of control statements (as opposed to in-line with the survey data) results in Therion extending the splays incorrectly. This behaviour is present regardless of whether data is imported via PocketTopo, TopParser or SexyTopo. Examples below. Below, a SexyTopo elevation surveying to the right (splays are correctly drawn) Below, the above SexyTopo elevation exported to Therion (it is the same – good) Below, the above elevation from Therion exported left (splays are wrong) Notice how all the splays are extended in the direction that the legs are extended in. Another example of Therion export to pdf showing splays incorrectly extending in the direction that the legs have been extended. It should be more aligned to the approach that TopoDroid uses (page 19 of the user manual) <https://sites.google.com/site/speleoapps/home/topodroid/user-manual> “mid-line = centreline” “azimuth = bearing” Bruce

4 6

Extended Gridl ines longer and other font for altitude
by Axel 29 Jul '20

29 Jul '20

2 4