Re: [Therion] Revisiting Breaking extended elevations on specific stations

[Bruce Mutton via Therion]

Stacho

Stop seems like a keyword that probably evokes the right expectations from a 
user.

Although, what are you thinking that a description of what it does would look 
like?

 

extend stop 8 7

 

Maybe, “when extending along leg 8 7, stop at 7, backup and start extending at 
the next part of the centreline that needs to be extended”.

Or would it exactly mimic the extend ignore 8 7 extend ignore 7 8 behaviour 
shown in the log in my 8 July email, which stops generating at station 8, then 
backs up, and eventually assigns itself a second start station to patch up an 
orphaned leg?

 



What would be the expected behaviour of extend 8 7 if the centreline were to be 
extending from the right, starting at 11?

 

And as a general question…

Are extend statements processed in the sequence they are written, or are they 
all read by Therion before Therion chooses the best order to process them (as 
it does with survey data)?

 

Bruce

 

From: Therion  On Behalf Of Stacho Mudrak
Sent: Wednesday, 15 July 2020 17:43
To: List for Therion users 
Subject: Re: [Therion] Revisiting Breaking extended elevations on specific 
stations

 

Hi, after returning from the caving trip, I would like to finish this topic.

 

For me, adding another parameter to extend is a little bit problematic, I would 
prefer some new keyword.

 

What do you think about:

 

extend stop 8 7

 

S.

 

On Wed, 8 Jul 2020 at 11:01, Tarquin Wilton-Jones via Therion 
mailto:therion@speleo.sk> > wrote:

> How about...
> extend ignore 8 7 [ (from) | to ]
> ... since we already use the from and to keywords with respect to stations at 
> each end of a survey leg?

It's all good by me.

The only reason I didn't suggest that keyword is that Therion is
stepping through my loop backwards. So a user might assume that the "to"
station is the "to" station from their data, when actually it is the
"to" station from the "extend ignore" pair.

But as long as people think it is intuitive enough, carry on :)
___
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] Joining maps with the join command

[Bruce Mutton via Therion]

>Sadly the only error message I see is "invalid map item"

 

Common mistakes I have made;

*   Forgetting to have an 'endmap' statement
*   Mixing scraps and maps within the same map definition
*   Missing a dash at the start of an option such as ‘-title’
*   Forgetting one of more “ surrounding a string (such as in -title “map 
title string”)

 

But looking at your original post, I think maybe you have a join inside a map 
definition.

Joins should be inside the survey, not inside the map.

 

Brue

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

Re: [Therion] Joining maps with the join command

[Bruce Mutton via Therion]

Tarquin

As Benedikt mentioned, scraps are joined, not maps.  If you join scraps, the 
maps that use those scraps will automatically show the join, so the maps 
themselves are not relevant to the joining process.

I have an example of a three cave system that we surveyed and subsequently 
joined in 2007-2008.  The highlighted words are the names of the respective 
cave surveys.

 

For one of the joins, we could use a simple (and recommended) scrap to scrap 
join, using scrap_ids;

 

  join GreenlinkUSumpsPlan_s2@Greenlink GreenlinkFPlan_s1@MiddleEarth  -smooth 
on

 

For the other pair of caves, I have lots of lines within each scrap that 
crossed from one to the other, so I had to use the more complicated line by 
line joining, that you seem to be trying to follow, using line_ids;

 

   join jpwall04@SwissM:end GUSwall02@Greenlink:end 

   join jpwall03@SwissM:00  GUSwall01@Greenlink:0 

 

   join jpwall06@SwissM:end GUSwall03@Greenlink:0

   join jpwall07@SwissM:end GUSwall04@Greenlink:end  

   

join uwall04@SwissM:0 swall02@Greenlink:end

join secondwall01@SwissM:0 swall05@Greenlink:end

 

Although looking at it now, with the benefit of 10 more years of experience, I 
wonder if I could have used a simpler scrap to scrap join, with the -count 3 
option.  [Refer to the description of join on page 40-41 of The Therion Book].

Depending on the details of your data structure, there may need to be subtle 
differences in the way you reference the scraps, but looking at your 
description below, I think the style of scrap referencing I have used should 
work for you (probably).  If it does not, you could try removing the 
(highlighted) cave survey names.

 

Bruce

 

 

-Original Message-
From: Therion  On Behalf Of Tarquin Wilton-Jones via 
Therion
Sent: Sunday, 14 April 2019 05:32
To: therion@speleo.sk
Cc: Tarquin Wilton-Jones 
Subject: [Therion] Joining maps with the join command

 

Hi,

 

I am currently learning how to use Therion to draw up a detailed survey.

 

My survey is split into several "caves", each of which has its own .th and .th2 
file. In the .th file for each cave is a separate "map", so that the cave can 
be rendered separately.

 

cave1.th:

survey cave1

input "cave1 plan.th2"

input "cave1 ee.th2"

map cave1MP

  scrap1

  scrap2

endmap

centreline

  ...

endcentreline

endsurvey

 

cave2.th:

survey cave2

input "cave2 plan.th2"

input "cave2 ee.th2"

map cave2MP

  scrapa

  scrapb

endmap

centreline

  ...

endcentreline

endsurvey

 

Then I have an overall file which combines the maps called allcaves.th:

survey allcaves

map allcavesMP

  cave1MP@cave1

  cave2MP@cave2

  join 

endmap

centreline

  ...

endcentreline

endsurvey

 

Imagine the two caves join in scrap1 (id "foo":0) and scrapb (id "bar":end), 
and I want to use a join command to make the scraps join neatly (I have already 
positioned the passage ends very close to each other). Could you please tell me 
the syntax needed to make the join command reference the correct points of the 
correct lines inside the correct scraps inside the correct maps?

 

Every example of the "join" command I could find assumes you were trying to 
join scraps inside the same map, and did not show how to reference items in a 
sub-map. As a result, I have not been able to work out how to construct a valid 
join command for this situation.

 

Many thanks for any information you can provide.

 

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] FYI - scrap is too large to process in metapost in this scale - maximal scale for this scrap is

[Bruce Mutton via Therion]

Possibly, but probably not, related to the issues with coordinates, that
seem to be resolved just now with eddb4c3.

 

I have one thconfig file, (in amongst a large project with many thconfigs
that work just fine), with a mysterious scale related error.  I suspect this
must be of my own making, and not a Therion bug.  

 

C:\Program Files (x86)\Therion\therion.exe: error -- scrap
RiwakaResurgenceRoughPlan-s1@RiwakaResurgence.RiwakaArea.RiwakaSystem
defined at ./RiwakaArea/./RiwakaResurgenceCave/RiwakaResurgenceRoughPlan.th2
[9] is too large to process in metapost in this scale -- maximal scale for
this scrap is 1 : 210

 

The scale I am using is 1:5000, which I assume is considered smaller than
the 1:210 that is being complained about by Therion.

This is a thconfig for a large project that I only tend to run once every
year or so, therefore I'm not sure when the problem manifested.

I have not figured out why the all component caves compile OK, but the whole
system fails.

 

Unless anyone has any brilliant insights I'm not really seeking a solution
from the forum just yet.  I have yet to find time to explore all the
possible mistakes I may have made.  I have tried removing the offending
scrap from it's parent map, but then another scrap in a completely different
cave triggers the same error.

 

All the same, any insight gratefully received.

 

Bruce

 

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

Re: [Therion] 5.4.3 has broken output cs conversions

[Bruce Mutton via Therion]

Thanks Stacho, prompt work.

Therion 5.4.3+eddb4c3 (2019-03-08) compiles and converts the coordinates just 
fine on a number of my projects.  So I think it is good.

 

The tex outcsname variable is still broken, whereby the cs code is output 
rather than the cs name, so I take it this one is still outstanding.

 

Bruce

 

From: Therion  On Behalf Of Stacho Mudrak via Therion
Sent: Saturday, 9 March 2019 02:41
To: List for Therion users 
Cc: Stacho Mudrak 
Subject: Re: [Therion] 5.4.3 has broken output cs conversions

 

Hi Bruce,

 

thanks for finding this serious bug out. It should be fixed in the latest 
commit. Could you please check, whether it works for you?

 

S.

 

On Thu, 7 Mar 2019 at 10:43, Bruce Mutton via Therion mailto:therion@speleo.sk> > wrote:

Therion version 5.4.3 and subsequent development versions have broken the 
functionality whereby coordinates entered with a variety of coordinate systems 
are converted to a user selected coordinate system for output.

The 5.4.2 output attached is from the last installation file I have that gives 
a correct output (all coordinates start with 159), and the next one, 5.4.3 and 
all subsequent versions have coordinates some 1000 km apart.  It makes it a 
very long cave, but unfortunately two of the entrances are in the middle of the 
pacific ocean!  The problem is that Therion is assuming that they are all in 
the  chosen output coordinate system, but it is not performing any conversion.  
No errors are reported (although there are mysterious scale related errors in 
other datasets that could be as a result of this problem).

 I am using these coordinate systems for input; 

cs EPSG:2193  #NZ Transverse Mercator 2000

cs EPSG:27200 #NZ Map Grid 1949

cs lat-long 

and for output in this case I am using;

cs EPSG:2193  #NZ Transverse Mercator 2000

Bruce

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

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

[Therion] tex outcsname variable broken

[Bruce Mutton via Therion]

It seems a problem with the outcsname token register has been introduced
with release 5.4.3.

Instead of containing the output coordinates system name, it now contains
the output coordinates system code.

As below, stepping through recent Therion releases. 

 

Version 5.4.2 creates this in my customised header;



 

.as does therion 5.4.2+16a5e3e (2019-01-17)

 

But 5.4.3 and all subsequent versions create this;



 

Bruce

 

 

 

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

Re: [Therion] SVG output gives blank file and compiling error

[Bruce Mutton via Therion]

I have compiled a small section of SludgePit and it produces proper svg and 
xhtml files on Windows 10.
I've sent Andrew a small dataset of mine for him to test.
Bruce

-Original Message-
From: Therion  On Behalf Of Andrew Atkinson via 
Therion
Sent: Tuesday, 26 February 2019 22:48
To: therion@speleo.sk
Cc: Andrew Atkinson 
Subject: Re: [Therion] SVG output gives blank file and compiling error

Are your files available so that I can see if they work on my machine?

My files are on the link sent in the original email.

http://www.cave-registry.org.uk/svn/WookeyCatchment/SludgePit/

If you have time could you try to compile them, we can then find out if it is 
my mistake or maybe a Linux bug

thanks

Andrew

On 26/02/2019 06:22, Bruce Mutton via Therion wrote:
> Andrew
> Not sure if this is helpful or not.
> I just compiled a random project that I am working on just now.
> svg files are produced OK.  The label text spacing is rubbish however.
> xhtml files are produced OK. They have a header and the text spacing seems 
> just fine.
> 
> Using therion 5.4.3+d0538ee (2019-02-01) on Windows 10
> 
> Bruce
___
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] Depth in the header

[Bruce Mutton via Therion]

Hi Xavier

I ran your example, just to check that it compiles as provided, and it does.  I 
have not tried to unpick it – no time at present.

I think you have exhausted my metapost knowledge already, and come to the same 
road blocks and questions that I have previously experienced (converting 
variable types, doing maths with them, and parsing them from procedure to 
procedure (from file to file).

:)

Bruce

 

From: Therion  On Behalf Of Xavier Robert via Therion
Sent: Tuesday, 26 February 2019 10:16
Subject: Re: [Therion] Depth in the header

 

Hi Bruce  !

 

Thanks a lot for your answer, it has given me some ideas (I try to be synthetic 
and hopefully understandable, but I am really far to be a Tex guru, I may 
misunderstand this language) :

 

If I manually define a reference altitude that is the altitude of the main 
entrance, this is easy to calcul the depth for the header:

+[Max. altitude of the cave - ref. altitude] / [Min. altitude of the cave - 
ref. altitude]. 

 

I thus tried to do that by combining a thconfig (where I should define the 
altitude reference) and a config.thc (where I should define the layouts and Tex 
codes to perform all the calculs and tweek the header) files to port the coding 
to multiple thconfig's files (see attachements, I tried to comment all my 
changes and my problems):

*   In the config.thc, I wrote 3 layouts

*   a layout langue-en that define some variables in english (Presently, I 
also have the same in french and spanish). This is where I also define all the 
new tokens I eventually use in my layouts (clubs, synthesys, webpage,...). This 
is working very well.
*   a layout headerl where I define all what I want to write in my header. 
I used the models from the Therion Wiki, and arrange it a bit to my desires... 
I specially wrote a section to modify the depth (between TEST / END TEST). This 
part seems OK, depending on the type of variables used (see further).
*   a layout Testdepth : this is the layout where I calcul the altitude 
differences above and under the entrance inside a code tex-map - endcode block. 
Here, I have a problem: If I do this calcul by using directly numbers (i.e. I 
need to give the values as numbers [e.g. \edef\cavemaxzc{1008}], and not as 
variable[e.g. \edef\cavemaxzc{\the\cavemaxz}]), it is OK. If I try to use 
counters or token, I receive an error. The problem is that if I want to be able 
to use this code for a lot of caves, I need to be able to give the value of the 
tokens \cavemaxz and \caveminz. (I tried with \the\cavemaxz or 
\number\cavemaxz, and that does not work).

*   In the thconfig, I made 3 changes to change the depth in the header:

*   I manually define the variable \altref that correspond to the altitude 
of the entrance. If I declare the variable as a token (\newtoks) or a counter 
(\nexcount), I get an error: ! Missing number, treated as zero. {l.765 \newcount\altref \altref{1000}. I need to define it as 
\edef\altref{1000}. If this variable is empty, I also have an error, probably 
because this variable is not passed to the layouts in config.thc
*   I call the layout Testdepth from the config.thc. In that case, I have 
the error: ! Missing number, treated as zero \relax l.755 
...hc = \numexpr \cavemaxzc - \altref \relax. It seems that the variable 
\altref that I defined is not passed to the Tex code in the layout Tesdepth. I 
fear that is because this new defined variable is not a token. May I true ?

*   If I copy the layout Testdepth from the config.thc and paste it inside 
the layout my_layout from the thconfig (while I comment the line copy 
Testdepth), it does work, if the \cavemaxz and \caveminz are defined as numbers 
and not as token or counters. If this variable is empty, I also have an error, 
probably because this variable is not passed to the layouts in config.thc. (On 
the contrary, the new counters \maxdepthc and \mindepthc are passed !)

If I good understood, in Tex, a token is not a number, and thus we cannot 
directly make any calculs with it. We need to translate it to a number.

 

Moreover, it seems that if we want to pass variables between layouts that are 
stored in different files (i.e. here config.thc and thconfig), the variable 
needs to be defined everywhere as tokens (or counters ?).

 

So I suppose that I need to find a way to translate a token or a counter into a 
number. Does anyone know how to do that?

 

Sorry for this long email,

Cheers,

 

Xavier

 

  _  

De: "List for Therion users" mailto:therion@speleo.sk> >
Envoyé: Jeudi 21 Février 2019 14:33:34
Objet: Re: [Therion] Depth in the header

 

Kia Ora Xavier

I don’t have a proper answer for you.  It would seem to me that this is too 
complicated to become a built in feature.  As you suggest, for an export of one 
cave the problem might be easier to solve, but where many caves are exported it 
might be difficult to conceive an automated approach.

 

Maybe an easier thing to code 

Re: [Therion] SVG output gives blank file and compiling error

[Bruce Mutton via Therion]

Andrew
Not sure if this is helpful or not.
I just compiled a random project that I am working on just now.
svg files are produced OK.  The label text spacing is rubbish however.
xhtml files are produced OK. They have a header and the text spacing seems just 
fine.

Using therion 5.4.3+d0538ee (2019-02-01) on Windows 10

Bruce

-Original Message-
From: Therion  On Behalf Of Andrew Atkinson via 
Therion
Sent: Tuesday, 26 February 2019 02:11
Subject: [Therion] SVG output gives blank file and compiling error

Using 5.4.3ds1-4 on Debian testing

The thconfig.thc at

http://www.cave-registry.org.uk/svn/WookeyCatchment/SludgePit/

works fine for pdf map output, but if I try to output svg a file is produced 
that does not display in any of the svg programs I have. It also does not 
finishing compiling giving a red ERROR in xtherion

The log file just seems to stop
...
I have also tried xhtml which the manual says is  SVG embedded in XHTML file 
which contains also legend
and only a legend is produced. Spent a while looking at the manual and wiki 
pages, and not finding my mistake, can anyone help
thanks

Andrew

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

Re: [Therion] Depth in the header

[Bruce Mutton via Therion]

Kia Ora Xavier

I don’t have a proper answer for you.  It would seem to me that this is too 
complicated to become a built in feature.  As you suggest, for an export of one 
cave the problem might be easier to solve, but where many caves are exported it 
might be difficult to conceive an automated approach.

 

Maybe an easier thing to code would be something where the user could just 
choose a reference altitude to use as a notional zero altitude for your user 
defined metapost?  

 

Personally I do not care much for the height relative to entrances, and I have 
modified the header to report height like this.



Together with gridlines and altitude points throughout the map, the user of the 
map can do their own maths!

 

Regarding ‘caves’ and ‘main entrances’, I explored some ideas in the wiki here 

  

 

Regards

Bruce

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

Re: [Therion] Morphing of background scketches fails on Win10 when Therion installation path contains spaces

[Bruce Mutton via Therion]

And Therion 5.4.3+d0538ee (2019+02+01)
Bruce

-Original Message-
From: Therion  On Behalf Of Duncan Collis via Therion
Sent: Friday, 15 February 2019 00:26
To: List for Therion users 
Cc: Duncan Collis 
Subject: Re: [Therion] Morphing of background scketches fails on Win10 when 
Therion installation path contains spaces

Hi, Bruce.

Hmm, that's interesting. There must indeed be more to it. I suspect it will 
require a bit of poking around in the code to figure it out.
However unless there are users who encounter this problem for whom the 
workaround I described doesn't work, I don't think it need to be looked at with 
any urgency.

Best regards,
Duncan.

On 14/02/2019, Bruce Mutton via Therion  wrote:
> The space in the Therion install path may not be the whole story.
> The path to my installation of Therion is C:\Program Files 
> (x86)\Therion , which has two spaces, and I have no problem compiling 
> a map with 'sketches on' and -sketch  set for some scraps.
>
> Windows 10 Home v 1803
>
> Bruce
>
> -Original Message-
> From: Therion  On Behalf Of Duncan Collis 
> via Therion
> Sent: Thursday, 14 February 2019 20:02
> To: List for Therion users 
> Cc: Duncan Collis 
> Subject: [Therion] Morphing of background scketches fails on Win10 
> when Therion installation path contains spaces
>
> Hi,
>
> Another problem I encountered when trying to morph background 
> sketches, this time with an easy workaround which I am posting here in 
> the hope that it will of use to someone.
>
> With Therion installed in:
>
>D:\Program Files\Therion
>
> the following error appears in the compiler window when trying to 
> morph background sketches:
>
> 'D:\Program' is not recognized as an internal or external command, 
> operable program or batch file.
>
> Reinstalling Therion in:
>
>D:\Therion
>
> solves the problem, which seems to be due to the space in the original 
> installation path.
>
> Best regards,
>
> Duncan.
> ___
> 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 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] Morphing of background scketches fails on Win10 when Therion installation path contains spaces

[Bruce Mutton via Therion]

The space in the Therion install path may not be the whole story.
The path to my installation of Therion is C:\Program Files (x86)\Therion , 
which has two spaces, and I have no problem compiling a map with 'sketches on' 
and -sketch  set for some scraps.

Windows 10 Home v 1803

Bruce

-Original Message-
From: Therion  On Behalf Of Duncan Collis via Therion
Sent: Thursday, 14 February 2019 20:02
To: List for Therion users 
Cc: Duncan Collis 
Subject: [Therion] Morphing of background scketches fails on Win10 when Therion 
installation path contains spaces

Hi,

Another problem I encountered when trying to morph background sketches, this 
time with an easy workaround which I am posting here in the hope that it will 
of use to someone.

With Therion installed in:

   D:\Program Files\Therion

the following error appears in the compiler window when trying to morph 
background sketches:

'D:\Program' is not recognized as an internal or external command, operable 
program or batch file.

Reinstalling Therion in:

   D:\Therion

solves the problem, which seems to be due to the space in the original 
installation path.

Best regards,

Duncan.
___
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] Inconsistent SELECT behaviour for pdf and xvi map output with background sketches..

[Bruce Mutton via Therion]

Duncan
I think your experience is more or less consistent with that here 
https://therion.speleo.sk/wiki/outputs#map_xvi_therion that I experimented with 
4-5 years ago.
One observation I made was that exporting a map to xvi actually produced 
something more akin to a model.  In those pages I did not have any -sketch 
specified with the scraps, so I guess all Therion had to work with was the 
centreline (model).
Although I don't think there is anything about on that wki page, I recall that 
xvi map exports are a bit 'scattergun' in that they do not respect the limits 
of the selected map.  
Maybe if a survey is selected rather than a map you may have better xvi control?
Have a look at this table 
https://therion.speleo.sk/wiki/outputs#map_xvi_therion, it may provide some 
insight.  It may no longer be current, and there may have been mistakes in it 
from the start.  Any feedback welcome.

Bruce

-Original Message-
From: Therion  On Behalf Of Duncan Collis via Therion
Sent: Thursday, 14 February 2019 15:10
To: therion@speleo.sk
Cc: Duncan Collis 
Subject: [Therion] Inconsistent SELECT behaviour for pdf and xvi map output 
with background sketches..

In my th2 file I've got scraps with -sketch specified, and stations placed to 
enable warping/morphing of these background images.

In th2 a map is defined (let's call it map_A) which includes the scraps I want.

Then in .thconfig:

select map_A

layout morph
  scale 1 500
  grid bottom
  grid-size 100 100 100 m
  sketches on
  grid off
endlayout

# Output plan in Therion pdf format
export map \
  -projection plan \
  -format pdf\
  -output map_A.pdf \
  -layout morph

# Output plan in Therion xvi format
export map \
  -projection plan \
  -format xvi\
  -output map_A.xvi\
  -layout morph

PDF output is as expected from the manual. It shows the background images 
attached to the scraps in the selected map, plus only the parts of the 
centreline that are used in those scraps. However if I change the export 
command to use XVI format, I get the background images and the centreline for 
the whole project, which contains over 20,000 stations. This is very difficult 
to use as it takes a long time for XTherion to load it, and then the area I'm 
interested in is tiny compared with the whole drawing area, so it requires 
quite a bit of zooming and scrolling to get there before I can start working.

Am I right in thinking that the XVI output should contain the same bits of 
centreline as appear in the PDF output, rather than the whole lot? Am I missing 
something?

Also: 'grid off' does not seem to affect the XVI output, which is why I've 
specified a fairly large grid size so that the grid isn't obscuring the 
sketches. I'd really like to be able to disable the grid in XVI completely.

Is there a way to achieve these two things?

Best regards,

Duncan.
___
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] Changing text on the legend

[Bruce Mutton via Therion]

Hi Bill

Not sure what is going wrong (just perused your files, I have not compiled
them).

I have had no such problems, and cannot see any significant differences to
what I am doing for symbols that do not exist as a Therion default ,
although I have only user defined points and lines, not areas.

 

Here are some examples that work in my thconfig file just fine (rope is
perhaps a bad example, as I think it is now a default symbol, however it was
not when I first created this many years ago).

text en "line u:rope""rope" #text to appear in legend 

text mi "line u:rope""taura"

text fr "line u:rope""corde"

text en "line u:heyphone""hey phone antenna" 

 

In the particular case of rope, have small differences associated with
symbol definition, that I don't expect are relevant, but maybe.

1.  No semi colon after initsymbol (seems like it is a mistake on my
part, but it seems like it has not ever caused me problems).
2.  I have defined the 'shape' of the symbol in the legend.

 

initsymbol("l_u_rope")

 

def l_u_rope_legend =

l_u_rope(((.2,.2) -- (.8,.8)) inscale)

enddef;

 

Don't expect this will help, but maybe.

Bruce

 

-Original Message-
From: Therion  On Behalf Of Bill Gee via Therion
Sent: Saturday, 9 February 2019 10:01
To: therion@speleo.sk
Cc: Bill Gee 
Subject: [Therion] Changing text on the legend

 

