April 2017 - Therion

"\legendbox" "\loadpicture" and absolute paths
by rowena 14 Mar '21

14 Mar '21

Hello, I am using the "\loadpicture" capability in "\legendbox" constructs to include map sections, elevations, etc. It all works nicely on my PC where I am using relative paths to the pdf files. My club has a desire to archive the map data for posterity - ie if my pc dies or I go walkabout, the map data should still be available so that others can add to the maps as they are extended. I would prefer to have the images included using relative pathnames, rather than absolute pathnames, so that future explorers can download the map data and extend it, without having to duplicate my file hierarchy. How can I include relative paths in the \loadpicture functionality? Thanks, Rowena

4 5

Scale dependant error when using area fills
by Tom Foord 20 Jan '19

20 Jan '19

Hi all I'm having some problems compiling a project which includes debris area fills. Depending on the exact symbol fill that I use, I am getting strange scale-dependant errors which seem to cause the compiler to loop endlessly until I force it to stop. I originally noticed the problem when using a custom area fill that I made by modifying the standard a_debris_AUT symbol fill. I've attached my modified metapost definition in the attached text file 'a_debris_WUG.txt'. The error occurs for any scale between 1:2000 and 1:4483 (outside of this range the project compiles fine). See attached output log 'Output log - a_debris_WUG.txt'. As you can see, the file seems to loop over and over again. Initially I thought this problem was specific to my custom fill, but then I noticed that I also get a similar error when using the standard a_debris_AUT fill, however this time the error only occurs when the scale is set to exactly 1:2000 (any other scale seems to be fine). See attached output log 'Output log - a_debris_AUT.txt'. Can anyone help with this problem? Thanks Tom

9 21

Import a scrap into another scrap (or th2-file)
by torstein finnesand 11 Oct '17

11 Oct '17

Hi fellows, Sometimes I realize that two scraps should have been one (for instance scrap A in A.th2 should have been a part of scrap B in B.th2), in particular when it's difficult to join them. It's easy to insert the xvi file into the scrap B file. But I have to draw it again. Is there any workaround here? Torstein Finnesand Norway

8 14

Re: [Therion] Linux and DistoX (Wookey)
by Marco Corvi 30 Jun '17

30 Jun '17

