- Therion - speleo.sk

Problem in 3D model
by Gilbert Fernandes (mailinglist) 24 Jan '08

24 Jan '08

Hello, I notice a bug in the 3D modeling. In this short exemple you can reproduce the error. The main problem is when you have a pit, ans so a vertical survey ( compas = 90 or -90 ), the up and down value in survey data is used in the 3D model (.lox file) for the with of the pit and not for the hight (or down) of the galery. So pits are always as fat as they are hight. Look the .th file and try to change the up and down value as comment in the exemple, look the effect in the 3D view. Thanks, Gilbert encoding utf-8 source pinee1.th export model -o pinee_3D.lox

2 1

Calculating Magnetic Declination
by David A. Riggs 24 Jan '08

24 Jan '08

I just spent far too long trying to get automatic calculation of magnetic declination to work, and I'm posting my findings so that others don't make the same mistake, and so that therion (an already great piece of software) can be improved accordingly. I've found that... Specifying the fixed coordinate before the coordinate system causes therion to silently fail to apply declination. In other words, this is wrong: date 2007.06.31 fix A0 626333 4320333 2620 cs UTM17 Specifying the coordinate system before the fixed coordinate causes therion to properly calculate magnetic declination. This is correct: date 2007.06.31 cs UTM17 fix A0 626333 4320333 2620 Therion 0.5.1 does this completely silently, with no notification that declination has been applied at all. Therion 0.5.0 prints the following (rather confusing) message in therion.log: output coordinate system: EPSG:32617 meridian convergence (deg): -0.9190 geomag declinations (deg): 2007.1.1 -8.9944 2008.1.1 -9.0224 My recommendations are that therion should: - Ignore the order of 'cs' and 'fix', apply declination as long as both are included - Explicitly state that declination has or has not been applied, regardless of configuration, so users are aware of this - Emit a warning if partially or incorrectly configured for magnetic declination calculation Thanks very much! Dave Riggs Morgantown, WV -- David A. Riggs <david.a.riggs(a)gmail.com>

2 1

long lines
by Wolfgang Zillig 14 Jan '08

14 Jan '08

Hi, what is the limit in line length? My elevation model hits that limit (it was just a test with interpolated data, so nothing that really bothers me). The question is out of interest only. C:\Program Files\Therion\therion.exe: error -- AHS.th [12] -- line too long Regards Wolfgang

2 1

therion 0.5.1 uploaded to Debian
by Wookey 04 Jan '08

04 Jan '08

I finally got round to uploading the work I did in January to Debian proper. So there is now a current Therion in unstable as well as experimental, and the various long-standing bugs are fixed. The new packages use texlive instead of tetex, as Debian has transitioned to these, and the wiki docs are included in the therion-docs package (that's currently the wiki docs as of about a year ago. I'll update those too shortly). The package now appears in Applications/Science/Geoscience in line with current menu policy (I'll do an update of Survex with this property too soon). You can see current package status here: http://packages.qa.debian.org/t/therion.html and build logs here: http://buildd.debian.org/pkg.cgi?pkg=therion Please try them out if you can and report any problems. I've included the current debian diff below in case Stacho wishes to include any of it upstream (I'm afraid I've trampled all over your nice multiplatform build stuff stacho, but a few bits of the diff are probably worth incorporating upstream). This has raised a few issues worthy of note. 1) 64-bit loch Wolfgang Zillig reported in April that he couldn't get loch to work on his AMD64 box. It doesn't work on mine either. I'll post more details in that thread. 2) gcc warnings The therion code generates hundreds of warnings if you do a build with default gcc4.2.2 like this: thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' thdataleg.h:141: warning: deprecated conversion from string constant to 'char*' I've worked around that for now using -Wno-write-strings but I think the correct fix is to use const in the function prototypes to match the declarations. You can see a log of the full set of whinges here if someone wants to go through them: http://buildd.debian.org/fetch.cgi?pkg=therion;ver=0.5.0-2;arch=ia64;stamp=… The gcc docs suggest that -Wno-deprecated should also stop these warnings, but that doesn;t seem to work. Not sure if I was just having finger trouble/too much beer over xmas there, but it really didn't seem to stop them all. 3) New sample data I had a bit of trouble building this, so it's not in the current package, but I've worked it out now (paths and dependencies was the issue) and so will integrate it into the docs package on the next upload. It's a nice piece of work. Is this intended to replace the wiki docs eventually? 4) tcl version. Does Therion care if tcl 8.4 or 8.5 is used? I've left it defaulting 8.4 for now, but I guess 8.5 would work and would be preferred? A quick test suggests that it works fine. 5) library linkages: The shared-library analyser points out that we link to all the wxgtk libs but only actually use some of them. This is wrong. dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_xrc-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_qa-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_gtk2u_adv-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_baseu_xml-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libwx_baseu_net-2.6.so.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libvtkImaging.so.5.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libvtkIO.so.5.0 (it uses none of its symbols). dpkg-shlibdeps: warning: debian/therion-viewer/usr/bin/loch shouldn't be linked with libz.so.1 (it uses none of its symbols). I think the reason is that the build uses: $(shell wx-config --libs --gl-libs) to list the wx libs so gets all of them. I haven't fixed this yet as I'm not sure what the best fix is. Should we just list the libs that actually are used, or is there a way to use wx-config to DTRT? 6) No desktop files Therion doesn't appear to have any desktop files so it doesn't appear in the main menus of xfce/gnome/kde. Anyone done any, or care to do some? Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/

