November 2010 - Therion

plan cross-section
by marco corvi 24 Jun '11

24 Jun '11

seems that cross-section scrap must have a projection `none', which means that therion cannot use stations to scale it "properly". i had to draw a vertical cave, a sequence of pits, one on top of the next. instead of drawing a plan, with plenty of maps shifted to the side, i preferred to draw plan cross-sections nearby the shafts as cross-sections (with a section line marking their position on the pit). i would also like to have one north symbol on the map, to mark the orientation of all the plan cross-sections. i did it fiddling with the sources, but a "more stable" solution is appreciated. thanks for the help, marco

4 6

Re: [Therion] distox
by marco corvi 12 Jun '11

12 Jun '11

On Wed, 2010-04-14 at 12:22 +0100, Wookey wrote: > +++ marco corvi [2010-04-14 09:18 +0200]: > > hi wookey, > > Is there any reason you replied off-list? I'm sure this would be > interesting to others. none. i just clicked on the sender name out of abit. > > the work on "my distox programs" is going on. > > you can get the programs and dome docs on the page > > http://marcocorvi.altervista.org/caving/distox/index.htm > > OK. good stuff. I will download, build and test tonight if I can. > > > important catch: > > my programs are meant to work with single survey. > > i rely on therion for the full cave(s) survey. > > also i do not have a portable device to take in the > > cave, so i do not focus much on working on-line, > > but on working off-line. > > OK. I do, so maybe I can help with that. I think it's important to get > something like the pocketopo functionality on non-windows devices. agree. any help is very much appreciated. > > recent changes (besides bug fixes), > > added pockettopo import/export (beat told me the file format > > and we had an email exchange about how to address the > > programs interoperability), > > worked on compass export, and therion export. > > reorganized some of the code. > > not sure these are all online. > > OK. What's the deal with the calibration algorithm? Having that remain > secret is going to be a problem. I thought the device could do its > own calibration, but apparently it needs an external app? Perhaps we > can adapt the SAP calibration code (which is Free) as it must be very > similar. as far as i read, beat algo is better. beat should have a paper published soon in CREG describing the algo. i believe that when it is published i can put my reimplementation in the sources. > What do you have and what have you agreed not to disclose? If > it's just the code then re-implementation via an explanation of the > algorithm should be fine. > > > i was considering dropping the QT3 support and work only > > with QT4 (better classes and easier interfaces). > > OK. I guess that is the way forward now. I guess that could be a > problem for GTK-based devices with limited storage. yes. marco

4 9

5.3.5 packaged for Debian - please test
by Wookey 19 Nov '10

19 Nov '10

I've packaged the current unstable release 5.3.5 for Debian testing (squeeze). Do please try it out and tell me how it works for you - especially if you have an intel graphics card and had problems with Loch crashing in the past. In 5.3.3 textures were disabled in order to have loch run on intel cards, but at least on this machine I have access to, this problem seems to have gone away so I have re-enabled it. Hopefully it was a VT/mesa bug. But I'd like to know how it works for other people. And do of course whinge if you see other issues such as documentation bugs. There does seem to be a problem with Loch and xtherion not appearing on menus, at least with XFCE, which I need to investigate. (desktopand application files are present) The packages are here for the time being: http://wookware.org/software/therion/ Once feedback is satisfactory these will be uploaded to Debian experimental and my Ubuntu PPA. Martin/Stacho - the new v3.0 source format (quilt patches) makes it a lot easier to see what's been changed. Do please peruse the patches as several of them could usefully go upstream. 10changelog.patch 30doc-fixes.patch 35loch-manpage.patch 40samples-fixes.patch 82-nolang-segfault-fix.patch Note that I have nobbled a lot of "warning: deprecated conversion from string constant to ‘char*’" by using -Wno-write-strings but these should probably be fixed properly. There are also a few build warnings remaining: ++ -c -Wall -DTHLINUX -O2 -o thimport.o thimport.cxx thimport.cxx: In member function ‘void thimport::import_file_img()’: thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fz’ may be used uninitialized in this function thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fy’ may be used uninitialized in this function thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fx’ may be used uninitialized in this function ++ -c -Wall -DTHLINUX -O2 -o thepsparse.o thepsparse.cxx thepsparse.cxx: In function ‘void parse_eps(std::string, std::string, double, double, double&, double&, double&, double&, converted_data&, double, double, double)’: thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[5]’ may be used uninitialized in this function thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[4]’ may be used uninitialized in this function thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[3]’ may be used uninitialized in this function thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[2]’ may be used uninitialized in this function thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[1]’ may be used uninitialized in this function thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[0]’ may be used uninitialized in this function ++ -c -Wall -DTHLINUX -O2 -o thattr.o thattr.cxx thattr.cxx: In member function ‘void thattr::export_html(const char*, int)’: thattr.cxx:732: warning: format ‘%u’ expects type ‘unsigned int’, but argument 3 has type ‘size_t’ Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/

3 3

FW: Source and Select
by Bruce 18 Nov '10

18 Nov '10

OK, I tried it. Selected a map containing a few caves, and a single survey, a small part of one of those caves in one of my datasets. The 2d pdf map produced a cave and reported 12km and the lists and 3d model in the same thconfig run reported a single survey of 45m. I see now it has always been this way, but was not what I had assumed for all these years. (One can never read the Therion book too carefully). It also explains the discrepancy in reported cave lengths between 2d pdf maps and the list outputs. If there are no scraps for a short length of survey, then the 2d pdf map does not report that portion of the cave length. This means that, assuming the surveys and maps are decoupled as is one of the supposed advantages of Therion (and I agree it is), it is therefore NOT usually possible to get a comprehensive set of outputs (2d pdfs, 3d models, lists of caves, continuations and surveys) that relate to a particular discrete SUBset of data (It is however possible to get these for the ENTIRE dataset at any level, but if the global effect of loop closures is to be accounted for at a lower level the outputs are unlikely to represent a consistent portion of the cave-unless map objects and surveys join at the same places). I agree Andrew, it would be good to select a map object and have all types of output refer to drawings and centrelines contained in that map object. It is the behaviour I was incorrectly assuming, and the inevitable discrepancies I had been putting down to bugs either in Therion or my haphazard data organisation. The reverse currently happens when a survey is selected I think. Ie all scraps are exported for selected surveys. This does not allow passage previews and offsets though. Martin, Stacho, Should/could Therion produce such synchronised outputs where maps are selected, or should the users have to make the boundaries of their map objects match survey junctions at key locations to enable them to get consistency between map based outputs and survey based outputs? The later, status quo, is workable, but seems to make it difficult for the user and make interpretation of output statistics quite onerous. So if I were to suggest a specific change it would be that when maps are selected, only data relating to survey legs contained within selected maps would be exported. Or am I missing something? Comments? Regards Bruce -----Original Message----- From: therion-bounces(a)speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Andrew Atkinson Sent: Wednesday, 17 November 2010 6:56 a.m. Your suggested solution, is what I do, for 3d, and it works, but I have not used lists yet. However, it would be nice to be able to select a map and only get a centreline with this would be good, but I suspect too much work for it to be worth while. (plus lots of decisions about what exactly would appear in the output Andrew On 16/11/10 09:08, Bruce wrote: > My reading of the Therion Book suggests to me; > > - that 'source' specifies the files that Therion should read and process > before deciding what to export. The source files should contain or > reference surveys and or a surface. > > - that 'select' chooses which survey(s) and or map(s) from the above > files to export. If there is no 'select' statement then 'all' are exported. > > My interpretation #1 is that this should allow all the surveys of a > large (or modest) system of cave passages to be referenced by way of > 'source' so that all the survey loop and scrap join distortions can be > processed BEFORE Therion decides what to export. This is what seems to > occur. So far, so good. > > My interpretation #2 is that when a map or maps for any particular > projection is 'selected' then ONLY the data that relates to those maps > should be exported. This is what seems to happen for Map outputs (pdf > and ?kml) and Atlas outputs. > > I have some difficulty and confusion with outputs that don't have a > projection, such as the lists, 3d outputs and database. What seems to > happen is that regardless of the 'selected' maps, all of the 'sourced' > data is exported to this type of output. > > What I would like is that only the data related to the 'selected' maps > are exported. This way all subset outputs can be consistent (same loop > closure distortions applied), and separately exported. > > In writing this out I suspect I may have realised the answer to my > question (but not yet tested it). Perhaps what I need to do is 'select' > survey(s) that encompass the same part of the cave as the maps? > > Any insights or clarifications gratefully received. > > Bruce

3 6

Source and Select
by Bruce 16 Nov '10

16 Nov '10

My reading of the Therion Book suggests to me; - that 'source' specifies the files that Therion should read and process before deciding what to export. The source files should contain or reference surveys and or a surface. - that 'select' chooses which survey(s) and or map(s) from the above files to export. If there is no 'select' statement then 'all' are exported. My interpretation #1 is that this should allow all the surveys of a large (or modest) system of cave passages to be referenced by way of 'source' so that all the survey loop and scrap join distortions can be processed BEFORE Therion decides what to export. This is what seems to occur. So far, so good. My interpretation #2 is that when a map or maps for any particular projection is 'selected' then ONLY the data that relates to those maps should be exported. This is what seems to happen for Map outputs (pdf and ?kml) and Atlas outputs. I have some difficulty and confusion with outputs that don't have a projection, such as the lists, 3d outputs and database. What seems to happen is that regardless of the 'selected' maps, all of the 'sourced' data is exported to this type of output. What I would like is that only the data related to the 'selected' maps are exported. This way all subset outputs can be consistent (same loop closure distortions applied), and separately exported. In writing this out I suspect I may have realised the answer to my question (but not yet tested it). Perhaps what I need to do is 'select' survey(s) that encompass the same part of the cave as the maps? Any insights or clarifications gratefully received. Bruce

2 1

Re: [Therion] Therion Digest, Vol 59, Issue 17
by Graham Mullan 16 Nov '10

16 Nov '10

Graham -- graham.mullan(a)coly.org.uk 0117 9502556 or 07887 637064 (or 0844 2327803) On 16/11/2010 11:00, therion-request(a)speleo.sk wrote: > Send Therion mailing list submissions to > therion(a)speleo.sk > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.speleo.sk/mailman/listinfo/therion > or, via email, send a message with subject or body 'help' to > therion-request(a)speleo.sk > > You can reach the person managing the list at > therion-owner(a)speleo.sk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Therion digest..." > > > Today's Topics: > > 1. Source and Select (Bruce) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 16 Nov 2010 22:08:50 +1300 > From: "Bruce"<dangle(a)tomo.co.nz> > Subject: [Therion] Source and Select > To: "'List for Therion users'"<therion(a)speleo.sk> > Message-ID:<8D8CD5FCB02E447CADDD297FA721A23D@JUICEBRAIN> > Content-Type: text/plain; charset="us-ascii" > > My reading of the Therion Book suggests to me; > > > > - that 'source' specifies the files that Therion should read and > process before deciding what to export. The source files should contain or > reference surveys and or a surface. > > > > - that 'select' chooses which survey(s) and or map(s) from the > above files to export. If there is no 'select' statement then 'all' are > exported. > > > > My interpretation #1 is that this should allow all the surveys of a large > (or modest) system of cave passages to be referenced by way of 'source' so > that all the survey loop and scrap join distortions can be processed BEFORE > Therion decides what to export. This is what seems to occur. So far, so > good. > > > > My interpretation #2 is that when a map or maps for any particular > projection is 'selected' then ONLY the data that relates to those maps > should be exported. This is what seems to happen for Map outputs (pdf and > ?kml) and Atlas outputs. > > > > I have some difficulty and confusion with outputs that don't have a > projection, such as the lists, 3d outputs and database. What seems to > happen is that regardless of the 'selected' maps, all of the 'sourced' data > is exported to this type of output. > > > > What I would like is that only the data related to the 'selected' maps are > exported. This way all subset outputs can be consistent (same loop closure > distortions applied), and separately exported. > > > > In writing this out I suspect I may have realised the answer to my question > (but not yet tested it). Perhaps what I need to do is 'select' survey(s) > that encompass the same part of the cave as the maps? > > > > Any insights or clarifications gratefully received. > > > > Bruce > > > > > >

1 0

Possible opacity offset bug
by Andrew Atkinson 15 Nov '10

15 Nov '10

Hi The file individually.png, shows a section of passage that when run by itself greys out 2 of the lines either side of the traverse. However, when compiled in the full survey it an offset part of the cave, and the lines are in full black. What looks to be happening: If these lines were not displaced they would be under another passage, and therefore all be the same shade of grey. When they are offset they are all returned to full black? Or am I missing a trick? thanks Andrew

3 4

Therion Survex Loop Closure Anomoly
by Bruce 15 Nov '10

15 Nov '10

I have a mystery, whereby an overland survey between two fixed points gives a correct pdf plan output with; loop-closure survex (I know it is 'correct' because the aerial photograph image matches the features surveyed) but if I specify; loop-closure therion then one of the fixed points is about 150m misplaced in plan and the surveyed features are clearly in the wrong place. In both scenarios therion.log reports identical average loop errors and specific loop error statistics. The error over a 500m loop is about 2.3%, mainly due to a 12m error in elevation (can not trust those gps readings). The plan error if one of the points has its 'fixity' removed is about 4m, and the plots produced are correct regardless of the loop closure method. It is a rather large dataset with many underground loops, and four fixed surface points. Two of which have overland surveys between them. Only one of the overland surveys has this problem. Using Therion 5.3.5. Can replicate this result on three computers. Any theories as to what might be going on and how to locate the issue? Bruce

2 1

label -place bottom
by Andrew Atkinson 11 Nov '10

11 Nov '10

Hello As can be seen from the attached screenshot, the label "box" is clipping the passage wall. To try to overcome this, as space is tight, I have added the option of -place bottom. However, the result is same. Am I doing something wrong, misunderstanding the use or possibly a bug? The thbook says that clip on is not an option for labels (and it complains if you try to add it as you would expect.) Is there another solution? Therion 5.3.3 (the debian build) on Ubuntu Also tested on 5.3.4 on Windows 7 thanks Andrew

3 3

Re: [Therion] Broken link
by dan hedger 08 Nov '10

08 Nov '10

When I use my browser to navigate to the Therion Website: I click on Wiki Other Examples Parameters in layout Source .th file - "demo-cave .th" ( *hyperlink) to Source scans and .th2*. When I click or copy this link it wants to call itself " http://www.therion.speleo.sk/stats/get.php?filename=demo-jaskyna.zip" and my ISP says: Sorry,"www.therion.speleo.sk" does not exist or is not available. I realize that the file is illustrated just below on the page but the link says its a .zip file its located on the page that has Cachtice cave -example of quite complicated map on it. Was wondering where I can download demo-jaskyna.zip?

3 3