Re: [Therion] World Magnetic Model

[Olly Betts via Therion]

On Thu, Apr 11, 2019 at 06:03:39PM +0200, Martin Budaj via Therion wrote:
> On Thu, Apr 11, 2019 at 5:05 PM kevin dixon via Therion 
> wrote:
> > The last Therion release 5.4.3 is dated 01 Feb 2019.
> >
> > There has in recent years been a significant change of the Magnetic North
> > Pole location, less so for the Geomagnetic South Pole:
> > https://ngdc.noaa.gov/geomag/GeomagneticPoles.shtml
> >
> > Given the above, an out of cycle World Geomagnetic Model WMM2015v2 was
> > released 04 Feb 2019.

Shortly after WMM2015v2 was released I did some comparisons for
Northerly locations on land between WMM2015v2 and IGRF12 for dates at
the end of this year (since IGRF13 is due out in December 2019) and the
largest difference I found was 0.1° which is probably acceptable given
the accuracy of the readings involved (and considering this is only an
issue until this December anyway).

> > When will this update appear in Survex and Therion ?

My current plan for Survex is to address this by updating to IGRF13 in
December 2019.

> Therion does not use WMM at all (as it doesn't contain 20th century
> historical data).
> It uses IGRF model (https://www.ngdc.noaa.gov/IAGA/vmod/igrf.html) which
> hasn't been updated yet.

Survex uses IGRF too, and for the same reason.

It'd be nice to support WMM2015v2 but we would still need to use IGRF
for dates before 2015 and have some way to cleanly transition between
the two (just using IGRF for < 2015 and WMM for >= 2015 would mean that
a series of surveys made from late 2014 to early 2015 could have a
sudden step in the declination corrections, which seems problematic).

I can't speak for Therion, but I'm open to supporting WMM in Survex if
the difference is actually an issue for people.  But if someone wants
WMM support in Survex we at least need a workable plan for what to do
about dates that WMM doesn't handle.  And even better would be a patch
to implement that plan.

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

Re: [Therion] Therion and DEM

[Olly Betts via Therion]

On Wed, Jan 23, 2019 at 11:44:36AM +0100, Marco Menchise via Therion wrote:
> I would know if it is a Therion limit and if it is somewhat possible to
> overcome it by, for example, recompiling Therion.

It looks like this line length limit is specified in thinput.cxx:

const long thinput::max_line_size = 8128;

So changing that and recompiling should help.

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

Re: [Therion] Compass (.dat) to Therion (.th) converter?

[Olly Betts via Therion]

On Mon, Jan 07, 2019 at 11:35:39AM +0100, Marco Menchise via Therion wrote:
> does anybody know if such a converter is available?

Another approach would be to process the Compass data with Survex to
get a .3d file, then use that .3d file in your Therion .th file with
something like:

import cave.3d -surveys create

See the samples/survex/ directory of the Therion source for some
examples demonstrating this.

The major difference is you get to keep the data in Compass format,
which may or may not be helpful (it's helpful if you're wanting to
collaborate with somebody still using the data in Compass, but less so
if you want to do a one-off conversion to move away from using Compass).

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

Re: [Therion] Background zoom-level bug

[Olly Betts via Therion]

On Mon, Nov 12, 2018 at 09:22:59PM +1300, Bruce Mutton via Therion wrote:
> This bug has been around ever since mouse wheel zooming was
> introduced.  An attempt was made to fix it I recall, but it did not
> have the desired effect.
> It manifests for bitmap background images, but not for xvi 'images'.
> A work around is to never roll the mouse wheel when working with th2
> with bitmaps inserted.  Very hard to do!.

There have been (at least) two changes that apparently fix bugs with
zooming in xtherion using the mouse wheel since the last release:

https://github.com/therion/therion/commit/82fc78e8931d36b215ab676754ede0cc54d3935d
https://github.com/therion/therion/commit/99d3347abaa96dde6ef3ba702a6040da65612e8c

It's been more than 18 months since the last release, and there are
a significant number of changes (~150 commits ignoring merge commits)
- perhaps it's time to make a new release?

It would be useful to have one before the end of the year from a Debian 
perspective so we can get it into the next stable release.

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

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

[Olly Betts via Therion]

On Wed, Nov 14, 2018 at 10:59:44PM +, Wookey via Therion wrote:
> On 2018-11-14 20:36 +0000, Olly Betts via Therion wrote:
> > On Wed, Nov 14, 2018 at 07:07:50PM +, Andrew Atkinson via Therion wrote:
> > > I've not had time to play with this, since Alistair showed me the problem
> > > on the weekend. The bit that I cannot get my head round is when 3d are
> > > imported with a coordinate system, if a th centreline then connects 2 
> > > parts
> > > of the survey from the 3d or an entrance coordinate is specified for the
> > > 3d, how does this change, or can it change the coordinates of the data 
> > > from
> > > the 3d as the stations from this already has coordinates with little
> > > information about the connections  [I hope that makes sense]
> > 
> > Survex .3d files record the coordinate system the data is in, if one was
> > specified.  This was added in Survex 1.2.14 (released 2014-07-05).
> 
> Right, and that is metadata saying, effectively, 'the numbers in this
> file should be considered to be in a co-ordinate system starting at
> X,Y on the planet, oriented this way'.

That's a bit oversimplified, but gives the right idea.

> > But looking at the therion source code, it appears therion never makes
> > use of this information.  I suspect therion just hasn't been updated for
> > Survex gaining coordinate system support.
> > 
> > You can specify the coordinate system as an option to therion's import
> > command, so for now I guess that's what you have to do.
> 
> Right, but (if I understand this correctly), that option does not
> change the numbers in the file. They must be valid for the cordinate
> system given in the import command. This info effectively says where
> the origin for the co-ordinates in the file are to be interpreted-as
> (and stuff about axis angles).
> So let's say that your survex data was processed in 'local' co-ordinates
> so it just starts from 0,0 in arbitrary 'nowhere' co-ordinates.
> 
> What Alistair wants to do is read that in, but use it with therion
> data that is in real-world co-ordinates (UTM30N).
> 
> The question is, can that be offset by some arbitrary number on
> reading-in so that it appears in the right place in the UTM30
> co-ordinate system? Is a rotation needed too?

I'd interpreted what Alistair had said as meaning he was specifying
the coordinate systems in his Survex data, but re-reading I think
you may be right that his data is currently just in arbitrary "local"
coordinates.

I don't think there's a way to retrofit a coordinate system to
processed data in arbitrary local coordinates.  Theoretically it
could probably be done, though if there are multiple fixed points then
you'd probably have to redo the loop closure to make it fit properly
(because space isn't exactly the same shape in different coordinate
systems - it's not just a translation and a rotation).

> The import -calibrate x y z X Y Z command looks like it should do the
> right thing, so long as the axes are aligned, by shifting from x y z
> to X Y Z. 

Adding on a fixed offset isn't going to correctly map you between most
pairs of coordinate systems though, so in general that's a bodge.  It
may sometimes be good enough given the errors in cave survey
measurements, but it seems simpler to just specify the coordinate
systems and fixed stations in the Survex data with "*cs" and "*fix", and
reprocess (and with current therion, also tell it what coordinate system
you used in "*cs out" in the Survex data).

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

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

[Olly Betts via Therion]

On Wed, Nov 14, 2018 at 07:07:50PM +, Andrew Atkinson via Therion wrote:
> I've not had time to play with this, since Alistair showed me the problem
> on the weekend. The bit that I cannot get my head round is when 3d are
> imported with a coordinate system, if a th centreline then connects 2 parts
> of the survey from the 3d or an entrance coordinate is specified for the
> 3d, how does this change, or can it change the coordinates of the data from
> the 3d as the stations from this already has coordinates with little
> information about the connections  [I hope that makes sense]

Survex .3d files record the coordinate system the data is in, if one was
specified.  This was added in Survex 1.2.14 (released 2014-07-05).

But looking at the therion source code, it appears therion never makes
use of this information.  I suspect therion just hasn't been updated for
Survex gaining coordinate system support.

You can specify the coordinate system as an option to therion's import
command, so for now I guess that's what you have to do.

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

Re: [Therion] Therion ini linefeeds

[Olly Betts via Therion]

On Fri, Nov 09, 2018 at 02:44:09AM +, Wookey via Therion wrote:
> The issue is the difference between Unix lineends, windows/DOS lineends and 
> macos lineends.
> unix uses 0x0A (10), Macos Uses 0x0D (14) and DOS/Windows uses both 
> (0x0D,0x0A).

0x0D is actually 13 not 14.

Pre-OS-X Macs used that, but modern macs use Unix-style line endings.

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

Re: [Therion] Complex model visualization with Aven, Loch, KML and Compass

[Olly Betts via Therion]

On Mon, Jul 16, 2018 at 10:37:45PM +0100, Wookey via Therion wrote:
> On 2018-07-16 19:20 +0200, Evaristo Quiroga via Therion wrote:
> > Aven is a very powerful tool too. I like the easy and intuitive rotation
> > controls and Error visualization. I can show/hide Therion surveys. But a
> > can't show/hide the "Centerlines". 
> 
> You can show/hide centrelines. Presumably you mean you can only hide
> all or none?  Last year it gained 'hide all but this one' feature, and
> just last week it gained 'show/hide each individual survey'.

"Hide others" was actually added in 2016 (and the ability to show
individual surveys was the week before last!)

> > All my centerlines have "id" and "title".
> > I can't choose a color by survey. 
> 
> You mean that you want to be able to 'display survey foo in  colour>'? Or display title in colour ? Or something else?

"Colour by Survey" would be easier now thanks to the changes needed to
allow showing individual surveys.

Generally speaking, if there's a feature you feel would be useful
to add to Survex, open a ticket for it on https://trac.survex.com/ if
there isn't one already, or comment on an existing ticket (you'll need
to create an account there first).  Otherwise you're relying on me
thinking of it myself, or someone else getting around to proposing it.

If you're able to code it up yourself, even better.

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

Re: [Therion] Wrong average calculation from compass/backcompass data

[Olly Betts via Therion]

On Thu, May 17, 2018 at 09:25:23AM +0200, Evaristo Quiroga wrote:
> I attach the original file with the fore/back sight (SCAGUA.th) and a
> manually averaged  (SCAGUA_avg.th) to compare if Survex and Therion work
> well. The error loop is similar between the two files (2,9m) but I have to
> check if the station are positioned at the same coordinates.

I feel I should point out that Survex's handling of backsights isn't
coming in to play here at all - Therion flattens away the backsights
so they don't appear in what it asks Survex to process.

Out of interest I did a crude conversion of the two attached files to
Survex format and processed them natively, and with scagua.279.0 fixed
in each case the maximum discrepancy between the two results is:

Moved by (-0.11,0.13,0.03): scagua.a.10

Which seems entirely plausible - I wouldn't expect exact agreement in
this case as some of the data has backsights and some doesn't.  In the
data from SCAGUA.th, Survex will treat the data with backsights as
slightly more accurate (because the average of two essentially
independent readings is expected to be more accurate than a single
reading) and that affects the distribution of loop misclosures.

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

Re: [Therion] Wrong average calculation from compass/backcompass data

[Olly Betts via Therion]

On Wed, May 16, 2018 at 04:45:54PM +0200, Evaristo Quiroga via Therion wrote:
> I think the problem is the average calculation formula in "thdb1d.cxx"
> 
> >// check backwards compass reading
> >    if ((lei->data_type == TT_DATATYPE_NORMAL) ||
> >    (lei->data_type == TT_DATATYPE_DIVING) ||
> >    (lei->data_type == TT_DATATYPE_CYLPOLAR)) {
> >    if (!thisnan(lei->backbearing)) {
> >    if (thisnan(lei->bearing)) {
> >  lei->backbearing -= 180.0;
> >  if (lei->backbearing < 0)
> >    lei->backbearing += 360.0;
> >  lei->bearing = lei->backbearing;
> >    }
> >    else {
> >  lei->backbearing -= 180.0;
> >  if (lei->backbearing < 0)
> >    lei->backbearing += 360.0;
> >                                    // calculate average of two angles
> >  //lei->bearing += lei->backbearing;
> >  //lei->bearing = lei->bearing / 2.0;
> >                                    double sumx, sumy;
> >                                    sumx = cos((90.0 -
> >lei->bearing)/180.0*THPI) + cos((90.0 - lei->backbearing)/180.0*THPI);
> >                                    sumy = sin((90.0 -
> >lei->bearing)/180.0*THPI) + sin((90.0 - lei->backbearing)/180.0*THPI);
> >                                    lei->bearing = 90.0 - (atan2(sumy,
> >sumx) / THPI * 180.0);
> >  if (lei->bearing < 0.0)
> >    lei->bearing += 360.0;
> >    }
> >  }
> >    }
> 
> I think the formula is too complicated. I purpose a simpler formula, like:
>             If bearing <=180
>                       AverageBearing =  (bearing + (backbearing -180))/2
>                 else
>                       AverageBearing = (bearing + (backbearing +180))/2

Your proposed formula gives wrong answers in some cases - consider:

bearing = 80, backbearing = 0

These give AverageBearing = (80 + 0 - 180) / 2 = -50 (equivalent to
310), but this should be 130 (average of 80 and 180).

The therion formula is attempting to average the angles by trigonometry,
which seems a reasonable approach (though probably slower than trying to
average more directly like you're suggesting).  It looks essentially
correct to me, though it's a bit oddly written since cos(90 - x) is
sin(x), sin(90 - x) is -cos(x), 90 - atan2(y,x) is atan2(x,y) (possibly
+/- a multiple of 360).  But if I work it out with a calculator for
236.8 and 56.8 then I do get 236.8.

If it's still not working with the declination set to zero, perhaps
you should show us a complete small example we can process to see
what is going on?

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

Re: [Therion] What file I have to translate for Loch

[Olly Betts via Therion]

On Sun, Mar 11, 2018 at 01:31:59AM +, Wookey via Therion wrote:
> On 2018-03-11 00:13 +0100, Evaristo Quiroga via Therion wrote:
> > I have already translated it. Now, What do have I do. Wait for a new
> > compilation, or I can install it directly in the program directory to run.
> 
> By publishing it, Olly (or I) can add it to the Debian version so it's
> out there for those users very soon. For other users, they have to wait until
> there is a new upstream release including it.

If you have GNU gettext install, then I think you just need to run the
"msgfmt" program to generate a .mo file and then copy it to the
appropriate place (in this case, es/loch.mo alongside bg/loch.mo, etc).

I've attached a one-off conversion.

BTW, I think there's a typo here ("Aarchivo"):

# C:/Projects/MSVCProjects/loch/lxGUI.cxx:581
#: lxGUI.cxx:578
msgid ""
"All supported files (*.lox;*.plt;*.3d)|*.lox;*.plt;*.3d|Loch files (*.lox)|*."
"lox|Compass PLT files (*.plt)|*.plt|Survex 3D files (*.3d)|*.3d"
msgstr ""
"Tosos los archivos admitidos (*.lox;*.plt;*.3d)|*.lox;*.plt;*.3d|Loch "
"Archivos (*.lox)|*.lox| Aarchivo Compass PLT (*.plt)|*.plt| Archivo Survex 3D "
"(*.3d)|*.3d"

Cheers,
Olly


loch.mo
Description: Binary data
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] What file I have to translate for Loch

[Olly Betts via Therion]

On Sat, Mar 10, 2018 at 07:05:41PM +0100, Evaristo Quiroga via Therion wrote:
> What file I have to translate to Spanish for Loch? "loch.po" in
> /loch/locale?

Yes - create loch/locale/es/loch.po.  You can copy one of the other
loch.po files, change all the "msgstr" lines to be in Spanish, and amend
the metadata at the top.

There are various tools (e.g. poedit) which are specifically written
for working with these files, but you can just use a text editor.

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

Re: [Therion] Magnetic declination

[Olly Betts via Therion]

On Fri, Mar 02, 2018 at 05:57:26PM +0100, Radek via Therion wrote:
> Here's more accurate
> 
> https://www.ngdc.noaa.gov/geomag-web/#declination

That uses the same model as Therion does, so I can't see why it should
be more accurate (unless you're using a version of therion more than a
year old, as before https://github.com/therion/therion/pull/52 Therion
calculated the fraction of the year to use in a slightly odd way, though
even then the difference is tiny if you're specifying a full date).

Also, if you look up values by hand and specify them explicitly to
therion you are hard coding the answers for the current version of the
IGRF model.  But each generation of the IGRF model is necessarily
predictive for dates after it was issued and is only declared to be
definitive for dates more than 5 years before it was issued.  So each
new generation of the model can change the declination figures reported
for the last 10 years compared to the previous generation (and the new
answers should be expected to be better).

As Xavier suggests, the table of reported declinations in the log is for
the start of each year, but declinations used for surveys are calculated
for the actual survey dates.

Maybe this needs making clearer somehow, as this isn't the first time
this summary table has led someone to think that the declination was
only being calculated for the start of each year:

https://mailman.speleo.sk/pipermail/therion/2017-February/006241.html

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

Re: [Therion] xTherion translation: what does "MRR" means?

[Olly Betts via Therion]

On Thu, Mar 01, 2018 at 09:13:41AM -0300, Rodrigo Severo via Therion wrote:
> What does "MRR" means? It's a text to be translated in xTherion.

It's used in the blood alcohol calculator which xtherion slightly oddly
includes (see the "Help" menu).

It's something like the rate at which alcohol decreases in the
bloodstream.  It's probably not critical to translate it.

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

Re: [Therion] Therion color by scrap or map

[Olly Betts via Therion]

On Tue, Sep 12, 2017 at 09:17:41PM -0700, dennis mitchell via Therion wrote:
> Hello I've been looking for info on if we have the ability to set the color
> of scraps or maps. Or am I limited to color map-fg (altitude, scrap, map)

I implemented this a while back and my patch got applied, but Stacho
later disabled the feature - from the commit message it seems he thought
the colours should be defined in a different place to where I'd hooked
them up.

If you're happy to apply patches and rebuild the source, the two commits
you need to undo to make my patch work again are listed here:

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

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

Re: [Therion] warning -- equate used to define new station

[Olly Betts via Therion]

On Wed, Aug 02, 2017 at 03:42:47PM +0700, Vasily Vl. Suhachev wrote:
> Have we a legal way to define a station to "equate" to? Or recipe to export
> already defined station to upper namespace as in Survex with its
> (deprecated) global prefix "\"?

You don't need to use deprecated features to achieve this in Survex,
you can pretty much just do what it seems you are trying to do with
Therion:

*begin cave
*equate fixed some_path.fixed
*begin some_path
fixed 2 10.00 090 00
*end some_path
*equate fixed other_path.fixed
*begin other_path
fixed 2 12.34 180 00
*end other_path
*end cave

Survex doesn't warn about using *equate to create a "well-known" alias
for a station.  That's one of the intended uses for *equate.

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

Re: [Therion] Missing fonts when compiling a map

[Olly Betts via Therion]

On Tue, Jul 25, 2017 at 07:04:17AM -0500, Bill Gee via Therion wrote:
> I have Googled on these font names, but nothing turns up.  Where should I
> look to see if they are installed?  Where do they come from?  Should I be
> concerned about it??

As the message says, they're "optional fonts" - they'e only needed if
you're using Czech/Slovak (for the first list) or Cyrillic languages
(for the second list) in any text on your survey.

> checking optional fonts csr10 csti10 csbx10 csss10 csssi10 ... NOT INSTALLED
> checking optional fonts cmcyr10 cmcti10 cmcbx10 cmcss10 cmcssi10 ... NOT 
> INSTALLED

Not sure how they're packaged on Fedora - on Debian (and probably
Ubuntu) they're in the packages texlive-lang-czechslovak and
texlive-lang-cyrillic.

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

Re: [Therion] Loop closure algorithms

[Olly Betts via Therion]

On Wed, Jul 19, 2017 at 10:30:19PM +, Saeid Bostandoust via Therion wrote:
> On Thursday, July 20, 2017 2:47 AM, Wookey via Therion  
> wrote:
> > Installing or not-installing survex switches the algorithm. Not sure
> > if there is a way of forcing one or the other algorithm without doing that..

You can specify in therion.ini with:

loop-closure therion

or:

loop-closure survex

"By default, survex is used if present, otherwise therion."

> is it better to install survex and using survex loop closure algorithm
> or not?

While I'm probably biased, the fact that the default is to use survex if
it's installed indicates that therion's authors think it's the better
choice.

There's also a third way (which is what I do), which is have your data
in .svx format, and just point therion at an already-processed .3d
file with "import example.3d":

https://therion.speleo.sk/samples.doc/40.html

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

Re: [Therion] Person data type with more than two names

[Olly Betts via Therion]

On Sat, Jul 15, 2017 at 12:06:43PM +1200, Bruce Mutton via Therion wrote:
> Therion Book says of this data type:
> 
> person �� a person��s first name and surname separated by whitespace
> characters. Use ��/�� to separate first name and surname if there are more
> names.

Perhaps more clearly: a person can have at most two names (name1 and name2).
If there's a "/" then that separates the name1 and name2 (which can then
contain spaces), otherwise whitespace separates name1 and name2.  So
multiple "/" is an error, as is multiple whitespace without a "/".