Hello everyone -

 

This has been annoying me for a while.  Time to see if there is a fix ...

 

I have defined quite a few custom symbols, and I have redefined some of the
symbols that are included with Therion.  When Therion prints the legend,
those symbols get labels like "area u:pavement".

 

I added some text lines to the thconfig file, but that has no effect.  A
close reading of the Therion Book tells me that text substitution only works
for text strings that are part of the language pack.  That implies it does
NOT work to re-label symbols in the legend.  Is that true?

 

The attached file is a sample cave.  The PDF file shows the incorrect
strings in the legend.  The two custom symbols on this map are defined
below.

 

code metapost

# Define an area fill for pavement

beginpattern(pattern_pavement);

  draw (-0.7u, -0.2u)--(-0.1u, 0.2u) withpen pensquare scaled (0.04u);

  draw (0.1u, 0.2u)--(0.7u, -0.2u) withpen pensquare scaled (0.04u);

  patternxstep(1.6u);

  patternystep(0.50u);

endpattern;

 

def a_u_pavement (expr Path) =

  T:=identity;

  thclean Path;

  thfill Path withpattern pattern_pavement;

enddef;

 

# Define an area fill for tiled floor

beginpattern(pattern_tiles);

  draw (-0.1u, -0.1u)--(-0.1u, 0.1u)--(0.1u, 0.1u)--(0.1u,
-0.1u)--cycle;

  patternxstep(0.3u);

  patternystep(0.3u);

endpattern;



def a_u_tiles (expr Path) =

  T:= identity;

  thclean Path;

  thfill Path withpattern pattern_tiles;

enddef;





# Initialize the new symbols

initsymbol ("a_u_pavement");

initsymbol ("a_u_tiles");

 

endcode

 

 

Thanks!

-- 

Bill Gee

 

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

[Therion] Android emulator

[Bruce Mutton via Therion]

Has anyone used an Android Emulator on Windows to view or edit TopoDroid or
SexyTopo files?

My desire is to be able to view such files on any device that can process a
Therion dataset, once they have been incorporated into the overall project.

I see there are lots of them out there, but I may as well start with
something that a Therion user has already successfully used.

These two look reasonably interesting;

ARChon  

Bliss OS  

 

Recommendations?

 

Bruce

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

[Therion] changed definition of drawing of centreline

[Bruce Mutton via Therion]

Hi

Interested in the change
  to the line survey (centreline)
examples in the wiki that Martin just made (I'm up for a modest amount of
metapost learning).

 

I can follow what the new more complicated metapost is doing, and can
understand that it might be better practice to do it that way.

But is there no place for the more direct and simpler 'draw p' approach?  Or
did it not work? (I have not tested them).

 

Perhaps both versions could be listed on the wiki, with some comment about
pros and cons or why one approach is better than the other?

 

Bruce

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

Re: [Therion] Showing qestion mark texts broken?

[Bruce Mutton via Therion]

This is what I use.  Slightly different to your example.

Code in my standard layout...

#CODE TO DISPLAY CONTINUATIONS (LEADS)
#
layout LayoutShowContinuationQmarkOnly
  #Show question marks only where continuations 
  #are flagged in survey or scrap
  
  symbol-show point flag:continuation
 
endlayout LayoutShowContinuationQmarkOnly

layout LayoutShowContinuationFullText
  #Show full text highlighted in pink where continuations
  # are flagged in survey or scrap
  
  code metapost
def p_continuation(expr pos,theta,sc,al) =
  % draw default continuation symbol ie ?
  p_continuation_UIS(pos,theta,sc,al);
  % if text attribute is set
  if known(ATTR__text) and picture(ATTR__text):
  % set labeling color to light orange
  push_label_fill_color(1.0, 0.9, 0.8);
  % draw filled label with text next to symbol ?
  p_label.urt(ATTR__text,(.5u,-.25u) transformed T,0.0,8);
  % restore original labeling color
  pop_label_fill_color;
  fi;
enddef;
  endcode
  symbol-show point flag:continuation
  
  
endlayout LayoutShowContinuationFullText


Code in my layout called from export statement.

#INVOKE LAYOUTS from INPUT files  
  #---
  #select NEITHER or ONE of the following, NOT both
  copy LayoutShowContinuationFullText
   # copy LayoutShowContinuationQmarkOnly

Bruce

-Original Message-
From: Therion  On Behalf Of Benedikt Hallinger via 
Therion
Sent: Sunday, 23 December 2018 00:12
To: List for Therion users 
Cc: Benedikt Hallinger 
Subject: [Therion] Showing qestion mark texts broken?

Hi,
i try to add a layout for showing the question mark texts.
For this i tried the additions from the websites:
a) https://therion.speleo.sk/samples.doc/60.html
b) http://marcocorvi.altervista.org/caving/tbe/m_05/m_054.htm
but neither seems to work. a) produces no change and b) triggers a compile 
error :(


This is a) implemented in my layout.conf (taken from the web)
---
layout showContinationText.inc
code metapost
 def p_continuation(expr pos,theta,sc,al) =

   % draw question mark above station:
   % rotation=0, scaling=1, offset=(0,2)
   %
   p_continuation_UIS(pos, 0.0, 1.0, (0, 2) );

   % if text attribute is set
   if known ATTR_text:
 % set labeling color to red
 push_label_fill_color(1.0, 0.0, 0.0);

 % draw filled label with text below station
 p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8);

 % restore original labeling color
 pop_label_fill_color;
   fi;
 enddef;
   endcode
endlayout


and my thconfig export command includes this: "-layout 
showContinationText.inc", which in other cases is enough to activate it. 
The layout file is also loaded, i checked that.
However, no text is shown...

What am i doing wrong?


With best regards and happy christmas!
___
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] Showing qestion mark texts broken?

[Bruce Mutton via Therion]

> and my thconfig export command includes this: "-layout 
> showContinationText.inc", which in other cases is enough to activate it.

Hi Benedikt
Does the above statement mean that you have other projects where the 'show 
continuation text' has worked properly and it is just stopped working for this 
project?
Or have you never used 'show continuation text' before?

I just checked one of my projects, and both my continuation layout metaposts 
are working just fine with the latest Therion release 5.4.1+a08b94e 
(2018-12-17) 

Bruce

-Original Message-
From: Therion  On Behalf Of Benedikt Hallinger via 
Therion
Sent: Sunday, 23 December 2018 00:12
To: List for Therion users 
Cc: Benedikt Hallinger 
Subject: [Therion] Showing qestion mark texts broken?

Hi,
i try to add a layout for showing the question mark texts.
For this i tried the additions from the websites:
a) https://therion.speleo.sk/samples.doc/60.html
b) http://marcocorvi.altervista.org/caving/tbe/m_05/m_054.htm
but neither seems to work. a) produces no change and b) triggers a compile 
error :(


This is a) implemented in my layout.conf (taken from the web)
---
layout showContinationText.inc
code metapost
 def p_continuation(expr pos,theta,sc,al) =

   % draw question mark above station:
   % rotation=0, scaling=1, offset=(0,2)
   %
   p_continuation_UIS(pos, 0.0, 1.0, (0, 2) );

   % if text attribute is set
   if known ATTR_text:
 % set labeling color to red
 push_label_fill_color(1.0, 0.0, 0.0);

 % draw filled label with text below station
 p_label.bot(ATTR__text, pos shifted (0,-0.5u), 0.0, 8);

 % restore original labeling color
 pop_label_fill_color;
   fi;
 enddef;
   endcode
endlayout


and my thconfig export command includes this: "-layout 
showContinationText.inc", which in other cases is enough to activate it. 
The layout file is also loaded, i checked that.
However, no text is shown...

What am i doing wrong?


With best regards and happy christmas!
___
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] topodroid to therion

[Bruce Mutton via Therion]

Hi Marco

Ah, so midline = the set of legs = centreline!

 

 

>>That is a good description.  I can see a wiki page developing from it. I 
>>don’t think I have seen similar information before?

> that info is in the user manual, more or less

 

The meaning I meant to convey was; I don’t think I have seen a description of 
exactly the settings and workflow TopoDROID users should use if they want to 
export their data for Therion to process, in one place, and step by step.  No 
doubt the detail is in the TopoDROID user manual, but it is scattered around, 
and interspersed with information that is not particularly useful for Therion 
users.  And little indication of what settings will make life pleasant or 
unpleasant for Therion users.  Many of the default settings seem to be Therion 
unfriendly, as evidenced by the examples posted on the Therion forum over the 
previous year or so, and my own subsequent experimentations.

 

I suspect what is missing is a user guide that describes what to do to ensure a 
pleasant Therion experience with data generated by TopoDROID.  Your post from 
3-4 December is the first time I recall seeing such a targeted user guide 
format, and I am wondering if a Therion wiki page based on your post might fill 
that gap.  I am happy to create the outline of a wiki page and fit it into the 
Therion wiki structure somehow.  If I start something, maybe someone else can 
fill in the gaps?

 

Regards

Bruce

 

 

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

Re: [Therion] topodroid to therion

[Bruce Mutton via Therion]

Hi Marco

That is a good description.  I can see a wiki page developing from it. I don’t 
think I have seen similar information before?

It is a while since I played with TopoDROID.  Is it the intention that one 
TopoDROID sketch produces, or is equivalent to, one matching pair of Therion 
scraps (plan and elevation)?

I am interested in the data naming conventions you use, to facilitate the 
tracing of parent and child object relationships (ie data files (TopoDROID and 
Therion) through to survey and scrap, for example).

And I should just check exactly what you mean by ‘mid-line’?  I have always 
been guessing. Is it the survey shot line that goes from ‘from station’ to ‘to 
station’?

 

Regards

Bruce

 

From: Therion  On Behalf Of Marco Corvi via Therion
Sent: Tuesday, 4 December 2018 03:41
To: therion@speleo.sk
Cc: Marco Corvi 
Subject: [Therion] topodroid to therion

 

Is there a workflow that is easy to use with ‘TopoDROID to Therion’ process, 
that also allows more than one scrap per survey trip file?  With limited 
experimentation (and making assumption that TopoDROID ‘sketches’ might be 
approximately equivalent to Therion ‘scraps’), I have not yet found a way that 
is easy to implement and encourages a naming convention that eases tracing of 
scraps to their parent TopoDROID file.  And breaking existing scraps into 
smaller scraps is a task I find unnecessarily tedious, when one could just have 
drawn smaller scraps in the first place.

Am I missing something obvious?  What are experienced Therion users who 
subsequently became proficient with TopoDROID as a data collector doing in this 
space?

 

--

topodroid has many features requested by users that probably use other programs 
than therion to draft their

cave maps,

 

anyways, i use therion for my cave maps, and here is what i do.

 

