Re: [Therion] A puzzle in Loch

[Olly Betts]

On Tue, Aug 15, 2023 at 07:41:51PM -0500, Bill Gee wrote:
> Hmmm.   Maybe I am not using the splay flag correctly?  Is there another
> flag that might be more appropriate?
> 
> The reason those stations are flagged as splay is because they do not
> contribute to the length of the cave.  They are just connecting a side
> passage into the rest of the survey.  Marking the shots as splay means they
> get left out of the total length calculation.

The "duplicate" flag seems to be what you're wanting here.

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

Re: [Therion] sd for a vertical pole

[Olly Betts]

On Wed, Sep 07, 2022 at 10:56:00AM +0100, Tarquin Wilton-Jones via Therion 
wrote:
> > In Therion, this generates an error "invalid quantity -- plumb".
> > 
> > sd length 0.001 metres
> > sd plumb 0.125 degrees
> > gps surveystart 2.000 - DOWN
> 
> I wrote a bunch of tests. Therion is missing the required "sd plumb"
> functionality, and has no equivalent. I have filed this as:
> https://github.com/therion/therion/issues/445
> 
> The only workaround is to use:

Another workaround is to process your centreline data directly with
cavern and point therion at the resultant .3d file.  However, if you
have existing centreline data in therion format that would require
converting it which is probably too annoying.

> sd length 0.001 metres
> sd clino 0.125 degrees
> gps surveystart 2.000 - -90
> 
> but this will then generate a warning from Cavern saying that the
> compass bearing may not be omitted. (It will still work, however.)

Not sure what therion generates to feed to cavern in this case, but
presumably this gets handled as having a compass reading of 0, so
it doesn't give you the symmetric situation you want.

Setting the compass SD high probably won't give you the symmetric
situation either.

As you concluded modelling this as a plumb is the best approach
in Survex.  The plumb error is assumed to be a small angle from the
vertical since the main error component is assumed to be linear in the
length of the leg.

I'm not sure if those assumptions are entirely justified, but having
the error increase with length seems appropriate as on longer plumbs the
end tends to wander over a larger area and the period of oscillation for
a pendulum increases with length (proportional to sqrt(length) if you
assume the string is weightless, or if you assume the whole pendulum is
rigid, neither of which are going to be entirely true for a plumb in a
cave).

It might be interesting to experiment to see what the plumb reading
error actually looks like with increasing length (perhaps down a
stairwell in a tall building).

Anyway, the main error from your spirit level on the stick will also be
a small angle from the vertical.

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

Re: [Therion] Dive data, newline required

[Olly Betts]

On Wed, Jul 13, 2022 at 12:04:52PM +0200, Martin Sluka via Therion wrote:
> 
> 
> > 13. 7. 2022 v 11:14, A.M. van Rosmalen :
> > 
> >  data diving station depth length bearing
> 
> There is missing from station to station information:
> From Survey manual:

Martin seems to be quoting the Surve*x* manual here, so while I can't
really speak for what Therion supports here, it seems to follow Survex
here so I guess I should respond about what Survex supports and why.

The problem with the example given is that the supported interleaved
style looks like this (with the first and last being station specific):

  
  
  
  
  
  
  

In the original example given in this thread, "station" and "depth" are
specific to a station, while "length" and "bearing" are measured between
stations, so it would need to be rewritten - this works in Survex format
(therion you probably just need to drop the "*"):

*data diving station depth newline length bearing
GTENC000136.3
0.45257.6
GTENC000236.2
0.26248.6
GTENC000336.2
; commented out because incomplete: 0.52233.3

Note the final length and bearing can't be processed without a
corresponding final station and its depth to make a complete set of
data for the final leg.

As to why the newline is required, the supported style was based on
examples I'd seen of this style, and note taking in this style seems to
naturally lead people to grouping the readings like this, e.g. from a
random web search result:

https://southerncaliforniagrotto.com/graphics/resmap2.jpg

I don't think it's ever come up before that someone wanted interleaved
data but with the station and inter-station data all on a single line.
It could probably be supported (though I think it would need to be
limited to still requiring all inter-station readings after the station
specific ones because the final line has only station specific
readings), but you said your data is computer generated so tweaking the
code which generates the data to write a newline after the depth would
get you there much quicker.

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

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

[Olly Betts]

On Mon, Dec 27, 2021 at 05:04:20PM -0600, Bill Gee wrote:
> My question about significant digits is really related to how much
> precision can and should be carried through a calculation.  If compass
> readings are taken to four significant digits, then the mean of two
> such numbers is really only good to about three and a half significant
> digits.

That seems wrong to me - we expect the mean to have *better* accuracy
than the individual readings (otherwise one would want to avoid
averaging readings!)

Assuming independence (which may not an entirely valid assumption here
admittedly) and that both readings have the same standard deviation x,
then the s.d.  of the mean of 2 readings is x/sqrt(2) - or about
0.707*x.  I think that means you actually would expect to gain
log(1/sqrt(2))/log(1/10) or about 0.15 decimal significant digits from
taking the mean of two readings.  (And it's 1/sqrt(n) for n readings, so
if you average 100 independent readings then you'd expect to gain a
whole decimal significant digit.)

> Displaying more significant digits implies more precision
> that actually exists.

Right, but that argues for suitably presenting reported values, not for
rounding intermediate values during the calculations.

> A compass reading even from a DistoX2 is
> probably accurate to only +/- 2 least significant digits.
> 
> https://en.wikipedia.org/wiki/Significant_figures

I'm not quite sure what "2 least significant digits" means, and that
wikipedia page doesn't seem to help.

But I think I get the gist, and indeed any instrument will have a limit
to its accuracy, especially so for anything you'd be likely to consider
taking underground.

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

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

[Olly Betts]

On Sun, Dec 26, 2021 at 08:00:49AM +, Ben Cooper wrote:
> What does Survex actually do for all these loops?

It deal with any backsights up front and just adds a single link to the
network for each survey leg.

It's harder to properly account for partial backsights if we created a
separate link for the backsight (e.g. backcompass and backclino but no
backtape is common).

But even just from a network solving perspective, if we generated a
trivial loop for each backsight the network optimisations would
later rediscover each trivial loop and collapse it to a single leg,
but that would be less efficient than collapsing it when we have the
knowledge it's a trivial loop as we read in that leg.

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

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

[Olly Betts]

On Sat, Dec 25, 2021 at 08:50:26AM -0600, Bill Gee wrote:
> 1) Does Therion also recognize the BACKTAPE data type?

It seems not - there's no match in the source code repo for:

git grep -i BACKTAPE

> 2) What does Survex do if both TAPE and BACKTAPE are given?  Does it
> average the two readings?  Does Therion do the same thing?

Survex warns if they differ by more than 3 standard deviations, and then
takes the mean of the readings.

> I understand that Therion will use Survex to reduce the centerline
> data - if Survex is installed.  In case Survex is NOT installed, then
> Therion reduces the centerline itself.  As a result they might handle
> this situation differently.

Also, Therion generates a .svx file behind the scenes, but not
necessarily the .svx file you'd write yourself given the same data.
For example, I think Therion collapses backsights to a single reading
itself before processing with Survex.

> As I write this, another related question occurred to me.  When either
> Therion or Survex averages a forward and backward reading, how many
> significant digits does it carry in the calculation?  Can the
> significant digits be changed?

Survex uses double precision for this:

https://en.wikipedia.org/wiki/Double-precision_floating-point_format

That has 15-17 significant decimal digits - i.e. many more than matter
here.

Using more precision seems overkill.

If you really want to use fewer it should be possible to build cavern
to use single precision, but I don't think anyone actually does this.
We made it an option as decades ago it seemed you might want to do this
to reduce memory usage (4 bytes per floating point number instead of 8)
but cavern's memory use is very modest by modern standards, and single
precision only gives 6-9 significant decimal digits, which isn't even
enough to reliably store a UTM Northing to the nearest metre so you'd be
limited in what coordinate systems you could use in such a build.

I don't see why you'd want to be able to dynamically force rounding to
fewer significant figures - what's the benefit?

Downsides of rounding are it would slow things down a bit, and it risks
introducing systematic biases - a dumb example to make the issue
clearer: if all readings are to the nearest inch and you round the
average to the nearest inch and always round 0.5 up, then then assuming
an even distribution there's an average bias of +0.25 inches on each
tape reading.  The problem with systematic biases is they accumulate
rather than tending to cancel.

There are other rounding schemes which try to address this sort of
issue (like rounding 0.5 to the nearest even number) but it's hard to be
certain they might not introduce a more subtle bias (some cave systems
have dominant direction passage develops along so the distribution is
may not uniform across odd and even) and there doesn't seem a compelling
reason to be rounding in the first place.

> And the same question applies to loop closure calculations.  How many
> significant digits are carried through the calculations?

The same.

The final results are then stored in the .3d file to the nearest cm
(that's 0.49710 furlongs for our US readers).  That precision was
chosen so that coordinate values will fit in a 32 bit integer, and seems
adequate for the final results.

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

Re: [Therion] Get shortest route

[Olly Betts]

On Fri, Nov 26, 2021 at 05:10:18PM +0100, Benedikt Hallinger wrote:
> i would want to get some advanced statistics regarding lengths in a very big 
> cave (130km/Hirlatz).
> 
> Basicly i want to supply two stations and get the following data for the 
> shortest path:
> - length of shots
> - cumulated height for shots going upwards
> - cumulative depth for shots going downwards
> - optionally it would be cool to be able to somehow visualize the route in 
> aven/loch, or in a therion map output
> 
> Is this possible already?

I don't think so.

Someone was working on it, but I guess it didn't come to anything as
that was 2016:

https://lists.survex.com/pipermail/survex/2016-October/002082.html

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

Re: [Therion] Survex splays flag in Therion

[Olly Betts]

On Tue, Sep 21, 2021 at 07:40:43AM +, Rodrigo Severo via Therion wrote:
> Is there a way to make Therion recognize the splay shots flags defined
> in the Survex file so I can control their appearance separately from
> the main shots and their length not be included on the total cave
> length?

It looks like Therion is just missing handling for splay flags on import
from 3d (though oddly it does appear to have code to export them to 3d).

Try the attached patch (totally untested).

Cheers,
Olly
diff --git a/thimport.cxx b/thimport.cxx
index 2d3337aa..be0188e7 100644
--- a/thimport.cxx
+++ b/thimport.cxx
@@ -675,6 +675,9 @@ void thimport::import_file_img()
 if ((sli->flags & img_FLAG_DUPLICATE) != 0) {
   tmpdata->d_flags |= TT_LEGFLAG_DUPLICATE;
 }
+if ((sli->flags & img_FLAG_SPLAY) != 0) {
+  tmpdata->d_flags |= TT_LEGFLAG_SPLAY;
+}
 tmpdata->insert_data_leg(2, args);  
 this->db->csurveyptr = tmpsurvey;
   }
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] xtherion - Multiple background sketches

[Olly Betts]

On Mon, Jun 21, 2021 at 04:31:45PM -0500, Bill Gee wrote:
> Now I need to figure out how to set transparency on each layer.

Bring up the Gimp "Layers" dialog (shortcut key is Ctrl+L) and you can
click on each layer and drag the "Opacity" slider to make them partly
transparent.  Or you can change the mode on each layer to "Darken only"
and the result will be the darkest part of any layer, which is probably
what you're after (assuming your sketches are dark lines on a white
background).

> I wonder if Bruce's faint memory about setting transparency with an
> external editor worked because of using PNG format?  My own faint
> memory is that xTherion uses different libraries to handle png and jpg
> files.  Handling of transparency is probably a feature of the image
> library rather than xTherion.

I don't think the standard JPEG format supports transparency.

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

Re: [Therion] compass correction Re: Strange Therion/survex disparity

[Olly Betts]

On Mon, Mar 15, 2021 at 05:50:18PM +, alastair gott wrote:
> I'm afraid I there is no answer as to whether I mean calibration,
> declination or calibrate declination.
> 
> As the survex model has the *calibrate compass -2.65 already in it,
> and I don't know whether this is because they knew the compass was
> out, or whether they corrected for the declination in the survex model
> when the data was put in.

It would help a lot to determine what -2.65 includes.

If it wasn't recorded and you can't usefully ask the people who recorded
the data, you could try adjusting the data assuming this includes the
declination and again assuming it doesn't and see which version gives
better loop errors.  Aven can colour by error which provides a way to
visualise this.

>  When I refer to the calibration in Therion, I've just applied the
>  same function calibrate compass 357.3
> 
> I was hoping that running the comparison between therion and survex on
> the first leg of the survey, I could work out by trial and error what
> I should do to make the data the same. I'm happy to apply a fix to all
> the .th files, to ensure that the models align, but this doesn't seem
> like the therion way given that the underlying data is the same.

A key difference here is that Therion automatically corrects for
declination and for grid convergence (the difference between true north
and grid north) if you specify a coordinate system and put a date on a
survey.  It does this by calculating the corrections at the location
which is the average of all the specified fixed points (this doesn't
seem to be documented, but that's my understanding from reading the
source code.)

Survex takes a different approach and you have to turn on the equivalent
feature and specify the location to calculate the corrections at, e.g.:

*declination auto 0410600 5282000 1234

I didn't follow therion's automatic approach because it has the downside
that adding a new fixed point slightly changes the location of *ALL*
survey stations (apart from those which are also fixed points).

> PS. I know there will be parts of the datasets where there are
> differences, but till I can make the first leg the same, I think it
> will be difficult for me to spot even the biggest difference.

Rather than trying to maintain two parallel version of the data set,
my suggestion would be to save yourself a lot of work and just tell
Therion to use a .3d file produced from the Survex data set for the
station coordinates (see the "import" command).

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

Re: [Therion] Difference between Therion and Survex when calibrating tape

[Olly Betts]

On Fri, Aug 14, 2020 at 07:47:48PM +0100, Tarquin Wilton-Jones via Therion 
wrote:
> Survex manual does not say what happens to the scale value when it is
> omitted, but it does say "By default, the zero error is 0.0 and the
> scale factor 1.0 for all quantities." This implies that the scale value
> should reset to 1 whenever it is omitted.

Yes.  It also explicitly says lower down "(Scale defaults to 1.0)"
(where the formulae used are given.)

Both for this and in general, if you see something in the manual which
could be clearer, please do send a suggested patch (or just a
replacement paragraph to copy in if you don't know how to make a patch).

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

Re: [Therion] Splays - Revisiting Breaking extended elevations

[Olly Betts]

On Wed, Jul 29, 2020 at 06:25:50PM +0100, Tarquin Wilton-Jones via Therion 
wrote:
> TopoDroid, Pocket Topo and Survex all extend only the legs. They all
> keep the splays in the "same" direction (relative to the leg) as they
> were before, which makes them normally perfect for drawing extended
> elevations. They can project forwards and backwards out of the page (so
> to speak), so they end up the right distance, visually, from the station.
> 
> There is always the issue when you are at a station where the extend
> direction changes from left to right or vertical, since at that point
> you don't know whether a splay should take its direction from the leg
> before or the leg after (or the "nearest" leg to it - perhaps the most
> useful answer). Survex gets this wrong sometimes, but is normally useful.

Examples of where Survex it gets it wrong are definitely of interest.

I added extending of splays just over 3 years ago, and the NEWS entry
(which also explains the algorithm used) explicitly invites feedback:

| + Splays are now carried over the extended survey.  The current
|   handling is simplistic, but should do a good enough job to be more
|   useful than discarding splays.  The splays at each station are all
|   rotated together based on the bearing between the stations either
|   side of the current one along the first path extended through that
|   station.  This nicely handles dead ends and the situation at the top
|   or bottom of a pitch, and should tend to pick an angle close to the
|   passage orientation along a traverse.  It's weakest at junctions.
|   Feedback (especially examples which could be handled better) most
|   welcome.

But so far the only thing I could possibly count as feedback on this
subject is what you wrote above (which is good to hear overall, but it'd
be helpful to have some details of where you've seen it go wrong).

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

Re: [Therion] North arrow and magnetic declination

[Olly Betts]

On Thu, May 28, 2020 at 10:20:50AM +0200, Martin Sluka via Therion wrote:
> > 27. 5. 2020 v 23:39, Bill Gee :
> > I am well aware of how Therion processes declination when going
> > through the survey data.  I take the trouble to make sure every set
> > of survey data has a date associated with it so that the
> > declinations can be properly calculated.
> >  
> > As for putting declination on the map ... I have never done that and
> > do not plan to start.   I think it is not useful to have it on a
> > map.  In 20 years (or whenever) it will be wrong.  It is better to
> > just leave it off.
>
> Declination up to 1 degree could be not a problem. But there are
> regions where declination is more than 10 degree.

It's more than 25° in southern NZ:

https://www.gns.cri.nz/var/ezwebin_site/storage/images/home/our-science/land-and-marine-geoscience/earth-s-magnetic-field/declination-around-new-zealand/nz-magentic-declination/75157-1-eng-GB/NZ-magentic-declination.png

> And I know a false theory about development of two huge parallel caves
> instead of only one system because the author of that theory just
> omitted inclination of surveys of upper and lower part of that cave
> from upper and lover entrances (they were not connected). 

I suspect it took CUCC longer to connect Eislufthöhle to Kaninchenhöhle
because we weren't correcting for declination back then (the declination
in the area used to be essentially zero and the models to calculate it
weren't easily available so we left it to sort out later, but gradually
it increased to the point where it actually made a difference).

> Softwares for cave data offer the automatic calculation of declination
> (and grid convergence), so there is not reason not to use it. Therion
> calculates declination according each day from the model.

I don't think anyone has suggested in this thread that one shouldn't
correct for declination.

> Maybe there should be the date when a map was generated under North
> sign in such case.

If you're going to put a Magnetic North arrow on, then I agree it really
ought to be clear what date it's for.

Bill's original message was saying that therion has options for North
arrows which show both geographic and magnetic north, but *DON'T* say
what date the shown magnetic north is for:

https://mailman.speleo.sk/pipermail/therion/2020-May/008254.html

That seems like a bug to me.

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

Re: [Therion] new Therion 5.5.0

[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] Export EE as .3D and ignore "survey does not exist"

[Olly Betts]

On Sun, Mar 01, 2020 at 09:34:32PM +, Tarquin Wilton-Jones via Therion 
wrote:
> > 1) Is it possible to export an extended elevation as a 3D file (like
> > survex does)? For the purpose of 'debugging' the extends etc.
> 
> I doubt this is entirely possible. There are some kinds of extend
> options that Therion supports but Survex does not, such as "extend
> vertical". So I don't think you could turn it into a Survex-style 3D if
> you use those options.

An "extended elevation" .3d file is really just a normal .3d file with
a flag set (as of v8 of the .3d format there's an explicit flag, while
for older versions it's done by checking for a title ending
" (extended)").  If this flag is present, aven limits the view to be an
elevation looking North or South.

The Survex extend program folds the centreline to lie in an East-West
vertical plane through the origin, with splays rotated along with the
centre-line they're adjacent to but allowed to stick out of this plane.

