- Therion - speleo.sk

Therion uses wrong declination for surveys 'in the future'
by Matthias Keller 06 Oct '20

06 Oct '20

Hi I just had the following problem: A current survey (with survey dates 2020.06.27 and 2020.09.19) was compiled using Therion 5.4.4 (from 2019). I got the following warning during compilation: warning -- unable to determine magnetic declination for undated surveys However, firstly: this warning is wrong, as all surveys are dated correctly. However I was stunned by some large loop errors in the newest surveys (>60cm in only 10 legs). Then, just by some other impulse I updated therion to 5.5.1 and suddenly, those errors went down to <10cm and the generated models looked differently. Also, the above error message was not present anymore. So i experimented and just added "declination 3 deg" to the two new surveys (from June and September) and suddenly, the output generated by 5.4.4 looked pretty much as the one from 5.5.1 It appears that, when therion cannot determine the magnetic declination of a survey (with valid date!), it finally just assumes 0. The problem seems to be, that the declination data stored in 5.4.4 didn't let therion determine a possible declination for 2020.06.27 and 2020.09.19 so it just assumed 0. I would have expected therion to at least consider the latest known declination which would result to around 3° (in Switzerland). Is this a known issue? It just means that whenever you open a survey in some version being 'too old', it will kill your plans... BTW, Therion 5.4.4 seems to have *some* data for 2020 at least, as it seems: geomag declinations (deg): 2019.1.1 2.9201 2020.1.1 3.0503 but the only surveys from 2020 are the ones from June 2020 and September 2020, and both were assigned a declination of 0° instead of about 3°. I can verify that by adding the declination parameter with "0 deg" to those surveys and the output is identical to the one without this parameter. Thanks Matt

6 9

maps off solves unexpected scrap stacking order where no maps are defined
by Bruce Mutton 27 Sep '20

27 Sep '20

This is just a FYI in case anyone is interested. A problem solved, but a mystery not solved. On and off through 2019 there were discussions about how to predict or debug scrap stacking order. This message by Tarquin covers the expected behaviour fairly comprehensively. https://www.mail-archive.com/therion@speleo.sk/msg07925.html That is all very well, and 99% of the time my projects stack scraps the way I expect. Except that I have one large project where lower passage scraps stack on top of upper level scraps, in a few locations only, in the scenario where no maps defined whatsoever (with the intention that scraps therefore stack according to average altitude). Other scenarios using the same source data, where maps are defined and selected, all plot as expected according to the map structures. But for large overview maps I need to plot all scraps without any map structure, and I'd like them to stack correctly. The offending scraps were drawn many years ago, and were all much longer and encompassing much greater passage height variations than I would adopt these days. I just assumed that the average heights that Therion calculated were somehow not collated in the stacking order that I expected. Anyway I eventually found the time to check the scrap and heights reported in therion.log. To my slight surprise I found that in fact the average heights that Therion calculated were in exactly the order I expected. So why was Therion not stacking the scraps in the expected order? My anticipated solution of breaking the scraps into pieces to make them behave properly no longer seemed likely to make any difference. Since it was implemented, I have been making use of the 'maps off' to disable previews and offsets, as a more refined way of achieving a particular output than just 'not defining' any maps in a particular thconfig. https://www.mail-archive.com/therion@speleo.sk/msg07571.html In desperation I thought I'd try adding 'maps off' to the thconfig above, where no maps were defined. It should, I expected, make no difference at all. And in one easy step, all of the scraps now plot in the correct stacking order! So why does 'maps off' make scraps plot in the correct order when there are no maps defined? Bruce

2 1

Mac OS 10.14.6 install error
by marcus thomas 21 Sep '20

21 Sep '20

Hi, I’m having trouble installing therion on Mac OS 10.14.6. After installing all the additional programs via home-brew I get the following error message trying to install Therion itself: brew install https://raw.githubusercontent.com/ladislavb/homebrew-therion/master/therion… <https://raw.githubusercontent.com/ladislavb/homebrew-therion/master/therion…> Error: Calling Non-checksummed download of therion formula file from an arbitrary URL is disabled! Use 'brew extract' or 'brew create' and 'brew tap-new' to create a formula file in a tap on GitHub instead. Have any other Mac users come across this or shed some light on what i’m doing wrong?

2 1

2 fixes for a point with standard deviation
by Tarquin Wilton-Jones 21 Sep '20

21 Sep '20

