Re: [Therion] A wtherion update

[Tarquin Wilton-Jones via Therion]

Some great changes since I last saw it! The response is really fast.

A few things that have thrown me off, all of which are because the work 
is not finished, so please take them only as a "it would be nice to keep 
this in mind for the future".


Bézier curves are very limited. I cannot make an unbalanced curve point 
with a long smoothing arm on one side and short on the other (something 
I do all the time). I also cannot make the points have arms pointing in 
different directions than opposite each other (something else I have had 
to do a number of times, untick the "smooth" box for a line point in 
XTherion).


Ending Bézier curves is not obvious. Esc does nothing. Very few keyboard 
shortcuts seem to exist.


Undo is not helpful for points within a line. It just undoes the whole 
line. I clicked on a control point in a Bézier curve thinking it might 
give me a menu to alter the drag handles, but instead it deleted the 
point. I did not expect that and definitely did not want it. No way to 
get it back that I could find. XTherion may occasionally screw up its 
undo stack, but the undo functionality there is superb, because it seems 
to remember every little thing that you did (until it eventually screws 
up and throws an error).


Create a Bézier line, right click and use other-bezier.menu.finish to 
end it. Click to start a new line. Ctrl+Z and *both* lines disappear.


It doesn't seem to snap points to each other, or if it does, it doesn't 
have any way to show that it did. In XTherion, you can make lines share 
the same point, so they are guaranteed to be warped together, and not 
produce tiny overlaps. You can also move individual points if you got 
them wrong, and make them snap to each other.


It is not obvious that you can zoom (Ctrl+mousewheel). Some kind of zoom 
indicator would be good.


Line thickness is preset. You cannot set what the rendering scale will 
be, which means it looks more cluttered than it will be when rendered.


In future, it would be nice to be able to set the symbol set, especially 
for things like ceiling steps which are reversed in some of them, which 
makes it very hard to know which direction they will end up facing in 
the final render.


I assume that all of these are just because it's a work in progress, and 
the progress is good enough that you're getting this kind of report :)

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Geographical Coordinates on grid

[Tarquin Wilton-Jones via Therion]

I know John Stevens did this ages ago - he does read this mailing list 
sometimes, maybe he can say how he did it.


I rather suspect he manually specified the grid lines and crosses, and 
point labels for the numbers.

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Placing labels or symbols over top of labels

[Tarquin Wilton-Jones via Therion]

Is it possible to draw line arrow (or other symbols) over top of areas 
clipped by the ‘shadow’ of labels?



Sorry, I don't have the time to test right now, so I am going to throw 
some ideas at you.


Try -clip off with the arrow, because that makes things get drawn later 
(though I think arrows already have that by default).


Try putting the arrow in a different scrap that is stacked on top ("break").

Try using line label.

Try using u-comecustomtext to create the label instead of point label (I 
have some custom code if you need it, but I suspect you already use that 
somewhere), since you can then control when it paints it.

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Semi-transparent rock borders

[Tarquin Wilton-Jones via Therion]

I have some closed rock borders that are opaque as expected when viewing 
my PDF file in Adobe Acrobat and FoxIT but are semi-transparent in 
Okular and Atril.


Any suggestions on how to make them really opaque (on all PDF viewers)?


Translucency (which you only get on rock borders when using 
"smooth-shading off"), does not work in all PDF viewers. There is 
nothing you can do about that, unless you are able to submit a code 
patch to the PDF viewer application.


https://therion.speleo.sk/wiki/contrib:externalviewers

Sorry, I know that's not what you wanted to hear.

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Change altitude colours

[Tarquin Wilton-Jones via Therion]

Hi Paul,


/colour map-fg altitude/


Yes indeed, you can use a lookup table.

https://therion.speleo.sk/wiki/examples#colour_palette_scales_-_lookups
https://www.mail-archive.com/therion@speleo.sk/msg06798.html

Lookup tables allow you to do specific colouring by maps, or altitude.

I have never tried to use it with smooth colouring though, so have no 
idea how it interacts with that setting. I have only ever used it with:

smooth-shading off

Enjoy :)

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Turning LIDAR point clouds into cave maps

[Tarquin Wilton-Jones via Therion]

You can do a lot of DistoX2 splays and then try to manually match the
LIDAR point cloud to the DistoX2 splay model. This is the method I
used twelve years ago when I was first experimenting - it is very time
consuming. Now I would suggest you use something that is sufficiently
large enough to register in the LIDAR cloud that can be surveyed with
the DistoX2 eg. a large distinctive rock, formation or other natural
feature or something man-made, tackle bag, container, helmet etc.


I believe this purpose could very easily be served by the "three white 
orbs". (Though the accuracy might not be great, since they are not 
points, so you are hitting somewhere on a surface,  and can't precisely 
locate that.)


But this also then brings out the potential for error when the post 
processing doesn't match the centreline, and one of them has to "win". 
As you said, this is done in mine surveys.


I still wouldn't want to be using Therion to draw up LiDAR data, just 
because there is so much that it becomes unusable. It is already hard 
enough drawing up a survey that has a lot of regular splays because the 
team got over-enthusiastic with the Disto. "Wait, which one of those 
splays points to the pitch edge?". And there is nothing to tell you if 
something is a pitch, a climb, a floor step, or a dangerous pile of 
loose boulders. Point clouds are great for showing fancy fly-throughs 
for non-cavers, and for mining engineers to see exactly how much more 
material they can remove before compromising a wall, but they add a lot 
of confusion for a cartographer. (But again, see Julian's project.)

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Turning LIDAR point clouds into cave maps

[Tarquin Wilton-Jones via Therion]

Hi Bill,

A few years ago Apple released a very high-end smartphone which has a 
LIDAR feature (iPhone 12 Pro).  There are a few more models now which 
have it.  I have heard of some people using this to create cave maps. 
There is much I do not understand.


Has anyone in the group taken the point cloud from an Apple LIDAR scan 
and turned it into a Therion cave map?  If so, I am very interested in 
the details of the process.


OK, that's a mountain of a question. But yes they have been turned into 
maps, though I don't know about Therion.


Firstly, iPhone can do LiDAR and photogrammetry at the same time, and 
you can put those together as a mesh with a tonne of post processing (it 
can even do colours because of the photogrammetry!). It can do some of 
this with its own software, but afaik, people prefer to use other 
software for the LiDAR processing. This can be used to create pretty 
accurate 3D views of caves. The loop closures look amazing, but it's 
hard to know whether the post processing is swallowing the errors. There 
is some work going on at the British Cave Surveying Group to get it 
working. Jono was pioneering this.

https://3dcavesurveys.com
https://www.youtube.com/@valaheritage-jonathanleste4205

At the moment, it has no centreline (unless he added that since I last 
looked, but it's not a trivial task), so that currently makes it quite 
incompatible with Therion.


It is also worth noting that the iPhone has a 10 metre range. With 
passages larger than that, it just invents a ceiling or wall, even 
though there isn't one, which can really confuse any software that wants 
to use the result. And no LiDAR scanner copes well with water.


Secondly, with point cloud data, Julian Todd has a completely different 
surveying package used to draw up surveys. You draw them in 3D, using a 
VR headset. It's called TunnelVR. Some people love the experience, it 
feels a lot like a computer game. But it is extremely different from 
Therion - an entire world away, and although it can export paper 
drawings, it is not as mature as Therion in that respect. Julian is very 
enthusiastic about this if you wanted to ask for a demo.


There are others who do post processing of LiDAR data, using white 
spheres placed in the cave to link the scans to each other. These rely 
on very expensive hardware (but this was used as part of the project to 
survey all the world's largest chambers). I am very poor with names, and 
forget who was doing that. Perhaps someone else can remind me.


In all of these cases, a centreline does not exist. You could of course 
use a scanner at every station, and import those as splays. That is more 
data than I would ever want to work with in Therion. It would be 
impossible to see the positions of things like boulders, pitch lips, 
ceiling steps, etc., because the entire thing would be a mass of splay 
lines, and would just be a grey blob. Though you could draw the walls to 
perfection!


Those should be good places to get you started.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] scale option for lines

[Tarquin Wilton-Jones via Therion]

I can't see the effects of scale option in lines. Can someone describe a 
situation where the lines are affected by the scale option?



Lines are not affected by it when they are drawn. If I remember 
correctly, lines default to medium (normal) thickness. However, you can 
use the "min-symbol-scale" layout option to control what size of symbols 
should not be drawn, and lines disappear when you say "min-symbol-scale L".

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] anchors and rebelays line options

[Tarquin Wilton-Jones via Therion]

I am trying to understand the effect of the anchors and rebelays line 
options.


I can´t visually see any difference in the outputed map and looking in 
the code, I can´t find a place where the TT_LINE_TAG_ROPE_ANCHORS and 
TT_LINE_TAG_ROPE_REBELAYS flags are used. I can only find where they are 
set.


Can someone explain to me how to use them and how to see their effects?


Try them in elevation (extended or projected), and create a diagonal 
rope line with at least three linepoints.


Personally, I hate them, because you have no control, and they never 
seem to end up looking like the actual rigging. They just do rebelay 
loops in unnatural positions. So for my rigging topos, I use my own rope 
lines, which just draw basic lines, and I then manually draw rebelays, 
Y-hangs etc. using Bézier curves. I use point anchor for anchors with my 
custom anchor code, so I can set the specific kind of anchor symbol.


https://therion.speleo.sk/wiki/riggingtopos
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problems generating the sketch KML file

[Tarquin Wilton-Jones via Therion]

  input T97-1p.th2


If I am right, the error is in this file.
You need to check if you have created station points, with the correct 
-name options, for all of your stations in the scraps.

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problems generating the sketch KML file

[Tarquin Wilton-Jones via Therion]

Hi Brauli,

Xtherion does not calculate the coordinates of the sketch and places it 
incorrectly in Google Earth.


Sounds like your scraps may be missing the station points. Therion 
sometimes manages to muddle through when they are all missing, for 
generating a PDF, but it cannot cope when generating "map" KML.


I assume you have already specified the correct coordinate system ("cs") 
and fixed the survey ("fix"), since your lines seem to be correct.


Fingers crossed.

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] A puzzle in Loch

[Tarquin Wilton-Jones via Therion]

> Hmmm.   Maybe I am not using the splay flag correctly?  Is there
> another flag that might be more appropriate?

flags duplicate = a leg that must not count towards the length. It can
count towards the vertical range, if it is the highest or lowest point
in the cave. Use this when you have had to survey twice (or more) down
the same passage. Also use it if you are going from a station in a
passage whose length was already included with the legs going down the
passage itself, and the new legs are used to reach the start of a side
passage, where the main passage is really wide (such as a station on the
left wall of a 50m wide passage, and you need to get to a side passage
on the right wall). This is particularly useful when you have a side
passage you did not have a useful fixed station for, and the nearest
fixed station is a long way down the passage, so you will need to
resurvey from that fixed station, back down the passage you already
surveyed, to reach the side passage. As Olly said, this is the one you want.

#survey from fixed station to AB side passage
flags duplicate
megacairn AB1 12.34 27.5 1.5
AB1 AB2 8.97 42.93 -21.5 #AB2 is start of side passage
flags not duplicate

flags splay = a shot from a station towards a wall, ceiling, floor or
other solid object, such as a stalagmite. Therion uses these to build
the walls in the .lox file. Normally, you use anonymous splays like this
("-" instead of a station name):
AB1 - 1.234 12.5 -17.5
However, sometimes *rarely* you might want to name a splay, such as a
splay that hits something important like a named formation. Imagine you
have a stalagmite called "Medusa", you might do this to tell Therion "I
know this looks like a station, but it's a named splay":

flags splay
AB1 medusa 1.234 12.5 -17.5
flags not splay

flags surface = a leg or splay that is on the surface, not in the cave.
This will not be used for length, depth, or wall generation. It
basically tells Therion to ignore it for cave statistics, and for wall
generation. This might be used for the legs that go from the cave
entrance to your fixed location on the surface, or for splays that go
from a surface station to a surface feature, such as a cliff face
outside the cave.

station 2 "Alpha Cave" entrance
flags surface
fixedpoint 1 12.345 27.5 1.5
#splays around the outside of the entrance
1   -   0.555   237.50  -37.67  
1   -   0.882   258.89  -16.29  
1   -   0.895   296.19  -14.58  
1   -   1.198   320.46  -3.11   
1   2   1.266   62.55   -31.87
flags not surface

>   BU1    BU2    11.6  53.1   84.4    228.4   -84.9   16.8 2.2 1.1 11.6

Oh, this is interesting. I was wondering if you had used "UP" to get
from BU1 to BU2. In such a case, LRUDs are quite useless, as a leg has
no direction, so Therion has no information about which direction is
"left" or "right", so it might have had to make things up and got it
wrong. (Splays are vastly superior to LRUDs, because each one has an
explicit direction, so you can point to all walls of a pitch, not just 2
of them.)

I had expected maybe it was generating walls without any idea where to
point them, but that seems not to be the case, since you have an actual
direction for that leg.

So it seems the most likely cause for your problem is indeed the "flags
splay" where you meant "flags duplicate".

However, I would need more of the data forming that part of the cave to
be sure, since when I tried to compile your snippet, it did not show the
problem. Maybe it only shows up when you have both the old and new data.

I also have never seen data in this format, and am curious as to what
your "data" command looks like. It looks like it should be this:

data normal from to tape compass clino backcompass backclino left right
up down
But Therion won't let me use that, because the compass and backcompass
are not perfectly opposite. I am wondering if it gets confused when you
ask it to use all the data columns (I told it to ignore the backcompass).

Equally curious about what your measurement device is, since you are
getting only 10 cm accuracy (suggesting a measuring tape) and yet .1
degree precision compass and clino, which seems incredibly precise for
manual tools, especially considering the forward and backward devices
seem to disagree with each other by as much as 2.1 degrees (compass) and
1.1 degrees (clino). There is a huge 4.7 degree disagreement on the
BU1-BU2 leg. (Because the devices are being used nearly vertically, so
compass error is increased. Plumbed legs would normally be recommended
when using manual devices.) Whenever I have seen high quality data from
manual devices, the compass and clino have been given to 0.5 degree
precision, because that is the reading limit of the devices.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] A puzzle in Loch

