July 2013 - Therion

Compiling Therion projects from Notepad++
by Footleg 08 Jan '15

08 Jan '15

I find having multiple thconfig files open so I can compile different parts of my large cave system project very useful. So I was investgating how to run Therion from Notepad++ (my preferred text editor). This is how I got it working: I wrote a 2 line batch file containing these commands: cd %1 "C:\Program Files (x86)\Therion\therion.exe" %2 Saved to somewhere on disk, and then call it from Notepad++ using the Run command, as follows: On the Run menu in Notepad++, Select the 'Run' item, and enter the command as follows: "C:\Personal\Caving\Therion\compileTherion.bat" "$(CURRENT_DIRECTORY)" "$(FILE_NAME)" (But using the path to where you saved your batch file). Save the command (I called it 'Compile Therion' and gave it the shortcut CTRL+T). Now with any thconfig file open in a tab in Notepad++, I can compile that project by pressing CTRL+T, or by selecting 'Compile Therion' from the Run menu. You can create multiple thconfig files in the same folder on Windows, by giving them any filename you want with the extension .thc or give them no extension at all. That way all the files will be listed in the 'Open File' dialog from the compile tab in xTherion. Next I'll see if I can get my batch file to open the output PDF automatically in Foxit Reader :) But that will be less general because I need to pick a PDF filename which can vary between my thconfig files. Footleg

3 6

5.3.11
by Stacho Mudrak 06 Oct '13

06 Oct '13

Hello everybody, I have just uploaded version 5.3.11. Here is the list of changes: therion: * added -survey option for map for setting survey associated with map. For example all surveying statistics from this survey will be used, when this map is selected for output. * added sketch-colors <number-of-colors> option to thconfig file, to reduce size of sketch bitmap images in maps * hide symbol from legend, if it has explicitly empty translation * survey-level works for point station-name labels, if station name is automatically determined (no -text is specified) * symbol-show|hide group text for point label, remark, date and line label * grid-angle <value> <units> - can be used in centerline to specify magnetic grid angle (declination against grid north). * -cs output specification works for export cave-list (including lat-long) * dates are shown using OS locale settings in map export * layout statistics explo/topo-length on/hide/off -- if it is off, team members are sorted alphabetically * KML export format supported for cave-list and continuation-list * bugs fixed: - PLT export in output coordinate system - context point air-draught not working - instrument position in centerline does not work - debug scrap-names crashes if empty scraps - counter not working in centerline data diving - revise not working outside of survey context - wrong length/depth and other statistics calculation for map output - sketch bitmaps inserted multiple times in PDF files xtherion: * bugs fixed: - new file in xtherion works, even if file is already open Merry Christmas :) S.

5 9

image missing and import error
by Andrew Atkinson 13 Sep '13

13 Sep '13

Hello I have just upgraded to debian jessie which comes with Therion 5.3.10 When opening a th2 file I find that all my background images are not visable, also not listed in the background images on the right hand side So in a new file I try importing a jpg, one I have done before, it gives an error, the log of which is attached, as is the th2 file it produces, which looks okay at a quick glance. I also tried a .top text file import, again that I have successfully done before, with the same result, the xvi is produced. Trying importing an xvi it looks like the same error Suspect this is a debian bug, as no one else has complained so will file a report after this thanks Andrew

3 5

Error 768
by Andrew Atkinson 06 Sep '13

06 Sep '13

Hello Debian wheezy. Therion 5.3.9 and 5.3.10 First some history. I was using 5.3.9, but last weekend I was running a course in Wales so needed the OSGB:SN which is added to 5.3.10. So to achieve this built 5.3.10 from source as 5.3.10 is not in wheezy due to the freeze. So when producing a pdf I get the Error 768, log attached, everything else I do seems to work as normal Wookey was there to help, so also tried installing 5.3.10 from .deb and then 5.3.9 from the .deb, both with the same error. Now in the error there is the bit that says ! Unable to make mpx file. l.2 btex \mainfont 0 etex The two files given above are one of your source files and an auxiliary file I need to read to find out what your btex..etex blocks mean. If you don't know why I had trouble, try running it manually through MPtoTeX, TeX, and DVItoMP played around with this, but really do not know what I am doing, but it might help me trace the problem. 5.3.10 worked on Wookeys Wheezy machine, so the w/e training could continue, at least. This was generated when running the thconfig file in http://www.cave-registry.org.uk/svn/CheddarCatchment/Reservoir/ Thanks Andrew

