July 2022 - Therion

Transparency and connection issue
by david Le berre 23 Mar '23

23 Mar '23

Dear All New comer on this forum and new user of Therion for 18 months, I'm currently stucked by 2 issues that are certainly obvious for most of you but after lots of trials I dare to ask you!!! 1- Transparency on colour filled areas: Since I have colored some areas and customized some colors as well, I have lost transparency on overlapping cavities. Despite many trials in the layouts no success.I use in my layout for exemple: #clay-orange def a_clay (expr p) = T:=identity; thfill p withcolor (0.96, 0.82, 0.55); enddef; Result it looks better but it is far more difficult to understand some overlapping areas, see hereunder. I guess if I define a special pattern including 50% of colour and 50% of non-colored pixel it could work but I'm not skilled enough to play with metapost.Any ideas to have the transparency back? 2. Connexions lines for offseted scraps:My project covers a 4 kms cave that I have splitted into 4 sub-projects (called networks), I work in each network and gather them to get final export, usually I use connexion point in the scrap. - Network 1 is above Network 2, therefore in the final presentation I offset Network 2 - Network 2 includes itself offseted areas which appear well when I work on export of Network 2 only. When I compile the global project all connexion's doted lines inside network 2 appears then linked to the shadow of the network 2 offseted from the Network 1 instead of staying linked to the Network 2 representation, result is hawfull with dotted lines crossing every where and ending in the shadow area.Any ideas to maintain local connexion dotted line where they were at the beginning? Thanks in advance David

4 23

Passage height values
by Bill Gee 28 Jul '22

28 Jul '22

I am working on a map where there is a long section of very low belly crawl. Most of the passage is between about 6 inches and 15 inches high. I would like to use values in the passage height symbols which reflect the height with a bit more accuracy than seems to be default. It appears that the passage height symbol will take any value, but for display it is rounded down. For example, "-value [0.5 ft]" becomes 0 when the map is compiled. [1 ft] becomes 1, as expected. [1.5] remains at 1. I tried specifying a value in centimeters as "-value [12 cm]" but that still came out as 0 on the compiled map. It did not produce an error - it just did not display as I wanted. With passage height values over about 3 or 4 feet the decimals are not all that important. In passage this low, however, the difference between 6 inches and 12 inches is the difference between not passable and passable. Therefore I think it is important to make the distinction. Is there a way to make the passage height symbol use the actual value provided? ======== Bill Gee

1 0

Displaying some (not all) cross sections
by Bill Gee 28 Jul '22

28 Jul '22

I have an interesting question ... I am working on a map with a lot of cross sections. For some audiences such as other cavers and cave databases, I want all of them shown. For other audiences, displaying every cross section makes for a lot of clutter which does not really add to their understanding of the cave. A few cross sections are sufficient. Some time ago I found out how to exclude all cross sections from a map (symbol-hide group sections). Now I want to know if there is a way to make a map which has only some cross sections. And a related question - For many of these cross sections I had to draw an arrow to show which section line was associated with the scrap. Without the arrows, there is no way to clearly show which scrap goes with which section line. When I leave out cross sections, the arrows remain. Is there a way to designate the arrows as part of the "sections" group? Thanks! ======== Bill Gee

2 2

Status update for wtherion
by Csongor Zih 25 Jul '22

25 Jul '22

Hi everyone! It's been suggested to me that I should write a status update on the mailing list about how wtherion's development is going (if you're unfamiliar, it's an XTherion replacement for the web). I've finished adding the features I considered essential, and in the last few months I have only been fixing issues and making small improvements. I'm not an active user of Therion however, and I cannot fully test this software myself, on real data. It would be very useful if you could test it out with the tasks you normally use XTherion for, and provide feedback and bug reports. Of course this is only if you have enough time and can tolerate a potentially unstable software. You can see the project's page here: https://github.com/daem-on/wtherion This also contains the links to the app and the end-user documentation. I also need help with the positioning of XVI graphics, if you know anything about the XVI embedding format, please comment here: https://github.com/daem-on/wtherion/issues/5 I look forward to your feedback, and let me know if I can help in any way, Csongor

2 2

Drawing lines with graphic tablet
by Francesco Serafin 15 Jul '22