(0) a note3 with a stylus: reasonable compromise between the size of the 
android and that of the caves (lucky surveyors might go for a 7" tablet)

(1) enable only drawing tools that are supported by therion, otherwise i must 
go for metapost code

(2) each topodroid survey can have many sketches, and i usually draw several 
sketches, except for very simple surveys.

(3) switch off fractional 'extend"

(4) switch off loop closure compensation: better see potential blunders

(5) i usually use "normal" line style, and the decimation button to simplify 
them (if need arises)

(6) pre-exporting: check every sketch with joining sketches using the sketch 
outline feature, and make then fit nicely

(7) it may happen that a sketch needs to be splitted in two, but this is rare 
as i'm used to draw small sketches.

i never user sketch merge

(8) i use automatic station points, even if, unfortunately,

topodroid puts in all the stations in the convex hull of the sketch, and there 
can happen spurious ones. i do not remember if midline hide helps for this, 
however, midline hide is something i use only when the midline is very messy, i 
usually go over the station points and remove those that do not belong to the 
piece of midline of the skatch: this is easily done with a "good" text editor

(9) i usually do not use "line continuation", but i fix the gaps between wall 
lines with point line editings (snap to point and merge with line). i sometimes 
use the feature that shifts a portion of a line, but i find often easier to 
redraw the line and erase the old one.

(10) i have the feeling that outline is no longer very important to therion (it 
is however for csurvey, but this is ot on this list), thus i do not pay much 
attention that wall lines are properly oriented. anyways when i notice a line 
should be reversed i do it, as it's quick

(11) automatic export because it's a nuisance to export each sketch

(12) ... other things i do not recall at the moment

 

marco

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

[Therion] TopoDROID to Therion process with respect to scraps

[Bruce Mutton via Therion]

If I may ask a question unrelated to Thorir’s original post topic …

 

> try to make shorter scraps. There is no problem if you’ll create many short 
> scraps.

 

I agree with Martin’s statement above, however I wonder how to approach it if 
the survey data and drawing was created with TopoDROID, as it appears Thorir’s 
example was.

 

Is there a workflow that is easy to use with ‘TopoDROID to Therion’ process, 
that also allows more than one scrap per survey trip file?  With limited 
experimentation (and making assumption that TopoDROID ‘sketches’ might be 
approximately equivalent to Therion ‘scraps’), I have not yet found a way that 
is easy to implement and encourages a naming convention that eases tracing of 
scraps to their parent TopoDROID file.  And breaking existing scraps into 
smaller scraps is a task I find unnecessarily tedious, when one could just have 
drawn smaller scraps in the first place.

 

Am I missing something obvious?  What are experienced Therion users who 
subsequently became proficient with TopoDROID as a data collector doing in this 
space?

 

Bruce

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

Re: [Therion] Line artifact on scrap

[Bruce Mutton via Therion]

Þórir

I am not sure what that artefact is, but I often see it as well.  I think it is 
related to the scrap scaling feature.  I am not concerned about it because it 
has never had any negative impact on my drawing experience and nor does it 
appear in outputs.

 

Ie selecting a line



 

Then selecting the scrap which contains that line…



But I think it is completely harmless.

 

 

In the example file you submitted, I would be concerned about the point density 
and the size of the file (8800 lines).  And all in one scrap!  Those factors 
will make it difficult to work with in Therion, especially if you need to 
string together a number of files like this to map a cave or caves.

 

Regards

Bruce

 

From: Therion  On Behalf Of Thorir Jonsson via 
Therion
Sent: Sunday, 2 December 2018 06:49
To: List for Therion users 
Cc: Thorir Jonsson 
Subject: [Therion] Line artifact on scrap

 

I have a strange artifact on a scrap I am working on, that I can't seem to 
select or get rid of (see attached screenshot). It is always drawn in red and 
no matter what I do I can't select it or get rid of it. Any Ideas as to what 
might have caused this or how I can remove it?

 

Cheers,

Þórir Már

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

Re: [Therion] Add Coordinate data back at last level of Survey Hierarchy?

[Bruce Mutton via Therion]

Not sure I understand you situation properly.  And I have no experience using 
.3d files as input.

However, in general...

If you have multiple surveys, each with a different (but not arbitrary) 
coordinate system set, then there should be no problem if you identify the 
coordinate system in each low level (survey trip) survey.  Each one can be 
different.  ie cs lat-long in one, cs EPSG:27200 in another, and cs EPSG:2193 
in another.  On occasion I specify multiple cs in each input file.

Then you can specify the output coordinate system in the thconfig file.  If 
more than one is specified in the thconfig, then only the last one is used.   
Ie all outputs must share the same cs.

Looking at the wiki and Therion Book, I am not sure that the input side of this 
problem is well documented.

Bruce

-Original Message-
HI,

I was trying to join a file [with Centreline driven by .3d data (.3d)] to 
another file [with centreline driven by my electronic surveying data (Elec)].

The .3d file seems to come with it's own coordinate system, so we needed to 
remove(#) the entrance coordinates, from the Elec data.

I have joined these two surveys in a .th file and successfully got an output. 
There are two entrances to the system.

So my question is, can I add back coordinate data for one (or more) Entrance(s) 
at the last level of the survey hierarchy? or will the mismatch between .3d and 
Elec prevent me from doing this?


 Regards,
 Alastair Gott.
 
 alastairg...@hotmail.com,
 M: 07931779380,
   
___
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] mark [(Station list)]

[Bruce Mutton via Therion]

The mark [station list]  statement allows you to differentiate stations.

 

For example, I use natural to refer to a speleothem or pointy rock that is a 
station, and fixed to represent a rock cairn, or artificial insert.  The 
default ‘temporary’ is for ephemeral stations that cease to exist once the 
survey has moved on.

 

In a finished map, I symbol-hide the temporary stations, and show the others.  



 

Bruce

 

From: Therion  On Behalf Of Torsten Schnitter via 
Therion
Sent: Wednesday, 14 November 2018 22:54
To: therion@speleo.sk
Cc: Torsten Schnitter 
Subject: [Therion] mark [(Station list)] 

 

Hi

Can sombody explain what the switch:
mark [(station list)] 

from the command centreline does!?

As  one of the following ist allowed:
temporary (default)
painted
natural
fixed

I can't find an example and therefore do not understand the meaning of this 
switch.
Thanks!

regards,
Torsten

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

[Therion] Nautiz X8

[Bruce Mutton via Therion]

Hi Pavel

It might be difficult for me to get device to test before buying, so I just 
want to clarify the significance of this issue that you mentioned...

"it´s necessary to protect screen from drops of water, even small ones are 
registered and making some effect on screen".

 

You are using it a lot, as you mention, and I assume that you are using the 
device underground.  Therefore I assume that from time to time water droplets, 
wet mud and sand on the display are inevitable.  It happens for me all the 
time, and I wipe with my hand, lick the display clean (yuk), or wash it in a 
stream or from my water bottle.

*   Does this scenario make the X8 unusable for drawing and typing, or just 
mildly annoying?
*   What about wiping it with a cloth after washing it.  Does that fix it? 

(I have a non-caving device, that once wet, needs to be removed from the humid 
environment completely before the display will respond correctly - drying with 
a non-absorbent cloth is not sufficient - I want to make sure the X8 is not 
like this).

 

Regards

Bruce

 

-Original Message-
From: Therion  On Behalf Of Bruce Mutton via Therion
Sent: Saturday, 3 November 2018 18:02
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: [Therion] Nautiz X8

 

Thanks for the insights Pavel.

I can see those side buttons are in exactly the wrong place.

I too would be after the Windows version, I understand the Windows ones can run 
Android, but not vice versa.

So before proceeding I will check PocketTopo speed, stylus and water response.  
All our caves are such that devices are constantly wet and muddy while 
surveying. That the Nautiz display responds badly to water surprizes me, as our 
Trimble Recons have never responded to water (except once when swimming), and 
that assumption is the reason I am looking at them.

Regards

Bruce

 

-Original Message-

From: Therion < <mailto:therion-boun...@speleo.sk> therion-boun...@speleo.sk> 
On Behalf Of Pavel Herich via Therion

Sent: Saturday, 3 November 2018 03:18

To: List for Therion users < <mailto:therion@speleo.sk> therion@speleo.sk>

Cc: Pavel Herich < <mailto:her...@speleodd.sk> her...@speleodd.sk>

Subject: Re: [Therion] Nautiz X8

 

Hello,

i´m using it for more than two years now, 3 to 15 times per month. My device is 
built on windows, so there is PocketTopo installed. For me it works great, 
strong battery, quite big screen, I use to clean it just directly under the 
flowing water. But on the other hand, surprisingly PocketTopo turned out to run 
significantly slower than on the previous, old and cheap PDA (means menu 
reactions, context menu calling and so; it doesn´t affect bleutooth connection 
or any other core functionalities - anyway it could be just some settings 
error). Then, I had to replace stylus, which was very wide and not draw 
friendly, instead I use thin stylus from old PDA (metal core), which doesn´t 
works perfectly, but it´s much better to work with. As well, the screen is not 
so precise for drawing than on my old PDA, partly perhaps because of bigger 
screen, but I think the technology has been changed (you can use only plastic, 
thin protection of the screen to be able to use old and precise stylus). 

Also, the two buttons (arrows) on the left side of the device I found very 
annoying - there are right there, where one would hold the device, they manage 
volume, which is very necessary to work with inside the cave...; I will try to 
seal them once. And last thing, it´s necessary to protect screen from drops of 
water, even small ones are registered and making some effect on screen.

So that´s all troubles I noticed, otherwise you can count with this device 
anywhere.

But to use it just to draw a raw sketch in PocketTopo or Topodroid, it´s bit 
expensive (f.e. DigiTerra explorer - basic GIS software can be instaled).

Pavel

 

Dňa 2018-10-31 19:06 Bruce Mutton via Therion napísal(a):

> Good Morning.

> Does anyone have experience with these?

> Nautiz X8

> 

> https://www.handheldgroup.com/rugged-computer/handheld-pda/nautiz-x8/#tab=tecspec[1]
>  

> 

http://ruggedpcreview.com/3_handhelds_handheldus_nautiz_x8.html [2]

 

> https://www.handheldgroup.com/rugged-solutions/Customer-Solutions/nautiz-x8-extreme-environment-surveying-with-rugged-handhelds
>  

> 

> Bruce

 

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

[Therion] Therion ini linefeeds

[Bruce Mutton via Therion]

Torsten wrote

> I'm using a windows with Therion and if you have a look to the ini file there 
> are missing all line feeds.



I’m currently using Windows 10 with Therion development version dfe3c00 and 
have never noticed any problem.

But I recall some changes mentioned regarding linefeed behaviour in recent 
commits, so I thought I’d check with other editors.

 

So my preferred editor NotePad++ displays the linefeeds ini files correctly, as 
does WordPad.

But the NotePad application that ships with Windows 10 does not display the 
therion.ini linefeeds, except one.  The whole therion.ini file displays on two 
lines.  Xtherion.ini displays on about 7 lines with the linefeeds in random 
places, apparently midline.

 

As I never use the NotePad that ships with Windows it does not concern me, but 
maybe this is something that needs resolving or explaining so that other users 
are not inconvenienced.

 

Bruce

 

 

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

[Therion] Nautiz X8

[Bruce Mutton via Therion]

Thanks for the insights Pavel.
I can see those side buttons are in exactly the wrong place.
I too would be after the Windows version, I understand the Windows ones can run 
Android, but not vice versa.
So before proceeding I will check PocketTopo speed, stylus and water response.  
All our caves are such that devices are constantly wet and muddy while 
surveying. That the Nautiz display responds badly to water surprizes me, as our 
Trimble Recons have never responded to water (except once when swimming), and 
that assumption is the reason I am looking at them.
Regards
Bruce

-Original Message-
From: Therion  On Behalf Of Pavel Herich via Therion
Sent: Saturday, 3 November 2018 03:18
To: List for Therion users 
Cc: Pavel Herich 
Subject: Re: [Therion] Nautiz X8

Hello,
i´m using it for more than two years now, 3 to 15 times per month. My device is 
built on windows, so there is PocketTopo installed. For me it works great, 
strong battery, quite big screen, I use to clean it just directly under the 
flowing water. But on the other hand, surprisingly PocketTopo turned out to run 
significantly slower than on the previous, old and cheap PDA (means menu 
reactions, context menu calling and so; it doesn´t affect bleutooth connection 
or any other core functionalities - anyway it could be just some settings 
error). Then, I had to replace stylus, which was very wide and not draw 
friendly, instead I use thin stylus from old PDA (metal core), which doesn´t 
works perfectly, but it´s much better to work with. As well, the screen is not 
so precise for drawing than on my old PDA, partly perhaps because of bigger 
screen, but I think the technology has been changed (you can use only plastic, 
thin protection of the screen to be able to use old and precise stylus). 
Also, the two buttons (arrows) on the left side of the device I found very 
annoying - there are right there, where one would hold the device, they manage 
volume, which is very necessary to work with inside the cave...; I will try to 
seal them once. And last thing, it´s necessary to protect screen from drops of 
water, even small ones are registered and making some effect on screen.
So that´s all troubles I noticed, otherwise you can count with this device 
anywhere.
But to use it just to draw a raw sketch in PocketTopo or Topodroid, it´s bit 
expensive (f.e. DigiTerra explorer - basic GIS software can be instaled).
Pavel




Dňa 2018-10-31 19:06 Bruce Mutton via Therion napísal(a):
> Good Morning.
> 
> Does anyone have experience with these?
> 
> Nautiz X8
> 
> https://www.handheldgroup.com/rugged-computer/handheld-pda/nautiz-x8/#
> tab=tecspec
> [1]
> 
> http://ruggedpcreview.com/3_handhelds_handheldus_nautiz_x8.html [2]
> 
> https://www.handheldgroup.com/rugged-solutions/Customer-Solutions/naut
> iz-x8-extreme-environment-surveying-with-rugged-handhelds/
> [3]
> 
> Bruce
> 
> Links:
> --
> [1]
> https://www.handheldgroup.com/rugged-computer/handheld-pda/nautiz-x8/#
> tab=tecspec [2] 
> http://ruggedpcreview.com/3_handhelds_handheldus_nautiz_x8.html
> [3]
> https://www.handheldgroup.com/rugged-solutions/Customer-Solutions/naut
> iz-x8-extreme-environment-surveying-with-rugged-handhelds/
> ___
> 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 mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Nautiz X8

[Bruce Mutton via Therion]

Good Morning.  

Does anyone have experience with these?

 

Nautiz X8

 

https://www.handheldgroup.com/rugged-computer/handheld-pda/nautiz-x8/#tab=te
cspec

 

 
http://ruggedpcreview.com/3_handhelds_handheldus_nautiz_x8.html

 

 

https://www.handheldgroup.com/rugged-solutions/Customer-Solutions/nautiz-x8-
extreme-environment-surveying-with-rugged-handhelds/

 

Bruce

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

Re: [Therion] ***UNCHECKED*** Problem with elevation view

[Bruce Mutton via Therion]

Torsten

The image of the xvi file makes it look as though there is a loop (not sure if 
it is a plan or elevation view – presume it is elevation).  Also if you have a 
fixed point at each end, then this could also cause ‘a loop’ which might give 
differing elevations at each end.

Also, if the water is flowing, then the water levels at each end will actually 
differ.

 

But I assume you have correctly assessed these effects as negligible, or at 
least not detected by your survey method.

 

I think you are implying that the 0m line is a raster background.  If that is 
the case, it may be distorted by Therion.  One way to check would be to turn on 
gridlines for the layout.  That will show you what Therion really thinks is a 
horizontal line.

 

Also check that Therion has the water surface survey stations at the same 
altitude.  You can check this easily by interrogating a .3d output with Aven.

 

Bruce

 

From: Therion  On Behalf Of Torsten Schnitter via 
Therion
Sent: Tuesday, 30 October 2018 04:36
To: therion@speleo.sk
Cc: Torsten Schnitter 
Subject: [Therion] ***UNCHECKED*** Problem with elevation view

 

Hi all

I have a under water cave survey and all the data is done with depth 
measurements.
So the Z coordinates are absolute and the survey is not with clino data.
The cave starts at one point and after roughly 800m you have another surface 
point.

When I compile the data I get a strange behaviour.
Although it's not a WYSIWIG map editor I would expect points which have the 
same depth are at the same "depth"/level on the xvi file. But they are not (see 
attached screenshot "elevation problem").
The 2 points within the red marks do have the same depth measurements.
But if you have a closer look to it you can see they are not at the same level.
(They differ somehow in x/y way and therefore the points are not on top of each 
other.)
There are no loop closures inbetween which could be a reason for different 
levels.

Not having the same level with these points (I assume it is this point) leads 
to a bigger problem later on.
When drawing the elevation scraps and putting a water surface (depth = 0m) to 
the scraps and having a raster in the background, the surface at the beginning 
of the cave is not at the same level than at the next surface point of the 
cave. But it should be.
See pictures "elevation problem-start" and "elevation problem-end".

What's wrong?
Can anybody help?
If more info is needed please let me know.

Thanks,
Torsten

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

[Therion] overlaying maps

[Bruce Mutton via Therion]

Interesting.  The fact that red and green are not consecutive should not make a 
difference.

I don’t remember seeing this before.  As Martin suggests, it may be an issue 
with your particular viewer, try some other viewers to check this.

Or maybe it is an issue with ‘break’ as Torsten suggests, although that would 
normally manifest with equal width and full density lines.  Torsten’s 
suggestion hinting at other line types over the green walls deserves a look, 
but if that were the case, I would expect they would be grey also – as in the 
water in the red scrap near the word chem17.  I notice the word P5 presumably 
part of the green scrap renders correctly.  Are all your scrap lines actually 
associated with the scrap that you think they are?  No unintentional doubled up 
lines?

Bruce

From: Therion  On Behalf Of Martin KERN via Therion
Sent: Sunday, 21 October 2018 03:24
To: therion@speleo.sk
Cc: Martin KERN 
Subject: [Therion] overlaying maps

 

Hi,

I have a question about the overlaying maps. 

I drew a plan to explain that:

  

  

On my survey, the blue scrap is the n°1 and it is above the red (the second). 
Here the overlaying is good. 
The red scrap (n°2) is above the green (n°4). So, there is a scrap n°3 between 
the red (n°2 and the green (n°4). (It does not appear on my plan.)

My problem is that the overlaying of the red scrap over the green is not 
"normal". The lines are thinner. Why that? Because these two scraps are not 
consecutive?

I would like that they are as the other overlaid lines. It’s possible?

 

All these scraps are contained in the same map.

 

Thanks,

Martin

 

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

[Therion] DistoX2 zero distance reference points and end piece extension

[Bruce Mutton via Therion]

OK, I figured it out.  My mistake, to set the end piece extension, two
actions are required.

1.  Set the end piece zero offset using the FUNC button.
2.  Toggle the 'back' reference from 'back of case' to 'back of end
piece offset', using REF + FUNC (hold 2 seconds)

 

The new distoX2 now works as expected, although I still need to calibrate
it.

This IS mentioned in the user manual.

 

Bruce

 

From: Therion  On Behalf Of Bruce Mutton via
Therion
Sent: Sunday, 28 October 2018 10:19
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: [Therion] DistoX2 zero distance reference points and end piece
extension

 

I have an older distoX2 and a new distoX2, and came to thinking about
building a protective case.  Naturally the topics of zero reference points
and end piece extensions has come to mind.  Rather belatedly I thought I
would run a rudimentary test over a short ~250mm distance that I could
measure with a steel ruler, just to check my understanding of the behaviour.

 

It was not as I expected, and I have not found an explanation in any of the
documentation.  Maybe someone has similar experiences.

The newer distoX2 is not yet calibrated, and they both have differing
hardware and firmware versions, so either or both may be the cause of the
differences.  Perhaps a table is the best way to document what I have found.


Disto

Old

New


Hardware

1.0

1.1


Firmware

2.4

2.5


ID

2973

4036


End piece setting

0.012 m

0.060 m


Reference toggle cycle

End piece-front-tripod

Back-front-tripod


Comment

End piece extension reference option is available

End piece extension reference option is NOT available


End piece disto - ruler comparison

267 - 265 mm
works as expected

N/A


Back disto - ruler comparison

N/A

253 - 312 mm
end piece setting ignored, does not work as expected


Front disto - ruler comparison

132 - 131 mm

131 - 131 mm


Tripod disto - ruler comparison

245 - 243 mm

244 - 243 mm


Calibrated

Yes

Not yet


Apparent accuracy

1-2 mm

1 mm except with end piece

 

One explanation could be that the end piece zero reference is not available
and any end piece setting will be ignored until the distoX2 has been
calibrated.

I am hoping that is what the situation is, and it will be easy enough to
test, once I get around to it.  It does seem a bit odd however, as I assume
the calibration is all about directions, and not distances.

Thoughts?

Bruce

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

[Therion] DistoX2 zero distance reference points and end piece extension

[Bruce Mutton via Therion]

I have an older distoX2 and a new distoX2, and came to thinking about
building a protective case.  Naturally the topics of zero reference points
and end piece extensions has come to mind.  Rather belatedly I thought I
would run a rudimentary test over a short ~250mm distance that I could
measure with a steel ruler, just to check my understanding of the behaviour.

 

It was not as I expected, and I have not found an explanation in any of the
documentation.  Maybe someone has similar experiences.

The newer distoX2 is not yet calibrated, and they both have differing
hardware and firmware versions, so either or both may be the cause of the
differences.  Perhaps a table is the best way to document what I have found.


Disto

Old

New


Hardware

1.0

1.1


Firmware

2.4

2.5


ID

2973

4036


End piece setting

0.012 m

0.060 m


Reference toggle cycle

End piece-front-tripod

Back-front-tripod


Comment

End piece extension reference option is available

End piece extension reference option is NOT available


End piece disto - ruler comparison

267 - 265 mm
works as expected

N/A


Back disto - ruler comparison

N/A

253 - 312 mm
end piece setting ignored, does not work as expected


Front disto - ruler comparison

132 - 131 mm

131 - 131 mm


Tripod disto - ruler comparison

245 - 243 mm

244 - 243 mm


Calibrated

Yes

Not yet


Apparent accuracy

1-2 mm

1 mm except with end piece

 

One explanation could be that the end piece zero reference is not available
and any end piece setting will be ignored until the distoX2 has been
calibrated.

I am hoping that is what the situation is, and it will be easy enough to
test, once I get around to it.  It does seem a bit odd however, as I assume
the calibration is all about directions, and not distances.

Thoughts?

Bruce

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

Re: [Therion] overlaying maps

[Bruce Mutton via Therion]

Martin

The image did not come through to me in the message. Perhaps you could send it 
again as an attachment?

Bruce

 

From: Therion  On Behalf Of Martin KERN via Therion
Sent: Sunday, 21 October 2018 03:24
To: therion@speleo.sk
Cc: Martin KERN 
Subject: [Therion] overlaying maps

 

Hi,

I have a question about the overlaying maps. 

I drew a plan to explain that:

  

  

On my survey, the blue scrap is the n°1 and it is above the red (the second). 
Here the overlaying is good. 
The red scrap (n°2) is above the green (n°4). So, there is a scrap n°3 between 
the red (n°2 and the green (n°4). (It does not appear on my plan.)

My problem is that the overlaying of the red scrap over the green is not 
"normal". The lines are thinner. Why that? Because these two scraps are not 
consecutive?

I would like that they are as the other overlaid lines. It’s possible?

 

All these scraps are contained in the same map.

 

Thanks,

Martin

 

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

Re: [Therion] Cave-list command - imperial units

[Bruce Mutton via Therion]

Bill Gee wrote

> However - The output is all in metric, and not even labeled as such.  Is 
> there a way to either label it or (preferably) to use imperial units?


Hi Bill
Not aware of units control for the cave-lists.  I am lucky enough to be metric 
I'm afraid.
Bruce

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

Re: [Therion] Cave-list command

[Bruce Mutton via Therion]

See also https://therion.speleo.sk/wiki/outputs#lists 

 

From: Therion  On Behalf Of Bruce Mutton via Therion
Sent: Thursday, 4 October 2018 20:41
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: Re: [Therion] Cave-list command

 

Like this?



 

export cave-list \

  -surveys on   \

  -location on \

   -output ./Output/RiwakaSystemCaves.html 

   #for html set surveys on, AND location on to see all entrances as well as 
caves

 

Bruce

 

From: Therion mailto:therion-boun...@speleo.sk> > 
On Behalf Of Matthieu Egels via Therion
Sent: Thursday, 4 October 2018 20:00
To: List for Therion users mailto:therion@speleo.sk> >
Cc: Matthieu Egels mailto:matthieu.eg...@im2np.fr> >
Subject: [Therion] Cave-list command

 

 

I work on a large project of topography in the south east of France. My project 
contains 17 caves and I use cave-list command to export it in html format it 
work fine but is it possible to export coordinates of each entrance in the html 
file? In did not found any about this in the thérion book. 

 

Matthieu EGELS
Maître de Conférence. 

 

Université d'Aix-Marseille 

 

Enseignement:
IUT d'Aix-Marseille, Dep. GEII.
142 traverse Charles Susini BP 157
13388 Marseille cedex 13

 

Recherche:
IM2NP (UMR 7334 CNRS)
Technopôle de Château Gombert
Campus de Polytech Marseille
60 rue Frédéric Joliot Curie
Bâtiment Néel - 2eme étage
13453 Marseille cedex 13

 

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

Re: [Therion] Cave-list command

[Bruce Mutton via Therion]

Like this?



 

export cave-list \

  -surveys on   \

  -location on \

   -output ./Output/RiwakaSystemCaves.html 

   #for html set surveys on, AND location on to see all entrances as well as 
caves

 

Bruce

 

From: Therion  On Behalf Of Matthieu Egels via 
Therion
Sent: Thursday, 4 October 2018 20:00
To: List for Therion users 
Cc: Matthieu Egels 
Subject: [Therion] Cave-list command

 

 

I work on a large project of topography in the south east of France. My project 
contains 17 caves and I use cave-list command to export it in html format it 
work fine but is it possible to export coordinates of each entrance in the html 
file? In did not found any about this in the thérion book. 





Matthieu EGELS
Maître de Conférence. 



 

Université d'Aix-Marseille 



 

Enseignement:
IUT d'Aix-Marseille, Dep. GEII.
142 traverse Charles Susini BP 157
13388 Marseille cedex 13



 

Recherche:
IM2NP (UMR 7334 CNRS)
Technopôle de Château Gombert
Campus de Polytech Marseille
60 rue Frédéric Joliot Curie
Bâtiment Néel - 2eme étage
13453 Marseille cedex 13



 

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

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

Thanks Martin, and Stacho, for your collected efforts.

I’ll try out and digest all of those suggestions, and put something on the wiki 
in due course.

 

I started wondering if a similar thing could be done for ‘line label’ (for say 
boxed or filled) but looking at the code it seems like that would be a much 
bigger chunk of work, as the mode concept is not implemented there.

 

Thanks again

 

Bruce

 

From: Therion  On Behalf Of Martin Budaj via Therion
Sent: Thursday, 4 October 2018 07:07
To: List for Therion users 
Cc: Martin Budaj 
Subject: Re: [Therion] Height numbers in square boxes

 

On Tue, Oct 2, 2018 at 9:07 PM Bruce Mutton via Therion mailto:therion@speleo.sk> > wrote:

If I wanted to box just one or two text labels, night it be possible to pass 
this parameter using a standard ‘point label’ entity with a ‘mode’ option?

Or would we have to go down a user defined label route?

 

Hi,

 

there is no such option, but you can use custom attribute, let's name it 
"label_mode":

 

-attr label_mode 6

 

Than you just need to redefine the label macro to use it:

 

vardef p_label@#(expr txt,pos,rot,mode_) =

  if known ATTR_label_mode:

mode := scantokens(ATTR_label_mode);

  else:

mode := mode_;

  fi;

  if (mode=1) or (mode=7): interim labeloffset:=(u/8) fi;

  lab:=thelabel@#(txt, pos);

  if mode>1: pickup PenD fi;

  if mode=1:

pickup pencircle scaled (u/6);

drawdot(pos);

process_label(pos,0);

  elseif mode=2: process_uplabel;   

  elseif mode=3: process_downlabel;

  elseif mode=4: process_updownlabel;

  elseif mode=5: process_circledlabel;

  elseif mode=6: process_boxedlabel;

  elseif mode=7: process_label(pos,rot);  % station name

  elseif mode=8: process_filledlabel(pos, rot);

  else: process_label(pos,rot); fi;

enddef;

 

Best regards,

Martin

 

 

 

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

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

Stacho

All those edits you have done are very much appreciated.  I look forward to 
figuring out usage cases for all of this.

Possibly some issues for now though, 

 

On using ‘debug all’ or ‘debug scrap’

 

>> p_label_mode_dbgscrap-1

! Unknown relation will be considered false.



 

Looks like have missed changing a dbgscrap to debugscrap somewhere in the code.

 

Also some odd assignments.

p_label_mode_debugstation:=2; %should be set to 7…

 

…to prevent debug station-names doing this

 

 

I suspect this one is not quite right either.

p_label_mode_debugscrap:=1; % Perhaps it should be 6?

 

Boxed labels work well.



 

I tried the filled labels, mode 8, but cannot see the difference to the generic 
label, mode 0.

 

Regards

Bruce

 

 

 

 

From: Therion  On Behalf Of Stacho Mudrak via Therion
Sent: Tuesday, 2 October 2018 09:08
To: List for Therion users 
Cc: Stacho Mudrak 
Subject: Re: [Therion] Height numbers in square boxes

 

Hi Bill, 

 

we have rearranged therion metapost code in latest commits and now (using last 
devel build) it should be possible to have boxed height labels just by using 
following code in your layout:

 

code metapost

p_label_mode_height:=6;

endcode

 

The magic number 6 stands for boxed label. See 
https://github.com/therion/therion/blob/master/mpost/thText.mp#L85 for list of 
all label modes.

 

Please let us know, if this is what you have been looking for or more 
complicated changes are needed.

 

S.

 

On Wed, 19 Sep 2018 at 23:35, Bill Gee via Therion mailto:therion@speleo.sk> > wrote:

Hello everyone -

A common convention around Missouri cave mapping is to indicate the height 
change of a floor step by enclosing the value in a square box.  This is not 
the same as ceiling height which is enclosed in a circle or oval.

I have been using the object "point height" for this.  It works except there 
is nothing around the value.  It just hangs out in space, so to speak.

I used the "-d" option to dump all the MetaPost and TeX code.  I find no 
references in any of the files to objects of type height or passage-height, 
which implies that these two objects are not generated by MetaPost.

Is it possible to redefine the "point height" symbol so it draws a square box 
around the value?

Thanks!
-- 
Bill Gee




___
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] boxed label

[Bruce Mutton via Therion]

Thanks Marco

Eventually the squeaky wheel gets oiled :)

Looks like it should work, but it seems to complain about setting the parsed 
attribute to a picture.

I will look some more when I have time tonight..

 

**data.mp

(./data.mp [4001] [4002] [4003] [4004] [4005] [4006] [4007] [4008] [4009] [4010

] [4011] [4012] [4013]

[4014] [4015] [4016] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]

[14] [15] [16] [17]

>> unknown picture pic

>> thelabelboxed

! Equation cannot be performed (unknown picture=numeric).

 

Bruce

 

From: Therion  On Behalf Of Marco Corvi via Therion
Sent: Monday, 24 September 2018 21:16
To: therion@speleo.sk
Cc: Marco Corvi 
Subject: [Therion] boxed label

 

hi bruce,

 

this is a boxed u:label

basically it gets the string as picture,

its bounding box corners, and define the x and y to draw the box, 

then draw the string picture

 

point 10 20 u:label -attr val 20

 

def p_u_label ( expr p,r,s,t ) =

  picture pic;

  pic := thelabel( ATTR_val, (0,0)) scaled s;

 pair q[]; numeric n[], m[], v;

 path bb;

 v := defaultscale;

 qO = ulcorner pic;

 q1 = lrcorner pic;

 nO := ypart q0 + 2.5 * v;

 n1 := ypart q1 - 1.5*v;

 m0 := xpart q0 - v;

 m1 := xpart q1 + 1.5*v;

bb := (m0,n0) -- (m0,n1) -- (m1,n1) -- (m1,n0) -- cycle;

draw bb  rotated r shifted p;

draw pic rotated r shifted p;

enddef;

 

 

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

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

Every time I have a good idea, I eventually realise why it will not work.  
Sigh...

 

So I think the way forward may be to understand and build on the general point 
label definition

 

vardef p_label@#(expr txt,pos,rot,mode) =

  if (mode=1) or (mode=7): interim labeloffset:=(u/8) fi;

  lab:=thelabel@#(txt, pos);

  if mode>1: pickup PenD fi;

  if mode=1:

pickup pencircle scaled (u/6);

drawdot(pos);

process_label(pos,0);

  elseif mode=2: process_uplabel;   

  elseif mode=3: process_downlabel;

  elseif mode=4: process_updownlabel;

  elseif mode=5: process_circledlabel;

  elseif mode=6: process_boxedlabel;

  elseif mode=7: process_label(pos,rot);  % station name

  elseif mode=8: process_filledlabel(pos, rot);

  else: process_label(pos,rot); fi;

enddef;

 

Thomas Holder modified it to get custom ‘point altitude’ here

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

It is interesting as I don’t think there is a ‘point altitude’ definition 
present in the Therion distribution, but Thomas has created one to use in 
conjunction with a modification of the p_label definition above.  The situation 
may be similar for ‘point height’.

 

And Stacho Mudrak once proposed another modification to enable any text label 
to be hidden, based on a user specified attribute.

http://article.gmane.org/gmane.comp.gis.therion/933/match=importance+scaling+text+orientation

In principle this approach would allow us to add a box or some other 
characteristic to any text label.

 

It might be helpful to figure out what the mode settings refer to.  Here are my 
deductions so far.

mode = -1  % symbol does not or cannot have a text property

mode = 0  % point label

mode = 1  % point altitude

mode = 2  % point passage-height +ve

mode = 3  % point passage-height -ve

mode = 4  % point passage-height both +ve and -ve

mode = 5  % point passage-height unsigned

mode = 6  % ??(this is the so-called ‘boxed_label’)

mode = 7  % point station-name, point height

mode = 8  % ??(this is the so-called ‘filled_label’)

Missing entities include ‘remark’, ‘date’

 

If anyone knows better, please let me know.

 

This bit of code that puts continuation text inside a coloured text box might 
also provide insight for a one-off solution as well.

 

  code metapost

def p_continuation(expr pos,theta,sc,al) =

  %# draw default continuation symbol ie ?

  p_continuation_UIS(pos,theta,sc,al);

  %# if text attribute is set

  if known(ATTR__text) and picture(ATTR__text):

  %# set labeling color to light orange

  push_label_fill_color(1.0, 0.9, 0.8);

  %# draw filled label with text next to symbol ?

  p_label.urt(ATTR__text,(.5u,-.25u) transformed T,0.0,8);

  %# restore original labeling color

  pop_label_fill_color;

  fi;

enddef;

  endcode

 

Bruce

 

-Original Message-
From: Therion mailto:therion-boun...@speleo.sk> > 
On Behalf Of Bruce Mutton via Therion
Sent: Sunday, 23 September 2018 10:25
To: 'List for Therion users' mailto:therion@speleo.sk> >
Cc: Bruce Mutton mailto:br...@tomo.co.nz> >
Subject: Re: [Therion] Height numbers in square boxes

 

Maybe we can use an approach that Thomas Holder demonstrated here   
<https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_symbols>
 
https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_symbols
 

 

  def l_rockborder (expr p) =

if abs(llcorner p - urcorner p) > u:

  l_rockborder_UIS(p);

fi;

  enddef;

 

Simply enclosing an existing metapost definition within a user customised 
metapost wrapper.

In the case above, it is "if the symbol is big enough, draw it".

 

What we want instead is, "draw the symbol, draw a box around it".

I expect something like bbox should enable us to put a line around a symbol, 
regardless of whether it is a text or arbitrary linework.

 

I'll leave it to someone else to explore...

 

Bruce

 

-Original Message-

From: Therion < <mailto:therion-boun...@speleo.sk> therion-boun...@speleo.sk> 
On Behalf Of Andrew Atkinson via Therion

Sent: Friday, 21 September 2018 09:16

To:  <mailto:therion@speleo.sk> therion@speleo.sk

Cc: Andrew Atkinson < <mailto:and...@wotcc.org.uk> and...@wotcc.org.uk>

Subject: Re: [Therion] Height numbers in square boxes

 

...

 

Yes I'm having similar problems to you defining a box, my skills are generally 
limited to copying existing definitions and adjusting them slightly. My guess 
is that it is not a metapost, it is tex as it is a label, in tex you can put a 
box round text  with

 

\fbox{4}

 

but how or if you can use that in therion I do not know.

 

It is a problem that is interesting me, as I think it is something that I might 
want to use.

 

Andrew

 

 

___

Therion mailing list

 <mailto:Therion

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

Every time I have a good idea, I eventually realise why it will not work.  
Sigh...

 

So I think the way forward may be to understand and build on the general point 
label definition

 

vardef p_label@#(expr txt,pos,rot,mode) =

  if (mode=1) or (mode=7): interim labeloffset:=(u/8) fi;

  lab:=thelabel@#(txt, pos);

  if mode>1: pickup PenD fi;

  if mode=1:

pickup pencircle scaled (u/6);

drawdot(pos);

process_label(pos,0);

  elseif mode=2: process_uplabel;   

  elseif mode=3: process_downlabel;

  elseif mode=4: process_updownlabel;

  elseif mode=5: process_circledlabel;

  elseif mode=6: process_boxedlabel;

  elseif mode=7: process_label(pos,rot);  % station name

  elseif mode=8: process_filledlabel(pos, rot);

  else: process_label(pos,rot); fi;

enddef;

 

Thomas Holder modified it to get custom ‘point altitude’ here

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

It is interesting as I don’t think there is a ‘point altitude’ definition 
present in the Therion distribution, but Thomas has created one to use in 
conjunction with a modification of the p_label definition above.  The situation 
may be similar for ‘point height’.

 

And Stacho Mudrak once proposed another modification to enable any text label 
to be hidden, based on a user specified attribute.

http://article.gmane.org/gmane.comp.gis.therion/933/match=importance+scaling+text+orientation

In principle this approach would allow us to add a box or some other 
characteristic to any text label.

 

It might be helpful to figure out what the mode settings refer to.  Here are my 
deductions so far.

mode = -1  % symbol does not or cannot have a text property

mode = 0  % point label

mode = 1  % point altitude

mode = 2  % point passage-height +ve

mode = 3  % point passage-height -ve

mode = 4  % point passage-height both +ve and -ve

mode = 5  % point passage-height unsigned

mode = 6  % ??(this is the so-called ‘boxed_label’)

mode = 7  % point station-name, point height

mode = 8  % ??(this is the so-called ‘filled_label’)

Missing entities include ‘remark’

 

If anyone knows better, please let me know.

 

This bit of code that puts continuation text inside a coloured text box might 
also provide insight for a one-off solution as well.

 

  code metapost

def p_continuation(expr pos,theta,sc,al) =

  %# draw default continuation symbol ie ?

  p_continuation_UIS(pos,theta,sc,al);

  %# if text attribute is set

  if known(ATTR__text) and picture(ATTR__text):

  %# set labeling color to light orange

  push_label_fill_color(1.0, 0.9, 0.8);

  %# draw filled label with text next to symbol ?

  p_label.urt(ATTR__text,(.5u,-.25u) transformed T,0.0,8);

  %# restore original labeling color

  pop_label_fill_color;

  fi;

enddef;

  endcode

 

Bruce

 

-Original Message-
From: Therion  On Behalf Of Bruce Mutton via Therion
Sent: Sunday, 23 September 2018 10:25
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: Re: [Therion] Height numbers in square boxes

 

Maybe we can use an approach that Thomas Holder demonstrated here   
<https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_symbols>
 
https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_symbols
 

 

  def l_rockborder (expr p) =

if abs(llcorner p - urcorner p) > u:

  l_rockborder_UIS(p);

fi;

  enddef;

 

Simply enclosing an existing metapost definition within a user customised 
metapost wrapper.

In the case above, it is "if the symbol is big enough, draw it".

 

What we want instead is, "draw the symbol, draw a box around it".

I expect something like bbox should enable us to put a line around a symbol, 
regardless of whether it is a text or arbitrary linework.

 

I'll leave it to someone else to explore...

 

Bruce

 

-Original Message-

From: Therion < <mailto:therion-boun...@speleo.sk> therion-boun...@speleo.sk> 
On Behalf Of Andrew Atkinson via Therion

Sent: Friday, 21 September 2018 09:16

To:  <mailto:therion@speleo.sk> therion@speleo.sk

Cc: Andrew Atkinson < <mailto:and...@wotcc.org.uk> and...@wotcc.org.uk>

Subject: Re: [Therion] Height numbers in square boxes

 

...

 

Yes I'm having similar problems to you defining a box, my skills are generally 
limited to copying existing definitions and adjusting them slightly. My guess 
is that it is not a metapost, it is tex as it is a label, in tex you can put a 
box round text  with

 

\fbox{4}

 

but how or if you can use that in therion I do not know.

 

It is a problem that is interesting me, as I think it is something that I might 
want to use.

 

Andrew

 

 

___

Therion mailing list

 <mailto:Therion@speleo.sk> Therion@speleo.sk

 <https://mailman.speleo.sk/listinfo/therion> 
https://mailman.speleo.sk/listinfo/the

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

Maybe we can use an approach that Thomas Holder demonstrated here
 
https://therion.speleo.sk/wiki/metapost#scale_dependant_visualization_of_symbols
 

  def l_rockborder (expr p) =
if abs(llcorner p - urcorner p) > u:
  l_rockborder_UIS(p);
fi;
  enddef;

Simply enclosing an existing metapost definition within a user customised 
metapost wrapper.
In the case above, it is "if the symbol is big enough, draw it".

What we want instead is, "draw the symbol, draw a box around it".
I expect something like bbox should enable us to put a line around a symbol, 
regardless of whether it is a text or arbitrary linework.

I'll leave it to someone else to explore...

Bruce

-Original Message-
From: Therion  On Behalf Of Andrew Atkinson via 
Therion
Sent: Friday, 21 September 2018 09:16
To: therion@speleo.sk
Cc: Andrew Atkinson 
Subject: Re: [Therion] Height numbers in square boxes

...

Yes I'm having similar problems to you defining a box, my skills are generally 
limited to copying existing definitions and adjusting them slightly. My guess 
is that it is not a metapost, it is tex as it is a label, in tex you can put a 
box round text  with

\fbox{4}

but how or if you can use that in therion I do not know.

It is a problem that is interesting me, as I think it is something that I might 
want to use.

Andrew


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

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

An example

 

point 3094.0 282.0 height -value [+20 m]

 

line wall -subtype pit -outline none -clip off -height [20 m] #solid filled pit 
line entered independent of the point height label above

  3091.0 543.0

  3094.0 504.0 3078.0 392.0 3042.0 340.0

endline

 

point 3280.0 882.0 height -value [-5 m]

 

line wall -subtype pit -outline none -clip off #open pit line entered 
independent of point height label above

  3222.0 847.0

  3220.0 832.0 3168.0 750.0 3161.0 742.0

  3154.0 734.0 3109.0 716.0 3091.0 695.0

  3076.15 677.67 3059.0 665.0 3062.0 636.0

  3065.0 607.0 3088.0 563.0 3091.0 543.0

  smooth off

endline

 



 

Bruce

 

-Original Message-
From: Therion  On Behalf Of Bruce Mutton via Therion
Sent: Sunday, 23 September 2018 09:02
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: Re: [Therion] Height numbers in square boxes

 

I think the height attribute is only used for the AUT symbol set, for line pit, 
and line wall:pit.  Look in uAUT.mp If the pit height is greater than 10m, then 
the open triangles are filled in.

If the pit height is less than or equal to 10m or undefined, then the triangles 
are open.

 

Looks like if you want to label the pit, you should use point height and place 
it near to the line pit (or line floor-step or chimney whatever).

ie completely independent input required by the user.  A bit like how point 
sink and point water-flow are intended to be used tother.

 

Bruce

 

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

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

Well, this is beyond my expertise, but I have collected together some clues 
from the code, in the attached file.
Maybe someone else can make something of it.
It seems like the distributed metapost code has boxed label capability built 
into it, but the overall implementation does not provide a way for it to be 
used (maybe).
The C code allows for all the 'modes' to be used, except mode = 6 for boxed 
labels and mode = 8 for filled labels.  So looks like there needs to be changes 
at that level.

Bruce

-Original Message-
From: Therion  On Behalf Of Bruce Mutton via Therion
Sent: Friday, 21 September 2018 20:45
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: Re: [Therion] Height numbers in square boxes

It might be that this capability is already built into Therion.

Look in the source files.
/mpost/thText.mp line 84: 
vardef p_label@#(expr txt,pos,rot,mode) = ...
  elseif mode=2: process_uplabel;   
  elseif mode=3: process_downlabel;
  elseif mode=4: process_updownlabel;
  elseif mode=5: process_circledlabel;
  elseif mode=6: process_boxedlabel;
  elseif mode=7: process_label(pos,rot);  % station name
  elseif mode=8: process_filledlabel(pos, rot);
  else: process_label(pos,rot); fi;

/mpost/therion.mp line 440: 
def process_boxedlabel =
q:=bbox lab;
draw lab;
draw q;
write_bbox(q);
enddef;

/mpost/therion.mp line 484:
def write_bbox (expr q) =

I think we just need to figure  out how to invoke the various modes, and we can 
make use of the predefined label ornaments.
Unfortunately I don't have time to play with any of this just now, I'm sure one 
of you will figure it out.

Bruce

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

FROM thTex.mp
point label definition


vardef p_label@#(expr txt,pos,rot,mode) =
  if (mode=1) or (mode=7): interim labeloffset:=(u/8) fi;
  lab:=thelabel@#(txt, pos);
  if mode>1: pickup PenD fi;
  if mode=1:
pickup pencircle scaled (u/6);
drawdot(pos);
process_label(pos,0);
  elseif mode=2: process_uplabel;   
  elseif mode=3: process_downlabel;
  elseif mode=4: process_updownlabel;
  elseif mode=5: process_circledlabel;
  elseif mode=6: process_boxedlabel;
  elseif mode=7: process_label(pos,rot);  % station name
  elseif mode=8: process_filledlabel(pos, rot);
  else: process_label(pos,rot); fi;
enddef;

FROM therion.mp
low level process_ various label types


def fonts_setup (expr t,s,m,l,h) =
  write "\def\updown#1#2{\vbox{" &
"\offinterlineskip" &
"\setbox100=\hbox{#1}" &
"\setbox101=\hbox{#2}" &
"\ifnum\wd100>\wd101\hsize=\wd100\else\hsize=\wd101\fi" &
"\centerline{\box100}\vskip4pt" &
"\centerline{\box101}}}" &
"\def\thlabel{\thnormalsize}" &
"\def\thremark{\thsmallsize\si}" &
"\def\thcomment{\thsmallsize}" &
"\def\thentrance{\thsmallsize}" &
"\def\thaltitude{\thsmallsize}" &
"\def\thstationname{\thsmallsize}" &
"\def\thdate{\thsmallsize}" &
"\def\thheight{\thsmallsize}" &
"\def\thheightpos{+\ignorespaces}" &
"\def\thheightneg{-\ignorespaces}" &
"\def\thframed{\thsmallsize}" &
"\def\thwallaltitude{\thtinysize}"
  to "mptexpre.tex";
  write "\def\thtinysize{\size[" & decimal max(optical_zoom*t,0) & "]}" & 
"\def\thsmallsize{\size[" & decimal max(optical_zoom*s,0) & "]}" & 
"\def\thnormalsize{\size[" & decimal max(optical_zoom*m,0) & "]}" & 
"\def\thlargesize{\size[" & decimal max(optical_zoom*l,0) & "]}" & 
"\def\thhugesize{\size[" & decimal max(optical_zoom*h,0) & "]}" 
  to "mptexpre.tex";
  write EOF to "mptexpre.tex";
enddef;

% @MACRO
% process_label --
%
% draws a label saved in lab picture variable and calls 
% write_bbox macro.


def process_label (expr cent, rot) =
  begingroup;
interim bboxmargin:=0.8bp;
q:=((bbox lab) smoothed 2) rotatedaround (cent, rot);
draw lab rotatedaround (cent, rot);
write_circ_bbox(q);  % without corners smoothing it was enough to use
 % write_bbox(q);
  endgroup;
enddef;

% @MACRO
% process_uplabel --
%
% draws a label into semicircular box and writes clipping path to a file

def process_uplabel =
  begingroup;
interim bboxmargin := 0.8 bp;
q:=bbox lab;
  endgroup;
alef:=.8-.02*(xpart lrcorner q - xpart llcorner q)

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

I think the height attribute is only used for the AUT symbol set, for line pit, 
and line wall:pit.  Look in uAUT.mp
If the pit height is greater than 10m, then the open triangles are filled in.
If the pit height is less than or equal to 10m or undefined, then the triangles 
are open.

Looks like if you want to label the pit, you should use point height and place 
it near to the line pit (or line floor-step or chimney whatever).
ie completely independent input required by the user.  A bit like how point 
sink and point water-flow are intended to be used tother.

Bruce

-Original Message-
From: Therion  On Behalf Of Andrew Atkinson via 
Therion
Sent: Friday, 21 September 2018 09:16
To: therion@speleo.sk
Cc: Andrew Atkinson 
Subject: Re: [Therion] Height numbers in square boxes

Yes the Missouri set would be even better.

> A common convention around Missouri cave mapping is to indicate the 
> height change of a floor step by enclosing the value in a square box.  
> This is not the same as ceiling height which is enclosed in a circle 
> or oval

The therion book indicates that height can be added to pit or wall:pit
p29
"height  ▷ height of pit or wall:pit; available in METAPOST as a numeric 
variable ATTR__height."

I guess that would also make sense for a floor-step, however if you try it you 
get the error -height not valid with type floor-step When you use an altitude 
on a wall it adds a label but does not seem to with pits maybe the same should 
happen with steps and pits, currently I have no idea what happens to the height 
attribute on a pit. Looking at data.mp the l_floorstep does have a ATTR__height 
and it is set to -1!

Yes I'm having similar problems to you defining a box, my skills are generally 
limited to copying existing definitions and adjusting them slightly. My guess 
is that it is not a metapost, it is tex as it is a label, in tex you can put a 
box round text  with

\fbox{4}

but how or if you can use that in therion I do not know.

It is a problem that is interesting me, as I think it is something that I might 
want to use.

Andrew



On 20/09/18 13:09, Martin Sluka via Therion wrote:
> Please contact Martin Budaj. 
> 
> Odesláno z iPhonu
> 
> 20. 9. 2018 v 13:32, Bill Gee via Therion :
> 
>> Hi Martin -
>>
>> Now that is an interesting idea!  Most of the symbols used in 
>> Missouri are UIS, so that would serve as the starting point.
>>
>> Is there any documentation on how to create an entire symbol set?
>>
>> And my original question is still there ...  How can I create a 
>> symbol that puts a number inside a square box?
>>
>> --
>> Bill Gee
>>
>>
>>
>> On Thursday, September 20, 2018 12:37:42 AM CDT Martin Sluka via 
>> Therion
>> wrote:
>>> The correct way could be to define “Missoury symbol set” as one of 
>>> defaults for Therion.
>>>
>>> It should be more simple than user symbol, because it will work with 
>>> contents menus.
>>>
>>> Martin S.
>>>
>>> Odesláno z iPhonu
>>>
>>> 20. 9. 2018 v 1:05, Bill Gee via Therion :
 Hi Andrew -

 I have defined several of my own symbols such as a pendant and 
 popcorn with hollow circles.  I could easily define a custom point 
 that would display a square box.

 But then how to get the value displayed inside the box?  And how to 
 make the box scale according to the number of digits it contains?  
 And will Therion do unit conversions like it does for the passage-height 
 object?
 That's why I was looking for the existing code.  If I can find it, 
 then it is probably pretty easy to modify.

> Yes that is probably possible, however, using a defined symbol for 
> something else is probably not the right answer. Therion allows 
> you to define your own points.
>
>> From the wiki
>
> point u: where  is the name of a user defined symbol that 
> you have defined or referenced in a layout.
>
> The actual definition seems to be beyond me at the moment, let me 
> sleep on it, but hopefully a more skillful person will have the 
> answer.
>
> Andrew
>
>> On Wed, 19 Sep 2018, 22:28 Bill Gee via Therion, 
>> 
>> wrote:
>> Hello everyone -
>>
>> A common convention around Missouri cave mapping is to indicate 
>> the height change of a floor step by enclosing the value in a 
>> square box.  This is not the same as ceiling height which is 
>> enclosed in a circle or oval.
>>
>> I have been using the object "point height" for this.  It works 
>> except there is nothing around the value.  It just hangs out in 
>> space, so to speak.
>>
>> I used the "-d" option to dump all the MetaPost and TeX code.  I 
>> find no references in any of the files to objects of type height 
>> or passage-height, which implies that these two objects are not 
>> generated by MetaPost.
>>
>> Is it possible to redefine the "point height" symbol so it draws 
>> a square box 

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

It might be that this capability is already built into Therion.

Look in the source files.
/mpost/thText.mp line 84: 
vardef p_label@#(expr txt,pos,rot,mode) =
...
  elseif mode=2: process_uplabel;   
  elseif mode=3: process_downlabel;
  elseif mode=4: process_updownlabel;
  elseif mode=5: process_circledlabel;
  elseif mode=6: process_boxedlabel;
  elseif mode=7: process_label(pos,rot);  % station name
  elseif mode=8: process_filledlabel(pos, rot);
  else: process_label(pos,rot); fi;

/mpost/therion.mp line 440: 
def process_boxedlabel =
q:=bbox lab;
draw lab;
draw q;
write_bbox(q);
enddef;

/mpost/therion.mp line 484:
def write_bbox (expr q) =

I think we just need to figure  out how to invoke the various modes, and we can 
make use of the predefined label ornaments.
Unfortunately I don't have time to play with any of this just now, I'm sure one 
of you will figure it out.

Bruce

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

Re: [Therion] Height numbers in square boxes

[Bruce Mutton via Therion]

One of the developers added a NZSS symbol set some years ago, based on a few 
symbol definitions I posted on this forum.

I have some more symbol definitions I would like to add to it, btw.

If someone points me to the general code location, I might try to cut my teeth 
on git and add those extra definitions.

 

A new symbol set can include as little as a single symbol, so it should not be 
a big job Bill.  You can simply reassign symbols from other symbol sets for 
those not defined in your chosen symbol set.  ie

 

  symbol-assign line gradient UIS

  symbol-assign point gradient UIS

 

Maybe some learning we can do together Bill (on adding to symbol sets).

 

Also for what it is worth, I made this clumsy attempt at text within boxes (or 
sorts).  Not quite what you are after, but might give some ideas.

 

A more generally useful thing I have been wondering about for point labels and 
point remarks (or line labels for that matter) would be the ability to add a 
box around the text, as a simple property of that entity, activated in the same 
way as we specify -align left or -scale xs.  And even a -hyperlink [path|url] 
would be useful

 



 

# Define an experimental label symbol for graffiti

  

code metapost

def p_u_graffiti (expr pos,theta,sc,al)=

  U:=(.2u,.5u);

  T:=identity aligned al rotated theta scaled sc shifted pos;

  

  %# pos and al work fine in label below, but theta and sc transformed about 
far off point???

  %# so have been disabled for label component.  Plan rotation seems to have no 
further detrimental effect

  label (btex Gr etex, pos) aligned al; % rotated theta scaled sc aligned al;  
% btex and etex are wrappers around code to be process by tex

  

  thdraw unitsquare scaled u shifted (-0.5u,-0.5u) rotated 45 withpen PenD; % 
diagonal box with thin pen

  thdraw fullcircle scaled u withpen PenD;  

enddef;

 

initsymbol("p_u_graffiti")

  

  

endlayout LayoutMapThisCave

 

#legend entries for custom entities

 

text en "point u:graffiti" "Historic graffiti" #text to appear in legend

 

 

Regards

Bruce

 

-Original Message-
From: Therion  On Behalf Of Martin Sluka via Therion
Sent: Friday, 21 September 2018 00:09
To: List for Therion users 
Cc: Martin Sluka 
Subject: Re: [Therion] Height numbers in square boxes

 

Please contact Martin Budaj. 

 

Odesláno z iPhonu

 

20. 9. 2018 v 13:32, Bill Gee via Therion <  
therion@speleo.sk>:

 

> Hi Martin -

> 

> Now that is an interesting idea!  Most of the symbols used in Missouri 

> are UIS, so that would serve as the starting point.

> 

> Is there any documentation on how to create an entire symbol set?

> 

> And my original question is still there ...  How can I create a symbol 

> that puts a number inside a square box?

> 

> --

> Bill Gee

> 

> 

> 

> On Thursday, September 20, 2018 12:37:42 AM CDT Martin Sluka via 

> Therion

> wrote:

>> The correct way could be to define “Missoury symbol set” as one of 

>> defaults for Therion.

>> 

>> It should be more simple than user symbol, because it will work with 

>> contents menus.

>> 

>> Martin S.

>> 

>> Odesláno z iPhonu

>> 

>> 20. 9. 2018 v 1:05, Bill Gee via Therion <  
>> therion@speleo.sk>:

>>> Hi Andrew -

>>> 

>>> I have defined several of my own symbols such as a pendant and 

>>> popcorn with hollow circles.  I could easily define a custom point 

>>> that would display a square box.

>>> 

>>> But then how to get the value displayed inside the box?  And how to 

>>> make the box scale according to the number of digits it contains?  

>>> And will Therion do unit conversions like it does for the passage-height 
>>> object?

>>> That's why I was looking for the existing code.  If I can find it, 

>>> then it is probably pretty easy to modify.

>>> 

 Yes that is probably possible, however, using a defined symbol for 

 something else is probably not the right answer. Therion allows you 

 to define your own points.

 

> From the wiki

 

 point u: where  is the name of a user defined symbol that 

 you have defined or referenced in a layout.

 

 The actual definition seems to be beyond me at the moment, let me 

 sleep on it, but hopefully a more skillful person will have the 

 answer.

 

 Andrew

 

> On Wed, 19 Sep 2018, 22:28 Bill Gee via Therion, 

> <  therion@speleo.sk>

> wrote:

> Hello everyone -

> 

> A common convention around Missouri cave mapping is to indicate 

> the height change of a floor step by enclosing the value in a 

> square box.  This is not the same as ceiling height which is 

> enclosed in a circle or oval.

> 

> I have been using the object "point height" for this.  It works 

> except there is nothing around the value.  It just hangs out in 

> space, so to speak.

> 

> I used the "-d" 

[Therion] DistoX2 waterproof case

[Bruce Mutton via Therion]

While we are on the topic of DisoX2.

 

Has anyone here tried these? https://www.facebook.com/DistoX2Case/

Any feedback?

 

I have tried to contact Stanislav via the facebook page, but without any
luck.

I would like two, and I suspect there would be a market in New Zealand for
at least few more.

 

Regards

Bruce

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

Re: [Therion] Eurospeleo 2018

[Bruce Mutton via Therion]

Might there be an electronic conferencing option for the cave survey workshop? 
(a bit late notice I know)
Bruce
Sent from my Samsung device

 Original message 
From: Evaristo Quiroga via Therion  
Date: 23/08/18  03:13  (GMT+12:00) 
To: Stacho Mudrak via Therion  
Cc: Evaristo Quiroga  
Subject: Re: [Therion] Eurospeleo 2018 


Hi, 

  

  I (Evaristo Quiroga) arrive tomorrow 23/8/2018 in the afternoon, and I
  will be there until 8/27/2018. See
  you at the welcome ceremony.

  

  Regards,

  

  Evaristo. 



  

  El 21/08/2018 a las 15:38, Stacho Mudrak via Therion escribió:



  
  

  
  Hi everybody,
  

  eurospeleo meeting in Austria starts tomorrow. Me and Martin 
(Budaj), we are leaving there tomorrow and we will be there until Surveying 
workshop on Sunday afternoon. If you are interested, we could meet at welcome 
ceremony.
  

  
  S.


  

  
  

  
  

  ___
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] therion website not secure