[Tarquin Wilton-Jones via Therion]

On 15/08/2023 22:52, Bill Gee wrote:
> Looking at the .lox file for Stark Caverns, I see a spike that does not
> make any sense.  I suspect it might be a blunder in the LRUD data,
> perhaps a misplaced decimal point - but I have searched all over the
> data and cannot find anything that looks out of line.  Besides, the
> spike is not horizontal, which you would expect from an LRUD blunder. It
> goes up at about a 20 degree angle.
> 
> Take a look at the file at
> 
> https://campercaver.net/MiscFiles/StarkCaverns.lox

Possibly unrelated to the problem, but ...
Several legs are created with a splay, when it looks like they should
have been a leg or a duplicate.
BU1 to BU2 (where the problem is)
G13 to Z1
B1 to B1a
AB1 and AB2
A5 to R1
12 and 14
These can cause issues, because splays are legs are different things,
and you could confuse Therion when it tries to generate walls. It is
supposed to use actual splays for that, but not duplicates. Because you
are calling them splays, Therion tries to use them to work out where the
walls are, and generates a wall where the LRUD data conflicts with what
you have called a splay. So it tries to join the wall it drew at a
station, with the wall you told it is somewhere else in the LRUD data. I
can understand if it does so with a crazy spike, though it is usually
better at handling inconsistent data.

I would need to see the source data to debug further, since I cannot see
what any of the LRUD data looks like.

Cheers

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with Depth

[Tarquin Wilton-Jones via Therion]

No problemo, glad it was so easy to solve :)

On 15/08/2023 21:33, Torsten Schnitter wrote:
> Hi Tarquin
> Thanks a lot for your advices!
> It was not a wrong station point but missing ones.
> I did not have all stations within the drawing but only some.
> And therefore not all surveys did have stations marked in the drawing.
> With "debug on" the distortion was very obvious.
> Now that I have inserted all stations ... tadaaa ... everything shows up as 
> expected.
> THANK YOU!
> regards, Torsten
> 

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with Depth

[Tarquin Wilton-Jones via Therion]

Sorry, I accidentally sent this direct instead of to the list. Copied
below to save anyone else having to send replies. This solved the issue.

On 15/08/2023 20:14, Tarquin Wilton-Jones wrote:
> Hi Torsten,
> 
>> Does anyone have a hint what's going on and what is wrong?
> 
> I would export a .3d file. That way there is no morphing involved, only
> the centreline. Measure the depth with Survex Aven. If it is right,
> good, then this is not a data issue.
> 
> Then enable centreline in the layout, so you can see whether the
> centreline and the cave walls agree with each other. I suspect you will
> see the error here; maybe you have selected the wrong station number in
> a scrap when creating a "point station" with "-name foo". This tends to
> create the biggest warps.
> 
> In the layout:
> debug all
> 
> That will show you which parts of a scrap have the most distortion. Your
> error is somewhere around that.
> 
> Hopefully one of those helps. If not ... share the code if you can, and
> I will try to debug it?
> 
> Cheers,
> 
> Tarquin
> 

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How to add 1.5 x linefeed to a text string

[Tarquin Wilton-Jones via Therion]

> Could not make that work.  No errors, Therion just echos what is typed in
> the text string.

I only ever used it directly in the metapost (it's in my code for
creating custom labels). In the .th, Therion turns everything into
\char103 escape sequences. In the metapost, you have more control.

I don't know of a way to inject tex control characters directly from a
.th but I have no doubt someone else on this mailing list will know a
lot more than me.

You could create custom labels with your own string replacement to add
your own control character, like  instead of , but that only
works for symbols. Not sure how to do that for strings in the cave info.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Big room multiple scraps - How to join

[Tarquin Wilton-Jones via Therion]

> Something along the lines of
> map ProblemchamberMP
> GrandcanyonSP
> FlatroomSP
> endmap
> 
> select Problemchamber
> export map -proj plan -o Problemchamber.th2
> 
> Instead of exporting to pdf, this will then export this to a .th2 file,
> where I guess it will appear with all the lines you have joined, instead
> of you having to join them with line joins/scrap joins or amending line
> end positions to force therion to automatically recognise them.
> 
> This will allow you to work on the whole chamber as one in a single .th2
> file.

Fun fact, you can even ask therion to take the sketches, and output
those, pre-warped and pre-scaled, aligned to each other. It's fairly
advanced stuff though, and I only used it once while boggling slightly.

Sketch Morphing, in the Therion book. Or here:
http://marcocorvi.altervista.org/caving/tbe/m_04/m_045.htm

That's harder than the original problem, but very cool if you wanted to
use it, since it can solve this exact problem (multiple surveys of
different arts of the same chamber at different scales).
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How to add 1.5 x linefeed to a text string

[Tarquin Wilton-Jones via Therion]

> I’m wondering if there is a way to add a 1.5x  linefeed to text
> strings in Therion?

Not sure if there is a proper way, but you can just put tex into the
text input in xtherion, right? If so, you could try
foo \thtinysize  \thnormalsize bar

That's quite hacky though ;)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Big room multiple scraps - How to join

[Tarquin Wilton-Jones via Therion]

> There are lots of features that will cross those walls, so I will be
> making extensive use of "-clip off".

That is entirely up to where you draw your invisible walls. I would try
not to allow them to go through any area fills, but you can join feature
lines too, so either clip off, or two separate lines with a join.

The reason Therion struggles with your drawing is that your gaps are
bigger than the passage width. It needs gaps in the walls to be narrower
than the width across a passage. It tries to close gaps with the
"nearest end of a wall", which is the far side of the passage, instead
of the wide gap. You can leave gaps, just not such wide ones. So if
needed, an invisible wall across the mouth of a passage (that is not in
the current scrap) might help.

> A thought occurred as I was writing this.  There is one survey station
> about in the middle of the white triangle which is present on all of the
> sketches.  I wonder if I can draw invisible walls to that station? Might
> that help everything fit together?  Should be fairly easy to try.

That sounds like something worth trying. It will be a case of
suck-it-and-see.

> I have considered trying to get all the sketches mangled together in a
> single JPG file to use as the drawing background.  The problem with that
> is some of the sketch is done at 20 feet to the inch and some at 10 feet
> to the inch.  Resizing everything to match would take some doing.  I am
> sure GIMP can do it, if only I knew how to use it.

It can, but we're getting quite off topic for this mailing list if you
want a tutorial on Gimp too...

> Hindsight is, of course, 20/20.  If I knew then what I know now, I would
> have sketched the whole room as one big scrap.

This is always the issue with surveying during exploration, rather than
surveying after exploration. A grade 1 helps plan the grade 5+. It is
something you can expect to happen. We hit the same issue in one of mine
- a collapse chamber with loads of walls that are actually not walls.
You don't realise until afterwards.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Big room multiple scraps - How to join

[Tarquin Wilton-Jones via Therion]

Hi Bill,

> Hello everyone - I am having a problem getting Therion to understand how
> to join several scraps to make a large room.

The best advice; never begin or end a survey at a junction! Always
survey through the junction in one surveying trip, so that one survey
"owns" the entire junction itself, and other surveying trips own the
branches off it.

Draw a chamber, and starts of the passages (at the same level) leading
out of it, as a single scrap.

Now that you have not done that, you face a common problem. Thankfully,
it can be easily solved, but you will need some creative "join" commands.

1. Draw invisible walls from the opening of one passage, leading into
the middle of the chamber. That is a subtype of normal walls. Do the
same with If you manage to do it well enough, the lines all match up
well enough to colour the whole chamber. And potentially, a standard
"join" command on the scraps can make it link them all nicely.

2. OK, reality; your chamber is going to be awkward. Joins will not be
so easy to join because there are not stations perfectly on the joins on
a wall, and you will probably not be able to use a standard scrap join.
You will need to use line joins.

Every line that needs a join, needs an ID attribute.

in survey from "trunk" passage:
trunkeast (visible east wall of the passage)
trunkwest (visible wast wall of the passage)
chamberdivide (invisible wall)

in survey from "side" passage:
sidenorth
sidesouth
chamberdividenorth

etc.

then you can join all the line points to make them connect perfectly:

join trunkeast@trunk:0 chamberdivide@trunk:end sidenorth@side:end
chamberdividenorth@side:0 -smooth off

join chamberdivide@trunk:0 chamberdividenorth@side:end -smooth off

etc.

you will need one join statement for every line point that needs to
connect to another one.

This way you can fill the chamber with enough walls to fill the space
with colour.

Does that all make sense?

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Statistics on surveys of a network

[Tarquin Wilton-Jones via Therion]

On 10/05/2023 10:00, Tarquin Wilton-Jones via Therion wrote:
>> Thanks for the answers. I wrote a python script. It is far from being 
>> elegant but it does the job. I attach it to this message in case it can be 
>> helpful to some of you.
> 
> Very nice!
> Thanks for sharing.

One thing I do notice, is that like Therion's own PDF surveying length
stats, the script does not give any length for surface legs, so surface
surveyors are not given any credit.
https://github.com/therion/therion/issues/132

I think this is a bug in Therion's SQL output:
create table CENTRELINE (ID integer, SURVEY_ID integer, TITLE
varchar(60), TOPO_DATE date, EXPLO_DATE date, LENGTH real,
SURFACE_LENGTH real, DUPLICATE_LENGTH real);
...
 insert into CENTRELINE values (4147, 4146, NULL, NULL, NULL, 0.00,
0.00, 0.00);

All of my surface surveys have 0 length.

The python script has the same issue though, in that it only shows
"length", and ignores surface surveys.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Statistics on surveys of a network

[Tarquin Wilton-Jones via Therion]

> Thanks for the answers. I wrote a python script. It is far from being elegant 
> but it does the job. I attach it to this message in case it can be helpful to 
> some of you.

Very nice!
Thanks for sharing.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] finding coordinates of specific station

[Tarquin Wilton-Jones via Therion]

Hi Ofir,

> can I find the coordinates of a specific station?
> for example:
> having a survey with 10 stations,
> station 6 has "fix" coordinates, and is the only station with
> known coordinates.
> i want to find the coordinates for station 2 & 8.
> how?

1. Export a survex .3d file. Open it in Survex's "Aven" (the .3d
viewer). Hover any station, and the coordinates appear in the status bar
at the bottom of the window.

2. With Therion, if you label a station as an "entrance":

survey foo -title "mycave" -entrance 2
  centreline
station 2 "mycave main" entrance
station 8 "mycave secondary" entrance

Then when you export a cave-list, it can give you the coordinates of
that station:

export cave-list -surveys on -location on -o cavelist.html

There may be other approaches too.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Statistics on surveys of a network

[Tarquin Wilton-Jones via Therion]

Hi Philippe,

> Is there a way to export the statistics of a network with the following 
> information:
> -date of each surveys, 
> -names of the team members for each survey
> -length surveyed for each survey

export cave-list -surveys on -location on -o cavelist.html
export survey-list -o surveylist.html

The best it can give is the lengths.

cave-list gives you:
Title   Length  Depth   ExploredX   Y   Altitude
For each "cave" (surveys that have survey ... -entrance 2), and for each
survey above that.

survey-list gives you:
Title   Length  Depth   ExploredApprox. Duplicate   Surface Shots   
Stations
That is; it gives you statistics of the survey data, not the team.

The team members are printed on the PDF (if you enable the right
options), but only a total. It does not give you per-survey.

However, I don't know what it will output if you ask it to export a
database. Probably nothing useful.

Unless there is some magical hidden option I don't know about.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Re : 3 Map-connection issue - effect of map-level

[Tarquin Wilton-Jones via Therion]

Hi David

> Thks a lot for your answer that seems to confirm thé bug, i saw thé same
> Behavior as Bruce discribed with acuracy in my project.
> I will remove thé connection point on thé faulty level replaced by an
> arrow line. Less clean but more logical.

As I said in my previous emails (our different thread "Map connection
issue" from 2 years ago), I only ever use 2 levels, and it works
perfectly.  And it also worked when I tried to expand it into more
levels. We discussed what I do there, that made it work correctly:
https://www.mail-archive.com/therion@speleo.sk/msg08912.html

I thought Bruce prepared some samples that made it go wrong, so that a
bug could be filed.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Remove little text in global export & offseted map

[Tarquin Wilton-Jones via Therion]

Hi David,

> My survey is quite huge and I need to export different scales
> In the biggest I would like to remove all little object and particularly
> text from the export to make it more understandable.

Yes, but also no:
https://therion.speleo.sk/wiki/templates#setup_a_default_standard_layout

layoutstandards.txt has some metapost code that can hide small text
labels. *BUT* the way it works is to physically measure the size of the
text label. So if - for example - you have something like this:

point 740.0 918.5 label -scale xl -text [foobar] -align left

The linebreak in there makes the rendered text block taller than one
line of text would be. The metapost code does not understand that, so it
assumes it must be a large text size, and it allows it to render.

(Yes, it would be possible to make the code check only the first text
character, but that is not as easy as you might think, since the first
character can be a linebreak, or formatting.)

You can also use this layout option:
min-symbol-scale M
but that affects all symbols at once, and you need to remember that all
lines have a default size, even if you did not explicitly set one!

Therion really, really needs to have a setting like this:
min-symbol-scale point label M
* wishes *

> *2- Offseted map:*
> 
> this topic is known but I would like to know if there were some progress?
> 
> Some under-level of offsetted map refers directly to the initial shadow
> when using connection map point.

Sorry, I do not understand this question, could you perhaps explain in
more detail?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] convert excel to therion

[Tarquin Wilton-Jones via Therion]

> i was thinking - maybe someone has some script that does this conversion?

Possibly there is, but there is not really a need to do so for simple
data sets:

1. in Excel, save-as "Text (tab-delimited) (*.txt)", call it foo.th
2. edit it in a text editor
3. add this at the start:

survey foo
  centreline
date .mm.dd
data normal from to length compass clino left right up down

and this at the end:

  endcentreline
endsurvey

