- Therion - speleo.sk

specific which label appears in output
by Axel 31 Jan '21

31 Jan '21

2 2

Matrix of heights from Lidar data?
by Martin Sluka 22 Jan '21

22 Jan '21

Hi, anybody has a recipe how to extract matrix of heights from Lidar data preferred a free solution. Martin

2 1

Metapost inspirations
by Martin Sluka 15 Jan '21

15 Jan '21

Some advanced Metapost code for ancient looking illustrations (or maps): https://github.com/jemmybutton/fiziko https://m.habr.com/en/post/454376/ https://habr.com/ru/post/423571/?_ga=2.47603047.1584527340.1610742907-19622… Enjoy Martin

1 0

new Therion 5.5.6
by Therion 13 Jan '21

13 Jan '21

Hi, there is a new release 5.5.6 of Therion. Release notes: v5.5.6 Therion 5.5.6 (2020-12-27): therion: * fixed map statistics bug introduced in 5.5.5 Best regards, Therion team

7 8

Therion 5.5.5 + 5a614ef testing - colour map-fg hierarchy
by Bruce Mutton 26 Dec '20

26 Dec '20

Stacho Most of my datasets checked so far look OK, but there is one that is suspicious, and I am not sure of the proper hierarchy or what it has been in the preceding versions, so it may be OK. What seems to be happening for colour map-fg hierarchy is: 1. ‘lookup’ colours defined in layout override all other map-fg colour specifications 2. ‘Selected’ map colours specified in thconfig override unless there is a matching lookup 3. Explicitly specified map-fg colours are ignored if either of the above are present. I was expecting that number 2 to be top of the list, always, and then the other two dependent on the order called. But it seems never to be the case if there is a lookup, the hierarchy is always as above I think. It might always have been this way, but it seems inconsistent that; a. Selected map colours in thconfig do not always override those defined in layouts (lookups and explicitly specified map-fg), and b. Lookup and explicitly specified map-fg colours do not take their precedence based on order of appearance in layouts. A limited example…. In thconfig: select MegamaniaBeyondWordsPlanMap -color [100 0 0] #ie colour red should override for whole map In layout: colour map-fg map, with a ‘lookup map’ defined Output: Is greyscale as set in a map lookup Change layout to: colour map-fg [97 86 38] # yellow brown Output: Is red as expected, with the select map colour overriding If it has always been this way, then it is not a problem to consider for the Debian release, but maybe later on. Bruce From: Therion <therion-bounces(a)speleo.sk> On Behalf Of Stacho Mudrak Sent: Thursday, 24 December 2020 09:44 To: List for Therion users <therion(a)speleo.sk> Subject: Re: [Therion] Therion 5.5.5 bug - statistics missing from header If you will find some bugs or some suspicious behavior, please let us know. And if someone could test the latest version on some larger datasets, it would be great. We would like to have the most stable version of therion in Debian 11 release and there are still some days left until freeze happens. Thanks, S. On Wed, 23 Dec 2020 at 15:07, Benedikt Hallinger <beni(a)hallinger.org <mailto:beni@hallinger.org> > wrote: Ok wookey, will check that regarding the glx Patch issue then. > Am 23.12.2020 um 14:26 schrieb Wookey <wookey(a)wookware.org <mailto:wookey@wookware.org> >: > > On 2020-12-23 10:42 +0100, Stacho Mudrak wrote: >> I am sorry, one bug fixed, another introduced :/ >> It should be OK in 5a614ef. Windows binaries should be automatically built >> within half an hour. > > And the Debian packages are now built in unstable. They should move into testing in 5 days time. > > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ > _______________________________________________ > Therion mailing list > Therion(a)speleo.sk <mailto:Therion@speleo.sk> > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion(a)speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion

2 1

Therion 5.5.5 bug - statistics missing from header
by Bruce Mutton 26 Dec '20

26 Dec '20

