[Therion] Colouring ceiling formations?

[Benedikt Hallinger]

Hello again,

i want to define an optional layout in which some formations are colored 
differently, however i have no idea what to do.
Following the examples in the wiki, i tried:

---
layout colorMap.layout
   symbol-colour group water  [30  30  95]#this works! :)

   symbol-colour line chimney [0.95 0.15 0.15]   # no change :(
   symbol-colour line ceiling-meander [0.95 0.15 0.15]
endlayout
---

The water color changes like expected, but the chimney and meander parts 
remain black :(
What am i doing wrong here?




Also the same occurs with sand and clay patterns, however here i did my 
custom version:


code metapost
 % --- LEHM ---
 beginpattern(pattern_clay_AUT_HVHO);
   % Zeichnet einfach eine Reihe punkte an fixen X/Y Koordinaten
   pickup PenC;
   draw (0.20u, 0.30u);
   draw (0.35u, 0.70u);
   draw (0.40u, 0.40u);
   draw (0.60u, 0.50u);
   draw (0.80u, 0.10u);
  endpattern;
  def a_clay_AUT (expr Path) =
   T:=identity;
   %  thclean Path;
   %thfill Path withpattern pattern_sand_AUT ;  % original
   thfill Path withpattern pattern_clay_AUT_HVHO ;
 enddef;

 % --- SAND ---
 beginpattern(pattern_sand_AUT_HVHO);
   % Zeichnet einfach eine Reihe punkte an fixen X/Y Koordinaten
   pickup PenB;
   draw (0.20u, 0.20u);
   draw (0.40u, 0.60u);
   draw (0.80u, 0.40u);
   patternbbox(0u,0u, 1.0u,1.0u); % definiert Rechteckgroesse des Symbols
 endpattern;
 def a_sand_AUT (expr Path) =
   T:=identity;
   %  thclean Path;
   %thfill Path withpattern pattern_sand_AUT ;  % original
   thfill Path withpattern pattern_sand_AUT_HVHO ;
 enddef;
   endcode
-

I think i need to tell Therion somehow to draw the line in the color 
specified using "symbol-colour".
I know i could duplicate metapost code and add my colors there, however i 
want to use the distributions symbol definitions here if possible 
(maintianing upwards compatibility).



Thank you very much!

[Therion] AUT Symbolset area flowstone

[Benedikt Hallinger]

Hello,
recently i took some time to make a new symbol for area-flowstone in the AUT 
symbol set.
It resembles the austrian SPELDOK B43 guidelines.


---snip---

   # AUT area:flowstone
   code metapost
 beginpattern(pattern_flowstone_AUT);
   pickup PenC;
   draw (0.0u, 0.01u)--(0.33u, 0.01u);
   draw (0.33u, 0.33u)--(0.66u, 0.33u);
   patternbbox(0u,0u, 0.66u, 0.66u);
 endpattern;

 def a_flowstone_AUT (expr Path) =
   T:=identity;
   thclean Path;
   thfill Path withpattern pattern_flowstone_AUT ;
 enddef;

 initsymbol("a_flowstone_AUT");  % make the symbol available in AUT 
symbol set
   endcode

---snap---

The code above could be made available in your layout definition. As soon as 
you use "symbol-set AUT" and make an ordinary area tagged "flowstone", the 
new pattern will be used.

(probably this pattern could also be made available in the default symbol 
set shipped with therion...)


With best regards,
Beni

[Therion] New complimentary software: PEAR PHP Class library File_Therion

[Benedikt Hallinger]

Hi there,
i just wanted to inform you that since some time i am working on a PHP class 
framework to parse/generate therion files with PHP.
I initially need this to export data in therion format from the austrian 
SPELIX system, where austrian cave data is centrally collected.
Since i thought that a PHP class framework for therion file structures would 
probably be of broader use, i made it public as a PEAR project.

Some days ago i released the second public release (0.2.0) with basic 
centreline and survey support and (i think) all important structures present 
(however not all of them do something right now, thus the alpha state).
The rabbit example is parsable and writable again with core features (like 
centreline).


I think it would be useful to list the packages home at the therion wiki 
page: http://therion.speleo.sk/wiki/doku.php/contrib:complimentarycaveapps

File_Therion package home: http://pear.php.net/package/File_Therion/
(contains link to sources and in the future documentation; APIdoc there is 
currently broken but will be fixed soon)


With best regards,
Beni Hallinger
Höhlenverein Hallstatt-Obertraun / Austria

[Therion] Making custom metapost symbols recognize "symbol-color" thconfig command

[Benedikt Hallinger]

Hi there,
i wonder how i can make my own custom map symbols recognize the 
"symbol-color" command.


Maybe i also get some spare time and can adjust some of the default symbols 
to honor it too?


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

Re: [Therion] Making custom metapost symbols recognize "symbol-color" thconfig command

[Benedikt Hallinger]

Thank yu for the fast answers,

is this "colour_block_bg" variable the bit im looking for?
 > if known colour_block_bg: thfill p withcolor colour_block_bg; else: 
thfill p withcolor (0.75,0.75,0.75); fi;





Am 2016-09-27 21:40, schrieb Bruce Mutton:

Beni
Long ago I thought about such things.  There were some challenges I did 
not crack.  I forget now.
Have a look at Colour Dependant Visualization of Symbols in 
https://therion.speleo.sk/wiki/doku.php/metapost


Bruce

-Original Message-
From: Therion [mailto:therion-boun...@speleo.sk] On Behalf Of Benedikt 
Hallinger

Sent: Wednesday, 28 September 2016 7:39 AM
To: therion@speleo.sk
Subject: [Therion] Making custom metapost symbols recognize "symbol-color" 
thconfig command


Hi there,
i wonder how i can make my own custom map symbols recognize the 
"symbol-color" command.


Maybe i also get some spare time and can adjust some of the default 
symbols to honor it too?


Greetings, Beni
___
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] UISv1 grades: made a file, please give feedback

[Benedikt Hallinger]

Hello,

for a recent project i made a grades file (based on the BCRE-example in 
therion distribution) for UISv1 specifications (see attachment).
It would be a pleasure for me if it is useful to somebody; it would also be 
very nice if i could get some feedback on it.



With the naming i had the intention that exporting from databases is easily 
doable. The prefix is "UISv1_" followed by the actual grades number.
I included all the grades to faciliate documentation inside the th-files, so 
one can stright export "-1" surveys too.



With best regards,
Benedikt Hallinger




For better archiving and searchability, here is the code reproduced:
 UISv1Grades.th -
encoding utf-8
# UIS Grades - International standard grades specification
#   from: http://www.uisic.uis-speleo.org/UISmappingGrades.pdf
# Version 2 from 14 Sep 2012 (cosmetic update; UISv1 values still apply)
#
# Note: UIS standards says nothing about accuracy of the stations
#   positions, so it is probably good practice to include a
#   "sd position  " definition in your centrelines.
#

# Grade -1: no map available
# Only for database purposes: It means that the cave map has not been drawn 
yet.

grade "UISv1_-1" -title "UISv1 ungraded survey without map"
  # Not applicaple for therion data.
  # It is mainly here to support automated data exports from
  # databases wich may export such a number.
endgrade


# Grade 0: ungraded
# Only for database purposes. If a cave survey is ungraded, its quality 
cannot be

# assessed. This is most usually true for historic or otherwise old maps.
grade "UISv1_0" -title "UISv1 ungraded survey"
  # Nothing defined here.
  # Specifying such an grade may be useful to document that the survey was
  # not graded. As it is documented in the *.th-datafiles it may easily be
  # searched for. Use it as a kind of "todo" flag...
endgrade


# Grade 1: sketch from memory, not to scale
grade "UISv1_1" -title "UISv1 survey grade 1"
  # nothing defined here.
  # Specifying such an grade may be useful to document that the survey was
  # just the result of a sketch and shpuld be redone.
endgrade


# Grade 2: No instruments, from annotations/sketches/estimates
# Map compiled from annotations, sketches and estimates made
# in the cave. No instruments used.
grade "UISv1_2" -title "UISv1 survey grade 2"
  # nothing defined here.
  # Specifying such an grade may be useful to document that the survey
  # was the result of sketches/annotations in the cave.
endgrade


# Grade 3: Rough magnetic/analogue survey
# Directions measured by compass, distances measured by chord,
# pace, or body dimensions. Significant slopes estimated.
#
# A Silva clinometer or comparable, relatively simple means without precise
# readings qualify for grade 3. Mapping from head to head of the surveyors
# qualifies only for grade 3. Topofil measurements qualify generally for
# grade 3 or 4.
grade "UISv1_3" -title "UISv1 survey grade 3"

  # 95.44% of readings are within 0.5m (2 S.D.)
  length 0.25 metres

  # 95.44% of readings are within 5.0 degrees (2 S.D.)
  bearing 2.50 degrees

  # 95.44% of readings are within 30.0 degrees (2 S.D.)
  # (estimating is allowed, no measurement needed - value guessed by me)
  gradient 15.0 degrees

  # UIS specifications say nothing about station position accuracy.
  # Add "sd position  " to your centreline.

endgrade


# Grade 4: Magnetic survey
# Compass and tape survey, using deliberately chosen and fixed
# stations. Slopes measured by clinometer or horizontal and vertical
# components of line.
#
# Topofil measurements may qualify for grade 4 if the survey shots are not 
too
# long and care is given to correctly read all data. Laser rangefinder can 
be

# used throughout grades 4 to 5. In order to attain grade 4, fixed and
# re-findable survey stations must be made. They have not to be necessarily 
on

# the walls; tripod-mounted points with a defined length above the floor are
# also accepted
grade "UISv1_4" -title "UISv1 survey grade 4"

  # 95.44% of readings are within 0.1m (2 S.D.)
  length 0.05 metres

  # 95.44% of readings are within 2.0 degrees (2 S.D.)
  bearing 1.00 degrees

  # 95.44% of readings are within 2.0 degrees (2 S.D.)
  gradient 1.00 degrees

  # UIS specifications say nothing about station position accuracy.
  # Add "sd position  " to your centreline.

endgrade


# Grade 5:
# Compass and tape survey. Directions and slope by calibrated
# instruments, distances by fibreglass or metallic tape, or tachometry.
#
# Calibrated DistoX, DUSI or comparable instruments attain grade 5. With a
# calibration of the length measurement, they attain grade 6. If they are
# uncalibrated, they are to be graded with 1! Topofil used for vertical pits
# may reach grade 5. In order to reach grade 5, the survey 

Re: [Therion] UISv1 grades: made a file, please give feedback

[Benedikt Hallinger]

Oops, yes, thank you for spotting this!
It must read 0.125 of course!

Am 2016-11-09 15:21, schrieb Footleg:
This looks potentially very useful, but I have not yet explored defining 
sd settings in my survey data. So I may need to learn a bit more in order to 
use it.


I spotted one potential error? In the grade 6 section, the compass bearing 
is to 0.125 degrees. But the clino is stated as 1.125 degrees. I think both 
should be 0.125 right?


Footleg

On Mon, Nov 7, 2016 at 10:17 PM Benedikt Hallinger [4]> wrote:



Hello,

for a recent project i made a grades file (based on the BCRE-example in
therion distribution) for UISv1 specifications (see attachment).
It would be a pleasure for me if it is useful to somebody; it would also 
be

very nice if i could get some feedback on it.

With the naming i had the intention that exporting from databases is 
easily

doable. The prefix is "UISv1_" followed by the actual grades number.
I included all the grades to faciliate documentation inside the th-files, 
so

one can stright export "-1" surveys too.

With best regards,
Benedikt Hallinger

For better archiving and searchability, here is the code reproduced:
 UISv1Grades.th -
encoding utf-8
# UIS Grades - International standard grades specification
#   from: http://www.uisic.uis-speleo.org/UISmappingGrades.pdf [1]
# Version 2 from 14 Sep 2012 (cosmetic update; UISv1 values still apply)
#
# Note: UIS standards says nothing about accuracy of the stations
#       positions, so it is probably good practice to include a
#       "sd position  " definition in your centrelines.
#

# Grade -1: no map available
# Only for database purposes: It means that the cave map has not been 
drawn

yet.
grade "UISv1_-1" -title "UISv1 ungraded survey without map"
   # Not applicaple for therion data.
   # It is mainly here to support automated data exports from
   # databases wich may export such a number.
endgrade

# Grade 0: ungraded
# Only for database purposes. If a cave survey is ungraded, its quality
cannot be
# assessed. This is most usually true for historic or otherwise old maps.
grade "UISv1_0" -title "UISv1 ungraded survey"
   # Nothing defined here.
   # Specifying such an grade may be useful to document that the survey 
was
   # not graded. As it is documented in the *.th-datafiles it may easily 
be

   # searched for. Use it as a kind of "todo" flag...
endgrade

# Grade 1: sketch from memory, not to scale
grade "UISv1_1" -title "UISv1 survey grade 1"
   # nothing defined here.
   # Specifying such an grade may be useful to document that the survey 
was

   # just the result of a sketch and shpuld be redone.
endgrade

# Grade 2: No instruments, from annotations/sketches/estimates
# Map compiled from annotations, sketches and estimates made
# in the cave. No instruments used.
grade "UISv1_2" -title "UISv1 survey grade 2"
   # nothing defined here.
   # Specifying such an grade may be useful to document that the survey
   # was the result of sketches/annotations in the cave.
endgrade

# Grade 3: Rough magnetic/analogue survey
# Directions measured by compass, distances measured by chord,
# pace, or body dimensions. Significant slopes estimated.
#
# A Silva clinometer or comparable, relatively simple means without 
precise
# readings qualify for grade 3. Mapping from head to head of the 
surveyors

# qualifies only for grade 3. Topofil measurements qualify generally for
# grade 3 or 4.
grade "UISv1_3" -title "UISv1 survey grade 3"

   # 95.44% of readings are within 0.5m (2 S.D.)
   length 0.25 metres

   # 95.44% of readings are within 5.0 degrees (2 S.D.)
   bearing 2.50 degrees

   # 95.44% of readings are within 30.0 degrees (2 S.D.)
   # (estimating is allowed, no measurement needed - value guessed by me)
   gradient 15.0 degrees

   # UIS specifications say nothing about station position accuracy.
   # Add "sd position  " to your centreline.

endgrade

# Grade 4: Magnetic survey
# Compass and tape survey, using deliberately chosen and fixed
# stations. Slopes measured by clinometer or horizontal and vertical
# components of line.
#
# Topofil measurements may qualify for grade 4 if the survey shots are 
not

too
# long and care is given to correctly read all data. Laser rangefinder 
can

be
# used throughout grades 4 to 5. In order to attain grade 4, fixed and
# re-findable survey stations must be made. They have not to be 
necessarily

on
# the walls; tripod-mounted points with a defined length above the floor 
are

# also accepted
grade "UISv1_4" -title "UISv1 survey grade 4"

   # 95.44% of readings are within 0.1m (2 S.D.)
   length 0.05 metres

   # 95.44% of readings are within 2.0 degrees (2 S.D.)
   bearing 1.00 degrees

   # 95.44% of readings are within 2.0 degrees (2 S.D.)
   gradient 1.00 degrees

   # UIS s

[Therion] Additional morphing points (type "extra") explained

[Benedikt Hallinger]

Hello,
i struggle to understand how the extra morphing points are meant to be used.

How do they work technically? How do i correctly set them?
Are they linked to the nearest station and could i use more than two extra 
points?

Are they linked to LRUD data?

I already investigated the "morohing" example from the documentation (both 
in code and in thbook), so i think it would be good to stick to this example.


Thank you very much!
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Additional morphing points (type "extra") explained

[Benedikt Hallinger]

Thank you for the fadt reply.
If i understand and interpret correctly, the behavior unfolds in the 
following way:

- when i detect inproper morphing of walls compared to lrud data
- i place "extra" points on my traced wall signature.
- the extra point position is approximately where the lrud point is assumed 
to be on the wall.
- when rendering, therion morphes the wall to match the extra point position 
to the corresponding lrud position for that point (which is the nearest 
station).


That would imply:
a) there is no use for extra points without lrud data.
b) extra points reference l+r positions of lrud data of the nearest station, 
therefore it is not possible to set more than two extra points per station.


Is the above true?



Am 2016-11-18 11:20, schrieb Martin Sluka:

18. 11. 2016 v 8:07, Benedikt Hallinger :

Hello,
i struggle to understand how the extra morphing points are meant to be 
used.


How do they work technically? How do i correctly set them?
Are they linked to the nearest station and could i use more than two 
extra points?

Are they linked to LRUD data?

I already investigated the "morohing" example from the documentation 
(both in code and in thbook), so i think it would be good to stick to this 
example.


Thank you very much!
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Hi Benedikt,

the purpose of these extra points is to correct differences between LRUD 
data (if available) and distances to walls in sketches.


Check page 89 of TherionBook.

m.

___
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] Additional morphing points (type "extra") explained

[Benedikt Hallinger]

Thank you very much!

The extra point then just basicly just indicates "this *known* point is xx 
meters away from point y"; as is the (implicit) same for the LRUD data.

In other words, the LRUD data generates implicitely such points if present.

Just to clarify (and for the archive):
To correct an arbitary wall between two long survey legs, i would place two 
extra points at the middle of the leg at the position where i have drawn my 
wall signature. Then i would enter the "-from" info and the respective -dist 
to that point.


I just tested this and it works like desired, however it involves a little 
fiddling.



Thanks again for clarifying this!




Am 2016-11-18 14:13, schrieb Xavier Pennec:
According to the therion book (p. 25), extra points can also be used 
without LRUD by specifying the distance to either the closest station of a 
specific station, e.g.: point 0.0 0.0 extra -dist 3 -from 2@mysurvey

I have not tried yet, though.

Xavier

Le 18/11/2016 11:52, Benedikt Hallinger a écrit :

Thank you for the fadt reply.
If i understand and interpret correctly, the behavior unfolds in the 
following way:

- when i detect inproper morphing of walls compared to lrud data
- i place "extra" points on my traced wall signature.
- the extra point position is approximately where the lrud point is 
assumed to be on the wall.
- when rendering, therion morphes the wall to match the extra point 
position to the corresponding lrud position for that point (which is the 
nearest station).


That would imply:
a) there is no use for extra points without lrud data.
b) extra points reference l+r positions of lrud data of the nearest 
station, therefore it is not possible to set more than two extra points per 
station.


Is the above true?



Am 2016-11-18 11:20, schrieb Martin Sluka:

18. 11. 2016 v 8:07, Benedikt Hallinger :

Hello,
i struggle to understand how the extra morphing points are meant to be 
used.


How do they work technically? How do i correctly set them?
Are they linked to the nearest station and could i use more than two 
extra points?

Are they linked to LRUD data?

I already investigated the "morohing" example from the documentation 
(both in code and in thbook), so i think it would be good to stick to 
this example.


Thank you very much!
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Hi Benedikt,

the purpose of these extra points is to correct differences between LRUD 
data (if available) and distances to walls in sketches.


Check page 89 of TherionBook.

m.

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


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


--

-
Xavier Pennec
Senior Research Scientist / Directeur de recherche
Asclepios project-team, INRIA Sophia-Antipolis
2004 Route des Lucioles, BP93
F-06902 Sophia-Antipolis Cedex, France
+33 4 92 38 76 64
+33 6 78 35 16 90
http://www-sop.inria.fr/asclepios/
---


___
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] request for help

[Benedikt Hallinger]

I successfully use debian for years with therion.

> Am 14.05.2019 um 12:03 schrieb Martin Sluka via Therion :
> 
> Dear friends, I forward you mail of Therion user from Cuba. I have no any 
> experiences with Linux. May you send him your advice, please?
> 
> Thnx
> 
> Martin
> 
> Odesláno z iPhonu
> 
> Začátek přeposílané zprávy:
> 
>> Od: vlado6208 
>> Datum: 13. května 2019 17:18:56 SELČ
>> Komu: Martin Sluka 
>> Předmět: Consejo
>> 
>> I thinking change the operating system from the PC of project.
>> I think in Linux but I do not what version.
>> I do not know if Ubuntu, Debian or other.
>> What do you think?
>> 
>> 
>> 
>> Sent from my MetroPCS 4G LTE Android Device
> ___
> 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] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Hello there,
i have a very large dataset here. It is organised by regions like this 
(but much more leaf objects and regions):


=snip=
- survey TheCave
  - survey RegionWest
- survey 1
- survey 3
- survey 5
  - survey RegionEast
- survey 2
- survey 4
- survey 6
=snap=

I currently work from bottom to up, that is i draw the individual 
surveys as scraps, based on original material (sometimes they are really 
large and cosnsist of several many scraps).


In each of they leaf surveys (the numbered ones) i make by convention a 
map called "-Hauptplan". The main idea is that every leaf survey can 
be treaten modular and that i can compile varoius maps at upper levels 
(i.e regions).


Currently, the regions have no "-Hautplan". When i use "select 
RegionWest.TheCave", therion is instructed to select all scraps below 
it. For the most part, this works like intendet and the overlappings are 
calculated correctly. There are some places however, where the upper 
part of the passage is rendered below the lower part, which is wrong. 
This is with about 10-15% of the passages (so most is already ok).


I know from the manuals that therion does this "randomly" so there is no 
real way to adjust this from my perspective (placing the "input 2.th" 
command in the region.th file, wich then inputs the scraps etc, lower in 
the list does not help - it seems random where it is).
I think, however, that it would be a very great addition, if there would 
be some code in the renderer, that sorts the vertical presentation of 
the scraps/maps by average altitude of said scrap/map, and that this 
behavior is controllable by some configuration (cmdline option, or even 
better, thconfig parameter).
=> Is there maybe already something hidden like this i don't know so 
far?
That would be very great, because when i look at the dataset, i face 
about 30-50 hours producing correctly manually sorted handcrafted maps 
at the region level...



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

Re: [Therion] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Hi Stacho, hello Bruce,
you understood correctly.

The problem here is, we are talking about uncorrelated maps and scraps. 
They are from several subsurveys.


is there any kind of debug output i can activate to get the average 
scrap height?


And is the sorting done scrap-wise, or are the maps averaged?


Am 2019-05-30 22:27, schrieb Stacho Mudrak:

Hello,