That's it. Done. Not really enough steps to need a script. If your
spreadsheet has data in this order, you could do it with step 1 only:

survey|foo
centreline
date|.mm.dd
data|normal|from|to|length|compass|clino|left|right|up|down
1.1|1.2|7.74|331|3.7|1.9|6.4|2|0
endcentreline
endsurvey

If you have a *lot* of files, then yes, maybe you could create a macro
to do it, but the exact information needed would depend on how your
spreadsheet is arranged, so the macro would need to be created
specifically for your spreadsheets, and you could not use someone else's
script. It would depend on the order of your data, and where the date is
written in the spreadsheet, what format the date is written in the
spreadsheet, and where the survey name is written in the spreadsheet.
Your macro would need to rearrange the file to match that format given
above, then save the file as a TSV.

An Excel macro could do all of that, and you could probably record it,
without needing any programming/scripting ability. (Except maybe you
might need to manually put the date in the right format.)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] convert excel to therion

[Tarquin Wilton-Jones via Therion]

Step 1 would be to get the data out of Excel and into a text-based
format. Axel suggests copy & paste, which works very well.
Alternatively, in Excel, use "Save as" to save it as a CSV file. Then
open the CSV file in a text editor that has a find-&-replace function,
and replace all commas with spaces. Save the file as something.th

It's entirely up to you which approach you would prefer.

Step 2 is to add in the basic Therion wrapper that Axel suggested.

Cheers,
Tarquin

> u have to wrap it around some basic Therion code (survey/ centerline).
> As ure question suggest u have not worked before with Therion u might
> want to have a look at one of the dokumentations listet here:
> https://therion.speleo.sk/wiki/doku.php
> u want something like:
>   survey 1
>     centerline
>   date .mm.dd
>   data normal from to length compass clino left right up down
>   1.1  1.2  7.74  331  3.7  1.9  6.4  2  0
>   (copy)
>   ...
>     endcenterline
>   endsurvey
> in a text file saved as *.th
> as stated before, pls have a look at the dokumentation. There are plenty
> listed: e.g. a step by step one for cavers:
> https://therion.speleo.sk/wiki/tfc
>  
> Axel
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion not overwriting existing PDFs

[Tarquin Wilton-Jones via Therion]

Hi Rodrigo,

> Is it a recent bug or some incompatibility with Fedora 37?

I have seen this before *on Windows* when:
1. The PDF is locked by a PDF viewer like Acrobat.
2. The .xtherion.dat file is read-only or hidden.

That second one is a real gotcha when copying from a Linux system.

Are you perhaps bumping into a Linux equivalent of one of those?

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Custom map connections

[Tarquin Wilton-Jones via Therion]

> My arrows have multiple colours. I will share the CC0 code later once I
> am back in front of my computer.

Attached. (Hope the list lets it through.) To use it, you need to set this:

symbol-assign line map-connection MY

Yes, that is the *line* not the point, because Therion turns each point
into a line if it is using offsets on its map.

Hopefully the comment at the start of the code is enough for you to use
it. But basically, it goes something like this. If Therion's bug ever
gets fixed, you can just create:

point mapconnection -attr theme 1
...
endpoint

But until Therion's bug is fixed, you can use my hack:

point mapconnection
...
endpoint
point u:mapconnectiondata -attr theme 1
endpoint

Therion gets it right with line mapconnection, so if you are using those
(eg. in an extended elevation as shown in the Therion book), you can
just set the -attr directly on the line mapconnection.

Each u:mapconnectiondata will only have its theme attribute used once.
So in this case, the first mapconnection point will use theme "default",
and the second one will use theme "1" (because Therion draws things in
reverse order).

point mapconnection
...
endpoint
point mapconnection
...
endpoint
point u:mapconnectiondata -attr theme 1
endpoint

Note that Therion draws "-clip off" objects out of sequence from the
rest of the objects, so if you set that property on a mapconnection
point, you would also need to set it on the u:mapconnectiondata.

Hopefully this is useful for your purposes.

Tarquin
#This MetaPost symbol definition is licensed under CC0 1.0. See the package 
LICENCE.txt for details.

# use with the following -attr type "value" options
# -attr theme default = draws in the default brown
# -attr theme inherit = draws in the symbol colour defined in the layout
# -attr theme 1 = draws in red
# Therion 6 does not support -attr on point mapconnection, so this code 
contains a hacky workaround;
# by placing a point u:mapconnectiondata below the point mapconnection, the 
-attr from that point
# will be used instead. (Note that it must appear below it in rendering order - 
that means any use of
# -clip must also be taken into account!)

#the next line is part of the hack
text en "point u:mapconnectiondata" ""
layout l_mapconnection_MY
code metapost
def l_mapconnection_MY (expr P) =
T:=identity;
begingroup;
save arrowsize, type, arrowhead;
%the length of the arrowhead, which must be 
bigger than the pen size by enough margin for the line's curved end not to poke 
past the walls of the arrowhead
arrowsize:=0.4u;
string theme;
if known ATTR_theme:
theme:=ATTR_theme;
%this is part of the hack
p_u_mapconnectiondata_ATTR_theme:="";
elseif known p_u_mapconnectiondata_ATTR_theme:
%the same attribute, passed using a 
point u:mapconnectiondata
%this is part of the hack
theme:=p_u_mapconnectiondata_ATTR_theme;
p_u_mapconnectiondata_ATTR_theme:="";
else:
theme:="default";
fi;
if (theme = "1"):
drawoptions( withcolor (1,0,0) dashed 
evenly ); %red
elseif (theme = "2"):
drawoptions( withcolor (1,0.6,0) dashed 
evenly ); %orange
elseif (theme = "3"):
drawoptions( withcolor (0.78,0.78,0) 
dashed evenly ); %dark yellow
elseif (theme = "4"):
drawoptions( withcolor (0.46,0.78,0) 
dashed evenly ); %spring green
elseif (theme = "5"):
drawoptions( withcolor (0,0.78,0) 
dashed evenly ); %green
elseif (theme = "6"):
drawoptions( withcolor (0,0.5,0.44) 
dashed evenly ); %greeny teal
elseif (theme = "7"):
drawoptions( withcolor (0,0.8,0.87) 
dashed evenly ); %sky blue
elseif (theme = "8"):
drawoptions( withcolor (0,0,1) dashed 
evenly ); %navy blue
elseif (theme = "9"):
drawoptions( withcolor (0.5,0,1) dashed 
evenly ); %violet
elseif 

Re: [Therion] Custom map connections

[Tarquin Wilton-Jones via Therion]

Hi Axel,Yes. Therion's bug is annoying. I have a workaround. It's a hack, but 
it works.I have a custom u point that has to appear in the object list just 
below the map connection point. The code reads the attributes from the custom 
point and stores them in a global variable. The map-connection code uses that 
variable if it cannot find attributes on the map connection point itself.My 
arrows have multiple colours. I will share the CC0 code later once I am back in 
front of my computer.Hack hack hack...Tarquin
 Original message From: Axel  Date: 
10/09/2022  06:45  (GMT+00:00) To: therion@speleo.sk Subject: [Therion] Custom 
map connections Bonjour all,

 

some months ago Tarquin opened a request on Github to pass point_mapconnection 
attributes to the actual l_mapconnection (#434).
I wonder if something happened there?

As caves don't know how to behave, I have one at the minute that has -just- 5 
passages above/underneath each other. Different styled map-connections would 
make it so much easier to understand the plan and follow the route in the cave 
(eg make the main ones thicker, change color for overlying/underlying passages).

 

has anyone found a way around it?

 

cheers,
Axel

 

 

from the mailing-list:

---

 Tarquin Wilton-Jones via Therion Thu, 07 Jul 2022 10:04:09 -0700

Hi folks,

I have a challenge, presented to me by some users of one of our surveys.


We have a cave with layers horribly stacked above each other (10
passages all crossing the same point!). Simple solution; use map offsets
to put them all side by side. Use map connection arrows to show what
connects to what.

That's all good, but they find the default connection arrow hard to see.
I can redefine l_mapconnection to create my own arrows. Great!

But here's the challenge; they want us to show the difference between an
unimportant connection, and a major "follow this route" connection. Eg.
minor ones in grey, major route in red.

I have tried everything I can think of with the mapconnection point: id,
scale, rotation, -attr etc., but Therion is not creating a
p_mapconnection. it creates a l_mapconnection, and passes it a path to
create the line. The attributes are all completely ignored.

Normally, I would use "-attr type major", but that cannot work here,
because Therion just ignores it. In my opinion, this is a limitation
that should be fixed.

The only solution I can think of, is to put *two* mapconnection points.
The l_mapconnection code can then see if the current path matches the
previous path, and if so, draw it in red. But this is such a horrible
hack, and prone to failure in future if someone does not realise why
there are two points, and why they have to follow on from each other.

Can anyone think of a better workaround?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

 

 

 
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] sd for a vertical pole

[Tarquin Wilton-Jones via Therion]

> In Therion, this generates an error "invalid quantity -- plumb".
> 
> sd length 0.001 metres
> sd plumb 0.125 degrees
> gps surveystart 2.000 - DOWN

I wrote a bunch of tests. Therion is missing the required "sd plumb"
functionality, and has no equivalent. I have filed this as:
https://github.com/therion/therion/issues/445

The only workaround is to use:

sd length 0.001 metres
sd clino 0.125 degrees
gps surveystart 2.000 - -90

but this will then generate a warning from Cavern saying that the
compass bearing may not be omitted. (It will still work, however.)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] sd for a vertical pole

[Tarquin Wilton-Jones via Therion]

> I guess this could just as easily be a Survex question as a Therion
> question.

Actually, it's not. In Survex terminology, it would be done like this:

*sd length 0.001 metres
*sd plumb 0.125 degrees
gps surveystart 2.000 - DOWN

That is how you are supposed to do a vertical leg with variable
clinometer accuracy and length accuracy, but no compass reading (this is
taken from Survex's "How do I?" article, when talking about a radio
location fix).

In Therion, this generates an error "invalid quantity -- plumb".

sd length 0.001 metres
sd plumb 0.125 degrees
gps surveystart 2.000 - DOWN

So how do you do the equivalent in Therion without being allowed to use
"sd plumb"? Is this a bug in Therion? Does it use clino instead? Can it
pass this to the underlying Survex correctly?

Cheers,

Tarquin

> I have GPS readings taken on a pole, with the position being given for
> the top of the pole. Subsequent Disto readings are taken from the bottom
> of the pole. The pole is brought to vertical using a spirit level. I
> have checked the accuracy of the spirit as being 0.125°.
> 
> I have the (measured) standard deviations of the GPS positions, so I can
> specify the standard deviations for the location fix. What I need to
> work out is how to specify the standard deviation for the pole. It's not
> a plumb measurement, because it is not purely gravitational. So although
> I could use "DOWN" that is not actually accurate, since it is really a
> nearly-vertical measurement depending on the accuracy of the spirit
> level. It's really a length and clinometer reading.
> 
> #length of the pole accuracy measurements
> sd length 0.001 metres
> #accuracy of the spirit level
> sd clino 0.125 degrees
> 
> But when working with a supposedly vertical position, even the slightest
> error in the clinometer angle of the pole could cause the compass
> bearing to flip to any angle at all. But this seems extreme:
> sd compass 360 degrees
> 
> So what would be the right way to specify it?
> 
> Cheers,
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
> 

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] sd for a vertical pole

[Tarquin Wilton-Jones via Therion]

Hi folks,

I guess this could just as easily be a Survex question as a Therion
question.

I have GPS readings taken on a pole, with the position being given for
the top of the pole. Subsequent Disto readings are taken from the bottom
of the pole. The pole is brought to vertical using a spirit level. I
have checked the accuracy of the spirit as being 0.125°.

I have the (measured) standard deviations of the GPS positions, so I can
specify the standard deviations for the location fix. What I need to
work out is how to specify the standard deviation for the pole. It's not
a plumb measurement, because it is not purely gravitational. So although
I could use "DOWN" that is not actually accurate, since it is really a
nearly-vertical measurement depending on the accuracy of the spirit
level. It's really a length and clinometer reading.

#length of the pole accuracy measurements
sd length 0.001 metres
#accuracy of the spirit level
sd clino 0.125 degrees

But when working with a supposedly vertical position, even the slightest
error in the clinometer angle of the pole could cause the compass
bearing to flip to any angle at all. But this seems extreme:
sd compass 360 degrees

So what would be the right way to specify it?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Radiolocation Fixed Points

[Tarquin Wilton-Jones--- via Therion]

On 25/08/2022 20:16, Tarquin Wilton-Jones--- via Therion wrote:
>> I am only suggesting removing one of the radiolocation points because
>> your siphon survey sounds like it's fairly accurate, and as tarquin says
>> not likely to be causing the error. I would think the accuracy of the
>> radiolocation could be the weak link, but i'm no expert with radiolocation.
> 
> Depends. I would say something that uses gyroscopes to detect its
> position, is likely to be quite inaccurate, but that really depends on
> the quality of the device. I know Andrew has worked with some supremely
> accurate devices, but in this case, I would consider it quite suspect.

Did some more looking into it. The manufacturers do not state the
accuracy of their inertial sensors (gyroscopes and accelerometers). This
is a summary of what I found:

This particular one works using GPS when in contact with the surface,
then gyroscopes, accelerometers, compass and depth gauge underground or
underwater. Its design seems to be aimed at the use of scooters, rather
than being handheld. The compass has only 3-5° accuracy (unless
specifically calibrated), and the depth gauge has 0.3m accuracy. Part of
its operation uses a speed sensor which detects water flow, so its
results vary depending on the current within the cave, and its accuracy
is 2% when moving at scooter speed (and likely far worse at slow
speeds). The main accuracy limitation is the quality of the inertial
sensors, which will become progressively worse over time, so the
accuracy decays over longer dives. Even a high quality device is
expected to lose 50 m of accuracy within 15 minutes, and a poor one
within just 10 seconds [taken from a forum thread about this exact
problem with this device]. The manufacturer does not state the quality
of the sensors or their use of them. The equivalent cave surveying grade
is therefore very hard to estimate, and probably equates to grade 2 at best.