So, thanks to me giving a competent person (who also doesn't own any Windows or Android devices) a couple of distoX's that needed ... At the moment this only works with python3 and distoX1, But Stuart plans to use the topodroid codebase to work out the differences for the X2 protocol (unless anyone has a doc for this already, or Marco can tell him). wookey, i may be not precise because i do not have the docs at hand. the distox2 protocol is backward compatible. therefore, getting the calib raw data from the distox2 is the same as in distox1, namely two data packets, one for G, one for M. the commands to toggle calib mode on and off are the same, too. the computation of the calib coeff has changed a bit with firmware 2.2 (or 2.3, don't remember well) beat added three non-linear coeffs, and these are written after the other 24. there is a catch: in the distox1 those mem are set at 0xff (ie -1), so these three coeff are written with 0 getting to 0xff. the non-linear calib should not be used for older firmwares. i have not changed the linux code, and i do not think to have the time to do that. i also understand you may not want to use android, but you can use the android code and turn it in C++ the computational methods are very much C like, and the helper classes are just basic linalgebra. if you or stuart have any question, send me email marco

2 1

Link to class material of DisotX + Topoddroid + Therion portuguese course
by Rodrigo Severo 14 Jun '17

14 Jun '17

Hi, Here is the link to all class material of a portuguese course I taught on DistoX + Topodroid + Therion: https://goo.gl/YsDLhk I wonder how could I make it available through Therion's wiki page. Regards, Rodrigo Severo

2 2

Therion 5.4.1 on Fedora 25 - Compile fails in loch
by Bill Gee 09 Jun '17

09 Jun '17

Hello everyone - Once again I am wrestling with the ancient problem of getting loch to compile on Fedora Linux. Below is the sequence of errors that I get. I think I can modify the Therion Makefile so that it skips loch, but I would rather not do that. Some versions ago I figured out a set of changes to the loch Makefile that allowed it to compile. The listing below shows those changes. They do not work anymore, as seen by the compiler error. In the second set of errors it is saying that some libraries cannot be found. I do not find any files by these exact names. They probably have some extension, perhaps .so? But I do not find any files with that extension either. vtkIO.so does not exist. Two questions for the group: 1) Exactly what files are missing? I very likely have them, just not where the compiler is looking. If I can find them, maybe I can add something to VTKLIBPATH. 2) Is there an easier way to deal with this? Why is it that Fedora always has problems? It should Just Work. -- Bill Gee ===== Using the providede Makefile for loch: make -C ./loch make[1]: Entering directory '/home/bgee/Installs/therion-5.4.1/loch' gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk3- unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL - D__WXGTK__ -pthread -O2 -o /home/bgee/Installs/therion.bin/loch/lxR2P.o lxR2P.c gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk3- unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL - D__WXGTK__ -pthread -O2 -o /home/bgee/Installs/therion.bin/loch/lxTR.o lxTR.c c++ -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk3- unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL - D__WXGTK__ -pthread -Wno-deprecated -I/usr/include/freetype2 -I/usr/local/ include/vtk-5.4 -O2 -o /home/bgee/Installs/therion.bin/loch/lxOGLFT.o lxOGLFT.cxx c++ -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX -I/usr/lib64/wx/include/gtk3- unicode-3.0 -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL - D__WXGTK__ -pthread -Wno-deprecated -I/usr/include/freetype2 -I/usr/local/ include/vtk-5.4 -O2 -o /home/bgee/Installs/therion.bin/loch/lxSetup.o lxSetup.cxx In file included from lxSetup.h:23:0, from lxSetup.cxx:38: lxData.h:34:25: fatal error: vtkPolyData.h: No such file or directory #include <vtkPolyData.h> ^ compilation terminated. Makefile:147: recipe for target '/home/bgee/Installs/therion.bin/loch/ lxSetup.o' failed make[1]: *** [/home/bgee/Installs/therion.bin/loch/lxSetup.o] Error 1 make[1]: Leaving directory '/home/bgee/Installs/therion-5.4.1/loch' Makefile:206: recipe for target 'loch/loch' failed make: *** [loch/loch] Error 2 bgee  ~  Installs  therion-5.4.1  === Modified loch makefile: #VTKVERSION = $(shell tclsh ./getvtkver.tcl version) #VTKPATH = $(shell tclsh ./getvtkver.tcl incpath) #VTKLIBPATH = $(shell tclsh ./getvtkver.tcl libpath) VTKVERSION=6.3 VTKV6 = $(shell tclsh ./getvtkver.tcl version6) #ifeq ($(VTKV6),1) #VTKLIBS = -lvtkCommonExecutionModel-$(VTKVERSION) -lvtkCommonDataModel-$ (VTKVERSION) -lvtkCommonCore-$(VTKVERSION) -lvtkFiltersCore-$(VTKVERSION) - lvtkFiltersHybrid-$(VTKVERSION) -lvtkIOLegacy-$(VTKVERSION) -lfreetype -lpng - ljpeg #else #VTKLIBS = -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering - lvtkCommon -lvtkjpeg -lvtkpng -lvtkzlib -lvtksys -lfreetype #endif # VTKVERSION = 5.4 # VTKPATH = /usr/local/include/vtk-$(VTKVERSION) # VTKLIBPATH = /usr/local/lib/vtk-$(VTKVERSION) VTKPATH=/usr/include/vtk VTKLIBPATH=/usr/lib64/vtk ==== Gives this result when compiling: c++ -o ./loch -Wall ./lxR2P.o ./lxTR.o ./lxOGLFT.o ./lxSetup.o ./lxRender.o ./lxWX.o ./lxImgIO.o ./lxLRUD.o ./lxFile.o ./lxSTree.o ./lxData.o ./lxMath.o ./lxSView.o ./lxSScene.o ./lxGUI.o ./lxGLC.o ./lxOptDlg.o ./lxAboutDlg.o ./ lxPres.o ./img.o -lwx_gtk3u_gl-3.0 -pthread -lwx_gtk3u_xrc-3.0 - lwx_gtk3u_webview-3.0 -lwx_gtk3u_html-3.0 -lwx_gtk3u_qa-3.0 -lwx_gtk3u_adv-3.0 -lwx_gtk3u_core-3.0 -lwx_baseu_xml-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 -L/ usr/lib64/vtk -lvtkHybrid -lvtkImaging -lvtkIO -lvtkGraphics -lvtkFiltering - lvtkCommon -lfreetype -lGLU -lGL -lpthread -lX11 -lz -s /usr/bin/ld: cannot find -lvtkHybrid /usr/bin/ld: cannot find -lvtkImaging /usr/bin/ld: cannot find -lvtkIO /usr/bin/ld: cannot find -lvtkGraphics /usr/bin/ld: cannot find -lvtkFiltering /usr/bin/ld: cannot find -lvtkCommon collect2: error: ld returned 1 exit status Makefile:165: recipe for target 'loch' failed make: *** [loch] Error 1 ==== Installed vtk packages: bgee  ~  Installs  therion-5.4.1  loch  rpm -qa | grep vtk vtk-python-6.3.0-11.fc25.x86_64 vtk-java-6.3.0-11.fc25.x86_64 vtk-tcl-6.3.0-11.fc25.x86_64 vtk-6.3.0-11.fc25.x86_64 vtk-qt-tcl-6.3.0-11.fc25.x86_64 vtk-devel-6.3.0-11.fc25.x86_64 vtk-qt-6.3.0-11.fc25.x86_64 vtk-qt-python-6.3.0-11.fc25.x86_64