[Bruce Mutton via Therion]

Is there a problem with the Therion website?

My browser is complaining that the https is no longer working.

 

Bruce

 



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

[Therion] tex-map \maplayout hiding special symbols (scalebar and northarrow)

[Bruce Mutton via Therion]

I am trying again to understand control of map elements, independent of the
standard map header.  For now just considering scale-bars and north-arrows.

 

The Therion Book, page 70 says…

 

North arrow and scale bar may be displayed using
* \ifnortharrow ▷ conditional; true if map projection is plan and symbol
north-arrow
is not hidden in layout
* \ifscalebar ▷ conditional; true if scalebar is not hidden

 

>From this, I assume that the following statements in a layout should
prevent a north-arrow and scale-bar from being output.

 

symbol-hide special north-arrow 

symbol-hide special scale-bar 

 

However I find that these elements are always output regardless of the
layout.  ie the symbol-hide statements have no effect for the special
symbols, even though they work just fine for groups, lines and points.

 

This is an example of what I am using;

 

\def\maplayout{

  \legendbox{100}{100}{NW}{\the\legendcontent} %insert default header with
cave name, northarrow, scalebar, statistics etc

  \legendbox{17}{00}{N}{\northarrow } %insert just a northarrow

  \legendbox{17}{-100}{N}{\scalebar} %insert just a scalebar

}

 