It would be interesting to know how well the device actually performs in
a test without GPS, comparing a disto survey with an underwater dive
survey done using an ENC3.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Radiolocation Fixed Points

[Tarquin Wilton-Jones--- via Therion]

> I am only suggesting removing one of the radiolocation points because
> your siphon survey sounds like it's fairly accurate, and as tarquin says
> not likely to be causing the error. I would think the accuracy of the
> radiolocation could be the weak link, but i'm no expert with radiolocation.

Depends. I would say something that uses gyroscopes to detect its
position, is likely to be quite inaccurate, but that really depends on
the quality of the device. I know Andrew has worked with some supremely
accurate devices, but in this case, I would consider it quite suspect.

From the specs, it sounds like roughly grade 2 compass (5°), reasonably
accurate depth (30 cm), but using gyroscope and accelerometer to measure
motion is not exactly accurate, at least in most consumer grade
equipment. But I would love to hear otherwise!

If you set the "sd" options correctly for the device, and set the
appropriate standard deviations for the radio location fixes, then
Therion should be able to sort out the error distribution accordingly.
sd for a radio location is likely to be quite large, but actually not as
bad as you might expect.

Radio location "may be able to locate the horizontal position of an
underground point to within just 1.5% of the depth below ground (about 1
metre per 67 metres of depth), and the depth to about 5% of its actual
depth, depending on how level the surface is". But that is in addition
to whatever error there is in locating the point on the surface where
the radio location antenna was used (ie. if you survey to it at grade 5,
or locate it with a GPS that has a 5x5x15 m error - fairly good for a
GPS, no matter what yours might like to claim). Both of those errors
would need to be put into the standard deviation, to get it right.

eg. for a passage 200 m below surface:
1.5% * 200 = 3
5% * 200 = 10
3 + 5 = 8
10 + 15 = 25
fix sumpstart 123 123 123 8 8 25 # 8 m easting, 8 m northing, 25 m alt
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Radiolocation Fixed Points

[Tarquin Wilton-Jones via Therion]

> Therion in general seems to work at the 1 cm level when exporting
> certain formats, but I think (someone correct me if I am wrong) that
> internally, it works on much higher resolution, and therefore can work
> even with tiny legs.

I tested this, and can confirm that Therion can indeed work at tiny,
tiny leg lengths. I produced a survey of 100'000 legs, of 1 mm length.
(I tried 1 million, but Loch just crashed!). And then at 0.1 mm length

It is below the resolution of the Loch graphics handling to render each
of the tiny lines correctly at that scale, but the overall rendering is
correct.

When fixing the points at the start and end of the survey, the overall
rendering is still correct, and the error is distributed correctly.

So basically, Therion can work at crazy small leg lengths, it does not
cause strange distortions. But that can take it beyond the capabilities
of the app being used to render the output.

Your error probably lies elsewhere.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Radiolocation Fixed Points

[Tarquin Wilton-Jones via Therion]

Hi Daniel,

> There are many many stations saved automatically with the device.
> 
> We fixed two points determined by radiolocation, one at the beginning of
> the siphon and another at the end.

Interesting. How are you fixing only the easting and northing, without
fixing the altitude? (Or are you fixing the altitude, with a high
standard deviation factor?)

> When after Therion compilatione, the survey is completely distorted.

It would help to see an example of this - source code for the survey
itself. (Only the part with the siphon and fixed points.)

Also, what happens if you break the data for the siphon by disconnecting
two stations from each other; do the two ends end up where you expect
them to be?

> Doesn't the problem come from too many shots and Therion not being able
> to compensate for the very small shots?

Therion in general seems to work at the 1 cm level when exporting
certain formats, but I think (someone correct me if I am wrong) that
internally, it works on much higher resolution, and therefore can work
even with tiny legs.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Loop in survey, how to split the extended view on a specific station ?

[Tarquin Wilton-Jones via Therion]

Hi Gilbert,

> Therion split automatically the extended survey (we can see it on the
> xvi file), but, can we tell the software in which point we want to split
> the survey ?
> 
> can you change the split point ? where ?

I wrote an article about this specific problem here:
https://therion.speleo.sk/wiki/breakingextend

Enjoy! :)

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Label and passage height colours

[Tarquin Wilton-Jones via Therion]

On 01/08/2022 22:07, Paul Rowe wrote:
> Ok, I'll have a go at the metapost route.

MetaPost for label type things is really inconvenient to work with, so
you might want to use my code to create stylable text labels for a
custom point. It just hooks into the existing label code, so it can
create any type of text label point that Therion can already create
(including the passage height symbols). You could use it to create - for
example:
point u -subtype speciallabel -attr text 23

Then you can style that whatever colour you want.

https://therion.speleo.sk/wiki/metapost#adding_custom_styled_labels_at_any_point_linepoint

And some code that uses it for a custom point type:

https://therion.speleo.sk/wiki/metapost#rope_lengths
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Drawing lines with graphic tablet

[Tarquin Wilton-Jones via Therion]

> 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?

Sorry, I do not know about whether you can draw lines like that in
XTherion. However, you can in TopoDroid. It creates lines with loads of
line points, and no Bezier curves.

Then you open it in XTherion, right click the line, select "Edit line" -
"Convert to curve". XTherion will turn it from a series of points into a
Bezier curve.

So if you could find a way to create a set of dots instead of Bezier
curves, then XTherion can handle the second part of your request.
Perhaps by tapping repeatedly as you "draw" your stroke. Just make sure
you do not create any drag handles, because if you do then Therion
cannot create a curve from the line.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Map-connection issue

[Tarquin Wilton-Jones via Therion]

> Clutching at straws - I wonder if it because I define lowest level maps
> outside of the survey they are associated with?

Well, that is definitely different from me.

Every survey contains its own maps of its scraps.

survey foo -title "day 1 at the swamp"
  map fooMP -projection plan
area1SP
area2SP
  endmap
  centreline
...data...
  endcentreline
endsurvey

Each parent survey contains maps with any potential offsets:

survey thecave
  input foo/foo.th
  ...
  #these say how long the arrows should be
  # XP = exploded plan, in case you were wondering
  map fooXP -projection plan
fooMP@foo [4 -47 m] none
  endmap
  ...
  #these say where the arrows should point to - ie. the total offset
  #of the "parent" piece of cave it connects to
  map thecaveXP -projection plan
fooXP [123 15m] none
  endmap
endsurvey

The grandparent survey contains the whole area, minor caves, surface,
etc. and for testing purposes, I added another offset at this level, and
everything worked:

survey thevalley
  input thecave/thecave.th
  ...
  map valleyXP -projection plan
thecaveXP@thecave [-20 123 m] none
othercaveXP@othercave
  endmap
endsurvey

This is the basic structure that I try to maintain. I do not generally
have sub-sub-sub-surveys since none of my projects so far are big enough
to want to divide a cave into areas within areas. So I do not have any
data to test deeper. (Inception might come into play.)

Who knows why Therion likes my setup more?

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Map-connection issue

[Tarquin Wilton-Jones via Therion]

> I think Tarquin’s explanation and approach,
> https://therion.speleo.sk/wiki/mapconnectors, like the Therion Book
> example only goes two levels deep, ie offset of offset.
> 
> I have attempted to go three levels, offset of offset of offset, and the
> map-connections that worked for two level suddenly flip to originate
> from the main map.

There isn't an emoticon horrified enough to cope with how that made me feel!

It was already complicated enough at 2 levels.

In my current map, I do everything in just 2 levels though, because it
made things cleaner for me. Outer map specifies the offset for each
inner map, giving the location their arrow must start from (ie. what is
the offset of the piece of cave the arrow starts from). Inside that is
the offset of that piece of cave compared with the offset of the
previous piece, which creates the arrow.

Therefore there is only ever 2 levels of offset. It does mean that if
you change 1 map's offset by 1 metre, you must also update the offset
for every map down the chain. But it was still easier than infinitely
nesting maps (17 offset levels deep!).

But I just tested it done with multiple levels, and my offset arrows
still work, so I cannot reproduce the behaviour you described. It is
always the inner-most offset (so to speak) that creates the arrow. At
least with my stuff - you doubtless have much more complex stuff than me.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Custom map connections

[Tarquin Wilton-Jones via Therion]

Hi Philippe and Bruce,

> Can’t you just define some map in grey and some in colors depending on the 
> scrap and the connection ?

A nice thought, but sadly not. A single scrap might have 2 or 3
different connection arrows going from it, and there is no way to
distinguish between those from the MetaPost, except the order in which
they appear in the source. Any approach to fixing that becomes a
horrendous hack that quickly becomes unmaintainable for anyone else who
tries to work on the project.

Bruce, your thought process seems to have gone a long way along the same
lines as mine. In our cave, there are a crazy number of overlaps - 10
overlapping passages at one point - and a lot of shifted sections (it's
an exploded plan, because the plan is unusable otherwise), so without
actual arrows showing the parts a caver can travel through (the same
approach we used), it is a minefield of wondering which bit got shifted
to where. So yes, those arrows are needed in most cases (replacing the
odd couple with letters would not really clear up much confusion).
Clearly you ran into the same limitation, where the solution became to
create a custom point because Therion fails to pass variables into the
MetaPost.

I could in fact create a custom point
p_u_arrowvariables
read the -attr values, save them globally, and pick them up in the
MetaPost for the arrows. This is also a cludge, but a more flexible
cludge than my current one since I can have different themes. But it
means having another point showing up in the legend. Can p_u_foo be
hidden from the legend?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Transparency and connection issue

[Tarquin Wilton-Jones via Therion]

Hi David, and welcome to the mailing list!

>     thfill p withcolor (0.96, 0.82, 0.55);

Since Therion 6.0:
thfill p withcolor (0.96, 0.82, 0.55) withalpha 0.5;

In earlier versions you need to use withtransparentcolor instead.

> Any ideas to  maintain local connexion dotted line where they were at
> the beginning?

When you have an offset within an offset, the connection arrow gets
drawn in the inner-most offset (I hope that makes sense).

I wrote an article about how to work with this here, and I think this
covers your use-case, but let me know if I have misunderstood your
specific issue:
https://therion.speleo.sk/wiki/mapconnectors

Hope this helps.

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Custom map connections

[Tarquin Wilton-Jones via Therion]

Hi folks,

I have a challenge, presented to me by some users of one of our surveys.

We have a cave with layers horribly stacked above each other (10
passages all crossing the same point!). Simple solution; use map offsets
to put them all side by side. Use map connection arrows to show what
connects to what.

That's all good, but they find the default connection arrow hard to see.
I can redefine l_mapconnection to create my own arrows. Great!

But here's the challenge; they want us to show the difference between an
unimportant connection, and a major "follow this route" connection. Eg.
minor ones in grey, major route in red.

I have tried everything I can think of with the mapconnection point: id,
scale, rotation, -attr etc., but Therion is not creating a
p_mapconnection. it creates a l_mapconnection, and passes it a path to
create the line. The attributes are all completely ignored.

Normally, I would use "-attr type major", but that cannot work here,
because Therion just ignores it. In my opinion, this is a limitation
that should be fixed.

The only solution I can think of, is to put *two* mapconnection points.
The l_mapconnection code can then see if the current path matches the
previous path, and if so, draw it in red. But this is such a horrible
hack, and prone to failure in future if someone does not realise why
there are two points, and why they have to follow on from each other.

Can anyone think of a better workaround?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Problems with labels and scaling

[Tarquin Wilton-Jones via Therion]

Hi folks,

I assume someone has already found out about these, but I could not find
anything, so I have reported them as bugs. The first one is causing me
issues. Does anyone know a workaround for it?

1. Labels get weird debugging numbers inserted before them if the ratio
of base-scale to scale is not an integer:
https://github.com/therion/therion/issues/428

2. Some kinds of label points cannot rotate, but most others can:
https://github.com/therion/therion/issues/429

3. XTherion does not have the context menu items for editing altitude,
date and station-name points.
https://github.com/therion/therion/issues/430

4. The Therion book is missing the date -value and point station-name
-text options.
https://github.com/therion/therion/issues/431

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Point altitude/deph, Help !

[Tarquin Wilton-Jones via Therion]

On 28/06/2022 10:04, Philippe Vernant wrote:
> Hi guys,
> 
> I’m digging this topic since I’m running in a similar issue. Would that
> be possible to have for the points with the option “altitude" something
> like :
> 640 [-30], where 640 would be the altitude and -30 the depth ?

You could use two different types of label, positioned at the same
place, with one -align left and one -align right.

These are the existing labels:

altitude, date, height, label, passage-height, remark, stationname

altitude:

General altitude label. All altitudes are exported as a difference
against grid Z origin (which is 0 by default). To display altitude on
the passage wall, use altitude option for any line point of the passage
wall.

So you set the grid origin to whatever height you want as the reference,
and you get the depth shown by the labels.

height:

Height of formations inside of the passage (like pit etc.)

label:

generic label

passage-height:

Height of the passage (floor to ceiling)

remark:

general comment

Of those, you could maybe consider abusing height for your purpose. Put
the altitude  as the height above sea level, and the "height" as the
depth below the entrance.

Alternatively, you could consider creating a custom p_u_depth that does
whatever kind of label you wanted. I have demo code for how to create
labels in your own metapost:
https://therion.speleo.sk/wiki/metapost#adding_custom_styled_labels_at_any_point_linepoint
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] The purpose of \thfb

[Tarquin Wilton-Jones via Therion]

Why do I always do this to myself? Send a mail, then work out the answer...

> But I have no idea why that works, and was hoping someone could explain
> to me:
> 1. What is \thfb ?

thTMPDIR\th_enc.tex

\def\mainfont{\thfb}

It is telling it to use TeX's "mainfont". There are also some others
defined in that file, like \rm which can be used instead of \thfb

> 2. Why does it need that, and not a space?

Because it used to default to using the mainfont, now it defaults to
using no font.

> 3. How come it works without the whitespace, when plaintext could be
> anything, and that could construct a btex like:
> \thframed {\thnormalsize\thfbfoo}
> I would have expected \thfbfoo to be a command, but it seems to know
> that it is "\thfb" and "foo", not a single command.