3 7

Metapost and user attributes
by Xavier Pennec 23 Dec '07

23 Dec '07

Dear all, I have a survey with lots of sections (which are on another map than the plan and the elevation, see attached files NaduelFilonCerisiersPlan.pdf and NaduelRD8_sections.pdf) and I would like to add automatically a label numbering each section at the end of the section line in the plan. As I want to be able not to display the section lines AND the their numbers when I inlcude that survey into the larger map, I thought that adding a user attribute to the section line would be the right way. Thus, I used a user attribute called label in my th2 file: line section -reverse on -direction both -attr label "one" 312.0 327.0 334.09 327.0 396.0 327.0 425.0 327.0 endline and I redefined the section line metapost command into in my layout: code metapost def l_section (expr P)(text txt) = T:=identity; path Q; Q = punked P; pickup PenC; for t = 0 upto length P - 1: pair zz[]; zz1 := point t of P; zz2 := point t+1 of P; zz3 := postcontrol t of P; zz4 := precontrol t+1 of P; if (length(zz3-1/3[zz1,zz2]) > 0.1pt) or (length(zz4-2/3[zz1,zz2]) > 0.1pt): zz5 = whatever[zz1,zz2]; (zz3-zz5) = whatever * (zz1-zz2) rotated 90; draw zz1--zz5; zz6 = whatever[zz1,zz2]; (zz4-zz6) = whatever * (zz1-zz2) rotated 90; draw zz2--zz6; else: draw zz1--zz2; fi; endfor; for pnt=txt: if pnt=-1: else: T:=identity rotated angle(thdir(Q,pnt)) shifted (point pnt of Q); pickup PenC; thdraw (0,0)--(0,.8u); thdraw (-.1u,.55u)--(0,.8u)--(.1u,.55u); if known ATTR_label: p_label( ATTR_label, (point pnt of Q), 0, 5); fi; fi; exitif pnt=-1; endfor; enddef; endcode The file NaduelRD5_plan.pdf is an example on what it gives. With that solution, I have two problems: - the first one is that is I change -attr label "one" with -attr label "1" then metapost crashes because ATTR_label is intrepreted in that case as a known numeric and not as a string. - the second problem is how to give an offset to the label so that it is actually above and below the lines? If there is any metapost guru that can help, I'll appreciate. Xavier PS: there would be another solution to my problem, which would be to put sections and their labels in separate scraps, simulating different layers as in gimp, and not to include these scraps into the large map. However, to define properly a scrap as a layer of another one, it would be needed to deform both scarps exactly in the same way, which is not the case right now if some reference survey station is moved in one scrap only. Thus, I would imagine that a bettre solution would be a special type of layer scrap where the geometry is copied from another (e.g. something like scrap scrap2_layer2 -copy scrap2). Is that something feasible?

2 1

declination
by Wolfgang Zillig 20 Dec '07

20 Dec '07

