June 2019 - Therion

TerrainTool
by Graham Mullan 28 Jun '19

28 Jun '19

Mike McCombe's TerrainTool has been fixed and is available again from http://www.ubss.org.uk/terraintool/terraintool.php Download and enjoy. It may not use the latest data but it remains the most straightforward way of adding topographic detail to Therion 3D models. Graham

8 30

BreakOut 3D cave viewer
by Bill Gee 26 Jun '19

26 Jun '19

Hello everyone - I attended the NSS annual convention in Cookeville, TN last week. There was a very interesting presentation on a 3D cave viewing software that might be interesting to this group. The web site is https://breakoutcavesurvey.com The program is pure Java, so it requires a Java Runtime Environment of some kind. The whole thing is just one .jar file. The demonstration was on a Mac laptop. It starts on my desktop running Fedora 30, but gives an OpenGL error on my laptop. There are probably some missing libraries of some kind. The developer said that it will run on Windows. The viewer knows how to deal with Compass and Walls files. Therion can output a Compass PLT file, so should be able to feed Breakout. I have not tried this yet. -- Bill Gee

3 3

Re: [Therion] Different Color for Rocks?
by Max D 25 Jun '19

25 Jun '19

> On 24. Jun 2019, at 12:00, therion-request(a)speleo.sk wrote: > > BTW, what is the PDF viewer the screenshot from you sent? It is Apple default "Preview" (PDFKit). Bruce, thanks for the Pointer! --max

2 1

Different Color for Rocks?
by Max D 24 Jun '19

24 Jun '19

Currently if I have a closed `rock-border` the contents (the rock) will be drawn slightly darker than the passage fill due to transparency and this area being painted twice - see http://filez.foxel.org/e817c23fd65d Is it possible to fill rocks with an other color than the passage fill color? Best regards --max

3 2

Using 3d Scan Data To Create A Map
by Nick Bairstow 20 Jun '19

20 Jun '19

Hi, Something a bit different for the clever people out there. I have been playing with some 3d scan data and have attempted to use it to create a Therion map. Firstly we put created an outline of the cave passage using point cloud software and exported as dxf. I turned the dxf into a background sketch and drew around it and could output a nice pdf of our cave. Also did a manual scaling. So far so good. I added a dummy station and gave it entrance coordinates, then exported as a KML model. When I open the output file Google Earth fly's to the correct spot and shows a pin with the cave name but no cave. My question is , does this fail because we have no survey data, centreline etc and it is impossible to do this or am I missing something. As an alternative I can export to an esri shp file and run that though Qgis and get what I want but as I am going to attempt to combine the 3 scan data with a several normal disto surveys I would like to see Therion Kml output work if possible to save lots of messing around. (GIS makes my head hurt) On a side note using the point cloud software I can slice though the scan data on different planes and pick up lots of detail, rocks and boulders etc. Using the dxf/background image method I should be able to get a very accurate representation of the passage. I can hear you all saying what the hell is he doing that for when he could just survey the cave in the normal way! Well the cave is a show cave and absolutely rammed with metal walkways and cables. Disto tests showed wild inaccuracy's so it was looking like the only viable option was going to be to use a Total Station device which we don't have. We then had a very kind offer to scan the cave, this has proved to be very interesting but drawing a normal map is a bit of a challenge although it seems not impossible. Any help would be appreciated. Nick

5 9

code for Map layout
by Bruce Mutton 10 Jun '19

10 Jun '19