Because "foo" was numbers. \thfb123 = "\thfb" and "123", while that is
not the case for letters. With letters, they are all assumed to be part
of the command. Therefore it needs a space so it knows where the command
name ends.

> 4. Is there a better way to construct a btex "string" that can be used
> to create a p_label.urt piece of text that can work with the
> p_label_mode_passageheight style?

Leaving this question open, because I don't have an answer.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] The purpose of \thfb

[Tarquin Wilton-Jones via Therion]

Hi folks,

A question relating to TEX.

Previously, I used to use this:
thTEX("\thframed {" & textsize & plaintext & "}")
Where textsize was something like \thnormalsize
This worked until recently. But now (Therion 6?) it returns nothing.
After some trial and error (and looking through the -d output), I
managed to make it work again like this:
thTEX("\thframed {" & textsize & " \thfb " & plaintext & "}")

But I have no idea why that works, and was hoping someone could explain
to me:
1. What is \thfb ?
2. Why does it need that, and not a space?
3. How come it works without the whitespace, when plaintext could be
anything, and that could construct a btex like:
\thframed {\thnormalsize\thfbfoo}
I would have expected \thfbfoo to be a command, but it seems to know
that it is "\thfb" and "foo", not a single command.
4. Is there a better way to construct a btex "string" that can be used
to create a p_label.urt piece of text that can work with the
p_label_mode_passageheight style?

For reference, this is what Therion itself creates:
p_label(btex \thframed {\thsmallsize \thfb\char54 \mainfont{}}
etex,(16.93,13.78),0.0,p_label_mode_passageheight);


Stabbing in the dark here, and cannot find any explanations.

Cheers

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] new Therion 6.1.0

[Tarquin Wilton-Jones via Therion]

> Properties -> Compatibility -> Change high DPI settings
> And then selecting High DPI scaling override, scaling performed by
> application.

Aww yisss!

Thank you, that is so much nicer.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] new Therion 6.1.0

[Tarquin Wilton-Jones via Therion]

On 20/06/2022 21:01, Stacho Mudrak wrote:
> Hi, this should be fixed in the latest snapshot - upgrading wxWidgets
> from 3.0 to 3.1 seems to solve the problem.
> 
> Could you please try and confirm whether this fix works for you?

Verified fixed. Windows 10, Loch 6.1.0+682fcb3 msys2 #376. Nice
turnaround speed :)

The UI buttons and general graphics look really fuzzy though. I think
that is all releases since 6 or 6.1, because Therion now respects the
Windows scaling "Change the size of apps and text on the main display".
Can I disable that in Loch by any chance? Because Loch does not do it
nicely at all.

I could not see anything in the changelog.

Cheers

Tarquin

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] new Therion 6.1.0

[Tarquin Wilton-Jones via Therion]

On 20/06/2022 16:48, Benoit Martinez wrote:
> Same here with the standard installer on the release page, on Windows 11

Nearly a month after the release and nobody mentioned it yet o_O
I don't know what this says about all of us :D

Something about who is on vacation, the number of Windows Therion users,
the number of Lox users, or how often we all update?

Well, I am guilty of the last one, anyway.

> I use the MXE installer and there is no more problem
> : https://github.com/therion/therion/actions/runs/2397690531

Interesting. At least that allows me to run it, thanks!

Filed as https://github.com/therion/therion/issues/426
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] new Therion 6.1.0

[Tarquin Wilton-Jones via Therion]

On 27/05/2022 18:00, Therion via Therion wrote:
> Hi, there is a new release 6.1.0 of Therion.
> Check https://github.com/therion/therion/releases/tag/v6.1.0 for more details.

Just got around to updating, using the standard "Windows installer" on
the Therion download page. In this release, I have been getting this
error on Windows 10 when trying to run Loch:

---
Fatal Error
---
Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1016,wx
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1017,wx
containers,compatible with 2.8).
---
OK
---

This doesn't sound like something wrong on my machine, but I would have
expected someone else to mention it already if it was wrong with the
Therion release. Did I miss something?
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Is copying supposed to be done in reverse?

[Tarquin Wilton-Jones via Therion]

On 20/06/2022 10:19, Bruce Mutton wrote:
> Ha!  It was the great Tarquin who provided me with insight one year ago
> https://www.mail-archive.com/therion@speleo.sk/msg08109.html 

"I have no memory of this place" Gandalf

But yes, what I am seeing now conflicts with what I wrote then. So
something has changed, and I don't think it is for the better.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Is copying supposed to be done in reverse?

[Tarquin Wilton-Jones via Therion]

> As far as I am aware, the last called layout or statement always wins.
> Certainly since I started using the recipe I have not noticed any
> problems, and my layouts occasionally have conflicting parameters for a
> particular setting (which is why I originally had problems – I was not
> rigorous about call order).
> 
> Seems to conflict with your experience, maybe mine are simpler?

Affirmative, what I am seeing conflicts with the statement you made on
the wiki.

Your example seems not to have two "copied" layouts arguing with each
other. But the written text claims that what I am seeing is not what
should be happening. Thus I assume this is a bug. I would love to have a
more definitive "It is supposed to work like [blah]", so I know what bug
report to file though. It is fairly evident that having the "copy"
commands being executed in the specified order is best. However,
arguments could be made in both directions for whether statements before
a copy should override the copy.

> (I don’t see an endlayout for your layout third – could that be something)

There is one. Or at least, I can see it. o_O

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Is copying supposed to be done in reverse?

[Tarquin Wilton-Jones via Therion]

Hi folks,

I stumbled on something odd about the "copy" command, which is used in a
"layout". Normally, commands in a layout are interpreted in sequence, so
if you hide something with one command, then show it with a subsequent
command, it will use the second one, and show it:

symbol-hide point stalactite
symbol-show point stalactite #this one wins

If two copy commands copy conflicting information, the first one is
used, not the second. Assume the following .thconfig:

layout first
  symbol-hide point stalactite
  symbol-hide point water-flow
  symbol-hide point dig
  code metapost
let l_wall_bedrock = l_pit;
  endcode
endlayout
layout second
  symbol-show point stalactite
  code metapost
let l_wall_bedrock = l_wall_debris;
  endcode
endlayout
layout third
  symbol-show point water-flow #overrides the copy below
  copy first #first one wins with copy
  copy second
  symbol-show point dig #overrides the copy above
  symbol-hide point anchor
  symbol-show point anchor #second one wins normally
endlayout
source "copy.th"
select copyMP@copy
export map -proj plan -layout third -o "copy.pdf"

Use a basic survey with a default (bedrock) wall, stalactite, anchor,
water-flow. I would expect the wall to look like debris, the stalactite
to be visible, the anchor to be visible, the dig to be visible, and the
water-flow to be hidden. But instead, the wall looks like a pitch, the
stalactite is hidden (!), the anchor is visible, the dig is visible, and
the water-flow is visible (!).

It seems very inconsistent that the anchor and stalactite are visible at
the same time, because it means most commands are executed sequentially,
but copy commands are executed in reverse. It also seems inconsistent,
but understandable, that both the water-flow and dig are visible. My
understanding is therefore that:

* All copy commands get moved to the top of the layout that they are
inside, no matter where you put them in the layout. (Understandable but
weird.)
* Copy commands get executed in the opposite order from how they are
specified (inconsistent with other commands).

I couldn't find anything in the Therion book or wiki describing this, so
is it a bug or expected behaviour?

The book just says "copy  . set properties here that
are not modified based on the given source layout". That wording is
really minimal, but it seems to suggest that commands in "third" will
override anything in "first" and "second", which rather poorly explains
the first bullet point. It does not explain the second.

Therion 6.1.0, Windows 10.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] New default settings and recent proj changes

[Tarquin Wilton-Jones via Therion]

> That all makes sense now.  Strange how my Windows search could not find
> the folder even though I was explicitly searching for it.

It normally ignores AppData and other hidden folders unless you are
already within that folder. It knows better than you, mkay.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Updated XTherion editor side panel adjustment

[Tarquin Wilton-Jones via Therion]

On 28/02/2022 01:12, Bruce Mutton wrote:
> I expect there may be a variable I
> could edit in XTherion.ini (or is  XTherion.new.ini, there seems to be
> one of each) that will increase the snapping distance.


It does not appear to be a snapping distance, per se. It appears to snap
to the points when your cursor is over the top of whatever point you are
trying to snap to. So the "distance" is basically "the point icon's
size". That means that to change it, you would need to change the size
of the point icon (normally a circle, but a triangle in the case of
station points).

Though maybe there is some scaling option somewhere for that.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] new Therion 6.0.5

[Tarquin Wilton-Jones via Therion]

"added support for cave volume calculation (Tools → Survey statistics)"Awesome 
addition.Could someone maybe explain what the difference is between 3D and LRUD 
envelope?I get how 3D probably works based on the rendered 3D view of the cave. 
 But how can the LRUD thing work when I only use splays instead of LRUD? Does 
it just pick some particular or average splay and use it as a LRUD measurement? 
The results are so vastly different. Sometimes much bigger (one of my simple 
caves) sometimes much smaller ( a pothole).
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Fwd: Re: How to calculate the volume of a cave

[Tarquin Wilton-Jones via Therion]

> In this case the cave is very small, only 50 meters, and there are only 14 
> survey stations.  Retyping it into a Compass data file did not take long.
> 
> Compass and MeshLab do very different calculations to come up with volume.  
> For my cave Compass gives about 2900 cubic feet and MeshLab gives over 20,000 
> cubic feet (about 585 cubic meters).  Compass is doing a simple calculation 
> based on polygons and using only centerline plus LRUD.  MeshLab is a much 
> more complex calculation based on a 3D model of triangles.  Ultimately its 
> calculation can be traces back to centerline, LRUD, walls, passage height 
> objects and cross sections.  Therion uses all of that to build a .lox file 
> which, through translations, becomes the MeshLab file.

If it's that short, I would be tempted to do it manually, for a kind of
sanity check. Pretend it's a cave made up from cuboids. Take the cross
sectional area for each station (passage height * width), calculate the
cuboid volume for each leg. See if it closer to one of the other.

The MeshLab version seems like it might be doubling (or more) up,
because of the way Therion generates cave tubes and passages from
multiple overlapping 3D shapes, not a single "tube". One tube for the
leg, then extra 3D shapes layered into the same 3D space for the wall
drawings. If MeshLab is treating those as separate entities, rather than
just the overall outer volume, then it will get a vastly larger measurement.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Hide symbols within certain maps/subsurveys

[Tarquin Wilton-Jones via Therion]

Hi folks,

I have a survey of a cave and its surrounding surface area, including
all the little caves in the area. So you can basically get an overview
of the area, see the surface streams and sinks.

Normally, I want the cave survey to be on its own, showing the cave's
features, passage names, fill areas, boulders, water flow, etc.. But
when I show the area overview, all those features become unimportant,
and most labels should be hidden (only the cave names are important).

When showing an overview though, I still want to show the surface
labels, slopes, cliffs, water flow, arrows, borders, etc.

Does anyone have a nice way to hide almost all symbols within one
map/subsurvey (the cave), while showing them all within other maps (the
surface)? Does Therion have a dedicated way to do this that I missed?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Handling of tape and backtape in survey data

[Tarquin Wilton-Jones via Therion]

On 27/12/2021 19:15, Martin Sluka via Therion wrote:
> 
> 
>> 26. 12. 2021 v 19:32, Tarquin Wilton-Jones via Therion
>> mailto:therion@speleo.sk>>:
>>
>> However, for Disto
>> surveying, it feels largely unnecessary, as the accuracy is already a
>> lot more than most surveys need when just using forward sightings.
> 
> But because DistoX is an electronic device it is only way to be sure it
> works properly. The same as check, if three (four) readings for
> surveying leg with rotation around the longitudinal axe of DistoX are in
> tolerance interval.

Oh very true. This is one of the checks I recommend performing
occasionally to test calibration (or every leg when working around
scaffolding or magnetic rocks). Create legs with one reading flat, one
rotated 90 degrees longitudinally, another reading flat or in any other
orientation. Then validate with a splay back to the previous station.

But personally I consider the leg forward, then duplicate backsighted
*leg* for every single leg, to be largely overkill. There are already 3
readings for every leg, and a rotational test (with optional backsight
splay) already serves the purpose of testing calibration and magnetic
effects. And standard leapfrogging can already counteract clinometer
calibration faults.

But I am sure someone will have their reason to make each leg from 6
readings. :)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Handling of tape and backtape in survey data

[Tarquin Wilton-Jones via Therion]

> when I do I always do a full reading

A splay is useful only for immediate error checking on the data
gathering device (magnetic or calibration), but cannot be used for
automatic error correction unless the app can do it for you (like
SexyTopo can, but only for opposing splays, not for opposing legs). So
there is a benefit to having a full leg there. However, for Disto
surveying, it feels largely unnecessary, as the accuracy is already a
lot more than most surveys need when just using forward sightings.

> instead Toporobot just generates a new station for the backsite.

This must be a nightmare for mistakes, always having to tell the app
which station the next readings are going to be taken from, before you
continue surveying.

> I then manually “equate” these in the .th file, creating a loop

While nice for error handling, this must make your cave lengths
completely meaningless; typically twice the correct length (if you
consistently do it throughout a survey). Or do you manually set the
"flags duplicate" for every backsight, then back to "flags not
duplicate" for the forward sighting?

Do Survex and Therion know to use only a single length if there is a
forward and backsight leg between the same two stations?

I sense an investigation coming soon unless Wookey appears with some
knowledge gem...


Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Get shortest route

[Tarquin Wilton-Jones via Therion]

> I implemented such functionality (not the visualization) a while ago
> as a little exercise in Python. If you know how to run a Python
> script, then you might find this useful.

Awesome!

I would love for that to be built in to Aven, so it could actually
highlight the route too (you know the problem, you give someone an inch
they ask for a mile).

It's something I have wanted when showing someone a survey in Aven;
"Show me the route I took". That is not always the shortest route, but
much like with Google Maps, it would use the shortest route between
control points.