At least that's what the code appears to do, and it's consistent with all
your examples.

I guess it's up to the user how best to separate a person's fairly arbitrary
number of names into at most two groups.

Just be careful never to go surveying with someone with a "/" in their name...

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

Re: [Therion] same color for several scraps

[Olly Betts via Therion]

On Mon, Apr 24, 2017 at 11:16:19AM +0200, Philippe Vernant via Therion wrote:
> I’m trying the option [color] or [colour] to specify the same color for 
> different scraps and it is not working. I have therion 5.4.0 compiled on Mac 
> OS.
> 
> Here what I use :
> 
>  map m1p -projection plan -color [0 70 0]
> 
>baign-p1
>baign-p2
>pend-p1
>gphal-p2
>gphal-p4
>gphal-p3
>  endmap
> 
> end the error message is :
> therion: error -- maplist.th [3] -- unknown option -- -color
> 
> Any clue ?

Stacho disabled it shortly before 5.4.0 was released:

commit 856debf20df0913b279d122fa488c0358748132b
Author: Stacho Mudrak 
Date:   Mon Apr 3 20:09:26 2017 +0200

Removed map colour option. It should be defined in layout, not source files.

commit ed00c08b02db29c134dd29429b09d8c39e091c86
Author: Stacho Mudrak 
Date:   Mon Apr 3 20:07:06 2017 +0200

