November 2019 - Therion

Re: [Therion] Point altitude/deph, Help !
by Xavier Robert 28 Jun '22

28 Jun '22

Hi all, I think I have found a trick. The other Xavier led me to the right tracks, thanks a lot ! Finally, this is quite simple with the point altitude, and no need to change anything inside the : - If we use the point altitude only with the option -align, we get the altitude - If we use the point altitude with the options -align and -value [-1004 m] where 1004 is the altitude of the main entrance, we print the depth only for that point (Do not forget the " - " before the altitude of the main entrance), and thus, we do not erase the classic point altitude. The only (small) limits are : * If the main entrance changes, we need to manually update ALL the points that print the depth. But that should not be be everyday, and not a big issue to do that. * the symbology of the two points is the same. I will have a look for a way to modify that and let you know if I find a trick (If I copy the code of the point Altitude, and call it p_u_depth(expr pos, R, S, A), it crashes...). Cheers, Xav

4 4

How to calculate the volume of a cave
by Bill Gee 31 Jan '22

31 Jan '22

Hello everyone - What tools can be used to calculate the volume of a cave based on center line and LRUD data? I found an email from Martin Sluka from about 4 years ago describing how to use Loch to export a .lox file in other formats, then run that file through CloudCompare or ParaView. The process looks very complex to me, and besides - Loch does not run on my computers, so there is no way for me to generate an export. As far as I can tell, Survex does not have a way to calculate volume. Could it be done with a KML file and Google Earth? -- Bill Gee

8 11

"\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

extend
by Marco Corvi 02 Jun '20

02 Jun '20

i think that extend should take values in the interval [-1,1], ie also fractional values, plus some special value such as "ignore" to open loops, and "undefined" to let the program choose, because it's a nuisance to enter a decimal number for every shot (legs + splays). therion uses the left/right normal/reverse etc. solution, and users should be allowed to set extend also for splays, if they need to. for now, let's use left/right/vert, and ignore only to open loops btw, are vertical extend considered in the computation of the cave length by therion ? marco

5 6

World Magnetic Model
by kevin dixon 28 Feb '20

28 Feb '20

The last Therion release 5.4.3 is dated 01 Feb 2019. There has in recent years been a significant change of the Magnetic North Pole location, less so for the Geomagnetic South Pole: https://ngdc.noaa.gov/geomag/GeomagneticPoles.shtml Given the above, an out of cycle World Geomagnetic Model WMM2015v2 was released 04 Feb 2019. When will this update appear in Survex and Therion ? Thanks, Kevin Dixon

4 4

New symbols
by rsev＠protonmail.com 21 Dec '19

21 Dec '19