Instead, I end up manually copying it into an image editor, and adding a
background along the route.

(This is kind of off topic for Therion of course, but actually, I would
love for Loch to have a lot of the features that I still rely on Aven
for, such as selecting stations and splays and measuring between them.
So I guess that would be needed first!)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Cutting off a grid

[Tarquin Wilton-Jones via Therion]

On 24/11/2021 10:49, Tarquin Wilton-Jones via Therion wrote:
> Hi,
> 
> We have a vertical cave that is just over 100 metres deep, with its
> entrance just below a 100 metre contour.
> 
> We want to show a grid on the elevation view, like this:
> 
> #show an altitude grid every 25 metres
> #("50 50" affects only plan view, so is ignored here)
> grid bottom   #behind the cave
> grid-size 50 50 10 meters #one line every 25 metres of depth

Umm, yeah. That should have been "50 50 25"

> grid-coords border#show numbers at the edge of the survey
> 
> This leaves a 20+ metre gap at the bottom, since the cave only just made
> it past the last 25 metre grid line.
> 
> 1. Is there a way to cut off the grid after a certain amount, so that it
> doesn't show the blank gap at the bottom? Or alternatively, cut off the
> grid after the cave ends? Or "show the next grid line if the cave is
> within 5 metres of it"?
> 
> 2. Is there a way to start the grid at "0" at the entrance to the cave,
> in order to show depth below the entrance instead of the altitude above
> sea level?
> 
> I tried this:
> grid-origin 0 0 400 meters
> But Therion just threw an error with no error message, so I am obviously
> doing something wrong. Does that only work in plan view perhaps?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Cutting off a grid

[Tarquin Wilton-Jones via Therion]

Hi,

We have a vertical cave that is just over 100 metres deep, with its
entrance just below a 100 metre contour.

We want to show a grid on the elevation view, like this:

#show an altitude grid every 25 metres
#("50 50" affects only plan view, so is ignored here)
grid bottom   #behind the cave
grid-size 50 50 10 meters #one line every 25 metres of depth
grid-coords border#show numbers at the edge of the survey

This leaves a 20+ metre gap at the bottom, since the cave only just made
it past the last 25 metre grid line.

1. Is there a way to cut off the grid after a certain amount, so that it
doesn't show the blank gap at the bottom? Or alternatively, cut off the
grid after the cave ends? Or "show the next grid line if the cave is
within 5 metres of it"?

2. Is there a way to start the grid at "0" at the entrance to the cave,
in order to show depth below the entrance instead of the altitude above
sea level?

I tried this:
grid-origin 0 0 400 meters
But Therion just threw an error with no error message, so I am obviously
doing something wrong. Does that only work in plan view perhaps?
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] thfill with page background colour?

[Tarquin Wilton-Jones via Therion]

On 23/11/2021 20:35, Martin Budaj wrote:
> On Tue, Nov 23, 2021 at 4:34 PM Tarquin Wilton-Jones via Therion
>  wrote:
>>
>>> In which variable do i access the page's background color (the one set
>>> wit the layout option "map-bg")?
>>
>> Fun fact ... you can't access that. Or at least, it didn't seem to be
>> available back when I was trying to do that in version 5. And I still
>> can't see any useful variable in version 6.
> 
> Hi,
> 
> it's now set as MapBackground in the latest commit.

Woohoo! What service :)
Thank you kind sir.

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] thfill with page background colour?

[Tarquin Wilton-Jones via Therion]

> In which variable do i access the page's background color (the one set
> wit the layout option "map-bg")?

Fun fact ... you can't access that. Or at least, it didn't seem to be
available back when I was trying to do that in version 5. And I still
can't see any useful variable in version 6.

"background" is the default background (white) in v5, but even that is
absent in v6.

I tested like this with identical input using the -d switch to get the
data.mp:

1. color map-bg [100 100 0] # yellow
2. color map-bg [100 0 0] # red

The data.mp debugging output was identical in both cases, so it is not
putting the colour into a variable in that file.

In places where I have needed this, my layout included a "code metapost"
which set a global variable where I specified the background colour
(written in metapost notation this time). The symbol code could then
read my global variable. Messy solution.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Rock border not creating boulders with smooth altitude shading

[Tarquin Wilton-Jones via Therion]

> I'm with you Tarquin.
> See my other message (some reason it has not turned up in
> https://www.mail-archive.com/therion@speleo.sk/)
> Seems like it is intentional, but it is more complicated than that.
> This page describes
> https://therion.speleo.sk/wiki/contrib:externalviewers#examples_of_rendering
> _differences_between_pdf_viewers

I had not realised that this would cause me issues!

FWIW, I would prefer that rocks do not obscure a passage stacked below
their scrap completely. I do not mind seeing water as translucent below
a rock when the rock sits in the water.

I very much like the look of boulders as a translucent overlay on top of
water, since we have situations where boulders sit in water, and that
was a great way to represent them as a boulder with water underneath.
You could then use "placement bottom" to put a boulder underwater, such
as a shallow area within a lake. Either way, you could see a second
passage hidden underneath the first.

I do not care much for Adobe Reader and its inability to draw layered
opacity (which has caused issues for other applications that create PDFs
such as PrinceXML). It's an awful PDF reader.

Foxit, Sumatra, Evince; these look great to me, and the others the who
were discussing the output with me today.

> I had always thought double rendered translucent objects where the
> intention, but seems they are not.
> I would vote for making it an option (not withstanding what you actually see
> will depend on the viewer used).

+9
If someone uses Adobe, they get junk. So be it. Let good PDF viewers
display it nicely please. :)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Rock border not creating boulders with smooth altitude shading

[Tarquin Wilton-Jones via Therion]

Hi folks,

I feel like I must have missed some email about this; surely someone
will have noticed before...

Boulders. They are made from line rock-border, which will create a
shaded boulder when closed.

Make an area of water. Create a line rock-border half-way into the
water, and half out of the water, but still in the passage. The boulder
is the same colour as the background. Translucent, sitting on top of the
water.

Set this:
color map-fg scrap

Still works the same.

Now set this:
color map-fg altitude

The boulder loses its colour, and is nothing more than a thick line, so
it stops looking like a boulder.

Set this, and the boulder returns to being a boulder:
smooth-shading off

Is this an intentional change, a known limitation, or a bug?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Depth adds on surface if it is in a different sub-survey

[Tarquin Wilton-Jones via Therion]

Hi folks,

Ages ago, I filed https://github.com/therion/therion/issues/165 and
Stacho fixed it (thanks!).

We have just stumbled on another variant of it in a survey where both
surface and the cave are rendered in a map (a few slopes on the
surface), but the surface comes from a different sub-survey. This causes
Therion to add on the depth of the surface legs too, so the cave gets
far deeper than it should be.

https://github.com/therion/therion/issues/392

I wonder how many cave surveys there are out there with the wrong depth
because of this, since I would think that the vast majority of big
surveys are done this way...

o_O

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Minimum symbol scale

[Tarquin Wilton-Jones via Therion]

> I know that I suggested one format below, but thinking about it more,
> this might be better:
> min-symbol-scale  [ ]
> 
> That means no fussing around with the parameter ordering. But it is then
> inconsistent with symbol-colour.

I have run into this one again, and really need this functionality.

Andrew (or perhaps this is Bruce's originally) has a partial solution in
MetaPost:
if abs(llcorner txt - ulcorner txt ) > 3pt:
The trouble with this is that it only works if the text is all on one
line. It breaks with this because it sees the outer dimensions as huge:
point label -text [foobar>]

The text has already been converted into a "picture" by the use of the
"btex" operator. I tried using the "textpart" operator to get back to
the original (so I could use a substring operator to look for the
\thlabel\thlargesize substring), but that didn't work, unfortunately.

Any other thoughts about how to analyse it? Obviously I could construct
my own btex picture objects and compare the sizes to see if it perfectly
matches a known size, but that gets confused by "L" and "g" being
different sizes due to "g" descending below the line, so it would be
prone to errors, and would need a lot of tests with different text.

There has to be a MetaPost solution in here somewhere...
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Weird handling of directions

[Tarquin Wilton-Jones via Therion]

> If someone wants to help debug this, you can do conversion from grid to
> lat/long using Helmert here (note, use SH 0.00 0.00
> format with several decimal places to avoid it using the middle of a
> grid square):
> http://www.howtocreate.co.uk/php/gridref.php

ARGH!

I should take my own advice. Ignore me. I was never here.

(Therion is doing just fine. It has a 2-4 mm discrepancy, but I think
that is not something to worry about. Probably rounding errors
accumulating.)

Think I am going to crawl back into a hole.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Weird handling of directions

[Tarquin Wilton-Jones via Therion]

Hi folks,

Technical problem. Perhaps something to do with PROJ. Perhaps I have my
declinations backwards?

survey testdirection -title "Test direction"
 centreline
  date 2021.08.13
  cs OSGB:ST #change this to test other grid squares
  fix startst 0.00 0.00 0.00
  station endst "end" entrance
  data normal from to length compass clino
#for SU
#  startst endst 10 0.22666712328 0
#for ST
  startst endst 10 0.7235958904109588 0
#for SH
#  startst endst 10 1.51343150685 0
 endcentreline
endsurvey

thconfig:
source "testdirection.th"
export cave-list -surveys on -location on -o testpositions.html

Those compass bearings match the declination at those locations, on
those dates. I can see this in the Therion output pane:
geomag declinations (deg):
  2021.1.1  -0.8475
  2022.1.1  -0.6465

I have double checked them against
https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml#declination
and I get the same numbers there (rounded to 2 dp). Therion seems to be
doing the right thing so far.

I have converted the startst location into lat,long (using both Helmert
and OSTN5+drift just in case it made a difference). Then applied a
northerly 10 metre geodesic to see where it lands (using two separate
geodesics formulae just in case it made a difference), when given that
bearing and declination.

When doing this at the SU00 line (where OSGB grid and true north
line up), Therion gets the same answer as me for the endst coordinates:
SU 0.00010.000  -0.000

When doing this at the ST00 line (where OSGB grid and true north
do not line up), the geodesic calculation gives this (1 mm rounding
errors possible due to imperfections in geodesic formulae):
ST 0.276501 9.9942170.000
(Converted using Helmert, to be compatible with Therion, but the results
are within 1 mm when converting more accurately.)
Therion gives an answer that is shifted to one side by 8 cm:
ST 0.1929.998   0.000
This seems to cause a rotation to our entire survey. The amount of
rotation depends on the location of the cave. Where we are working, it
is a 12 cm shift within a length of just 10 metres. By the time you
reach SH00 it is a 23 cm shift.

Am I wrong somewhere? Or is Therion (and perhaps Survex?) applying the
declinations in the wrong place?

If someone wants to help debug this, you can do conversion from grid to
lat/long using Helmert here (note, use SH 0.00 0.00
format with several decimal places to avoid it using the middle of a
grid square):
http://www.howtocreate.co.uk/php/gridref.php

And you can perform geodesics here:
https://geographiclib.sourceforge.io/cgi-bin/GeodSolve?type=D=50.7909132676dN+-3.420104865715981dE+0+10=g=f=r=6=6378137=1%2F298.257223563=Submit

Thanks for any help,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Ariane's line - Underwater cave survey device

[Tarquin Wilton-Jones via Therion]

> It's called "Ariane's line", you can find more details on this website:
> arianesline.com 

MNemo is the main piece of kit.
Looks like it is a device you clip onto your dive line. As you swim, it
counts how much line it has been pulled along. It records compass,
length and clino/depth.

Basically that's just a normal survey, either in regular data format or
in diving format (your choice). Survex and Therion can both handle
either of those data formats. You just need to set the right "data"
command. You would need to convert from Excel to Survex/Therion format,
or ask the devs to export it natively. Should be simple to do.

The loop closure of 2% is because you have to unclip it from the line at
a tie-off, then clip it back on again on the other side, so a small
amount of length goes missing. Also if the line is not tight, the
bearing or clino can be wrong. Same if it wraps around a curved
wall/floor. Still, that's better than most diving surveys. Looks like a
really cool device.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] cannot load thconfig in xtherion

[Tarquin Wilton-Jones via Therion]

On 23/08/2021 09:29, Martin Sluka via Therion wrote:
> BTW, using for project “foo" name “foo.thconfig" is not a bad idea.

Indeed. It makes your code more portable, since Windows doesn't show a
"what do you want me to do with this 'thconfig.[nothing]' file that has
no mimetype data?" dialog. Grr.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] 3D viewer CaveView

[Tarquin Wilton-Jones via Therion]

On 31/07/2021 09:43, Martin Sluka via Therion wrote:
> OpenSource 3D viewer for Therion, Survex and Compass 3D models, where
> you may view your remote files (Settings/File).

Stunning! I don't have a big enough data set to see how well it performs
with big systems, but it works great with my surveys.

(Note, to use it, you need to disable mouse gestures in any browser that
supports them. Eg. Vivaldi or Opera. Otherwise all the right mouse
movements can have bad side effects.)

I know that personally, I will always prefer a desktop application
(though it could easily work as a stand-alone Chromium application), but
it's great to have access to it in places where people cannot install
the full application. It's also great to see so many extra options that
are not available in the Loch desktop Lox viewer. Very cool indeed!

For example, I would love to be able to show splays instead of tubes in
Loch. And switch to Aven controls.

My wishlist for Loch would also include:
* More keyboard shortcuts like Aven, so you could switch back and
forward (animated) between Plan and Elevation like Aven's P and L - I
use this all the time to help identify specific points. And press NESW
to rotate to compass directions.
* Automatic rotation like Aven's Enter and Space.
* Rotate *only* without zooming, and zooming *only* without rotating
(Aven does these separately based on which direction you move first,
Loch does not, which is very frustrating).
* Measuring distances between stations/splays like Aven can.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Minimum symbol scale

[Tarquin Wilton-Jones via Therion]

On 28/06/2021 20:33, Bruce Mutton wrote:
> Yes, I wouldn't mind some more refinement.
> Here are my comments from a while back (some of which may have been resolved 
> since).
> [Therion] min-symbol-scale and fonts-setup 
> https://www.mail-archive.com/therion@speleo.sk/msg06651.html