Hi, I've just changed one input file from survex format to therion format to get the LRUD data into the model. The declination is corrected manually by "declination xx degree" within the centreline. I've noticed that I had to change the prefix from "-" (minus) to "+" to get the same result as with survex. In survex it is done by "*calibrate declination xx". It would be nice to add a comment in the Therion book that declination correction is opposite from Survex. Regards Wolfgang

2 1

Preview above / below
by Cooper, Ben 19 Dec '07

19 Dec '07

Has something changed with preview above / below since 0.5.0? My thconfig files that used to produce grey outline now produce nothing. I've gone back to my original sources from September, and re-built them using the current snapshot only to find that nothing is produced. See attached. The pdf files were created using the thconfig file attached. I've also included my main source file, UpperFlood.th, which defines the map Outline_m2500 containing the preview above and below commands. I've always found the description of preview above / below very difficult to understand in The Book. For example, I've found that I have to put a scrap reference into map Outline_m2500 before the preview above command, otherwise I get the error "incompatible map projection". Any help appreciated. Regards, - Ben

4 4

XVI scale
by Cooper, Ben 16 Dec '07

16 Dec '07

Has there been a change to the XVI scaling? I regenerate XVI files whenever I re-compile my survey, but I've noticed recently that they no longer fit some of my older scraps, where I use XVI as the base image for drawing over. They appear to be 10 or 20% smaller than before. How can I enlarge them without re-drawing all of my scraps? - Ben

1 1

Drawing rigging
by Hilary Greaves 14 Dec '07

14 Dec '07

Hi folks, I am trying to draw rigging on my elevation in the usual way, i.e. black dots for bolts and lines down pitches to indicate where the rope hangs. In Therion, "rope" seems (oddly?) to be a point symbol (allowing the user to place a small pretty picture of a backed up belay anywhere on the survey he chooses), rather than a line; further, there doesn't seem to be any existing line symbol that will naturally do the trick. (Also, there doesn't seem to be any natural way of user-defining a suitable line symbol, since lines are oriented and ropes shouldn't be.) Is there a standard way of doing this? Thanks for any tips! Hilary.

6 6

Elevation Projected Direction? (and creation from Extended Elevations)
by Bruce Mutton 14 Dec '07

14 Dec '07

Hi, I seem to have acquired more of a Therion mindset, and drawing plans is going quite well. Just trying to get the elevations sorted, and perhaps I'm trying too much at once. Using Therion 0.5.2. Have roughed up an extended elevation based on a scanned sketch (of a projected elevation - the passage runs more or less from north to south, and descends at about 30 deg, as surveyed). I notice I had to add an 'extend left' to the centreline data to stop the passage plotting upside down and sort of inside out. (although interior of passage was correctly rendered) I assume that this approach is the correct way to address this issue?? The extended elevation looks more or less OK, vertical lines a little slanting, no doubt due to the distortion caused by foreshortening as the survey legs range diagonally from side to side across the wide passage. I guess I should adjust my survey technique! The code below produces the map. export map -projection extended -layout ThisCaveMapLayout \ -output ./Maps/SystemExtendedElev.pdf -fmt pdf Now here's where I thought I'd cheat, to get a projected elevation from the same sketch. I copied my extended elevation.th2 file and renamed it projected elevation.th2, then edited it to change the scrap name and projection type from extended to elevation. (It's not too different in concept to redrawing it manually in another file, where the passage is fairly straight and runs perpendicular to the desired projection direction) The trouble is, this always plots as though it is extended (dashed horizontal grid, no vertical grids) but with an obvious projection (of 000 deg- assuming 0 deg means looking towards the north(?)) that does not change regardless of the bearing provided in the export command. In other words it's partially working. For example the code I used is below. export map -projection [elevation 270 deg] -layout ThisCaveMapLayout \ -output ./Maps/SystemElev.pdf -fmt pdf (I have tried similar code for single surveys, individual caves and cave system levels of detail with the same result) These lines are all in the same thconfig file, and I had a few issues with map structure as interpreted by the Therion compiler window, until I realised that Therion seems to determine the hierarchy based in part on the map titles. Duplicate map titles seem to create trouble! I realise there is not enough information here to properly assess, but is there something fundamental I'm doing wrong? When I just had centreline data the projected elevations seemed to work OK for any direction. Any hints or comments appreciated. Bruce

2 2