Therion really doesn't seem to like using Survex for fixed points :( When you have exactly 2 fixes for a station, Therion 5.5.1 (with Survex 1.2.42) gives up when processing survey data, and gives no reason why. https://github.com/therion/therion/issues/270 There is a workaround; specify every fix twice. The result will be the same, but it will actually work. I get the feeling I am "holding it wrong". Surely this must have been a problem for someone in the past. Bruce, how come this has not broken your surveys?

2 2

Loch and VTK 9.0.1 (on Macos)
by Xavier Robert 11 Sep '20

11 Sep '20

Dear all, I was trying to upgrade my Therion version, and this morning, the VTK package upgraded from version 8.2.0_11 to 9.0.1 (I ‘am still on macosX 10.14, and I am upgrading my binaries with Homebrew). I do not know if this is relevant, but it also upgraded pcl (1.11.1—>1.11.1_1) and qt (5.15.0—>5.15.1) In consequence, Loch building crashes with this output (that was fine with vtk 8.2) : ./utest =============================================================================== All tests passed (47 assertions in 19 test cases) /Applications/Xcode.app/Contents/Developer/usr/bin/make -C ./xtherion make[1]: Nothing to be done for `all'. /Applications/Xcode.app/Contents/Developer/usr/bin/make -C ./loch c++ -c -Wall -D_GNU_SOURCE -DLOCH -W -Wall -std=c++11 -DLXMACOSX -I/usr/local/lib/wx/include/osx_cocoa-unicode-3.0 -I/usr/local/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXMAC__ -D__WXOSX__ -D__WXOSX_COCOA__ -I/usr/local/opt/freetype/include/freetype2 -I/usr/local/include/vtk-9.0 -Wno-deprecated -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -O2 -o lxData.o lxData.cxx lxData.cxx:541:28: error: no member named 'SetInput' in 'vtkPolyDataNormals'; did you mean 'SetOutput'? this->scrapWallsNormals->SetInput(this->scrapWalls); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:554:19: error: no member named 'AddInput' in 'vtkAppendPolyData' this->allWalls->AddInput(this->scrapWallsNormals->GetOutput()); ~~~~~~~~~~~~~~ ^ lxData.cxx:555:19: error: no member named 'AddInput' in 'vtkAppendPolyData' this->allWalls->AddInput(this->lrudWalls); ~~~~~~~~~~~~~~ ^ lxData.cxx:562:27: error: no member named 'SetInput' in 'vtkTriangleFilter'; did you mean 'SetOutput'? this->allWallsTriangle->SetInput(this->allWalls->GetOutput()); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:563:25: error: no member named 'SetInput' in 'vtkDepthSortPolyData'; did you mean 'SetOutput'? this->allWallsSorted->SetInput(this->allWallsTriangle->GetOutput()); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:569:27: error: no member named 'SetInput' in 'vtkStripper'; did you mean 'SetOutput'? this->allWallsStripped->SetInput(this->allWallsTriangle->GetOutput()); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:576:25: error: no member named 'SetInput' in 'vtkPolyDataNormals'; did you mean 'SetOutput'? this->surfaceNormals->SetInput(this->surface); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:584:26: error: no member named 'SetInput' in 'vtkTriangleFilter'; did you mean 'SetOutput'? this->surfaceTriangle->SetInput(this->surfaceNormals->GetOutput()); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:585:24: error: no member named 'SetInput' in 'vtkDepthSortPolyData'; did you mean 'SetOutput'? this->surfaceSorted->SetInput(this->surfaceTriangle->GetOutput()); ^~~~~~~~ SetOutput /usr/local/include/vtk-9.0/vtkPolyDataAlgorithm.h:54:16: note: 'SetOutput' declared here virtual void SetOutput(vtkDataObject* d); ^ lxData.cxx:611:6: error: no member named 'SetInput' in 'vtkPolyDataWriter' w->SetInput(this->allWallsStripped->GetOutput()); ~ ^ 10 errors generated. make[1]: *** [lxData.o] Error 1 make: *** [loch/loch] Error 2 I imaging that this is due to a new definition of the function SetInput/AddInput in the new package VTK? Xavier

1 0

Error while compiling Therion 5.5.x (proj issue?) on MacosX
by Xavier Robert 11 Sep '20

11 Sep '20

Dear all, I am trying to compile the last Therion version on my Macos 10.14.6. The compilation fails with the ./utest with the error: ./utest proj_create: cannot build projectedCRS 32634: cannot build geodeticCRS 4326: SQLite error on SELECT name, ellipsoid_auth_name, ellipsoid_code, prime_meridian_auth_name, prime_meridian_code, area_of_use_auth_name, area_of_use_code, publication_date, deprecated FROM geodetic_datum WHERE auth_name = ? AND code = ?: no such column: publication_date (null): error -- PROJ library: -61 (generic error of unknown origin): epsg:32634 make: *** [tests] Error 1 Versions 5.5.0, 5.5.1, 2020-09-08-master (57fce14) and the today’s master (6c41c82) are raising the same error. With the master (6c41c82) version: A « tclsh thcdata.tcl » gives « No PROJ system definitions imported ». If I do a search for « 32634 » in thcsdata.cxx, I find only 1 line: {false, true, false, "+init=epsg:32634", "PROJCS[\"WGS_1984_UTM_Zone_34N\",GEOGCS[\"GCS_WGS_1984\",DATUM[\"D_WGS_1984\",SPHEROID[\"WGS_1984\",6378137.0,298.257223563]],PRIMEM[\"Greenwich\",0.0],UNIT[\"Degree\",0.0174532925199433]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"False_Easting\",500000.0],PARAMETER[\"False_Northing\",0.0],PARAMETER[\"Central_Meridian\",21.0],PARAMETER[\"Scale_Factor\",0.9996],PARAMETER[\"Latitude_Of_Origin\",0.0],UNIT[\"Meter\",1.0]]", "WGS84 / UTM zone 34N"}, I tried the compilation with 2 proj versions: 6.3.2 (proj) and 7.1.1 (osgeo-proj). The compilation stops with the same error. I also have the sqlite3 from Anaconda installed. On the other side, I also tried to recompile the 5.4.4 version (that I already have and that is running fine), and I could recompile it without any errors (with proj 6.3.2, I did not tried with proj 7). Does anyone have faced the same problem and have solved the issue ? Cheers, Xavier

3 3

Bug with uncertainty on fixed station on windows 10?
by Xavier Pennec 10 Sep '20

10 Sep '20

Dear all, I have a problem with the last version of therion (after 5.3.15) on windows 10 with fixed points endowed with a stddev. The very short example attached is ending with an error on the step "processing survey data" without leaving any trace (no log file, even with the -d flag). I could just catch the attached screen capture on the fly before it crashes. Same thing is happening with Therion 5.4.4, 5.4.2 and 5.4.1 (5.3.15 does not crashes but provides wrong results probably due to the version of survex which is too recent). However, the attached example works well on ubuntu with Therion 5.4.1 (with Survex 1.2.33) on a friend's computer. Curiously, every thing works well on my windows 10 if I comment out the std dev on the fixed points... But I really need this uncertainty as the gps measures along a cliff are very uncertain due to reflections. Any idea of what is going wrong and how to get around? Thank you for any clue... best Xavier -- > ------------------------- > Xavier Pennec > Senior Research Scientist / Directeur de recherche > Asclepios project-team, INRIA Sophia-Antipolis > 2004 Route des Lucioles, BP93 > F-06902 Sophia-Antipolis Cedex, France > +33 4 92 38 76 64 > +33 6 78 35 16 90 > https://team.inria.fr/epione/en/ > -------------------------------

3 10

Command extend
by Markus Boldt 06 Sep '20

06 Sep '20

Hi all, the command "extend" comes in the loop centerline / endcenterline in the TH-File - right? Best Markus

2 2

3D loch model question
by עמרי גסטר 04 Sep '20

04 Sep '20

Hi everyone, I have a question about the 3d model. something I see a lot but I don't know why this is happening.... In the attached screenshot, therion build a wall between station c1 & B36.1 (marked with blue line). These are supposed to be two separate chimanies. Why does it feel the necessity to connect it? [image: image.png] --

3 3

Different map-level for different map items
by Tarquin Wilton-Jones 24 Aug '20

24 Aug '20

Hi, Just wondering if map-level can be dynamic or set differently for different map items. map mymap -projection plan eastcaves westcaves surfaceMP@surface #this has a title endmap map eastcaves cave1MP@cave1 #this has a title cave2MP@cave2 #this has a title endmap map westcaves cave3MP@cave3 #this has a title cave4MP@cave4 #this has a title endmap If I were making an atlas of "mymap" (using "select mymap@mycaves -map-level 2" and "export atlas"), I would want to use "-map-level 2" for the caves, but "-map-level 1" for the surface. Is there a way to make it use a different map-level for each item in mymap, or would I need to create a nested map to put surfaceMP@surface into, so that it would also have a map-level of 2? Cheers, Tarquin

1 0