This looks like a very familiar situation indeed.

Perhaps we can work out an appropriate syntax, and see if someone might
possibly take it on.

I know that I suggested one format below, but thinking about it more,
this might be better:
min-symbol-scale  [ ]

That means no fussing around with the parameter ordering. But it is then
inconsistent with symbol-colour.

> [Therion] scaling line ornamentation - metapost 
> https://www.mail-archive.com/therion@speleo.sk/msg07032.html 
> [Therion] next level therion symbol strategy 
> https://www.mail-archive.com/therion@speleo.sk/msg07860.html

Ah yes, some excellent proposals you had there. Would be nice to revisit
those ideas. I wonder if devs can be bribed ;)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Minimum symbol scale

[Tarquin Wilton-Jones via Therion]

Hi folks,

There is a setting:
min-symbol-scale M

That allows you to hide all symbols of S or XS scale. That's useful when
you want to show only the most important symbols in a low resolution survey.

But is there a way to control this differently only for certain symbols?
Eg. I want to be able to hide all "point label" symbols of scale M-XS
but I don't want all my cave walls or breakdown choke symbols to
disappear (which are at the default M scale).

Essentially I want something like this:

min-symbol-scale point label L
min-symbol-scale point anchor:foo M

Some of this I can of course do with MetaPost. But labels (the thing I
care most about) don't allow you to easily redefine the MetaPost macro
... or at least the syntax is so weird that I don't understand it.

Thanks for any advice.

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How to morph sketches

[Tarquin Wilton-Jones via Therion]

On 28/06/2021 09:58, Martin Sluka via Therion wrote:
> 28. 6. 2021 v 10:17, Tarquin Wilton-Jones via Therion  <mailto:therion@speleo.sk>>:
>>
>> Ah yes, doing it as separate scraps is a lot less messy. Though in the
>> end you then probably have to keep using multiple scraps, even if the
>> idea was to warp it into a nice shape so you can draw it up as a single
>> scrap.
> 
> Anyway you may use all morphed sketches in one final scrap (Torsten).
> Take care if you add another xvi file it will go above of recent one. So
> the way is to switch visibility of mesh (xvi itself) to off and move
> morphed sketch (xvi - IMGn) to correct position: select that sketch in
> "Background images" field, check coordinates of cursor (lover right
> corner of map editor window) where you want to place it, write those
> coordinates to fields next of “Move to” and press Enter. Manually move
> sketch to exact position. There is the bug in Therion that th2 file will
> remember only 3 such positions. For fourth and next you should repeat
> that last step after you open th2 file again.
> 
> To move to your sketch is the shortest way to click on point or line in
> “Object section” - on the top of sections menu.

So that would be a solution to Bill's problem, of combining separate
surveys of a single room into one scrap. (Think someone mentioned this
in that thread too...)

Just need to set the -name property correctly for each survey station
(like 1@subsurvey1) if you end up using the resulting .th2 from a parent
survey that has access to all of the subsurvey data.

And if they are paper drawings, perhaps morph (warp) them first using
the instructions from earlier mails in this thread.

This has been a hugely useful learning exercise :)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How to morph sketches

[Tarquin Wilton-Jones via Therion]

> You are right. It could be very useful in simple passages. But in your
> case I’ll divide sketch to three pieces first and try to use “extra”
> points when LRUD are available.

Ah yes, doing it as separate scraps is a lot less messy. Though in the
end you then probably have to keep using multiple scraps, even if the
idea was to warp it into a nice shape so you can draw it up as a single
scrap.

I tested out the "sketch-warp" option (that goes directly in the
.thconfig file, not inside the layout). "plaquette" gave a very good
resulting shape for my demo case (and was really fast!), but made the
lines jagged and hard to see. "linear" preserved the sketch best but
caused more distortion. "point" took forever, but the result was
absolutely excellent. It is interesting to me that the default "line"
gave the worst result of all options.

The Therion book does not mention "linear" or "point", and could do with
an update. I found more details on this very old tutorial:
http://marcocorvi.altervista.org/caving/tbe/m_04/m_045.htm

Torsten, that article is a treasure trove for you!

> Note: You may change order of morphed sketches and xvi with splay shots,
> centreline and xvi mesh, switch visibility on/off, move them to exact
> coordinates in “Background sketches” part of Map editor.

Are these documented anywhere? Specifically how to use the options.

I can see the "point extra" options in the linked article above, but not
how to use the coordinates or visibility.

Feeling like I must have missed something, since the Therion book
doesn't mention "background sketches" at all, and only describes setting
 and  coordinates for the scrap's -sketch option. I am guessing
that x/y lets you offset the sketch to a more useful location relative
to your stations (though I have no idea why you would need to).
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How to morph sketches

[Tarquin Wilton-Jones via Therion]

Hi Torsten,

> As I read some of the last mails I came to the question how to morph a
> sketch.

You don't.

> All I found was on page 89 ff in the book which shows some pictures
> before and after morphing.

Clarification; that appears to be page 94 of this:
https://therion.speleo.sk/downloads/thbook.pdf

> If I got it right it is possible like that:

Those pages of the book do not (at east to my knowledge) show how you do
things with Therion.

You do not warp the drawings. You start with the original drawings in a
.th2 file. Create a "scrap" and set the approximate scale and
approximate scale directions (x/y = east distance/north distance) -
normally it doesn't matter if you get this wrong, as long as you have
more than one station per scrap, but occasionally it makes very odd
shapes if you get it badly wrong. Inside that scrap, you put "station"
points on the stations shown in your drawings. You then draw the walls
using "wall" lines (and other features using other lines). Then when you
process the survey with Therion, it takes the line vectors, and warps
those as needed to force them to align with the real directions of the
survey legs.

I *think* those pages of the book are just trying to help you visualise
how Therion will internally warp the *vector* drawing to match the legs.
It does not actually warp the xvi/image drawings. The book is trying to
show you how the morphing approach would need to correct the
imperfections of a sketch to make it align with reality.

But maybe I am also wrong, and Therion might have some very cool
functionality I have never seen. No doubt one of the highly experienced
users will confirm either way.

Cheers

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] xtherion - Multiple background sketches

[Tarquin Wilton-Jones via Therion]

> Doing a join on room sketches like this is probably not possible.

Well, it is. But it will be a bit of work. You draw scraps with
invisible walls (or any other line with -outline out) as their edges
where there is no real wall. Personally, I would use a border with
"-outline out -visibility off" to draw the boundaries between scraps.

Then use line joins to join each and every set of points to the related
points in the other scraps. I personally use "point crystal" on each
line point to work out where they end up, and move the crystals to make
the lines match fairly closely, then snap the line points to the crystal
locations so that when the "join" gets used, it lines up nicely with
minimal warping. Now the crystals can be deleted again.

This allows you to solve this issue in all cases, including a survey
that has to halt in the middle of a mega chamber due to lack of time, or
because a survey tool runs out of battery. It even works in cases where
your sketches are drawn in different scales (such as with old style
paper surveys).

I attached an example, showing a chamber with multiple scraps extending
into it. Each green spot is a linepoint which gets used in the "join"
for all scrap edge lines that it touches. This approach works well only
if each scrap will get a similar background colour, so perhaps not
useful for "colour by scrap".

The "join" command for a pair of lines looks like this:
join one_line_id:1 another_line_id:3 -smooth off

Hope I am not teaching my grandmother to suck eggs...

(The main difference between using "wall" lines and "border" or any
other lines, is that "wall" lines get used when performing scrap "join"
commands, and the others do not. As long as you are using line joins
instead of scrap joins, it won't matter which line types you use.)

Hope this helps.

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Two extended profiles for same survey

[Tarquin Wilton-Jones via Therion]

> Full description on the wiki https://therion.speleo.sk/wiki/extend
> The second option that Tarquin describes is set out towards the bottom of 
> that page.

Pretty sure the answer is "no", but...

Can you do this in a thconfig:

source "cave.th"
source "extend1.th"

where cave.th contains the cave survey data, and extend1.th contains the
"extend" commands?

I would imagine that to do it, you would need to re-enter the original
survey, which is not permitted.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Two extended profiles for same survey

[Tarquin Wilton-Jones via Therion]

> Is it possible to work around this problem?

Yes but no.

This is why Bruce (?) recommends keeping your "extend" directives in a
totally separate document. You can have
survey/subsurvey/subsurvey.th
survey/subsurvey/extendv1.th
survey/subsurvey/extendv2.th
and in subsurvey.th you use:

input extendv1.th

when you want to use that version. Manual editing of the files is
required. Annoying, I know.

You can make life easier with a top level file (whole map, not
subsurvey) specifying the full set of "extend" commands for all
subsurveys at once. Then you only need a single edit to swap out the
extended elevation for the entire survey.

Unless maybe there is some mechanism I don't know about.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

[Tarquin Wilton-Jones via Therion]

> (I would love to understand why arclength / width gives eg. 5, but it
> will actually have enough space for 5 dots and 5 gaps, which should be
> 10 times the width, not 5. Is arclength half the actual length?)

Because "PenA scaled" is a multiplication factor, not an actual size.
And pen sizes change with the scale/basescale, so my formula worked only
by chance at the specific scale I was using. Oops.

This code should work correctly, by measuring the pen:

def l_u_route (expr P)=
 begingroup;
  save scale, multiplier, linewidth, dotwidth, len, steps, dotgap;
  T:=identity;
  multiplier:=5;
  linewidth:=((xpart (lrcorner PenA)) - (xpart (llcorner PenA))) *
multiplier;
  % If you make the dotwidth too small, MetaPost cannot perform the
  % dashpattern calculations, and it gets the spacing wrong
  % minimum limit is 0.0002
  dotwidth:=0.001;
  len:=arclength P;
  % each dot needs space for the dot, and a gap at each end half
  % as wide as the dot, so a total space of twice the line width
  % short lines still need a dot
  steps:=max(round(len / (2 * linewidth)), 1);
  % the total amount of gap (with the wasted space for the dot
  % removed) which will be split into a before half and after half
  dotgap:=(len / steps) - dotwidth;
  pickup PenA scaled multiplier;
  thdraw P dashed dashpattern(off dotgap/2 on dotwidth off dotgap/2)
withcolor (0.9,0,1);
 endgroup;
enddef;
initsymbol("l_u_route");

This uses the same basic approach as adjust_step, but uses rounding and
will always return at least 1 step, while adjust_step uses flooring and
will return at least 2 steps. It could be made to use adjust_step, and
risk overlaps for very short lines:

  dotgap:=adjust_step(len, 2 * linewidth) - dotwidth;
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

[Tarquin Wilton-Jones via Therion]

> So I am playing with a purple dashed line (thanks Axel!) and it looks
> almost great. Almost. I would like it more if I could make it
> translucent, but I think "withtransparentcolor" only works for fills.
> For lines, it seems to act like a regular withcolor. Is there a way to
> draw translucent lines with Therion's MetaPost? (Obviously I can
> recreate the line using a series of filled dots, or two parallel lines
> that get filled in between, but those are messy approaches.)

I will repeat my question of "can I draw a translucent line?" because it
would still be nicer, and hopefully someone here knows a way.

And it would still be very useful to be able to tint scraps somehow, eg.
make them half way between their depth colour, and the background
colour, without having to layer a different colour over the top (which
ruins opacity).

Anyway, I have done it with a dotted line. It sounded so simple; "dashed
evenly", but that puts the dots at regular spacing based on the line
width, without taking care of the line ends. Sometimes it ends half way
through a dot. And at the edges of a scrap, it gets cut off horribly,
and does not line up with the dot pattern of the next scrap's line.
Short lines across a scrap don't get any dots at all. You can use a
single line over multiple scraps and tell it not to clip, but then it
overlays all your other symbols. Urgh!

There is a solution, it is neat enough that some of you might want it
for your own projects;

The solution was to create a custom dashpattern, where each "dash" (a
dot) has half a gap width at each end of it. That means the line starts
with a gap, not a dot, and there is no overlap. To make sure it also
ends with a gap, it counts how many dots it can fit in the line length,
rounds it to the nearest integer (minimum of 1 dot), then works out how
much space should be devoted to each dot. It subtracts the width of a
dot's actual length (the minimum line length that can be drawn), and
then divides the remaining space by 2, and uses that as the "off" dash
length at either side of the dot's "on" width. I believe the built-in
adjust-step macro can offer something similar.

The end result looks good to me, and will always have half a gap at each
end - with gap lengths adjusted to fit perfectly - so lines that start
and end at the same coordinate as each other will always get a whole gap
between their dots.

(I would love to understand why arclength / width gives eg. 5, but it
will actually have enough space for 5 dots and 5 gaps, which should be
10 times the width, not 5. Is arclength half the actual length?)

Basic code:

def l_u_route (expr P)=
 begingroup;
  save scale, linewidth, len, steps, dotgap, dotwidth;
  T:=identity;
  linewidth:=u;
  % If you make the dotwidth too small, MetaPost cannot perform the
  % dashpattern calculations, and it gets the spacing wrong
  % minimum limit is 0.0002
  dotwidth:=0.001;
  % the drawn length of the line is twice its arclength,
  % so dot + gap makes exactly steps number of dots
  len:=arclength P;
  % short lines still need a dot
  steps:=max(round(len / linewidth), 1);
  dotgap:=len / steps;
  pickup PenA scaled linewidth;
  thdraw P dashed dashpattern(off (dotgap-dotwidth)/2 on dotwidth off
(dotgap-dotwidth)/2) withcolor (0.9,0,1);
 endgroup;
enddef;
initsymbol("l_u_route");
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

[Tarquin Wilton-Jones via Therion]

On 13/06/2021 12:17, Axel wrote:
> an additional thought just occoured to me:
> If u draw a mainroute-line wouldn't it be possible for the coding-gurus
> to get the length and maybe the altitude difference of that line type?

I would have thought the easier way would be a "flags" switch that could
do it for you. "flags mainroute". It wouldn't even be an estimate. Maybe
some of the Survex folks on this list could shed some light on how
feasible that would be. Might require a Survex modification though.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

