April 2004 - Therion

Survex vs Therion
by Olly Betts 28 Apr '04

28 Apr '04

On Thu, Apr 22, 2004 at 11:31:49AM +0100, Wookey wrote: >> It would probably help things like this a lot if you were able to monitor >> the Therion list Wookey forwarded me some recent messages. I'm now subscribed (well, it says I am - nothing has arrived yet). >> This seems like a retrograde step. If survex is not doing quite what you >> want then fixing survex ought to be a better plan. We need better >> Therion/survex cooperation. I must get Olly to start reading this list. It would be better to try to coordinate what we're up to to prevent duplicating work, or worse working against each other. I did actually try to start to encourage a bit of cooperation a while ago - in particular regarding the details of therion's "charset" command which Survex could usefully implement. But I didn't get a useful response... >>> > Oh yes, I meant to ask about that - why have you moved the loop closure >>> > inside Therion (out of survex) > >> >> Well, there were some good reasons to do it: >> >> - installation is simpler now >> - there were some problems with survex' msg files -- if msg >> file was missing, cavern didn't start at all; >> if cavern used the file, we had problems with parsing >> the translated log file for information about centreline >> (e.g. E-W range) Survex programs don't have any version of the messages compiled in, save for a handful of messages needed to report errors in loading the messages (unlike programs using GNU gettext which always compiles in all the English messages). The survex message code actually predates GNU gettext. It's much more frugal on memory, so I'm reluctant to chuck it away - on PDAs this still genuinely matters. Anyway, the upshot is that cavern simply *can't* run without the message files - it couldn't output anything! But if you just want to hide cavern inside therion, it wouldn't be hard to compile in messages. You could even have your own set of "translations" providing easy to machine parse output for E-W range, etc. The pieces needed to provide a mechanism to compile in a single translation are already mostly there. >> - we had somehow to parse err file to get information about >> loop errors (this will go to SQL export; bad loops may be >> highlighted in the map...) Again, it would be pretty easy to add code to allow a custom-built cavern to output error statistics in whatever format you desire. >>> > This seems like a retrograde step. If survex is not doing quite what you >>> > want then fixing survex ought to be a better plan. We need better >>> > Therion/survex cooperation. I must get Olly to start reading this list. > >> >> We waited for cavern-library (promised in the SPUD to-do for more than 2 >> years) and would be happy to use it. In Therion everything is prepared to >> link such a library. Nobody's mentioned to me that they're waiting for loop closure to become a library. I've got a list of things to do, and I have to decide on a sensible order. So far, making loop closure a library has been well down the list because there are other items which will do more to improve the user's "survex experience". If the code would be useful, perhaps this should be higher priority... >>> >Oh yes, I meant to ask about that - why have you moved the loop closure >>> >inside Therion (out of survex) and not even accepted the covariance numbers >>> >(even if not processing them)? > >> >> First of all - we have an experience, that allowing users to specify too >> many things (that are not processed) is quite misleading. Therefore we have >> decided to strictly remove all the stuff, that is not used and will not be >> used in the next major version (user can use comments in any case). Changing these fields to comments would require the user to edit the file though. And then remember to change it back. >> Here I have some doubts. Do you know anybody, who has ever inserted these >> covariances in reality ??? As far as I understand the process of GPS - >> these variance/covariances strongly depend on current positions of >> satelites and local landscape. Therefore I do not believe, that you're able >> to read somewhere variances/covariances that make a lot of sense. http://www.hartrao.ac.za/geodesy/gps.html (Search for "covariance"). A consumer grade GPS probably won't report them (some report DOP I think). Survey grade units will though, and since the loop closure algorithm can make use of the information, it's a shame not to be able to specify it when you have it. >> 3. I've been missing one thing in survex - and this is the system of real >> closed loops with minimal number of shots. When we've closed a large loop >> in the cave, I was not able to read from err-files the real error on this >> loop. All I was able to get was survex error correction on some segments of >> it - but this is only a partial and not interpretable number, that depends >> on loop closure algorithm. Sadly the idea of loop closure statistics for "complete loops" seems obvious but isn't really very meaningful. The closure is done on those segments, and to report information for "complete loops", you have to combine those segments in some arbitrary way. And by combining them you lose information - in particular large errors which indicate possible blunders will be less obvious. "Minimal number of shots" seems particularly arbitrary. "Minimum length" seems a bit more justifiable. But either is going to prefer to pick out the survey loop around the walls of the chamber near the entrance rather than your magnificent new closure involving several kms of survey. The most sensible approach is to display the information graphically. Then where the "complete loops" are is no longer an issue. And if you want to know the closure on a particular loop, you can highlight it with the mouse and ask. Cheers, Olly

2 1

therion 0.3.1
by Stacho Mudrak 26 Apr '04

26 Apr '04

Hi, last friday, we've released version 0.3.1, in which some important bugs have been fixed. S.

1 0

'subtype' syntax change proposal
by Martin Budaj 23 Apr '04

23 Apr '04

Topic for discussion: incompatible change of -subtype option for line symbols Working on 2D export and 3D reconstruction we came to incredible obstacles caused by the -subtype syntax: it currently applies to an arbitrary subpath of the line. Proposed new behaviour is to allow only one global -subtype specification for the whole line. Would it cause big troubles to split lines in every point where subtype is changing in your existing data? Martin

4 9

Therion 0.3.0
by m.b＠speleo.sk 23 Apr '04

23 Apr '04

Hi everybody! Therion 0.3.0 is available. Substantial changes: * Therion goes 3D: vrml, 3dmf and native therion formats with passages reconstructed from 2D maps * completely new Win32 installation with TeX and Tcl/Tk included XTherion: * 3D model viewer added * Map editor: only the visible part of background images is zoomed (less memory consumption and speed improvement) * Map editor: support for JPEG and PNG images if tkImg extension is installed M.

4 8

Re: drawing up - seeking advice
by Wookey 01 Apr '04

01 Apr '04

+++ Martin Sluka [04-03-31 10:05 +0200]: >> At 15:50 +0100 30.3.2004, Wookey wrote: >> ******************************************* >> > >>> >A comparison of therion, TunnelX and Carto would be very useful, but I >>> >don't >>> >know of anyone who's tried all three. > >> >> Only a note: Check automatic overlap feature of therion - there is a >> sample on therion page. >> >> http://therion.speleo.sk/img/sample.png neat. Although I strongly contend that lines which go underneath should have a small gap so that they do not touch the wall which they are going under. This makes for much clearer pictures. Althernatively the greying could occur before the wall/clipping zone. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/

3 3