Hi Omri These files are part of my ‘new project’ template, so they rea ready to go, as is (provided you have a similar folder layout to what I use). For me a project is usually a catchment or small caving region. Of course within that there are individual caves, so these files are more or less ‘one for each cave’. Except for the zipped files, which are ‘one for the project’. The only change I make when I bring these into use is to find and replace each instance of ‘NameOfCave’ and change it to whatever the ‘shortcode’ name of the cave or catchment is. ie only the thconfig file. All of these layout files are referenced (input) in the thconfig file. >From then on, any of the layout definitions can be invoked at will (using copy statement). So it is more like your second statement below. In case you are interested, I have included a default project readme file. It is an attempt to ensure all contributors to a particular mapping project are pulling the donkey (all of the donkeys) in the same direction. The data arrangement suggested is the only one that ticks all of the boxes for me, but it is far from universally accepted outside my circle of influence. Other arrangements are perfectly valid. Bruce From: עמרי גסטר <omrigas(a)gmail.com> Sent: Tuesday, 11 June 2019 06:27 To: bruce(a)tomo.co.nz Subject: Re: [Therion] code for Map layout I need to separate each layout to a different file and then call it with the copy command right? or can I specify the file name and then call a specific layout from the file? On Mon, Jun 10, 2019 at 12:18 AM Bruce Mutton <bruce(a)tomo.co.nz <mailto:bruce@tomo.co.nz> > wrote: Omri Here is how I do it. My aim is to have it modular and flexible, so it is easy to get many types of pdf output from the same project, either simultaneously or with minimal easy edits between compiles. Refer attached. Quite a lot of experimental noise in there, particularly in LayoutStandards.thc, but you should find something of use. Some probably outdated explanatory information here https://therion.speleo.sk/wiki/templates And here https://therion.speleo.sk/wiki/bds Bruce

1 0

code for Map layout
by עמרי גסטר 10 Jun '19

10 Jun '19

Hello everyone, does any one have a code for map layout that I can use on my projects? I would be glad to see examples from more experience users Omri --

2 2

Problem with aligning point symbols that have an orientation set - due to definition transformation order
by Bruce Mutton 01 Jun '19

01 Jun '19

I have just spent some time to understand the positioning of point symbols, with regard to metapost definitions and the alignment offsets, and have written up my insights by adding to this wiki section https://therion.speleo.sk/wiki/metapost#symbol_sizing_and_positioning Thanks to the two Martins for helping me along this path. In the process of achieving understanding, I unearthed a problem that has occasionally plagued me over the previous 10 years. Before now I could never get the pattern or a hint of what the cause may be. But now I have it! An example with the air-draught symbol to demonstrate. I have chosen it because it is long and skinny and also highlights a minor problem with 'tight' aligning of such symbols; with half width of 0.2u and half height of 1.0u. The definition of the symbol includes matching alignment offsets of U: = 0.2u and 1.0u, and starts like this. def p_airdraught_UIS (expr pos,theta,sc,al)= U:=(.2u,u); T:=identity aligned al rotated theta scaled 1 shifted pos; Like almost all built-in Therion metapost symbols, the T: function first aligns the symbol, then rotates it. For orthogonal rotations at least, the alignments are very nicely matched to the insertion point, but not so much for non-orthogonal rotations. This is the relatively minor problem. The bigger problem is that for -orientations much different to zero, then alignments are inappropriately rotated as well! In the example SymbolAirdraughtAlignedTHENRotated.png attached, -align right manifests as -align left, and -align bottom-right manifests as -align top-left once the -orientation is much more than 45 degrees. A situation that has resulted in uncomfortable drawing hacks on my part on more than one occasion. On both attached images the cross hair intersection is the insertion point of the symbol, and the layout used includes a rotation of 15 degrees, to highlight the differences between not specifying a symbol orientation, and specifying an -orientation of zero and 180 degrees. So I wondered what would happen if I changed the order of the transformation? ie def p_airdraught_UIS (expr pos,theta,sc,al)= U:=(.2u,u); T:=identity rotated theta aligned al scaled 1 shifted pos; And the answer is, the alignments entered by the user are properly honoured! With both methods, there is a problem aligning long narrow symbols that are also rotated. I think this can be compensated for by stretching out the smaller U: component a little. Say, instead of U:=(.2u,u); Make it more like U:=(.4u,u); So the question. Is there an appetite for changing the order of transformation for almost all of Therion's metapost point symbols? It will affect a number of existing projects, but only materially where point symbols with an orientation greater than 45 degrees off 0 degrees (or 360) and a non-centred alignment are used. These are probably limited to points entrance, air-draught, passage ends, gradients (maybe), water-flow, spring, sink, and possibly any point labels that have been aligned with these. Unless anyone can come up with any more unpleasant side effects, I would vote for change. Bruce

1 0