Removed map colour option. It should be defined in layout, not source files.

If you're building from git, revert those two commits and it ought to work.

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

Re: [Therion] Disconnected centrelines - Extended Elevation Control

[Olly Betts via Therion]

On Sat, Apr 08, 2017 at 11:32:00AM +0200, Martin Sluka via Therion wrote:
> 8. 4. 2017 v 10:46, Bruce Mutton via Therion :
> > Both options feel a little bit like hacks.
> 
> Nosurvey is nosurvey.

The thbook defers to the Survex manual for the definitions of the data
styles ("See Survex manual for details.") and the Survex manual says:

A NOSURVEY survey doesn't have any measurements - it merely indicates
that there is line of sight between the pairs of stations.

Adding NOSURVEY legs where there isn't a line of sight (or even a passage
without an exact line of sight) is definitely a hack.

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

Re: [Therion] New version of Therion 5.4.0 available

[Olly Betts via Therion]

On Wed, Apr 05, 2017 at 10:20:55PM +0200, Benedikt Hallinger via Therion wrote:
> Can't wait to see it in debian testing :)

Debian testing is currently frozen in preparation for the next release,
but it should appear in Debian experimental soon.

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

Re: [Therion] cavern exit code 256

[Olly Betts via Therion]

On Sun, Apr 02, 2017 at 12:53:25PM +0200, Benedikt Hallinger via Therion wrote:
> when compiling my project, i get an cavern error:
> 
> >therion: warning -- cavern exit code -- 256
> 
> Everything seems to be fine in the map, but what does this exit code mean?

256 is the number returned by system(), which runs another program.

If the bottom 8 bits are zero (as here) then the next 8 bits are the
exit status of cavern, so in this case 1 which means there was an error
(or multiple errors) while procesing the data.

If cavern had been killed by a signal (e.g. a segmentation fault) then
the bottom 8 bits would be (signal_number | 0x80), so on Linux you'd get
139 for a segmentation fault.

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

Re: [Therion] cavern exit code 256

[Olly Betts via Therion]

On Sun, Apr 02, 2017 at 11:49:54PM +0200, Benedikt Hallinger via Therion wrote:
> The source giving causing it is:
> >fix 1.0 x y z 0 0 0
> 
> If i remove the standard-deviation zeros, cavern stops to complain.
> 
> The reason was that the entrance location was measured by public service
> against official grid by theodolite and as such is "perfectly correct".
> How can i give this information? Am i forced to use some minimal positive
> fraction? (eg. "0.1"?)

Just omit the SDs - that means it's an exact fix.

> If yes, could this be an cavern bug?

It's really a bug in the .svx file therion generates - it should omit
the zero SDs even if they're explicitly specified in the .th file, since
the documented syntax for an exact *FIX command is that you omit the SDs.

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

Re: [Therion] Necessary packages to compile Therion on a Ubuntu machine