if you select just survey, then all maps consisting of scraps in this
and sub-surveys should be ordered by average altitude. But this may
easily cause that some overlapping is not done correctly. But it is
also possible, there is some bug and it is not done correctly. Are you
able to post some minimalistic sample, where depth sort fails?

The only way how to manually order maps in the output is to create
upper-level maps (in your case probably what you mean by
-Hautplan) consisting of lower level maps in the correct
order.

HTH, S.

On Thu, 30 May 2019 at 15:55, Benedikt Hallinger 
wrote:


Hello there,
i have a very large dataset here. It is organised by regions like
this
(but much more leaf objects and regions):

=snip=
- survey TheCave
- survey RegionWest
- survey 1
- survey 3
- survey 5
- survey RegionEast
- survey 2
- survey 4
- survey 6
=snap=

I currently work from bottom to up, that is i draw the individual
surveys as scraps, based on original material (sometimes they are
really
large and cosnsist of several many scraps).

In each of they leaf surveys (the numbered ones) i make by
convention a
map called "-Hauptplan". The main idea is that every leaf survey
can
be treaten modular and that i can compile varoius maps at upper
levels
(i.e regions).

Currently, the regions have no "-Hautplan". When i use
"select
RegionWest.TheCave", therion is instructed to select all scraps
below
it. For the most part, this works like intendet and the overlappings
are
calculated correctly. There are some places however, where the upper

part of the passage is rendered below the lower part, which is
wrong.
This is with about 10-15% of the passages (so most is already ok).

I know from the manuals that therion does this "randomly" so there
is no
real way to adjust this from my perspective (placing the "input 2.th
[1]"
command in the region.th [2] file, wich then inputs the scraps etc,
lower in
the list does not help - it seems random where it is).
I think, however, that it would be a very great addition, if there
would
be some code in the renderer, that sorts the vertical presentation
of
the scraps/maps by average altitude of said scrap/map, and that this

behavior is controllable by some configuration (cmdline option, or
even
better, thconfig parameter).
=> Is there maybe already something hidden like this i don't know so

far?
That would be very great, because when i look at the dataset, i face

about 30-50 hours producing correctly manually sorted handcrafted
maps
at the region level...

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



Links:
--
[1] http://2.th
[2] http://region.th
___
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] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Hi Stacho,
your infos did the trick.
indeed the data showed at closer examination, that the parts where 
averaged lower than the part in question. The wrongly-lower part 
contains a steep slope but the average height was still some few meters 
below the average of the offending part.


What puzzled me was that even splitting the scraps was not enough!
I now have a scrap containing only the sloped part of the tunnel, and 
that is surely averaged above the lower part.


What solved it was to also rearrange the map definitions that contain 
the sloped part: i put the low part prior the slope in question in 
another map like this:

---snip--
# This works instead:
map working-priortunnel
  scrap-low-tunnel-before-slope
endmap
map working-slope
  scrap-slope-itself-with-followig-high-part
endmap


# this does NOT work lie intendet:
#map notWorking-combined
#  scrap-low-tunnel-before-slope
#  scrap-slope-itself-with-followig-high-part
#endmap
---snap--

It looks like therion currently uses the average height of the MAP, not 
the contained scraps, to calculate which part is above or below. In this 
example, it looks like it is getting the average height of the 
"notWorking-combined" combined map and comparing this to the 
uncorrelated below-tunnel.
If i put the "scrap-low-tunnel-before-slope" in its own MAP definition, 
the average calculation can only take the 
"scrap-slope-itself-with-followig-high-part" and thus resulting in a 
much higher average height.


Can you confirm this from therions sourcecode, and is this really the 
intendet behaviour, since i think each scrap shopuld be averaged for 
itself, regardless of its map allocation...?



Wih best regards,
Beni


Am 2019-05-30 22:27, schrieb Stacho Mudrak:

Hello,

if you select just survey, then all maps consisting of scraps in this
and sub-surveys should be ordered by average altitude. But this may
easily cause that some overlapping is not done correctly. But it is
also possible, there is some bug and it is not done correctly. Are you
able to post some minimalistic sample, where depth sort fails?

The only way how to manually order maps in the output is to create
upper-level maps (in your case probably what you mean by
-Hautplan) consisting of lower level maps in the correct
order.

HTH, S.

On Thu, 30 May 2019 at 15:55, Benedikt Hallinger 
wrote:


Hello there,
i have a very large dataset here. It is organised by regions like
this
(but much more leaf objects and regions):

=snip=
- survey TheCave
- survey RegionWest
- survey 1
- survey 3
- survey 5
- survey RegionEast
- survey 2
- survey 4
- survey 6
=snap=

I currently work from bottom to up, that is i draw the individual
surveys as scraps, based on original material (sometimes they are
really
large and cosnsist of several many scraps).

In each of they leaf surveys (the numbered ones) i make by
convention a
map called "-Hauptplan". The main idea is that every leaf survey
can
be treaten modular and that i can compile varoius maps at upper
levels
(i.e regions).

Currently, the regions have no "-Hautplan". When i use
"select
RegionWest.TheCave", therion is instructed to select all scraps
below
it. For the most part, this works like intendet and the overlappings
are
calculated correctly. There are some places however, where the upper

part of the passage is rendered below the lower part, which is
wrong.
This is with about 10-15% of the passages (so most is already ok).

I know from the manuals that therion does this "randomly" so there
is no
real way to adjust this from my perspective (placing the "input 2.th
[1]"
command in the region.th [2] file, wich then inputs the scraps etc,
lower in
the list does not help - it seems random where it is).
I think, however, that it would be a very great addition, if there
would
be some code in the renderer, that sorts the vertical presentation
of
the scraps/maps by average altitude of said scrap/map, and that this

behavior is controllable by some configuration (cmdline option, or
even
better, thconfig parameter).
=> Is there maybe already something hidden like this i don't know so

far?
That would be very great, because when i look at the dataset, i face

about 30-50 hours producing correctly manually sorted handcrafted
maps
at the region level...

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



Links:
--
[1] http://2.th
[2] http://region.th
___
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] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Thank you for your message, this helps alot.
There is a way out tough, a middle ground: one can define custom maps in 
the thconfig file using source.


I need to think about how this affects the projects structure.

Besides that, is there a option to disable map-averaging and tell 
therion to use the scrap average for each scrap?

That would solve this imho.

Thanks, i understand i better now, how this works currently.


Am 2019-05-31 21:22, schrieb Stacho Mudrak:

Hello Beni,

I am not 100% sure if I understand your problem correctly, but this is
how therion does average altitude calculations:

the altitude of a scrap = arithmetic average of altitudes of its
stations
the altitude of a map = arithmetic average of altitudes of scraps

And your observation is correct. If you have some maps defined in your
dataset, then maps of selected surveys are exported and sorted
according to their altitudes. If you have no maps defined, then scraps
in selected surveys are taken and altitude sorted.

So if you are working on a large dataset and you do not want to define
upper-level maps, it is probably better not to define any maps at all
- then only scraps will be taken into consideration.

Best regards, S.

On Fri, 31 May 2019 at 15:38, Benedikt Hallinger 
wrote:


Hi Stacho,
your infos did the trick.
indeed the data showed at closer examination, that the parts where
averaged lower than the part in question. The wrongly-lower part
contains a steep slope but the average height was still some few
meters
below the average of the offending part.

What puzzled me was that even splitting the scraps was not enough!
I now have a scrap containing only the sloped part of the tunnel,
and
that is surely averaged above the lower part.

What solved it was to also rearrange the map definitions that
contain
the sloped part: i put the low part prior the slope in question in
another map like this:
---snip--
# This works instead:
map working-priortunnel
scrap-low-tunnel-before-slope
endmap
map working-slope
scrap-slope-itself-with-followig-high-part
endmap

# this does NOT work lie intendet:
#map notWorking-combined
#  scrap-low-tunnel-before-slope
#  scrap-slope-itself-with-followig-high-part
#endmap
---snap--

It looks like therion currently uses the average height of the MAP,
not
the contained scraps, to calculate which part is above or below. In
this
example, it looks like it is getting the average height of the
"notWorking-combined" combined map and comparing this to the
uncorrelated below-tunnel.
If i put the "scrap-low-tunnel-before-slope" in its own MAP
definition,
the average calculation can only take the
"scrap-slope-itself-with-followig-high-part" and thus resulting in a

much higher average height.

Can you confirm this from therions sourcecode, and is this really
the
intendet behaviour, since i think each scrap shopuld be averaged for

itself, regardless of its map allocation...?

Wih best regards,
Beni

Am 2019-05-30 22:27, schrieb Stacho Mudrak:

Hello,

if you select just survey, then all maps consisting of scraps in

this

and sub-surveys should be ordered by average altitude. But this

may

easily cause that some overlapping is not done correctly. But it

is

also possible, there is some bug and it is not done correctly. Are

you

able to post some minimalistic sample, where depth sort fails?

The only way how to manually order maps in the output is to create
upper-level maps (in your case probably what you mean by
-Hautplan) consisting of lower level maps in the correct
order.

HTH, S.

On Thu, 30 May 2019 at 15:55, Benedikt Hallinger



wrote:


Hello there,
i have a very large dataset here. It is organised by regions like
this
(but much more leaf objects and regions):

=snip=
- survey TheCave
- survey RegionWest
- survey 1
- survey 3
- survey 5
- survey RegionEast
- survey 2
- survey 4
- survey 6
=snap=

I currently work from bottom to up, that is i draw the individual
surveys as scraps, based on original material (sometimes they are
really
large and cosnsist of several many scraps).

In each of they leaf surveys (the numbered ones) i make by
convention a
map called "-Hauptplan". The main idea is that every leaf

survey

can
be treaten modular and that i can compile varoius maps at upper
levels
(i.e regions).

Currently, the regions have no "-Hautplan". When i use
"select
RegionWest.TheCave", therion is instructed to select all scraps
below
it. For the most part, this works like intendet and the

overlappings

are
calculated correctly. There are some places however, where the

upper


part of the passage is rendered below the lower part, which is
wrong.
This is with about 10-15% of the passages (so most is already

ok).


I know from the manuals that therion does this "randomly" so

there

is no
real way to adjust this from my perspective (placing the "input

2.th [1]

[1]"
command in the regio

Re: [Therion] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Good morning,
thank you for that info!
Would it be a huge effort to make such an option available? Just asking.

To define the top level hierarchies, it would be cool to somehow get the 
altitude-sorted map names from some debug log or so. That list could be used 
directly to construct the map-command block that reproduces the current result. 
This would drastically reduce the effort.
Would it be possible to add a debug log output command, that produces such a 
list? Or is it already possible to get that list somehow, for example from the 
sql database output?

> Am 01.06.2019 um 22:44 schrieb Stacho Mudrak :
> 
> Unfortunately, there is no such option. Once a map is defined in your 
> dataset, it will be used with its average altitude in the export when only 
> surveys are selected for output. The idea behind is, that once you start 
> defining maps out of the scraps, you will build the whole tree of them 
> including top-level ones. So the only way how to overcome this problem is to 
> comment all your maps in the code until you define the whole hierarchy of 
> them.
> 
> S.
> 
>> On Fri, 31 May 2019 at 22:15, Benedikt Hallinger  wrote:
>> Thank you for your message, this helps alot.
>> There is a way out tough, a middle ground: one can define custom maps in 
>> the thconfig file using source.
>> 
>> I need to think about how this affects the projects structure.
>> 
>> Besides that, is there a option to disable map-averaging and tell 
>> therion to use the scrap average for each scrap?
>> That would solve this imho.
>> 
>> Thanks, i understand i better now, how this works currently.
>> 
>> 
>> Am 2019-05-31 21:22, schrieb Stacho Mudrak:
>> > Hello Beni,
>> > 
>> > I am not 100% sure if I understand your problem correctly, but this is
>> > how therion does average altitude calculations:
>> > 
>> > the altitude of a scrap = arithmetic average of altitudes of its
>> > stations
>> > the altitude of a map = arithmetic average of altitudes of scraps
>> > 
>> > And your observation is correct. If you have some maps defined in your
>> > dataset, then maps of selected surveys are exported and sorted
>> > according to their altitudes. If you have no maps defined, then scraps
>> > in selected surveys are taken and altitude sorted.
>> > 
>> > So if you are working on a large dataset and you do not want to define
>> > upper-level maps, it is probably better not to define any maps at all
>> > - then only scraps will be taken into consideration.
>> > 
>> > Best regards, S.
>> > 
>> > On Fri, 31 May 2019 at 15:38, Benedikt Hallinger 
>> > wrote:
>> > 
>> >> Hi Stacho,
>> >> your infos did the trick.
>> >> indeed the data showed at closer examination, that the parts where
>> >> averaged lower than the part in question. The wrongly-lower part
>> >> contains a steep slope but the average height was still some few
>> >> meters
>> >> below the average of the offending part.
>> >> 
>> >> What puzzled me was that even splitting the scraps was not enough!
>> >> I now have a scrap containing only the sloped part of the tunnel,
>> >> and
>> >> that is surely averaged above the lower part.
>> >> 
>> >> What solved it was to also rearrange the map definitions that
>> >> contain
>> >> the sloped part: i put the low part prior the slope in question in
>> >> another map like this:
>> >> ---snip--
>> >> # This works instead:
>> >> map working-priortunnel
>> >> scrap-low-tunnel-before-slope
>> >> endmap
>> >> map working-slope
>> >> scrap-slope-itself-with-followig-high-part
>> >> endmap
>> >> 
>> >> # this does NOT work lie intendet:
>> >> #map notWorking-combined
>> >> #  scrap-low-tunnel-before-slope
>> >> #  scrap-slope-itself-with-followig-high-part
>> >> #endmap
>> >> ---snap--
>> >> 
>> >> It looks like therion currently uses the average height of the MAP,
>> >> not
>> >> the contained scraps, to calculate which part is above or below. In
>> >> this
>> >> example, it looks like it is getting the average height of the
>> >> "notWorking-combined" combined map and comparing this to the
>> >> uncorrelated below-tunnel.
>> >> If i put the "scrap-low-tunnel-before-slope" in its o

Re: [Therion] Sorting scraps/maps by height in default mode

[Benedikt Hallinger]

Very nice,
cant wait to try it out once it reaches release!

> Am 27.06.2019 um 21:49 schrieb Bruce Mutton :
> 
> Thanks for following up on this Stacho, it is an important topic!
> I have just done a trial run, and it works, but there could be issues with 
> exported pdf file sizes (7MB becomes 113MB) and with some of my scraps and 
> maps that have strange elevations. Ie these are very common
> “
> M 
> -8000.00
>  SL-SilentSumpPlan@MiddleEarth (SL-SilentSump Plan )
> S   379.51  SL-SilentSumpPlan-s2@MiddleEarth ()
> S   387.63  SL-SilentSumpPlan-s1@MiddleEarth ()
> “
> I need to research this before commenting further.  The average scrap 
> elevations in the log looks like it will be helpful in planning map outputs.
>  
> But the very best thing for me is that ‘maps off’ has the effect of disabling 
> all passage offsets with a single switch.
> Something I have long been hoping for.
>  
> Thanks, a great addition to Therion.
> Bruce
>  
> From: Therion  On Behalf Of Stacho Mudrak
> Sent: Friday, 28 June 2019 05:20
> To: List for Therion users 
> Subject: Re: [Therion] Sorting scraps/maps by height in default mode
>  
> Hello,
>  
> sorry for reopening this thread, but finally this feature (to ignore existing 
> map structures) was added to therion. Just use
>  
> maps off
>  
> in your thconfig file, and it should work (in the latest development 
> version). Also, selection (with scrap/map altitudes) was added to therion.log 
> for debugging purposes.
>  
> S.
>  
> On Mon, 3 Jun 2019 at 08:21, Benedikt Hallinger  wrote:
> Good morning,
> thank you for that info!
> Would it be a huge effort to make such an option available? Just asking.
>  
> To define the top level hierarchies, it would be cool to somehow get the 
> altitude-sorted map names from some debug log or so. That list could be used 
> directly to construct the map-command block that reproduces the current 
> result. This would drastically reduce the effort.
> Would it be possible to add a debug log output command, that produces such a 
> list? Or is it already possible to get that list somehow, for example from 
> the sql database output?
> 
> Am 01.06.2019 um 22:44 schrieb Stacho Mudrak :
> 
> Unfortunately, there is no such option. Once a map is defined in your 
> dataset, it will be used with its average altitude in the export when only 
> surveys are selected for output. The idea behind is, that once you start 
> defining maps out of the scraps, you will build the whole tree of them 
> including top-level ones. So the only way how to overcome this problem is to 
> comment all your maps in the code until you define the whole hierarchy of 
> them.
>  
> S.
>  
> On Fri, 31 May 2019 at 22:15, Benedikt Hallinger  wrote:
> Thank you for your message, this helps alot.
> There is a way out tough, a middle ground: one can define custom maps in 
> the thconfig file using source.
> 
> I need to think about how this affects the projects structure.
> 
> Besides that, is there a option to disable map-averaging and tell 
> therion to use the scrap average for each scrap?
> That would solve this imho.
> 
> Thanks, i understand i better now, how this works currently.
> 
> 
> Am 2019-05-31 21:22, schrieb Stacho Mudrak:
> > Hello Beni,
> > 
> > I am not 100% sure if I understand your problem correctly, but this is
> > how therion does average altitude calculations:
> > 
> > the altitude of a scrap = arithmetic average of altitudes of its
> > stations
> > the altitude of a map = arithmetic average of altitudes of scraps
> > 
> > And your observation is correct. If you have some maps defined in your
> > dataset, then maps of selected surveys are exported and sorted
> > according to their altitudes. If you have no maps defined, then scraps
> > in selected surveys are taken and altitude sorted.
> > 
> > So if you are working on a large dataset and you do not want to define
> > upper-level maps, it is probably better not to define any maps at all
> > - then only scraps will be taken into consideration.
> > 
> > Best regards, S.
> > 
> > On Fri, 31 May 2019 at 15:38, Benedikt Hallinger 
> > wrote:
> > 
> >> Hi Stacho,
> >> your infos did the trick.
> >> indeed the data showed at closer examination, that the parts where
> >> averaged lower than the part in question. The wrongly-lower part
> >> contains a steep slope but the average height was still some few
> >> meters
> >> below the average of the offending part.
> >>

Re: [Therion] merge lines in xtherion

[Benedikt Hallinger]

What exactly is the problem with two separate lines in this case?
Just curious

> Am 26.07.2019 um 07:26 schrieb Martin Sluka via Therion :
> 
> No
> 
> Martin
> 
> Odesláno z iPhonu
> 
> 25. 7. 2019 v 22:51, עמרי גסטר :
> 
>> Hi everyone,
>> I want to merge two wall lines into one line 
>> is there a way to do that in xtherion?
>> 
>> I know I can do that in notepad but it would be much easier if there is a 
>> way to do it in xtherion
>> 
>> Omri
>> 
>> 
>> 
>> -- 
>> ___
>> 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] merge lines in xtherion

[Benedikt Hallinger]

I once got the hint to render topodroid to image and then redraw in therion by 
hand.

Obviously a function in xtherion to combine lines would be nice.

> Am 26.07.2019 um 13:03 schrieb עמרי גסטר :
> 
> we use Therion to make an intermediate map and then we finish it on 
> illustrator.
> To make the wall buffer for the wall we need the wall to be one line.
> 
> In order to do that we must use "continue" option when we draw in Topodroid 
> (which is not always the most convenient one), or after we finish the sketch 
> we need to go over it and use "attach to line" option in Topodroid to make it 
> a single line.
> The "attach to line" option is still in tester mode and it is not fully 
> reliable (sometimes it delete the line).
> 
> if there was an option to do it in Therion it would make things much easier.
> 
> Omri
>  
> 
>> On Fri, Jul 26, 2019 at 1:41 PM MD  wrote:
>> 
>> 
>> > On 26. Jul 2019, at 10:37, Benedikt Hallinger  wrote:
>> > 
>> > What exactly is the problem with two separate lines in this case?
>> > Just curious
>> 
>> For example my TopoDroid exports tend to have half a dozen separate lines, 
>> where One would be enough. Changing styles etc is a pain this way.
>> 
>> Also „convert to curve“ gets better results with a single line.
>> 
>> —max
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> 
> 
> -- 
> בברכה,
> עמרי גסטר
> 052-6124995
> ___
> 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] How to calculate the volume of a cave

[Benedikt Hallinger]

It would be awesome if the compiler could derive this fron the loch model and 
write it to the statistics block (the one where also loop closure info and 
total west/east and north/south dimwnsions are returned) when compiling this, 
as the neccessary data should be already present?

> Am 09.08.2019 um 14:58 schrieb Bill Gee :
> 
> Hello everyone - 
> 
> What tools can be used to calculate the volume of a cave based on center line 
> and LRUD data?
> 
> I found an email from Martin Sluka from about 4 years ago describing how to 
> use Loch to export a .lox file in other formats, then run that file through 
> CloudCompare or ParaView.  The process looks very complex to me, and besides 
> - Loch does not run on my computers, so there is no way for me to generate an 
> export.
> 
> As far as I can tell, Survex does not have a way to calculate volume.
> 
> Could it be done with a KML file and Google Earth?
> 
> -- 
> 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] Detecting errors

[Benedikt Hallinger]

To expand a little in this, you could also use the standard „grade“ to tell 
theriob which centerline data has which quality. We use this to mark the 
centerlines we have surveyed with distox and traditional way and therion uses 
this to put more of the errors towards the more bad survey.

See therion book page 34 for all details needed.

> Am 15.08.2019 um 11:41 schrieb Martin Sluka via Therion :
> 
> Somebody else could answer you more detailed.
> 
>> 15. 8. 2019 v 10:17, MD :
>> 
>> Our current project is nearing 2000 Stations in a labyrinth and things start 
>> to get cumbersome. We have more than 100 Loops detected by therion.
>> 
>> I wonder what people use to find errors. For example im I have too loops L1 
>> and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can 
>> assume that the error is in the stations/shots which are part of L2 but not 
>> L1. Is there an automated approach for that?
> 
> Not automated. You may use Survex method for loop closure and check detailed 
> report in therion.log. If you compile (export to PDF) data (or particular 
> data) with parameter -d (debug) you should receive graphical representation 
> of the biggest error - the yellow line.
> 
>> We have Disto X (no transcription errors possible) and  traditional 
>> (transcription errors likely) surveys. How to handle that?
> 
> You may set errors for data in any particular centerline section - ''sd'' 
> parameter
> 
> Martin
> 
> ___
> 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] Detecting errors

