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
[Therion] A puzzle in Loch
> 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
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] Invalid length reading error reported due to (valid) scrap definition
On 2023-08-07 08:38 +0200, Benedikt Hallinger wrote: > Hm, I'm not sure this will trigger a lot of false positives in some of my > projects, where structure is heavily divided into smaller files which are > inputted to form a whole complete. Right. centreline doesn't have to be balanced on a per-file basis. Survey structure and file structure are independent in Therion same as they are in survex. > When an encenterline is missing somewhere, this is some sort of unbalanced > braces problem like in a C compiler; so mabye therion should output at the > end that there is unbalanced centerline/endcenterline numbers (or all other > such structures, in this regard) in the input data. Right if it errored on unbalanced start/end primitives and said which files were unbalanced that should narrow it down enough to find the mistake (because on most projects most files will be balanced?). I'm not sure if there is a better interface/algorithm? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature ___ 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?
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