[Olly Betts via Therion]

On Mon, Feb 27, 2017 at 11:36:07PM +, Wookey via Therion wrote:
> On 2017-02-25 10:27 -0300, Rodrigo Severo via Therion wrote:
> > Here is a list of packages necessary for compiling Therion on a Ubuntu 16.04
> > machine:
> > 
> > apt install libvtk6-dev libwxgtk3.0 libfreetype6-dev build-essential
> > wx3.0-headers libwxbase3.0-dev libglu1-mesa-dev mesa-common-dev bwidget 
> > feynmf
> > libtk-img texlive-metapost
> > 
> > It might save someone sometime.
> 
> The packaged version of therion does of course include this info.
> 
> 'apt-cache showsrc therion' 
> would show you:
> Build-Depends: dpkg (>= 1.16.2), debhelper (>= 9), perl (>= 5.5),
>   docbook-to-man, tcl, libvtk6-dev, libwxgtk3.0-dev, libfreetype6-dev,
>   libjpeg-dev, libpng-dev, pkg-config, texlive-base, libproj-dev
> Build-Depends-Indep: texlive-metapost, imagemagick, ghostscript
> 
> (and that assumes that build-essential is also installed)

Though note that this list includes some packages you don't need to build the
upstream version - e.g. therion's source tree includes a copy of the PROJ.4
sources but the Debian package patches the upstream build system to instead
build against the packaged version of PROJ.4 (so libproj-dev is needed for the
package, but not for building the unpatched upstream code).