Not sure if this is of my making due to my customisations, or a bug introduced recently. I suspect a bug. Therion 5.5.5 and 5.5.4+4e3623 produce map headers without explorers, surveyors, cartographers or copyrights. Without making any change other than installing 5.5.4+647dcea the explorers, surveyors, cartographers and copyrights are correctly exported. Bruce

6 10

Re: [Therion] Cartesian STD for individual legs
by Marcelo Taylor 23 Dec '20

23 Dec '20

*Hi Marcelo,* Hi Tarquin, thanks for your kind answer. > These surveys only > use tape and clinometer, surveying triangles, starting from two > coordinates known stations. *That's ... both cool and insane at the same time.* I believe that a typical speleological topographer thing: being a little bit ingenious and a lot insane... *Pretty sure a Total Station can cope with this magnetic rock situation.Perhaps someone else on this list can offer advice...* For sure, but total stations are expensive, cumbersome and time consuming. Our idea is to provide a cheap fast way to deal with magnetic anomalous caves.. > Is there a way to specify specific standard deviations for each leg in > Therion? *As far as I know, SD affects all legs specified after it, until another* *sd command changes it. Similar to the "calibrate" command or "units"* *command.* *sd compass 0.3 degrees* *1 2 12.5 315 17* *sd compass 0.5 degrees* *2 3 7.2 220 33* *It is a Survex command (most things inside a Therion centreline block* *are a direct copy of their Survex equivalents, and can be passed through* *to Survex for processing; group/endgroup is an exception, which is* *begin/end in Survex syntax).* *I tested it with a loop where every leg is set to sd 0.1, but one single* *leg set to 200. Therion gave that single leg most of the error.* Thanks for the suggestion, I will try it for sure. Nevertheless I will prefer to use cartesian data and dX, dY and dZ notations. It is because transversal and longitudinal expected errors are very different in trilateration methodology and I have been able to estimate it in cartesian coordinates. I am a little worried if it will also work in "leap-frogging" legs, but I will check it, for sure. *If that doesn't work for you, you can use:* *group* *sd compass 0.3 degrees* *1 2 12.5 315 17* *endgroup* *group* *sd compass 0.5 degrees* *2 3 7.2 220 33* *endgroup* *It's quite verbose, but that is explicitly stated as being possible in* *the Therion book.* I will try this option too. Right now, that calculations have been done in an Excell spreadsheet,it is verbose, for sure. But the idea is to include in our TOPGRU software package (https://see.ufop.br/topgru) in the future. So, after coding, it will only lead to larger lines centerline blocks, that can be copied directly into Therion. TOPGRU right now is only in portuguese and have a more educational characteristics, but one of our 2021 goals is to release an english version and maybe moving it to GNU compliant. *Hope this helps.* It helped a lot, Tarquin. Many thanks. Marcelo Taylor Cel: +55 21 9 9344 5196 marcelo.taylor(a)gmail.com

2 1

Cartesian STD for individual legs
by Marcelo Taylor 22 Dec '20

22 Dec '20

Dear all, I am a brazilian cave topographer and I am developing a methodology of planimetric trilateration for magnetic influenced caves (Brazil has thousands of caves in iron formation rocks). These surveys only use tape and clinometer, surveying triangles, starting from two coordinates known stations. I have been able to calculate coordinates for all the stations and predict specific cartesian standard deviations for each leg, and prepared both normal and cartesian output that can be read by Therion (I suppose that by Survex too, although I am not a Survex user). Is there a way to specify specific standard deviations for each leg in Therion? I understood that the SD command is only for surveys, isn´t it? Because of trilateration a complex triangle network is created in this kind of survey and it will be very useful to close them in a least Squares algorithm, such as Therion´s. I am sorry if this is a too basic question, but I got stuck in this. Regards, Marcelo Taylor Cel: +55 21 9 9344 5196 marcelo.taylor(a)gmail.com

2 1

new Therion 5.5.5
by Therion 22 Dec '20

22 Dec '20