[Benedikt Hallinger]

... forgot to mention, survex can display the errors visually, when generated 
from therion this way. When you marked the surveys accordingly you can see 
which loops are bad and which ones are good in the polylines. This greatly aids 
in finding problematic or faulty measurements.

For traditional surveys i also usually get good results with the morphing 
information of therion (big morphing at stations suggests faulty data when the 
sketch is accurate).

> Am 15.08.2019 um 11:50 schrieb Benedikt Hallinger :
> 
> To expand a little in this, you could also use the standard „grade“ to tell 
> theriob which centerline data has which quality. We use this to mark the 
> centerlines we have surveyed with distox and traditional way and therion uses 
> this to put more of the errors towards the more bad survey.
> 
> See therion book page 34 for all details needed.
> 
>> Am 15.08.2019 um 11:41 schrieb Martin Sluka via Therion :
>> 
>> Somebody else could answer you more detailed.
>> 
>>> 15. 8. 2019 v 10:17, MD :
>>> 
>>> Our current project is nearing 2000 Stations in a labyrinth and things 
>>> start to get cumbersome. We have more than 100 Loops detected by therion.
>>> 
>>> I wonder what people use to find errors. For example im I have too loops L1 
>>> and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can 
>>> assume that the error is in the stations/shots which are part of L2 but not 
>>> L1. Is there an automated approach for that?
>> 
>> Not automated. You may use Survex method for loop closure and check detailed 
>> report in therion.log. If you compile (export to PDF) data (or particular 
>> data) with parameter -d (debug) you should receive graphical representation 
>> of the biggest error - the yellow line.
>> 
>>> We have Disto X (no transcription errors possible) and  traditional 
>>> (transcription errors likely) surveys. How to handle that?
>> 
>> You may set errors for data in any particular centerline section - ''sd'' 
>> parameter
>> 
>> Martin
>> 
>> ___
>> 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] Detecting errors

[Benedikt Hallinger]

You could also indicate the misalignment with instrument correction commands, 
but i dont know the exact command at the moment. I think that would not with  
different orientations of the same device...

> Am 05.09.2019 um 13:10 schrieb Max D :
> 
> 
> 
>> On 5. Sep 2019, at 08:28, Olly Betts  wrote:
>> 
>>> On Fri, Aug 16, 2019 at 05:11:22AM +0200, MD wrote:
>>> We also then to measure the same small loop at the beginning  of each trip: 
>>> A-B in four device orientations
>>> B-A in four device orientations
>>> A-C in four device orientations
>>> C-A in four device orientations
>>> C-B once
>>> 
>>> So I could calculate an SD based on that. 
>> 
>> You probably don't want to work out a set of SDs per-trip -
> 
> Currently we set the SD per calibration - which works out to about every 
> second trip. We Take the "Error stddev" from Topodroid Calibration Results - 
> e.g.0.1058 in the attached Screenshot.
> 
> Thinking of it, this might be the wrong approach because it only considers 
> the instrument.
> 
>> *sd tape 0.002 metres ; 2 millimetres
>> *sd compass clino 0.5 degrees
>> *sd position 0.05 metres ; 5 centimetres
> 
> Interesting. I will read up on the difference between tape and position
> 
>>> For sone Devices errors seem to be bound very much to orientation. In
>>> the data saved by TopoDroid you can see the device orientation and so
>>> we could set a sd based on the direction in which the shot was taken.
>>> I have nit investigated this further so far. Also because we have this
>>> data only for about 20% of the cave.
>> 
>> This is already taken into account - you tell Survex the SD for the
>> "tape" (read laser range-finder), "compass" and "clino" (read magnetic
>> field measuring devices) and position (how close to the station you
>> actually measure from) and it uses the direction of the leg to produce
>> a 3D set of expected errors, which are then summed along each traverse.
> 
> But I would need a extra set SD data per device orientation. 
> So I know that if the display is to the right the Disto tends to reassure an 
> Azimuth 2 degrees to high and if the display is to the left.
> And when the display is to the left it tends to give an Azimuth 1 degree to 
> low.
> 
> But perhaps I just should try to do more and better calibrations instead of 
> fixing stuff afterwards.
> 
> 
>>> TopoDroid also is able to flag an “magnetic anomaly” - i’m not totally
>>> sure how but this als could be used in setting a per shot SD. i have
>>> not looked much into this.
>> 
>> I think you want to treat that as an in-cave indication that you should
>> check for sources of magnetic interference and redo affected readings.
> 
> Good Advice!
> 
> Thanks!
> 
> --max
> 
> 
> ___
> 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 crashes on debian testing (bullseye)

[Benedikt Hallinger]

Hi there,
i upgraded my debian testing installation some time ago and since then, 
therion wont compile anymore.


When i run
i get the following output:


therion 5.4.4 (2019-05-01)
cavern - Survex 1.2.42
initialization file: /etc/therion.ini
reading ... done
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=pdfetex)

 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT 
INSTALLED
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=pdfetex)

 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ... NOT 
INSTALLED
configuration file: 
therion/model.hirlatz-dop-1m_geoland-dom-10mALS.thconfig

reading ... done
reading source files ... proj_create: Error -1: no arguments in 
initialization list


therion: error -- PROJ4 library: -1 (no arguments in initialization 
list)



I cant figure out whats wrong



Also loch crashes, is this related?
--
$ loch
Error: glXCreateContext failed
--


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

Re: [Therion] therion crashes on debian testing (bullseye)

[Benedikt Hallinger]

Hi, this is enough:

-test.th-
survey test
  centerline
units length meters
data normal from to length bearing clino
1   2   10  10  10
2   3   20  20  20

   cs EPSG:31258
   fix 1 47 20 123

  endcenterline
endsurvey
--

-test.thconf-
source test.th

export model -o test.3d
-



Gives:
beni@segin:/tmp/thdebug$ therion test.thconf
therion 5.4.4 (2019-05-01)
cavern - Survex 1.2.42
initialization file: /etc/therion.ini
reading ... done
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=pdfetex)

 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT 
INSTALLED
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=pdfetex)

 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ... NOT 
INSTALLED

configuration file: test.thconf
reading ... done
reading source files ... proj_create: Error -1: no arguments in 
initialization list


therion: error -- PROJ4 library: -1 (no arguments in initialization 
list)

beni@segin:/tmp/thdebug$




Am 2019-09-12 22:17, schrieb Olly Betts:

On Thu, Sep 12, 2019 at 09:09:29PM +0200, Benedikt Hallinger wrote:
i upgraded my debian testing installation some time ago and since 
then,

therion wont compile anymore.


Do you have any idea when "some time ago" was?  If we know when this
broke that would help narrow down the culprit.

configuration file: 
therion/model.hirlatz-dop-1m_geoland-dom-10mALS.thconfig

reading ... done
reading source files ... proj_create: Error -1: no arguments in
initialization list

therion: error -- PROJ4 library: -1 (no arguments in initialization 
list)



I cant figure out whats wrong


I'd guess a something changed with PROJ.  Therion uses the library from
proj 5.2.0-1 which was uploaded nearly a year ago, but there's a
proj-data package which got updated on 2019-09-04 to come from proj
6.2.0-1 instead of 5.2.0-1.  So if "some time ago" was after that
then this could be the cause.

Debian has continuous integration to attempt to catch this sort of
problem, but that's currently green:

https://ci.debian.net/packages/t/therion/testing/amd64/

The current CI test tries to process:

therion samples/morphing/sample1/thconfig.1

and checks that a non-empty cave1.pdf is produced.

But unfortunately that sample doesn't use coordinate systems so 
wouldn't

catch issues with PROJ (it seems none of the supplied samples do).

I tried adding "cs" and "fix" lines to that sample, but it processes OK
so it seems it's something specific to your example, or perhaps to your
installation.  Can you show a cut-down example which fails?  If you
replace the survey data with a single dummy leg and change the entrance
coordinates to be something random but valid there shouldn't be 
anything

potentially sensitive revealed.


Also loch crashes, is this related?
--
$ loch
Error: glXCreateContext failed
--


It seems unlikely to be related.

I see this too - it happens if "execution fails on the client side"
apparently:

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glXCreateContext.xml

That seems uselessly vague though.

Cheers,
Olly

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

Re: [Therion] therion crashes on debian testing (bullseye)

[Benedikt Hallinger]

...Also just tried to build the package myself on my system, sadly with 
the same results.


Am 2019-09-13 17:54, schrieb Benedikt Hallinger:

Hi, this is enough:

-test.th-
survey test
  centerline
units length meters
data normal from to length bearing clino
1   2   10  10  10
2   3   20  20  20

   cs EPSG:31258
   fix 1 47 20 123

  endcenterline
endsurvey
--

-test.thconf-
source test.th

export model -o test.3d
-



Gives:
beni@segin:/tmp/thdebug$ therion test.thconf
therion 5.4.4 (2019-05-01)
cavern - Survex 1.2.42
initialization file: /etc/therion.ini
reading ... done
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian)
(preloaded format=pdfetex)
 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT 
INSTALLED

This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian)
(preloaded format=pdfetex)
 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ...
NOT INSTALLED
configuration file: test.thconf
reading ... done
reading source files ... proj_create: Error -1: no arguments in
initialization list

therion: error -- PROJ4 library: -1 (no arguments in initialization 
list)

beni@segin:/tmp/thdebug$




Am 2019-09-12 22:17, schrieb Olly Betts:

On Thu, Sep 12, 2019 at 09:09:29PM +0200, Benedikt Hallinger wrote:
i upgraded my debian testing installation some time ago and since 
then,

therion wont compile anymore.


Do you have any idea when "some time ago" was?  If we know when this
broke that would help narrow down the culprit.

configuration file: 
therion/model.hirlatz-dop-1m_geoland-dom-10mALS.thconfig

reading ... done
reading source files ... proj_create: Error -1: no arguments in
initialization list

therion: error -- PROJ4 library: -1 (no arguments in initialization 
list)



I cant figure out whats wrong


I'd guess a something changed with PROJ.  Therion uses the library 
from

proj 5.2.0-1 which was uploaded nearly a year ago, but there's a
proj-data package which got updated on 2019-09-04 to come from proj
6.2.0-1 instead of 5.2.0-1.  So if "some time ago" was after that
then this could be the cause.

Debian has continuous integration to attempt to catch this sort of
problem, but that's currently green:

https://ci.debian.net/packages/t/therion/testing/amd64/

The current CI test tries to process:

therion samples/morphing/sample1/thconfig.1

and checks that a non-empty cave1.pdf is produced.

But unfortunately that sample doesn't use coordinate systems so 
wouldn't

catch issues with PROJ (it seems none of the supplied samples do).

I tried adding "cs" and "fix" lines to that sample, but it processes 
OK
so it seems it's something specific to your example, or perhaps to 
your

installation.  Can you show a cut-down example which fails?  If you
replace the survey data with a single dummy leg and change the 
entrance
coordinates to be something random but valid there shouldn't be 
anything

potentially sensitive revealed.


Also loch crashes, is this related?
--
$ loch
Error: glXCreateContext failed
--


It seems unlikely to be related.

I see this too - it happens if "execution fails on the client side"
apparently:

https://www.khronos.org/registry/OpenGL-Refpages/gl2.1/xhtml/glXCreateContext.xml

That seems uselessly vague though.

Cheers,
Olly

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

Re: [Therion] therion crashes on debian testing (bullseye)

[Benedikt Hallinger]

Hello, is there anything new on this?
Should i file a bug on the therion git project, or is this already fixed in 
upstream and i have to just wait for a new debian package build?

> Am 16.09.2019 um 07:49 schrieb Martin Budaj :
> 
> Build-time, just for therion. It's used to parse the definitions of CSs from 
> the Proj database.
> M.
> 
>> On Mon, Sep 16, 2019, 01:16 Olly Betts  wrote:
>> On Sun, Sep 15, 2019 at 09:45:23PM +0200, Martin Budaj wrote:
>> > @Olly, Wookey: While investigating this issue I noticed that a dependency
>> > on libsqlite3-tcl should be added in Debian if Proj library version 6 is
>> > used.
>> 
>> What sort of dependency?  Build-time, run-time, both?
>> 
>> And if run-time, what exactly needs it?  There's a separate binary
>> package for loch (therion-viewer).
>> 
>> Cheers,
>> Olly
> ___
> 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] therion crashes on debian testing (bullseye)

[Benedikt Hallinger]

Tested a little more yesterday evening, if i comment out any fix and cs 
commands, therion compiles the maps just nice. However without georeferencing 
obviously...

As was pointed out before, is the solution to adjust the command invocation in 
the therion source to comply to proj6?
Is there any workaround i can use to be able to compile my orojects meanwhile?

> Am 07.10.2019 um 17:47 schrieb Benedikt Hallinger :
> 
> Hello, is there anything new on this?
> Should i file a bug on the therion git project, or is this already fixed in 
> upstream and i have to just wait for a new debian package build?
> 
>> Am 16.09.2019 um 07:49 schrieb Martin Budaj :
>> 
>> Build-time, just for therion. It's used to parse the definitions of CSs from 
>> the Proj database.
>> M.
>> 
>>> On Mon, Sep 16, 2019, 01:16 Olly Betts  wrote:
>>> On Sun, Sep 15, 2019 at 09:45:23PM +0200, Martin Budaj wrote:
>>> > @Olly, Wookey: While investigating this issue I noticed that a dependency
>>> > on libsqlite3-tcl should be added in Debian if Proj library version 6 is
>>> > used.
>>> 
>>> What sort of dependency?  Build-time, run-time, both?
>>> 
>>> And if run-time, what exactly needs it?  There's a separate binary
>>> package for loch (therion-viewer).
>>> 
>>> Cheers,
>>> Olly
>> ___
>> 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] How to suppress station name prefix?

[Benedikt Hallinger]

Hello,
my stations all follow the syntax „n.m“, like 1.28, 1.29, 2.1, 2.2 and so on.
I have some larger maps where only the first prefix (1.m) ever occurs.

Is there a way to supress the prefix when needed without tinkering with the 
data?
I think in the direction of overloading the station name symbol but dont know 
how to code this in metapost...

With best regards, Beni
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] New symbols

[Benedikt Hallinger]

I would love to see them included. I could really use that cracked mud area :)

The symbols really look useful in general!

> Am 26.11.2019 um 21:08 schrieb Rodrigo Severo via Therion :
> 
> ‐‐‐ Original Message ‐‐‐
>> On Tuesday, November 26, 2019 4:36 PM, Bruce Mutton  wrote:
>> 
>> Rodrigo
>> 
>> I think your first suggestion is a good one.
>> 
>> You could propose to add them to the source code at 
>> https://github.com/therion/therion I guess.  I have not yet braved 
>> contributing via git, but maybe one day, as I also have some symbols to add.
> 
> Certainly. It's just that, right now I ahve them as user defined symbols. I 
> would have to change a few things so they wuld be Thjerion symbols. I jsut 
> don't want to have the work of doing these changes if there is no interest in 
> including them as Therion symbols.
> 
> 
>> Do you have a graphic example of your symbols?
> 
> Sure. Here it is: 
> https://drive.google.com/open?id=1vXQg23eaPnG1XiQvohGY3Yhk6S7KxZCz
> 
> 
> Regards,
> 
> Rodrigo Severo
> 
> ___
> 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] New symbols

[Benedikt Hallinger]

Amazing work, rodrigo!!!
You are a metapost wizard.

May i wish something too?
I would need a line symbol with 90 degree „ticks“ like the section line, but 
without the arrow points.
Above the  upper tick (maybe start of line) i want to print some text, in my 
case the UIS plan quality quantifier, but probably this would be very useful 
for other purposes, so a -text option is a good idea...