I have also tried the likes of ;

 

  \legendbox{17}{-100}{N}{\ifscalebar\scalebar\fi }  %try to insert a
scalebar only if not hidden

 

But this does not work either, as the scale-bar is still always output
regardless of symbol-hide.

 

Am I misunderstanding the usage of symbol-hide for special symbols, or have
I broken something, or could there be a bug?

 

Bruce

 

 

 

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

[Therion] Tex and Therion comment characters

[Bruce Mutton via Therion]

Good evening

I'm trying to sort out some problem I'm having debugging a tex-map routine.

I'm trying to rule out things that might be causing unexpected results
(other than the obvious which is that I don't know what I am doing).

 

The comment character for tex is %

The comment character for Therion data files is #

 

Does it affect the way tex is interpreted by Therion if the two are
combined, as in the two examples below?

Mostly it seems to have no effect, but now I am wondering if I am mistaken,
and sometimes it does?

 

# Define Map title overrides 

code tex-map

# % Output map title as determined by Therion 5.3 is stored in cavename. 

# % It will be empty if there are multiple maps selected for any one
projection

# %   \edef\temp{\the\cavename}% cavename from Therion   

# %   \edef\nostring{} % empty string 

# %   \ifx\temp\nostring % test if cavename is empty

 

# Define Map title overrides 

code tex-map

  % Output map title as determined by Therion 5.3 is stored in cavename. 

  % It will be empty if there are multiple maps selected for any one
projection

 %   \edef\temp{\the\cavename}% cavename from Therion   

  %   \edef\nostring{} % empty string 

  %   \ifx\temp\nostring % test if cavename is empty

 

Thanks

Bruce

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

Re: [Therion] shell script for creating .th2 and .th files for a given survey

[Bruce Mutton via Therion]

Thanks Jonny

I have added that to the wiki.

https://therion.speleo.sk/wiki/contrib:complimentarycaveapps#other_applications

Bruce

 

From: Therion  On Behalf Of Jonny Prouty via Therion
Sent: Sunday, 22 July 2018 03:54
To: List for Therion users 
Cc: Jonny Prouty 
Subject: [Therion] shell script for creating .th2 and .th files for a given 
survey

 

Hello all,

 

I have created a shell script for the most repetitive part of my therion 
workflow, setting up new .th and .th2 files to hold the actual sketch data to 
be digitized. The script has proven to be quite a time saver. I've cleaned it 
up a bit and added a usage statement and decided to release it into the wild.

 

The script relies on imagemagick's display program, so as long as you have 
display and can run shell scripts, the script should run. I've only used/tested 
it on Fedora, but I imagine it will run on a mac without difficulty. It's 
possible you could get it to run in windows if you have a decent shell 
available.

 

The script is far from perfect and still has plenty of rough edges, so feel 
free to comment and suggest changes if you feel compelled to.

 

https://github.com/jonnyprouty/caving/blob/master/add_survey_trip.sh

 

Best regards,

 

Jonny Prouty

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

Re: [Therion] Adding entrance breaks extended elevation

[Bruce Mutton via Therion]

Well, I have solved my problem with this extended centreline, but not the
mystery of Therion!

My extended centreline relied on a lot of auto generation, and for some
reason adding the entrance flag broke some of the auto generation far away
in the middle of the network.

After a reasonable amount of explicitly extending every leg, everything
suddenly popped back into place.  There remain other auto generated
sequences in the dataset, so maybe future unpleasant surprises await me.

 

As myself and others have pointed out, extended elevations can be fickle.  I
have added todays insights to the wiki
<https://therion.speleo.sk/wiki/extend#summary_of_all_extend_options_for_sur
vey_centrelines> .

It would be nice to have some debug functionality aimed at communicating to
the user exactly how Therion has created the extended centreline.  Maybe
something graphical in the pdf, and an optional text listing in therion.log
of every extend function in the order it is executed. ie

Start 4.1

Left 4.1 4.2

Left 4.2 4.3

vertical 4.2 4.4

right 4.4 4.5

etc

Bruce

 

From: Therion  On Behalf Of Bruce Mutton via
Therion
Sent: Friday, 20 July 2018 22:58
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: [Therion] Adding entrance breaks extended elevation

 

We've been surveying a cave from half way between two entrances, and working
outwards towards those entrances over a number of survey trips.  ..  But as
soon as I add a station flag to the upstream entrance, the shape of the
extended centreline is broken.  It looks like Therion is overriding the
'extend start' that I have in the middle of the cave, and replacing it with
a start at the top entrance.  ..

 

Good, but no upstream entrance flag



 

Bad, after adding upstream entrance flag the extends are broken

   station 4.24 "Top Entrance" entrance



Any suggestions?

 

Bruce

 

 

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

[Therion] Adding entrance breaks extended elevation

[Bruce Mutton via Therion]

Hi all

We've been surveying a cave from half way between two entrances, and working
outwards towards those entrances over a number of survey trips.  As each
survey trip has been completed, I have been drawing, and constructing an
extended centreline, and attaching scraps.  The extended centreline is just
a little bit complicated, with two loops, but I have managed to get the
breaks where I want them, and offset passages to lay it out nicely.  As each
centreline is added, I modify the extend left and right for that survey to
suit the extended centreline shape that I want.  I have 'anchored' the
downstream entrance with a dummy survey leg, until I surveyed downstream to
that entrance and I could remove the dummy leg.  I have 'extended right' to
the downstream entrance.

All has gone well until I surveyed out of the upstream entrance, extending
left, mostly.  But as soon as I add a station flag to the upstream entrance,
the shape of the extended centreline is broken.  It looks like Therion is
overriding the 'extend start' that I have in the middle of the cave, and
replacing it with a start at the top entrance.  This completely scrambles
the shape of the centreline and attached scrap drawings. It looks a bit like
the default behaviour listed here
  (the first paragraph of the
main text) for Survex.

I have tried a few approaches to avoid this undesirable behaviour, but
nothing yet has worked.  

I would rather not try to recreate the extend development from upstream, as
Therion seems to want me to do, because even with such a simple cave, there
is some complexity and time involved in figuring it out.

 

Good, but no upstream entrance flag



 

Bad, after adding upstream entrance flag the extends are broken

   station 4.24 "Top Entrance" entrance



Any suggestions?

 

Bruce

 

 

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

Re: [Therion] coloring

[Bruce Mutton via Therion]

Marco

I think this is already implemented as described here (near the bottom of the 
section)

https://therion.speleo.sk/wiki/examples#colour_scales_-_lookups

but not for surveys.

 

However you can create a map that contains only one or two centreline surveys, 
and then colour that.  That may not work however, as it is only the map-fg that 
is coloured, I imagine.

 

However when I was testing I could not get the syntax;

 select map1 -color [100 0 0]

to work, but you should still be able to use a lookup to achieve the effect.

Bruce

 

From: Therion  On Behalf Of Marco Corvi via Therion
Sent: Tuesday, 17 July 2018 19:16
To: therion@speleo.sk
Cc: Marco Corvi 
Subject: [Therion] coloring

 

what about a scrap option "-color" that overrides the layout foreground color ?

 

survey too could have a color option.

 

marco

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

Re: [Therion] How to hide duplicate shots in export models?

[Bruce Mutton via Therion]

Evaristo

In Loch you right-click, select ‘scene’ then adjust the centreline settings.



For kml I am not sure.

I use this approach for STATION visibility in export map -o *.pdf.  It might 
work for kml but I suspect not.

(I got from this wiki post 

 )

 

   symbol-hide group cave-centreline #1. hides all centrelines, incl 
station-names - clears the canvas

  symbol-show point cave-station  #2. set up for identifying 
cave-stations to show/hide

 symbol-show point station:fixed  #3. actually show/hide 
(cave-)stations of mark ...

 symbol-show point station:painted #3. 

 symbol-show point station:natural  #3.

 symbol-hide point station:temporary #3.

 

At a guess, for SURVEY LINE visibility you could try something like…

 

   symbol-hide group cave-centreline #1. hides all centrelines, incl 
station-names - clears the canvas

  symbol-show line cave-survey  #2. set up for identifying cave survey 
lines to show/hide

 symbol-show line survey:duplicate  #3. actually show/hide (cave-) 
survey lines with flag ...

 

I have not tested this, and I might have made it far too complicated or got the 
entity names wrong  anyway.

 

 

 

-Original Message-
From: Therion  On Behalf Of Evaristo Quiroga via 
Therion
Sent: Monday, 16 July 2018 06:59
To: therion@speleo.sk
Cc: Evaristo Quiroga 
Subject: [Therion] How to hide duplicate shots in export models?

 

Hi,

 

I have shots with duplicate flags. I want hide this shots in the export models 
(loch and kml). In survex 3d, it's easy in Aven you can hide the duplicate 
shots.

Any suggestion?

Regards,

Evaristo.

 

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

[Therion] Page Size

[Bruce Mutton via Therion]

Hi Markus

Yes, but with limitations.

If you export map -f pdf, then you can indirectly influence the page size by
adjusting the scale and where you place the header.  Not as precise as you
are wanting.

If you export atlas -f pdf, then you can precisely specify the page size, as
you have been attempting.  The cave is then distributed across as many pages
as is required.  Disadvantages are that you cannot place headers and other
objects on the pages.

 

Have a look https://therion.speleo.sk/wiki/bds where there is some
information.

 

"A map output (not to be confused with a map object) is contained on a
single 'page' and the size of the page is automatically made big enough to
fit the cave by the software. A number of formats are supported but pdf
seems to be the most comprehensive. Pdf maps can include graphics such as
photos, logos, other pdf files or previously created cave maps.

An atlas output cuts the cave up to fit a user defined 'paper size' and adds
a navigation pane. Hyperlinks in the navigation pane and at the page edges
facilitate rapid navigation. If multiple maps are selected in the thconfig
file, then chapters are automatically created separating the maps. These may
be different caves or different levels in the cave - with hyperlinks to
navigate between different levels. Only pdf format is supported. Inserted
graphic images are NOT supported."

Also https://therion.speleo.sk/wiki/templates#atlas_specific which contains
some useful atlas paper size layouts.

 

Bruce

 

From: Therion  On Behalf Of Markus Boldt via
Therion
Sent: Sunday, 1 July 2018 23:02



Hello, 

how is it possible to "say" Therion to make a PDF-File with for example a
Size of DIN A4 (21 x 29,7 cm)? 

I have tried 

Page-setup 21 29.7 20 29 0.1 0.1 cm 

it doesn`t work 

I have tried 

Size 21 29.7 cm 

It doesn`t, too 

The command is ignored.

Greetings 

Markus 

 

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

[Therion] Point with entrance coordinates

[Bruce Mutton via Therion]

> I am very pleased with the use and the outputs of Therion. 

> However, for the map views and/or elevation (projected or extended) views, it 
> always seems to me that there is a lack of a convenient way to add the 
> entrance(s) coordinates somewhere. It could be inside the header, or near the 
> given entrance on the drawing. 

 

Funny thing.  Someone just asked me about this sort of thing yesterday.  I 
don’t have a solution, but would like to encourage anyone who would like to 
make more metadata available to tex, so that people can add it to custom 
headers, maps or atlas’.  One similar thing that comes to mind is something 
Therion does not yet track as metadata, the locality or region that the cave is 
in.  I see in that recent Tragaero’ pdf Xavier has what I suspect might be a 
custom variable he sets in a layout (I’m guessing) and displays with a 
customisation of the standard header.  I might see if I can also do that, as 
there seems to be some interest locally.

 

Bruce

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

[Therion] Tex variables to report according to cs, projection type and angle

[Bruce Mutton via Therion]

Hi all

I was just trying to make a new header definition that could report
appropriately, dependant on presence of a coordinate system, plan, extended
or projected elevation.  It was mostly progressing OK until I realised I was
pinning my hopes on using the metapost ATTR__elevation variable in a block
of tex code.  That and my very poor grasp of tex Boolean testing (   \if
ATTR__elevation  is probably the wrong syntax) mean that I am probably
doomed to fail. Since I have got this far, I may as well ask a few
questions..

 

In the code below.

Is there a tex variable equivalent to the  ATTR__elevation metapost
variable?

Is it possible to differentiate extended elevations from projected
elevations (and plans) with tex?

For example, can we determine the projection angle of a projected elevation?

How to format the magdecl output to just 1 decimal place? 

 

Bruce

 

# % print coordinate system and projection related information

  \if ATTR__elevation  % print elevation specific text %THIS TEST ALWAYS
FALSE??

# % extended elevation

{\the\legendtextsize\ss {Idealised elevation} \par} %'
looking generally East' %this whole line probably redundant

# % projected elevation

\edef\tmp{\the\outcsname} \ifx\tmp\empty %ie if no cs

  {\the\legendtextsize\ss {Elevation looking xxx deg
magnetic}\par} %NEED TO SEE IF PROJECTION ANGLE AVAILABLE TO TEX

\else%there is a cs

  {\the\legendtextsize\ss\the\outcsname { elevation looking xxx
deg}\par} %NEED TO SEE IF PROJECTION ANGLE AVAILABLE TO TEX

\fi

 

  \else % not ATTR__elevation % print plan specific text

# % plan   

\edef\tmp{\the\outcsname} \ifx\tmp\empty %ie if no cs 

   %{\the\legendtextsize\ss {Plan projection (not
georeferenced)}\par}  %remove preceding % for redundant long form

{\the\legendtextsize\ss Arrow points to
magnetic north} 

\else%there is a cs

\the\legendtextsize\ss\the\outcsname %{ plan
projection}\par %remove preceding % for redundant long form

\edef\tmp{\the\northdir} \ifx\tmp\empty
\else

{\the\legendtextsize\ss {
arrow points \the\northdir { north}}} % grid or true north

\fi   

# % Could report declination here 

\edef\tmp{\the\magdecl} \ifx\tmp\empty \else

  {\the\legendtextsize\ss\the\magdecl { deg magnetic
declination}\par} %HOW TO LIMIT TO ONE DECIMAL PLACE?

\fi  

\fi   

  \par\par  

  \fi % ATTR__elevation % end plan

 

Above code produces the top couple of lines of this header snapshot.  It
should be different depending whether it is a plan or elevation, but at
present is always this way.  However the coordinate system test does work
properly.



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

[Therion] extend

[Bruce Mutton via Therion]

After thinking in a more structured way, and after Evaristo’s clear explanation 
and request, I have gone back to my original line of thinking; that extend 
(left right vertical ignore) for splays has no direct meaning.  Perhaps it is 
more correct to say; it is not generally meaningful to apply extend control 
statements to splays.  Extend controls applied to legs will, however, affect 
where the splays are projected.  And in most cases the splay projection can be 
calculated explicitly without need of further user input.

 

I will try to explain my proposal with a word picture.  I would draw a diagram, 
but my skills don’t extend that far.

Plan Projection

Consider looking down on the cave, and projecting onto a horizontal plane, the 
shape and position of the stations, legs and splays. This is a fixed shape, 
once loops are closed.  It would not be appropriate for user control to move 
the projected position of splays.  I don’t think there would be any dispute 
here.

Elevation projection

This is the same as for a plan projection, except that the whole cave is viewed 
from the side, projected onto a vertical plane, looking say north-east, or any 
other compass direction.  Again, user control of projected splay positions 
would not be appropriate.

Extended Elevation (projection)

Here I am including both the concepts that Evaristo introduced, of Extended 
Profile and Idealised Profile. To some degree they are the same thing, once 
artistic input has been applied.

1.  We could think of one survey leg that has been extended left or right 
as been projected in a vertical plane, that passes through the leg.  The 
stations at each end of the leg are of course in that plane as well.
2.  Now the splays at each station are projected onto that plane, in the 
same way as described for plan projections and elevation projections above.  
This means that for this leg, and the splays attached to its stations, there is 
only one possible projected position and shape for its splays, in its vertical 
plane.  Splays that are not perfectly aligned with the plane will be 
foreshortened.
3.  Now the legs vertical plane is rotated or flattened out onto the 
‘page’, left or right as we specify, and we have one leg for our extended 
elevation.  No further user control is desirable at this point.
4.  If there is another leg at the end of the leg we are considering, we 
have to think about which splays are associated with which of the legs.  
5.  If there are only two legs from each station, this is easy, if the 
splay projected position is not between the stations, then the splay is 
projected in the other legs vertical plane.  If there are multiple legs 
intersecting, say at a passage junction, then it is more complicated, but a 
rational computation could be devised.  There may also be some justification 
for a user control that allows the user to assign which survey leg each splay 
is associated with. 
ie user assigns extend left or right to legs, user optionally assigns legs to 
splays.  This is not the same as extending splays left or right, as if we did 
that, the splay lengths would be too long (not projected into the legs vertical 
plane).
6.  Therion now follows this process for all legs that make up the cave and 
we have an extended elevation.  And as described above, splays are not directly 
manipulated by extend left, right or ignore.
7.  But there are some difficulties.  Vertical legs that are extended left 
or right will be a problem.  And any leg that is ‘extend vertical’ will be a 
problem.  In both cases there is no unique vertical plane in which to project 
the splays.  In each case, if there is only one vertical leg at a time ie there 
is a non-vertical leg at each end, then the non-vertical legs planes can be 
used to project the splays at each end.  No problem.
8.  Where there are multiple (near) vertical legs, either because you are 
surveying down a shaft, or because the user has extended multiple legs 
vertically, there is still a problem.  I can think of two expedient solutions:
-Allow splays to be extended left and right – This will have the effect of 
making these passages seem larger, as the splay lengths will not be 
‘projected’, or
-Have Therion refer back to a bearing associated with the vertical leg (entered 
in the centreline data) to decide the orientation of the vertical plane for 
splay projections, and then continue exactly as described above.  Although 
additional control would be required…
extend vertical -splay-left
extend vertical -spay-right
…in order for Therion to know which way around to project the splays.
I prefer the second option I think.

 

Does that make sense?

 

Aside from my explanation above, I have a selfish reason for preferring to 
minimise the ability to explicitly control splay extensions.  It is because I 
suspect that splay control can only be specified if the extend control 
statements are 

Re: [Therion] extend

[Bruce Mutton via Therion]

Marco, Evaristo

Looking also at Evaristo’s TopoDroid screenshots, which highlight the issue 
nicely, it seems to me that both TopoDroid (which I have not used) and 
PocketTopo (which I use) handle splays similarly, and automatically (maybe not 
TopoDroid?) and that automatically is the right way to do it, based on some 
combination of splay, leg and leg extend direction (difficult and arbitrary as 
a precise solution might be).  A precise solution is a difficult concept where 
extend switches say from left to right – although the software coders will be 
the experts on this.  At least PocketTopo mostly gives sensible splays.

Therion also messes up PocketTopo’s extended splay legs, and I just ignore it, 
because hopefully I still have the sketch to trace.

In theory a nice solution would be for Therion to somehow preserve what the 
source software gives it.  But in practice not so easy, especially as I always 
end up changing the extend specifications when it comes time to produce a 
finished drawing.

 

Marco, are you suggesting below that extend -1 would be left, extend 0 would be 
vertical, and extend 1 would be right?

Conceptually seems OK.  Personally I would not be bothered with that level of 
refinement, but I concede there are times when it would be nice to foreshorten 
a passage just a little in order to close a loop, or make something look or fit 
better.  Fairly often the extend direction I choose in the cave gets modified 
by the time I get to drawing the map!  More I think about it, the more I like 
it.

 

> btw, are vertical extend considered in the computation of the cave length by 
> therion?

I don’t know for sure, but it would seem illogical for anything about the 
drawing or presentation projection (extend is a hybrid of both) to have any 
effect on the centreline length or depth reported by Therion.  Length and depth 
are a survey centreline property.  Length should be the sum of all survey legs 
that are not duplicate and not splay.  It also includes nosurvey legs. Depth is 
the vertical range between highest station and lowest station, and I think it 
goes further to include possibly the highest and lowest splay points and or up 
and down measurement. Conceptually an elevation drawing could affect the 
reported depth, but as far as I can tell, elevation drawings are not yet 
considered when producing 3d models, so it would seem unlikely that Therion 
would bring them into the depth calculation.  Or did I misunderstand your 
question?

 

Another idea.

Debug could have an extend option ‘debug extend’.  It might include adding 
arrow heads and L, R or V to the centreline of each survey leg (not so 
meaningful for splays). And maybe there is some way to graphically show why 
some ignore statements shift large chunks of centreline far to the left or 
right – maybe by showing hidden legs in very light colour?  In conjunction with 
‘debug station-names’ this would help when trying to untangle large 
multi-looped survey networks.

 

Bruce

 

 

From: Therion  On Behalf Of Marco Corvi via Therion
Sent: Friday, 8 June 2018 10:51 PM
To: therion@speleo.sk
Cc: Marco Corvi 
Subject: [Therion] extend

 

i think that extend should take values in the interval [-1,1], ie also 
fractional values, plus some special value such as "ignore" to open loops, and 
"undefined" to let the program choose, because it's a nuisance to enter a 
decimal number for every shot (legs + splays).

therion uses the left/right normal/reverse etc. solution, 

 

and users should be allowed to set extend also for splays, if they need to.

 

for now, let's use left/right/vert, and ignore only to open loops

 

btw, are vertical extend considered in the computation of the cave length by 
therion ?

 

marco

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

[Therion] Conflict between "extend ignore" command and inverse legs

[Bruce Mutton via Therion]

Hi Marco

I am not sure I understand, let me test my thinking, for everyone to pick apart 
:)

 

I think the extend options provide control of the non-splay survey legs.  In 
general that control amounts to left, right, vertical, not at all, or not 
visible.

The splay legs should just ‘wobble around’ as a second order effect, in 
response to the extend parameters applied to the non-splay legs.

So the only sensible behaviour for splays is ‘extend auto’, and my observation 
is that this is already coded into PocketTopo and Therion, and so there is no 
reason to require the user to invoke ‘extend auto’ manually.

 

As noted in previous threads, Therion and PocketTopo do manage to orient splay 
legs differently.  Quite often I have to mentally reorient splays when drawing 
in Therion Drawing Editor.  Neither application seems to do it perfectly, but 
then because the shape of the extended centreline network is as much an 
arbitrary artistic choice on the part of the user, as it is based on hard 
numeric data, there is perhaps no ‘right approach’ for the software to take. I 
suspect that I have observed that TopParser can affect the orientation of 
splays as well, but I am not sure of that.

 

I think the right approach is to aim for Therion (and PocketTopo, TopoDroid) to 
orient splays automatically, based on the extend directions of the incoming and 
outgoing non-splay legs.  If the applications were to allow direct user control 
of splay extend direction, then the statements should not be able to be 
confused with existing statements that control the non-splay legs (ie adopt 
extend splay left, extend splay right, extend splay vertical, extend splay 
auto). Perhaps this topic is something the authors should collaborate on to 
achieve a consistent behaviour?

 

What do you think?

Bruce

 

From: Therion  On Behalf Of Marco Corvi via Therion
Sent: Thursday, 7 June 2018 11:29 PM
To: therion@speleo.sk
Cc: Marco Corvi 
Subject: Re: [Therion] Conflict between "extend ignore" command and inverse legs

 



I have commented all the splays "extend ignore", and Therion is doing 
now a good job, ignoring the appropriate leg (extend ignore 83 92). All 
the splays "extend ignore" was confusing the Therion compiler.

This data is an export from Topodroid, that incorporates the "extend 
ignore" command before the splays shots. I will comment to Marco Corvi 
on the problem.

 

@ Evaristo & Bruce:

what about a command "extend auto", which means let therion decide how to 
extend the splay shot ?

 

for the moment therion parser could behave as if the command weren't there.

 

marco

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

[Therion] Conflict between "extend ignore" command and inverse legs

[Bruce Mutton via Therion]

Evaristo

An interesting situation.  I have not tried to compile your data, but notice 
you have extend ignore prior to each set of splays.

I don’t think extend ignore has any useful function with respect to splays (but 
I am not sure).

I suspect what you have done is effectively follow ‘extend ignore’ with ‘extend 
left’ without any non-splay legs in between.  Possibly a confusing situation 
for Therion. Have a look at my understanding here 

  (although it does not yet consider splays at all, or inverse (backsight) legs 
properly).

 

What happens if you remove all the extend ignores prior to the splay legs?

 

Bruce

 