Hi, there is a new release 5.5.5 of Therion. Release notes: v5.5.5 Therion 5.5.5 (2020-12-22): therion: * updated Italian translation [#308] * fixed bug with statistic explo/topo/carto/copyright <number> * fixed bugs related to an undefined Area of Use, which should be used in Proj transformations Best regards, Therion team

1 0

RESOLVED: statistics <explo/topo/carto/copyright> number untrapped error
by Bruce Mutton 21 Dec '20

21 Dec '20

Thanks Stacho That solves the problem. Bruce From: Therion <therion-bounces(a)speleo.sk> On Behalf Of Stacho Mudrak Sent: Tuesday, 22 December 2020 05:19 To: List for Therion users <therion(a)speleo.sk> Subject: Re: [Therion] statistics <explo/topo/carto/copyright> number untrapped error Thanks a lot Bruce, looks like a bull's eye. I was able to replicate your error and fix it. Could you pls try again, it should be fixed in <https://github.com/therion/therion/commit/4e3623ea6e7f876a67ef5f116ff0edb4c…> 4e3623e. S. On Mon, 21 Dec 2020 at 10:23, Stacho Mudrak <lists(a)group-s.sk <mailto:lists@group-s.sk> > wrote: Thanks a lot Bruce, untrapped error should never occur. I will try to investigate your findings with greater numbers then surveyors and let you know. S. On Mon, Dec 21, 2020, 08:38 Bruce Mutton <bruce(a)tomo.co.nz <mailto:bruce@tomo.co.nz> > wrote: Stacho Sorry for the delay. Looks like version 5.5.4 and 647dcea both manifest the same problem at my end. It occurs for both plan and extended elevation pdf outputs. For these ‘failures’ I have the number set to 10, and in some cases the number of explorers, surveyors or cartographers is less than 10. Trial and error with some variations suggests that the syntax ‘statistics explo|topo|carto|copyright <number>’ will always fail if <number> is greater than the actual number of any one of those properties. The failure appears to be untrapped and stops processing unceremoniously. I think that if there are only 3 surveyors, but <number> is >= 3, then there should not be any error condition, and the output should be produced listing the 3 properties. So it seems like a bug to me. Bruce From: Therion <therion-bounces(a)speleo.sk <mailto:therion-bounces@speleo.sk> > On Behalf Of Stacho Mudrak Sent: Sunday, 13 December 2020 21:15 To: List for Therion users <therion(a)speleo.sk <mailto:therion@speleo.sk> > Subject: Re: [Therion] statistics <explo/topo/carto/copyright> number untrapped error Thanks Bruce for this feedback. In the latest snapshot, I have tried to fix this error by refactoring the whole problematic code. Could you please try, whether it still fails? S. On Sun, 29 Nov 2020 at 06:14, Bruce Mutton <bruce(a)tomo.co.nz <mailto:bruce@tomo.co.nz> > wrote: Stacho Further to the untrapped error I mentioned last week… Looks like it is counting scraps correctly. The following statements… statistics carto all statistics carto-count hide (or on or off) … work perfectly. One thing that does seem to be a problem however. The syntax… statistics <explo/topo/carto/copyright> number … is giving me problems. They all seem to result in what seems to be an untrapped error, and truncating the therion.log file in random locations. For example this is what I have been trying… statistics topo 10 statistics topo-length hide I checked with the previous recent version, 552f923 and after removing all the carto-count statements, I get the same behaviour, an untrapped error. So I think the carto-count is working perfectly and I have just unearthed a different problem. Having left the problem for a few days (and rebooting a number of times) I thought I’d try my ‘top 10’ statistics layout (as in the attached LayoutStatisticsReporting.thc file). I ran my thconfig a number of times. For a given input, the point at which the log file truncates seems to be consistent. The file log5 is what I get with a successful compile with all of the statistics. The file log1 is what statistics <whatever> 10 gives me. Thinking that the scraps reported near either side of the log file truncation might be associated, I commented them out of the map. The file log04 shows what happens then – the truncation just occurs a few more characters along the file. Bruce _______________________________________________ Therion mailing list Therion(a)speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion(a)speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion

1 0