> Am 27.11.2019 um 23:16 schrieb Rodrigo Severo via Therion :
> 
> ‐‐‐ Original Message ‐‐‐
>> On Wednesday, November 27, 2019 4:39 PM, Bill Gee  
>> wrote:
>> 
>> One more thought occurred to me just now ... The cave where I want to use 
>> the wheelchair symbol has parts of the tour which are NOT accessible due to 
>> stairs. How much trouble would it be to create a version of the wheelchair 
>> symbol with a red slashed circle on it? Call it notwheelchair, perhaps.
>> 
>>  
>> 
>> https://www.compliancesigns.com/signs/No-Wheelchair-Access has a picture of 
>> what I have in mind. Text is not needed for the cave symbol.
> 
> I wonder if I'm spoiling you :)
> 
> Here it is.
> 
> 
> 
> Regards,
> 
> Rodrigo
> 
> 
> 
> ___
> 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/loch crashes in sid (issue #158)

[Benedikt Hallinger]

Hi Olly,
i hope you can help me out with issue #158 
(https://github.com/therion/therion/issues/158)

I am fiddling around in hope to get my loch viewer working again.
It worked in the past but then decided after a debian update to cease 
functioning because of failing glx context.

I now have the impression, maybe  wxWidgets is the cause. The glx context is 
fine, other X applications can successfully establish 3D perfomance and glx 
debug commands also tell me „ok“.

I habe seen that there is a wxWidgets 3.1.4 out there. Maybe this could solve 
my issue?

Can you please make me an updated debian package (or tell me how i can build it 
myself)?___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion/loch crashes in sid (issue #158)

[Benedikt Hallinger]

Glad i‘m not alone. Which is no good thing...
Maybe its something with the wxWidgets lib...?

> Am 05.12.2019 um 13:27 schrieb Bill Gee :
> 
> I also have this problem. I am running Fedora, and have seen this for about 
> the last 6 months on both Fedora 30 and 31. It happens on computers with 
> nVidia, Intel and VirtualBox display drivers.
>  
> Aven works fine.
> 
> --
> Bill Gee
>  
>  
> 
> On Thursday, December 5, 2019 5:19:12 AM CST Benedikt Hallinger wrote:
> > Hi Olly,
> > i hope you can help me out with issue #158 
> > (https://github.com/therion/therion/issues/158)
> >
> > I am fiddling around in hope to get my loch viewer working again.
> > It worked in the past but then decided after a debian update to cease 
> > functioning because of failing glx context.
> >
> > I now have the impression, maybe wxWidgets is the cause. The glx context is 
> > fine, other X applications can successfully establish 3D perfomance and glx 
> > debug commands also tell me „ok“.
> >
> > I habe seen that there is a wxWidgets 3.1.4 out there. Maybe this could 
> > solve my issue?
> >
> > Can you please make me an updated debian package (or tell me how i can 
> > build it myself)?
> >
>  
>  
> ___
> 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] Therion/loch crashes in sid (issue #158)

[Benedikt Hallinger]

Hi Stacho,
see https://github.com/therion/therion/issues/158

I confirm the commit 19eb62409e fixes this.
I closed issue #158 :)

Thank you very much!


Am 2019-12-09 18:32, schrieb Stacho Mudrak:

After investigation, I realized that even if OpenGL context is created
for pixmap rendering, printing from loch on my Linux machine actually
does not work.

So I have rearranged the code and disabled rendering to pixmap on
Linux completely. It seems to work using just screen OpenGL buffer for
tiled rendering (for big images).

If anybody is interested in testing, your feedback is welcome.

S.

On Sat, 7 Dec 2019 at 00:15, Olly Betts  wrote:


On Fri, Dec 06, 2019 at 05:03:15PM +0100, Stacho Mudrak wrote:

If it is lxR2P.c what fails (it is off-screen rendering to pixmap

- for

large renderings) then it should be quite easy to disable it.

Could you

please somebody try to comment out following line

(lxGLC.cxx:1938)?


this->m_OSC->m_r2p = R2PCreate(w, h);

then recompile loch and try whether it can start?


Yes.  I've applied slightly more nuanced version of that (which
tries
to create the context, but on failure doesn't exit) and uploaded a
new debian package to unstable.  This obviously isn't a perfect fix,
but it beats loch being unusable, and if it was working for anyone
before it should still with off-screen rendering.

I've attached the patch I applied.

Cheers,
Olly
___
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] How does Therion decide which passages to put above and below

[Benedikt Hallinger]

Is there any layout option we can activate, so therion ignores map ordering 
alltogether and always just uses average scrap height?

> Am 12.12.2019 um 23:46 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> Alastair,
> 
>> I need to know how therion decides which passages to put above and below
>> others.
> 
> I have not yet looked into your specific setup, but this is the general
> case:
> 
> If you are *not* using "map-endmap" to define a map, or if you are
> selecting multiple objects in a dataset with several "select" commands
> rather than using a map, then Therion uses the average height of the
> stations in the scraps to determine the heights of each scrap, and
> stacks them accordingly.
> 
> If a scrap contains stations with altitudes 1m, 5m, and 15m, the average
> height of the scrap will be 7m. The scrap will be placed above scraps
> with average heights lower than that, even if the other scrap has two
> stations at 6 metres, passing over the first scrap's 1m altitude
> station. (It checks the averages, not the specific locations where the
> scraps cross each other.)
> 
> If you are using maps, then by default, a map of scraps will be placed
> with the scraps at the same stacking height as each other (so the
> passage fills are rendered overlapping, and the features like walls are
> all rendered on top of all the scraps at once). You use "break" to
> separate the rendering layers.
> 
> map map1
> scrap1
> scrap2
> break
> scrap3
> scrap4
> endmap
> 
> scrap1 and scrap2 get rendered at the same time, at the same stacking
> level as each other. scrap3 and scrap4 get rendered at the same time, at
> the same stacking level as each other. scrap1 and scrap2 get stacked and
> layered *above* scrap3 and scrap4.
> 
> When you have a map of maps, a "break" is implied between the maps.
> 
> map outermap
> map1
> map2
> map3
> endmap
> 
> The scraps in map1 are stacked/layered above the scraps in map2, and
> those in map2 are stacked/layered above map3.
> 
> You seem to be using maps, so you will be seeing this automatic breaking
> between maps.
> 
> If the scraps within a map are layered in the wrong order, change your
> ordering of scraps within the map to put them in the right order, and
> put "break" where needed to separate them into layers.
> 
> If the scraps within a map-of-maps are layered in the wrong order,
> change your ordering of maps within the outer map to put the top layers
> first.
> 
> Complicated setups can arise in some cases; If you have scraps within a
> map (eg. "mapxyz") where some are supposed to pass above, and some
> below, a scrap within another map (eg. "mapothr"), then you need to
> split your "mapxyz" map into two maps, one with the "above" scraps, and
> one with the "below" scraps, and then you need to include those two maps
> separately in the parent map, with the interleaved "mapothr" map between
> them.
> 
> I guess some of this might be stuff you already know, but maybe it will
> explain what you are seeing at least.
> 
> Tarquin
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How does Therion decide which passages to put above and below

[Benedikt Hallinger]

Automation of simpler but big caves, because one just needs to define submaps 
and layering could be automatic.

> Am 13.12.2019 um 08:42 schrieb Martin Sluka via Therion :
> 
> What is the reason to kill one of basic principles of Therion which allows to 
> generate maps of really complicated systems?
> 
> Martin
> 
> Odesláno z iPhonu
> 
> 13. 12. 2019 v 8:34, Benedikt Hallinger :
> 
>> Is there any layout option we can activate, so therion ignores map ordering 
>> alltogether and always just uses average scrap height?
>> 
>>> Am 12.12.2019 um 23:46 schrieb Tarquin Wilton-Jones via Therion 
>>> :
>>> 
>>> Alastair,
>>> 
>>>> I need to know how therion decides which passages to put above and below
>>>> others.
>>> 
>>> I have not yet looked into your specific setup, but this is the general
>>> case:
>>> 
>>> If you are *not* using "map-endmap" to define a map, or if you are
>>> selecting multiple objects in a dataset with several "select" commands
>>> rather than using a map, then Therion uses the average height of the
>>> stations in the scraps to determine the heights of each scrap, and
>>> stacks them accordingly.
>>> 
>>> If a scrap contains stations with altitudes 1m, 5m, and 15m, the average
>>> height of the scrap will be 7m. The scrap will be placed above scraps
>>> with average heights lower than that, even if the other scrap has two
>>> stations at 6 metres, passing over the first scrap's 1m altitude
>>> station. (It checks the averages, not the specific locations where the
>>> scraps cross each other.)
>>> 
>>> If you are using maps, then by default, a map of scraps will be placed
>>> with the scraps at the same stacking height as each other (so the
>>> passage fills are rendered overlapping, and the features like walls are
>>> all rendered on top of all the scraps at once). You use "break" to
>>> separate the rendering layers.
>>> 
>>> map map1
>>> scrap1
>>> scrap2
>>> break
>>> scrap3
>>> scrap4
>>> endmap
>>> 
>>> scrap1 and scrap2 get rendered at the same time, at the same stacking
>>> level as each other. scrap3 and scrap4 get rendered at the same time, at
>>> the same stacking level as each other. scrap1 and scrap2 get stacked and
>>> layered *above* scrap3 and scrap4.
>>> 
>>> When you have a map of maps, a "break" is implied between the maps.
>>> 
>>> map outermap
>>> map1
>>> map2
>>> map3
>>> endmap
>>> 
>>> The scraps in map1 are stacked/layered above the scraps in map2, and
>>> those in map2 are stacked/layered above map3.
>>> 
>>> You seem to be using maps, so you will be seeing this automatic breaking
>>> between maps.
>>> 
>>> If the scraps within a map are layered in the wrong order, change your
>>> ordering of scraps within the map to put them in the right order, and
>>> put "break" where needed to separate them into layers.
>>> 
>>> If the scraps within a map-of-maps are layered in the wrong order,
>>> change your ordering of maps within the outer map to put the top layers
>>> first.
>>> 
>>> Complicated setups can arise in some cases; If you have scraps within a
>>> map (eg. "mapxyz") where some are supposed to pass above, and some
>>> below, a scrap within another map (eg. "mapothr"), then you need to
>>> split your "mapxyz" map into two maps, one with the "above" scraps, and
>>> one with the "below" scraps, and then you need to include those two maps
>>> separately in the parent map, with the interleaved "mapothr" map between
>>> them.
>>> 
>>> I guess some of this might be stuff you already know, but maybe it will
>>> explain what you are seeing at least.
>>> 
>>> 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 mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Problem with dots in symbols: map-connection is empty

[Benedikt Hallinger]

Hi there,
we noticed some problems with dots in symbols yesterday, the won't show 
anymore.


I can reproduce this with therion 5.4.4+19eb624 (2019-12-09).
The problem exists with the default symbol for "point map-connection",
as well as with my custom layout code for clay:


code metapost
% --- CLAY ---
beginpattern(pattern_clay_AUT_HVHO);
  % Just draw some fixed points on x/y coordinates
  pickup PenB;
  draw (0.20u, 0.30u);
  draw (0.35u, 0.70u);
  draw (0.40u, 0.40u);
  draw (0.60u, 0.50u);
  draw (0.80u, 0.10u);
endpattern;

% overwrite default symbol with custom one
def a_clay_AUT (expr Path) =
  T:=identity;
  %  thclean Path;
  %thfill Path withpattern pattern_sand_AUT ;  % original
  thfill Path withpattern pattern_clay_AUT_HVHO ;
enddef;



Has something changed recently in the point definition?
I assume, because the default map-connection item should still work but 
doesn't show points?



With best regards,
Beni
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with dots in symbols: map-connection is empty

[Benedikt Hallinger]

Hello again and thank you for the quick reaction.

When i compile it with the newest build, the clay renders OK again.
However, now the altitude marks at the wall are designated with a small 
dot instead of the usual small line.


In the previous version, also the Questionmark symbol was missing the 
dot; that seems to be fixed now.


The default map-connection is still bugged here, tough.




Am 2019-12-18 21:06, schrieb Stacho Mudrak:

I've tried to fix these problems in commit d9361de. Hopefully, it
fixes the issue

S.

On Wed, 18 Dec 2019 at 20:37, Martin Budaj  wrote:


Hi,

the problem is in a global "linecap := butt;" setting in the point
mudcrack symbol (added on December 6) which changes the appearance
of
the line endings (the dot is a zero-length line which used to be
drawn
with a round pen). A thorough revision of newly added symbols is
necessary before the next stable release.

Martin

On Wed, Dec 18, 2019 at 8:01 PM Bruce Mutton 
wrote:


OK, it’s not ‘just’ a Therion issue.

Here is the same 5.4.4+19eb624 (2019-12-09) output viewed with

Foxit on the left, and Sumatra on the right.


If we go back in Therion versions, there is some point where both

pdf viewers plot the dots correctly (5.4.4+00a31d0 (2019-10-22) at
is OK I think).  My previous message shows shots from Foxit (I
think).  Now I have realised this I will need to start narrowing it
down again.


Bruce



From: Therion  On Behalf Of Bruce

Mutton via Therion

Sent: Thursday, 19 December 2019 07:05
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: Re: [Therion] Problem with dots in symbols:

map-connection is empty




Yes, with Therion version 5.4.4+4d5750d (2019-12-17) even my

customised point map-connection is affected.  The dot is missing.




In another project, my area sand is looking a bit weird (short

dashes, not dots).




If I revert to 5.4.4+00a31d0 (2019-10-22) (and remove maps-set and

log extend from my thconfigs) then the short dashes have rounded
dot-like appearance, as I believe they should.




And my map connection gets better.

Bruce





-Original Message-
From: Therion  On Behalf Of Benedikt

Hallinger

Sent: Thursday, 19 December 2019 04:12
To: List for Therion users 
Subject: [Therion] Problem with dots in symbols: map-connection is

empty




Hi there,

we noticed some problems with dots in symbols yesterday, the won't

show anymore.




I can reproduce this with therion 5.4.4+19eb624 (2019-12-09).

The problem exists with the default symbol for "point

map-connection", as well as with my custom layout code for clay:




Has something changed recently in the point definition?

I assume, because the default map-connection item should still

work but doesn't show points?






With best regards,

Beni

___

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___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Problem with dots in symbols: map-connection is empty

[Benedikt Hallinger]

Again me;
i tested further and when map opened with mupdf, everything looks fine 
now.
Just Okular has the issues with the altitude-mark being a point and the 
missing map-connection points now!


Am 2019-12-18 21:06, schrieb Stacho Mudrak:

I've tried to fix these problems in commit d9361de. Hopefully, it
fixes the issue

S.

On Wed, 18 Dec 2019 at 20:37, Martin Budaj  wrote:


Hi,

the problem is in a global "linecap := butt;" setting in the point
mudcrack symbol (added on December 6) which changes the appearance
of
the line endings (the dot is a zero-length line which used to be
drawn
with a round pen). A thorough revision of newly added symbols is
necessary before the next stable release.

Martin

On Wed, Dec 18, 2019 at 8:01 PM Bruce Mutton 
wrote:


OK, it’s not ‘just’ a Therion issue.

Here is the same 5.4.4+19eb624 (2019-12-09) output viewed with

Foxit on the left, and Sumatra on the right.


If we go back in Therion versions, there is some point where both

pdf viewers plot the dots correctly (5.4.4+00a31d0 (2019-10-22) at
is OK I think).  My previous message shows shots from Foxit (I
think).  Now I have realised this I will need to start narrowing it
down again.


Bruce



From: Therion  On Behalf Of Bruce

Mutton via Therion

Sent: Thursday, 19 December 2019 07:05
To: 'List for Therion users' 
Cc: Bruce Mutton 
Subject: Re: [Therion] Problem with dots in symbols:

map-connection is empty




Yes, with Therion version 5.4.4+4d5750d (2019-12-17) even my

customised point map-connection is affected.  The dot is missing.




In another project, my area sand is looking a bit weird (short

dashes, not dots).




If I revert to 5.4.4+00a31d0 (2019-10-22) (and remove maps-set and

log extend from my thconfigs) then the short dashes have rounded
dot-like appearance, as I believe they should.




And my map connection gets better.

Bruce





-Original Message-
From: Therion  On Behalf Of Benedikt

Hallinger

Sent: Thursday, 19 December 2019 04:12
To: List for Therion users 
Subject: [Therion] Problem with dots in symbols: map-connection is

empty




Hi there,

we noticed some problems with dots in symbols yesterday, the won't

show anymore.




I can reproduce this with therion 5.4.4+19eb624 (2019-12-09).

The problem exists with the default symbol for "point

map-connection", as well as with my custom layout code for clay:




Has something changed recently in the point definition?

I assume, because the default map-connection item should still

work but doesn't show points?






With best regards,

Beni

___

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

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

Re: [Therion] therion sketch .th, Use of Grade UISv1_1

[Benedikt Hallinger]

Hi Alastair,
grade/endgrade outside centerline or survey definition is to define 
grade-definitions.
Inside a centerline(!) you just need the grade specification, which will imho 
be valid until the next grade instance.

> Am 23.12.2019 um 18:02 schrieb alastair gott :
> 
> 
> Hi Therion mailing list,
> 
> I'm trying to use the function "grade" in one of our .th files, theres a 
> sketch made of a cave with very little detail, but we think it would be 
> better to include it.
> 
> I'm strugging to get the function grade to work, therion is giving me red 
> writing "-- not enough data readings" and stopping the survey from 
> generating, but only when I implement the grade function.
> 
> I must be using it incorrectly, but I've tried it between survey and 
> centreline commands too and that isn't working either. this gives red writing 
> "-- invalid value -- centerline"
> 
> centerline
> #[omitted] ​
> units length meters​
> units compass clino degrees​
> data normal from to length compass clino​
> extend left​
> grade UISv1_1​
> 0 1 1.00 300 0.0​
> 1 2 1.00  0.0 0.0​
> 2 3 1.00  0.0 0.0​
> 3 4 1.00  0.0 0.0​
> 4 5 1.00  0.0 0.0​
> endgrade​​
>   endcenterline
> 
> 
> 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] therion sketch .th, Use of Grade UISv1_1

[Benedikt Hallinger]

No, it is like this:
UISv1_

———-
centerline
...more stuff...
grade UISv1_3

units length meters
units bearing gradient degrees
datanormal  fromto  length  bearing gradientleft
right   up  down
...data follows...
endcenterline

> Am 23.12.2019 um 20:35 schrieb Andrew Atkinson :
> 
> I'm only on a phone so cannot check this but surely it needs a number after 
> the system
> 
> grade UISv1 3
> 
> Also the th book of 19/12/19 only has v1 not v1_1 listed
> 
> Andrew
> 
>> On 23 December 2019 18:02:00 CET, alastair gott  
>> wrote:
>> Hi Therion mailing list,
>> 
>> I'm trying to use the function "grade" in one of our .th files, theres
>> a sketch made of a cave with very little detail, but we think it would
>> be better to include it.
>> 
>> I'm strugging to get the function grade to work, therion is giving me
>> red writing "-- not enough data readings" and stopping the survey from
>> generating, but only when I implement the grade function.
>> 
>> I must be using it incorrectly, but I've tried it between survey and
>> centreline commands too and that isn't working either. this gives red
>> writing "-- invalid value -- centerline"
>> 
>> centerline
>>   #[omitted] ​
>>   units length meters​
>>   units compass clino degrees​
>>   data normal from to length compass clino​
>>   extend left​
>>   grade UISv1_1​
>>   0 1 1.00 300 0.0​
>>   1 2 1.00  0.0 0.0​
>>   2 3 1.00  0.0 0.0​
>>   3 4 1.00  0.0 0.0​
>>   4 5 1.00  0.0 0.0​
>>   endgrade​​
>> endcenterline
>> 
>> 
>> Regards,
>> Alastair Gott.
>> 
>> alastairg...@hotmail.com,
>> M: 07931779380.
> 
> Andrew
> -- 
> ___
> 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] therion sketch .th, Use of Grade UISv1_1

[Benedikt Hallinger]

Nice Christmas everyone :)

> Am 23.12.2019 um 20:55 schrieb alastair gott :
> 
> 
> Hi Beni,
> 
> Many thanks, Have just slotted it in before units and data within the 
> centreline/endcentreline wrapper, and it works!
> 
> Thank you for helping me get this sorted.
>  on your recommendation, I have not included an endgrade as there is no need.
> 
> Just realised you're the master of grades Beni :) 
> https://mailman.speleo.sk/pipermail/therion/2016-November/006103.html
> 
> 
> Regards,
> Alastair Gott.
> 
> alastairg...@hotmail.com,
> M: 07931779380.
> From: Therion  on behalf of Benedikt Hallinger 
> 
> Sent: 23 December 2019 19:41
> To: List for Therion users 
> Subject: Re: [Therion] therion sketch .th, Use of Grade UISv1_1
>  
> No, it is like this:
> UISv1_
> 
> ———-
> centerline
> ...more stuff...
> grade UISv1_3
> 
> units length meters
> units bearing gradient degrees
> datanormal  fromto  length  bearing gradientleft  
>   right   up  down
> ...data follows...
> endcenterline
> 
> > Am 23.12.2019 um 20:35 schrieb Andrew Atkinson :
> > 
> > I'm only on a phone so cannot check this but surely it needs a number 
> > after the system
> > 
> > grade UISv1 3
> > 
> > Also the th book of 19/12/19 only has v1 not v1_1 listed
> > 
> > Andrew
> > 
> >> On 23 December 2019 18:02:00 CET, alastair gott  
> >> wrote:
> >> Hi Therion mailing list,
> >> 
> >> I'm trying to use the function "grade" in one of our .th files, theres
> >> a sketch made of a cave with very little detail, but we think it would
> >> be better to include it.
> >> 
> >> I'm strugging to get the function grade to work, therion is giving me
> >> red writing "-- not enough data readings" and stopping the survey from
> >> generating, but only when I implement the grade function.
> >> 
> >> I must be using it incorrectly, but I've tried it between survey and
> >> centreline commands too and that isn't working either. this gives red
> >> writing "-- invalid value -- centerline"
> >> 
> >> centerline
> >>   #[omitted] ​
> >>   units length meters​
> >>   units compass clino degrees​
> >>   data normal from to length compass clino​
> >>   extend left​
> >>   grade UISv1_1​
> >>   0 1 1.00 300 0.0​
> >>   1 2 1.00  0.0 0.0​
> >>   2 3 1.00  0.0 0.0​
> >>   3 4 1.00  0.0 0.0​
> >>   4 5 1.00  0.0 0.0​
> >>   endgrade​​
> >> endcenterline
> >> 
> >> 
> >> Regards,
> >> Alastair Gott.
> >> 
> >> alastairg...@hotmail.com,
> >> M: 07931779380.
> > 
> > Andrew
> > -- 
> > ___
> > Therion mailing list
> > Therion@speleo.sk
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.speleo.sk%2Flistinfo%2Ftherion&data=02%7C01%7C%7C805d0e107d5443a6783008d787e03887%7C84df9e7fe9f640afb435%7C1%7C0%7C637127269406055996&sdata=OQbTN%2Bz7%2FvC522tLXJ31UTPMOJnUwbd1B70Z0jsDvXQ%3D&reserved=0
> ___
> Therion mailing list
> Therion@speleo.sk
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailman.speleo.sk%2Flistinfo%2Ftherion&data=02%7C01%7C%7C805d0e107d5443a6783008d787e03887%7C84df9e7fe9f640afb435%7C1%7C0%7C637127269406055996&sdata=OQbTN%2Bz7%2FvC522tLXJ31UTPMOJnUwbd1B70Z0jsDvXQ%3D&reserved=0
> ___
> 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] Changing Atlas layout

[Benedikt Hallinger]

Hello,
i currently map a relatively long tunnel and want to be able to print it 
out on several A4 papers.
The Atlas function of therion is the thing that solves this problem 
quite nicely.


However, how can i tune the atlas layout, like disabling all visible 
features of the atlas (no navigation, no title, no borders when showing 
the overlapping (but the overlapping should persist!)


The main goal is, to print the tunnel like it prints in normal export 
mode, but on several pages which break like it does in atlas mode.

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

Re: [Therion] Changing Atlas layout

[Benedikt Hallinger]

Hello,
that worked quite good already! Thanks for pointing me to that hint!


Am 2020-02-01 3:20, schrieb Bruce Mutton:

Have never played much with Atlas layout possibilities, beyond adding
a north arrow, which Stacho or one of the Martins showed me how to
do...

There is this suggestion on pg 69 of the Therion Book.

layout my_layout
scale 1 200
page-setup 29.7 21 27.7 19 1 1 cm
size 26.7 18 cm
overlap 0.5 cm
code tex-atlas
\def\dopage{\box\mapbox}
\insertmaps
endlayout

Seems like it should achieve at least some of your aims.

Bruce

-Original Message-
From: Therion  On Behalf Of Benedikt 
Hallinger

Sent: Saturday, 1 February 2020 11:33
To: therion@speleo.sk
Subject: [Therion] Changing Atlas layout

Hello,
i currently map a relatively long tunnel and want to be able to print
it out on several A4 papers.
The Atlas function of therion is the thing that solves this problem
quite nicely.

However, how can i tune the atlas layout, like disabling all visible
features of the atlas (no navigation, no title, no borders when
showing the overlapping (but the overlapping should persist!)

The main goal is, to print the tunnel like it prints in normal export
mode, but on several pages which break like it does in atlas mode.
___
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] Need metapost wizard: new text label

[Benedikt Hallinger]

Hi there,
i need some new point symbol (text label). Its a simple text on white color 
within a box with rounded corners, like the attached image.

My metapostskills are not good enough to get this to work...

For now i would be happy to have such a user point symbol.
It would be important that it scales well and react to xtherions direction 
setting.

Optional it would be cool if the default symbol could show the current survey 
identifier of the nearest station in the scrap and maybe also the nearest next 
survey.
But this information could also be maintained manually for now.

Is there someone here for my rescue? :)
Thanks in advance,
Beni___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Need metapost wizard: new text label

[Benedikt Hallinger]

Hello,
meanwhile i tried to play more with this.
I'm nearly there, however i still have no clue how to read out the text 
attribute i attached to the symbol in the th2. "txt := ATTR__text;" 
throws metapost out the window.


The point is defined like this:
  point 234.0909090909091 626.3636363636364 u:mappe -attr text 1234


Layout i came up with so far (does not support 
scaling/alignment/rotation, but thats fine so far):




-
layout m

  # Symbol to denote assigned survey.
  # If option -attr text  is given, it will be used; otherwise 
current survey is shown.

  code metapost
def p_u_mappe(expr pos, theta, sc, al) =
  T:=identity aligned al rotated theta scaled sc shifted pos;

  % GET LABEL TEXT:
  string txt;
  txt := "123";
  %txt := ATTR__text;   % does not work. How do i get the value from 
' -attr text "345" '?

  if known(ATTR__text):
txt := ATTR_text;   % NEVER evaluates to TRUE!?!?
  else:
txt := ATTR__survey;
  fi;

  % DRAW LABEL:
  lab:=thelabel(txt, pos);
  process_label(pos, 0.001);


  % BORDER:
  pickup PenA;  % border thickness
  interim bboxmargin:=6.5bp;% padding border->text
  q:=((bbox lab) smoothed 4);   % smoothness of corners
  draw q;

enddef;

initsymbol("p_u_mappe");
  endcode
endlayout
-----


Am 2020-02-19 18:34, schrieb Benedikt Hallinger:

Hi there,
i need some new point symbol (text label). Its a simple text on white
color within a box with rounded corners, like the attached image.


My metapostskills are not good enough to get this to work...

For now i would be happy to have such a user point symbol.
It would be important that it scales well and react to xtherions
direction setting.

Optional it would be cool if the default symbol could show the current
survey identifier of the nearest station in the scrap and maybe also
the nearest next survey.
But this information could also be maintained manually for now.

Is there someone here for my rescue? :)
Thanks in advance,
Beni

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

Re: [Therion] Need metapost wizard: new text label

[Benedikt Hallinger]

Thank you very much!
indeed i was really close. Time to go to bed, hopefully my eyes can find 
the bed :)
It is also already mentioned correctly at the therion book. However, 
maybe it would be good to add  footnote at page 35 so this is made more 
obvious.


The working code below, in case someone tries to google it.

Attached also screenshots:
- in the legend the current survey name is printed
- in the map the "-attr text 1234" is honored.

point symbol in th2-file:   point u:mappe -attr text "1234"





# Symbol to denote assigned survey.
# If option -attr text  is given, it will be used; otherwise 
current survey is shown.