From: Therion  On Behalf Of Evaristo Quiroga via 
Therion
Sent: Thursday, 7 June 2018 5:40 AM
To: therion@speleo.sk
Cc: Evaristo Quiroga 
Subject: [Therion] Conflict between "extend ignore" command and inverse legs

 

Hi,

I usually do my surveys doing inverse measures. I go ahead by positioning the 
points, and doing the measurements with the distoX2 looking back (inverse) and 
finally do the splay measurements at that destination point. My assistant is in 
origin point, and don't have survey experience, is only putting the target in 
the anterior point . With this I get all the data (leg and from and to splays) 
to be able to draw the sketches. 



You can look a example the data results:

extend left
82 81 10.47 147.7 1.4
extend ignore
82 . 0.53 230.7 1.2
82 . 1.85 66.3 -6.5
82 . 1.19 45.5 60.1
82 . 0.65 300.5 -88.8
82 . 2.76 105.7 -5.8
82 . 4.54 127.2 -0.9
82 . 5.86 132.4 -2.1
82 . 1.52 182.2 -8.3
82 . 4.45 156.5 -3.0
82 . 2.62 20.4 -9.8
82 . 2.39 311.0 -6.3
82 . 3.95 324.1 -6.9
extend left
83 82 7.95 146.4 1.4
extend ignore
83 . 0.35 235.9 1.0
83 . 1.87 38.5 -6.1
83 . 0.94 5.9 76.3
83 . 1.06 40.4 -80.9
83 . 4.49 117.2 -5.0
83 . 2.61 85.7 16.9
83 . 2.87 107.9 -6.0
83 . 2.98 154.2 -11.3
83 . 3.94 148.4 -3.6
83 . 5.92 127.1 -5.7
83 . 3.67 327.8 -5.8
83 . 4.40 300.2 -12.5
83 . 2.65 334.7 -20.5
83 . 5.62 132.6 3.5
extend left
84 83 8.40 132.5 3.5
extend ignore
84 . 1.39 215.1 23.4
84 . 2.51 101.7 -0.8
84 . 1.89 195.1 67.5
84 . 2.00 100.7 -28.2
84 . 3.16 118.1 -2.7
84 . 4.68 149.7 1.0
84 . 5.15 62.5 2.7
84 . 2.12 33.9 -1.3
83 . 4.99 250.9 -7.6
extend left
85 84 5.03 234.4 -6.3
extend ignore
85 . 2.56 261.5 -0.7
85 . 1.34 276.4 31.0
85 . 1.05 282.5 -62.6
85 . 4.43 304.8 -1.1
85 . 5.80 314.2 -1.4
85 . 1.33 181.0 0.5
extend left
86 85 6.33 149.5 -2.0
extend ignore
86 . 1.19 252.8 -18.6
86 . 2.85 85.3 3.7
86 . 0.92 225.3 -84.7
86 . 2.23 136.3 10.5
86 . 3.96 135.4 -5.4
86 . 3.83 143.8 -8.1
86 . 2.25 203.4 -10.9
86 . 3.50 186.7 -8.6
extend left
87 86 3.05 187.0 -8.7
extend ignore
87 . 2.59 223.7 -18.5
87 . 1.09 32.0 -1.2
87 . 1.67 183.2 59.1
87 . 0.58 315.6 -83.5
 
extend right
88 87 7.46 330.8 -3.4
extend ignore
88 . 0.77 66.7 4.2
88 . 0.47 257.5 -7.8
88 . 2.56 326.1 74.5
88 . 0.41 247.0 -80.9
88 . 1.85 127.1 15.2
88 . 0.96 104.7 4.6
88 . 0.85 207.2 1.2
88 . 4.20 343.3 -16.6
extend right
89 88 2.20 349.0 -20.5
extend ignore
89 . 0.95 43.1 -5.6
89 . 0.72 62.1 82.7
89 . 0.39 99.4 -77.6
89 . 0.89 324.9 -26.4
89 . 1.43 359.5 -23.5
89 . 1.08 72.7 -9.7
89 . 1.59 105.4 -3.8
89 . 2.56 125.6 -5.7
extend right
90 89 1.39 300.3 -13.8
extend ignore
90 . 0.46 62.7 -3.4
90 . 0.50 245.3 1.2
90 . 0.48 246.5 70.4
90 . 0.70 300.2 -82.3
90 . 1.74 184.4 -12.0
90 . 3.09 169.6 -9.1
90 . 3.69 166.8 -8.2
90 . 2.02 152.3 -17.2
90 . 1.40 132.2 -19.0
extend right
91 90 5.71 340.7 6.0
extend ignore
91 . 0.96 37.0 2.2
91 . 1.04 40.9 58.3
91 . 0.29 34.5 -56.7
91 . 1.48 338.9 -0.1
91 . 0.99 331.4 2.8
91 . 1.07 3.2 3.6
91 . 3.51 345.8 0.1
extend right
92 91 2.04 305.9 4.0
extend ignore
92 . 1.47 305.9 -11.0
92 . 1.06 301.4 45.1
92 . 0.43 339.3 -76.8
92 . 1.17 348.7 1.3
92 . 0.56 16.6 -9.2
92 . 0.57 270.9 -8.5
92 . 1.99 270.1 -7.4
92 . 1.56 230.3 -14.0
extend right
83 92 4.24 71.7 18.0  
  extend ignore  83 92
 

extend left
93 87 3.12 123.4 7.5
extend ignore
93 . 1.79 225.3 -3.2
93 . 1.70 49.9 -3.0
93 . 1.18 100.0 78.0
93 . 3.21 169.9 -2.6
93 . 2.09 88.5 -2.4
93 . 2.36 14.0 -2.1
93 . 3.78 347.3 1.9
93 . 3.62 300.1 -2.1
93 . 2.32 278.7 -3.8

In this data I have a loop. The main passage is: 82-83-84-85-86-87-93. And the 
secondary passage is: 87-88-89-90-91-92-83.

When I compile the data and produce a XVI file, Therion is making the secondary 
passage the main centerline, 

[Therion] Defining a user symbol that contains a short text string

[Bruce Mutton via Therion]

Thanks to Dave I did a little reading, and have come up with a partial
solution.

 

In the screenshot below, the top line shows that .

point 0 0 u:graffiti -align b (or centre or t)

works correctly.

The second line shows that -scale xs, s, l and xl work OK for the circle and
box, but not the label.

Similar for -orientation (rotation) on the third line.

 

For some reason the centre of the scale and rotation transformation is in
the wrong place for the label.  There is something I am doing wrong with the
label part of the symbol definition.  Any ideas?





 

My code so far looks like.

code metapost

def p_u_graffiti (expr pos,theta,sc,al)=

  U:=(.2u,.5u);

  T:=identity aligned al rotated theta scaled sc shifted pos;

  

  %# pos and al work fine in label below, but theta and sc transformed about
far off point???

  label (btex Gr etex, pos) rotated theta scaled sc aligned al;  % btex and
etex are wrappers around code to be process by tex

  

  thdraw unitsquare scaled u shifted (-0.5u,-0.5u) rotated 45 withpen PenD;
% diagonal box with thin pen

  thdraw fullcircle scaled u withpen PenD;  

enddef;

 

initsymbol("p_u_graffiti")

text en "point u:graffiti" "Historic graffiti"

Bruce

 

From: Bruce Mutton  
Sent: Tuesday, 29 May 2018 10:15 PM
To: 'List for Therion users' 
Subject: Defining a user symbol that contains a short text string

 

Good evening

I'd like to make a user defined symbol that is simply an ascii text string.
A quick and dirty adhoc symbol if you like. If I was going to be fancy, I
would add a box around it like in the example of Dave Clucas that I have
copied and modified below.

 

So rather than defining the shape of the omega symbol using metapost, I'd
like to hard code an ascii character, say "E".

The yellow shaded text below needs to be replaced with some simple metapost,
but I am too lazy to research and trial things.

I notice that other examples tend to use a copy of the p_label definition,
and modify that.  I would rather not head down that route, as then my custom
code would overwrite potential future improvements to Therion's source code.


 

My plan is not really to create an alternative to the entrance symbol, but
rather to create a template quick and dirty creation of single use or
unusual symbols, that can be enumerated in the legend.

 

Does anyone happen to know how to modify the code below to do what I
describe?

 

Thanks

Bruce

 

 
 

code metapost

def p_u_ent (expr pos,theta,sc,al)=

  U:=(.2u,.5u);

  T:=identity aligned al rotated theta scaled sc shifted pos;

  path p;

  p = (-.3u,-.25u) -- (-.2u,-.25u){dir 135} .. (0u, .25u) .. {dir
225}(.2u,-.25u) -- (.3u,-.25u); % define omega shape

  thdraw p withpen PenA;  % draw it with fat pen

  thdraw unitsquare scaled u shifted (-0.5u,-0.5u) rotated 45 withpen PenD;
% diagonal box with thin pen

enddef;

 

initsymbol("p_u_ent")
  
def p_u_ent_legend =
 p_u_ent(  )
enddef;
endcode
text en "point u:ent" "E for entrance" #text to appear in legend
 

 

 

 

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

[Therion] Defining a user symbol that contains a short text string

[Bruce Mutton via Therion]

Good evening

I'd like to make a user defined symbol that is simply an ascii text string.
A quick and dirty adhoc symbol if you like. If I was going to be fancy, I
would add a box around it like in the example of Dave Clucas that I have
copied and modified below.

 

So rather than defining the shape of the omega symbol using metapost, I'd
like to hard code an ascii character, say "E".

The yellow shaded text below needs to be replaced with some simple metapost,
but I am too lazy to research and trial things.

I notice that other examples tend to use a copy of the p_label definition,
and modify that.  I would rather not head down that route, as then my custom
code would overwrite potential future improvements to Therion's source code.


 

My plan is not really to create an alternative to the entrance symbol, but
rather to create a template quick and dirty creation of single use or
unusual symbols, that can be enumerated in the legend.

 

Does anyone happen to know how to modify the code below to do what I
describe?

 

Thanks

Bruce

 

 
 

code metapost

def p_u_ent (expr pos,theta,sc,al)=

  U:=(.2u,.5u);

  T:=identity aligned al rotated theta scaled sc shifted pos;

  path p;

  p = (-.3u,-.25u) -- (-.2u,-.25u){dir 135} .. (0u, .25u) .. {dir
225}(.2u,-.25u) -- (.3u,-.25u); % define omega shape

  thdraw p withpen PenA;  % draw it with fat pen

  thdraw unitsquare scaled u shifted (-0.5u,-0.5u) rotated 45 withpen PenD;
% diagonal box with thin pen

enddef;

 

initsymbol("p_u_ent")
  
def p_u_ent_legend =
 p_u_ent(  )
enddef;
endcode
text en "point u:ent" "E for entrance" #text to appear in legend
 

 

 

 

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

Re: [Therion] Remove individual symbols from legend

[Bruce Mutton via Therion]

That was easy.

 

text en "line border:visible" ""

text en "line border:temporary" ""

text en "line border:presumed" ""

 

Thanks Torsten

 

 

From: Therion <therion-boun...@speleo.sk> On Behalf Of Torsten Schnitter via 
Therion
Sent: Monday, 28 May 2018 8:13 PM
To: List for Therion users <therion@speleo.sk>
Cc: Torsten Schnitter <torsten.schnit...@netcologne.de>
Subject: Re: [Therion] Remove individual symbols from legend

 

Hi Brus

To switch off a symbol in the legend box just add a line to your thconfig file 
with "empty" text for that symbol:
text en line border ""

Torsten





Bruce Mutton via Therion <therion@speleo.sk <mailto:therion@speleo.sk> > hat am 
28. Mai 2018 um 09:48 geschrieben: 

It’s winter here so I’m drawing maps…

 

>From time to time I don’t want particular symbols to turn up in the legend. Is 
>it possible to turn off individual legend symbols, relatively easily with a 
>layout statement?

For example if I want border variants to be removed from the legend?

 



And just on the off chance… has anyone come up with metapost for a line root (a 
root that travels along the floor)?

 

Bruce


 

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


 

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

[Therion] Remove individual symbols from legend

[Bruce Mutton via Therion]

It's winter here so I'm drawing maps.

 

>From time to time I don't want particular symbols to turn up in the legend.
Is it possible to turn off individual legend symbols, relatively easily with
a layout statement?

For example if I want border variants to be removed from the legend?

 



And just on the off chance. has anyone come up with metapost for a line root
(a root that travels along the floor)?

 

Bruce

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

[Therion] Therion drawing file, scrap advice

[Bruce Mutton via Therion]

My thought’s on Martin’s advice…

 

>Try to create small scraps (max 100 m?). And try to create new .th2 file for 
>each one scrap. This will reduce opening time much!

 

Small scraps are good, and fast to load and render, but one scrap per file 
would seem to be excessive unless you are dealing with extra large scraps.

By limiting to one scrap per file, you are removing the significant advantage 
of automatic scrap joins that Therion enforces when points and line points from 
adjacent scraps are snapped to the same location.  And in addition you will 
have many more ‘input drawing.th2’ statements and ‘join scrap1 scrap2’ 
statements.

 

I am looking at a small cave I surveyed two weeks ago, just under 130m in 
length.  Parts of it are a little bit complex, and I am drawing at 1:250 
instead of my usual 1:500 or 1:1000, so scraps have been broken into smaller 
pieces than would be typical and so I have more of them.  It is much more 
detailed than my typical effort.

*   I made 3 PocketTopo files, because the plan and elevation complexities 
made it expedient to start new files (in other cases 500-1000m per PocketTopo 
would be a typical upper limit).
*   That led to 3 survey.th files, 3 plan.th2 files and 3 elev.th2 files.
*   Between the plan and elevation projections, the drawing files have 32 
scraps (5-6 scraps per file, 4 of them are cross sections), and total 2800 
lines (292-790 lines per file).
*   By maximising scraps per file, I estimate I have saved myself 24 input 
statements, and 20 - 25 join statements, and in addition, I am mostly drawing 
with the context of adjacent scraps in full view.

 

If this was part of a large cave drawn at 1:1000, there might have been less 
than one third the number of scraps (still a lot, but required to avoid single 
scraps passing over or under themselves).  The general point is, in a large 
cave system, one scrap per file would seem to create a lot of unnecessary work 
and input/join statements.

 

And I doubt the number of scraps per file is what actually causes the reduction 
in performance.

I would expect it is more related to the number of entities or number of lines 
within the th2 file, and the size of any xvi or image files loaded.  From 
memory the rendering starts to become noticeably slower at 1000-1500 lines per 
th2 file, and intolerable at 3000 lines per th2 file (assuming a minimal xvi 
image).  This will vary from computer to computer, and your tolerance to 
waiting.

 

My rules of thumb are;

*   Minimise the size of survey trip files (limits size of and delay due to 
xvi and sketch files)  I find 200 - 600m is good - same as Martins advice, we 
just have different thresholds.
*   Make as many scraps as you want or need in each th2 file, and avoid 
more than one th2 file per survey trip file if you can help it – differs from 
Martins advice – almost opposite!
*   Once your th2 file reaches about 1500 lines, start considering another 
th2 file. 

Having said that, I don’t think there are any absolute limits, it’s just a 
matter of preference.

 

Bruce

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

[Therion] Wrong average calculation from compass/backcompass data

[Bruce Mutton via Therion]

I agree to some extent with both sentiments below, however the software
should not abort just because of backsight discrepancies.

What about adding one more line to the Therion and or Survex log file;
either

"There are no backsights in the centreline", or

"Maximum backsight discrepancy is xx [degrees|grads]", as approprite

That way the user can be fully informed and make their own decision about
whether to investigate further if the information is not what they expect.

Bruce

 

17. 5. 2018 v 9:25, Evaristo Quiroga via Therion  >:

 

In this case is not a problem with my formula, is a serious magnetic anomaly
(100 degrees difference)  and the program should to stop and to send a
warning. 

 

Evaristo, 

 

Therion is a program to interprete your data, not to solve problems with
your data.

 

It is your responsibility what the data you import into Therion. 

 

Martin S.

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

Re: [Therion] Therion Map Header Overrides

[Bruce Mutton via Therion]

And thanks to Kevin Dixon for reminding me.

You can find much of relevance to Therion within the Survex Manual.  There
is a link to it on the front page of the Therion wiki.



Search the Survex manual for "flags" and you will learn more.

 

Bruce

 

From: Therion <therion-boun...@speleo.sk> On Behalf Of Bruce Mutton via
Therion
Sent: Thursday, 10 May 2018 8:02 AM
To: 'List for Therion users' <therion@speleo.sk>
Cc: Bruce Mutton <br...@tomo.co.nz>
Subject: Re: [Therion] Therion Map Header Overrides

 

Nick

Here are some examples of various 'flags' usage, for shot flags, not to be
confused with station flags.  They are a survey property, not so much a
drawing property.

 

Approximate and duplicate:

https://therion.speleo.sk/wiki/extend?s[]=flags#summary_of_all_extend_option
s_for_survey_centrelines
<https://therion.speleo.sk/wiki/extend?s%5b%5d=flags#summary_of_all_extend_o
ptions_for_survey_centrelines>  and scroll down to the code below "Creating
links between separate caves that are close to each other".  That one is a
bit oddball, not typical usage.

 

https://therion.speleo.sk/wiki/metapost?s[]=flags#general_symbol_examples
<https://therion.speleo.sk/wiki/metapost?s%5b%5d=flags#general_symbol_exampl
es>  to redefine centrelines to reflect flag states.

 

And, um, yes, there is not too much on actual usage examples for flags
surface.  Here is a snippet from my last Sunday's survey efforts.  A short
cave that required three ptopo files to adequately capture it.  It is part
of a survey loop that goes out of one entrance and into another.

 

data normal from to tape compass clino ignoreall

. 

#following legs are within the cave

#3.18 3.192.099 355.01   -32.843.19 entrance rock

#3.18 3.192.098 355.2 -32.67

#3.18 3.192.098 355.31   -32.69

3.183.192.098 355.11   -32.73Calculated leg from 3
above

3.19-  0.269 49.83 -12.76

3.19-  0.588 43.99 45.86 

3.19-  0.714 21.48 76.27 

.

 

flags surface

#following legs are on the surface

  # extend right

#3.19 3.202.819 254.97   -14.443.21 other entrance rock

#3.19 3.202.818 255.03   -14.34

#3.19 3.202.819 255.11   -14.33

3.193.202.819 255.0 -14.37Calculated leg from 3
above

3.20-  0.556 102.47   -59.13

3.20-  1.045 129.78   5.18

#3.20 3.216.017 207.42   -12.3  

#3.20 3.216.026 207.53   -12.4  

#3.20 3.216.067 207.48   -12.46

3.203.216.037 207.47   -12.39Calculated leg from 3
above

 

flags not surface

#following legs are within the cave

3.21-  1.275 43.78 -4.28  

3.21-  2.5841.32 3.61

3.21-  2.914 39.54 15.74 

.

  # extend left

#3.21 3.223.613 113.19   23.44 

#3.21 3.223.616 113.08   23.59 

#3.21 3.223.609 113.05   23.6#rename 3.22 as 3.14 to
acknowledge loop

3.213.143.613 113.13   23.55 Calculated leg from 3
above

3.14-  4.408 324.85   -51.94

 

The survey-list output for this cave looks like.

 


Title

Length

Depth

Explored

Approx.

Duplicate

Surface

Shots

Stations


Wairoa Valley Cave, Nelson

128

10

0

0

3

9

428

431


1-Wairoa

46

7

0

0

0

0

131

132


2-Upper, Wairoa Cave

15

3

0

0

0

0

61

62


3-Downstream, Wairoa Cave

67

3

0

0

0

9

235

235

 