(I'm not sure why PROJ.4 is bundled - you need to have wxWidgets and VTK
installed, so having to have PROJ.4 installed as well doesn't seem onerous).

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

Re: [Therion] Aven colour by loop error

[Olly Betts via Therion]

On Thu, Feb 23, 2017 at 10:00:35AM +0100, Martin Sluka via Therion wrote:
> 
> > 23. 2. 2017 v 3:08, Olly Betts via Therion <therion@speleo.sk>:
> > 
> > I've done the armchair equivalent and used Aven's error colouring to
> > successfully find mis-ties, reversed legs, etc.
> 
> You will find them by drawing scraps in xtherion with "debug on“ option in
> thconfig immediately. Typos too - like 1.23/12.3 m length. Idea of scraps and
> maps is the most important part of Therion.

OK, but Stacho's question was about the error measures in aven...

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

Re: [Therion] Aven colour by loop error

[Olly Betts via Therion]

On Thu, Feb 23, 2017 at 12:08:09AM +0100, Stacho Mudrak via Therion wrote:
> Hi, I agree with Bruce, that it is really a very useful feature. I have
> just pushed it on GitHub (see commit 2ebc7ed).
> 
> The only problem is, that survex calculates error which "is the ratio of
> the observed misclosure to the theoretical one". I have implemented more
> simple export (it was much easier), currently therion .3d export contains
> error equal to 2 * relative error of a loop. (because of 0-12 aven fixed
> error scale). It should be possible to extract survex relative error from
> either thTMPDIR/data.err or data.3d file, but it will take some time.

I'd definitely use the .3d file (no rounding, and a file format that's
intended for machine parsing).

> But when I compared 3D files with relative loop error and error with survex
> ratio, I received two quite different pictures. Are these two measures not
> comparable? Is a relative error of a loop useless number?

tl;dr: No and yes!

By "relative error of a loop" I'm assuming you mean "misclosure / length
of traverse * 100%".  If so that's not really a useful measure, though
at least historically it's been a fairly popular one, I suspect because
it's an obvious one to calculate.

The problem with it is that what's a "good" value depends on the length
of the traverse.  For random errors, the squares of the errors add, so a
traverse which is 100 times as long would be expected to only have 10
times the error, which means the relative error would be expected to be
10/100 = 1/10 as much.

As well as not providing a reliable measure of the random error, a
blunder in a long traverse will tend to be smoothed out in the relative
error, as it gets divided by the length of the traverse.

Observed error divided by theoretical error should be agnostic to length
of traverse.  It's simply telling you which traverses don't seem to be
surveyed to the accuracy that was claimed.

> Has anybody tried to go to a cave and resurvey "red shots", whether
> they are really so bad?

