Looking at the .lox file for Stark Caverns, I see a spike that does not make any sense. I suspect it might be a blunder in the LRUD data, perhaps a misplaced decimal point - but I have searched all over the data and cannot find anything that looks out of line. Besides, the spike is not horizontal, which you would expect from an LRUD blunder. It goes up at about a 20 degree angle. Take a look at the file at https://campercaver.net/MiscFiles/StarkCaverns.lox Turn on display of walls, survey stations and station labels. The spike is fairly obvious. It starts at around station BU1, station 3, or station E1. Does anyone have any ideas about why this shows up? Is there a way to find the survey stations that it connects to? For what it is worth, it does not appear in Aven using a .3d file. It also does not appear on the PDF plan map. It appears to do no harm ... but it is really bugging me! Thanks! -- =============== Bill Gee
On 15/08/2023 22:52, Bill Gee wrote:
Looking at the .lox file for Stark Caverns, I see a spike that does not make any sense. I suspect it might be a blunder in the LRUD data, perhaps a misplaced decimal point - but I have searched all over the data and cannot find anything that looks out of line. Besides, the spike is not horizontal, which you would expect from an LRUD blunder. It goes up at about a 20 degree angle.
Take a look at the file at
Possibly unrelated to the problem, but ... Several legs are created with a splay, when it looks like they should have been a leg or a duplicate. BU1 to BU2 (where the problem is) G13 to Z1 B1 to B1a AB1 and AB2 A5 to R1 12 and 14 These can cause issues, because splays are legs are different things, and you could confuse Therion when it tries to generate walls. It is supposed to use actual splays for that, but not duplicates. Because you are calling them splays, Therion tries to use them to work out where the walls are, and generates a wall where the LRUD data conflicts with what you have called a splay. So it tries to join the wall it drew at a station, with the wall you told it is somewhere else in the LRUD data. I can understand if it does so with a crazy spike, though it is usually better at handling inconsistent data. I would need to see the source data to debug further, since I cannot see what any of the LRUD data looks like. Cheers Tarquin
Hmmm..... Maybe I am not using the splay flag correctly? Is there another flag that might be more appropriate? The reason those stations are flagged as splay is because they do not contribute to the length of the cave. They are just connecting a side passage into the rest of the survey. Marking the shots as splay means they get left out of the total length calculation. That part of the cave is a big challenge to survey. The main feature there is a stairwell with steel hand rails on either side. The rails really mess with the compass measurements. We tried every which way but could not get a good match between forward and backward compass. I just have to trust that averaging the shots will get somewhere reasonably close to correct. It also is a place where a lower level stream passage (the E series), a mid-level side passage (the BU series) and the main passage (plain numbers going up the stairs) all come together. The survey trips in this part of the cave happened over three years. We did not know the BU passage existed until someone was just fooling around climbing over a rail and along a rock shelf full of electric lights. From the stairs it looks like a shallow alcove. Even the tour guides who go past there multiple times every day had no idea. Had we known, we would have left a good tie-in station. As it is - we had to make due. An extract from the centerline data file looks like this: ========================== data normal from to tape compass clino backcompass backclino left right up down # Side passage behind the overlook flags splay # The next line is the data we actually shot. Getting it to fit right on the map # required juggling the numbers a bit, and that is the second line. # 3 BU1 4.8 345.5 5.3 180.5 -6.3 - - - - 3 BU1 4.0 315.5 5.3 135.5 -6.3 - - - - BU1 BU2 11.6 53.1 84.4 228.4 -84.9 16.8 2.2 1.1 11.6 flags not splay BU2 BU3 18.6 152.8 0.5 332.1 -0.7 4.6 0 0.5 5.1 BU3 BU4 20.5 137.1 -1.1 318.1 1.4 10.7 6.8 1.0 2.2 BU4 BU5 18.5 68.6 2.5 248.7 -2.3 4.9 1.9 1.0 0.8 BU5 BU6 11.3 141.7 10.0 323.1 -11.1 0.5 10.6 7.2 2.3 BU6 BU7 7.8 207.0 18.6 27.9 -19.6 12.9 4.4 18.2 2.8 BU7 BU8 6.9 130.3 -48.0 312.4 47.8 3.8 3.7 5.9 0.5 BU8 BU9 8.6 184.0 10.4 3.2 -9.8 6.4 2.6 3.4 3.0 =============== Bill Gee On 8/15/23 17:10, Tarquin Wilton-Jones via Therion wrote:
On 15/08/2023 22:52, Bill Gee wrote:
Looking at the .lox file for Stark Caverns, I see a spike that does not make any sense. I suspect it might be a blunder in the LRUD data, perhaps a misplaced decimal point - but I have searched all over the data and cannot find anything that looks out of line. Besides, the spike is not horizontal, which you would expect from an LRUD blunder. It goes up at about a 20 degree angle.
Take a look at the file at
Possibly unrelated to the problem, but ... Several legs are created with a splay, when it looks like they should have been a leg or a duplicate. BU1 to BU2 (where the problem is) G13 to Z1 B1 to B1a AB1 and AB2 A5 to R1 12 and 14 These can cause issues, because splays are legs are different things, and you could confuse Therion when it tries to generate walls. It is supposed to use actual splays for that, but not duplicates. Because you are calling them splays, Therion tries to use them to work out where the walls are, and generates a wall where the LRUD data conflicts with what you have called a splay. So it tries to join the wall it drew at a station, with the wall you told it is somewhere else in the LRUD data. I can understand if it does so with a crazy spike, though it is usually better at handling inconsistent data.
I would need to see the source data to debug further, since I cannot see what any of the LRUD data looks like.
Cheers
Tarquin _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
On Tue, Aug 15, 2023 at 07:41:51PM -0500, Bill Gee wrote:
Hmmm..... Maybe I am not using the splay flag correctly? Is there another flag that might be more appropriate?
The reason those stations are flagged as splay is because they do not contribute to the length of the cave. They are just connecting a side passage into the rest of the survey. Marking the shots as splay means they get left out of the total length calculation.
The "duplicate" flag seems to be what you're wanting here. Cheers, Olly
Hmmm..... Maybe I am not using the splay flag correctly? Is there another flag that might be more appropriate?
flags duplicate = a leg that must not count towards the length. It can count towards the vertical range, if it is the highest or lowest point in the cave. Use this when you have had to survey twice (or more) down the same passage. Also use it if you are going from a station in a passage whose length was already included with the legs going down the passage itself, and the new legs are used to reach the start of a side passage, where the main passage is really wide (such as a station on the left wall of a 50m wide passage, and you need to get to a side passage on the right wall). This is particularly useful when you have a side passage you did not have a useful fixed station for, and the nearest fixed station is a long way down the passage, so you will need to resurvey from that fixed station, back down the passage you already surveyed, to reach the side passage. As Olly said, this is the one you want. #survey from fixed station to AB side passage flags duplicate megacairn AB1 12.34 27.5 1.5 AB1 AB2 8.97 42.93 -21.5 #AB2 is start of side passage flags not duplicate flags splay = a shot from a station towards a wall, ceiling, floor or other solid object, such as a stalagmite. Therion uses these to build the walls in the .lox file. Normally, you use anonymous splays like this ("-" instead of a station name): AB1 - 1.234 12.5 -17.5 However, sometimes *rarely* you might want to name a splay, such as a splay that hits something important like a named formation. Imagine you have a stalagmite called "Medusa", you might do this to tell Therion "I know this looks like a station, but it's a named splay": flags splay AB1 medusa 1.234 12.5 -17.5 flags not splay flags surface = a leg or splay that is on the surface, not in the cave. This will not be used for length, depth, or wall generation. It basically tells Therion to ignore it for cave statistics, and for wall generation. This might be used for the legs that go from the cave entrance to your fixed location on the surface, or for splays that go from a surface station to a surface feature, such as a cliff face outside the cave. station 2 "Alpha Cave" entrance flags surface fixedpoint 1 12.345 27.5 1.5 #splays around the outside of the entrance 1 - 0.555 237.50 -37.67 1 - 0.882 258.89 -16.29 1 - 0.895 296.19 -14.58 1 - 1.198 320.46 -3.11 1 2 1.266 62.55 -31.87 flags not surface
BU1 BU2 11.6 53.1 84.4 228.4 -84.9 16.8 2.2 1.1 11.6
Oh, this is interesting. I was wondering if you had used "UP" to get from BU1 to BU2. In such a case, LRUDs are quite useless, as a leg has no direction, so Therion has no information about which direction is "left" or "right", so it might have had to make things up and got it wrong. (Splays are vastly superior to LRUDs, because each one has an explicit direction, so you can point to all walls of a pitch, not just 2 of them.) I had expected maybe it was generating walls without any idea where to point them, but that seems not to be the case, since you have an actual direction for that leg. So it seems the most likely cause for your problem is indeed the "flags splay" where you meant "flags duplicate". However, I would need more of the data forming that part of the cave to be sure, since when I tried to compile your snippet, it did not show the problem. Maybe it only shows up when you have both the old and new data. I also have never seen data in this format, and am curious as to what your "data" command looks like. It looks like it should be this: data normal from to tape compass clino backcompass backclino left right up down But Therion won't let me use that, because the compass and backcompass are not perfectly opposite. I am wondering if it gets confused when you ask it to use all the data columns (I told it to ignore the backcompass). Equally curious about what your measurement device is, since you are getting only 10 cm accuracy (suggesting a measuring tape) and yet .1 degree precision compass and clino, which seems incredibly precise for manual tools, especially considering the forward and backward devices seem to disagree with each other by as much as 2.1 degrees (compass) and 1.1 degrees (clino). There is a huge 4.7 degree disagreement on the BU1-BU2 leg. (Because the devices are being used nearly vertically, so compass error is increased. Plumbed legs would normally be recommended when using manual devices.) Whenever I have seen high quality data from manual devices, the compass and clino have been given to 0.5 degree precision, because that is the reading limit of the devices.
Wow, thanks Tarquin! And Ollie, too. I tried a few things, but the spike still exists in the .lox file. I changed the connecting shots from 3 to BU1 and BU2 from splay to duplicate. After recompiling, the spike is still there. Next I change the shot from BU1 to BU2 so that it has no LRUD data. Recompile, and the spike is still there. Hmmm.... I think I need to change most of the splay shots to duplicate, but that seems to not be the reason for this anomaly. I double-verified the LRUD data for stations BU3, BU4 and BU5. The passage makes a sharp turn at BU4, and a bad left measurement would go about the same direction as the spike. The LRUD data for those stations is all correct. One thing that strikes me is that the spike is not horizontal. It angles upward by about 20 degrees. If it were the result of bad LRUD interpretation, I would expect it to be horizontal. I included the data line in my extract. It is indeed the same line as you deduced by looking at the data. Therion does produce warnings about "forwards and backwards bearing readings do not match". There are about 20 of these in the therion.log file. I have checked every one against the original notes. It really is off. Most are under ten degrees. The worst is 17 degrees off. Most of this cave was surveyed with DistoX2 devices. The compass and inclination readings go to two decimal places (0.01 degree). I do not believe for a New York minute that the DistoX2 is really that accurate. I suspect it is no better than a Suunto. The readings in the book are rounded to the nearest tenth, and I count on Therion averaging the two shots to get a somewhat better consensus. In this cave, especially around the tour trail, compass readings are difficult because there is so much metal. Hand rails, electric lighting fixtures, rebar in the concrete, support pillars and framing for the overlook platform ... It is a magnetic mess! We did the best we could, but there is just a lot of noise in the data. Some time ago I asked about reverse tape readings. That is a fairly new feature in Therion. For this cave we did not record any reverse distance data. The distances are in Imperial measurements to the nearest 0.1 foot. The DistoX2 displays to the nearest 0.01 foot and we round that to 0.1 before writing it down. I found a photo of the area we are looking at. https://campercaver.net/MiscFiles/P1100940-Small.jpg This shows the stairs leading up to the overlook. Station 3 is just out of sight on the left of the photo. BU1 and BU2 are out of the photo at upper right. The BU side passage is reached by getting onto the rock ledge on the right, then coming toward the camera. The passage goes off to the right of this photo. There is an electric light fixture just about dead center in the photo. If you levitate about 8 feet up from that fixture and look right, that is the passage entrance. =============== Bill Gee On 8/16/23 02:18, Tarquin Wilton-Jones via Therion wrote:
Hmmm..... Maybe I am not using the splay flag correctly? Is there another flag that might be more appropriate?
flags duplicate = a leg that must not count towards the length. It can count towards the vertical range, if it is the highest or lowest point in the cave. Use this when you have had to survey twice (or more) down the same passage. Also use it if you are going from a station in a passage whose length was already included with the legs going down the passage itself, and the new legs are used to reach the start of a side passage, where the main passage is really wide (such as a station on the left wall of a 50m wide passage, and you need to get to a side passage on the right wall). This is particularly useful when you have a side passage you did not have a useful fixed station for, and the nearest fixed station is a long way down the passage, so you will need to resurvey from that fixed station, back down the passage you already surveyed, to reach the side passage. As Olly said, this is the one you want.
#survey from fixed station to AB side passage flags duplicate megacairn AB1 12.34 27.5 1.5 AB1 AB2 8.97 42.93 -21.5 #AB2 is start of side passage flags not duplicate
flags splay = a shot from a station towards a wall, ceiling, floor or other solid object, such as a stalagmite. Therion uses these to build the walls in the .lox file. Normally, you use anonymous splays like this ("-" instead of a station name): AB1 - 1.234 12.5 -17.5 However, sometimes *rarely* you might want to name a splay, such as a splay that hits something important like a named formation. Imagine you have a stalagmite called "Medusa", you might do this to tell Therion "I know this looks like a station, but it's a named splay":
flags splay AB1 medusa 1.234 12.5 -17.5 flags not splay
flags surface = a leg or splay that is on the surface, not in the cave. This will not be used for length, depth, or wall generation. It basically tells Therion to ignore it for cave statistics, and for wall generation. This might be used for the legs that go from the cave entrance to your fixed location on the surface, or for splays that go from a surface station to a surface feature, such as a cliff face outside the cave.
station 2 "Alpha Cave" entrance flags surface fixedpoint 1 12.345 27.5 1.5 #splays around the outside of the entrance 1 - 0.555 237.50 -37.67 1 - 0.882 258.89 -16.29 1 - 0.895 296.19 -14.58 1 - 1.198 320.46 -3.11 1 2 1.266 62.55 -31.87 flags not surface
BU1 BU2 11.6 53.1 84.4 228.4 -84.9 16.8 2.2 1.1 11.6
Oh, this is interesting. I was wondering if you had used "UP" to get from BU1 to BU2. In such a case, LRUDs are quite useless, as a leg has no direction, so Therion has no information about which direction is "left" or "right", so it might have had to make things up and got it wrong. (Splays are vastly superior to LRUDs, because each one has an explicit direction, so you can point to all walls of a pitch, not just 2 of them.)
I had expected maybe it was generating walls without any idea where to point them, but that seems not to be the case, since you have an actual direction for that leg.
So it seems the most likely cause for your problem is indeed the "flags splay" where you meant "flags duplicate".
However, I would need more of the data forming that part of the cave to be sure, since when I tried to compile your snippet, it did not show the problem. Maybe it only shows up when you have both the old and new data.
I also have never seen data in this format, and am curious as to what your "data" command looks like. It looks like it should be this:
data normal from to tape compass clino backcompass backclino left right up down But Therion won't let me use that, because the compass and backcompass are not perfectly opposite. I am wondering if it gets confused when you ask it to use all the data columns (I told it to ignore the backcompass).
Equally curious about what your measurement device is, since you are getting only 10 cm accuracy (suggesting a measuring tape) and yet .1 degree precision compass and clino, which seems incredibly precise for manual tools, especially considering the forward and backward devices seem to disagree with each other by as much as 2.1 degrees (compass) and 1.1 degrees (clino). There is a huge 4.7 degree disagreement on the BU1-BU2 leg. (Because the devices are being used nearly vertically, so compass error is increased. Plumbed legs would normally be recommended when using manual devices.) Whenever I have seen high quality data from manual devices, the compass and clino have been given to 0.5 degree precision, because that is the reading limit of the devices. _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
One thing that strikes me is that the spike is not horizontal. It angles upward by about 20 degrees. Hi Bill If it helps (unlikely), I have had a project where the Loch model has (had) just such a spike, one hundred or so metres long, angling about 20 deg upwards. For more than 10 years the model had this spike, and from time to time I tried to troubleshoot it without luck. I have had other similar cases as well. I looked up some outputs compiled January this year - it seems this spike is no longer present. So there must have been a change in the algorithm in recent years to resolve this. There has been no survey or drawing activity in that part of the cave or model since about 2008-2010, but I concede that edits more than 100 m away (from the spike) in the model could possibly have had some effect. I notice that other Loch rendering artifacts seem to have been resolved also.
Are you using a recent version of Therion? I'm using 6.1.8, but unsure what it would have been in January. Bruce
Hi Bruce - I am glad to hear someone else has seen this kind of problem. It is really not much more than annoying since no one but me sees the .lox files. I have CaveView on a web server, so I suppose that might count as publishing the file. I am using Therion 6.1.8 and Survex 1.4.5 running on Fedora 38. I compiled Therion from source. Survex is the package the Jim Begley puts in his COPR repository. The Stark Caverns survey project has been going since December 2018. It has been run through quite a few versions of both applications. Every compile job builds the .lox file from scratch, so there should not be any cruft from old versions. And now I find something REALLY interesting! Mentioning CaveView in the first paragraph reminded me that it is a full LOX viewer with no dependency on Loch. Just for grins - I copied the latest Stark Caverns LOX file over to that server and opened it up. No spike! The anomaly is not there in CaveView. Take a look ... https://campercaver.net/CaveView/my-index.html and use the gear icon to choose the Stark Caverns file. I think something odd is going on in Loch. What other applications can open a .lox file? I gave it a quick try in MeshLab, but it does not recognize .lox as a valid file type. =============== Bill Gee On 8/16/23 15:04, Bruce Mutton wrote:
One thing that strikes me is that the spike is not horizontal. It angles upward by about 20 degrees. Hi Bill If it helps (unlikely), I have had a project where the Loch model has (had) just such a spike, one hundred or so metres long, angling about 20 deg upwards. For more than 10 years the model had this spike, and from time to time I tried to troubleshoot it without luck. I have had other similar cases as well. I looked up some outputs compiled January this year - it seems this spike is no longer present. So there must have been a change in the algorithm in recent years to resolve this. There has been no survey or drawing activity in that part of the cave or model since about 2008-2010, but I concede that edits more than 100 m away (from the spike) in the model could possibly have had some effect. I notice that other Loch rendering artifacts seem to have been resolved also.
Are you using a recent version of Therion? I'm using 6.1.8, but unsure what it would have been in January.
Bruce
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
participants (4)
-
Bill Gee -
Bruce Mutton -
Olly Betts -
Tarquin Wilton-Jones