January 2014 - Therion

Re: [Therion] Bug#718294: Background images and insert images not working
by Wookey 21 Jan '14

21 Jan '14

+++ Sergei Golovan [2014-01-21 20:01 +0400]: > Hi! > > On Tue, Jan 21, 2014 at 6:48 PM, Wookey <wookey(a)wookware.org> wrote: > > +++ Wookey [2013-12-27 01:37 +0000]: > >> +++ cawa sorix [2013-12-25 17:25 +0100]: > > > >> Aha - it hapens on jessie and sid, but not wheezy. OK. I can reproduce now. Cheers Cawa. > > There was a similar bugreport for Wavesurfer: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719109 > > Turns out that the change is in Tk and it's deliberate. Try to add > [catch] command to the offending line. At least if a tag doesn't match > any items it doesn't matter whether you do something with it or not. OK. I can confirm that using libtk-img 1.4 and downgrading tk8.5 8.5.14-2 to 8.5.11-2 makes it work as expected. So this indeed almost certainly the same bug. I tried this patch to put in the 'catch', which had already been suggested and tried in: http://mailman.speleo.sk/pipermail/therion/2013-July/004447.html and I already tried it myself to check. It didn't fix the problem, but I think I must have suffered from a) not fixing all 3 instances of this in the code and/or b) running the instaled version of xtherion, not the modified one, and/or c) modifiying the tcl me_imgs.tcl source but not rebuilding the xtherion app. Whatever it was it seemed not to be fixing the problem, and presumably Andrew made a similar mistake in the above mail thread. But in fact I have just made sure I got all of those right and this fix does indeed work. Grrr. Thank you Sergei for getting me back on the right track. Pity the previous mistakes kept me off it, otherwise this would have got fixed a lot sooner. Now I can finally upload a working version, and upstream can take this patch for 5.3.13. BTW can someone explain to me why giving an invalid tag 'command' here and then ignoring the error this generates is the right way to do things? Wouldn't it be better not to give an invalid tag? Index: therion-5.3.12/xtherion/me_imgs.tcl =================================================================== --- therion-5.3.12.orig/xtherion/me_imgs.tcl 2011-06-08 16:06:08.000000000 +0100 +++ therion-5.3.12/xtherion/me_imgs.tcl 2014-01-21 17:21:55.568707794 +0000 @@ -537,7 +537,7 @@ } # and change coordinates - $xth(me,can) lower $xth(me,imgs,$imgx,image) command + catch {$xth(me,can) lower $xth(me,imgs,$imgx,image) command} set iidx [lsearch -exact $xth(me,imgs,xlist) $imgx] if {$iidx > 0} { $xth(me,can) lower $xth(me,imgs,$imgx,image) $xth(me,imgs,[lindex $xth(me,imgs,xlist) [expr $iidx - 1]],image) @@ -805,7 +805,7 @@ set iw [image width $imgid] set ih [image height $imgid] lappend xth(me,imgs,$imgx,subimgs) [list $subimg $subcimg 0 0 $iw $ih] - $xth(me,can) lower $xth(me,imgs,$imgx,image) command + catch {$xth(me,can) lower $xth(me,imgs,$imgx,image) command} if {$iidx > 0} { $xth(me,can) lower $xth(me,imgs,$imgx,image) $xth(me,imgs,[lindex $xth(me,imgs,xlist) [expr $iidx - 1]],image) } @@ -831,7 +831,7 @@ lappend xth(me,imgs,$imgx,subimgs) [list $subimg $subcimg $subx $suby $subxx $subyy] } } - $xth(me,can) lower $xth(me,imgs,$imgx,image) command + catch {$xth(me,can) lower $xth(me,imgs,$imgx,image) command} set iidx [lsearch -exact $xth(me,imgs,xlist) $imgx] if {$iidx > 0} { $xth(me,can) lower $xth(me,imgs,$imgx,image) $xth(me,imgs,[lindex $xth(me,imgs,xlist) [expr $iidx - 1]],image) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

1 0

5.3.12
by Martin Sluka 21 Jan '14

21 Jan '14

Exactly after one year! Martin Sluka

4 9

Importing Compass files
by Graham Mullan 19 Jan '14

19 Jan '14

Jonny Prouty wrote: Hi Graham, You can import a Compass PLT file directly into Therion, but not a DAT as far as I know. Best regards, Jonny Thanks Jonny, I assume that would be by using similar syntax to that used to import Survex.3d files. However, as I would need to firstly write a project level .dat file in order to include the necessary co-ordinate information before generating the plt file, that makes it no simpler than my 'quick and dirty' fix of importing the original .plt file into Survex and then importing the resultant .3d file into Therion. This also has the advantage of consistent syntax in my Therion file making it easier to see errors. Graham

3 3

Re: [Therion] Compatibility with Survex
by Graham Mullan 15 Jan '14

15 Jan '14

Thanks guys. Yes, I am doing as Footleg suspected and importing already generated survex.3d files in this case. That's partially to save time, as I seem to be on a deadline with this, strange feeling for a survey project, and that's the way much of the data is getting to me. I have also been given some data in Compass.dat files & I can import that into Survex to generate a .3d but I've been never been able to get it to import directly into Therion. Does it? I could convert the data to Therion but that's time consuming to get right & as I said, I seem to have a deadline on this. However, thanks to Footleg I now know which version of Survex to use. I'd gone all the way back to 1.1.15 just to make sure it worked! Graham

2 1

What version of wxwidgets does therion windows build use?
by Wookey 09 Jan '14

09 Jan '14

Forwarded from the survex list. See query at bottom. ----- Forwarded message from Olly Betts <olly(a)survex.com> ----- Date: Wed, 8 Jan 2014 06:56:03 +0000 From: Olly Betts <olly(a)survex.com> To: Footleg <drfootleg(a)gmail.com> Cc: survex <survex(a)survex.com> Subject: Re: Survex 1.2.8: Aven can't get out of full screen mode List-Id: List for Survex users and developers <survex.survex.com> X-Spam-Status: No, score=-4.4 required=4.5 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.2 On Tue, Jan 07, 2014 at 01:14:13PM +0000, Footleg wrote: > The only quirky thing I see is that in full screen view the Windows > task bar still appears on top of the window, even though the Aven > window is covering the entire screen (I can see my model though the > semi-transparent taskbar. Who says the glassy UI features of Windows 7 > are not of any use?!). I see this same task bar z-order issue with > 1.2.7 too. Note that the Therion viewer Loch appears on top of the > task bar when I put that into full screen view. That's interesting, as Loch also uses wxWidgets, and the code in aven and loch to toggle full screen mode is essentially the same. The Windows build of Survex 1.2.7 was with wxWidgets 2.8.12 and 1.2.8 was with 2.9.5 (and 1.2.9 uses wxWidgets 3.0.0). Do you know what version of wxWidgets therion is built with? It doesn't seem to say on their website. Cheers, Olly -- Survex http://lists.survex.com/mailman/listinfo/survex ----- End forwarded message ----- Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

2 1

fixed point std error causes extreme survey network distortion
by Bruce 08 Jan '14

08 Jan '14

Below a conversation transcript that I took briefly off forum, but now time to post it I think. You can read from the bottom of the transcript below if you are interested. Briefly in summary, it seems to me that since 5.3.5 or earlier, therion loop closure results in grossly distorted outputs IF there are two or more fixed stations AND (only?) for the stations that have standard errors specified AND there are survey networks connecting those fixed stations. Specifying Survex loop closure bypassed this problem. Since I installed Survex 1.2.8 a few weeks agoi, my machine has been giving; C:\Program Files\Therion\therion.exe: warning -- can't open cavern output when survex loop closure is specified, and I suspect this is causing Therion to revert to therion loop closure and hence the distortion problem has been manifesting again if I specify std errors. You can see samples of my therion.log files in the attached dataset. Xavier is using Survex 1.2.6 and his log files, which do not have this problem, are attached separately. If you are interested you can experiment with the fixed station statements in the INDEX file in the attached dataset to see what effect various adjustments have. You might also have to adjust the loop-closure statement in therion.ini. So two things to fix; Therions loop closures and Survex 1.2.8 integration with Therion. Bruce _____ From: Bruce [mailto:bruce@tomo.co.nz] Sent: Friday, 27 December 2013 8:47 a.m. To: 'Xavier Pennec' Subject: fixed point std error causes extreme survey network distortion As commented below. Bruce _____ From: Xavier Pennec [mailto:Xavier.Pennec@inria.fr] Sent: Friday, 27 December 2013 12:48 a.m. To: Bruce Mutton Subject: Re: fixed point std error causes extreme survey network distortion Hi Bruce, I just compiled as is and did not get any distortion. However, I have survex installed: I vaguely remember having some problems using the therion loop-closure algorithm with some uncertainty on the fixed points a long time ago (actually problems when survex is not installed, which amounts to using the therion loop-closure engine). Way back in time this was the reason I first installed Survex I had similar problem with elevations (this one seems mainly a plan problem however) And then later I had this problem that I posted on the forum http://article.gmane.org/gmane.comp.gis.therion/2378/match=loop+closure Indeed, activating therion loop closure (using "loop-closure therion" in the therion.ini file) distorts the cave . This might be a side effect of the loop-closure problem that you reported in 2010 (link above) and which is still unsolved apparently. Based on past experience this is what I was expecting, but my current therion.ini is default and therion.log reports survex activity, so it seems for me both survex and therion loop closures are now giving me this effect (5.3.11 and 5.3.12 it seems). I have tried editing therion.ini to explicitly force both types of loop closure, and the log file reflects what I specify, but the output is always distorted when there are two or more fixed points and at least one has std errors specified. With therion loop-closure, I get as well with my data some "scraps too large" errors to produce the pdf output. Same (but also for Survex closure for me) Thus, we can conclude to a bug in therion loop-closure. (Historically I agree, but I am perplexed as to why I now get it with Survex loop closure as well. I have searched my machine and cannot find any rogue therion.ini files that might be causing the problem. The log file reports the correct initialization file. Perhaps there is a clue in the log file entry C:\Program Files\Therion\therion.exe: warning -- can't open cavern output Maybe this is causing my machine to revert back to therion loop closure in all cases?) Xavier Le 26/12/2013 02:48, Bruce a écrit : Hi Xavier Ive managed to replicate the problem Ive been having with standard errors on fixed points in this small dataset. It is a cave survey I have been using as a training exercise with prospective Therion users and consequently not finished, and has some strange things in it. Interested to see if you get the same problems I am getting. The dataset as attached manifests the problem. I have noticed that if std errors are specified for a particular fixed station, and if the loop closure required is not almost exactly zero, then that particular fixed point is displaced significantly from what it should be. You can experiment with this at the start of the file INDEXHunters.th If you comment out the second fix statement you can see what the cave should look like. (oriented roughly east-west) If you compile the attached as is and you get an output that looks like this, then you are not experiencing my problem. When I compile the attached, the western entrance is shifted some 300m to the north so that the cave is oriented roughly north south. Not sure, but the problem seems to be related to loop closure in north-south direction but not east-west. I think I may have had a similar effect in the vertical direction years ago, and installing Survex (changing loop closure algorithm) fixed it. Open the Hunters3DModel.3d and turn on fixed points, entrances and surface surveys to get an overview of the structure of the survey. Anyway, what happens for you? Distortion or not? Is there anything different in my dataset arrangement that might be causing this? (ie My map definitions in hunters.th are outside of the survey definition). Thanks for any insights you might have. Bruce