The total survey length (surface + cave + duplicate) is 140m, and 9m of it
is on the surface.  There is also 3m of survey in there that is duplicated
(happens to be a nosurvey "shot" for a visual-only connection established at
the whole-cave level of survey.

 

Bruce

 

From: Therion <therion-boun...@speleo.sk <mailto:therion-boun...@speleo.sk>
> On Behalf Of Nick Bairstow via Therion
Sent: Thursday, 10 May 2018 3:02 AM
To: List for Therion users <therion@speleo.sk <mailto:therion@speleo.sk> >
Cc: Nick Bairstow <n...@pff.uk.com <mailto:n...@pff.uk.com> >
Subject: Re: [Therion] Therion Map Header Overrides

 

Bruce, I have never used flags. I have just been though the Therion book and
wiki for information but for clarification could you post an example of
surface flag use please.  

 

Thanks.

 

Nick

 

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Bruce Mutton
via Therion
Sent: 09 May 2018 11:04
To: 'List for Therion users' <therion@speleo.sk <mailto:therion@speleo.sk> >
Cc: Bruce Mutton <br...@tomo.co.nz <mailto:br...@tomo.co.nz> >
Subject: [Therion] Therion Map Header Overrid

Re: [Therion] Therion Map Header Overrides

[Bruce Mutton via Therion]

Nick

Here are some examples of various 'flags' usage, for shot flags, not to be
confused with station flags.  They are a survey property, not so much a
drawing property.

 

Approximate and duplicate:

https://therion.speleo.sk/wiki/extend?s[]=flags#summary_of_all_extend_option
s_for_survey_centrelines
<https://therion.speleo.sk/wiki/extend?s%5b%5d=flags#summary_of_all_extend_o
ptions_for_survey_centrelines>  and scroll down to the code below "Creating
links between separate caves that are close to each other".  That one is a
bit oddball, not typical usage.

 

https://therion.speleo.sk/wiki/metapost?s[]=flags#general_symbol_examples
<https://therion.speleo.sk/wiki/metapost?s%5b%5d=flags#general_symbol_exampl
es>  to redefine centrelines to reflect flag states.

 

And, um, yes, there is not too much on actual usage examples for flags
surface.  Here is a snippet from my last Sunday's survey efforts.  A short
cave that required three ptopo files to adequately capture it.  It is part
of a survey loop that goes out of one entrance and into another.

 

data normal from to tape compass clino ignoreall

. 

#following legs are within the cave

#3.18 3.192.099 355.01   -32.843.19 entrance rock

#3.18 3.192.098 355.2 -32.67

#3.18 3.192.098 355.31   -32.69

3.183.192.098 355.11   -32.73Calculated leg from 3
above

3.19-  0.269 49.83 -12.76

3.19-  0.588 43.99 45.86 

3.19-  0.714 21.48 76.27 

.

 

flags surface

#following legs are on the surface

  # extend right

#3.19 3.202.819 254.97   -14.443.21 other entrance rock

#3.19 3.202.818 255.03   -14.34

#3.19 3.202.819 255.11   -14.33

3.193.202.819 255.0 -14.37Calculated leg from 3
above

3.20-  0.556 102.47   -59.13

3.20-  1.045 129.78   5.18

#3.20 3.216.017 207.42   -12.3  

#3.20 3.216.026 207.53   -12.4  

#3.20 3.216.067 207.48   -12.46

3.203.216.037 207.47   -12.39Calculated leg from 3
above

 

flags not surface

#following legs are within the cave

3.21-  1.275 43.78 -4.28  

3.21-  2.5841.32 3.61

3.21-  2.914 39.54 15.74 

.

  # extend left

#3.21 3.223.613 113.19   23.44 

#3.21 3.223.616 113.08   23.59 

#3.21 3.223.609 113.05   23.6#rename 3.22 as 3.14 to
acknowledge loop

3.213.143.613 113.13   23.55 Calculated leg from 3
above

3.14-  4.408 324.85   -51.94

 

The survey-list output for this cave looks like.

 


Title

Length

Depth

Explored

Approx.

Duplicate

Surface

Shots

Stations


Wairoa Valley Cave, Nelson

128

10

0

0

3

9

428

431


1-Wairoa

46

7

0

0

0

0

131

132


2-Upper, Wairoa Cave

15

3

0

0

0

0

61

62


3-Downstream, Wairoa Cave

67

3

0

0

0

9

235

235

 

The total survey length (surface + cave + duplicate) is 140m, and 9m of it
is on the surface.  There is also 3m of survey in there that is duplicated
(happens to be a nosurvey "shot" for a visual-only connection established at
the whole-cave level of survey.

 

Bruce

 

From: Therion <therion-boun...@speleo.sk> On Behalf Of Nick Bairstow via
Therion
Sent: Thursday, 10 May 2018 3:02 AM
To: List for Therion users <therion@speleo.sk>
Cc: Nick Bairstow <n...@pff.uk.com>
Subject: Re: [Therion] Therion Map Header Overrides

 

Bruce, I have never used flags. I have just been though the Therion book and
wiki for information but for clarification could you post an example of
surface flag use please.  

 

Thanks.

 

Nick

 

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Bruce Mutton
via Therion
Sent: 09 May 2018 11:04
To: 'List for Therion users' <therion@speleo.sk <mailto:therion@speleo.sk> >
Cc: Bruce Mutton <br...@tomo.co.nz <mailto:br...@tomo.co.nz> >
Subject: [Therion] Therion Map Header Overrides

 

Nick

>  The override below is to change the Therion default team, cave length,
cave depth data on the map output. Used in this case because a short surface
survey needed to be shown on the map but the data was skewing the actual
cave length and depth.

 

I'm not sure that is a very good way to deal with the issue.

In the screenshot below I have a surface survey shown (green dots),
designated surface by use of 'flags surface', 'flags not surface'
interleaved with the survey data as appropriate.  No need to fudge the cave
length or depth because Therion does not include surface data in the cave
length.  

There is some complexi

[Therion] Therion Map Header Overrides

[Bruce Mutton via Therion]

Nick

>  The override below is to change the Therion default team, cave length,
cave depth data on the map output. Used in this case because a short surface
survey needed to be shown on the map but the data was skewing the actual
cave length and depth.

 

I'm not sure that is a very good way to deal with the issue.

In the screenshot below I have a surface survey shown (green dots),
designated surface by use of 'flags surface', 'flags not surface'
interleaved with the survey data as appropriate.  No need to fudge the cave
length or depth because Therion does not include surface data in the cave
length.  

There is some complexity around it, but you can show or hide the cave and
surface centrelines using;

  symbol-show group surface-centreline

  symbol-hide group cave-centreline

Bruce

 



 

 

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

[Therion] Map Definitions discussion

[Bruce Mutton via Therion]

Here is a conversation that Nick and I had recently, about using map
definitions.

Bruce

 

From: Nick Bairstow  
Sent: Saturday, 5 May 2018 12:03 AM
To: Bruce Mutton  
Subject: RE: Map Definitions

 

Bruce, thanks for that explanation, I now think I understand things a little
better. You descriptions are once again very clear and understandable. I
will grab some data next week and play around with the various scenarios.

 

I do appreciate your spending time to give advice it is a great help.

 

Cheers,

Nick

 

From: Bruce Mutton
Sent: 03 May 2018 21:03
To: Nick Bairstow  
Subject: Map Definitions

 

Hi Nick

Yes, your folder structure seems normal and appropriate.

 

Believe it or not (my understanding is that) Therion is designed to
automatically produce the 'best' pdf output that it can, based on what has
been input, with minimal effort on the users part.  

But if the user wants to have more control, then they can (I always want .).

That control starts in a thconfig file with the choice to 'select' 'surveys'
and or 'maps' for output.

Then extends to defining 'maps' that can contain either surveys, scraps or
other maps.  Usually you don't include surveys, except that personally I
prefer to while I am progressing through the drawing process**.

 

Have a look at this page https://therion.speleo.sk/wiki/bds#concepts  and
scroll down a bit.

 

"select selects particular surveys and or maps to export. If you do not
select a survey, all surveys are selected by default. If you do not select a
map, all scraps and maps are selected by default. Optional. "

 

This explains why, with no maps defined or no maps selected, you get
everything that you have drawn.  You should also notice that if you have no
scraps drawn, your default output will have all of the cave centrelines
present.  As soon as you have one scrap, centrelines vanish from the output,
and you only get your scrap.

 

If by chance you want to produce an output with only some of what you have
drawn (at and below the current level of hierarchy), or you want to offset
parts of the drawing, then you MUST define maps, and select them for output
appropriately.

 

Also, if you want to see a combination of scrap drawing AND CENTRELINE
outside of the drawn scraps extent, or with splays visible, then you must
include the relevant surveys in map definitions.  See my ** comment above.

 

Survey and map definitions also give you control over the title that appears
on the drawing.

It can be complicated, but I once figured it out, and made this bit of code
to put in layouts used for plan outputs.  I prefer to allow Therion to
decide the output title based on the information I have entered in surveys,
maps and selections, but sometimes an override is required.  Note that
Therion assumes a survey or map title is the same as its id, unless you
specify -title "name" to override the id.  My preference is to always give
surveys or maps likely to be a primary selection for output a title that I
would like to see on a finished pdf output (and use a concise id).

The code, as below, only has effect if due to the users choices, Therion
cannot deduce a unique name for the output.

 

 

   #PLAN Cave Map Details

  #

  # Define Map title overrides

code tex-map

   % Output map title as determined by Therion 5.3 is stored in cavename. 

   % It will be empty if there are multiple maps selected for any one
projection

   % AND there are multiple source surveys identified in the thconfig file 

   % ie Therion can not infer a unique title from the input data given.

   % This code allows you to define an output map title {cavename} if it
happens to be empty

   

  \edef\temp{\the\cavename}% cavename from Therion   

  \edef\nostring{} % empty string 

  \ifx\temp\nostring % test if cavename is empty

% if empty reassign cavename to describe selected maps as a group

 

\cavename={Project Area Caves} 



  \else % if not empty keep the value set by therion, or assign an override
cavename here

  \fi

endcode  

 

This page on  what input data Therion draws on to produce outputs may well
be cryptic, but the bottom rows in the table may help.  It is based on my
deductions and experiments only.

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

 

 

Hope this helps. Good luck

Bruce

 

 

From: Nick Bairstow  
Sent: Friday, 4 May 2018 3:19 AM
To: Bruce Mutton  
Subject: Map Definitions

 

 

Hi Bruce, as I am supposed to be tutoring folk in Therion I thought it wise
to clear up some of "my" questions. I see in the mailing list you have
spoken about this over the years so maybe you can help.

I have a cave that has been surveyed with a total of 6 separate surveys.
i.e. I have 6 topo files. I process each topo file though TopParser and the
outputs file fly off into their relevant folders in the hierarchy. 

 

MainCaveName

 

[Therion] Rename legend symbol "water-flow"

[Bruce Mutton via Therion]

Yes, for example here is what I have sometimes redefined (in English)

 

text en "point water-flow:paleo" "paleo water flow (scallops)"

 

Bruce

 

 
 Evaristo Quiroga via Therion

Tue, 08 May 2018 01:06:54 -0700

Hi,
 
It's possible you have to specify what water-flow type you want, lyke this:
 
   text es "point water-flow:permanent" "curso de agua permanente"
   text es "point water-flow:intermittent" "curso de agua temporal"
 
Regards,
 
Evaristo
 
 
El 08/05/2018 a las 8:56, Torsten Schnitter via Therion escribió:
 
Hi
 
I'm trying to rename a text in the legend.
All parts are working except one: point water-flow
 
Within thconfig I use this:
text es "point water-flow" "flujo de agua"
 
But the text in the legend is not changing from it's original "curso agua"
 
Any help is appreciated.
Thanks.
 
Torsten

 

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

[Therion] Eurospeleo surveying

[Bruce Mutton via Therion]

> 2pm Sunday 26th 'Surveying Workshop' (Lecture Hall 3)
> http://eurospeleo.at/  Anyone planning to go?

As per the message that Martin forwarded, I am interested, but don't think I
can justify travelling around the world.
Some sort of electronic conferencing might be nice, to at least listen in,
and maybe contribute just a little.

Timing will be a bit challenging in NZ, looks like just after midnight on a
Monday morning.

Bruce



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

[Therion] Extended elevation page

[Bruce Mutton via Therion]

Good morning all

I have just put together a Therion Extended Elevations
  page, having convinced myself that
I have almost figured out how to make them work.  You can navigate there
from the wiki start page  , 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
  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] ***UNCHECKED*** scaling line ornamentation - metapost

[Bruce Mutton via Therion]

Thanks Dave

I was not clear enough, -Head can have values; both, all, begin, end, whereas Q 
can be 0, 1, 2, 3, so some go-between is required.

 

I finally looked and found part of it in source file thline.h

 

// tags pre arrow

  TT_LINE_TAG_HEAD_BEGIN = 1,

  TT_LINE_TAG_HEAD_END = 2,

 

Presumably somewhere else NONE is set to or implied as zero and BOTH is set to 
BEGIN + END.

That would complete the mapping from the data type that -Head takes as input in 
a th2 file, to the 0, 1, 2 or 3 that ‘line arrow’ requires for variable Q.

 

I rather suspect I don’t have the requisite knowledge for this, but sometimes I 
feel the need to push the boundaries anyway!

 

:)

Bruce

 

 

From: Therion  On Behalf Of Dave Clucas via Therion
Sent: Saturday, 31 March 2018 2:28 PM
To: therion@speleo.sk
Cc: Dave Clucas 
Subject: Re: [Therion] scaling line ornamentation - metapost (Bruce Mutton)

 

I’m not sure about this but I suspect that it doesn’t involve parsing. It’s 
likely that the metapost expects a parameter or parameters to be passed to it 
which it then assigns to the variable Q in its own procedure. It won’t care 
what the calling program calls it. I think the arrowhead is probably defined 
within an arrow class (arrow.h perhaps).

 

 

On 30 Mar 2018, at 18:00, therion-requ...@speleo.sk 
  wrote:

 

I notice line arrow takes the special argument -head [both | none | begin].
Somewhere between the th2 file and the metapost arrow definition, the
argument -head gets changed to the variable Q that is parsed to the metapost
code, that controls which ends of the arrow line get arrow heads. I have
copied the code below.  Whereabouts is the code that tells Therion that
-head is parsed to the metapost definition as Q?



 

 

Dave Clucas
  dave.clu...@icloud.com

Exploring the World - One cave at a time

 

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

[Therion] scaling line ornamentation - metapost

[Bruce Mutton via Therion]

Hi

I'm wondering if there is a way to scale the size of line ornamentation with
the -scale option?

I am thinking about arrows (and map-connections) as in a previous post.

 

I notice that I can apply -scale to a line wall 

 

Eg 

line wall -scale xs

subtype debris



endline

 

and the line will plot, but at always at normal scale.  I can see why that
might be, as there seems to be no way to pass the scale value into the
metapost definition of the wall (or arrow) line object.

However if I put in a layout.

 

min-symbol-scale m

 

then the wall (or arrow) that has a scale of s or xs will not plot (as I
think is expected). So there is some crude on/off control, but I have not
found where it is done.

 

So I am wondering, is there some way that we can have more refined control
of the scale of line ornamentation (wall debris, blocks, arrow heads)? 

 

I notice line arrow takes the special argument -head [both | none | begin].
Somewhere between the th2 file and the metapost arrow definition, the
argument -head gets changed to the variable Q that is parsed to the metapost
code, that controls which ends of the arrow line get arrow heads. I have
copied the code below.  Whereabouts is the code that tells Therion that
-head is parsed to the metapost definition as Q?

 

Bruce

 

 

In th2 file.

 

line arrow -head both



endline

 

 

In thline.mp or in a layout file.

 

code metapost

% Q = 0 -- no arrows

% 1 -- end

% 2 -- begin

% 3 -- both

def l_arrow (expr P, Q) =

  T:=identity;

  pickup PenB;

  thdraw P;

  p := (-.1u,-.5u)--(0,0)--(.1u,-.5u)--cycle; 

  %  0.25 changed to .5 and close end to get nicer arrowhead

  if odd Q:

thfilldraw p rotated (angle(thdir(P,0))+90) 

 shifted (point 0 of P);

  fi;

  if Q>1:

thfilldraw p rotated (angle(thdir(P,length P))-90) 

 shifted (point infinity of P);

  fi;

enddef;

 

 

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

Re: [Therion] Updated syntax highlight file for Kate/KWrite

[Bruce Mutton via Therion]

Check this is OK. 
https://therion.speleo.sk/wiki/contrib:externaleditors#katepart_kate_kwrite
Bruce

-Original Message-
From: Therion  On Behalf Of Bill Gee via Therion
Sent: Thursday, 29 March 2018 3:36 AM
To: therion@speleo.sk
Cc: Bill Gee 
Subject: [Therion] Updated syntax highlight file for Kate/KWrite

Hello everyone -

I spent more time this morning working through some details in the syntax 
highlighting file for Kate and KWrite.  Attached is version 1.1.  Bruce, can 
you put this on the Web site?

Changes:

-- Added several more keywords such as ceiling-step and floor-step.
-- Created a rule for MetaPost keywords.  This is not perfect - it probably has 
only a few of the keywords it should have.  But it is a start.
-- Numbers are now highlighted in color.
-- Cleaned up some stuff left over from the file I used as a base.

To Do:

The thing that bothers me most is that some keywords (such as "def") are used 
in both MetaPost and TeX code.  I would like to find a way to detect "code 
metapost/endcode" and "code tex-map/endcode" sections, then change the rules 
within those sections.  I think it can be done, but there is a learning curve 
to deal with.

-- 
Bill Gee



On Monday, March 26, 2018 11:00:51 AM CDT Bill Gee wrote:
> Hello everyone -
> 
> Xavier's effort inspired me to take a look at syntax highlighting
> definitions for other editors.  I run Fedora 27 with KDE desktop, so the
> editor I use most is Kate/KWrite.  KDE has a system-wide syntax
> highlighting system that is part of KatePart.
> 
> The attached XML file is for use in either Kate or KWrite.  It is very much
> a work in progress.  I have only scratched the surface of what is possible.
>  One major thing I want to look at is to see if there is a way to make the
> syntax highlighting change in "code metapost" and "code tex-map" sections. 
> KatePart already has highlighting files for metafont and latex.  With any
> luck there is a way to reuse those.
> 
> Copy the XML file to your user profile directory.  The exact location will
> vary depending on your distribution.  On my Fedora 27 system it is
> 
>   $HOME/.local//share/org.kde.syntax-highlighting/syntax
> 
> You may have to create this directory.
> 
> The file can also go in the common syntax highlighting directory which (on
> my system) is
> 
>   /usr/share/kde4/apps/katepart/syntax
> 
> You will need root permissions to copy to this folder.
> 
> The next time you start either Kate or KWrite, the new file will be used.
> 
> I plan to look at syntax highlighting files for both joe and gvim.
> 
> > Dear all,
> > 
> > I am not sure to have post this info for those who are interested in it.
> > 
> > I often edit my therion file inside an external editor as Textwrangler or
> > Brackets. I wrote some configuration files for both softwares to color the
> > Therion’s syntax. That is not complete, they may be still errors, but you
> > can find them here : For Texwrangler :
> > https://github.com/robertxa/Therion-TextWrangler For Brackets :
> > https://github.com/robertxa/Therion-Brackets
> > 
> > Have a good weekend,
> > 
> > Xavier


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

[Therion] Redefining map-connection

[Bruce Mutton via Therion]

Hi, I'm looking for a little metapost guidance.

 

I want to redefine the map-connection line, making the line thicker, dashed,
with a dot at the start and larger arrowhead at the end.  Also a nicer
generic arrowhead shape.

As the default Therion metapost uses a standard arrow definition for 'line
arrow' and for 'line map-connection' I would like to maintain that
efficiency, except I would like the map-connection arrows heads to be two or
three times larger than the standard arrow head.

So far, with the slightly modified standard Therion code below, I have
achieved all of that except for the difference in arrowhead sizes.



Compare this with the original



 

I expect I could do it by duplicating the l_arrow definition (and call it
l_arrowbig for example) , but this seems inefficient.  Could I modify the
size of the arrowhead with the statement that calls   l_arrow(P,1); ?

 

Although I'm thinking possibly that is not the best idea, as scaling l_arrow
will affect the whole line as well as the arrowhead I expect.

Comments?

 

Bruce

 

#ARROW and MAP-CONNECTION REDEFINITIONS

#--

code metapost

% Q = 0 -- no arrows

% 1 -- end

% 2 -- begin

% 3 -- both

def l_arrow (expr P, Q) =

  T:=identity;

  pickup PenB;

  thdraw P;

  p := (-.1u,-.5u)--(0,0)--(.1u,-.5u)--cycle; 

  %  0.25 changed to .5 and close end to get nicer arrowhead

  if odd Q:

thfilldraw p rotated (angle(thdir(P,0))+90) 

 shifted (point 0 of P);

  fi;

  if Q>1:

thfilldraw p rotated (angle(thdir(P,length P))-90) 

 shifted (point infinity of P);

  fi;

enddef;

 

def l_mapconnection (expr P) =

  thdrawoptions(dashed dashpattern(on 1bp off 2bp on 1bp off 2bp) 

scaled (2 * optical_zoom) withpen PenB);

 

  %draw map-connection line with arrowhead at end

  l_arrow(P,1); %How to double or triple arrowhead size with this call?

  

  %draw dot at start of map-connection line

  thdraw point infinity of P withpen pencircle scaled 0.3u; 

  %Why infinity and not 0 for start??  

  %If point before arrow head, then point does not render in legend but does
on map?? 

  

  thdrawoptions();

enddef;

endcode

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

Re: [Therion] Syntax highlighting for therion files (.th, .th2 and .thconfig)

[Bruce Mutton via Therion]

You might like to check and or edit what I have added here 
https://therion.speleo.sk/wiki/contrib:externaleditors#katepart_kate_kwrite

 

Bruce

 

From: Therion  On Behalf Of Bill Gee via Therion
Sent: Tuesday, 27 March 2018 5:01 AM
To: therion@speleo.sk
Cc: Bill Gee 
Subject: Re: [Therion] Syntax highlighting for therion files (.th, .th2 and 
.thconfig)

 

Hello everyone -

 

Xavier's effort inspired me to take a look at syntax highlighting definitions 
for other editors. I run Fedora 27 with KDE desktop, so the editor I use most 
is Kate/KWrite. KDE has a system-wide syntax highlighting system that is part 
of KatePart.

 

The attached XML file is for use in either Kate or KWrite. It is very much a 
work in progress. I have only scratched the surface of what is possible. One 
major thing I want to look at is to see if there is a way to make the syntax 
highlighting change in "code metapost" and "code tex-map" sections. KatePart 
already has highlighting files for metafont and latex. With any luck there is a 
way to reuse those.

 

Copy the XML file to your user profile directory. The exact location will vary 
depending on your distribution. On my Fedora 27 system it is

 

$HOME/.local//share/org.kde.syntax-highlighting/syntax

You may have to create this directory.

 

The file can also go in the common syntax highlighting directory which (on my 
system) is

 

/usr/share/kde4/apps/katepart/syntax

 

You will need root permissions to copy to this folder.

 

The next time you start either Kate or KWrite, the new file will be used.

 

I plan to look at syntax highlighting files for both joe and gvim.

 

-- 

Bill Gee

 

 


On Saturday, March 24, 2018 12:39:40 PM CDT Xavier Robert via Therion wrote:

> Dear all,

> 

> I am not sure to have post this info for those who are interested in it.

> 

> I often edit my therion file inside an external editor as Textwrangler or

> Brackets. I wrote some configuration files for both softwares to color the

> Therion’s syntax. That is not complete, they may be still errors, but you

> can find them here : For Texwrangler :

> https://github.com/robertxa/Therion-TextWrangler For Brackets :

> https://github.com/robertxa/Therion-Brackets

> 

> Have a good weekend,

> 

> Xavier

 

 

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

Re: [Therion] Syntax highlighting for therion files (.th, .th2 and .thconfig)

[Bruce Mutton via Therion]

Thanks Xavier.  

FYI I have added a rudimentary entry to 
https://therion.speleo.sk/wiki/contrib:externaleditors#for_input_files 

If you would like me to add to or reword the entry I can. Or you could contact 
wikiadmin[at]speleo.sk for a username and password, if you’d rather do it 
yourself.

:)

Bruce

 

From: Therion  On Behalf Of Xavier Robert via Therion
Sent: Sunday, 25 March 2018 6:40 AM
To: Therion 
Cc: Xavier Robert 
Subject: [Therion] Syntax highlighting for therion files (.th, .th2 and 
.thconfig)

 

Dear all,

 

I am not sure to have post this info for those who are interested in it.

 

I often edit my therion file inside an external editor as Textwrangler or 
Brackets. I wrote some configuration files for both softwares to color the 
Therion’s syntax. That is not complete, they may be still errors, but you can 
find them here :

*   For Texwrangler : https://github.com/robertxa/Therion-TextWrangler
*   For Brackets : https://github.com/robertxa/Therion-Brackets

 

Have a good weekend,

 

Xavier

 

 

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

Re: [Therion] Georeferenced PNG export problem

[Bruce Mutton via Therion]

>  Another question, can I convert the background to transparent directly from 
> Therion. I want import the georeferenced PNG in Google Earth or GIS, and want 
> only have the cave survey rendered and see the other layers around the cave. 



Try ‘colour map-bg transparent’ in your layout.  Around pg 54 of the Therion 
Book.

If it is working it should give you a pdf of the cave with a transparent 
background.  I have not tested this recently.  When it was first brought in, 
around version 5.3.5, it had to be placed directly in the export statement in 
your thconfig, something like;

export map -layout-colour map-bg transparent

Bruce

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

Re: [Therion] Scaling problems with backgrounds in th2 files - XTherion

[Bruce Mutton via Therion]

I’m a big fan of undo, and use it a lot.  Unfortunately I did not notice the 
reason in this case until too late.  I got to the end of the undo stack before 
the problem was resolved.

I think that the reason I did not take sufficient notice is that although the 
zoom behaviour was not quite right, I was sure I had not rolled the mouse 
wheel.  Hence I though I’d stumbled on a variant of the bug, and so put up with 
it for too long before trying to back out.  

For me rolling the mouse wheel to zoom is such a reflex (almost every 
application uses it) that I do it without realising.  One option, short of 
fixing the bug, would be to have the zoom level display on the menu bar between 
the + and – controls.  That would give the user a cue to an imminent problem.  
The notification in the Drawing Area side menu is buried too deep for the user 
to review constantly.

 

Bruce

 

From: Therion <therion-boun...@speleo.sk> On Behalf Of Martin Sluka via Therion
Sent: Monday, 19 March 2018 10:11 PM
To: List for Therion users <therion@speleo.sk>
Cc: Martin Sluka <martinsl...@mac.com>
Subject: Re: [Therion] Scaling problems with backgrounds in th2 files - XTherion

 

The same problem. I used undo button to return to the correct state.

 

Martin S.

 

 

 

 

19. 3. 2018 v 9:44, Bruce Mutton via Therion <therion@speleo.sk 
<mailto:therion@speleo.sk> >:

 

Today I made a new .th2 drawing file and used a .png file as a background 
image.  Not something I do very much these days, as I typically use .xvi files 
created PocketTopo files.  The xvi images work just fine in XTherion.

 

But as described in the post in this link,  
<https://www.mail-archive.com/therion@speleo.sk/msg06890.html> 
https://www.mail-archive.com/therion@speleo.sk/msg06890.html, there are 
problems when using the mouse wheel to zoom if background images are .jpg or 
.png.  Until now I have adopted a work around of only using the menu + and – 
zoom buttons where th2 files are linked to these.

 

However for one projected elevation drawing, even the + and – controls are 
problematic.  I think I accidentally used the mouse wheel before inserting the 
image.  As a result the image is only aligned with the sketch at one particular 
zoom level.  144% in this case.  There is also a problem with the image 
clipping.



 

In the above example, if I zoom out one level, the drawing reduces, but the 
image does not change by the same amount.



 

If I use the zoom wheel, the situation compounds and gets worse.  So I have a 
situation where I can only align this drawing at one zoom level, and I have to 
be careful not to use the mouse wheel.

Not really a problem in this case, as it is a trivial survey and scrap, but it 
is a significant issue for anyone who might still be regularly using scanned 
sketches for drawing.

 

Is this something that someone knows how to address?

 

I’m using Therion 5.4.1+f0c98ce (2018-03-03)

 

Bruce

 

 

 

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

 

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

[Therion] Scaling problems with backgrounds in th2 files - XTherion

[Bruce Mutton via Therion]

Today I made a new .th2 drawing file and used a .png file as a background
image.  Not something I do very much these days, as I typically use .xvi
files created PocketTopo files.  The xvi images work just fine in XTherion.

 

