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