3 6

Topparser response
by Bruce 05 Aug '13

05 Aug '13

Andrew Thanks for those revised input/output file instructions - makes perfect sense now. >> Perhaps the plan and elevation scraps should be forced (or at least >> have the option)to inherit the map suffixes entered on the Data TAB >> (and then the specific plan, elevation and section suffixes entered on >> the plan and elevation TABs). >> >> This would ensure better consistency and ready recognition by the >> human user of the relationship of particular scraps - maps - files. >Sorry not sure what you mean, do you mean that they all should be NewPassageSuffix. >Can you give an example, this is different from what I do The approach I am trying to enforce is that each object inherits the name of it's parent, and any suffixes that might have been appended to the parent (or grandparent). Also that each object name describes quite explicitly and unambiguously what it contains (but not overly verbose). Pretty close to what Topparser encourages already. eg Survey name: 404-Quackery Associated maps are therefore named; 404-QuackeryPlan 404-QuackeryElevEXT 404-QuackeryElev290 Etc Topparser encourages this at present. (A somewhat unrelated observation: Maps do not need to be children of the surveys they are based on, but the way Topparser currently creates them they are. Therion does allow them to be outside of the 'survey' 'endsurvey' block, and indeed outside of the survey.th file altogether. This is another topic however, but it could add complexity to Topparser in due course. For now it is easy enough for the user to move the map definitions to another file if they so wish.) Children of the maps (scraps) are therefore named; 404-QuackeryPlan-s1, 404-QuackeryPlan-x1 404-QuackeryElevEXT-s1, 404-QuackeryElevEXT-xp1, 404-QuackeryElevEXT-xv1 All the above can be achieved with Topparser at present, but you have to duplicate part of the suffix as in these screen dumps. The current implementation cannot mimic the type of inheritance I would like for projected elevations however; 404-QuackeryElev290-s1 is what I would like, but; The above produces; 404-QuakeryElev-s290_1 which is at odds with the rest of the object naming. So in summary, Topparser in general allows scraps that are not named the same as the th2 file they are inside of. While this might allow for more abbreviated scrap names it is not what the Therion wiki recommends (sure I've seen it somewhere :) ). This can be compensated for as in the examples above in all cases except for projected elevations. A minor thing that is easy for the user to overwrite each time - but worth considering. Bruce

3 23

file.sql format
by Andrew Atkinson 03 Aug '13

03 Aug '13

Hello I have just been playing with the export database part of Therion again. The file outputted was imported into some application fine, but most would not work phpMyAdmin being one of the ones that I could not import with and the one that my ISP forces me to use. phpMyAdmin was giving the error #1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TRANSACTION' at line 1 After a bit of searching I found this http://dev.mysql.com/doc/refman/5.0/en/commit.html (there is a similar page for MySQL4 and 3.23 that seem to say the same) So editing the exported file first line from begin transaction; to begin; and last line from commit transaction; to commit; then it worked Not sure if this is a bug or my lack of understanding of the .sql file format Andrew

4 3

Re: [Therion] TopParser
by Graham Mullan 28 Jul '13

28 Jul '13

Bruce Apologies if the instructions don't make full sense. I wrote them as a user, having had the program tried out on me by Andrew. The 'input' folder is simply that, it's where the Pocket Topo file that you want to use currently resides. In our usage, it tends to be the folder on the SD card taken from the PDA and put into the PC. The output folder is where you want the files to go, within the files structure that you have created for your project. If that makes sense, or doesn't, let us know & I will clarig=fy the instructions accordingly. Graham

3 2

Topparser
by Bruce 28 Jul '13

28 Jul '13