15 Jul '22

Hi everyone, I tried to draw the cave's walls in therion's map editor using a graphic tablet to have a finer control over the lines' shape and obtain a more realistic-looking cave shape. This method didn't work because therion's map editor uses Bezier curves to draw lines: when the pen touches the tablet, a new point is created - but any further movement of the pen will only adjust the curve's tangent at that point and doesn't extend the line. To create new points one must lift the pen and press again so the result is again imprecise. I was wondering if it would it be possible (and easy) to add a new line type that is more similar to Illustrator's pencil tool? With the pencil tool one can hand-draw a path by continuously moving the pen on the tablet (without lifting it). When the pen is lifted, the software calculates a Bezier curve from the path. Thank you Francesco

5 13

Dive data, newline required
by A.M. van Rosmalen 14 Jul '22

14 Jul '22

Dear Therionners, This is a sample of my centerline data: data diving station depth length bearing GTENC0001 36.3 0.45 257.6 GTENC0002 36.2 0.26 248.6 GTENC0003 36.2 0.52 233.3 Simple and straightforward as this may seem, Therion just spits it back into my face saying: -- non-interleaved data before newline -- length The following works (this is the format I use when processing a limited amount of survey data), but obviously this sucks balls when processing large amounts of data (I have 1000 lines of computer generated survey data in this centerline) data diving station depth left right up down ignore newline \ length bearing ignoreall GdB09 30.0 - - 2.7 0 [T, White arrow #4] 10 204 GdB08 30.6 3 0 2 0.5 [T, White arrow #3] 17 265 It seems I'm too stupid to understand why there needs to be a newline before length. Can anyone tell me what I'm not understanding / what I'm doing wrong / how to work around this apparently useless newline requirement? Cheers, Anton

4 3

Map-connection issue - effect of map-level
by Bruce Mutton 12 Jul '22

12 Jul '22

And noting that map-level progressively chops out the offsets, starting with the level-1 offset. Undocumented feature for export of maps? At least it does not change the map-connection line behaviour. export map -projection plan \ -layout LayoutMapThisCave \ -layout LayoutMapThisCavePlan \ -output ../Output/PlanMap.pdf select PlanMap@Cave -map-level 0 select PlanMap@Cave -map-level 1 select PlanMap@Cave -map-level 2 select PlanMap@Cave -map-level 3 select PlanMap@Cave -map-level 4 (and -map-level basic and -map-level 5 etc) Bruce

1 0

new Therion 6.1.2
by Therion 11 Jul '22

11 Jul '22

Hi, there is a new release 6.1.2 of Therion. Check https://github.com/therion/therion/releases/tag/v6.1.2 for more details. Best regards, Therion team

1 0

Map-connection issue - Going to four levels - Offset tests SAMD-ITF-IS example
by Bruce Mutton 11 Jul '22

11 Jul '22

I managed to squeeze five levels of maps out of my example, going to 4 levels of offset (offset of offset of offset of offset). All of the offsets are correctly made, relative to their parent maps. However the line created by point map-connection is only correctly originating from its parent map at the most deeply nested level of offset and at the 1st level offset. At all other offset levels, the map-connection line reverts to originating from the top-level map, and not from its direct parent. In the marked up diagram below: * #1, #2 indicates the offset level * The squares indicate the scope of the various maps subordinate to the main map * The extreme left (green) and right (yellow- almost) map-connection lines correctly originate from their parent maps * The map-connection lines highlighted pink and blue originate from the main map, and not from their parent map, even though the offset is correctly made from the parent. The recti-linear lines I have sketched show where I expect the map-connection lines to be drawn. For comparison https://therion.speleo.sk/wiki/mapconnectors?s[]=connection <https://therion.speleo.sk/wiki/mapconnectors?s%5b%5d=connection> describes offsets 2 levels deep, and as I have found and on that wiki page, 2 levels deep behaves as it should. It is only once we get to 3 levels of offset that the behaviour deviates and becomes problematic. So the pattern is clearer, and I am becoming more confident it is a bug. Why a bug? * Because at 2 levels of offset the effective behaviour is that each map-connection line originates from its direct parent. * And at 3 and 4 levels of offset, the effective behaviour is that the only the most deeply nested and the 1st level of offset map-connections originate from their direct parent. The intermediary level offset map-connections originate from the main map location and not from their direct parent. So maybe it is a problem with the definition of point map-connection, or the way that the origin and destination locations are parsed to the map-connection lines? Bruce

1 0

map-connection issue - Offset tests SAMD-ITF-IS example
by Bruce Mutton 11 Jul '22

11 Jul '22

Tarquin, David The results of our little quiz made me uneasy, so I found an old test project that I believe is structured like Tarquin's, a pattern I call 'scrap and map definitions - inside trip file - inside survey' SAMD-ITF-IS. The outcome I feared (due to my large collection of projects structured differently) is that map-connections with multi-level offsets would work just fine with SAMD-ITF-IS. That has not been the case, I have the same (I think) behaviour with this test project as I have with my other projects. So perhaps a degree of relief but still a mystery to resolve. With my test project: * Offsets work OK. * Offsets of offsets (level 2 offsets) work just fine so long as the most deeply nested offset map is comprised of scraps (and not maps). * Offsets of offsets (level 2 offsets) do not work (connection emanates from grandparent, not the parent) if the most deeply nested offset map is comprised of maps (a necessary prerequisite when preparing for the third level of offsetting). * Offsets of offsets of offsets (level 3 offsets) map-connections correctly emanate from their parent level 2 offset map, but the level 2 map-connection continues to incorrectly emanate from its grandparent. I have not progressed this to a fourth level, brain is starting to hurt and I ran out of scraps associated with the particular sub-survey that I picked on. Re-reading Tarquin's last email mentioning sub-sub-sub-surveys, I wonder if we are at cross purposes a little (or Tarquin is using 'survey' loosely to refer also to maps). In my example below (which I think is structured like Tarquin's) there are two surveys (1 and 2) and a parent cave survey that contains those two surveys, so only two levels of survey. However I have created three levels of map which offset correctly. When I create a fourth level of map in preparation for 3 levels of offset, the map-connection breaks. The code examples below show only to the level 2 and level 3 offset maps, and these are the maps on the left hand side of the diagrams, as annotated. Offset of offset is OK like this map 1-BottomUpPlan-Bottom \ -projection plan 1-BottomUpPlan-s2 break 1-BottomUpPlan-s1 #bottom terminal chamber endmap 1-BottomUpPlan-Bottom Offset of offset is not OK when same as above but map-of-scraps is split into map-of-maps that references maps-of-scraps ##Setup for OffsetLevel 3 map 1-BottomUpPlan-Bottom \ -projection plan 1-BottomUpPlan-B2 # break 1-BottomUpPlan-B1 endmap 1-BottomUpPlan-Bottom map 1-BottomUpPlan-B2 \ -projection plan 1-BottomUpPlan-s2 endmap 1-BottomUpPlan-B2 map 1-BottomUpPlan-B1 \ -projection plan 1-BottomUpPlan-s1 #bottom terminal chamber endmap 1-BottomUpPlan-B1 Offset of offset of offset is OK BUT its parent is not (as above) ##Setup for OffsetLevel 3 map 1-BottomUpPlan-Bottom \ -projection plan 1-BottomUpPlan-B2 # break 1-BottomUpPlan-B1 [0 10] below #OffsetLevel 3 endmap 1-BottomUpPlan-Bottom map 1-BottomUpPlan-B2 \ -projection plan 1-BottomUpPlan-s2 endmap 1-BottomUpPlan-B2 map 1-BottomUpPlan-B1 \ -projection plan 1-BottomUpPlan-s1 #bottom terminal chamber endmap 1-BottomUpPlan-B1 For what it is worth, here is the overall survey file, consistent with my SAMD-ITF-IS pattern: survey Cave map CavePlan -projection plan 2-EntrancePlan@2 1-BottomUpPlan@1 [0 -20] below #OffsetLevel 1 endmap CavePlan input 1-BottomUp.th input 2-Entrance.th centreline equate 1.4@1 1.4@2 endcentreline endsurvey Cave So Tarquin, Can you pick any fundamnetal differences? Are we doing the same things? Are we talking about the same things?

1 0