Re: [Therion] A puzzle in Loch
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 ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] A puzzle in Loch
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
Re: [Therion] A puzzle in Loch
> 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
Re: [Therion] A puzzle in Loch
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 ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] A puzzle in Loch
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.55.3180.5 -6.3 - - - - 3 BU1 4.0 315.55.3135.5-6.3 - - - - BU1BU211.6 53.1 84.4228.4 -84.9 16.8 2.2 1.1 11.6 flags not splay BU2BU318.6 152.80.5332.1 -0.7 4.6 0 0.5 5.1 BU3BU420.5 137.1 -1.1318.11.4 10.7 6.8 1.0 2.2 BU4BU518.5 68.62.5248.7 -2.3 4.9 1.9 1.0 0.8 BU5BU611.3 141.7 10.0323.1 -11.1 0.5 10.6 7.2 2.3 BU6BU7 7.8 207.0 18.6 27.9 -19.6 12.9 4.4 18.2 2.8 BU7BU8 6.9 130.3 -48.0312.4 47.8 3.8 3.7 5.9 0.5 BU8BU9 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 https://campercaver.net/MiscFiles/StarkCaverns.lox 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 ___ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Re: [Therion] A puzzle in Loch
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 > > https://campercaver.net/MiscFiles/StarkCaverns.lox 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
