BTW my 'extra line' problem remains (not suprisingly). I haven't had time to analyse this (due to drawing surveys the old-fashioned way), but I'll get a minimal example to send you soon.

I've received today a file from Martin Sluka, where this extra line problem is also present. I believe, now I can fix it very fast. Regards, S.

+++ Martin Budaj [04-04-19 16:45 +0200]:

...

...

...

Are there any other incompatible syntax changes that should be converted?

...

Only those mentioned in the CHANGES file:

OK, thanx

...

- centreline command: fix doesn't accept covariances specification

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)? It has taken many years to get the loop closure in Survex working right - and whilst it is easier to re-implment in 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?) 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. 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 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. 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/

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.

<does own loop closure>

Just to check - does this remove the need for Survex entirely now, or is it still used for something? (I need to change dependencies in Debian)

Yes. It is not needed now for data processing. But we're still using survex .3d viewer. S.