Discovered Andrew's Topparser (https://bitbucket.org/AndrewA/topparser/overview) yesterday. A very nice concept - almost one click conversion from Pocket Topo to Therion. Great for saving time and ensuring consistency of file structure. It creates a survey file with map definitions and drawing files with xvi, backgrounds and empty scraps for each projection and section that was drawn using PocketTopo. It also creates a thconfig and runs it, and looks like it will open the output and send it to a svn, mercurial or git repository. I could not get it to run therion automatically (crashes apparently due to the empty scraps - which btw I thought was fixed in 5.3.11) but if I commented out the maps (ie hide the empty scraps from Therion) the files Topparser created compiled perfectly. A number of features don't seem to have been finished yet, but seems quite usable as it is. The first data I ran through it came up with this anomaly. data normal from to tape compass clino ignoreall #401.4 401.5 3.15 0.38 12.72 #401.4 401.5 3.16 358.96 13.71 #401.4 401.5 3.16 0.04 12.68 401.4 401.5 3.157 119.79 13.04 Calculated leg from 3 above Ie does not average bearings correctly either side of north. I was using the 1.2.0 download, but I infer from the last commit message that Andrew might have fixed this. The instructions all make sense to a Therion user, except that I still have not really figured out the so called input and output folders. The instructions are not particularly explicit and the screenshot of folder structure does not appear to match the screenshot of the data entry on page 1. Minor quibbles. I think this is worth developing further. Bruce

2 2

Loch passage tube behaviour
by Bruce 23 Jul '13

23 Jul '13

Footleg I think the answer is 'yes'. Hopefully you can view the images embedded in the image rather than attached, otherwise this won't make much sense. In this example there is a single centreline (comprising both cave and surface survey) and 4 scraps. A short section of cave at the left hand end does not have any scrap drawn. Compiled with Therion 5.3.11 One interesting point is that regardless of the 'walls' setting, there is never a tube generated there once we have scraps drawn anywhere in this centreline. My deduction is that Loch uses only one type of tube generation per centreline, because in almost all my larger projects that transition between traditional survey and paperless survey, I have a combination of each type of tube generation within the same Loch model. This fits with the description in the Therion Book "walls <auto/on/off> turn on/off passage shape generation from LRUD data for subsequent shots. If set auto, passage is generated only if there is no scrap referencing given centreline." In these examples I have not used any 'point passage-height' or 'point dimensions' in the scraps. Paperless survey (no LRUD), walls auto, off or on (or not specified), No plan scraps. [Loch always guesses tube dimensions] -same if LRUD present and walls off Paperless survey (no LRUD), walls auto, off or on (or not specified), plan scraps drawn [Loch uses scraps for tube width and guesses tube height] Now, I added a few LRUD to the same centreline, including some with only UD data dimensions station left right up down 1.4 - - 20 20 1.5 - - 20 20 1.6 2 2 20 20 3.13 10 10 20 20 3.14 10 10 20 20 Tube generation, where it occurs extends one station beyond those specified. Paperless survey (some LRUD), walls on or auto (or not specified), No plan scraps. [Loch uses LRUD for tube dimensions and only for stations where partial data is provided, it guesses the missing data ie if a station has no data, no tube is generated] And now adding some scraps and things get interesting. Paperless survey (some LRUD), walls off (or not specified), Plan scraps drawn. [Loch uses scraps, not LR, for tube plan dimensions, and UD for height where specified, otherwise height is guessed. Where there are no scraps, LRUD is not used.] That is perhaps contrary to what one might expect from the Therion Book 'walls' entry. It also produces perhaps the best model. Paperless survey (some LRUD), walls on or auto, Plan scraps drawn. [Loch uses scraps AND LR for tube plan dimensions, and UD for height where specified, otherwise height is guessed. Where there is no LR, then it is guessed. Where there are no scraps, LRUD is used.] If I change the LRUD definition like this. data dimensions station up down 1.4 20 20 1.5 20 20 1.6 20 20 data dimensions station left right up down 3.13 10 10 20 20 3.14 10 10 20 20 ..then the guessed width troubles continue. Paperless survey (some LRUD), walls on or auto, Plan scraps drawn. [same as above] So my final conclusion, for paperless survey, no need to include walls statements in each survey, or if you do, walls off is better than on or auto. If you happen to provide some UD data, then your model will be improved (more realistic). I surmise that with these same settings, scraps with point passage-height or point dimensions will have a similar effect, but I have not tested this. Bruce

3 3

Re: [Therion] Options for converting splays in my Cave Converter tool
by Graham Mullan 22 Jul '13

22 Jul '13

I agree with Andrew and Martin. Splays are a different - and in my view more useful - form of data from LRUD. Keep them as splays. One or twice (in Therion) I have needed to convert a splay to a leg, but that is a highly selective process and not for a conversion tool. Graham -- graham.mullan(a)coly.org.uk

1 0