def p_u_mappe(expr pos, theta, sc, al) =
  T:=identity aligned al rotated theta scaled sc shifted pos;

  % GET LABEL TEXT:
  string txt;
  if known(ATTR_text):
txt := ATTR_text;
  else:
txt := ATTR__survey;
  fi;

  % DRAW LABEL:
  lab:=thelabel(txt, pos);
  process_label(pos, 0.001);


  % BORDER:
  pickup PenA;  % border thickness
  interim bboxmargin:=6.5bp;% padding border->text
  q:=((bbox lab) smoothed 4);   % smoothness of corners
  draw q;

enddef;





Am 2020-02-27 0:37, schrieb Tarquin Wilton-Jones via Therion:

Hi Benedikt,


  txt := "123";
  txt := ATTR__text;   % does not work. How do i get the value 
from


You are so nearly right.
Two underscores for Therion's built in properties. One underscore for
-attr properties.
ATTR_text

I have an example here:
https://therion.speleo.sk/wiki/metapost#rope_lengths

Regarding your main question, no I don't know how to create custom 
label

ornamentation (it looks like black magic to me). But you can see what I
have learned here:
https://therion.speleo.sk/wiki/metapost#adding_custom_styled_labels_at_any_point_linepoint

And then you need to look through the Metapost debugging output for:
vardef p_label@#(expr txt,pos,rot,mode) =

That is the code that actually draws labels with ornamentation. It then
calls functions like this: process_circledlabel

That in turn - after writing a label - uses some kind of bounding box
measuring to decide how to ornament it. Check out the function:
def write_circ_bbox expr q =

Good luck sir. If you work it out, please document it so we can all
learn how it all works. :)

Cheers,

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

Re: [Therion] Need metapost wizard: new text label

[Benedikt Hallinger]

Good morning, and thank you for your comments!
Honestly, i have no clue what this all does, i just managed to copy paste until 
it magically startet to work :)

If you want to upload it to the wiki, im honored and please modify to your 
wills, especially to make it not break anything existing. Would be nice if you 
could drop me a line if its ready :)
(I fear fiddling around with it, as it already took me about five hours to get 
this and i don’t want to break it again)

My intention for the usage was in bigger cave systems to show the adjacent 
survey names (with preview below/above) so one can more easily navigate in the 
data and see where to look next.

Btw, i found out that „symbol-hide point u:mysymbol“ does not seem to recognize 
the symbol subtype and thus cannot hide it. Is this normal or am i doing 
something wrong?

> Am 27.02.2020 um 09:02 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> Nice one :)
> 
> All simple enough to understand (I might put it on the wiki with some
> explanatory comments).
> 
>> thelabel(txt, pos); 
> 
> I notice in the main Therion Metapost, it uses
> lab:=thelabel@#(txt, pos);
> to make sure that it can respect alignment, which your code cannot.
> Don't suppose you worked out how to pass the correct alignment value to
> it, did you?
> 
>> interim bboxmargin:=6.5bp;% padding border->text
> 
> Just checking, since I don't know the "interim" keyword very well ...
> Doesn't it need to be inside a "begingroup/endgroup" pair, in order to
> know when to stop applying the "interim" value to the internal
> bboxmargin variable?
> 
> As far as I can tell, you are modifying the global value of it, so all
> subsequent uses of that internal variable will end up with your padding.
> At least until the next "endgroup" happens somewhere above your code in
> the stack.
> 
> (You are also trampling on any existing variables called lab, q or txt,
> but this is normal for Therion's code for some reason. Personally, I
> have started wrapping all of my symbol code in a group whenever it uses
> variables, and then I save them in order to make a macro equivalent to a
> "local" variable. This was needed in one case because I reused some
> variable name with a different datatype, and caused Metapost to get upset.)
> ___
> 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] Need metapost wizard: new text label

[Benedikt Hallinger]

... maybe it would be a very good idea to write a subchapter into the thbook 
user symbol chapter?
That contains all those pitfalls for metapost-th-symbols novices like me

> Am 27.02.2020 um 09:56 schrieb Benedikt Hallinger :
> 
> Good morning, and thank you for your comments!
> Honestly, i have no clue what this all does, i just managed to copy paste 
> until it magically startet to work :)
> 
> If you want to upload it to the wiki, im honored and please modify to your 
> wills, especially to make it not break anything existing. Would be nice if 
> you could drop me a line if its ready :)
> (I fear fiddling around with it, as it already took me about five hours to 
> get this and i don’t want to break it again)
> 
> My intention for the usage was in bigger cave systems to show the adjacent 
> survey names (with preview below/above) so one can more easily navigate in 
> the data and see where to look next.
> 
> Btw, i found out that „symbol-hide point u:mysymbol“ does not seem to 
> recognize the symbol subtype and thus cannot hide it. Is this normal or am i 
> doing something wrong?
> 
>> Am 27.02.2020 um 09:02 schrieb Tarquin Wilton-Jones via Therion 
>> :
>> 
>> Nice one :)
>> 
>> All simple enough to understand (I might put it on the wiki with some
>> explanatory comments).
>> 
>>> thelabel(txt, pos); 
>> 
>> I notice in the main Therion Metapost, it uses
>> lab:=thelabel@#(txt, pos);
>> to make sure that it can respect alignment, which your code cannot.
>> Don't suppose you worked out how to pass the correct alignment value to
>> it, did you?
>> 
>>> interim bboxmargin:=6.5bp;% padding border->text
>> 
>> Just checking, since I don't know the "interim" keyword very well ...
>> Doesn't it need to be inside a "begingroup/endgroup" pair, in order to
>> know when to stop applying the "interim" value to the internal
>> bboxmargin variable?
>> 
>> As far as I can tell, you are modifying the global value of it, so all
>> subsequent uses of that internal variable will end up with your padding.
>> At least until the next "endgroup" happens somewhere above your code in
>> the stack.
>> 
>> (You are also trampling on any existing variables called lab, q or txt,
>> but this is normal for Therion's code for some reason. Personally, I
>> have started wrapping all of my symbol code in a group whenever it uses
>> variables, and then I save them in order to make a macro equivalent to a
>> "local" variable. This was needed in one case because I reused some
>> variable name with a different datatype, and caused Metapost to get upset.)
>> ___
>> 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] Metapost variable macro suffixes

[Benedikt Hallinger]

> This is such a weird programming language :)

It is...
And despite being plenty of documentation online, this one seems to be 
mastering me (and i usually love programming)

> Am 01.03.2020 um 21:05 schrieb Tarquin Wilton-Jones via Therion 
> :
> 
> I do seem to like answering my own questions.
> 
> 3 days searching for the solution and ...
> 
> if A = (-1,1): sfx:="ulft";
> elseif A = (0,1): sfx:="top";
> ...
> if Foo = "b"
>  thelabel.scantokens(sfx)(txt, pos);
>  ... other stuff ...
> else:
>  p_label.scantokens(sfx)(thetext,P,R,style);
> fi;
> 
> Yes, scantokens can be used inline, as a function-like call that returns
> an actual suffix token which becomes part of the macro's suffix when the
> macro is subsequently called.
> 
> This is such a weird programming language :)
> ___
> 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] Need metapost wizard: new text label

[Benedikt Hallinger]

Hello Tarquin,

i tweaked and fiddled around and now have a version that correctly 
scales, rotates and aligns.
Your wiki page hint helped, but i already found it in the past... The 
example code there does not work here for some reason (compile error).


But anyhow, to answer your question regarding the "0.001" rotation 
parameter in the label calling:
if i use "0.0" or "0" or also "0.0001", it puts my label text in the 
center of the generated map with rotation of the scrap-rotation applied. 
I don't know why and found by try-and-error that this value works.



Here is the updated code:, enhanced with a nicer legend output:
---
# Symbol to denote assigned survey.
#   Option "-attr text " shows given text; otherwise current 
survey is shown.
#   Option "-attr bordersmooth " overrides edge smoothness (0 
for sharp edges)

#   Option "-attr bordermargin " overrides margin text/border
#   Option "-attr basescale " overrides basic text sizing 
factor (default text size)

def p_u_mappe(expr pos, theta, sc, al) =
  T:=identity aligned al rotated theta scaled sc shifted pos;
  begingroup;
% Basic config
bordersmooth:=4; % smoothness of box corners  (0=90° 
edges)

bordermargin:=5.0bp; % padding border->text
basescale:=1.0;  % basic scaling of default-sized text
if known(ATTR_bordersmooth): 
bordersmooth:=scantokens(ATTR_bordersmooth); fi;
if known(ATTR_bordermargin): 
bordermargin:=scantokens(ATTR_bordermargin); fi;
if known(ATTR_basescale):
basescale:=scantokens(ATTR_basescale);   fi;


% GET LABEL TEXT:
string txt;
if known(ATTR_text):
txt := ATTR_text;
else:
txt := ATTR__survey;
fi;

% DRAW LABEL:
lab:=thelabel(txt, (0.0,0.0));
pickup PenA;   % border thickness
interim bboxmargin:=bordermargin;  % padding border->text
q:=((bbox lab) smoothed bordersmooth) aligned al scaled (sc * 
basescale) rotated theta shifted pos;

draw q;
lab:=lab aligned al;
lab:=lab scaled (sc * basescale);
lab:=lab rotated theta;
lab:=lab shifted pos;
process_label(pos, 0.001);   % for some weird reason "0.0" does 
not work here and puts the label to map-center at scrap-rotation.


  endgroup;
enddef;
def p_u_mappe_legend =
begingroup;
save ATTR_text;
string ATTR_text;
ATTR_text:="028";
p_u_mappe((.5,.5) inscale, 0, 1.0, (0,0));
endgroup;
enddef;

---





Am 2020-03-01 22:23, schrieb Tarquin Wilton-Jones via Therion:

thelabel(txt, pos);


I notice in the main Therion Metapost, it uses
lab:=thelabel@#(txt, pos);
to make sure that it can respect alignment, which your code cannot.
Don't suppose you worked out how to pass the correct alignment value 
to

it, did you?


I have worked it out, see my thread "Metapost variable macro suffixes".
I will add it to my existing function which takes the point alignment
parameter and turns it into the right suffix in the "thelabel" call or
p_label call, whichever one ends up getting used.

Your code also didn't apply rotation to the ornamentation. You need
something like this:
draw ((bbox lab) smoothed 4) rotatedaround (pos,rotation);

Note that this applies the rotation around the point position, so
alignment and rotation at the same time is weird. This is the same with
regular labels though - Therion bug that Bruce is fond of :) - so at
least this is consistent with Therion itself.

Your code hardcoded rotation to a very specific 0.001 degrees, which 
was

weird. I assume you had intended to use 0 or a variable (my code uses
the rotation parameter of the point symbol).


interim bboxmargin:=6.5bp;    % padding border->text


Just checking, since I don't know the "interim" keyword very well ...
Doesn't it need to be inside a "begingroup/endgroup" pair, in order to
know when to stop applying the "interim" value to the internal
bboxmargin variable?

As far as I can tell, you are modifying the global value of it, so all
subsequent uses of that internal variable will end up with your 
padding.
At least until the next "endgroup" happens somewhere above your code 
in

the stack.


This was correct. You needed to use begingroup+endgroup or use a vardef
instead of a def (with vardef, it automatically applies a
begingroup+endgroup). Therion's Metapost uses both of these approaches
to avoid the problem.
___
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] Need metapost wizard: new text label

[Benedikt Hallinger]

Hello again.
I freshly copy-pasted your examples and now it works.
I must have made something wrong like you described (therion 5.4.4 
(2019-05-01)).


Tanks!


Am 2020-03-04 15:08, schrieb Tarquin Wilton-Jones via Therion:

example code there does not work here for some reason (compile error).


Interesting ... I am using it myself and it works here. I wonder if
there is something odd in what the wiki outputs. Or maybe you copy &
pasted the "code metapost" inside an existing "code metapost" block. If
you have time to check, what's your error message?

Or alternatively, do you have a minimal survey where I can see the
failure myself?


0.001


I won't pretend to understand what that is all about. Very weird 
indeed.

___
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] New DEM data from NASA

[Benedikt Hallinger]

Hello, could gdal be of use here?
At least it is what i use to process LIDAR data an i think i used it also to 
process aster+srtm data (including patching voids from the one with the other)

> Am 05.03.2020 um 23:48 schrieb Paweł Krawczyk via Therion :
> 
> 
> On 05/03/2020 20:39, Martin Sluka via Therion wrote:
>> https://www.gislounge.com/updated-global-elevation-data-released-by-nasa/
>> 
>> 
> With permission of the original author (Mike McCombe) and help of Wookey I 
> have recently started to refactor TerrainTool to use v3 ASTER files but seems 
> like we need to target the newest ones... Due to the complexity of the old 
> DEM file parser I'm considering using a dedicated GeoTiff library - anyone 
> has any experiences or suggestions?
> 
> We're talking about Java GUI app, right now repacked as Maven project, 
> sources can be found here:
> 
> https://git.sr.ht/~kravietz/TerrainTool
> 
> ___
> 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] New DEM data from NASA

[Benedikt Hallinger]

I have a (german commented) bash script doing this.
Only thing is that it is hatdcoded fir a specific case, but it shows the 
commands imvolved.

Should i post it to you?

> Am 06.03.2020 um 08:31 schrieb Paweł Krawczyk via Therion :
> 
> On 06/03/2020 07:12, Benedikt Hallinger wrote:
>> Hello, could gdal be of use here?
>> At least it is what i use to process LIDAR data an i think i used it also to 
>> process aster+srtm data (including patching voids from the one with the 
>> other)
>> 
> If there's a reliable workflow to generate surface files for Therion using 
> gdal then I guess so.
> 
> ___
> 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] New DEM data from NASA

[Benedikt Hallinger]

here it comes :)It uses LIDAR data from austrian sourves, but should be able to be adapted accordingly. I hoe it gives some hints.Feel free to modify and share!

generate.sh
Description: Binary data
Am 06.03.2020 um 12:26 schrieb Wookey :On 2020-03-06 09:02 +0100, Benedikt Hallinger wrote:I have a (german commented) bash script doing this.Only thing is that it is hatdcoded fir a specific case, but it shows the commands imvolved.Should i post it to you?Post it here. I doubt if Paweł is the only one interested.Wookey-- Principal hats:  Linaro, Debian, Wookware, ARMhttp://wookware.org/___Therion mailing listTherion@speleo.skhttps://mailman.speleo.sk/listinfo/therion___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] New DEM data from NASA

[Benedikt Hallinger]

... if it is needed, i can translate it to English. Just say so and i try to 
squeeze out some time...

> Am 06.03.2020 um 13:13 schrieb Benedikt Hallinger :
> 
> 
> here it comes :)
> 
> It uses LIDAR data from austrian sourves, but should be able to be adapted 
> accordingly. I hoe it gives some hints.
> Feel free to modify and share!
> 
> 
> 
> 
> 
>>>> Am 06.03.2020 um 12:26 schrieb Wookey :
>>>>> 
>>>>>> On 2020-03-06 09:02 +0100, Benedikt Hallinger wrote:
>>>>>>> 
>>>>>>>> I have a (german commented) bash script doing this.
>>>>>>>>> 
>>>>>>>>>> Only thing is that it is hatdcoded fir a specific case, but it shows 
>>>>>>>>>> the commands imvolved.
>>>>>>>>>>> 
>>>>>>>>>>>> Should i post it to you?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Post it here. I doubt if Paweł is the only one interested.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Wookey
>>>>>>>>>>>>> -- 
>>>>>>>>>>>>> Principal hats:  Linaro, Debian, Wookware, ARM
>>>>>>>>>>>>> http://wookware.org/
>>>>>>>>>>>>> ___
>>>>>>>>>>>>> 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] New DEM data from NASA

[Benedikt Hallinger]

Here :)


Am 2020-03-07 14:27, schrieb Rodrigo Severo via Therion:

‐‐‐ Original Message ‐‐‐
On Friday, March 6, 2020 9:34 AM, Benedikt Hallinger 
 wrote:


... if it is needed, i can translate it to English. Just say so and i 
try to squeeze out some time...


It would certainly help a lot.

Regards,

Rodrigo
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion#!/bin/bash
#
# Commands to generate therion DEM data with GDAL tools out of austrian ALS data
#

# 0. Make source data available in temporary folder
mkdir tmp
unzip -o ../../srcdata/DOM/ALS_DGM/Oberösterreich-DGM_10M.zip -d tmp/


# 1. Generate heightmap (DEM) from ALS-data
# ===
# The source data is in EPSG:31255 with grid width 10m; our target is EPSG:31258 (BMN M31)
# Target size is boundingbox in EPSG:31258:
#  #xllcorner469000
#  #yllcorner263500
#  #xurcorner476700
#  #yurcorner268400
gdalwarp -t_srs EPSG:31258   -te 469500 263000 476700 268400  -tr 10 10 -dstnodata  -r cubic   -overwrite  tmp/DGM_10M.tif tmp/dem.tif
# ^tgt-coord-system  ^llx   ^lly   ^urx   ^ury^grid-width   ^nodata-value  ^interpolation ^overwrite tgt data if existing 

# Verify results (shows generated boundingbox):
# The results are not always exactly the requested box coordinates which is a result of the underlaying grid.
gdalinfo tmp/dem.tif |grep -A4 "Corner Coordinates" |grep "Lower Left"
gdalinfo tmp/dem.tif |grep -A4 "Corner Coordinates" |grep "Upper Right"
# Results in this case (which fits exactly):
#   Lower Left  (  469500.000,  263000.000)
#   Upper Right (  476700.000,  268400.000)
# => Result is DEM file in GEO-TIFF: tmp/dem.tif in EPSG:31258 with 10m-grid


# Lets build therion data with that (therion can't use the TIFF file directly,
# we need to convert into ASCII format):
gdal_translate -co DECIMAL_PRECISION=5 -of AAIGrid tmp/dem.tif tmp/dem.txt

# Now add therion header data.
# We will produce the grid file which can be used by therion.
# (The needed values for the "grid" command comes from inside the ASCII-grid file)
#   ncols720
#   nrows540
#   xllcorner469500.
#   yllcorner263000.
#   cellsize 10.
cat - tmp/dem.txt > hirlatz-dom-10mALS.grid < hirlatz-dop-1m_geoland-dom-10mALS.th <___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Hello,
does anybody know how i can measure the distance from a given station to 
the surface, when i have a surface model loaded?


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

Re: [Therion] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Hello,
do i need some special options aside from "export model -o model.3d" to 
enable surface in aven?
If i try to enable the surface legs, aven prompts me to open some 
file...



Am 2020-03-26 22:49, schrieb Tarquin Wilton-Jones via Therion:
does anybody know how i can measure the distance from a given station 
to

the surface, when i have a surface model loaded?


I have always done this with Survex's Aven. Export 3D, open in Aven,
enable surface legs, click the station, hold mouse over the surface
legs. (I do this with either surface survey stations, or surface grid
that I prepared with TerrainTool.)

Aside:
If you use Survex rather than Therion to export this, the ends of the
splays become clickable points in Aven, so you can measure from your
highest splay. If you use a 3D exported by Therion, then you cannot
click on the splays. Therion does not add the control point at the end
of each splay (I have filed a bug for that).
___
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] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Yes i did. Thanks for that hint.
However, my aven does not enable me to avtivate it in the view menu, its 
disabled (greyed out), i assume because i do not have surface data in 
the file?

How do i tell therion to export this?


Am 2020-03-26 23:06, schrieb Tarquin Wilton-Jones:

enable surface in aven?
If i try to enable the surface legs, aven prompts me to open some 
file...


I assume you are trying to "file - open terrain" rather than "view -
surface survey legs".

Terrain is a different thing, which I have never used, and I don't 
think

you can select parts of it for use with measuring. I think though that
Survex's terrain is similar to the type of terrain used by Therion 
though.

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

Re: [Therion] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Hi there,
i just wrote a small tool to do the conversion from a therion surface 
mesh into survex format:

https://github.com/hbeni/therionsurface2survex

It would be nice if some C++ programmers can look over the code as this 
is my first c++ endeavour.


The program basically parses the therion source file and generates *fix 
commands out of it together with nosurvey-centerline connecting the 
stations to a mesh.
The resulting .swx file then can be put trough survex' cavern program to 
generate a 3d file of the mesh.
That can be easily combined with a 3d file of the cave generated from 
therion (using the import statements). For ease of use provided a basic 
example for combining in the readme. A sample to parse a mesh is in the 
projects example/ folder, however i also tested it positive with the 
rabbit cave example.


With my dataset the calculation seems to take a little longer there 
are 388.800 fixe stations in the surface mesh giving a 31M swx-file in 
total.
I hope this will finish somtime (running already for 25 minutes) but 
maybe i overloaded cavern with this.
Otherwise i probably need to turn down the grid resolution (currently 
10m grid size).




Am 2020-03-26 23:23, schrieb Tarquin Wilton-Jones:
However, my aven does not enable me to avtivate it in the view menu, 
its

disabled (greyed out), i assume because i do not have surface data in
the file?


Sounds like it. It works based on legs that have:

flags surface
1 2 9.8 123 0
flags not surface

Or if you have used TerrainTool to export it as a grid, it will have
added that for you.

This has been very easy for us in our projects because we either knew
exactly which line to follow on the surface beforehand, or we surveyed
the cave first then surveyed over the surface afterwards, staying above
the passage so we could have a useful measure of the surface above the 
cave.


In more complex caves, I rely on TerrainTool to cover the surface.
Looking forward to being able to use the new more accurate NASADEM so
that the measurements are actually accurate.

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

Re: [Therion] LOX: Measure distance from station to surface

[Benedikt Hallinger]

cavern had eaten itself, but after pushing ctrl-c in the shell running 
therion, the 3d  file was written successfully and the output was nice.


I enhanced the therion wiki a little with a link to the tool.

Sorry, i have no clue how to cross compile this for windows.


Am 2020-03-27 23:51, schrieb Benedikt Hallinger:

Hi there,
i just wrote a small tool to do the conversion from a therion surface
mesh into survex format:
https://github.com/hbeni/therionsurface2survex

It would be nice if some C++ programmers can look over the code as
this is my first c++ endeavour.

The program basically parses the therion source file and generates
*fix commands out of it together with nosurvey-centerline connecting
the stations to a mesh.
The resulting .swx file then can be put trough survex' cavern program
to generate a 3d file of the mesh.
That can be easily combined with a 3d file of the cave generated from
therion (using the import statements). For ease of use provided a
basic example for combining in the readme. A sample to parse a mesh is
in the projects example/ folder, however i also tested it positive
with the rabbit cave example.