There's no explicit representation of the extend operations which were
applied, only of the results, so "extend vertical" shouldn't be a
problem.  I can't think of an extend-like feature which couldn't be
easily fitted into this "2D+" representation.

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

Re: [Therion] World Magnetic Model

[Olly Betts]

On Thu, Apr 11, 2019 at 11:08:26PM +0100, Olly Betts wrote:
> 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:
> > > 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.

I've now pushed the changes to the Survex git repo to update to IGRF13,
and they'll be in Survex 1.2.43, hopefully fairly soon (ideally I'd like
to fix a bug with SVG export first).

I see Martin B. updated therion's git repo last month, so the next
therion release should also support IGRF13.

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

Re: [Therion] New development software issue

[Olly Betts]

On Thu, Dec 12, 2019 at 09:46:08PM +, Tarquin Wilton-Jones via Therion 
wrote:
> ERROR: Can not execute "command.com /c "C:\\Program
> Files\\Therion\\therion.exe" -x cave.th
> 
> (I managed to find an old thread with this same message, but there was
> no fix in that thread.)
> 
> However, the build from commit 802ad7c works correctly. Looks like
> commit 19eb624 has a regression that prevents it from running on Windows
> 10 at least (tested on Windows 10 Home only - I don't want to nuke my
> working Pro version, so please don't ask me to test there ;) ).
> 
> There is no "command.com" on Windows 10...

The code in xtherion/global.tcl tries to run cmd.exe first and if that
fails it assumes command.com:

if {[catch {
  set fid [open "|cmd.exe /c" r]
  read $fid;
  close $fid
}]} {
  set xth(gui,compcmd) "command.com /c $xth(gui,compcmd)"
} else {
  set xth(gui,compcmd) "cmd.exe /c $xth(gui,compcmd)"
}

This code hasn't changes for ages.  Perhaps it should just assume cmd.exe
these days, but for now I'd try to work out when cmd.exe /c fails on
your machine.

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

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

[Olly Betts]

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
Description: Allow loch to start without offscreen glXContext
 The call to glXCreateContext() always seems to fail.  in current sid.
 Upstream are investigating, but this is only used to render off-screen images,
 so it's better to let loch run than to give up.
Author: Olly Betts 
Bug: https://github.com/therion/therion/issues/158
Forwarded: no
Last-Update: 2019-12-06

--- a/loch/lxR2P.c
+++ b/loch/lxR2P.c
@@ -48,7 +48,9 @@
r2pc->ctx = glXCreateContext( r2pc->dpy, r2pc->visinfo, NULL, False );
if (!r2pc->ctx) {
   printf("Error: glXCreateContext failed\n");
+#if 0
   exit(-1);
+#endif
}

 }
@@ -74,6 +76,10 @@
   if (c) {
 c->dpy = XOpenDisplay(NULL);
 R2Pmake_context(c);
+if (!c->ctx) {
+  free(c);
+  return NULL;
+}
 R2Pmake_pixmap(c, (unsigned int) width, (unsigned int) height);
   }
 	return c;
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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

[Olly Betts]

On Thu, Dec 05, 2019 at 12:19:12PM +0100, Benedikt Hallinger wrote:
> 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“.

FWIW I see it too.

I don't think it's a wxWidgets bug - this is failing in code in
loch/lxR2P.c which makes calls to the glx layer which is a lower
level API than wxWidgets.  It could be some sort of interaction
with wxWidgets OpenGL support though since it's effectively going
behind wxWidgets back.

I'm not sure why loch doesn't just use wxWidgets OpenGL support - that's
what aven does and that still works in current Debian unstable.

You probably want Martin or Stacho rather than me - they wrote this code
and presumably understand the API it's using and why.

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

That's a development release, so not something we can package for Debian
- every new version would require rebuilding nearly 100 other packages,
and potentially updating them all for API changes.  We have to do that
for a new release series (e.g. moving from 3.0.x to 3.2.x) and it
typically takes 6 months to a year to complete.

I've not tried building packages of 3.1.x so I can't offer any useful
advice there.  But I doubt it's the answer anyway.

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

Re: [Therion] text

[Olly Betts]

On Thu, Sep 26, 2019 at 02:26:18PM +0100, Andrew Atkinson wrote:
> I've been adding text and in the thbook p26 under text
> 
> ", , , ,  ▷ font switches"
> 
> They all work apart from  which as far as I can tell, does nothing?
> 
> What is it mean to do?

Probably select a sans-serif font:

https://en.wikipedia.org/wiki/Sans-serif

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

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

[Olly Betts]

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

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

[Olly Betts]

On Fri, Sep 13, 2019 at 05:54:20PM +0200, Benedikt Hallinger wrote:
> therion: error -- PROJ4 library: -1 (no arguments in initialization list)

OK, this fails for me too.  Thanks for reducing that testcase.

I also spotted that therion had been binNMUed (read "rebuilt against the
latest dependencies") so it is actually fully using PROJ 6.1.0.

I'd guess this is probably a general incompatibility with newer PROJ.

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

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

[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] Detecting errors

[Olly Betts]

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 - there
would be quite a lot of random fluctuation in the observed SDs
from such a short loop, and an equivalent instrument properly calibrated
and used with suitable care really ought to be able to achieve similar
SDs.

Combining information from a lot of such small test loops would be
interesting though.

We've been doing some surface measurements at home with our disto-x2
while planning some building work and I did some experimenting with
setting different SDs and looking at how the loop error values are,
and I found the following SDs seem to be achievable with care:

*sd tape 0.002 metres ; 2 millimetres
*sd compass clino 0.5 degrees
*sd position 0.05 metres ; 5 centimetres

The tape/compass/clino are just taken from Beet's disto-x2 article:
http://paperless.bheeb.ch/download/DistoX2.pdf

I've glossed over exactly what a "precision" of 2mm means and assumed
it's just the standard deviation.  It might actually mean the SD is
even smaller, but that's pretty much irrelevant as the compass, clino
and position errors will swamp any contribution from the tape (1m at
0.5 degrees is 8.7mm).

The position error reflects how close I think I can reliably position
the spot I've marked on the back of the disto relative to the "from"
station plus the error in where the laser beam hits compared to the
"to" station.

I haven't tested if those are still reasonable underground.  There
should be less electromagnetic noise underground, but it's often
colder and wetter underground than in our front garden, and I've found
misty or dusty air can cause problems for the disto.

I'd be interested to hear what people can actually achieve in-cave.

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

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

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

Re: [Therion] Detecting errors

[Olly Betts]

On Thu, Aug 15, 2019 at 10:06:05PM +0100, Olly Betts wrote:
> The colour scale is fixed such that blue is "good" and anything else
> is suspect.  You probably want to look at the worst first.
> 
> Once you have a suspect traverse identified, you can look it up in the
> .err file which is produced alongside the .3d file when you process the
> data.  Here's an example entry:
> 
> 76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
> 76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
> Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   3.90%
> 4.920289
> H: 5.888476 V: 0.864600
> 
> Here 4.920289 is the number of sds (which is what aven colours by).  But
> below that the H and V are the equivalent numbers looking only at the
> horizontal and vertical errors.

Survex 1.2.42 (released yesterday) adds the ability to colour by
horizontal or vertical error (H and V above), so you can zoom in on
a suspect traverse based on the overall error, and then check how
its H and V values compare based on the colouring.

> So here the vertical error is very good,
> and the horizontal error lousy.  That suggests the error is probably either
> in a compass reading or the tape reading in a low-inclination leg.  (If
> H was fine and V bad, you'd be looking for a clino error or a tape error
> in a steep leg or plumb.)
> 
> So you can now look at each of the legs in the list on the first line and
> look at their compass readings and the tape readings for any low-inclination
> legs.  For manually entered data, compare with the original notes.

Another tip is that a common error type is a "mis-tie" - connecting a
new survey to the wrong existing station(s).

This is probably especially prevalent in long running survey projects
with a turnover of the people involved.  For example, it's all to easy
to tie to the "first bolt of the traverse" but fail to realise
somebody's extended the traverse since the original survey.  This sort
of problem affects both electronic and traditional instruments.

My experience is that the largest errors tend to turn out to be
mis-ties (but not all mis-ties result in large errors).  Mis-ties will
tend to have bad H and V, though maybe H will tend to be a bit less bad
(because it's easier to mis-tie to something in the same passage or
chamber, and harder to mix up top vs bottom of a pitch).

If you suspect a mis-tie, I would try simply disconnecting each end of
the problematic survey in turn.  If that makes the remaining network
look good then you can see what stations the disconnected end is near
to give you some candidates to consider for where it perhaps should be
tied to.

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

Re: [Therion] Detecting errors

[Olly Betts]

On Fri, Aug 16, 2019 at 02:23:20PM +1200, Bruce Mutton wrote:
> I'm a Therion user (not Survex), although I use survex loop closure.
> That gives some additional statistics in the Therion log file, but not
> the loop error standard deviations.  I wonder if Therion (or Cavern)
> could incorporate these in the log file, or if Aven could be made to
> list them?

Cavern already produces such a file - that's exactly what the .err file
I'm referring to here tells you:

> > 76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
> > 76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
> > Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   
> > 3.90%
> > 4.920289
> > H: 5.888476 V: 0.864600

I'm not sure what happens to that file when therion calls cavern to
process data though.  I keep my survey data in .svx files and process
as a separate step, then point therion at the .3d file.

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

Re: [Therion] Detecting errors

[Olly Betts]

On Thu, Aug 15, 2019 at 10:17:00AM +0200, MD wrote:
> 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?

I would avoid looking at the percentage error - what's reasonable
varies depending on the number of legs in the loop, and also how
long the legs are, so you can't simply compare the percentage errors
for two different loops.

What's more useful is what the observed error is compared to what you'd
expect the error to be based on the grade(s) of the survey(s).  The
grades say things like "compass readings within one degree" and from
that you can work out what you'd expect the error for each leg to be
(in 3 dimensions) and sum those to get the expected error for each traverse.

Benedikt's suggestion to view coloured by error in aven is where I
would start (right click on the colour key is the easiest way to change
what to colour by).  This shows you each traverse coloured by its error
measured in standard deviations - assuming the grades are appropriate
then 99.7% of readings should be within 3 standard deviations:

https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule

The colour scale is fixed such that blue is "good" and anything else
is suspect.  You probably want to look at the worst first.

Once you have a suspect traverse identified, you can look it up in the
.err file which is produced alongside the .3d file when you process the
data.  Here's an example entry:

76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   3.90%
4.920289
H: 5.888476 V: 0.864600

Here 4.920289 is the number of sds (which is what aven colours by).  But
below that the H and V are the equivalent numbers looking only at the
horizontal and vertical errors.  So here the vertical error is very good,
and the horizontal error lousy.  That suggests the error is probably either
in a compass reading or the tape reading in a low-inclination leg.  (If
H was fine and V bad, you'd be looking for a clino error or a tape error
in a steep leg or plumb.)

So you can now look at each of the legs in the list on the first line and
look at their compass readings and the tape readings for any low-inclination
legs.  For manually entered data, compare with the original notes.

It's still somewhat manual, but at least you can narrow down where to look
significantly.

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

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

[Olly Betts]

On Wed, Aug 14, 2019 at 04:38:20PM -0500, Bill Gee wrote:
> Update:  After poking around a bit, I discovered that Compass will
> calculate cave volume based on centerline and LRUD data.  Doing that
> means I have to run a Windows computer (ugh!) and type in the survey
> data twice (double ugh!)  Fortunately the cave for which I need this
> is small.
> 
> Can this feature be added as a suggestion for future versions of Survex?

There's a ticket open already:

https://trac.survex.com/ticket/80

Julian sketched out what needs doing there, but didn't actually provide
a patch (or else I'd have applied it by now).

But Therion could do a better job here as it has the drawn passage walls
to work from.

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

Re: [Therion] Loch fails on Fedora 30

[Olly Betts]

On Wed, Jul 17, 2019 at 09:22:55PM +0100, James Begley wrote:
> The build of Loch from the copr repository works for me on my fedora 30
> workstation, so I'm guessing that there is an incompatibility with some
> libraries on your laptop and desktop. You say that Loch "no longer works",
> so presumably it used to work? Do you know vaguely when it stopped working?
> Note that the build of Loch in the copr repository hasn't changed since the
> therion 5.4.4 build on the 1st of May, so if Loch was working after that
> date, and isnt working now then it would point to an external library
> problem.
> 
> Your error message points to a problem within the lxR2P.c file (
> https://github.com/therion/therion/blob/master/loch/lxR2P.c) which would
> suggest that the mesa-libGL package might be causing this issue. I've got
> version 19.0.8-1 installed here, which was built on the 26th June (see
> https://koji.fedoraproject.org/koji/packageinfo?packageID=184), but the
> Loch copr package would have been originally built against 19.0.3-1 . Does
> that help? (The mesa changelogs from https://www.mesa3d.org/ don't help me
> very much!).

Currently wxWidgets' OpenGL support requires X and doesn't work with
Wayland.

Fedora now defaults to Wayland, so perhaps Bill is using that default
but James is still using X?

You can override for a single application by running it from a terminal
like so:

GDK_BACKEND=x11 loch

In Survex this workaround is implemented in the aven code, but I don't
see anything equivalent in the therion code.

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

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] Aven colour by loop error

[Olly Betts via Therion]

On Sat, Apr 01, 2017 at 09:10:02PM +1300, Bruce Mutton via Therion wrote:
> The new capability of exporting loop closure information to 3d format is
> helping to identify the bad loops on our surveys.
> 
> Very nice.
> 
> However the scalebar at the top right seems to be locked into a range of 0.0
> to 12.0 (%) error.

Aven's error scale isn't in %, but rather in "sigmas" - i.e. it's how many
times the expected error the observed error is.  Assuming normal distribution
of errors (which sums of random errors will tend towards) anything more than 
3 is only 0.3% likely by random errors, so highly suspect:

https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule

If what Stacho said back in February is still true, therion outputs the
wrong data in this field in the 3d file, so you actually see "2 * relative
error of a loop" there, by which I think he means percentage misclosure.

But as I said at the time, percentage misclosure isn't really a useful
measure of loop quality because the threshold of what is reasonable
varies with the length of the loop:

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

> This is OK for our really nasty loop closures; the maps look suitably
> colourful, but some of our more recent cave surveys don't have error much
> more than 1.5%, so the picture is kind of shades of blue, as below.  It
> doesn't help with visualising the relative quality of the loops.

Unless Stacho has since fixed this, you're actually seeing 0-6% there
currently.

> Would it be possible to change the default scalebar to something like 0.0 to
> 2.0, with the upper limit stepping upwards to suit the data, if there are
> larger loop errors?

I'd much rather we fixed therion to export the correct error information.
Trying to colour based on percentage error just seems to be fundamentally
a less helpful approach.

Also, not varying the colours for a particular number of sigmas depending on
how bad the data is was a deliberate choice.  2 sigmas is no better or worse
just because someone blundered a survey elsewhere.  And if data is surveyed to
a lower quality the grades should be set appropriately to reflect that.

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

[Therion] non-magnetic screws for DistoX2

[Olly Betts]

On Wed, May 04, 2016 at 05:03:05PM +0200, Martin Sluka wrote:
> To replace all steel screw you may use these
> 
> https://de.screwerk.com/shop/detail/stp/STP390200160E.html

I asked Martin about these off-list, as I was wondering how much
difference changing the screws makes - he's not sure, as he has
just aimed to eliminate as many potentially magnetic parts as possible.

But one important detail is that the above link is apparently for the
wrong length, as they need to be 12mm long not 16mm long:

https://de.screwerk.com/shop/detail/stp/STP390200120E.html

There are apparently 8 screws you can change, but the 15 EUR minimum
order on the site means 30 costs the same as 8, so you'd be best off to
club together with some friends.

Cheers,
Olly

[Therion] Therion compiling error (Loch, lxGUI)

[Olly Betts]

On Sat, May 14, 2016 at 03:14:59AM +0100, Wookey wrote:
> +++ Christian Rößler [2016-05-13 23:32 +0200]:
> > Am Montag, 2. Mai 2016, 23:10:06 schrieb Christian Rößler (Roessler):
> > >> I am trying to compile Therion on an openSuse 13.2 64bit, and had no
> > >> success so far. 
> 
> > > But now it hangs at:
> > >> lxGUI.cxx:517:73: error: invalid cast from type ‘wxString’ to type
> > >> ‘const wxChar* {aka const wchar_t*}’
> > >>  #define matchtype(w,t) if (fName.EndsWith((const wxChar
> > >> *)wxString(_T(w return t;
> 
> > well, after reading the hint to that repository, I downloaded it at once, 
> > and read in file changes: VTK 6.0 support. So I compiled it anew, as 
> > working in a virtual machine is sometimes a bit bothersone. But it hangs 
> > at the exactly same point while compiling as mentioned above. So I would 
> > like to ask if there is a solution on the horizon, so to say?
> 
> You might have more joy with the Debian package which is patched to fix 
> various such build-time issues:
> http://httpredir.debian.org/debian/pool/main/t/therion/therion_5.3.16-10.dsc
> and the corresponding .orig.tar.gz and .debian.tar.gz
> That's built against vtk6.2
> 
> This one is built against vtk6.1:
> http://httpredir.debian.org/debian/pool/main/t/therion/therion_5.3.15-2.dsc
> 
> The debian vtk packaging layouts may not exactly match the Suse ones
> but you will probably find clues.
> Or you can look online here (although I don't see anything much that looks 
> relevant):
> https://sources.debian.net/src/therion/5.3.16-10/debian/patches/

The above error sounds like a wx issue not a vtk one, but indeed not one
we seem to have hit in the debian package.

I don't understand why there's a cast to (const wxChar*) there - I'd
try removing that, since that's what's causing the error - i.e. make
that line (loch/lxGUI.cxx line 517):

#define matchtype(w,t) if (fName.EndsWith(wxString(_T(w return t;

Cheers,
Olly

[Therion] Setting Scrap Colours

[Olly Betts]

On Mon, Mar 28, 2016 at 07:47:49AM +0100, Andrew Atkinson wrote:
> Excellent, this has been needed for some time, and opens up lots of
> possibilities.
> 
> Not tested it yet, as I am up mountains.
> 
> Just a thought, would it be possible to assign colour when adding maps to
> another map, so things like water paths can be shown on an overview without
> having to change the maps individually
> 
> Eg
> 
> map detail
> Map1 -colour[100 0 0]
> Map 2 -colour [0 100 0]
> Map3 -colour [0 0 100]
> endmap

That would also naturally extend to support colouring scraps within maps
too.

It probably isn't too hard if you know the code well, but therion
doesn't currently parse options in that position and I'm not sure how to
hook it up to do so.  The current patch just adds a new option to a
place they were already accepted.

Cheers,
Olly

[Therion] Setting Scrap Colours

[Olly Betts]

On Sun, Mar 27, 2016 at 09:44:37AM +0100, Olly Betts wrote:
> On Mon, Mar 14, 2016 at 09:23:39PM +1300, Bruce wrote:
> > Colour by map works just fine, as does colour by scrap or altitude.
> > 
> > In the context of your question I thought you were trying to SPECIFY
> > which colour a particular scrap (or map or altitude) would be
> > assigned.
> 
> I was "commissioned" to implement the ability to specify the colour
> used for each map - patch attached.
> 
> With this (surprisingly small) change you can specify the colour for
> each map, which then overrides the automatic choice when the layout
> specifies "colour map-fg [map]".  Any maps without one get the same
> automatic colour they would before.
> 
> Usage example:
> 
> map 2012.map -projection plan
>   colour [0 70 0]
>   # etc
> endmap

You can also specify the colour on the "map" line (which is probably
clearer):

map 2012.map -projection plan -colour [0 70 0]
  # etc
endmap

Jenny Black produced an example showing what you can do with this patch:

https://survex.com/~olly/107-plan-col-year.pdf

Cheers,
Olly

[Therion] Setting Scrap Colours

[Olly Betts]

On Mon, Mar 14, 2016 at 09:23:39PM +1300, Bruce wrote:
> Colour by map works just fine, as does colour by scrap or altitude.
> 
> In the context of your question I thought you were trying to SPECIFY
> which colour a particular scrap (or map or altitude) would be
> assigned.

I was "commissioned" to implement the ability to specify the colour
used for each map - patch attached.

With this (surprisingly small) change you can specify the colour for
each map, which then overrides the automatic choice when the layout
specifies "colour map-fg [map]".  Any maps without one get the same
automatic colour they would before.

Usage example:

map 2012.map -projection plan
  colour [0 70 0]
  # etc
endmap

You can say "color" instead, if you really must.

Cheers,
Olly
-- next part --
A non-text attachment was scrubbed...
Name: allow-map-colour-to-be-specified.patch
Type: text/x-diff
Size: 2208 bytes
Desc: not available
URL: 

[Therion] Survex Terrain model problem

[Olly Betts]

On Thu, Mar 24, 2016 at 04:30:54PM +0200, Владимир Георгиев 
wrote:
> On Thu, Mar 24, 2016 at 3:50 PM, Olly Betts  wrote:
> > It should be fairly easy to update - just call img_open_write_cs()
> > instead of img_open_write() and pass in the PROJ4 projection string for
> > the output coordinate system as an extra parameter.
> 
> I didn't understand that part. What would be easy to update?

Therion's code should be fairly easy to update.

> Those two functions are part of the Survex source (img.c) from what I see.

Yes.  The second (relatively new) function needs to be used if you want
to specify the coordinate system, but therion probably uses the first
one (which has existed for a very long time).

So it's a matter of changing which function is called by therion, and
passing in the PROJ4 string describing the coordinate system to it.
Therion also uses PROJ4 so the appropriate string should be available.

Cheers,
Olly

[Therion] Survex Terrain model problem

[Olly Betts]

On Thu, Mar 24, 2016 at 03:36:04PM +0200, Владимир Георгиев 
wrote:
> Hmm, you seem to be talking about the original Survex data file. I see the
> format is similar to the .th files, but I meant producing a 3D file
> exported from Therion.
> 
> In the Therion data I have a CS command and a fixed station, but maybe this
> is not exported to the 3D file for consuming by Survex.

I suspect therion hasn't yet been updated to include coordinate system
information when it exports a .3d file.

It should be fairly easy to update - just call img_open_write_cs()
instead of img_open_write() and pass in the PROJ4 projection string for
the output coordinate system as an extra parameter.

> Most of the 3D file looks binary and I can't find out whether it
> contains this info or not.

You can see if you use the "dump3d" tool - it'll include a "CS" line in
the header section if the coordinate system is specified, e.g.:

CS +proj=utm +ellps=WGS84 +datum=WGS84 +units=m +zone=33 +no_defs

Or look for a string starting "+proj" near the start of the file itself.

But if aven says there's no coordinate system specified, it's just
checked that for you.

Cheers,
Olly

[Therion] What means that or where is the fault?

[Olly Betts]

On Sun, Feb 21, 2016 at 10:37:28PM +, Footleg wrote:
> Or possibly you have incompatible versions of Therion and Survex installed?
> Make sure you have a recent Survex version for the current Therion, or
> Survex is called by Therion to produce a file which Therion is not able to
> read (because the format changed in the Survex output).

You do want a recent Survex version (or a sufficiently old one), but
the reason isn't a format change.

On Microsoft Windows, therion currently assumes that the file
association set for processing .svx files runs cavern, which isn't true
by default for Survex 1.2.23 and later (instead aven is now run).

I added a workaround for this in Survex 1.2.24 - if aven is run in the
invalid way which results from this, it runs cavern instead.  This is
ugly, but shouldn't break anything else and is enough to make therion
happy for now.

So this should only be an issue with Survex 1.2.23.  If you still see
it after upgrading to a newer version, I'd try uninstalling and
reinstalling (I'm not sure if the file associations get updated when
upgrading).

It would be good to fix therion not to make this assumption though.
Aside from the issue above, the user can change file associations to
anything they like.

Cheers,
Olly

[Therion] new Therion?

[Olly Betts]

On Tue, Dec 01, 2015 at 03:20:30PM -0500, Philip Balister wrote:
> https://github.com/Cavewhere/cavewhere/blob/master/LICENSE.txt
> 
> After a quick look, I do not recognize what license family it is.

Looks like Apache 2.0 to me, though I didn't compare the text in detail:

http://www.apache.org/licenses/LICENSE-2.0

If so, you can make a derived work with GPL v2+ software by using the
latter under GPLv3.

Cheers,
Olly

[Therion] Can't Open Cavern Log File For Input

[Olly Betts]

On Mon, Sep 21, 2015 at 01:15:37AM +0100, Olly Betts wrote:
> Looking at the code in therion to find cavern, it looks in the registry
> for the file associations which Survex's installer sets up.
> 
> This is the code therion uses:
> 
> if 
> (RegOpenKey(HKEY_CLASSES_ROOT,"survex.source\\shell\\Process\\command",&key) 
> != ERROR_SUCCESS)
> 
> There are two issues with this:
> 
> One is that it only looks under HKEY_CLASSES_ROOT - if Survex was
> installed a non-admin/power-user, then this setting will be under the
> user classes instead (so it ought to also check HKEY_CURRENT_USER).

It seems this isn't actually true on Vista and later - there the Survex
installer should prompt you to log in as an admin or power user if you
aren't already (and the checks for the user being an admin or power user
the installer script does are pointless).

I guess the lack of people moaning about not being able to install
Survex as a normal user means this isn't a great imposition.  We could
allow it but it would either mean that Survex was only usable by the
user who installed it, or that there were two different installers
and you had to download the right one.

So this probably isn't Nick's issue.

> The other is that it assumes that cavern is the program run here, but as
> of Survex 1.2.23 .svx are set up to process using aven by default, so
> this will find aven.exe not cavern.exe.  A simple workaround would be to
> replace "aven" with "cavern" in the leafname of the value returned.
> This is the issue Jenny's hitting.

I've added a bodge to make this work as is in Survex 1.2.24 (just
released), and Jenny's tested it.

I'd still recommend that therion use the workaround above, as currently
you'll get the additional overhead of aven being run, realising it was
called by therion, and then running cavern.

Cheers,
Olly

[Therion] Can't Open Cavern Log File For Input

[Olly Betts]

On Mon, Sep 21, 2015 at 09:22:02AM +1200, Jenny wrote:
> Are your different machines running the same version of survex? I get
> that error too, but only when I am running the latest version of
> survex (1.2.23), if I go back to 1.2.20 then therion works fine. (This
> is also on windows 7).

Looking at the code in therion to find cavern, it looks in the registry
for the file associations which Survex's installer sets up.

This is the code therion uses:

if 
(RegOpenKey(HKEY_CLASSES_ROOT,"survex.source\\shell\\Process\\command",&key) != 
ERROR_SUCCESS)

There are two issues with this:

One is that it only looks under HKEY_CLASSES_ROOT - if Survex was
installed a non-admin/power-user, then this setting will be under the
user classes instead (so it ought to also check HKEY_CURRENT_USER).
My guess is that Nick is install Survex this way, so this is the cause
of his problem.

The other is that it assumes that cavern is the program run here, but as
of Survex 1.2.23 .svx are set up to process using aven by default, so
this will find aven.exe not cavern.exe.  A simple workaround would be to
replace "aven" with "cavern" in the leafname of the value returned.
This is the issue Jenny's hitting.

Cheers,
Olly

[Therion] How to create KML files

[Olly Betts]

On Sun, Mar 22, 2015 at 10:04:42PM -, Henry Bennett wrote:
> Bill Gee writes:
> > "therion: warning -- data not georeferenced -- unable to export KML file"
> > 
> > I think this is because I have not included latitude/longitude information.
> > 
> > My question is ...  How is latitude and longitude specified?
> > 
> > Reading through the Therion book, it seems it is done in the "cs" statement 
> > within the centerline.  However, the syntax is not clear.   Are there any 
> > examples that show how it is done?

> Use Fix
> 
> http://therion.speleo.sk/wiki/doku.php/tbe:wiki2?s[]=fix&s[]=entrance

You need to both specify a coordinate system with "cs" *and* use "fix"
to locate at least one station in that coordinate system, e.g.:

cs long-lat
fix entrance -77.0365 38.8977 30

That assumes datum WGS84 (which is what your GPS probably gives you by
default).

You can't use lat/long as the output coordinate system, as that needs to
use length units.  I don't know off-hand if therion picks a suitable
one for you - if not, you'll need to specify a suitable output
coordinate system in your config file - e.g. 'cs utm' where  is
the UTM zone you are in.

Cheers,
Olly

[Therion] MacOSX error and solution: ImageMagick after upgrading from Mt.Lion to Mavericks

[Olly Betts]

On Sat, Feb 21, 2015 at 08:40:57PM +0100, Martin Sluka wrote:
> Why is ImageMagick trying to load JPG coder at
> /usr/local/Cellar/imagemagick/6.8.8-9/lib/ImageMagick//modules-Q16/coders/jpeg.la?
> Why the double slash after ImageMagick// ?

Repeating a slash (any number of times) in a Unix filename is generally
ignored (the OS itself should ignore it, though programs which parse
filenames might not be written with the possibility in mind).

A doubled slash often arises from building a path like:

   directory + '/' + relative_path

when directory already has a trailing '/'.

Cheers,
Olly

[Therion] Therion wx3 support tweaks

[Olly Betts]

Patch attached to fix some lingering issues.

One is that wxGLCanvas::OnSize() is deprecated in 3.0 - the portable
(between platforms and wx versions) way to achieve this is to call
event.Skip(); which will cause the event to be propagated to the base
class.  AIUI, the only platform this matters on is OS X, which I can't
test on - it would be useful to confirm that resizing the window still
works on OS X.

The other was in my original patch, but got lost when it was applied.
As a result wx3 gives an "assertion failed" if loch fails to load a
file.  The issue here is that the wxWindowDisabler needs to be off
before the messagebox gets shown, which I had carefully arranged by
reordering code and adding an extra { } block around just the section
which needs protecting.  I've added a comment this time, to document the
reason for the extra { } block.

Cheers,
Olly
-- next part --
A non-text attachment was scrubbed...
Name: wx3.0-leftovers.patch
Type: text/x-diff
Size: 1958 bytes
Desc: not available
URL: 

[Therion] Bug#751471: Bug#751471: Therion hanging after compile

[Olly Betts]

On Tue, Jan 13, 2015 at 12:01:51AM +, Olly Betts wrote:
> On Mon, Jan 12, 2015 at 04:29:09PM +0100, Stacho Mudrak wrote:
> > I am sorry, I was never able replicate this bug.
> 
> You need a large log file for it to be noticeable, as the problem seems
> to be that trying to match this pattern causes Tcl's regexp engine to do
> a lot of backtracking:
> 
>   set rx {\S*[^\]\s]\s+\[\d+\]}
> 
> I don't really follow the Tcl code around this, but if this is trying to
> match on lines such as:
> 
> 2253> input:42871 -- gemse.th [4]
> 
> Then adding "-- " to the start of the pattern and then adjusting the
> offsets when highlighting in the text widget should address the problem.
> The fixed substring "-- " serves as a way to efficiently limit where the
> regexp engine tries to match the pattern.

I managed to guess enough tcl and tk to implement this, patch attached
which fixes the 10 minute wait while xtherion parse the log, while still
creating the links as before (at least as best I can tell).

Cheers,
Olly
-- next part --
A non-text attachment was scrubbed...
Name: fix-log-file-regexp-backtracking.patch
Type: text/x-diff
Size: 1099 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150113/953273d3/attachment.patch>

[Therion] Bug#751471: Bug#751471: Therion hanging after compile

[Olly Betts]

On Mon, Jan 12, 2015 at 04:29:09PM +0100, Stacho Mudrak wrote:
> I am sorry, I was never able replicate this bug.

You need a large log file for it to be noticeable, as the problem seems
to be that trying to match this pattern causes Tcl's regexp engine to do
a lot of backtracking:

  set rx {\S*[^\]\s]\s+\[\d+\]}

I don't really follow the Tcl code around this, but if this is trying to
match on lines such as:

2253> input:42871 -- gemse.th [4]

Then adding "-- " to the start of the pattern and then adjusting the
offsets when highlighting in the text widget should address the problem.
The fixed substring "-- " serves as a way to efficiently limit where the
regexp engine tries to match the pattern.

> If it is this regex that causes problems, it can be removed completely. It
> is used to enable clicking on error source and opening in in appropriate
> editor. Feature almost never used.

If you think it's best just to kill it, that's fine, but I can probably
package up the example that we hit this on if you want to take a look,
and I can certainly test a patch.

Cheers,
Olly

[Therion] therion 5.3.16

[Olly Betts]

On Wed, Jan 07, 2015 at 09:11:06AM +, Wookey wrote:
> +++ Stacho Mudrak [2014-12-30 11:09 +0100]:
> >  * 82-nolang-segfault-fix.patch  (this avoids a genuine error case of
> >  language not being defined)
> > 
> >I believe, this error is already fixed. Are you able to reproduce it with
> >current version of therion?
> 
> I can't remember what the issue was or how to reproduce it. Anyone remember?

No, but thlang_getid() now starts with an explicit check to handle the
case where the id is -1, so the patch is clearly no longer needed:

const char * thlang_getid(int id) {
  if (id < 0) {
return "en";
  }

In 5.3.11 (which the patch was created from judging by the paths), this
check isn't present, though it looks to me like thlang_getlang() will
map -1 (which is THLANG_UNKNOWN) to something valid, so it looks to me
like it wasn't actually useful even there.

Perhaps the patch is actually older and was just regenerated for 5.3.11,
but debian/changelog doesn't seem to actually mention it being added,
and the packaging isn't kept in a VCS, so it's harder to check than I
can be bothered to.

The important conclusion is that it clearly isn't useful for 5.3.16.

Cheers,
Olly

[Therion] Therion fails to compile with vtk 6

[Olly Betts]

On Mon, Dec 15, 2014 at 07:32:53PM -0600, Bill Gee wrote:
> I took a stab at changing the loch Makefile manually.  It still fails, but 
> now 
> it has yet another message.  Here is the last few bits from the compile run.
> 
> ==/usr/lib64/
> gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX  -I/usr/lib64/wx/include/gtk2-
> unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -
> D_LARGE_FILES -D__WXGTK__ -pthread  -o .././loch/img.o img.c
> c++ -o .././loch/loch -Wall .././loch/lxR2P.o .././loch/lxTR.o 
> .././loch/lxOGLFT.o .././loch/lxSetup.o .././loch/lxRender.o .././loch/lxWX.o 
> .././loch/lxImgIO.o .././loch/lxLRUD.o .././loch/lxFile.o .././loch/lxSTree.o 
> .././loch/lxData.o .././loch/lxMath.o .././loch/lxSView.o 
> .././loch/lxSScene.o 
> .././loch/lxGUI.o .././loch/lxGLC.o .././loch/lxOptDlg.o 
> .././loch/lxAboutDlg.o .././loch/img.o -lwx_gtk2u_gl-2.8 -pthread 
> -Wl,-z,relro   
> -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -
> lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -
> lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8  -L/usr/lib/vtk-5.4 -
> lvtkCommonExecutionModel-6.1 -lvtkCommonDataModel-6.1 -lvtkCommonCore-6.1 -
> lvtkFiltersCore-6.1 -lvtkFiltersHybrid-6.1 -lvtkIOLegacy-6.1 -lfreetype -lGLU 
> -lpthread -lz  -s
> /usr/bin/ld: cannot find -lvtkCommonExecutionModel-6.1
> /usr/bin/ld: cannot find -lvtkCommonDataModel-6.1
> /usr/bin/ld: cannot find -lvtkCommonCore-6.1
> /usr/bin/ld: cannot find -lvtkFiltersCore-6.1
> /usr/bin/ld: cannot find -lvtkFiltersHybrid-6.1
> /usr/bin/ld: cannot find -lvtkIOLegacy-6.1
> collect2: error: ld returned 1 exit status
> make[1]: *** [.././loch/loch] Error 1
> make[1]: Leaving directory `/home/bgee/Installs/therion/loch'
> make: *** [loch/loch] Error 2
> ==
> 
> I noticed a section at the top of the Loch Makefile where it is using some 
> tcl 
> programs to find where vtk is installed.  This starts on line 14.  On my 
> systems the three tcl programs return data as if vtk 5.4 were installed.  The 
> system has no trace of vtk 5.4 left on it.  The two directories returned for 
> VTKPATH and VTKLIBPATH do not exist.  Will this cause any problems?

Looking at getvtkver.tcl it assumes 5.4 if it can't find a vtk install,
so I suspect that's what is happening for you.

On Debian unstable, VTKPATH is /usr/include/vtk-6.1 (correct) but
VTKLIBPATH is /usr/lib/vtk-6.1 (wrong).  But the latter doesn't matter,
as the libraries are in /usr/lib/x86_64-linux-gnu which is on the
default linker search path, so are found anyway.

It looks like your build finds the headers (so VTKPATH isn't a problem)
but fails to find the libraries when it comes to link.  If you can
determine the correct directory, you can probably override by passing it
on the command line, like so:

make VTKLIBPATH=/usr/lib64/vtk6.1

Cheers,
Olly

[Therion] Therion fails to compile with vtk 6

[Olly Betts]

On Sun, Dec 14, 2014 at 08:23:23PM -0600, Bill Gee wrote:
> Thanks for the reply.  I downloaded the patch file vtk6.patch and tried to 
> apply it to the Therion 5.3.15 source tree.  It looks like the first part 
> worked but not the second.  Here is the output from patch:
> 
> ===
> [bgee at main2 therion]$ patch -p1 -i vtk6.patch 
> patching file loch/lxData.cxx
> Hunk #1 succeeded at 540 (offset 5 lines).
> Hunk #2 succeeded at 582 (offset 5 lines).
> patching file loch/Makefile
> Hunk #1 FAILED at 37.
> 1 out of 1 hunk FAILED -- saving rejects to file loch/Makefile.rej
> [bgee at main2 therion]$ 
> ==
> 
> If I try to compile this, it goes further than before but still fails while 
> processing loch.  It appears to still be looking for vtk libraries in the 
> vtk-5.4 directory.

That's probably just a consequence of the changes to loch/Makefile not
getting applied (since that's where those libraries are specified),
which is probably because some earlier patch in the huge pile we're now
carrying also changed that area of that file.

If you look at loch/Makefile.rej, you can probably make the required
changes to loch/Makefile by hand.

Alternatively, applying all the patches in the order given in the series
file should work - you can get quilt to do that with:

QUILT_PATCHES=/path/to/debian/patches quilt push -a

Cheers,
Olly

[Therion] Therion fails to compile with vtk 6

[Olly Betts]

On Thu, Dec 11, 2014 at 12:42:24PM -0600, Bill Gee wrote:
> Based on this it appears to me that major changes have been made
> between vtk 5 and 6.   Eventually I am sure other people will run into
> this problem.

I already fixed this for the Debian package - you can find a patch here:

http://sources.debian.net/src/therion/5.3.15-2/debian/patches/vtk6.patch/

It would be great if more of the patches we're carrying in Debian got
merged so that others didn't hit these same problems and have to try to
fix them again for themselves:

http://sources.debian.net/src/therion/5.3.15-2/debian/patches/

If there's anything Wookey or I can do to help get them merged, please
say.

Cheers,
Olly

[Therion] Bug#751471: Therion hanging after compile

[Olly Betts]

# Having to wait 10 minutes counts as a major effect on usability
Control: severity -1 important

On Sat, Jun 14, 2014 at 12:16:27PM +0100, Olly Betts wrote:
> On Fri, Jun 13, 2014 at 11:15:26AM +0100, Wookey wrote:
> > +++ Jenny Black [2014-06-11 19:12 +1200]:
> > > Olly has just had a look (thank you Olly!), and in xtherion he changed:
> > > set rx {\S*[^\]\s]\s+\[\d+\]}
> > > to:
> > > set rx {\s\[\d+\]}
> > > It now no longer hangs, and runs as well as ever. We're not sure
> > > what the regular expression search was for, or whether changing it
> > > matters. As far as I can see it doesn't, as the pdf and log files
> > > have already been made.
> > 
> > Just noticed this. Well fettled. I've filed a bug in Debian BTS about
> > this so it doesn't get forgotten. 
> > 
> > I'll do a 5.3.15 upload with this and ol's other fixes in very soon.
> 
> I'm not at all confident this fix is correct - my grasp of Tcl is
> insufficient to understand what the code is actually doing with this
> regex.
> 
> All I did was to prune the bit off the start of the pattern which was
> causing the regex engine to do insane amount of backtracking (which
> with a large log file could easily result in it taking 10 minutes to
> run this regex over the whole log).
> 
> So you might want to wait for comments from Stacho or Martin before
> shipping this.

After staring some more, I'm fairly sure my patch doesn't actually
constitute a fix (it was never really intended to - I just meant it to
show what was taking all the time).

But it would be good to fix this before the Debian release freeze, so in
the absence of any clues as to what this code is trying to do (as far as
I can make out so far, it seems to be parsing a log to get a list of
errors to show), I'll sit down with the tcl docs and figure it out.

Cheers,
Olly

[Therion] What is going on with these survey legs?

[Olly Betts]

On Mon, Sep 08, 2014 at 01:47:57PM -0500, Bill Gee wrote:
> The starting point is two azimuth readings.  Call them FOR1 and BACK1.
> 
> 1) FOR2 = BACK1 + 180
> 2) FOR2 = FOR2 MOD 360.0
> 3) If (FOR1 - FOR2) > 180 then FOR2 = FOR2 + 360.0
> 4) FINAL = ((FOR1 + FOR2) / 2) MOD 360.0)

For 1 and 179, that gives me 180, rather than 0.

What Survex does is more complex, as the foresight and backsight may
have different standard deviations specified, and it's working in
radians at this point, but in the case where the two instruments are the
same specified accuracy (which seems likely to be by far the most
common), it boils down to this (fabs() is the absolute floating point
value - i.e. drop any minus sign):

backcomp -= 180;
diff = comp - backcomp;
adj = fabs(diff) > 180 ? 180 : 0;
final = (comp + backcomp) / 2 + adj;

You can see the full version here:

https://github.com/ojwb/survex/blob/master/src/datain.c#L893

That's pretty close to what you have - I think the key difference is
the fabs() on the wrap-around check.

I believe I proved that the averaging algorithm Survex uses was correct
back when I implemented this, though unhelpfully I didn't add the proof
as a comment in the code.

Though looking at the code now, I think it should be wrapping the
two bearings to the range [0,360) after it corrects for zero errors
and declination and before it does the actual averaging.  I'll take
a look at that.

Footleg's idea of averaging vectors is interesting - I'd not thought
about that before.  One nice feature is that it naturally extends to
more than 2 bearings.  It also helpfully gives "invalid" for trying to
average bearings which completely oppose (whereas feeding the same
bearing in as foresight and backsight above will give you a bearing
that's 90 degrees away to one side or the other, arbitrarily).

Cheers,
Olly

[Therion] Fw: therion 5.3.15-2 MIGRATED to testing

[Olly Betts]

On Sun, Aug 24, 2014 at 05:53:16PM +0100, Wookey wrote:
> Thanks to Olly for getting things to actually work, Therion (using
> wx-widgets3.0 and vtk6) is now back in Debian ready for the next stable
> release early in 2015.

I already sent the patch for vtk6 support.

Here's a patch which updates therion's use of wxGLCanvas, etc to the
revised API (this one works with wx 2.8 too):

http://sources.debian.net/src/therion/5.3.15-2/debian/patches/wx-gl-api-update.patch/

There's a second patch which more directly addresses wx 3.0
compatibility.  I haven't checked this wx 2.8, but I think most of
it should be fine, perhaps all:

http://sources.debian.net/src/therion/5.3.15-2/debian/patches/wx3.0-compat.patch/

It would be good to see some of these patches merged back in.  If
there's a way I can present them more helpfully, let me know.

Have you considering having a public code repo?  That would make
it easier to send patches which apply to the latest unreleased
version of the code.

Cheers,
Olly

[Therion] Survey length anomalies

[Olly Betts]

On Sun, Aug 24, 2014 at 11:55:29AM +0200, Martin Sluka wrote:
> 24. 8. 2014 v 8:33, Olly Betts :
> > Survex treats cartesian data as counting in the survey length by
> > the same rules as other measured data styles, and nosurvey data never
> > counts towards the surveyed length (it's assumed to be used for things
> > like visual connections or other unsurveyed links like you say, and
> > really the clue is in the name).
> 
> This is the way how to recreate missing data set from published map,
> isn't it.

You're replying to a paragraph talking about both the cartesian and
nosurvey styles, so I'm not totally sure which you mean by "this".

I've certainly done that with the cartesian style, but if you don't want
the recreated data to be measured, you can flag it as "duplicate",
though one could argue it should count towards the surveyed length
- if there's a map it presumably was surveyed, but the data has been
lost.  That's certainly the case for some older CUCC finds.

I don't think this is really a good use of the nosurvey style - you
could calculate where the reinvented stations would be and *fix them,
then add nosurvey legs for the passages, but that doesn't play well with
adding fresh survey data in later - you probably want to trust the newer
data more than the reinvented, but with *fix, the reinvented data is
treated as the (under)ground truth.

Cheers,
Olly

[Therion] Survey length anomalies

[Olly Betts]

On Sun, Aug 24, 2014 at 09:18:20AM +1200, Bruce wrote:
> A bug?  Depends on point of view I guess, cartesian implies no actual
> distance measured, so zero survey length, but the definition of two points
> does have some parallels with a 'shot' and hence survey length.

I don't think that is implied - it's just a different way of specifying
measurements between two points.

When we added it to Survex originally the idea was it provided a way
to specify measurements which didn't fit any of the other supported
data styles, without forcing people to invent tape/compass/clino data 
from such measurements.

> I have not checked any of the other data survey formats.
> Other peoples thoughts on this?

FWIW, Survex treats cartesian data as counting in the survey length by
the same rules as other measured data styles, and nosurvey data never
counts towards the surveyed length (it's assumed to be used for things
like visual connections or other unsurveyed links like you say, and
really the clue is in the name).

I hadn't thought about something like you GPS trail example where
an instrument produces a series of absolute positions before.  Perhaps a
measured version of "nosurvey" would be useful, though I'm not sure we
yet have something which can do that underground.  Radiolocation could
theoretically, but practically it takes too long to set up at each
position to be a sane option for surveying a series of points along a
passage using it, unless things have evolved a lot since I was last
involved.

Cheers,
Olly

[Therion] What is going on with these survey legs?

[Olly Betts]

On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote:
> I am struggling with a couple of survey shots that Therion is not 
> interpretting correctly.  It might be a bug in how Therion averages forward 
> and backward compass when the readings are near 360 and 180 degrees.

There's a bit of a gotcha when averaging compass readings, due to the
wrap-around at 360/0 degrees.

For example, if we try to average two readings: 359 and 003, then the
correct answer (at least assuming we believe them to be equally
accurate) would be 001.  But if we naively sum and divide by the number
of readings, we get (359+003)/2 = 362/2 = 181.

The same issues affects averaging forward and back sights - the only
different is that the back sights get altered by 180 degrees before
averaging.

I've not tried to find where in therion this is implemented, but it
appears to explain what you are seeing here - assuming therion subtracts
180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 =
180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the
second.

> One of the shots (B11-B12) has compass readings of exactly 0 and 180.  This 
> shot displays correctly on the map.

In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this
case also fits my hypothesis.

Survex is careful to get these cases right, but unfortunately it seems
that when therion uses Survex to process the centreline data, it does
the backreading averaging itself before it passes data to Survex, so
that doesn't provide a way to work around this problem.

You could put the centreline data in a .svx file, and tell therion to
process that and use the .3d file.

Cheers,
Olly

[Therion] Patch for VTK6 support

[Olly Betts]

Hi folks,

Attached is a patch to make therion (in particular loch) work with vtk6.
We're now using this patch in the Debian package, since Debian is
switching from vtk5 to vtk6.

My understanding is that loch currently uses compatibility functions
which support vtk4-style code, and that the code changes should be
compatible with vtk5 too.  That's based on this page (I didn't test
with vtk5):

http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Replacement_of_SetInput

Cheers,
Olly
-- next part --
A non-text attachment was scrubbed...
Name: vtk6.patch
Type: text/x-diff
Size: 2974 bytes
Desc: not available
URL: 

[Therion] Some patches

[Olly Betts]

On Sat, Jun 07, 2014 at 06:43:09AM +0100, Olly Betts wrote:
> therion-document-missing-cs.patch
> 
> Not all the coordinate systems which therion understands are listed
> in the manual - this patch adds the missing ones, though I don't know
> what JTSK03, IJTSK03 or S-MERC are, so please fill in where the '?' are.

It appears "S-MERC" is the spherical mercator projection often known as
"Web Mercator", as used by various online mapping sites (e.g.
OpenStreetMap, Google maps, Bing maps).

Cheers,
Olly

[Therion] Aven colour by date and loop error

[Olly Betts]

On Sun, Jul 06, 2014 at 02:23:41PM +1200, Bruce wrote:
> Also, I presume that colour by date in Aven refers to 'survey date'.  Is
> colour by 'exploration date' something that has been considered?

It's whatever you put in the *date commands - that's expected to be the
survey date, but it isn't currently used for anything like autocomputing
the declination.  But that doesn't really help if you want both dates
available.

I'm planning to add exploration date at some point, but it'll need
another revision of the 3d file format, so I'm going to try to sort out
all the other things which need such a revision (like other survey
metadata) and do them all together rather than have a new version of
the format every release or two.

Although now I think about it, it might be possible to avoid that -
e.g. setting the date twice without anything in between could be
defined to mean the first date is the exploration and the second the
survey date, but existing readers would see this as if the first
setting wasn't there, and existing writers shouldn't produce this.
Maybe there's some problem I'm overlooking, but it seems plausible.

> In a serendipitous world Olly would add this extra bit to Aven (PS I
> like the new zoom to box feature in 1.2.14 Olly)

Me too.

> and then Martin/Stacho would support these features in the export
> models.

The aven part isn't much work once the data is available in the 3d
format.

Cheers,
Olly

[Therion] Therion hanging after compile

[Olly Betts]

On Fri, Jun 13, 2014 at 11:15:26AM +0100, Wookey wrote:
> +++ Jenny Black [2014-06-11 19:12 +1200]:
> >Olly has just had a look (thank you Olly!), and in xtherion he changed:
> >set rx {\S*[^\]\s]\s+\[\d+\]}
> >to:
> >set rx {\s\[\d+\]}
> >It now no longer hangs, and runs as well as ever. We're not sure what the
> >regular expression search was for, or whether changing it matters. As far
> >as I can see it doesn't, as the pdf and log files have already been made.
> 
> Just noticed this. Well fettled. I've filed a bug in Debian BTS about
> this so it doesn't get forgotten. 
> 
> I'll do a 5.3.15 upload with this and ol's other fixes in very soon.

I'm not at all confident this fix is correct - my grasp of Tcl is
insufficient to understand what the code is actually doing with this
regex.

All I did was to prune the bit off the start of the pattern which was
causing the regex engine to do insane amount of backtracking (which
with a large log file could easily result in it taking 10 minutes to
run this regex over the whole log).

So you might want to wait for comments from Stacho or Martin before
shipping this.

Cheers,
Olly

[Therion] wxWidgets 3.0.0

[Olly Betts]

On Sat, Jun 14, 2014 at 12:16:31PM +0200, Stacho Mudrak wrote:
> Unfortunatelly, I do not understand what exactly is the problem with wx 3.0.
> 
> I have installed debian jessie/sid on my virtual linux box and all I needed
> to do to get therion 5.3.15 working was related to VTK6.
> 
> I needed to change lxData.cxx and link all existing vtk libraries in the
> system this dirty way:
> 
> VTKLIB = $(addprefix -l,$(subst xxxlib,,$(addprefix xxx,$(notdir $(basename
> $(shell ls /usr/lib/x86_64-linux-gnu/libvtk*-6.1.so))
> VTKLIBS = $(VTKLIB) -lfreetype -lpng -ljpeg
> 
> No need to change anything with wx3.0.
> 
> When I run loch - it prints a lot of assertions, but it runs without any
> problem, if I click to ignore them.

My patch from the message at start of this thread should fix those
assertions.

Another option is to build with -DNDEBUG - this will disable these
assertion messages, and wx3.0 will then handle these cases quietly, just
like it does in a default build of wx2.8.  However, these assertions are
due to incorrect uses of the wx API, so it's better to try to actually
deal with them really.

The assertion dialogs appearing will of course change the timing though,
so you may find that without them you see the problems I do.

> I have not yet tested Olly's patches, I have done this two weeks ago
> or so.

This isn't one of the patches I sent recently - it was sent to this
list in November last year:

http://thread.gmane.org/gmane.comp.gis.therion/3886

The more recent patches aren't connected to wx3.0 support.

> Even running loch with filename as argument works fine. I have not
> tried on a box with 3D hardware acceleration, may be there timing
> issue will rise. But is this related with wx3.0? As far as I know,
> there were problems with intel 3D cards on Linux box from the
> beginning.

I think I did compare results with the build of loch already in Debian,
but I'll recheck.  FWIW, I do have intel graphics hardware in the
machine I have been testing on, but other 3D stuff seems to work fine.

Cheers,
Olly

[Therion] Some patches

[Olly Betts]

Hi therioneers,

Attached are five patches:

therion-document-missing-cs.patch

Not all the coordinate systems which therion understands are listed
in the manual - this patch adds the missing ones, though I don't know
what JTSK03, IJTSK03 or S-MERC are, so please fill in where the '?' are.

therion-fix-init-order.patch

In C++, class members are initialised in the order declared in the
class, and it's clearer if the order of the initialiser list matches
the order the members are actually initialised in.  Some compilers
will issue a warning if they don't match.

therion-fix-memory-leak.patch

Free the memory proj_init_plus() allocates.

therion-fix-typo.patch

Fix a typo.

therion-remove-unsigned-less-than-zero-checks.patch

These checks can never be true, since size_t is unsigned.  I've removed
them in the patch, though perhaps these checks were intended to be ==0
rather than <0?

Cheers,
Olly
-- next part --
A non-text attachment was scrubbed...
Name: therion-document-missing-cs.patch
Type: text/x-diff
Size: 1258 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: therion-fix-init-order.patch
Type: text/x-diff
Size: 579 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: therion-fix-memory-leak.patch
Type: text/x-diff
Size: 388 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: therion-fix-typo.patch
Type: text/x-diff
Size: 608 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: therion-remove-unsigned-less-than-zero-checks.patch
Type: text/x-diff
Size: 608 bytes
Desc: not available
URL: 

[Therion] version 5.3.15

[Olly Betts]

On Thu, May 29, 2014 at 03:59:43AM +0100, Wookey wrote:
> (Also Olly posted about the similar transition from wx2.8 to wx3.0 a
> while back, and how it produced a couple of bugs. Any chance someone
> can look at that too?) 
> https://release.debian.org/transitions/html/wxwidgets3.0

I tested 5.3.15 with wx3.0 yesterday and it still doesn't work.

> vtk6 build failure:
> c++ -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX 
> -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 
> -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ 
> -pthread -I/usr/include/freetype2 -I/usr/include/vtk-6.1  -o 
> .././loch/lxData.o lxData.cxx
> lxData.cxx: In member function 'void lxData::Rebuild()':
> lxData.cxx:538:28: error: 'class vtkPolyDataNormals' has no member named 
> 'SetInput'
>this->scrapWallsNormals->SetInput(this->scrapWalls);
> ^

I looked very briefly at this yesterday too - it looks like SetInput()
needs to be replaced by either SetInputConnection() or SetInputData(),
depending on context:

http://www.vtk.org/Wiki/VTK/VTK_6_Migration/Replacement_of_SetInput

Seems that should also work with VTK5.

Cheers,
Olly

[Therion] New release of Cave Converter

[Olly Betts]

On Sun, Apr 13, 2014 at 03:05:33PM +0100, Footleg wrote:
> - Added substitution of illegal characters in series and station names to
> Survex format output.
>   Compass files allow various punctuation characters in series and station
> names, which are not
>   allowed in Survex format data files. These will be substituted by an
> underscore character followed
>   by a two letter code indicating the character which was substituted (e.g.
> '!' becomes '_ex').

You can specify the non-alphanumeric characters for Survex to allow in a
station name, for example if you want "!" to work in addition to the
default of "_", you can use:

*set names _!

Cheers,
Olly

[Therion] Importing Compass files

[Olly Betts]

On Sat, Jan 18, 2014 at 05:03:20PM -, Graham Mullan wrote:
> Thanks Jonny, I assume that would be by using similar syntax to that
> used to import Survex.3d files.

Therion's support for importing Compass PLT files is provided by the
"img" library from Survex, which primarily provides reading and writing
of .3d files, but can also read Survex .pos files, Compass PLT, and
CMAP XYZ files.  The syntax should be the same except for the filename
extension.

If there are other formats people would find it useful to be able to
read, it's probably not hard to add support for them.

Cheers,
Olly