2 6

Question/Problem with customizing text labels
by Torsten Schnitter 21 May '17

21 May '17

Hi all I have a question concerning customizing text labels. Drawing a map with scale 1:250 is ok. Just some points a very small on the map. Therefore I would like to resize these points and make them bigger. For example: "point x y passage-height -value [- 10 m]" generates the wanted symbol, a number with a frame around. But it's to small (attached picture passage-height-1.jpg). I add the option "-scale xl". Now it's a little bit bigger but still to small (attached picture passage-height-2.jpg). Finally I use within the layout command: code metapost fonts_setup(6,8,10,14,36); endcode Now the number is looking good in size but the frame around is not correct anymore (attached picture passage-height-3.jpg). Is there a solution for this problem? Or is there any other option to resize single points or lines (like "point passage-heigt" or "line label" ...)? I'm looking forward for any help. Thanks, Torsten

6 12

Re: [Therion] same color for several scraps
by Martin Sluka 26 Apr '17

26 Apr '17

That is a bit problem, because Therion is not able in any way to calculate correct vertical position of scraps. It is theoretically impossible. Correct way could be to define another map from scraps which are above and other map from scraps which a below: map all.map -projection plan above.map break below.map endmap You may define as many different maps as you need in your project and select the proper one in the thconfig. m.s. On Apr 26, 2017, at 04:07 PM, Philippe Vernant <phil.vernant(a)gmail.com> wrote: Thanks guys, I’m just using the automatic color set up for map as suggested by Martin. Now I have another question. I have a file like that: map map1 -projection plan scrap1 scrap2 scrap3 endmap map map2 -projection plan scrap4 scrap5 scrap6 endmap On the plot with map1 et map2 the map2 scraps that should be blow the scraps of map1 are above. Do I have to look for something wrong in my scraps, or is it that therion compute an average altitude for map1 and map2 and lay all the scraps based on this average elevation rather that the average elevation of each scraps ? Thanks, Phil On 26 Apr 2017, at 9:10 AM, Martin Sluka via Therion <therion(a)speleo.sk> wrote: 26. 4. 2017 v 2:08, Olly Betts via Therion <therion(a)speleo.sk>: Removed map colour option. It should be defined in layout, not source files. But it doesn’t allow to choose color for particular map! Martin _______________________________________________ Therion mailing list Therion(a)speleo.sk https://mailman.speleo.sk/listinfo/therion

2 1

same color for several scraps
by Philippe Vernant 26 Apr '17

26 Apr '17

Hi guys, I’m trying the option [color] or [colour] to specify the same color for different scraps and it is not working. I have therion 5.4.0 compiled on Mac OS. Here what I use : map m1p -projection plan -color [0 70 0] baign-p1 baign-p2 pend-p1 gphal-p2 gphal-p4 gphal-p3 endmap end the error message is : therion: error -- maplist.th [3] -- unknown option -- -color Any clue ? Thanks, Phil

4 6

combining several lox files
by Graham Mullan 21 Apr '17

21 Apr '17

Benedikt Hallinger said: " the last problem now is, that the surface lox is in a different coordinate system than the caves (EPSG:31468 vs. lat-long) :/ I hoped loch would recognize this and recalculate as appropriate, but that was not the case. Is there some option to convert conveniently?" I have never used Lat/Long but I do have a quite extensive data set that uses two different EPSG numbers, one UTM - and I think there's an IOS or two in there somewhere but cannot find them quickly - and this has generated a lox file that seems to have put everything in the right places. I have only ever seen "computer says no" messages when there have been sections where the co-ordinate system had not been specified at all. I'd be wary about stating the cs in your thconfig file as that will clash if a different cs has been used elsewhere in the data set, I think. Graham

2 1