>> 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) - 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...) >> 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. That sounds sensible. I only wonder if some GPS device provides info about covariances. >> 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. >> 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. Only one note: even if the algorithm used now is not working perfectly, it doesn't damage your data. If it will be improved or replaced, simply recompile your data and get perfect maps :) With regards, Martin
