[Therion] Extended elevation page

[Bruce Mutton via Therion]

Good morning all

I have just put together a Therion Extended Elevations
<https://therion.speleo.sk/wiki/extend>  page, having convinced myself that
I have almost figured out how to make them work.  You can navigate there
from the wiki start page <https://therion.speleo.sk/wiki/start> , via the
'Data Organisation' link.

 

Thanks and apologies to Marco Corvi, for the inspiration and words I have
borrowed from his page.  Marco, is it OK?

 

It is not quite complete yet (I have a history of not completing projects)
however if someone can direct me to the centreline and drawing data for the
famous Therion Extended Elevation Control
<https://therion.speleo.sk/samples.doc/25.html>  sample, then I might remain
inspired enough to generate a more comprehensive set of examples.

 

Enjoy your caves

Bruce

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

[Therion] Extended elevation of a vertical cave

[Martin Budaj]

> A better approach would be to define your own line type rope and assign it
> an already defined linetype (like 'border').  [This is quite easy but I'd
> have to look it up -obviously not so easy as I would have done it already! -
> someone else may have it on the tip of their tongue]
>
> This would allow you to change all the 'ropes' at some future time just by
> adding the symbol definition - when you could find time to make a line rope
> definition to your liking.

This would be currently the best option. In the future there should be
a special symbol for ropes. If you are ready to experiment with
metapost code and user defined symbols, there is already a preliminary
symbol for ropes in elevation maps (imitating freely hanging rope) in
therion sources (mpost/thLine.mp -> l_rope_SKBB).

martin

[Therion] Extended elevation

[Bruce]

Hi Andrew
I have not really used extend yet, but have it in mind for some future
projects. I am hoping to use 'revise' to allow multiple extended elevation
projections of the same piece of cave and to move the 'extend' out of the
survey data and into the map definition where it more logically sits if one
is keeping map structure independent of survey structure.  I digress.

I had a play with your hazelnut file with v5.3.8 to see what would happen.
I got exactly the same outputs as you did.

I read the Therion book on extend, and figured that although I agree, there
is quite a bit of unexpected behaviour as you described, the extend normal
or reverse before the first station did not make sense as there is no
previous station. See description on pg 21.  So that aberration at least
could be excused.  The examples near the end of the Therion Book are also
quite helpful.

Maybe Therion needs a bit more specification to help it along with the
hazelnut survey?
For example...

extend start 2.0
extend normal

...before the first data line makes it do what you might expect, although
possibly not for any logical reason.

Similarly...

extend right 2.0 2.1

... before the first data line makes all the legs head right correctly.

So there are some aberrations, but some lateral thinking seems to make it
work out quite efficiently.

And I agree, PocketTopo does seem to make a better stab at where the splays
should be drawn.  Maybe the algorithm could be borrowed from Beat?

Bruce

[Therion] Extended elevation

[Andrew Atkinson]

I am struggling with the extend: left right normal and reverse, they do 
not seem to be doing what I would expect or as described at

http://therion.speleo.sk/wiki/doku.php?id=tfc:321

therion 5.3.7 on debian wheezy

