> 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). > Also the co-variances are important for fixed points (especially GPS fixed > points which often aren't very 'fixed' at all). At the very least the > information should be retained in the files even if it is not currently used. 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. > C++ than it was to do in C originally I wonder why bother - it is very > likely to have bugs in, and it seems to me that using the external program > made a lot of sense here. (or have you used the actual code rather than > re-implemented?) I've tried to use actual code - but it was not possible to integrate it into therion. So I've implemented my own very simple loop closure algorithm. > 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. I agree - survex has a very sophisticated loop closure, and from this point of view - replacing it was a retrograde step, but: 1. our ultimate priority was to have windows standalone installation (a lot of people asked for it) - and it was not possible to integrate survex in it 2. the quality of loop closure is very relative - if you have blunders in it, no loop closure is good. If not - every loop closure produces results, that looks OK :) 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. > I don't mean to sound too critical, but this seems an odd an retrograde step > to me. Survex/Therion incompatibilites are already a problem, and this seems > like adding a new one, for no obvious gain. Please, be very critical! If you would not be - I would never do a fast zooming in xtherion. Now (thanks only to you, everybody else was not enought critical) it works and even on my "fast" computer with a "lots" of RAM it saves me a huge amount of time. In fact, survex loop closure was not removed from source code. Using a simple switch (at the begining of thdb1d.cxx file), you can turn it back for you (if therion loop closure is not good enought). In the future, this can be also option in the initialization file - which loop closure should be used. But until it will not be possible to link survex as independent library, we will use this alternative... S.