4 4

dip strike symbol
by Dirk Peinelt 05 Jan '14

05 Jan '14

Hi, have anyone developed a dynamic "dip strike symbol" for stratification at this time? d

2 1

Drawing stairs / steps
by Roger Schuster 05 Jan '14

05 Jan '14

Hi all, in Therion is line type "steps" available. I draw one line for each step of the stair in plan view. The compiler gives me the message "Warning: Invalid stairs definition in scrap". Can somebody please explain how the line type "steps" is to be used? The TH book explains point type "steps" only. Regards Roger

2 2

symbol-colour point station-name affects some wall altitudes
by Bruce 02 Jan '14

02 Jan '14

While I am on the topic of minor bugs, I think there might be something 'loose' wrt the coding of the colour for wall point altitudes and 'point station-names'. In the examples below I have a more or less black and white layout, but I have made the survey stations stand out as follows; symbol-colour point station [54 7 60] # affects +s, flag symbols and station text symbol-colour point station-name [54 7 60] # affects station-names (and sometimes wall altitude . 's) The image above is as it should be, station symbols and names are coloured and the wall altitude is black. However in the same output, there are usually a few wall altitudes that take on the station colour as above. It only happens when the 'symbol-colour point station-name' is defined, so I guess that is a clue. It usually happens when the altitude is near a station-name, but not always, as you can see in the example above. The effect can be made to go away sometimes by moving either the station-name or the altitude, so it is perhaps related to the proximity, or drawing order, although in the example above moving the "3.11" down near the word "log" does not change the effect on the "185" altitude. Anyone else notice effects like this, or have suggestions as to why it might be happening. Thanks Bruce

1 0

cross section minor bugs (station symbol and statistics reporting)
by Bruce 02 Jan '14

02 Jan '14

Having unearthed the sample dataset I posted last week, I though I would progress the drawing a little more. I have noticed some minor bugs (I think) when drawing cross sections. 1. In cross sections, point station symbols do not render with the correct symbol when they have 'mark fixed' set, as in the plan and section below. The point station in the section seems to plot with the temporary survey station symbol regardless. 2. The map header 'drawn statistics' do not recognise the scrap author (person and date) and do not recognise the copyright date for scraps that are cross sections (projection none). I noticed this because all the plan scraps were drawn in 2012 by someone else, and I have just added some 2014 cross sections with myself as author. However, although the cross sections are included in the pdf output, only the drawn and copyright statistics from the original plan scraps are reported.

1 0