These have been generated from the th file attached, which was an import 
from pocket topo. The file is as I needed it to work, for the below, 
remove all extend commands and then only add before the first line as 
shown. which is how PocketTopo export comes in. Adding it to the 
centreline -extend # seems to have the same effect as below. They 
are all viewed in the pdf, as I really have nothing else at the moment :(

Also it appears that the extend command, moves all the splays in the 
same direction, which I guess is how survex intended it, but this is 
different from the PocketTopo, that treats slays differently and to me 
more sensibly (well in most situations). But this is not really that 
important as the splays generated by therion are not used for the 
PocketTopo image import.

Noextend.pdf as it says has all the extend commands removed, so I would 
expect everything to go right, apart fro, 2.0 to 2.1 goes left


case1.pdf
So add extend right before the line

extend right
   2.0 - 260.00 11.60 2.610

So the legs go right then left, right,left right right...right, left, 
leftleft???

case2.pdf (file not included as it is the same as Noextend)
extend normal
   2.0 - 260.00 11.60 2.610

should be the same as right (unless I am missing a subtle difference) 
and no commands at all. It is the same as Noextend.pdf but different 
from case 1

case3.pdf
extend left
   2.0 - 260.00 11.60 2.610

opposite of right so at least consistent
left, right, left, right, left, left ... left right, right

case4.pdf
extend reverse
   2.0 - 260.00 11.60 2.610

consistent again: opposite of normal, but the first leg goes right 
instead of left and the they all go left

So normal and reverse seem to work apart from the first leg, but left 
and right are doing something strange to the first few legs

Using the commands in anywhere else in a linear part of the centreline 
mostly seems to work fine, and as expected, continuing down the 
consecutive numbering at a branch fine (but this could also be the order 
of the data in the file). However, left and right are less reliable than 
normal and reverse?? But not worked out a pattern yet. Other branches it 
is less clear for and this email is long enough

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: Hazelnut.tar.gz
Type: application/x-gzip
Size: 124608 bytes
Desc: not available
URL: 

[therion] Extended elevation

[Roman Muñoz]

On Sat, 05 Mar 2005 00:21:22 +0100
Stacho Mudrak  wrote:

>> There is a new developement snapshot with new extended elevation
>> processing. Now you can work with it like with plan/elevation
>> projections. Specifications can be done via extend option in
>> centerline(see CHANGES file). Also
>>
>> export map -proj extended -fmt xvi
>>
>> should work (with UD data). If you are interested in testing, your
>> suggestions and BUG reports are welcome.
>>
>> S.
>>


I simply wrote "extend reverse" before first station of passage I want
extended to left side, and "extend normal" after the last one. It
worked. No centerline -extend  is given.

If this is the expected way to do, it's really intuitive, and very easy
indeed.

I'm delighted.

Regards,
Roman

[therion] Extended Elevation, and other questions.

[Martin Budaj]

>> Again, add in layout:
>>
>> color map-fg 50
>> symbol-hide group all
>> symbol-show area water
>>
>> code metapost
>>   def a_water (expr p) =
>> T:=identity;
>> thfill p withcolor (0.1, 0.2, 0.8);
>>   enddef;


It would be more correct do define own symbol set than to redefine the
default symbol (it has the same result, but redefining the default doesn't
allow to switch among various symbol sets). So the correct solution is:

-
color map-fg 50
symbol-hide group all
symbol-show area water
symbol-assign area water MY

code metapost
  def a_water_MY (expr p) =
T:=identity;
thfill p withcolor (0.1, 0.2, 0.8);
  enddef;
  initsymbol("a_water_MY");
-

Now you may use the symbol-assign command to switch among all predefined
symbol sets and the new set MY.

Regards, Martin

[therion] Extended Elevation, and other questions.

[Stacho Mudrak]

Eric Madelaine wrote:

>  Here is the data off the embut de la Pinee, including whatever cause this 
> wrong extended elevation map.
>  I have not included any scan images (except for the ext. elevatin itself) as 
> it would have be over 4 Mo large...

Well, I had a look at your code, and there are several errors in the exteded 
elevation stations specification.

point 152.0 1010.0 station -name k1 at pinee8 -extend left

-extend should be right, because you extend the stations to the right (k2 is on 
the right side of k1). Therion is not able to mirror scrap (currently).

point 890.0 619.0 station -name k11 at pinee8
point 890.0 619.0 station -name k11 at pinee8

I'm not sure, but station k11 should be there only once, but may be, this is 
not an error.

Main source of distortion are these lines:
point 1070.0 468.0 station -name k15 at pinee8
point 1224.0 338.0 station -name k16 at pinee8

station k15 is on the right of station k14, therefore there should be -extend 
right and station k16 is on the left of k13, therefore there should be -extend 
[left prev k13 at pinee8]. I know, in therion book this is written not very 
understandable way :( So the right code should be

point 1070.0 468.0 station -name k15 at pinee8 -extend left
point 1224.0 338.0 station -name k16 at pinee8 -extend [right prev k13 at 
pinee8]

After redefinition of anchor symbol, replacing the "point blocks" symbols on 
the floor with "wall -subtype blocks" and reparing the scrap outline, the 
extended elevation looks little bit better.


> I also tried, after our discussion, to produced a large-scale "filled 
> galeries" map, on which I wanted to have only the scal and north arrow, but 
> no other headers... I have the feeling that I need redefine some tex-level 
> macros for that, but th ebook is not very useful, it only specifies layout 
> changes for the atlas. I have browsed through the tex sources, but I have nor 
> been able to identify the layout macro (or the header macro) for Maps.

In the configuration file, there is also simple-map layout, where also 
scale-bar is redefined (it is a 50 m line in both directions). Using it, you 
should be able to align the cave on the topo-map (the coordinate grid will be 
present in some future version of therion).



Using your files, I have found some another serious bugs in therion, I'll try 
to repair them as soon as possible. I have attached the files I have modified.

Regards, S.