[Tarquin Wilton-Jones via Therion]

> Have not solved the problem yet

Well at least I am not alone. But that's a shame in this case ;)
A problem shared is a problem where everyone is scratching their heads.

> Where there are multiple levels it is relatively easy just by having a map 
> per level and offsetting them.

Absolutely. This would be my go-to. But sadly here, it's (mostly) not
multiple levels. It's a collapsed zone where there are several ways
through, with one of them being the most obvious. The walls of each of
them are often the walls of another one; you're just looking at the same
peeled off boulder from opposite sides. Hard to explain, even harder to
represent.

I have played with the idea of shading parts of the passage, to
highlight the main way. This could be done by fading out the lesser
passages (making them closer to the background colour) or emboldening
the main passage (eg. making it darker). The approach I am trying is this:

area u:fadeout

then this metapost:

#translucent white, matching background colour of page
def_transparent_rgb(a_u_fadeout_fill, 1, 1, 1)
def a_u_fadeout (expr p) =
 T:=identity;
 thfill p withtransparentcolor a_u_fadeout_fill;
enddef;

(I notice that "area u -subtype foo" doesn't seem to work but u:foo
does, so I cannot supply "-subtype foo" as an option for the area - a
bug I assume ... ?)

Anyway, the idea "works" but it has some ugly side effects. It acts like
a big boulder. It adds an extra layer on top of the passage colour, so
any passages behind it are doubly obscured, and get really hard to see.

And you lose the ability to clearly see depths, so I don't really like it.

Being able to tint a scrap background colour might work, but this idea
does not. Not in practice anyway.

So I am playing with a purple dashed line (thanks Axel!) and it looks
almost great. Almost. I would like it more if I could make it
translucent, but I think "withtransparentcolor" only works for fills.
For lines, it seems to act like a regular withcolor. Is there a way to
draw translucent lines with Therion's MetaPost? (Obviously I can
recreate the line using a series of filled dots, or two parallel lines
that get filled in between, but those are messy approaches.)
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Main route through a cave

[Tarquin Wilton-Jones via Therion]

Thanks for the replies. Axel's line sounds a lot like my arrow. It was my 
preference.Shading scraps is not impossible for simpler cases. A pain for 
complex ones like this. The biggest issue is you can't then colour by altitude, 
which is a major limitation.But being able to shade scraps differently based on 
an attr would be amazing. Say 50% opacity for attr minor.I could do a a_u_major 
with some prominent shading., which would allow darkening of part of a scrap.
 Original message From: Andrew Atkinson  
Date: 13/06/2021  09:47  (GMT+00:00) To: Tarquin Wilton-Jones via Therion 
, Therion  Subject: Re: [Therion] Main 
route through a cave Not tried this myself  and it would not be ideal. Could 
you use carefully selected scraps and maps then use colour to make the main 
route obvious. Could either be subtle or very distinct. Also would allow easy 
turning off if all the side passages, so an extract of just the main route 
could be published.No idea how hard this is to do in practice.Andrew-- Sent 
with K-9 MailOn 13 June 2021 08:49:44 BST, Tarquin Wilton-Jones via Therion 
 wrote:>Hi folks,>>I am surveying a cave that could be best 
described as an insanity of>hidden routes.>>When you go through the cave, it 
feels easy. You follow the obvious route.>>When drawing up the survey, there 
are loads of alternative routes all>crossing over each other and hiding 
underneath the floor. This means>that the survey is harder to navigate than the 
cave itself.>>I was wondering what the general ideas were that people use 
to>counteract this situation. These are what I could come up with:>>1. Fail to 
draw all the passages (GAH!).>>2. Draw the walls of the main route with 
different line types? like>subtype "underlying" and "overlying" instead of 
regular walls (useless>if you are trying to use "subtype blocks" which is my 
specific problem;>the passage is a mess of boulders and ceiling steps creating 
false walls).>>3. Arrows.>>But does anyone have a dedicated, better approach? 
Some way of shading>the main route differently? A dedicated 
symbol?>>Cheers,>>Tarquin>___>Therion
 mailing 
list>Therion@speleo.sk>https://mailman.speleo.sk/listinfo/therion___Therion
 mailing listTherion@speleo.skhttps://mailman.speleo.sk/listinfo/therion___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Main route through a cave

[Tarquin Wilton-Jones via Therion]

Hi folks,

I am surveying a cave that could be best described as an insanity of
hidden routes.

When you go through the cave, it feels easy. You follow the obvious route.

When drawing up the survey, there are loads of alternative routes all
crossing over each other and hiding underneath the floor. This means
that the survey is harder to navigate than the cave itself.

I was wondering what the general ideas were that people use to
counteract this situation. These are what I could come up with:

1. Fail to draw all the passages (GAH!).

2. Draw the walls of the main route with different line types? like
subtype "underlying" and "overlying" instead of regular walls (useless
if you are trying to use "subtype blocks" which is my specific problem;
the passage is a mess of boulders and ceiling steps creating false walls).

3. Arrows.

But does anyone have a dedicated, better approach? Some way of shading
the main route differently? A dedicated symbol?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Atlas

[Tarquin Wilton-Jones via Therion]

On 26/05/2021 21:05, Philippe Vernant wrote:
> Thanks Stacho for the example. If I understand correctly it means that
> for an atlas I cannot keep the option "color map-fg map” and get the
> maps on the same page with color coding for each map. It is either all
> the maps but the same color with transparency levels, or one by one maps
> but with different colors. Am I right ?

You can always use a lookup to set colours for the submaps. The good
part about that is that they don't randomly change every time you add a
new submap in the middle, which they will do with a basic colour-by-map.

https://therion.speleo.sk/wiki/examples#colour_palette_scales_-_lookups
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Need help producing scraps.kml without white blobs

[Tarquin Wilton-Jones via Therion]

Hi Michael,

> but I'm happy to provide the complete data to anyone who is willing to
> dive into this problem.

Certainly I would be happy to help dissecting a survey to work out
what's going wrong. So do share if you are comfortable doing so.

One thing I immediately notice with your survey is that you seem to
expect a scrap to have two outlines, which is not permitted. Near the
southern end - where I see a white overlap in Google Earth due to the
underlying passage - you end one passage, then start a new one on the
far side of the pitch, without starting a new scrap. This happens at the
junction in the north as well.

If you were hoping to have two separate outlines there, then you need
separate scraps. If not, then you are going to get a weird overlap
anyway with the passage above and below both showing at the same time.

In the middle of the scrap, your "-outline in" oxbow also is incomplete
(the part that appears as a huge chamber in KML). Close off the open
passage end with a wall, set to "-outline in -visibility off". I don't
know if that will fix it, but it might.

Further north, you start a passage inside the other passage, which
causes another overlap. That may be correct if the passage does indeed
pop out part way inside the outer wall of the other passage. But if you
want to avoid that overlap, join the scrap walls to each other so that
the passages do not overlap.

The northern-most junction is a mess of overlaps, because you have ended
the passage with it open at each side passage, and none of them extend
through the junction in between. This is not unique to KML. If you
render your cave with a background colour in PDF, you will see the same
problem. One passage needs to "own" the junction. Meaning it must have
an outline that extends fully around the junction (or you can use
horrendous joins and have passages each owning parts of the junction).
Use invisible borders with "-outline out" if you need to, in order to
extend one of the passages through the junction so that it owns the
passage. This particular situation is covered very nicely in Footleg's
tutorial:
http://wscc.darkgem.com/footleg/therion/Therion%20Tutorial%2015thMar2016.pdf
Lesson 9

Does this help fix the problems you are seeing?

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Join 3 scraps from different maps

[Tarquin Wilton-Jones via Therion]

> Instead of joining first the 2 lines of the scrap1.1 and scrap1.2 from
> map1 in th-file1 and then join the 2 lines from scrap1.2 and scrap2.1 in
> the main-th-file I just joined the 3 lines in the main-th file.

A quick quote from the Therion book:
"
When joining more than two points or lines, use one join command for all
of them, not a sequence of join commands for pairs.
E.g. use join a b c, not join a b followed by join b c.
"

Each point/linepoint can only be referenced in a single join command.
Subsequent attempts to use that point/linepoint will be ignored (as you
found out).

> I thought this might be ignored if I only output map1, but the 2 scraps
> are joined correctly.

When you select a subset of your survey, it still processes the entire
survey data, and all scraps for the specific projection, and processes
all the joins correctly. It only *draws* the parts you select, but it
has to process the rest anyway, so that it can pull the lines into the
correct shapes (applying error correction, loop closure warping of
drawings, etc.).

If it didn't work that way, then when you rendered a subset of the map,
the now-disconnected scraps might be rendered differently than when you
render the entire survey, which would be undesirable.

In other words, as you found out; don't worry about where your joins are
specified in the data hierarchy, they will always be used correctly,
even when you are only selecting a subset of the survey below them.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Join 3 scraps from different maps

[Tarquin Wilton-Jones via Therion]

> In one of those subfolders I joined 2 scraps in a map, all good. Now I
> need to join at this position another scrap from a different subfolder

"at this position"

You cannot join 3 scraps at the same place using automatic scrap joins,
since there is no "open end" for it to join the third scrap to after it
has joined the first 2 scraps.

In this case, I would be joining the lines instead of the scraps. With a
line join, you can join as many lines as you want at the same time.

Give each wall an ID if it needs to be included in the join, then
join lineid@survey1:0 otherlineid@survey2:end thirdlineid@survey3:0

Each connection set must be in a single command. Use "0" or "end" (or
the specific point number) depending on which end of the lines are being
joined where.

(Alternatively, if you want to make maintenance difficult for yourself,
you can give the individual linepoints their own ID and join those.)

Hope this clarifies things for you. Please let me know if I
misunderstood your use-case.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Strange Therion/survex disparity in altitudes

[Tarquin Wilton-Jones via Therion]

Hi Alastair,

> Survex: http://cave-registry.org.uk/svn/Andara/Tresviso/

Fun that you choose to use a different file/folder structure for the two
versions. Makes them a little awkward to compare ;)
Fixes inline in one, and in a global file in the other...

> On the .3d file generated from therion I get the following
> Entrance= 470m

Because that's how it is fixed.
http://cave-registry.org.uk/svn/Andara/Tresviso/Nacimiento/therion/Nacimiento2020/entrance_boulder/entrance_boulder.th
fix 1 0363921 4789684 470

> On survex model I get:
> Entrance= 480m

Because that's how it is fixed.
http://cave-registry.org.uk/svn/Andara/Tresviso/FixedPoints.svx
*fix T130363921 4789684 480;Cueva del 
Nacimiento (Cueva del Agua)

That accounts for the 10 m error, right?

I notice you also fix the entrances in the Therion version with "cs
UTM30N" but you don't do that in the Survex version.

> 92m difference at the top.

There is something hugely different in one part of the cave. Aside from
the crazy rotational error.

dr2000_aven is really tall in the .svx version, but goes up and down in
the Therion version. Look for station 2214 in domino_satan in the
Therion version to find the same station.

DOWN has been mis-converted into +90 rather than -90, when converting
from Survex format to Therion format.
Survex:
22132212B   3.49-   DOWN
Therion:
2213  22123.49  311  90
I'm guessing that error may turn up elsewhere. consort_climax looks
similarly wrong.

tinkerbell_bigpitch (Survex name) is also completely different (wrong?)
in the Therion version. I think maybe you have a cluster of equates in
the domino_colins area (Therion name) that are not supposed to be joined.

It's really hard to look for differences with all the extra duplicated
data scattered everywhere though. Making my head hurt. Working on an
isolated and simplified set of data would really help.

I need to get some sleep. I will pick this up when I have some time
tomorrow, if you don't manage to spot the rest of them.

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] 3D model height

[Tarquin Wilton-Jones via Therion]

> If there is a real need for a switch between converting and not
> converting the heights, let us know.

At least here in the UK, a lot of rough and ready surveys seem to use
Garmin handheld GPS units like the 66sr. These use barometric altitude,
which you calibrate to a local benchmark. That means you get local
mapping heights that do not need to be converted, while the GPS
coordinates would need to be converted.

Anyone relying on this approach (which already is rather poor from an
accuracy perspective) would indeed need you to perform conversion on x
and y but not z, while anyone using a proper GPS unit which outputs
ellipsoid heights would need you to convert x, y, and z. I therefore see
a need for it to be controllable.

Personally, I use real GPS ellipsoid heights, which I manually convert
using continental drift calculations and the higher quality
OSTN15+OSGM15 transformation (since these then remain correct in spite
of continental drift). I do not rely on proj for that, and have built my
own tool instead, since proj does not have access to the data required
for it.

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Removing the lines between survey stations created for surface features

[Tarquin Wilton-Jones via Therion]

Hi David,

> Does anyone know how to remove the lines that appear between survey
> stations used for surveying around surface features?

symbol-hide group surface-centreline

This also hides the stations. If you want those, you need to put them back:

symbol-show point station

And then you can also hide the temporary stations, so only the
fixed/painted/permanent stations are shown:

symbol-hide point station:temporary

The statements are interpreted in the order you write them, so put the
most generic one first, then get more specific. As far as I remember,
you cannot choose to show/hide only surface temporary stations while
showing only the underground painted ones (you can only do the whole
surface centreline at once, while the stations relate to surface and
underground at the same time). Maybe others know of a way though.

> Apart from this, the surface feature drawing all works pretty well,
> using the line type "border" with "clip" set to "off".

I like slope for dolines, and pitch for cliffs.

https://therion.speleo.sk/wiki/surfacefeatures

Cheers,

Tarquin
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Splays appearing when not selected

[Tarquin Wilton-Jones via Therion]

> Tarquin, did you know, there is a "-walls off" option for scrap?

Very neat :)

I will certainly use that.

It does limit you though, to only being able to hardcode it into the
scrap. You could not prepare two different versions of the .lox by
selecting the relevant maps (plan and extended elevations at the same
time). You could prepare the two versions, but only by manually editing
the scraps in between.

For me, the existing solution is fine, but does seem oddly limited.
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion