Re: [Therion] World Magnetic Model
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
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?
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
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?
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?
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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?
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?
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?
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?
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