I've done the armchair equivalent and used Aven's error colouring to
successfully find mis-ties, reversed legs, etc.

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

Re: [Therion] Aven colour by loop error

[Olly Betts via Therion]

On Wed, Feb 22, 2017 at 09:34:03PM +, Footleg via Therion wrote:
> Therion strips most of the data apart from staions and legs out of 3D files
> it generates. Colour by error and by date are not possible because that
> information is not in the 3D files generated from a Therion project.
> Entrances are lost too. One of the reasons I plan to add Therion to Survex
> conversion into my cave converter program (when time permits).

Therion-generated .3d files now[*] contain date and coordinate system
information, thanks to a patch from Vlad:

https://github.com/therion/therion/commit/43e6630e3109196d2c251f05e52c2663496419d9

[*] This isn't in a released version of therion yet, but I'm guessing
there's likely to be a new release soon as it's been years since 5.3.16
and a lot of useful stuff has been merged recently.

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

Re: [Therion] Interface translation

[Olly Betts via Therion]

On Tue, Feb 21, 2017 at 07:58:07PM +0100, Ladislav Blažek via Therion wrote:
> check xtherion/lang subfolder. Same process as for map objects.

There's also loch/locale/ for loch (which uses the standard PO format
for translations).

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

Re: [Therion] Declination handling imprecise?

[Olly Betts via Therion]

On Sat, Feb 18, 2017 at 09:24:42PM +, Olly Betts via Therion wrote:
> On Sat, Feb 18, 2017 at 10:20:54AM +0200, Benedikt Hallinger via Therion 
> wrote:
> > For the date-observation, indeed my conclusion came from the summary in the
> > log. Thank you for claryfying this. Good to hear, therion uses fractions
> > here, and 1/12 is perfectly good.
> 
> To be clear, therion calculates the fractional year taking into account the
> day of the month - it just doesn't assign quite equal lengths to every day of
> the year, but instead puts the start of each month 1/12 of a year apart, and
> then splits up each 1/12 into 28, 29, 30 or 31 equal pieces.  Really it
> should split the year into 365 or 366 equal pieces.

FYI, I submitted a patch to address this which Stacho has merged, so the
next release should calculate this using even sized days (leap years aside):

https://github.com/therion/therion/pull/52

> > However i have seen that it looks like the calculated declination is maybe
> > rounded to full degrees? Or is this just an display thing in aven viewer?
> 
> Aven currently only shows a whole number of degrees, which is unhelpful for
> this sort of thing.  It probably ought to show one decimal place.

The next release of Survex will show one decimal place.

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

Re: [Therion] First use of locally compiled Therion: metapost error

[Olly Betts via Therion]

On Mon, Feb 20, 2017 at 08:40:36PM -0300, Rodrigo Severo via Therion wrote:
> To fix it I had to include the following line on */etc/therion.ini*
> 
> tex-fonts raw cmr10 cmti10 cmbx10 cmss10 cmssi10
> 
> despite Therion Book stating at page 80 that this is the default setting.
> 
> Should this line be uncommented on the default *therion.ini* file?

Do you have the Ubuntu package of therion installed too?

If so, my guess is that /etc/therion.ini is from that package.  Currently
the Debian (and hence Ubuntu) packages have a couple of patches in this
area - see the discussion here for details:

https://github.com/therion/therion/pull/31

Assuming I'm right, the quickest fix for your situation is probably to copy
therion.ini from the source tree to /etc.

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

Re: [Therion] Declination handling imprecise?

[Olly Betts via Therion]

On Sun, Feb 19, 2017 at 09:00:52PM +, Olly Betts via Therion wrote:
> On Sun, Feb 19, 2017 at 01:50:45PM +0200, Benedikt Hallinger via Therion 
> wrote:
> > Is the centerline shown in aven correct and only the displayed angles
> > rounded (i.e. the calculated coordinates are valid)?
> > How about loch?
> 
> Not sure about loch, but (as I mentioned in the message you replied to)
> released versions of aven indeed show the bearing of the measuring line
> as an integer (probably actually truncated to the integer <= the value
> rather than rounded).

Someone smarter than me just pointed out that you're actually asking if the
angles in the displayed centreline are also rounded.

The only rounding of the centreline is that coordinates in the 3d file are
stored in centimetres, which should have a negligible effect on the ~1000m
long legs in your testcase.

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

Re: [Therion] Declination handling imprecise?

[Olly Betts via Therion]

On Sun, Feb 19, 2017 at 01:50:45PM +0200, Benedikt Hallinger via Therion wrote:
> Thank you everybode for those insights!
> It is good to hear therion is this accurate, however i need to learn what i
> understand wrong in the test data.
> 
> Is the centerline shown in aven correct and only the displayed angles
> rounded (i.e. the calculated coordinates are valid)?
> How about loch?

Not sure about loch, but (as I mentioned in the message you replied to)
released versions of aven indeed show the bearing of the measuring line
as an integer (probably actually truncated to the integer <= the value
rather than rounded).