With my dataset the calculation seems to take a little longer
there are 388.800 fixe stations in the surface mesh giving a 31M
swx-file in total.
I hope this will finish somtime (running already for 25 minutes) but
maybe i overloaded cavern with this.
Otherwise i probably need to turn down the grid resolution (currently
10m grid size).



Am 2020-03-26 23:23, schrieb Tarquin Wilton-Jones:
However, my aven does not enable me to avtivate it in the view menu, 
its

disabled (greyed out), i assume because i do not have surface data in
the file?


Sounds like it. It works based on legs that have:

flags surface
1 2 9.8 123 0
flags not surface

Or if you have used TerrainTool to export it as a grid, it will have
added that for you.

This has been very easy for us in our projects because we either knew
exactly which line to follow on the surface beforehand, or we surveyed
the cave first then surveyed over the surface afterwards, staying 
above
the passage so we could have a useful measure of the surface above the 
cave.


In more complex caves, I rely on TerrainTool to cover the surface.
Looking forward to being able to use the new more accurate NASADEM so
that the measurements are actually accurate.

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

Re: [Therion] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Thanks, but i'm not into python :)


Am 2020-03-28 1:18, schrieb Philippe Vernant:

Hi,

There is an easy way to extract coordinates from the therion sql
export. Then using a shell script and GMT could provide the depth of
each point below the surface. I know that there is now a GMT library
under Python, if they have implemented the function in the library,
everything could be wrapped up in a single python script.

Cheers,
Phil


On 28 Mar 2020, at 00:28, Benedikt Hallinger  
wrote:


cavern had eaten itself, but after pushing ctrl-c in the shell running 
therion, the 3d  file was written successfully and the output was 
nice.


I enhanced the therion wiki a little with a link to the tool.

Sorry, i have no clue how to cross compile this for windows.


Am 2020-03-27 23:51, schrieb Benedikt Hallinger:

Hi there,
i just wrote a small tool to do the conversion from a therion surface
mesh into survex format:
https://github.com/hbeni/therionsurface2survex
It would be nice if some C++ programmers can look over the code as
this is my first c++ endeavour.
The program basically parses the therion source file and generates
*fix commands out of it together with nosurvey-centerline connecting
the stations to a mesh.
The resulting .swx file then can be put trough survex' cavern program
to generate a 3d file of the mesh.
That can be easily combined with a 3d file of the cave generated from
therion (using the import statements). For ease of use provided a
basic example for combining in the readme. A sample to parse a mesh 
is

in the projects example/ folder, however i also tested it positive
with the rabbit cave example.
With my dataset the calculation seems to take a little longer
there are 388.800 fixe stations in the surface mesh giving a 31M
swx-file in total.
I hope this will finish somtime (running already for 25 minutes) but
maybe i overloaded cavern with this.
Otherwise i probably need to turn down the grid resolution (currently
10m grid size).
Am 2020-03-26 23:23, schrieb Tarquin Wilton-Jones:
However, my aven does not enable me to avtivate it in the view 
menu, its
disabled (greyed out), i assume because i do not have surface data 
in

the file?

Sounds like it. It works based on legs that have:
flags surface
1 2 9.8 123 0
flags not surface
Or if you have used TerrainTool to export it as a grid, it will have
added that for you.
This has been very easy for us in our projects because we either 
knew
exactly which line to follow on the surface beforehand, or we 
surveyed
the cave first then surveyed over the surface afterwards, staying 
above
the passage so we could have a useful measure of the surface above 
the cave.

In more complex caves, I rely on TerrainTool to cover the surface.
Looking forward to being able to use the new more accurate NASADEM 
so

that the measurements are actually accurate.

___
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] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Hi there,
i released version 1.0 of therionsurface2survex 
(https://github.com/hbeni/therionsurface2survex)
and now the problem with this is, that the name is not fitting 
anymore...


Version 1.0 can:
- read GDAL ASCII grids directly [1]
- read therion "surface" blocks
- write survex .swx files containing the mesh
- write therion source files containing the mesh (flags surface) [2]


[1] i niticed that those files do not contain information about the 
coordinate-system used, so you need to add this manually afterwards. 
Question to all of you: would you expect an option that the tool adds it 
itself?
[2] would be my preferred way because it allows better control about 
further usage, also integration is more straightforward.



Am 2020-03-28 1:21, schrieb Benedikt Hallinger:

Thanks, but i'm not into python :)


Am 2020-03-28 1:18, schrieb Philippe Vernant:

Hi,

There is an easy way to extract coordinates from the therion sql
export. Then using a shell script and GMT could provide the depth of
each point below the surface. I know that there is now a GMT library
under Python, if they have implemented the function in the library,
everything could be wrapped up in a single python script.

Cheers,
Phil


On 28 Mar 2020, at 00:28, Benedikt Hallinger  
wrote:


cavern had eaten itself, but after pushing ctrl-c in the shell 
running therion, the 3d  file was written successfully and the output 
was nice.


I enhanced the therion wiki a little with a link to the tool.

Sorry, i have no clue how to cross compile this for windows.


Am 2020-03-27 23:51, schrieb Benedikt Hallinger:

Hi there,
i just wrote a small tool to do the conversion from a therion 
surface

mesh into survex format:
https://github.com/hbeni/therionsurface2survex
It would be nice if some C++ programmers can look over the code as
this is my first c++ endeavour.
The program basically parses the therion source file and generates
*fix commands out of it together with nosurvey-centerline connecting
the stations to a mesh.
The resulting .swx file then can be put trough survex' cavern 
program

to generate a 3d file of the mesh.
That can be easily combined with a 3d file of the cave generated 
from

therion (using the import statements). For ease of use provided a
basic example for combining in the readme. A sample to parse a mesh 
is

in the projects example/ folder, however i also tested it positive
with the rabbit cave example.
With my dataset the calculation seems to take a little longer
there are 388.800 fixe stations in the surface mesh giving a 31M
swx-file in total.
I hope this will finish somtime (running already for 25 minutes) but
maybe i overloaded cavern with this.
Otherwise i probably need to turn down the grid resolution 
(currently

10m grid size).
Am 2020-03-26 23:23, schrieb Tarquin Wilton-Jones:
However, my aven does not enable me to avtivate it in the view 
menu, its
disabled (greyed out), i assume because i do not have surface data 
in

the file?

Sounds like it. It works based on legs that have:
flags surface
1 2 9.8 123 0
flags not surface
Or if you have used TerrainTool to export it as a grid, it will 
have

added that for you.
This has been very easy for us in our projects because we either 
knew
exactly which line to follow on the surface beforehand, or we 
surveyed
the cave first then surveyed over the surface afterwards, staying 
above
the passage so we could have a useful measure of the surface above 
the cave.

In more complex caves, I rely on TerrainTool to cover the surface.
Looking forward to being able to use the new more accurate NASADEM 
so

that the measurements are actually accurate.

___
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] Question for lox generating strange spikes at passage end

[Benedikt Hallinger]

Hello,
in a dataset i get a strange behavior regarding the loch model at 
passage ends:


At station 1.10 a weird spike is produced in the loch model, that should 
not be there.
If one comments out some branch that is not located near 1.10, the 
problem goes away.


What causes these spikes?

Attached a test set with comented section, thus producing correct ending 
of the tunnel.
Also, an image showing the problem (left: wrong spike, right: correct 
result with the branch commented)



Thanks alot,
Beni

test.tar.gz
Description: GNU Zip compressed data
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Command line Therion on Windows

[Benedikt Hallinger]

Wed had a similar problem and resorted to make everywhere unix slashes.
It would be cool if therion would parse that to backslash reference on 
windows when parsing filepaths.


Am 2020-04-05 0:16, schrieb Rhys Tyers:

I think so. If I change the first file path to have backslashes then
the error is about the second file path in the config, and so on.

On Sat, 4 Apr 2020, 23:14 Philippe Vernant, 
wrote:


Hi Rhys,

Are you sure that is is not the end of the line rather than the
slashes ?

Phil


On 4 Apr 2020, at 11:00, Rhys Tyers  wrote:

Hello,

I have therion data repo that has been mainly worked on by
linux/mac users. Now I'm trying to work on it in Windows. Using
the xtherion gui works fine, but if I try to use the therion.exe
directly on the command line (like I would in linux) then it fails
because all the file paths have forward slashes rather than back
slashes.

Is there a way to get command line therion to run on files with
linux style file paths? I assume there must be because xtherion
manages it somehow.

Thanks,
Rhys ___
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] Command line Therion on Windows

[Benedikt Hallinger]

Maybe TCL does it automatically since its platform independent, c is usually 
not (directly). Xtherion compiled is a tcl program.

> Am 05.04.2020 um 11:36 schrieb Rhys Tyers :
> 
> 
> I agree, but also when compiling in XTherion it does work so there is some 
> magic happening in XTherion. I tried to have a look through the Therion 
> source to see what the difference is between how XTherion parses file paths 
> and how Therion command line parses file paths but I am not a C developer (or 
> anything close) and could not work it out.
> 
>> On Sat, 4 Apr 2020 at 23:45, Benedikt Hallinger  wrote:
>> Wed had a similar problem and resorted to make everywhere unix slashes.
>> It would be cool if therion would parse that to backslash reference on 
>> windows when parsing filepaths.
>> 
>> Am 2020-04-05 0:16, schrieb Rhys Tyers:
>> > I think so. If I change the first file path to have backslashes then
>> > the error is about the second file path in the config, and so on.
>> > 
>> > On Sat, 4 Apr 2020, 23:14 Philippe Vernant, 
>> > wrote:
>> > 
>> >> Hi Rhys,
>> >> 
>> >> Are you sure that is is not the end of the line rather than the
>> >> slashes ?
>> >> 
>> >> Phil
>> >> 
>> >>> On 4 Apr 2020, at 11:00, Rhys Tyers  wrote:
>> >>> 
>> >>> Hello,
>> >>> 
>> >>> I have therion data repo that has been mainly worked on by
>> >>> linux/mac users. Now I'm trying to work on it in Windows. Using
>> >>> the xtherion gui works fine, but if I try to use the therion.exe
>> >>> directly on the command line (like I would in linux) then it fails
>> >>> because all the file paths have forward slashes rather than back
>> >>> slashes.
>> >>> 
>> >>> Is there a way to get command line therion to run on files with
>> >>> linux style file paths? I assume there must be because xtherion
>> >>> manages it somehow.
>> >>> 
>> >>> Thanks,
>> >>> Rhys ___
>> >>> 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] Question for lox generating strange spikes at passage end

[Benedikt Hallinger]

Hello,
i fiddled more with the data, but to no avail.
It seems its something in lochs extrapolation code using misaligned data or 
something...

Is this reproducible at your setup?

> Am 31.03.2020 um 18:26 schrieb Benedikt Hallinger :
> 
> Hello,
> in a dataset i get a strange behavior regarding the loch model at passage 
> ends:
> 
> At station 1.10 a weird spike is produced in the loch model, that should not 
> be there.
> If one comments out some branch that is not located near 1.10, the problem 
> goes away.
> 
> What causes these spikes?
> 
> Attached a test set with comented section, thus producing correct ending of 
> the tunnel.
> Also, an image showing the problem (left: wrong spike, right: correct result 
> with the branch commented)
> 
> 
> Thanks alot,
> Beni
> 
> 
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Sketches on doesn't work / legacy survey

[Benedikt Hallinger]

What Tarquin said:
You can use "symbol-hide group cave-centerline" to hide all centerline 
relevant symbols.


Am 2020-04-15 20:19, schrieb Tarquin Wilton-Jones via Therion:

symbol-hide line centerline does *not *work (unknown symbol


centreline is not a valid line type, so you cannot use the keyword
"line" with it. (That is to say, it's not a type of line that you can
select from the dropdown when you are creating a line in XTherion.)

The line is called "survey" (with subtypes survey:cave and
survey:surface that you can select in XTherion), and Therion
automatically generates lines of that type when you ask it to render a
PDF. It also draws stations (subtypes painted, fixed, temporary,
natural). These are all grouped together as "cave-centreline" when
inside a cave (flags not surface) and surface-centreline (flags
surface), and those two groups are grouped into "centreline".

group centreline
|-group cave-centerline
| |-line survey
| | `-line survey:cave
| `-point station
|   |-point station:fixed
|   |-point station:natural
|   |-point station:painted
|   `-point station:temporary
`-group surface-centerline
  |-line survey
  | `-line survey:surface
  `-point station
|-point station:fixed
|-point station:natural
|-point station:painted
`-point station:temporary

And yes, that does mean that you cannot selectively hide just the
stations that are on the surface. But you can hide the parent group, 
and

then unhide the other things you want to appear...

symbol-hide group surface-centerline
symbol-show line survey:surface

I have not tested if this would actually work, but I think it should.
Have fun, and see what happens.

Hope this makes sense.
___
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] Hatching profiles and extended elevations

[Benedikt Hallinger]

Hello,
for the hatches:
maybe you could do a custom area symbol and use it with "clip off" 
option. I don't know if this is supported, but it might work. You could 
try it with some other area first...


And the section arrows are easy by a line option (see thbook p. 29):
"direction  ▷ can be used only with the 
section type.
It indicates where to put a direction arrow on the section line. None is 
default."



Am 2020-04-18 22:06, schrieb Roger Schuster:

Hello cavers,

at least in Germany it is/was usual to add hatching to extended
elevations and profiles (cross sections) like in the following
example:

I guess it will be difficult to do this in Therion because the
hatching is outside of the passage and will be clipped but anyway: Is
there a way to achieve this?

Is it possible to add an arrow to lines of type section indicating the
viewing direction like in this example:

Thank you!

Best regards,

Roger
___
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] Therion does not write valid colour by horizontal or vertical error data to 3d output

[Benedikt Hallinger]

What is the expected data therion should write instead?

> Am 26.04.2020 um 07:00 schrieb Bruce Mutton :
> 
> 
> A while back Survex 1.43 improved the ability of Aven to visualise loop 
> misclosures.
> Not only can it colour by error, it can now colour by horizontal or vertical 
> loop error.
>  
> Unfortunately, the 3d files produced by Therion do not properly write the 
> data.
> A brief discussion here 
> https://github.com/ojwb/survex/commit/fe8a1b478b91bd977a4b21be49af25724b16c692
>  that identifies the problem.
> Olly suggests the problem is:
> -Therion writes 0 for all the horz and vert error values where Survex is 
> being used for data processing.
> -Therion equates the horz and vertical error to the total error where Therion 
> does its own data processing.
>  
> For users who want a work around, there is one described in the last line of 
> the thread linked above.
>  
> 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] new Therion 5.5.0

[Benedikt Hallinger]

Cool, thanks!

what does --reproducible-output exactly do?
i cannot derive this from the thbook. What does reproducible mean?

Am 2020-05-01 10:32, schrieb Therion:

Hi, there is a new release 5.5.0 of Therion.
Release notes:

v5.5.0  Therion 5.5.0 (2020-05-01):

therion:
 * maps-offset  feature in thconfig file to disable maps 
drawn

   in offset [#159]
 * maps  feature in thconfig file to produce map just from 
scraps,

   ignoring the maps definition
 * log extend feature in thconfig to log extended elevation 
construction

 * added point mudcrack (thanks to Rodrigo Severo)
 * added an extensive SBE symbol set (thanks to Rodrigo Severo)
 * geomag data updated up to 2025
 * added support for reproducible generation of PDF and SVG output
   (command-line option --reproducible-output)
 * make thbook.pdf build reproducible (derive the created/modified 
dates

   of the PDF file from the commit date)
 * improved support for Proj 6.0 and 7.0 (see proj-auto init file 
option)

 * Catch2 unit testing library and Proj test cases added
 * all python scripts use Python 3 now
 * added Serbian (thanks to Ivana Miskovic) and Slovenian [PR#142]
translations
 * updated Portuguese translation [PR#170,220]
 * thbook improvements by Benedikt Hallinger [PR#161,162]
 * bugs fixed
   - spelling in some thbook chapters
   - html and kml output [PR#145,150]
   - extend ingore  fixed
   - Survex 3D output is missing the nodes on the end of anonymous
 splay legs [#157]
   - a_blocks_AUT missing semi-colon [#126]

xtherion:
 * add thconfig* to selectable config file list [PR#168]
 * bugs fixed:
   - Windows xtherion window geometry bugfix

loch:
 * bugs fixed:
   - MacOS X compilation [PR#144]
   - multiple minor fixes
   - Linux off-screen rendering bugfix

Best regards,
Therion team
___
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] new Therion 5.5.0

[Benedikt Hallinger]

Thanks for clarifying, i could imagine this is good for version control 
too :)


Am 2020-05-01 23:30, schrieb Olly Betts:

On Fri, May 01, 2020 at 09:22:31PM +0200, Benedikt Hallinger wrote:

what does --reproducible-output exactly do?
i cannot derive this from the thbook. What does reproducible mean?


It means that the output is exactly (bit-for-bit) determined by the
input.  For example, Therion uses pseudo-random numbers for drawing 
some

symbols so we need to seed the random number generator the same way to
get a reproducible output.

For normal Therion use, non-reproducible output probably doesn't matter
(though sometimes you might prefer that the rocks don't move just
because you regenerated the PDF), but it's very useful for getting
Therion packages to build reproducibly because Therion itself is used 
to

generate output for the examples as part of the build.

There's been a move over the last few years to make Free and Open
Source Software build reproducibly - for example, the majority of
packages in Debian now do:

https://tests.reproducible-builds.org/debian/unstable/amd64/stats_pkg_state.png

If you're wondering why that's a good thing, some motivations are
covered here:

https://reproducible-builds.org/

Cheers,
Olly

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

Re: [Therion] North arrow and magnetic declination

[Benedikt Hallinger]

It is map compile time and it shows the declination for the day of map 
compilation:


As i understood, when compiling the map all directions are converted to 
geographic north, because the station positions are georeferenced to the 
coorindates. There, the date of the survey is taken into account to get 
the corrected coordinates based on the magnetic model and the 
location/survey date.


Aligning the map to geographic north and putting out the magnetic north 
is just an info "today the declination is this-and-that degrees".
Aligning the map to magnethic north makes that info crucial to be able 
to calculate geographic north.



Am 2020-05-27 22:28, schrieb Bruce Mutton:

Hi Bill

I played with Dirk's north arrow back in 2018, making my own
adjustments, and came to the conclusion that the magnetic north
reported is that at the date of map compilation.   Looking at my
comments in my metapost I am not absolutely convinced however.
Regardless, the reporting of a magnetic north direction needs to be
accompanied by the date and location to avoid confusion.  Dirk's north
arrow, and my variation, both report the date, so we have that
covered, and Therion uses the 'centre' of the map as the location.

It is somewhat relevant in New Zealand.  The magnetic deviation is
approximately 20 degrees and has varied 2 or 3 degrees over my
lifetime, and it varies by a similar amount across our caving regions.
 There are surveys that span three decades.

The only time I have encountered a problem with plan maps in Therion
related to magnetic deviation is when a recent survey is added, and
the compiling software version pre-dates that survey (geomagnetic
model cuts out prior to the survey date).  In this circumstance
Therion sets the magnetic deviation to zero and does not report the
error, or reports it as something unrelated.

Bruce

From: Therion  On Behalf Of Bill Gee
Sent: Thursday, 28 May 2020 01:51
To: Therion Mail List 
Subject: [Therion] North arrow and magnetic declination

Hello everyone -

I was looking at some of the sample code on the wiki for alternate
north arrows. At least two of them display both geographic north and
magnetic north. Those are northarrow4 and northarrow4a, both by Dirk
Peinelt.

My question is this: What date is used when calculating the offset
angle for the magnetic north arrow?

This is especially relevant for caves that have been surveyed over a
period of years. The declination changes from year to year, and
sometimes more often than that. There are at least four possibilities:

1) The date of the first survey.

2) The date of the most recent survey.

3) A date about half-way between the first and last surveys. This
assumes that the declination change is somewhat linear over time.

4) The date the map is compiled.

Does anyone know which date is used?

For me this is mostly academic. I am just curious! I have never used a
north arrow that shows both geographic and magnetic north. Most of the
maps I make are for caves in Missouri. The magnetic declination is
less than 1 degree. It is almost irrelevant here.

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] LOX: Measure distance from station to surface

[Benedikt Hallinger]

Hello,
i just uploaded an updated version of the 1.0 release, which now contains also 
a Windows .exe binary in the release tar.gz archive.
:)

> Am 31.03.2020 um 12:59 schrieb Benedikt Hallinger :
> 
> Hi there,
> i released version 1.0 of therionsurface2survex 
> (https://github.com/hbeni/therionsurface2survex)
> and now the problem with this is, that the name is not fitting anymore...
> 
> Version 1.0 can:
> - read GDAL ASCII grids directly [1]
> - read therion "surface" blocks
> - write survex .swx files containing the mesh
> - write therion source files containing the mesh (flags surface) [2]
> 
> 
> [1] i niticed that those files do not contain information about the 
> coordinate-system used, so you need to add this manually afterwards. Question 
> to all of you: would you expect an option that the tool adds it itself?
> [2] would be my preferred way because it allows better control about further 
> usage, also integration is more straightforward.
> 
> 
> Am 2020-03-28 1:21, schrieb Benedikt Hallinger:
>> Thanks, but i'm not into python :)
>> Am 2020-03-28 1:18, schrieb Philippe Vernant:
>>> Hi,
>>> There is an easy way to extract coordinates from the therion sql
>>> export. Then using a shell script and GMT could provide the depth of
>>> each point below the surface. I know that there is now a GMT library
>>> under Python, if they have implemented the function in the library,
>>> everything could be wrapped up in a single python script.
>>> Cheers,
>>> Phil
>>>> On 28 Mar 2020, at 00:28, Benedikt Hallinger  wrote:
>>>> cavern had eaten itself, but after pushing ctrl-c in the shell running 
>>>> therion, the 3d  file was written successfully and the output was nice.
>>>> I enhanced the therion wiki a little with a link to the tool.
>>>> Sorry, i have no clue how to cross compile this for windows.
>>>> Am 2020-03-27 23:51, schrieb Benedikt Hallinger:
>>>>> Hi there,
>>>>> i just wrote a small tool to do the conversion from a therion surface
>>>>> mesh into survex format:
>>>>> https://github.com/hbeni/therionsurface2survex
>>>>> It would be nice if some C++ programmers can look over the code as
>>>>> this is my first c++ endeavour.
>>>>> The program basically parses the therion source file and generates
>>>>> *fix commands out of it together with nosurvey-centerline connecting
>>>>> the stations to a mesh.
>>>>> The resulting .swx file then can be put trough survex' cavern program
>>>>> to generate a 3d file of the mesh.
>>>>> That can be easily combined with a 3d file of the cave generated from
>>>>> therion (using the import statements). For ease of use provided a
>>>>> basic example for combining in the readme. A sample to parse a mesh is
>>>>> in the projects example/ folder, however i also tested it positive
>>>>> with the rabbit cave example.
>>>>> With my dataset the calculation seems to take a little longer
>>>>> there are 388.800 fixe stations in the surface mesh giving a 31M
>>>>> swx-file in total.
>>>>> I hope this will finish somtime (running already for 25 minutes) but
>>>>> maybe i overloaded cavern with this.
>>>>> Otherwise i probably need to turn down the grid resolution (currently
>>>>> 10m grid size).
>>>>> Am 2020-03-26 23:23, schrieb Tarquin Wilton-Jones:
>>>>>>> However, my aven does not enable me to avtivate it in the view menu, its
>>>>>>> disabled (greyed out), i assume because i do not have surface data in
>>>>>>> the file?
>>>>>> Sounds like it. It works based on legs that have:
>>>>>> flags surface
>>>>>> 1 2 9.8 123 0
>>>>>> flags not surface
>>>>>> Or if you have used TerrainTool to export it as a grid, it will have
>>>>>> added that for you.
>>>>>> This has been very easy for us in our projects because we either knew
>>>>>> exactly which line to follow on the surface beforehand, or we surveyed
>>>>>> the cave first then surveyed over the surface afterwards, staying above
>>>>>> the passage so we could have a useful measure of the surface above the 
>>>>>> cave.
>>>>>> In more complex caves, I rely on TerrainTool to cover the surface.
>>>>>> Looking forward to being able to use the new more accurate NASADEM so
>>>>>> that the measurements are actually accurate.
>>>> ___
>>>> 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] epsg:3794 - PROJ4 library: -1 (no arguments in initialization list)

[Benedikt Hallinger]

Hi there, we had a similar error a while ago.
Reason was that proj lib was upgraded and therion was not compatible 
with that at the time, but that was fixed already for some time now.


Which therion version are you using?


Am 2020-06-29 23:00, schrieb Rhys Tyers:

Hello,

I'm trying to compile a therion config and am getting the following
error:

therion: error -- PROJ4 library: -1 (no arguments in initialization
list)

The repo and file I'm attempting to compile:

https://github.com/tr1813/migresurvey/blob/master/data/_config/overview/system_migovec.thconfig

This works for for someone on OSX and another on Windows but not for
me on Ubuntu 20.04. I tried searching for the error but there wasn't
anything enlightening.

It compiles if I comment out "epsg:3794" so I'm guessing perhaps my
version of the proj library does not have this coordinate system?
Could I build a more up to date version?

Can anyone point me in the right direction?

Thanks,
Rhys
___
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] Command extend

[Benedikt Hallinger]

Yes, you are right.

> Am 06.09.2020 um 12:58 schrieb Markus Boldt :
> 
> 
> Hi all,
> the command „extend“ comes in the loop centerline / endcenterline in the 
> TH-File – right?
> Best
> Markus
>  
> ___
> 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] maps off solves unexpected scrap stacking order where no maps are defined

[Benedikt Hallinger]

Wow-that surely is not easy to figure out i think.
But at least you have a dataset to reproduce this!

My naive guess is that when no Maps are defined and maps-off Not in effect, 
that sometimes the order of definition plays a role too?

Btw, i love maps-off and that was a feature i was wanting a long time. When i 
finally requested it, it got quickly implemented, and i am very grateful for 
that!

> Am 27.09.2020 um 10:28 schrieb Bruce Mutton :
> 
> 
> This is just a FYI in case anyone is interested.
> A problem solved, but a mystery not solved.
>  
> On and off through 2019 there were discussions about how to predict or debug 
> scrap stacking order.
> This message by Tarquin covers the expected behaviour fairly comprehensively. 
>  https://www.mail-archive.com/therion@speleo.sk/msg07925.html
>  
> That is all very well, and 99% of the time my projects stack scraps the way I 
> expect.  Except that I have one large project where lower passage scraps 
> stack on top of upper level scraps, in a few locations only, in the scenario 
> where no maps defined whatsoever (with the intention that scraps therefore 
> stack according to average altitude).  Other scenarios using the same source 
> data, where maps are defined and selected, all plot as expected according to 
> the map structures.  But for large overview maps I need to plot all scraps 
> without any map structure, and I’d like them to stack correctly.
>  
> The offending scraps were drawn many years ago, and were all much longer and 
> encompassing much greater passage height variations than I would adopt these 
> days.  I just assumed that the average heights that Therion calculated were 
> somehow not collated in the stacking order that I expected.  Anyway I 
> eventually found the time to check the scrap and heights reported in 
> therion.log.  To my slight surprise I found that in fact the average heights 
> that Therion calculated were in exactly the order I expected.  So why was 
> Therion not stacking the scraps in the expected order?  My anticipated 
> solution of breaking the scraps into pieces to make them behave properly no 
> longer seemed likely to make any difference.
>  
> Since it was implemented, I have been making use of the ‘maps off’ to disable 
> previews and offsets, as a more refined way of achieving a particular output 
> than just ‘not defining’ any maps in a particular thconfig.
> https://www.mail-archive.com/therion@speleo.sk/msg07571.html
>  
> In desperation I thought I’d try adding ‘maps off’ to the thconfig above, 
> where no maps were defined.  It should, I expected, make no difference at all.
> And in one easy step, all of the scraps now plot in the correct stacking 
> order!
> So why does ‘maps off’ make scraps plot in the correct order when there are 
> no maps defined?
>  
> 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] Therion uses wrong declination for surveys 'in the future'

[Benedikt Hallinger]

Falling hard with an appropriate error message would be good: it’s obvious then 
that the available data is invalid, and why. And the message should include the 
hint to the declination command to fix this.

> Am 05.10.2020 um 20:40 schrieb Bruce Mutton :
> 
> 
> Hi Matt
> I think these issues have been raised previously.
> The error message for dates later than those included in the Therion model 
> was inaccurate, as you point out.  I ‘think’ that in recent versions this may 
> have been replaced with a more meaningful message.
>  
> And then the question of whether it is better for Therion to extrapolate 
> future declinations, or set them to zero?
> Shades of failing gracefully or abruptly, I guess.  I could take either side, 
> but I think my preference would be for Therion to set declinations beyond 
> those modelled to zero.  This way it is more likely that users will detect 
> the problem (as you have), and either upgrade to a more recent version of 
> Therion, or manually set the declination for each affected survey, using the 
> declination statement.
>  
> Bruce
>  
> From: Therion  On Behalf Of Matthias Keller
> Sent: Monday, 5 October 2020 21:40
> To: therion@speleo.sk
> Subject: [Therion] Therion uses wrong declination for surveys 'in the future'
>  
> Hi
> 
> I just had the following problem: A current survey (with survey dates 
> 2020.06.27 and 2020.09.19) was compiled using Therion 5.4.4 (from 2019). I 
> got the following warning during compilation:
> 
> warning -- unable to determine magnetic declination for undated surveys
> 
> However, firstly: this warning is wrong, as all surveys are dated correctly.
> 
> However I was stunned by some large loop errors in the newest surveys (>60cm 
> in only 10 legs). Then, just by some other impulse I updated therion to 5.5.1 
> and suddenly, those errors went down to <10cm and the generated models looked 
> differently. Also, the above error message was not present anymore.
> 
> So i experimented and just added "declination 3 deg" to the two new surveys 
> (from June and September) and suddenly, the output generated by 5.4.4 looked 
> pretty much as the one from 5.5.1
> 
> It appears that, when therion cannot determine the magnetic declination of a 
> survey (with valid date!), it finally just assumes 0. The problem seems to 
> be, that the declination data stored in 5.4.4 didn't let therion determine a 
> possible declination for 2020.06.27 and 2020.09.19 so it just assumed 0. I 
> would have expected therion to at least consider the latest known declination 
> which would result to around 3° (in Switzerland).
> 
> Is this a known issue? It just means that whenever you open a survey in some 
> version being 'too old', it will kill your plans...
> 
> BTW, Therion 5.4.4 seems to have *some* data for 2020 at least, as it seems:
> 
> geomag declinations (deg):
>   2019.1.1  2.9201
>   2020.1.1  3.0503
> 
> but the only surveys from 2020 are the ones from June 2020 and September 
> 2020, and both were assigned a declination of 0° instead of about 3°. I can 
> verify that by adding the declination parameter with "0 deg" to those surveys 
> and the output is identical to the one without this parameter.
> 
> Thanks
> 
> Matt
> 
> ___
> 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] Therion uses wrong declination for surveys 'in the future'

[Benedikt Hallinger]

Couldn't this be just some data file in the therion installation 
directory?
This could be replaced by any means (like copying yourself, for instance 
and fallback). An online updater would be cool, tough.


Am 2020-10-06 3:34, schrieb Wookey:

On 2020-10-05 23:54 +0200, Matthias Keller wrote:

   Exactly this.

   Unfortunately, even the current Therion 5.5.1 doesn't have a more
   meaningful (and correct) message than "unable to determine magnetic
   declination for undated surveys"


I thought this might be a proj confusing error message, but it is 
therion's.



   I would propose:

1. If a survey is dated but is newer than available correction 
data,

   build should fail with a message like:
   "Error determining magnetic declination for survey  with 
date
   . Please specify the declination explicitly using for 
example

   'declination 3 deg'"
   instead of the (completely wrong)
   "unable to determine magnetic declination for undated surveys"
2. If at least one of the imported (and thus joined) surveys has 
magnetic
   data but at least one does not (or cannot be determined), an 
error
   shall be thrown as well, because mixing corrected and 
uncorrected
   surveys is just plain wrong and causes a lot of confusion (as 
it has
   happened to me). The same error message shall be displayed and 
the

   build fails.


This does seem reasonable behaviour. And I agree the error message is
wrongly worded or issued here.

I just had a look at the code that produces this error but it's rather
confusing. A bitmap is used to record what declination data was used
and if bits 1 and 3 are set you get the above error. I think bit 2 is
'used igrf model to get delination' and bit 3 is 'used defined
declination', and bit 3 is 'didn't use any', but I'm not sure and I
don't see why two bits would be set. I'll leave it to Martin/Stacho to
work out how the logic should run here.



   Is this the right place to request that or shall I open an issue on
   github?


I think this list is the canonical place to discuss such things.

   I really find this issue pressing, because I just cannot imagine, 
that
   this doesn't happen to everyone here from time to time - keeping 
therion
   up to date is not the same cycle as adding new surveys, and 
suddenly you

   fall out of the prediction data.


This is really an issue of the geomag model. It does work some way
into the future, but there is a cutoff. Looks like it does 10 years
into the future as the latest data in the therion source (igrf12) ends
in 2015 and the previos igrf11 (used in therion 5.4.4) ended in
2010. igrf13 (with data to 2020) was released in December 2019
https://www.ngdc.noaa.gov/IAGA/vmod/coeffs/igrf13coeffs.txt

So clearly this will arise anytime you have survey data 10 years newer
than the model in the therion you are running, which as they are only
released every 5 years and therion may take a year or two to update
and the installed one may be a few years old, is quite likely to
happen from time to time, especially in years ending with 0 or 5.


   btw, is there any way to update the data in an existing therion
   installation? Or is the only way the update to a (hopefully 
existing) new

   version?


There could be - the files are available online so therion could use
the currently-installed version of the file. But currently the igrf
coefficients file is compiled-in as thgeomagdata.h This means therion
can always find the data, but it's not updateable without
recompiling. I could fix this for linux relatively easily, but it's
harder on Windows. (and it was making things work on windows that
caused therion to compile-in all the stuff it needed from subsystems,
many years ago). Ideally it would compile one in but have the ability
to read a newer file if provided. But then someone has to write a
parser. We could also try a little harder not to get 10 years behind
again. (5.4.4 was released in May 2019 with a model that expired in
mid 2020, when the 2025 model had been available since 2015 (and was
included with the next therion release in May 2020). Not sure why the
update was not to 2030 as that was available from Dec 2019.)


Wookey
___
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] Survex (loop closure) related fixes

[Benedikt Hallinger]

I tried to compile the model of the Hirlatz cave with it and it looks 
good, from a big picture view.

The passages shifted sometimes slightly, as expected.

When trying to compile a specific plan map view PDF i get an error about 
UTF8. The compile runs fine with release-therion 5.5.1, however!

(i don't know if this is related)


therion 5.5.2+4683494 (2020-10-13)
cavern - Survex 1.2.42
initialization file: therion.ini
reading ... done
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) 
(preloaded format=pdftex)

 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT 
INSTALLED
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian) 
(preloaded format=pdftex)

 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ... NOT 
INSTALLED
configuration file: 
../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/plan.DOP.map.thconfig

reading ... done
reading source files ... done
preprocessing database ... done
./therion: warning -- year 1951 magnetic declination used for undated 
surveys

undated surveys:
155.Wilder_Westen.Hirlatzhoehle
323.Westen.Hirlatzhoehle
326.Hochdonnerbach.Hirlatzhoehle
scanning centreline tree ... done
searching for centerline loops ... done
calculating station coordinates ... done
average loop error: 1.98%
processing survey data ... done
calculating basic statistics ... done
processing extended elevation ... done
processing references ... done
selecting export objects ... done
processing projection plan ... done
average distortion: 3.21%
writing 
../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/../Hirlatz.plan.DOP.map.pdf 
...

./therion: error -- Invalid utf-8 string!



Am 2020-10-14 10:02, schrieb Tarquin Wilton-Jones via Therion:

Hi folks,

Stacho fixed these "when using Survex loop closure" bugs in yesterday's
development release:

https://github.com/therion/therion/issues/269 Therion miscalculates
fixes in multiple centreline blocks when using Survex loop closure

https://github.com/therion/therion/issues/270 Therion cannot have
exactly 2 fixes for a station when using Survex loop closure

And this Survex compatibility bug:

https://github.com/therion/therion/issues/263 Scale value should 
default

to 1 when omitted from "calibrate" commands

I have checked and verified the fixes, and my surveys still look right.
But could someone with a bigger dataset check that it didn't break
anything else when using Survex loop closures. That particular fix 
looks
like the kind that could create regressions. It only improved things 
for

me though :)

Yes, your cave entrance locations will change if you ever ran into #269
without realising - they are supposed to. And yes, you might find some
parts of the cave change size if you ever hit the calibrate statement 
bug.


Cheers,

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

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

Re: [Therion] Survex (loop closure) related fixes

[Benedikt Hallinger]

I experimented a little bit more.

In the thconfig file I set some header data.
statistics explo off
statistics topo  off
statistics carto off
statistics copyright all

If i comment out the line
#statistics carto off
the compilation works again (then showing the people of course).
The same is true with "statistics carto all".

Why does turning off the carto yield invalid UTF8 data?




Am 2020-10-14 10:38, schrieb Benedikt Hallinger:

I tried to compile the model of the Hirlatz cave with it and it looks
good, from a big picture view.
The passages shifted sometimes slightly, as expected.

When trying to compile a specific plan map view PDF i get an error
about UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


therion 5.5.2+4683494 (2020-10-13)
cavern - Survex 1.2.42
initialization file: therion.ini
reading ... done
This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT 
INSTALLED

This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020/Debian)
(preloaded format=pdftex)
 restricted \write18 enabled.
entering extended mode
(./fonttest.tex
checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ...
NOT INSTALLED
configuration file:
../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/plan.DOP.map.thconfig
reading ... done
reading source files ... done
preprocessing database ... done
./therion: warning -- year 1951 magnetic declination used for undated 
surveys

undated surveys:
155.Wilder_Westen.Hirlatzhoehle
323.Westen.Hirlatzhoehle
326.Hochdonnerbach.Hirlatzhoehle
scanning centreline tree ... done
searching for centerline loops ... done
calculating station coordinates ... done
average loop error: 1.98%
processing survey data ... done
calculating basic statistics ... done
processing extended elevation ... done
processing references ... done
selecting export objects ... done
processing projection plan ... done
average distortion: 3.21%
writing
../../Dokumente/cave/HVHO/svn/Hirlatzhoehle/therion/../Hirlatz.plan.DOP.map.pdf
...
./therion: error -- Invalid utf-8 string!



Am 2020-10-14 10:02, schrieb Tarquin Wilton-Jones via Therion:

Hi folks,

Stacho fixed these "when using Survex loop closure" bugs in 
yesterday's

development release:

https://github.com/therion/therion/issues/269 Therion miscalculates
fixes in multiple centreline blocks when using Survex loop closure

https://github.com/therion/therion/issues/270 Therion cannot have
exactly 2 fixes for a station when using Survex loop closure

And this Survex compatibility bug:

https://github.com/therion/therion/issues/263 Scale value should 
default

to 1 when omitted from "calibrate" commands

I have checked and verified the fixes, and my surveys still look 
right.

But could someone with a bigger dataset check that it didn't break
anything else when using Survex loop closures. That particular fix 
looks
like the kind that could create regressions. It only improved things 
for

me though :)

Yes, your cave entrance locations will change if you ever ran into 
#269

without realising - they are supposed to. And yes, you might find some
parts of the cave change size if you ever hit the calibrate statement 
bug.


Cheers,

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

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

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

Re: [Therion] Survex (loop closure) related fixes

[Benedikt Hallinger]

Hey Martin,
thanks for responding.
The exact same dataset compiles well with 5.5.1.
As far as i know, no special characters are used here.

As its rather huge, and i have no idea how to reduce the problem. It 
surely must be somewhere in the .th2 files "author", since that is 
probably the only place where this gets gathered from, isn't it?


I enhanced the thtexfonts.cxx on line 247 to print out the offending 
string (if you want i make a PR for that) that now shows something 
looking like garbage:

  ./therion: error -- Invalid utf-8 string! (offending string: 'P]���U')


I probably need to wade trough the data manually.


Am 2020-10-14 20:04, schrieb Martin Budaj:

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger
 wrote:


When trying to compile a specific plan map view PDF i get an error
about
UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


Hi, there was no change in the processing of utf-8 strings between
5.5.1 and 5.5.2. Could you check the same data set is used by those
versions?

You should get this error if you use a unicode character outside of
the BMP (see
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

M.
___
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] Survex (loop closure) related fixes

[Benedikt Hallinger]

Hello all, thanks for all the hints.

What about multifile search for”P]” in text files? It is quite strange 
combination of characters and they are part of ASCII set.
I had that in mind, but i don't think its the problem here. If it would, 
5.5.1 should fail too...



What about multifile search for”P]”
With every run the string changes. I have seen that before with C++ 
code, that was when i tried to put out a memory adress instead of the 
actual string. Maybe the passed string is already memory garbage at this 
point?



QA folks start grinning. Generic instructions below:
Uh, then i will have a grey beard finishing this. We talk about 130km of 
cave in way over 600 files here.



I also commented the the error line in the source code that bails out 
here, and everything (therion, but also the map) compiles just fine as 
it should. Also the cartographers names print nicely.



Nonewithstanding i had a idea i went trough. A part of the cave is done 
using an inkscape plugin, which converts the svg data into th2 files. 
That usually goes good, and did to therion 5.5.1.


I also was able to isolate a scrap line causing the problem (excerpt 
attached).
However, if i craft a very simple thconfig, it compiles fine; and the 
isolated line looks not suspicious at all for me!


The problem occurs only if i try to render the whole cave (in a very big 
scale 1:5000); if i craft a very simple thconfig and source only the 
passage th file, it goes OK.
Could it be that somewhere some string buffer runs over when gathering 
all the cartographers?
or that something else messes stuff up memory-wise, because the dataset 
is so big already?


I'm out of ideas.


Am 2020-10-14 20:34, schrieb Benedikt Hallinger:

Hey Martin,
thanks for responding.
The exact same dataset compiles well with 5.5.1.
As far as i know, no special characters are used here.

As its rather huge, and i have no idea how to reduce the problem. It
surely must be somewhere in the .th2 files "author", since that is
probably the only place where this gets gathered from, isn't it?

I enhanced the thtexfonts.cxx on line 247 to print out the offending
string (if you want i make a PR for that) that now shows something
looking like garbage:
  ./therion: error -- Invalid utf-8 string! (offending string: 
'P]���U')



I probably need to wade trough the data manually.


Am 2020-10-14 20:04, schrieb Martin Budaj:

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger
 wrote:


When trying to compile a specific plan map view PDF i get an error
about
UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


Hi, there was no change in the processing of utf-8 strings between
5.5.1 and 5.5.2. Could you check the same data set is used by those
versions?

You should get this error if you use a unicode character outside of
the BMP (see
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

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

___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therionencoding  utf-8
##XTHERION## xth_me_area_adjust 0 0 1432.044359 1455.405165
##XTHERION## xth_me_area_zoom_to 100


# THIS HAS OFFENDING CHARACTERS:
scrap 237-plan1.3 -scale [0 0 90 0 0 0 500 0 inch] -projection plan -author 
2020.03.22 "Foo Bar"

# THIS DOES WORK:
#scrap 237-plan1.3 -scale [0 0 90 0 0 0 500 0 inch] -projection plan


line wall -subtype debris
  698.1766 498.9593
  698.9107 510.1675 698.4598 521.3301 693.7274 532.328
endline

point 1350.6446 56.0884 u:mappe -attr text 253
point 1017.9026 158.2627 passage-height -value 16
point 1264.195 71.1864 passage-height -value 12
point 905.4025 90.8898 passage-height -value 4
point 674.3731 473.9263 passage-height -value 1.1
point 956.171 212.2135 continuation -text [Schlot]
point 1058.3538 248.9031 continuation -text [Schlot]
point 742.8787 178.1511 altitude -align r
point 1231.4015 34.8879 altitude -align l
point 1103.6943 242.364 altitude -align r
point 710.4934 492.3343 altitude -align r
point 1353.6321 105.8449 station-name -scale xs
point 1237.7953 57.0631 station-name -scale xs
point 998.0274 167.6244 station-name -scale xs
point 676.8842 539.3195 station-name -scale xs
point 700.5987 294.6161 station-name -scale xs
point 729.1645 393.9866 label -text [Klamm] -align r -scale s
line border 
  1349.3419 95.0398
  1350.8979 92.9743 1351.8803 90.4498 1351.3281 86.6977
endline

point 1158.2586 159.375 debris -orientation 336.025125
point 967.0364 196.1817 height -value "+"
point 1065.6624 231.3641 height -value "+"
point 776.7726 142.1957 gradient -scale xs -orientation 258.18624432
line border -close on -id 237-plan1.3_debris_1 -visibility off
  684.8291 528.1967

Re: [Therion] Survex (loop closure) related fixes

[Benedikt Hallinger]

I sent Martin a dataset to investigate.
Hopefully he can spot something...


Am 2020-10-14 21:40, schrieb Benedikt Hallinger:

Hello all, thanks for all the hints.

What about multifile search for”P]” in text files? It is quite strange 
combination of characters and they are part of ASCII set.

I had that in mind, but i don't think its the problem here. If it
would, 5.5.1 should fail too...


What about multifile search for”P]”

With every run the string changes. I have seen that before with C++
code, that was when i tried to put out a memory adress instead of the
actual string. Maybe the passed string is already memory garbage at
this point?


QA folks start grinning. Generic instructions below:

Uh, then i will have a grey beard finishing this. We talk about 130km
of cave in way over 600 files here.


I also commented the the error line in the source code that bails out
here, and everything (therion, but also the map) compiles just fine as
it should. Also the cartographers names print nicely.


Nonewithstanding i had a idea i went trough. A part of the cave is
done using an inkscape plugin, which converts the svg data into th2
files. That usually goes good, and did to therion 5.5.1.

I also was able to isolate a scrap line causing the problem (excerpt 
attached).

However, if i craft a very simple thconfig, it compiles fine; and the
isolated line looks not suspicious at all for me!

The problem occurs only if i try to render the whole cave (in a very
big scale 1:5000); if i craft a very simple thconfig and source only
the passage th file, it goes OK.
Could it be that somewhere some string buffer runs over when gathering
all the cartographers?
or that something else messes stuff up memory-wise, because the
dataset is so big already?

I'm out of ideas.


Am 2020-10-14 20:34, schrieb Benedikt Hallinger:

Hey Martin,
thanks for responding.
The exact same dataset compiles well with 5.5.1.
As far as i know, no special characters are used here.

As its rather huge, and i have no idea how to reduce the problem. It
surely must be somewhere in the .th2 files "author", since that is
probably the only place where this gets gathered from, isn't it?

I enhanced the thtexfonts.cxx on line 247 to print out the offending
string (if you want i make a PR for that) that now shows something
looking like garbage:
  ./therion: error -- Invalid utf-8 string! (offending string: 
'P]���U')



I probably need to wade trough the data manually.


Am 2020-10-14 20:04, schrieb Martin Budaj:

On Wed, Oct 14, 2020 at 10:38 AM Benedikt Hallinger
 wrote:


When trying to compile a specific plan map view PDF i get an error
about
UTF8. The compile runs fine with release-therion 5.5.1, however!
(i don't know if this is related)


Hi, there was no change in the processing of utf-8 strings between
5.5.1 and 5.5.2. Could you check the same data set is used by those
versions?

You should get this error if you use a unicode character outside of
the BMP (see
https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane).
Do you such exotic characters?

Sending a minimal data sample would be helpful.

M.
___
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] Survex (loop closure) related fixes

[Benedikt Hallinger]

OK, now i got something.

Guess what - one of about 5 compiles runs trough.
This leads me to think that there is a race condition or something else 
somewhere, overwriting memory of the to-be-checked string.
I'm pretty sure now that this is not a problem with the dataset per se, 
but some memory issue of the compiled therion program.


The following pattern resulted in several runs with 5.5.2 (n=failed, 
y=ok):

nnnynnynnynynynynnny




Am 2020-10-14 21:53, schrieb Martin Sluka via Therion:

I use BBEdit on MacOSX and it has all features you mentioned.

Martin

14. 10. 2020 v 21:17, Tarquin Wilton-Jones via Therion 
:


On 14/10/2020 20:08, Martin Sluka via Therion wrote:
What about multifile search for”P]” in text files? It is quite 
strange combination of characters and they are part of ASCII set.


If you have an editor that is working in the same character set as
Therion, that could work. Definitely worth a try.

I suspect the fault relates to character set conversion though. Such 
as

an editor working in 8859-1, and Therion trying to interpret it in
UTF-8. Most basic text editors don't let you control character set, 
and

just work in the system default (Windows-1252 on English-based Windows
systems). Even if they do, most users are not aware of what it all
means, and just stick with the default.
___
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] Survex (loop closure) related fixes

[Benedikt Hallinger]

Hi there,
i performed a git bisect (the very first in my lifetime, and that is 
really a nice and easy tool to search such things!!!).


The commits at and before c7d41d9 compiled the cave sucessfully 10 of 10 
times.


1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit
commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8
Author: mbudaj 
Date:   Wed Aug 19 07:25:53 2020 +0200

dynamically load EPSG/ESRI labels in Proj>=6

https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8

This compiles unstable like described before.



Am 2020-10-14 22:32, schrieb Wookey:

On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote:

OK, now i got something.

Guess what - one of about 5 compiles runs trough.
This leads me to think that there is a race condition or something 
else

somewhere, overwriting memory of the to-be-checked string.
I'm pretty sure now that this is not a problem with the dataset per 
se, but

some memory issue of the compiled therion program.

The following pattern resulted in several runs with 5.5.2 (n=failed, 
y=ok):

nnnynnynnynynynynnny


Oh dear. This could be fun to track down

Better check 5.5.1 always works, not just more often. But if it does
then careful examination of what changed is in order. Maybe send some
others the dataset to see who can reproduce (windows/linux/macOS)?

Wookey
___
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] Survex (loop closure) related fixes

[Benedikt Hallinger]

I just made a new issue ticket: 
https://github.com/therion/therion/issues/278



Am 2020-10-14 22:53, schrieb Benedikt Hallinger:

Hi there,
i performed a git bisect (the very first in my lifetime, and that is
really a nice and easy tool to search such things!!!).

The commits at and before c7d41d9 compiled the cave sucessfully 10 of 
10 times.


1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8 is the first bad commit
commit 1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8
Author: mbudaj 
Date:   Wed Aug 19 07:25:53 2020 +0200

dynamically load EPSG/ESRI labels in Proj>=6

https://github.com/therion/therion/commit/1c1fcf14e4eaf6e0bb89da513702ad9b89204ed8

This compiles unstable like described before.



Am 2020-10-14 22:32, schrieb Wookey:

On 2020-10-14 22:05 +0200, Benedikt Hallinger wrote:

OK, now i got something.

Guess what - one of about 5 compiles runs trough.
This leads me to think that there is a race condition or something 
else

somewhere, overwriting memory of the to-be-checked string.
I'm pretty sure now that this is not a problem with the dataset per 
se, but

some memory issue of the compiled therion program.

The following pattern resulted in several runs with 5.5.2 (n=failed, 
y=ok):

nnnynnynnynynynynnny


Oh dear. This could be fun to track down

Better check 5.5.1 always works, not just more often. But if it does
then careful examination of what changed is in order. Maybe send some
others the dataset to see who can reproduce (windows/linux/macOS)?

Wookey
___
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] Creating PDF/A map files

[Benedikt Hallinger]

Hi,
instalation of veraPDF was straightforward.

For a test run i get this:
failedChecks="1846">

This will be a long road.

But your idea is quite good, as it will preserve valuable work.
OTOH the PDFs are just results, what is really valuable would be the 
source files. And they are pretty good to archive already, as they are 
just text files!
Therion should be fine to run a long time into the future, hopefully. 
And as its OpenSource, there are no constraints whatsoever to fix bugs 
in the future to make it work again...



Am 2020-10-22 15:17, schrieb Bill Gee:

Hello everyone -

I propose a new feature for Therion. This will probably take some
work, and I am sure there will be discussion about how to implement
it.

It seems to me that the maps we produce with Therion are likely going
to be stored for a very long time, perhaps running into multiple tens
of years. As we all know, computer technology over that amount of time
will change drastically. Just think about the contrast in both
hardware and software in the last 25 years - from Windows 95 running
on 486dx processors to Linux and Windows 10 running on i7 and i9
processors.

I think we have some obligation to make sure the cave maps we generate
are still usable many years from now. Saving them in PDF format is a
large - but incomplete - step in that direction.

The new feature I propose is to modify the PDF creation code so that
it produces files that are PDF/A version 1b (or possibly version 2)
compliant.

https://en.wikipedia.org/wiki/PDF/A [1]

I have checked all of the PDF files I created in Therion, and none of
them are flagged as PDF/A compliant. It is possible that they are, in
fact, compliant and simply do not have the necessary flag. The experts
can check that against the PDF/A specifications.

Existing PDF documents can be checked for PDF/A compliance with a
command-line tool called "verapdf". The web site for that tool is

https://openpreservation.org/products/verapdf/ [2]

It is possible to use GhostScript to transform an existing PDF into a
PDF/A file. The command line is daunting.

https://www.mcbsys.com/blog/2018/10/batch-convert-pdf-to-pdf-a-2018-edition/
[3]

I tried the GhostScript conversion on one of my Therion maps.
Immediately at startup it produced this message three times:

"GPL Ghostscript 9.53.3: UTF16BE text string detected in DOCINFO
cannot be represented in XMP for PDF/A1, reverting to normal PDF
output"

The process continued running and took about 10 minutes. The resulting
file failed verapdf analysis. It also increased the file size from 4.3
megabytes to over 52 megabytes! The output file displayed correctly in
Okular.

I do not have any idea how Therion produces PDF files. It probably
uses some combination of TeX and GhostScript to get it done. The new
feature may be as simple as adding some additional parameters to the
command lines that call the external programs.

Let the discussion begin! :-)

--

Bill Gee



Links:
--
[1] https://en.wikipedia.org/wiki/PDF/A
[2] https://openpreservation.org/products/verapdf/
[3] 
https://www.mcbsys.com/blog/2018/10/batch-convert-pdf-to-pdf-a-2018-edition/

___
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] Symbol assign

[Benedikt Hallinger]

No idea, but i second the reques - that would be utterly useful for me 
too!


Am 2020-11-02 8:26, schrieb Pavel Herich:

Hi,
when exporting maps to a large scale, I´d like to assign wall:debris,
wall:presumed etc. to just "wall". "Symbol-assign line wall:debris
wall:bedrock" in config file doesn´t work, any idea?
Thank you
Pavel
___
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] Symbol assign - use metapost def instead

[Benedikt Hallinger]

I just did that with the AUT symbol set and it looks good:

--- snip 
layout 
...

code metapost
def l_wall_underlying_UIS (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;
def l_wall_presumed_UIS (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_pit_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_sand_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_clay_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_pebbles_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_debris_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_blocks_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_ice_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_underlying_AUT (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;
def l_wall_overlying_AUT (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;
def l_wall_moonmilk_AUT (expr Path) = l_wall_bedrock_UIS 
(Path); enddef;
def l_wall_flowstone_AUT (expr Path) = 
l_wall_bedrock_UIS (Path); enddef;

endcode

...
endlayout
--- snap --


Am 2020-11-02 9:25, schrieb Bruce Mutton:

I have done exactly that, but with conjectural water to be shown with
the permanent water symbol.
Need to use a little metapost in your layout...

  #replace conjectural waterflow symbol with permanent symbol to
improve visibility
code metapost
def l_waterflow_conjectural (expr Path) =
  l_waterflow_permanent_UIS (Path);
enddef;
endcode

You need to do a similar thing with the definition of your debris and
presumed wall lines to show instead as bedrock.
Bruce

-Original Message-
From: Therion  On Behalf Of Pavel Herich
Sent: Monday, 2 November 2020 20:27
To: List for Therion users 
Subject: [Therion] Symbol assign

Hi,
when exporting maps to a large scale, I´d like to assign wall:debris,
wall:presumed etc. to just "wall". "Symbol-assign line wall:debris
wall:bedrock" in config file doesn´t work, any idea?
Thank you
Pavel
___
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] Connection of Really straight mine level to surveyed passage

[Benedikt Hallinger]

Another option would be to get the coordinates of the linking mine station and 
fixing it, and just giving that station a „perfect“ Standards deviation (isn’t 
that default if not given?)

> Am 14.11.2020 um 21:29 schrieb Ben Cooper :
> 
> 
> Hi Alistair
> I would definitely link all the survey centrelines. The implication is that 
> you have some errors in the survey, but you know that the straight mine level 
> needs to be straight so the error isn’t there. One thing you could try is to 
> set the SD for the level to be very low, and the SD for the rest of the cave 
> to be quite high. When Therion distributes the error, most of this should go 
> to the survey sections either the highest SD, and the level should be less 
> distorted. 
> Best regards 
> Ben
> 
> 
> Sent from my iPhone
> 
>>> On 14 Nov 2020, at 11:49, alastair gott  wrote:
>>> 
>> 
>> HI Therion people,
>> 
>> I'm helping with a project we've got a cave/mine system with a really 
>> straight mine level for one of the entrances, which we have the centreline 
>> data for (but no sketches to show where the points are).
>> 
>> When the system was joined up together with all the entrances there was a 
>> kink in the mine level. so to counteract this, I removed some of the unknown 
>> survey points in the centre of the level and hung the survey on some points 
>> at the beginning and end of the level.
>> 
>> I now want to add in a section of cave in the centre of the level. I have 
>> connected this quite well in a map at a lower level with just the one 
>> entrance coordinates in it, but when I run the full map with all the 
>> entrances in, the model then tries to remove the loop error by doing it's 
>> statisical wizardry.
>> 
>> Unfortunately in doing so, it shifts the start of the level (the entrance) 
>> to the east. and then leaves the section of cave out unconnected.
>> 
>> If anyone can help, then the config for the full system is here: 
>> http://www.cave-registry.org.uk/svn/PeakDistrict/Castleton/peak_speedwell_model/
>> 
>> This is what I get:
>> 
>> 
>> 
>> 
>> the config for the one entrance coordinate is here: 
>> http://www.cave-registry.org.uk/svn/PeakDistrict/Castleton/peak_speedwell_model/speedwell_mine/Speedwell_mine_thconfig.thc
>> 
>> and these are the two selects if you want to run it at the lower level:
>> select bottomless_pit.speedwell_mine
>> select oakden_level.speedwell_mine
>> This is what I want:
>> 
>> 
>> 
>> 
>> 
>> If I add in a survey point to hook it to, then I get this:
>> 
>> 
>> 
>> Rather than this:
>> 
>> 
>> 
>> Adding in more survey points further down the passage to the south only 
>> increases the amount of distortion in a small space of passage. as there are 
>> three loop closures at the bottom of the picture [just below the red circle) 
>> which the model is running (i've just not included the maps on the drawing 
>> for clarity).
>> 
>> 
>> 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
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Colorizing sections of centerline

[Benedikt Hallinger]

No idea, but i usually just use the generated .3d file and aven at this stage.
Aven can also generate screenshots for printing, and can color the centerline 
based on various metrics.

> Am 15.11.2020 um 12:48 schrieb Alvaro Aguilera :
> 
> Hello everyone,
> 
> is there a way to change the color of different sections of the centerline?
> 
> I'm at the stickmap-stage of the survey and it would be really helpful to put 
> some colors to it.
> 
> Regards
> Alvaro
> ___
> 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] Vertical scalebar created by Juraj Halama added to wiki

[Benedikt Hallinger]

Cool, do you have a link? :)

Am 2020-11-26 11:55, schrieb Martin Sluka via Therion:

Vertical scalebar created by Juraj Halama added to wiki

Martin Sluka
___
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] FYI Therion explorer name and explored length counting insight

[Benedikt Hallinger]

Thank you very much for sharing!

> Am 29.11.2020 um 06:15 schrieb Bruce Mutton :
> 
> 
> This is just an ‘I should have known better’ story, in case you are 
> interested…
>  
> Learnings about map output statistics (that are or probably should have been 
> self-evident):
> This is for a cave where some plan scraps were drawn on the original 
> centreline and were retained in the final map, when the entire original 
> survey was made duplicate due to a subsequent more comprehensive survey that 
> was flagged ‘not-duplicate’. For the extended elevation scraps, these were 
> all drawn on the subsequent ‘not-duplicate’ survey.
> If a whole centreline is made ‘flags duplicate’ then the explorers names 
> appear in the list, but not the length that they explored (it is shown as 
> zero).  You must (also) add the explorers to the corresponding 
> ‘not-duplicated’ centreline to have their explored length credited!
> Only the statistics for the centrelines that are (partly) included in scraps 
> that are output are presented.
>  
> For this plan map, where the duplicated centrelines are actually the ones for 
> which the scraps are exported, the ‘not-duplicate’ centrelines did not have 
> the explorer’s names entered (repeated) and so their names are recorded, but 
> their survey length is not.  Lesson: Always record the original explorers in 
> subsequent survey centrelines.  This behaviour is nice because it alerts the 
> author to a problem with their data entry.
> 
>  
> For this extended map, where the ‘not-duplicate’ surveys have scraps 
> exported, but the duplicate surveys do not, the ‘duplicate’ explorers names 
> are not presented.  This is appropriate behaviour.
> But why is there a surveyor whose name appears with a zero length?  I think 
> it is because, for the entire ‘not-duplicate’ survey, I only contributed to 
> one survey leg (and it is in its very own centreline) and this leg is a 
> surface leg connecting the subsequent ‘not-duplicate’ survey to the original 
> ‘duplicate’ survey.  So my name is recorded as a surveyor, but I have no 
> ‘cave length’ and Therion records zero.  Possibly this is not ideal 
> behaviour, but it would seem inconsistent to change it.
> 
> Here is part of the html survey-list for the cave, with the statistics 
> discussed above highlighted.
> 
>  
> I then thought that if I associated the cave survey with the plan and the 
> elevation maps,
> 
> the statistics might have been better (a feature that I was involved in 
> requesting if I recall correctly).  They are.
> For the plan, there is no change (I still need to add the original explorers 
> to the ‘not-duplicate’ centrelines).
> 
>  
> And for the extended elevation, the duplicate zero length explorers names are 
> brought in, as have the surveyors for the centrelines for which there are no 
> scraps.  It matches the plan statistics.  Perfect (once I fix my centreline 
> metadata as mentioned above).
> 
>  
> 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] Italian translation update

[Benedikt Hallinger]

That is a good way to go, it's what i always do.

You can fork it via githubs website and then clone that locally.
When you create and push your branch to _your_ repo, github offers an 
option at your forks main site to create such a pull request in the 
therion repo.



Am 2020-12-17 0:09, schrieb Rodrigo Severo via Therion:

‐‐‐ Original Message ‐‐‐

 Em quarta-feira, dezembro 16, 2020 7:23 PM, Fra
 escreveu:


Hello everyone,

I recently started using Therion and I noticed that the Italian
translation has some typos and it was probably not updated for quite
a while.

I updated the /thlang/texts.txt file, is there a way to get
permissions to push it with git? Or else can I just send the updated
file to anybody so it can maybe be included in the next update?


I believe you should fork Therion's github project, create a branch in
your fork just for these updates, commit your changes there and them
make a push request to Therion original repository.

Regards,

Rodrigo


Thank you!

Best regards,

Francesco Bellamoli

___
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] Converter for Compass to Therion

[Benedikt Hallinger]

Cool!
I added it to the complimentary cave softwares wiki page: 
https://therion.speleo.sk/wiki/contrib:complimentarycaveapps


Am 2020-12-20 11:44, schrieb Roger Schuster:

Hello cavers,

for those of you who either use the "Compass" cave surveying package
together with Therion or need to convert legacy data from Compass
there is something to try out. I wrote a little converter that
transfers Compass raw data (*.dat) to Therion (*.th). You can find a
description and the source code at



and a compiled package for download at



Please give it a try, I hope it is useful for some of you!

Best regards,

Roger

___
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] Therion 5.5.5 bug - statistics missing from header

[Benedikt Hallinger]

Ok wookey, will check that regarding the glx Patch issue then.

> Am 23.12.2020 um 14:26 schrieb Wookey :
> 
> On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:
>>   I am sorry, one bug fixed, another introduced :/
>>   It should be OK in 5a614ef. Windows binaries should be automatically built
>>   within half an hour.
> 
> And the Debian packages are now built in unstable. They should move into 
> testing in 5 days time.
> 
> 
> Wookey
> -- 
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> ___
> 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] Therion 5.5.5 bug - statistics missing from header

[Benedikt Hallinger]

Here Explorers/etc statistics are missing with the debian package, sadly 
:(


Am 2020-12-25 23:07, schrieb Wookey:

On 2020-12-23 15:06 +0100, Benedikt Hallinger wrote:

Ok wookey, will check that regarding the glx Patch issue then.

> Am 23.12.2020 um 14:26 schrieb Wookey :
>
> On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:
>>   I am sorry, one bug fixed, another introduced :/
>>   It should be OK in 5a614ef. Windows binaries should be automatically built
>>   within half an hour.
>
> And the Debian packages are now built in unstable. They should move into 
testing in 5 days time.


Therion 5.5.5 is now in debian testing (for testing :-)
https://tracker.debian.org/pkg/therion

Wookey
___
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] Therion 5.5.5 bug - statistics missing from header

[Benedikt Hallinger]

GLX issue seems to be fixed in the debian package!

Am 2020-12-23 15:06, schrieb Benedikt Hallinger:

Ok wookey, will check that regarding the glx Patch issue then.


Am 23.12.2020 um 14:26 schrieb Wookey :

On 2020-12-23 10:42 +0100, Stacho Mudrak wrote:

  I am sorry, one bug fixed, another introduced :/
  It should be OK in 5a614ef. Windows binaries should be 
automatically built

  within half an hour.


And the Debian packages are now built in unstable. They should move 
into testing in 5 days time.



Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
___
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