Hi, I have create the following 52 new symbols for Therion: Therion symbol set Topodroid symbol group Points: altar EGB anthro archeo-excavation EGB extra audio EGB extra bat EGB extra bone EGB extra curtains UIS extra danger EGB speleo disc-stalactite UIS extra eletric-light EGB anthro ex-voto EGB anthro gate EGB anthro helictites UIS extra human-bone EGB extra masonry EGB anthro minus EGB speleo mud EGB speleo mud-crack EGB extra nameplate EGB anthro pendant EGB extra photo EGB extra pillar-with-curtains UIS extra pillars-with-curtains UIS extra plus EGB speleo plus-minus EGB speleo seed-germination EGB extra stalactite-stalagmite UIS extra stalactites-stalagmites UIS extra tree-trunk EGB extra volcano EGB extra walkway EGB anthro walkway-metalic EGB anthro walkway-soil EGB anthro walkway-stone EGB anthro walkway-wood EGB anthro water-drip EGB speleo Lines: abyss-entrance UIS extra dripline UIS extra fault UIS extra joint UIS extra low-ceiling UIS extra pit-chimney UIS extra walkway EGB anthro walkway-metalic EGB anthro walkway-soil EGB anthro walkway-stone EGB anthro walkway-wood EGB anthro Areas: mud-crack EGB extra pillar UIS extra pillar-with-curtains UIS extra stalactite UIS extra stalactite-stalagmite UIS extra stalagmite UIS extra I would like to offer them to be included in Therion's source code. My suggestion it to incorporate them Therion distributed in 2 symbol sets: the existing UIS one and on a new one to be called EGB. The ones to go to UIS have their images inspired by similar symbols from UIS. The ones to go to EGB are ones that I can't identify some already existing symbol set to receive them so I am proposing a new symbol set named EGB (for Espeleo Grupo de Brasília = Brasilia's Speleo Group, my speleo group) as many of these symbols were demanded by some fellow members of EGB. This is my suggestion but obvioulsy we can choose any other path, for example: - distribue them differently among symbol set's; - incorporate just some of them in Therion's source code; - not incoporate any of them (I would distribute them as stadalone files to be used by the interested parties as user symbols). As I mentioned, we can follow any prefered path. Please let me know if the idea is to incorporate them in Therio's source code, as I would have to adapt them because, right now they are formated as standalone user symbols. Please advise. Regards, Rodrigo Severo P.S.: The "Topodroid symbol group" mentioned on the table above is the symbol group where each symbol resides in Topodroid. I bet this info isn't actually relevant to Therion but I decided to include it for completeness.

8 34

Breaking a loop at a specific station on extended elevation
by Tarquin Wilton-Jones 21 Dec '19

21 Dec '19

Hi folks, There are a few of us who are struggling with an extended elevation problem. I have attached a sample data file, which represents the data from a real cave. There is a main passage (stations 1-2-3-4-5-7), and a high level oxbow (stations 2-6-5). Because the oxbow is shorter, Therion defaults to using that as the primary extended elevation path, which is not desired. The natural (human preferred) way of extending that, is to show the main passage as a single line, then have the high level oxbow split at station 6, with a leg pointing to each of the two stations it connects to, and a dotted line connecting the two versions of station 6. Like this (if your email client shows this with a fixed width font): 6....6 / \ 1--2--3--4--5--7 We tried various "extend left" "extend right" and "extend ignore", and we managed to make it break station 2, but it seems not to want to break on station 6. (We can obviously break it in the right place by breaking the data, but that is not the intention is to keep the data valid.) Can someone please tell us the magic formula of extend commands that will produce the desired output? Thanks for the assistance. Tarquin

5 26

Effect of point symbol alignment, orientation and layout rotation on output symbol alignments
by Bruce Mutton 01 Dec '19

01 Dec '19

OK, here is a little experiment that illustrates the symbol alignment problem, just to prove to myself that there is a problem. I found that my custom entrance symbol does not always plot correctly, but neither do the default Therion symbols. Each scrap contains nine stations, named for the alignment of the coincident point symbols. Each station has a coincident water-flow, flowstone-choke and entrance symbol. There are short bits of passage shown to help with visual orientation. The variables include: * Relative orientation of the scrap drawing compared to north or output orientation (not really explored here, I have taken the simple case of scrap orientation 'up' matches 'north'. I don't believe I have ever noticed any problems associated with scrap drawing orientation - just remember that symbol -align option is relative to the scrap drawing as viewed on your monitor, which in this example is north). * Symbol alignment (c, l, r, tl, t etc) * Symbol orientation ( 000 to 359, although I only explore 000 and 210 here) * Layout rotation ( 000 to 359, although I only explore 000 and 285 here) * Therion default symbols, and symbols I have customised a little I think what the attached show for the three default Therion symbols I have chosen is: * Symbol alignments and layout rotation symbol behaviour is OK where symbol orientations are set to zero (and I assume this is the case where orientations are undefined). * Symbol orientations and layout rotation symbol behaviour is OK, but alignments are the reverse of what they should be where symbol orientations are set to 210 (degrees). ie non-zero symbol orientations always break symbol alignment (although I expect that where orientation is within some other quadrant this may not be the case). I am sure there are some Therion symbols that behave properly (I think labels do), I just did not stumble on them in this experiment. My custom entrance symbol introduces other problems, but that is an issue of my own making, and so not of particular concern. It does suggest there is something that requires fixing, and that a 'Therion symbol design guide' might eventually help people not fall into these traps. Bruce PS: If you want to remove any customisations likely to affect the output from the attached zipped project, in the file LayoutMapThisCave.thc comment out the lines: # copy LayoutColourSymbols # copy LayoutStandard # copy AMERCustomSymbols

1 0

next level therion symbol strategy
by Bruce Mutton 30 Nov '19

30 Nov '19

With the recent discussion and welcome submissions of new symbols, I've been thinking about the various symbol concepts proposed and examples of the last 10 years or so. What interest is there in evolving the Therion symbol family/environment a little bit? I'm thinking small incremental steps, not big or complicated changes. Currently at the local symbol level we have options or properties like: subtype; scale; outline; orientation (rotation); align; place; visibility ; clip. These provide a lot of functionality, and generally work well. But there are things that are missing that I would like to see added to all generic symbols; * We cannot scale line ornamentation (lines accept a scale, but nothing happens, except for behaviour with min-symbol-scale) * We cannot arbitrarily add text to any point symbol (I've sometimes wanted to label anchor, air-draught, speleothem and other point symbols). If we could add a text property to every point symbol, then labelling would be more efficient, and the relative alignment would always be good. This would not replace the dedicated label symbols, just provide more options. * We cannot add a link (hyperlink) property to symbols. I would like every point, line, area symbol to have a link property. These should be able to link to a file system path or to a url. I'm not sure what options there are in the pdf format/viewers to manage the visibility of links on screen while hiding them in printed output. Maybe we just have a global switch that makes them visible or not, and compile two maps - one online and one for hardcopy. * The relationships of the point symbol alignment parameter U: relative to the size and proportions of the symbol are not consistent across all symbols. This affects the distance that the symbol is moved in each direction when an align is specified. There are issues for long skinny symbols like speleothems and water-flow as well. * Align has bugs for some symbols And then there are global switches/conventions that we apply in layouts; min-symbol-scale; symbol-show/hide; symbol-colour; symbol-set, to name a few. Some things that have been proposed at a local symbol level that, that with some global switches, would add useful functionality include: * Automatic hiding of lines and areas that are smaller than a certain threshold. This would complement min-symbol-scale for points (but better suited to lines and areas). An example is described in the wiki https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_sym bols * Creating symbols that are optimised automatically for colour or black and white dependant on whether the user has chosen a switch one way or the other. Colour variables can be created, and complimentary colour schemes could be created to suite each of the symbol groups. Users could customise these if they choose to. An example is described in the wiki https://therion.speleo.sk/wiki/metapost#colour_dependant_visualization_of_sy mbols * Legend box symbols. We need better control of these, as Tarquin has recently suggested <https://www.mail-archive.com/therion@speleo.sk/msg07858.html> . This might also include better symbol aggregation in a single box (ie combining the point, line and area symbol in the same box, or at least not repeating them if the symbols are reasonably similar). If we were to decide some of these are worth aspiring to, then it would require some agreement as to the structure and type of implementation of a typical generic point, line and area. Currently most symbols follow a similar pattern, but I suspect we might see some divergence unless we have a pattern to follow. My metapost and tex skills are definitely limited to 'copy, paste and meddle' so it really needs someone with broader skills to progress this. Some of these suggestions would change the existing behaviour a little, so that is something to consider, with regards to compatibility for existing projects. I don't think the impact would be very big in most cases. Thoughts? Bruce

1 0

New symbols
by Bruce Mutton 30 Nov '19

30 Nov '19

As far as I can see, it's all related to the order you choose to apply the transformations. I used the align before the rotate. If you move the align to be done after the rotate the behaviour changes. Maybe you could test a little bit and propose a better order for the transformations after testing several use cases. Yes, if you swap align and rotate, all becomes well. I did quite a lot of testing. Read all of this wiki section Symbol Sizing and Positioning <https://therion.speleo.sk/wiki/metapost#symbol_sizing_and_positioning> > 5. Points that can be aligned , have their (non-zero) rotation corrupted when they are both rotated and aligned. You can see in the example that the speleothem points have been aligned bottom-right, when the th2 file says they should be aligned right). This problem exists with all (almost) existing Therion points. I have identified the cause and proposed a solution here https://therion.speleo.sk/wiki/metapost#symbol_sizing_and_positioning but my metapost skills are very basic, so no doubt it could be improved upon. I'm not sure I fully understand your issue. The result for rotated and right aligned symbols seemed more intuitive to me when I inverted the align and the rotate transformations in symbols. I bet that would be a nice change but I wonder if you are talking about something more subtle that I have not fully understood yet. I think you have understood what I am referring to. The situation where this is most apparent and vexing in a real cave drawing is when using a point water-flow, or point air-draught entering or leaving a passage (perpendicular to a wall). You want to align the symbol so that it plots correctly at a variety of scales, but invoking the alignment makes it displace in entirely the wrong direction. It at first appears to be random, because it depends entirely on the value of the rotation option. But this is a live problem (bug) for almost every point symbol currently in Therion. Oops, I have messed up. I did not test the information in the wiki post sufficiently, six months ago when I wrote it, and just made the assumption that I had fixed a Therion symbol alignment problem that I had noticed. In fact, I just changed the problem. So my coloured words in the boxed text above are wrong, and the wiki post is only partly correct. So if you are looking at the lower diagram in the wiki post and trying to make sense of it, don’t worry, it is wrong and the pictures show that it is wrong! There are SOME Therion point symbols that do not align correctly, but it is not a general problem (of course, someone would have noticed it before now). My proposed solution in the wiki post is therefore not right, and actually makes the problem worse. I think I know what to do now, but won’t have time for a while. Symbols that align the wrong way include water-flow and air-draught. There is also something amiss with the alignment of speleothem symbols, but it is not of the same nature. Eventually I will have a go at fixing it, but not for some time. Maybe I will put together an example file to demonstrate the issue first, so that I can be sure second time around that it is solved. Sorry about any confusion caused. Bruce

1 0