But as described in the post in this link,
https://www.mail-archive.com/therion@speleo.sk/msg06890.html, there are
problems when using the mouse wheel to zoom if background images are .jpg or
.png.  Until now I have adopted a work around of only using the menu + and -
zoom buttons where th2 files are linked to these.

 

However for one projected elevation drawing, even the + and - controls are
problematic.  I think I accidentally used the mouse wheel before inserting
the image.  As a result the image is only aligned with the sketch at one
particular zoom level.  144% in this case.  There is also a problem with the
image clipping.



 

In the above example, if I zoom out one level, the drawing reduces, but the
image does not change by the same amount.



 

If I use the zoom wheel, the situation compounds and gets worse.  So I have
a situation where I can only align this drawing at one zoom level, and I
have to be careful not to use the mouse wheel.

Not really a problem in this case, as it is a trivial survey and scrap, but
it is a significant issue for anyone who might still be regularly using
scanned sketches for drawing.

 

Is this something that someone knows how to address?

 

I'm using Therion 5.4.1+f0c98ce (2018-03-03)

 

Bruce

 

 

 

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

Re: [Therion] Error When Adding A new Cave to Master Index

[Bruce Mutton via Therion]

Nick

I'm guessing you have created a map that contains the survey only for your
new cave, and a map which contains scraps or maps for your other caves.

I do this intentionally while I am drawing up a new  piece of passage, then
remove the survey map once I am finished.

Bruce

 

From: Therion  On Behalf Of Nick Bairstow via
Therion
Sent: Friday, 2 March 2018 7:38 AM
To: List for Therion users 
Cc: Nick Bairstow 
Subject: [Therion] Error When Adding A new Cave to Master Index

 

I have just added a small cave to my main index .th. Everything compiles but
the pdf shows the new cave as shots and splays not as the normal walls etc
you would expect in a map. All other caves display correctly as intended.

Has anyone point out what I am doing wrong.

 

Nick

 

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

Re: [Therion] Translation doubts: color-legend-explodate X color-legend-topodate

[Bruce Mutton via Therion]

Explodate = passage exploration date

Topodate = passage surveyed date

 

Bruce

 

From: Therion  On Behalf Of Rodrigo Severo via 
Therion
Sent: Friday, 2 March 2018 12:17 AM
To: List for Therion users 
Cc: Rodrigo Severo 
Subject: [Therion] Translation doubts: color-legend-explodate X 
color-legend-topodate

 

Hi, 

 

 

I'm translating a few new texts to portuguese.

 

What is the difference between color-legend-explodate and color-legend-topodate?

 

 

Regards,

 

Rodrigo Severo

 

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

Re: [Therion] grade commande

[Bruce Mutton via Therion]

Phil

I don't do this much, but here is what I do for a low grade survey.

I put this near the start of the low grade survey file.

 

  centreline

grade BCRA3  # low accuracy

# grade BCRA5  # high accuracy

 

...

  Endcentreline

 

I am not sure if the same centreline can have multiple grades if you put grade 
statements in line with your data.

The Therion Book description on page 19 would suggest not, as quoted below.

 

“sd▷ sets the standard deviation for the given
measurements. The Quantity list can contain the following keywords: length, 
tape,
bearing, compass, gradient, clino, counter, depth, x, y, z, position, easting, 
dx, northing, dy, altitude, dz.
• grade  ▷ sets standard deviations according to the survey grade 
specification (see grade command). All previously specified standard deviations 
or grades are
lost. If you want to change an SD, use the sd option after this command. If 
multiple
grades are specified, only the last one applies. You can specify grades only 
for position
or only for surveys. If you want to combine them, you must use them in one 
grade line.

”

 

There are UISv1 grade options these days, but I will let someone else who knows 
them verify that they work…

 

Bruce

 

 

-Original Message-
From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Philippe Vernant 
via Therion
Sent: Friday, 23 February 2018 10:11 AM
To: List for Therion users 
Cc: Philippe Vernant 
Subject: [Therion] grade commande

 

Hi guys,

 

Sorry to bother you with my dumbness, but I can't figure it out how to use the 
command grade based on the manual. Let say that I have a survey with poor 
measurements, how to I apply grade3 to this survey ?

 

Thanks,

Phil

___

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] 'can't read "xth(me, cmds, ....": no such element in array' errors

[Bruce Mutton via Therion]

Rodrigo

Do you still get the error if you remove the loop in the wall?



 

And if you correct the orientation of the line wall in the top right corner 
(it’s yellow tick mark points out, not in)?

 

Bruce

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Rodrigo Severo 
via Therion
Sent: Friday, 23 February 2018 5:27 AM
To: List for Therion users 
Cc: Rodrigo Severo 
Subject: [Therion] 'can't read "xth(me, cmds, ": no such element in array' 
errors

 

Hi,

 

 

I trying to work in a topo I make recently. One of the sketches got way bigger 
than it should and is presenting errors like:

 

can't read "xth(me,cmds,5,18,x)": no such element in array

 

I already reduced the file to something really small and I still get these 
errors most of the times I try to open it.

 

Any ideas on what could be the cause?

 

I send attached both a small version of the sketch that presents the error and 
the complete log of the error.

 

 

Regards,

 

Rodrigo

 

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

Re: [Therion] How to combine two maps

[Bruce Mutton via Therion]

Hi Bill

I think you have the answers you need already, but I’ll add my two bits anyway.

I do almost the same as Ladislav.

Sounds like your caves are or should be part of one Therion project (simply 
because they are in the same general locality).  No need to change anything 
other than to make sure  all of the existing cave folders are collected 
together in a single project folder (as in the image below).

In the example below, my project folder is th_TakakaValley/trunk  (the /trunk 
is just an artefact of the version control system we use) and there are 7 caves.

The other folders are for outputs and standardised layout files.

I use a flat structure these days, ie each individual cave has its own folder, 
with INDEX*.th and thconfig files, which is entirely self-contained (except for 
the output and standard files folders) so an individual cave can be easily 
moved to any other folder location and still compile with little fuss. 

 

Below, the INDEXTakakaValley.thc ties together all of the caves in the project, 
and puts them on the same map.  If two or more of the caves were joined, then I 
would just create another INDEX file in the top level project folder, eg 
INDEXBaigentsBreweryCaves.thc, and possibly matching thconfg and layout files.

 



If you download the latest development version of Therion,  you can use a 
lookup to specify particular colours for each of the caves, as described 
https://therion.speleo.sk/wiki/examples?s[]=lookup#colour_scales_-_lookups 

   (half way down the page).

 

 

Regards

Bruce

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

Re: [Therion] Экспорт в KML - export cave-list html and kml

[Bruce Mutton via Therion]

Thankyou Vlad, makes me feel like I’ve finally made it!  You’ve tricked me into 
starting a wiki post, in the FAQ page.

Right, your BTW made me think to look in the Therion Book (if all else fails, 
read the instructions).

Page 17 clears up the mystery of when Therion assumes a ‘cave’ if none is 
defined, but I think there are other cases.

 

All this looking at cave-list has made me realise I have been defining caves in 
the wrong place, the lowest level trip surveys.

I should be defining them in the next level up, the cave surveys – obvious 
really.

I will play with that for a bit, and I am hoping it does not change the 
behaviour.

 

Bruce

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of   
via Therion
Sent: Sunday, 28 January 2018 7:54 PM
To: List for Therion users <therion@speleo.sk>
Cc: Владимир Георгиев <vld.georg...@gmail.com>
Subject: Re: [Therion] Экспорт в KML - export cave-list html and kml

 

Bruce

Very good test and illustrations. You are my Therion guru :)

Using both markings seems to be a good way to separate the "cave" (main 
entrance marked on the survey command) from the secondary entrances (marked 
with station commands), and to switch the secondary ones on/off in the lists.


​Btw​, if you use -surveys off it hides the entrances, but only if you have 
defined a "cave main entrance" in the survey. If there is no main entrance, it 
still shows all the secondary ones defined with station.

 

Would you have the time to put your description and screenshots in the wiki? 
This is good information have.

Vlad

 

 

On Sun, Jan 28, 2018 at 4:45 AM, Bruce Mutton via Therion <therion@speleo.sk 
<mailto:therion@speleo.sk> > wrote:

Sorry С уважением, I may have taken over your post!

 

> I suspect the kml exports are not reporting the hierarchy however.

I was wrong, export cave-list -fmt kml does report the full hierarchy, and may 
even behave better than the html output.

But it is a bit complicated – I did some testing…

 

Using this general form of survey definition…

survey 01 -title “Some Cave name” -entrance 1  

#defining the entrance here as part of survey definition tells Therion ‘it is a 
cave’

  centerline
cs lat-long
fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
station 3 "Some other entrance name" entrance  

  # Mark station 3 as another entrance of ‘Some Cave name’ cave, and 
display it’s name also 

…

  endcenterline

endsurvey

 

And using these exports….

 

#html

export cave-list \

  -surveys on   \ # on = show survey, cave hierarchy, & entrances so long as 
location is on, 

  # off = show caves only, not entrances, no hierarchy

  -location on \  # on = show cave coords, and entrance coordinates only if 
surveys are on

  # off = no coordinates

   -output ./Output/RiwakaSystemCaves.html 

 

#kml

export cave-list \

  -surveys on   \ # on = show survey, cave & entrances hierarchy

  # off = show caves only, not entrances, no hierarchy

  -location on \  # on|off = no difference

   -output ./Output/RiwakaSystemCaves.kml   

 

Some examples using variations of the above.  In outputs below there are four 
caves explicitly defined; H-Hawkes Cave, Hawkes Kairuru Middle Cave, Kairuru 
Cave, Kairuru 3030.  And one cave that Therion has deduced as it is implied by 
the survey structure; Ngarua cave, Takaka Hill.  (Unfortunately I have not been 
disciplined with naming, so apologies that it is confusing). 

 

“Kairuru 3030” is defined as a cave, and it has two entrances defined in the 
centrelines (that are therefore part of Kairuru 3030 Cave, which has three 
entrances in total).

It is one of many caves in a Therion project that the outputs below are taken 
from.

Here the word ‘cave’ is used to mean the main entrance (ie ‘cave’ is an 
entrance and a cave, whereas ‘entrance’ is just an entrance that is usually a 
part of an already defined cave).

 

HTML Outputs

 

Html surveys on location on (the survey, cave and entrance hierarchy is shown.  
Caves have a length reported, entrances do not)



 

Html surveys on location off (the survey and cave hierarchy is shown, but not 
entrances*.  Caves have a length reported, entrances do not)



*  Could this be a bug? Maybe, maybe not.

The last two records ARE entrances, but they have no survey legs associated, 
they are gps fixes only.  Maybe that is why Therion treats them differently and 
displays these but not others. 

Therion has used the survey hierarchy to infer it is a cave called “Ngarua 
Cave, Takaka Hill” even though there is no cave entrance defined in the survey 
definition.

 

Html surveys off location on (No hierarchy, caves only, no entrances – except 
fixed entrances, has coordinates columns)

Html surveys off location off (No hierarchy, caves only, no entrances – except 
fixed entranc

[Therion] Экспорт в KML - export cave-list html and kml

[Bruce Mutton via Therion]

rance" lines.


Does it make a difference which syntax is used?

Vlad

 

On Sat, Jan 27, 2018 at 11:01 PM, Bruce Mutton via Therion <therion@speleo.sk 
<mailto:therion@speleo.sk> > wrote:

And I have no Russian, but making assumptions based on Vladimir’s response…

(and apologising for using English)

 

There are more subtle nuances that can be conveyed.

Have a look at 
https://therion.speleo.sk/wiki/drawingchecklist?s[]=entrance#points 
<https://therion.speleo.sk/wiki/drawingchecklist?s%5b%5d=entrance#points>  and 
scroll down to ‘Passage Ends’ point entrance.

You can tell Therion to define a cave, and further, specifically define all the 
entrances that the ‘cave’ has.

 

To expand on and change Vladimir’s example

 

survey 01 -title “Some Cave name” -entrance 1  

#defining the entrance here as part of survey definition tells Therion ‘it is a 
cave’

  centerline
cs lat-long
fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
station 3 "Some other entrance name" entrance  

  # Mark station 3 as another entrance of ‘Some Cave name’ cave, and 
display it’s name also 

…

  endcenterline

endsurvey

Have I got that right Vlad?

Bruce

 

 

From: Therion [mailto:therion-boun...@speleo.sk 
<mailto:therion-boun...@speleo.sk> ] On Behalf Of   via Therion
Sent: Sunday, 28 January 2018 7:18 AM
To: List for Therion users <therion@speleo.sk <mailto:therion@speleo.sk> >
Cc: Владимир Георгиев <vld.georg...@gmail.com <mailto:vld.georg...@gmail.com> >
Subject: Re: [Therion] Экспорт в KML

 

Hi

My Russian is not that good, so I will reply in English.

The kml model can export the entrances, if that is what you mean by "объектов". 
To get the name of the cave to display, you have to mark one or more stations 
as entrances. Something like this:

  centerline
cs lat-long
fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
station 0 "Some cave name" entrance  # Mark station 0 as an entrance and 
set the name to be displayed. Not necessarily the same station as the one with 
the coords.
  ...

Vladimir

 

 

2018-01-26 11:08 GMT+02:00 Кунгурская лаборатория-стационар via Therion 
<therion@speleo.sk <mailto:therion@speleo.sk> >:

Здравствуйте.  Подскажите, пожалуйста. Я пытаюсь экспортировать данные
в KML-файл. Вот строка

export model -fmt kml -output Kungur_Z.kml

При   просмотре   kml-файла   он   не  отображает названия объектов, а
отображаются только линии.

Подскажите,  пожалуйста, как сделать так, чтобы названия объектов тоже
отображались?

 


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

 

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

Re: [Therion] Экспорт в KML

[Bruce Mutton via Therion]

Yes it does make a difference. Define a cave with the survey definition. Define 
secondary entrances within centrelines.See the difference if you export caves 
to a html file. For best effect you can do this for a multi cave project where 
each cave has multiple entrances.  I will post example outputs later.I suspect 
the kml exports are not reporting the hierachy however.
Bruce
Sent from my Samsung device, hence the typo's

 Original message 
From: Владимир Георгиев via Therion <therion@speleo.sk> 
Date: 28/01/18  10:16  (GMT+12:00) 
To: List for Therion users <therion@speleo.sk> 
Cc: Владимир Георгиев <vld.georg...@gmail.com> 
Subject: Re: [Therion] Экспорт в KML 

Bruce

Yes, that's right, you can define any number of entrances like this.
Although I admit I haven't used the "survey 01 -title “Some Cave name” 
-entrance 1" syntax. So far I have always listed the entrances within the 
surveys with several  "station XX "Some other entrance name" entrance" lines.

Does it make a difference which syntax is used?

Vlad

On Sat, Jan 27, 2018 at 11:01 PM, Bruce Mutton via Therion <therion@speleo.sk> 
wrote:
And I have no Russian, but making assumptions based on Vladimir’s response…(and 
apologising for using English) There are more subtle nuances that can be 
conveyed.Have a look at 
https://therion.speleo.sk/wiki/drawingchecklist?s[]=entrance#points and scroll 
down to ‘Passage Ends’ point entrance.You can tell Therion to define a cave, 
and further, specifically define all the entrances that the ‘cave’ has. To 
expand on and change Vladimir’s example survey 01 -title “Some Cave name” 
-entrance 1  #defining the entrance here as part of survey definition tells 
Therion ‘it is a cave’  centerline
    cs lat-long
    fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
    station 3 "Some other entrance name" entrance    # Mark station 3 as 
another entrance of ‘Some Cave name’ cave, and display it’s name also …  
endcenterlineendsurvey

Have I got that right Vlad?Bruce  From: Therion 
[mailto:therion-boun...@speleo.sk] On Behalf Of   via Therion
Sent: Sunday, 28 January 2018 7:18 AM
To: List for Therion users <therion@speleo.sk>
Cc: Владимир Георгиев <vld.georg...@gmail.com>
Subject: Re: [Therion] Экспорт в KML Hi

My Russian is not that good, so I will reply in English.The kml model can 
export the entrances, if that is what you mean by "объектов". To get the name 
of the cave to display, you have to mark one or more stations as entrances. 
Something like this:

  centerline
    cs lat-long
    fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
    station 0 "Some cave name" entrance  # Mark station 0 as an entrance and 
set the name to be displayed. Not necessarily the same station as the one with 
the coords.
  ...Vladimir  2018-01-26 11:08 GMT+02:00 Кунгурская лаборатория-стационар via 
Therion <therion@speleo.sk>:Здравствуйте.  Подскажите, пожалуйста. Я пытаюсь 
экспортировать данные
в KML-файл. Вот строка

export model -fmt kml -output Kungur_Z.kml

При   просмотре   kml-файла   он   не  отображает названия объектов, а
отображаются только линии.

Подскажите,  пожалуйста, как сделать так, чтобы названия объектов тоже
отображались?

 
___

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] Экспорт в KML

[Bruce Mutton via Therion]

And I have no Russian, but making assumptions based on Vladimir’s response…

(and apologising for using English)

 

There are more subtle nuances that can be conveyed.

Have a look at 
https://therion.speleo.sk/wiki/drawingchecklist?s[]=entrance#points 
  and 
scroll down to ‘Passage Ends’ point entrance.

You can tell Therion to define a cave, and further, specifically define all the 
entrances that the ‘cave’ has.

 

To expand on and change Vladimir’s example

 

survey 01 -title “Some Cave name” -entrance 1  

#defining the entrance here as part of survey definition tells Therion ‘it is a 
cave’

  centerline
cs lat-long
fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
station 3 "Some other entrance name" entrance  

  # Mark station 3 as another entrance of ‘Some Cave name’ cave, and 
display it’s name also 

…

  endcenterline

endsurvey



Have I got that right Vlad?

Bruce

 

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of   
via Therion
Sent: Sunday, 28 January 2018 7:18 AM
To: List for Therion users 
Cc: Владимир Георгиев 
Subject: Re: [Therion] Экспорт в KML

 

Hi

My Russian is not that good, so I will reply in English.

The kml model can export the entrances, if that is what you mean by "объектов". 
To get the name of the cave to display, you have to mark one or more stations 
as entrances. Something like this:

  centerline
cs lat-long
fix 0 11:22:33.4 22:33:44.5 1234  # set the GPS coordinates and elevation 
of station 0
station 0 "Some cave name" entrance  # Mark station 0 as an entrance and 
set the name to be displayed. Not necessarily the same station as the one with 
the coords.
  ...

Vladimir

 

 

2018-01-26 11:08 GMT+02:00 Кунгурская лаборатория-стационар via Therion 
 >:

Здравствуйте.  Подскажите, пожалуйста. Я пытаюсь экспортировать данные
в KML-файл. Вот строка

export model -fmt kml -output Kungur_Z.kml

При   просмотре   kml-файла   он   не  отображает названия объектов, а
отображаются только линии.

Подскажите,  пожалуйста, как сделать так, чтобы названия объектов тоже
отображались?



 

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

[Therion] -scale number for cross-sections

[Bruce Mutton via Therion]

I was just adding some cross sections to a drawing, and it occurred to me to
try the -scale  option, as in this case it would be nice to show
sections at twice the size of the main passage drawing (plan or elevation).



Therion 5.4 (5.4.1 now 2017-04-18)

added support for -scale  for point and line symbols (1.0 ≡ medium
symbol size)



So I tried

point section -scrap 03-GrowlerPlan-x1.8 -align r -scale 2



As I expected, it did not work, although no errors reported either.

I was wondering if this is something that is easy enough to implement, and
if people see scalable passage views (relative to the output scale) as a
desirable feature?



Bruce

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

Re: [Therion] Scaling problems with backgrounds in th2 files

[Bruce Mutton via Therion]

I have experienced both, with same work arounds in each case.

Most often as Evaristo describes it however.

Bruce

 

From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Martin Sluka via 
Therion
Sent: Monday, 22 January 2018 11:03 AM
To: List for Therion users 
Cc: Martin Sluka 
Subject: Re: [Therion] Scaling problems with backgrounds in th2 files

 

Evaristo,

 

I have experienced this problem too but in different way. Background moving is 
accidental very often if I only touch scroll function on mouse. So I have to 
use undo several times to restore correct state.

 

m.s.

 

21. 1. 2018 v 20:01, Evaristo Quiroga via Therion  >:

 

Hi John,

I have experienced the same zoom problems in Windows with the scroll wheel use 
or + -. If you play with the + - you see, the trace and the background image 
are well placed at 25%, 50%, 100% ,200% and 400%. When you push further  this 
scales the trace and background image are wrong placed. With the scroll wheel 
they are wrong always because the % zoom are normally further or between this 
scales. 

I think is a program bug. 

But we have a trick to overcome the problem. Only use the zoom button in the 
"Drawing Area" (above the "Background image" control) to choose the scales 25%, 
50%, 100% ,200% or 400%, when you want the trace and background image well 
placed. And use scroll wheel or + - when you want zoom  only the trace quickly. 

Evaristo. 







 

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

[Therion] Redefined point continuation does not obey -align properly

[Bruce Mutton via Therion]

Good morning

Something I noticed some years ago, and I have noticed again recently.

The alignment of point continuations does not properly adhere to the
alignment conventions that other textual point labels (such as label,
remark, date) do.

 

-align [left | right]  typically draws the symbol to the left or right of
the 'point' that is drawn.

 

For continuations, this occurs for the question mark, but not for the
'debug-like' text that is written describing the continuation.

This debug-like text is always written to the right of the question mark.

The debug-like text does responds to  text string codes, but not to
 or  codes, as other text entities do. 

 

This only affects point continuations that have been redefined like this;

 

code metapost

  def p_continuation(expr pos,theta,sc,al) =

% draw default continuation symbol

p_continuation_UIS(pos,theta,sc,al);

% if text attribute is set

if known(ATTR__text) and picture(ATTR__text):

% set labeling color to light orange

push_label_fill_color(1.0, 0.9, 0.8);

% draw filled label with text next to ?

p_label.urt(ATTR__text,(.5u,-.25u) transformed T,0.0,8);

% restore original labeling color

pop_label_fill_color;

fi;

  enddef;

endcode

So perhaps there is something to change in this metapost?

 

I suspect around the line that starts with p_label.urt..

 

For example, here is a drawing with a point continuation I have tried to
align top-left.

 

point continuation -text "vegetable debrisgas bubbles up from sand"
-attr who "B Mutton" -attr what passage -attr priority caution -attr ref
plan -align tl

 



 

Does anyone have a solution to this?

 

Regards

Bruce

 

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

[Therion] colour graduation lookup feature - carto-date, copyright-date, scrap-author

[Bruce Mutton via Therion]

One of the uses I have found for the recent addition of 'colour map-fg' for
explo-date and topo-date, together with lookups, is that I can check up on
the cave drawing team members.  It is now easy to find surveys that are
missing metadata such as exploration date and survey date.

 

This could be expanded to include 'colour map-fg carto-date', colour map-fg
copyright-date.  A metadata quality control mechanism for larger projects.

 

And to keep up the competition pressure on the drawing team, how about
'colour map-fg scrap-author'?  This way one can see qualitatively who has
drawn the most passage length.  And if 'statistics carto-count' was created,
to be similar in behaviour to
 'statistics
explo-length' (on, off, hide) , but counting the number of scraps, then with
on or hide, one could see who has drawn the most scraps.  (More and more I
am finding that smaller scraps produce more versatile maps).

 

Just keeping the development pressure up :)

 

Regards

Bruce

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

[Therion] colour graduation lookup feature - choice of terminology

[Bruce Mutton via Therion]

I'm liking the lookup feature added in October, in case you hadn't noticed
by my earlier posts.

However I wonder if the term 'lookup' is a good choice?

 

When I think about what it does, or achieves, it is about creating
collection(s) of map foreground colour palettes, which each map parameter
values to specific colours.  If a colour legend is produced, it controls the
legend text, and the number of legend entries.

 

I think 'lookup' is too generic, and it would be better to use a term that
better conveys what it achieves for the user.  

What about replacing the term 'lookup' in Therion with 'palette' or
'palette-map-fg' (to allow for other possible palettes in future)?

 

Before we get to imprinted on the word lookup.

Thoughts?"

 

Regards

Bruce

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