equate to non-existant station does not raise error
This may have been raised before. If a typing error is made in a station equate statement, no error is raised. For example in the following station kb51.29@kb does not exist, therefore the loop is not closed as the user intended. equate kb51.29@kb kb51.29@57 Can an error be raised in this circumstance please. Regards Bruce Mutton
Does the log file contain a warning? I thought that it was using Survex under the hood, and that warns of stations referred to but not used in and fix or leg. On 29 Nov 2013 20:07, "Bruce" <bruce@tomo.co.nz> wrote:
This may have been raised before.
If a typing error is made in a station equate statement, no error is raised.
For example in the following station kb51.29@kb does not exist, therefore the loop is not closed as the user intended.
equate kb51.29@kb kb51.29@57
Can an error be raised in this circumstance please.
Regards
Bruce Mutton
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
That should have said 'not used in any fix or leg' On 30 Nov 2013 09:53, "Footleg" <drfootleg@gmail.com> wrote:
Does the log file contain a warning? I thought that it was using Survex under the hood, and that warns of stations referred to but not used in and fix or leg. On 29 Nov 2013 20:07, "Bruce" <bruce@tomo.co.nz> wrote:
This may have been raised before.
If a typing error is made in a station equate statement, no error is raised.
For example in the following station kb51.29@kb does not exist, therefore the loop is not closed as the user intended.
equate kb51.29@kb kb51.29@57
Can an error be raised in this circumstance please.
Regards
Bruce Mutton
_______________________________________________ Therion mailing list Therion@speleo.sk http://mailman.speleo.sk/mailman/listinfo/therion
We can control whether Therion or Survex loop closures are used, and the default is Survex, if it is installed on the same machine as far as I recall. Mine is using Survex loop closures and I am getting log reporting from Survex 1.2.6 My inference from warnings I get on other occasions is that Survex reports fixed stations that are not connected to any survey leg. I have many of these in other files - gps locations of surface features for example. I imagine the 'equate' part of the processing is different, and in any case neither Survex nor Therion are reporting the anomaly when Therion is run. This is different, and I believe it should be reported by Therion as either a warning or perhaps preferably should stop execution. When equates are defined, I would have expected that it would be required that all equated stations have been defined elsewhere, and if they are not, it should be an exception that should raise and exception or at least a warning. Bruce _____ From: therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Footleg Sent: Saturday, 30 November 2013 10:55 p.m. To: List for Therion users Subject: Re: [Therion] equate to non-existant station does not raise error Does the log file contain a warning? I thought that it was using Survex under the hood, and that warns of stations referred to but not used in any fix or leg. On 29 Nov 2013 20:07, "Bruce" <bruce@tomo.co.nz> wrote: This may have been raised before. If a typing error is made in a station equate statement, no error is raised. For example in the following station kb51.29@kb does not exist, therefore the loop is not closed as the user intended. equate kb51.29@kb kb51.29@57 Can an error be raised in this circumstance please. Regards Bruce Mutton
On Sun, Dec 01, 2013 at 07:52:32AM +1300, Bruce wrote:
My inference from warnings I get on other occasions is that Survex reports fixed stations that are not connected to any survey leg. I have many of these in other files - gps locations of surface features for example.
Yes, Survex will warn about a fixed point which isn't connected to anything, unless you specify the fix to be a 'reference', e.g.: *fix big_doline reference 10485 83132 1600
I imagine the 'equate' part of the processing is different, and in any case neither Survex nor Therion are reporting the anomaly when Therion is run.
Survex treats an equate much like any other survey leg for these purposes, so if you try to equate two points which aren't otherwise referred to, you'll get an error, e.g.: The following survey stations are not attached to a fixed point: a.4
This is different, and I believe it should be reported by Therion as either a warning or perhaps preferably should stop execution. When equates are defined, I would have expected that it would be required that all equated stations have been defined elsewhere, and if they are not, it should be an exception that should raise and exception or at least a warning.
If at least one of the stations in a *equate command is used elsewhere, it's OK to "create" stations with a *equate. This provides a way to create a nice alias for a station, e.g.: *equate 4 tip_of_cairn_at_junction Making this an error would break existing datasets, and adding a warning would be unhelpful, unless we also provided a good way to suppress it. But in your original example, you're linking to a non-existent station in a different survey (if I follow the therion syntax correctly), and the equivalent situation gets a warning from Survex: badequate.svx:1: warning: Station "kb.kb51_29" referred to just once, with an explicit prefix - typo? I think we made this a warning rather than an error because it makes processing subsections of a large survey (e.g. a single cave) easier. Cheers, Olly
+++ Olly Betts [2013-12-01 23:02 +0000]:
But in your original example, you're linking to a non-existent station in a different survey (if I follow the therion syntax correctly), and the equivalent situation gets a warning from Survex:
badequate.svx:1: warning: Station "kb.kb51_29" referred to just once, with an explicit prefix - typo?
I think we made this a warning rather than an error because it makes processing subsections of a large survey (e.g. a single cave) easier.
Yes, we did. And that's still useful functionality, although the need for processing small sections is much reduced these days. Consideration could be given to whether it would now be appropriate to declare that the smallest section of processing is now 'a system', and provide better visibility controls for viewing subsections. (and if you want to process smaller sections in isolation you'll have to make efforts to include 'stub' or reference connection points to avoid errors). There are both pros and cons to this and some thought would be needed on where the balance lies. Does therion process subsections using survex, or collect it all up into a complete dataset and proces that? Presumably bruce's problem is solved simply by better visibility of the existing warning, which shouldn't be hard? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
I had the same problem as Bruce several times: an error in the name of an equate was unnoticed and it took me a long time before I noticed it. In parallel, I used a lot the the "equate to undefined" feature to compile small subsections of a large survey and I find it very useful. However, for the same survey subsections, the nightmare is to verify that all equates are correctly taken into account when considered in the large survey, since the warning are hidden in the (potentially very long) list of unused fixed points. Keeping the meaning of equate as it is right now (i.e. create a synonym if one of the stations is not defined) is of course necessary for compatibility with previous surveys. However, one could imagine to create a more constrained command (e.g. equate* like in latex?) whose meaning would be a zero length shot between two existing stations and a error if one of them is undefined. It could also make sense to have an option in therion to force the interpretation of equate as equate* for debugging. Xavier Le 02/12/2013 10:58, Wookey a écrit :
+++ Olly Betts [2013-12-01 23:02 +0000]:
But in your original example, you're linking to a non-existent station in a different survey (if I follow the therion syntax correctly), and the equivalent situation gets a warning from Survex:
badequate.svx:1: warning: Station "kb.kb51_29" referred to just once, with an explicit prefix - typo?
I think we made this a warning rather than an error because it makes processing subsections of a large survey (e.g. a single cave) easier. Yes, we did.
And that's still useful functionality, although the need for processing small sections is much reduced these days. Consideration could be given to whether it would now be appropriate to declare that the smallest section of processing is now 'a system', and provide better visibility controls for viewing subsections. (and if you want to process smaller sections in isolation you'll have to make efforts to include 'stub' or reference connection points to avoid errors). There are both pros and cons to this and some thought would be needed on where the balance lies.
Does therion process subsections using survex, or collect it all up into a complete dataset and proces that?
Presumably bruce's problem is solved simply by better visibility of the existing warning, which shouldn't be hard?
Wookey
--
------------------------- Xavier Pennec Senior Research Scientist / Directeur de recherche Asclepios project-team, INRIA Sophia-Antipolis 2004 Route des Lucioles, BP93 F-06902 Sophia-Antipolis Cedex, France +33 4 92 38 76 64 +33 6 78 35 16 90 http://www-sop.inria.fr/asclepios/ -------------------------------
participants (5)
-
Bruce -
Footleg -
Olly Betts -
Wookey -
Xavier Pennec