- Therion - speleo.sk

log extend - hide not annotated
by Bruce Mutton 07 Dec '19

07 Dec '19

Extend hide is not annotated in the log, and it probably should be (definitely should be – nothing harder that debugging an invisible network if it is not identified as such). I suggest it should present it like this RIGHT 5@extendedloop RIGHT 7@extendedloop BACK 5@extendedloop HIDE RIGHT 6@extendedloop Another example, hiding two legs. Similarly, this one should be … HIDE RIGHT 3@extendedloop HIDE RIGHT 4@extendedloop And spicing it up a bit, adding some vertical and specifying hide with just a single station. Again, this one should be … HIDE RIGHT 3@extendedloop HIDE RIGHT 4@extendedloop And just checking normal = right and reverse = left: It does the first time, but that does not test the subtilty of these statements. Using that syntax repeatedly (not shown here) does either propagate the preceding direction, or keep reversing the direction, as is indicated in the documentation. So normal and reverse is working and logging perfectly. Bruce

1 0

log extend
by Bruce Mutton 06 Dec '19

06 Dec '19

Here is what happens with a real project that I did a year ago. As far as extended elevations go, it is a well-behaved project, that was built incrementally, starting with survey 1, then 2 etc. While the extended network behaves well, the log does not do so well. Here is a small sample. Curiously the extend log shows it starting in the middle of the survey sequence (it goes to survey 6 or 7) at a random entrance. There is no start 4.24 in the data, only a start 1.0! And yet… Two more things: The sequence from 4.20 to 4.19 all the way to 4.15 is extending right, but the log says it is left. I deduce that the sequence then steps back along the same network until it is time to extend along a new branch. That is what the BACK refers to (nice). Here is what the specified extended network that generates both of the images above look like. and much further down the table it gets to the bit of passage in the image above… So, the extend log, although following a credible path along the survey network, has some directional errors, and is nothing like the specified path. Curiously, this log, like the logs for some other projects of mine, end with some apparently random non-existent STARTs and stations that don’t necessarily exist, like -@1 in the sequence below. So, this feature has real promise, but I wonder if there is a bug, and now I am really interested how the extend specifications and logs compare in Tarquin’s short oxbow examples. Bruce

3 6

Survey altitude in debuggable format
by Tarquin Wilton-Jones 05 Dec '19

05 Dec '19

Is there some kind of debug output that I can get from Therion which will tell me the altitudes that it picked for its automatic colour bands (for "color map-fg altitude")? Obviously, I can see these visually on a PDF, but those numbers are rounded (I don't know if Therion actually picks "4" or "4.253" as the actual boundary), and I was hoping they might be in a format that is more easily machine readable. Perhaps something in thTMPDIR? Thanks for any info.

1 0

Therion code question; map colours
by Tarquin Wilton-Jones 05 Dec '19

05 Dec '19

I was trying to look into Therion's source, to work out how it decides the highest and lowest parts of the displayed map, and how it determines the colours to use. I can see it uses thset_color in thparse.cxx, which in turn uses thHSV2RGB. That is a HSV to RGB converter, that returns RGB values in the 0-1 range. thset_color intentionally reduces the hue range to stop it from looping back towards red. All very easy to understand. This is called by thexpmap.cxx, and the work seems to happen in the thexpmap::export_pdf_set_colors function. But what I don't understand is why in the loop there, this line of code seems to ask only for 6 colours: if (addleg && (maxz > minz) && (this->layout->color_crit == TT_LAYOUT_CCRIT_ALTITUDE)) { The PDF shows 7 colours (which I have documented in the wiki page about lookups). How come it manages to get 7, when the code seems to ask for 6? If I plug the numbers in that I would get from that 6-loop, I do not get the colours that I would expect. If I plug in the numbers for a 7-loop, then I get the right colours. What is happening? Is it actually some other code somewhere else that does the legend altitudes - thlookup maybe?

1 0

kml export is not working
by Torsten Schnitter 05 Dec '19

05 Dec '19

Hello I have some problems with exporting a kml file and I wonder what I'm doing wrong. I'm using Therion 5.4.4 (2019-05-01) on Windows 7. Aim is to just get the survey lines from a part of the cave system into a kml file. In the thconfig file I select several lines with the "select command". (I used to do this with double click on the data structure on the right side from the compiler window) Generating a pdf file with: export map -fmt pdf -proj plan -o _Output\Reseau_de_lOuysse_southpassage_2019.pdf -layout layout_plan is doing exactly what I want to have. The result is just the survey data from a part of the complete cave system. But exporting a kml file with the same selected lines fails: export model -fmt kml -o _Output\Reseau_de_lOuysse_southpassage_2019.kml This file does not have any survey data in it. Both files are attached. Does anybody have any idea what I'm doing wrong? regards, Torsten

6 11

Maps-offset New development version
by Bruce Mutton 03 Dec '19

03 Dec '19

Thanks Martin Something might be a bit off however. Is 'maps' and 'maps-offset' intended to work together or are they mutually exclusive? maps on maps-offset off select (one or more) maps This combination produces a pdf output as though only 'maps off' had been specified. ie all scraps that exist are exported, not just those that have been selected. I was expecting that just the scraps specified in the selected maps would be exported, so maybe this is a bug? maps on maps-offset on select (one or more) maps This combination produces an output that seems to match those that we would get prior to these features being developed, as is intended I presume. maps off maps-offset on select (one or more) maps I did not know what to expect with this combination as one would seem to contradict the other. As far as I can tell, the maps off specification seems to have been ignored, or perhaps it is overridden by the 'maps-offset on'. I get the same map as if both features are 'on'. If I swap the order in the above. maps-offset on maps off select (one or more) maps This produces a pdf that matches 'maps off', so I include the order is important, and the last one specified dominates. So at present, it seems that the 'maps-offset' feature duplicates almost exactly the 'maps' feature. I presume this is not what is intended. Also the syntax description in the Therion Book for maps has been swapped with maps-offset, just to make it interesting perhaps. :) I wonder if the therion.log should report the state of the maps-offset flag, once it is working? Bruce From: Therion <therion-bounces(a)speleo.sk> On Behalf Of Martin Sluka via Therion Sent: Sunday, 1 December 2019 22:04 To: Therion users List for <therion(a)speleo.sk> Cc: Martin Sluka <martinsluka(a)mac.com> Subject: [Therion] New development version https://github.com/therion/therion/tree/802ad7c Add thconfig option to disable offsets Martin Sluka

2 2

New development version
by Martin Sluka 01 Dec '19

01 Dec '19

https://github.com/therion/therion/tree/802ad7c <https://github.com/therion/therion/tree/802ad7c> Add thconfig option to disable offsets Martin Sluka

1 0

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