I've already pushed a change to show one decimal place, as this thread
reminded me that I'd been meaning to sort this out, and it was a simple
issue to address.

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

Re: [Therion] Declination handling imprecise?

[Olly Betts via Therion]

On Sat, Feb 18, 2017 at 10:20:54AM +0200, Benedikt Hallinger via Therion wrote:
> If therion calculates the average position of all fixed points this is fine.
> the cave spans about 5km w/e and about 3km n/s.

Ah, the 100km is total passage length not extent then.

For a few km the variation is probably fairly small for most of the world
compared to the errors from the instrument readings, though the instrument
errors are random and the declination discrepenacy is systematic
- systematic errors are worse because they don't lessen when you combine a
lot of readings (for random errors the error of the sum increases as the
square root of the number of readings - e.g. for 100 readings, the random
error only increases 10 times).

The grid convergence may well be larger (IIRC therion calculates that at
the same average fixed point location; I know that Survex calculates it at
the same coordinates you give in "*declination auto").  To quantify these
errors, for the coordinates in your test file, 5km E means about 0.015
degrees change in declination and about 0.049 degrees change in grid
convergence (in opposite directions).

> For the date-observation, indeed my conclusion came from the summary in the
> log. Thank you for claryfying this. Good to hear, therion uses fractions
> here, and 1/12 is perfectly good.

To be clear, therion calculates the fractional year taking into account the day
of the month - it just doesn't assign quite equal lengths to every day of the
year, but instead puts the start of each month 1/12 of a year apart, and then
splits up each 1/12 into 28, 29, 30 or 31 equal pieces.  Really it should split
the year into 365 or 366 equal pieces.

> However i have seen that it looks like the calculated declination is maybe
> rounded to full degrees? Or is this just an display thing in aven viewer?

Aven currently only shows a whole number of degrees, which is unhelpful for
this sort of thing.  It probably ought to show one decimal place.

> Based on what you have said, i would assume that the problem source lies in
> therion itself summarizing all centreline dates into one survey average
> date, and not just by centerline as i would assume, when each centerline has
> a date specification.

I think you need Stacho or Martin to comment on whether that's happening.

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

Re: [Therion] Declination handling imprecise?

[Olly Betts via Therion]

On Fri, Feb 17, 2017 at 07:08:48PM +0200, Benedikt Hallinger via Therion wrote:
> i found out that the declination handling seems to be somewhat inaccurate.
> The produced error is marginal and negligible with small caves, however i am
> currently working on a system with >100km and this produces errors of >10m
> there.

Therion calculates all declination values at the same location (the average
location of all the fixed points), which is potentially problematic if your
survey spans that sort of distance.  I wonder if this might actually be the
source of your problems.

Survex requires specifying the location to calculate declination values at,
and you can use different locations for different parts of the survey
hierarchy.  So keeping your centreline data in Survex format and feeding
therion a 3d file would be one solution if this is the issue you're hitting.

(Using the actual location of the station the reading was taken at is hard
as you need the declination value to calculate that location.  It would also be
fairly slow to evaluate the IGRF model at every station where a compass was
read.)

> What i observe is the following:
> - Therion seems to use the first day of any given year referenced by "date"
> command.

If that's from looking at therion's log file, the "geomag declinations (deg)"
table there is just a summary.  It indeed shows the values on January 1st of
each "interesting" year, but doesn't reflect the dates actually being used to
calculate declinations for surveys.

Or was that from looking at the source code?  The get_start_year() and
get_end_year() methods actually return a fractional year value, not just the
year of the survey.  The fraction is calculated assuming each month is 1/12 of
the year - not quite right, but probably not a significant error in practice.

> - If a survey was taken at the end of a year it seems that the 1.1 of the
> following year will be used (i assume this happens at mid-year).
> - This approach looses at most half a years magnetic drift.
> This alone is acceptable as the data by itself is already not that accurate.
> 
> However if you have several centerlines in the survey, each with different
> date-commands, therion seems to calculate the average of all dates and then
> uses the calculated declination for that date (applying the rule above, so
> taking the "closest 1.1.").
> This is then applied to all shots of the whole survey.

Not sure - I don't know therion's code that well.

> A possible solution to this seems, to get the correct declination for each
> date and explicitely write suitable "declination" commands that override the
> "date"-calculated values. This then gives the proper results.

This approach is less than ideal, and not just because it's a significant
effort.

Each generation of the IGRF model is necessarily predictive for dates after it
was issued and only declared to be definitive for dates more than 5 years
before it was issued.  So each new generation of the model can change the
declination figures reported for the last 10 years compared to the previous
generation.

In simple terms, when IGRF-13 comes out in late 2019 it'll potentially give
different answers for all dates in 2010 and later (not hugely different one
would hope, but your motivation here is to avoid introducing unnecessary
errors).

See table 1 here for the date information for each IGRF model generation:

http://earth-planets-space.springeropen.com/articles/10.1186/s40623-015-0228-9

So unless you're dealing with historic data, you really want your software
to calculate the declination automatically so that you get the benefit of
improvements when the IGRF model is updated.

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