Survex vs Therion
olly at survex.com
Wed Apr 28 02:33:35 CEST 2004
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
>>> > 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.
(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
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.
More information about the Therion