Just managed to understand the basics of SvxEdit + Aven and am successfully creating simple demo surveys then viewing and rotating in 3D.

Running in Linux - Ubuntu 10.10

Next step - how do I add "meat" to the skeleton - passage widths and heights - then view in 3D as though passage is a solid structure? Simplest way possible please, if anyone knows.

Thanks 

You need the latest (and still a bit unstable, especially Aven) development version of Survex to do this. The methodology does not appear in the Survex documentation, as yet, but is fairly straightforward. I'm not at my desk ATM so don't have access to the relevant files but when I get back home, I'll post an example of the file layout for you, unless someone else beats me to it at some point today or tomorrow.

Is footleg out there (he da man).

(Not that Graham wont be able to provide ample info  :-[ )

Sam, I am also hoping that footleg will be able to deal with this before I get home so  :tease: to you.

I've been playing with LRUD data in Survex just lately and found it a bit of a pain. I ended up having to cut and paste loads of data, flip Ls and Rs etc. I'd like to see your example data Graham and would welcome any advice too.

Version 1.1.15, which as Graham says is not the current stable version (1.0.39), but a development version supports the LRUD feature.

Download it here:

http://survex.com/software/1.1.15/

The manual is there too, but explanation on using LRUD is a bit sparse.

PASSAGE

        This survey style defines a 3D "tube" modelling a passage in the cave.
        The tube uses the survey stations listed in the order listed. It's
        permitted to use survey stations which aren't directly linked by the
        centre-line survey. This can be useful - sometimes the centreline will
        step sideways or up/down to allow a better sight for the next leg and
        you can ignore the extra station. You can also define tubes along
        unsurveyed passages, akin to "nosurvey" legs in the centreline data.

        This means that you need to split off side passages into seperate
        tubes, and hence separate sections of passage data, starting with a new
        *data command.

        Simple example of how to use this data style (note the use of ignoreall
        to allow a free-form text description to be given):

        *data passage station left right up down ignoreall
        1  0.1 2.3 8.0 1.4  Sticking out point on left wall
        2  0.0 1.9 9.0 0.5  Point on left wall
        3  1.0 0.7 9.0 0.8  Highest point of boulder

Click to expand...

I'll be trying Therion shortly as I have some drawing up to do. Does the Therion viewer handle LRUD data in a more "conventional" fashion?

I've been using LRUD data in Survex and now Therion.

The Aven and Loch viewers display the resulting .3d files differently.  Aven does blocky walls and Loch smooth ones (unless i'm missing a trick).  You can get Therion to

The caves of Fairy Cave Quarry are here http://www.sump4.com/downloads/fairy_cave_quarry.3d - this one is compiled in survex 1.1.15 and the Loch viewer cannot read it.

Here's a smaller file of Wookey Hole - Chamber 9 to 21 http://dl.dropbox.com/u/22755151/wookey.3d (all underwater - passage dimensions acquired by SONAR).  This will work in Loch and Aven.

As you might have been able to tell, I've been away for a week. I see you have already sorted the basic passage dimensions entry in Survex already. As you have observed, Aven creates blocky/square passages. Loch smooths them and looks nicer. The passage walls support in Survex is also present in builds 1.1.12 and onwards. I believe files created using Survex 1.1.14 or earlier will be readable by Loch. Something changed in 1.1.15 which makes the files incompatible with older versions of Aven and the current Loch viewer.

Some tricks to be aware of in entering passage data in Survex files. The passage walls will be created between each pair of stations in the order you enter the lines in the *data passage block. It does not pay any attention to the actual survey centreline. So if you have a junction at station 4 in a passage with stations 1-7 where your side passage starts with a station 8 then you need to put in a new '*data passage ... ' line after the LRUD data for stns 1-7, and then given LRUD data for station 4, followed by stn 8 to start a new passage. Remember that for this station 4 the LRUD data is the cross section of the new side passage at this station and not the same LRUD data for stn 4 in the main passage. Without the second '*data passage ... ' line survex will put a solid passage section from stn 7 to stn8 where no real passage exists.

I'm still getting to grips with Therion since the Mendip course, but I have learned that it will also create passage walls from the plan sketches you create, so you can create solid models from survey data which is missing the LRUD data. I've not worked out how it get the passage height in this case, as it does not seem to determine it from elevation sketches as far as I can tell.

Hopefully this example explains this more clearly. This Rowten Sumps passage survey contains a couple of T junctions. You should be able to cut and paste the data below this line into a text file and process it in Survex:

; Rowten Sumps to Master Junction, and up to Swinsto Streamway Junction
; 15/11/2008
;
; Instruments: Footleg
; Tape:        Tony Cook
; Notes:      Footleg
;
; Instrument set and calibration details
; Footleg's Suunto Tandem. ULSA 50m Tape
;
; Footleg: Compass 190, 011 Clino -04, +04

*begin RowtenSumpsPassage

*calibrate compass +4.0


;fr to  tape comp clino
2 1 9.80 307 -1
2 3 8.16 162 1
3 4 19.43 175 -2
4 5 2.17 005 31
4 6 8.00 131 -2
6 7 17.81 192 -2
7 8 2.07 253 6
7 9 7.48 089 0
8 10 5.63 232 1
10 11 11.13 183 -2
11 12 5.43 181 -3
11 13 15.00 136 -2
13 14 4.71 168 0
14 15 8.21 217 0
15 16 10.05 221 -2
16 17 10.35 122 0
18 17 4.23 078 1
17 19 6.72 120 0
19 20 10.68 090 2
19 21 2.51 174 4
21 22 12.23 201 -1
22 23 8.93 190 -2
23 24 10.25 227 -1
24 25 11.19 190 -2
25 26 9.61 252 3
26 27 6.81 285 -5
27 28 6.02 214 0
28 29 5.66 286 -3
29 30 13.92 236 -1
30 31 11.08 241 1
31 32 12.73 287 0
32 33 6.31 014 -5
33 34 20.13 326 -1
34 35 19.56 318 -2
35 36 1.24 050 11


*data passage station left right up down
1 1.5 1 0.3 0.8
2 1 4.5 0.3 0.4
3 1.6 2 0.3 1
4 2.7 2 0.6 1
6 1.3 4 0.6 0.5
7 2.5 2 0.5 1.4

*data passage station left right up down
9 1.1 1.1 0 0.7
7 2 2.5 0.5 1.4
8 2 3 0.2 1.6
10 2.5 2 0.6 0.8
11 2.6 1.5 0.6 0.5
13 1.5 2 0.3 0.8
14 1 3 0.6 1.6
15 2 1 0.8 1.4
16 2 2 0.6 1
17 1.5 2.5 0.7 0.5
19 2.5 2 0.6 0.8
20 0.5 3.5 1 1.4

*data passage station left right up down
19 2.5 2 0.6 0.8
21 2.7 1.6 0.3 1.7
22 2 2 0.9 1
23 2 2 0.2 1.5
24 1.5 2.5 0.3 1.6
25 1 3 0.8 0.6
26 3 2 0.5 1
27 5 0.7 1 0.4
28 4 4 0.8 0.4
29 4.5 1.3 0.6 0.4
30 5 3 0.8 0.4
31 5 5 0.6 0.4
32 0 6.5 1.4 1.2
33 3.5 2 1 0.6
34 3.5 1 1 0.5
35 3.5 2.5 0.2 0.4

*end  RowtenSumpsPassage

Thanks Footleg. I seem to have understood it in the same way as you then. 1 block of data for the centreline followed by separate blocks of LRUD data for each "branch" of passage.

I do like the result, but it involves quite a lot of manual work to create it in terms of splitting out the LRUD data and determining where branches are and potentially swapping Ls and Rs. Something of a departure from the Survex ethos of entering your survey more or less as it appears in your notes.

Rhys

I take your point about complication but it helps if the person with the instruments (I use a SAP and Disto and have a trusted person doing the notes) understands how the data will be used.  Thus we survey in ther direction of travel and I swap LR if I'm doing a back bearing.  For side passages I take a LR in two directions - one on the main leg and the other facing into the side passage.  As I'm generally the person doing the data entry I have it in my mind what data is required.  My note taker makes sure that I provide the correct amount of data.  Also if a station occurs (as often) at a change in passage dimensions I'll ask the notetasker to record additional detail such as under the Up reading right a second value where the roof height changes.

For underwater surveying I have recorded LRUD data at every (other) line tag (5 or 10 m) to define passage shape using SONAR.  For example in Pwll-y-Cwm to Daren Cilau it is every 5 m to add "meat" to the already established centreline.  The vis. is typically poor (less than the passage dimensions) and multiple shots are made to check accuracy.  Although incomplete these data indicate where there might be side passages (or more likely oxbows).

Rhys, I've always taken my notes with centreline in one section, and LRUD in another - so in fact the notes are entered just as they are written down.

The problem with trying to combine them into one section is that LRUDs are about stations and centrelines are about legs, so formats that combine them are at best a bit awkward.

And somehow you have to tell survex where to break tunnels. I believe olly did look at various ways of trying to infer them from station numbering, but there is no reliable heuristic. This is the same reason that toporobot enforces surveying in 'series'. Where a series is a 'contiguous passage tube'. It has never been a popular scheme in the UK, but we're all getting exposure to it now because pockettopo only works if you use 'totprobot-style' numbering. The UK-style numbering is bust.

I did fix the loch 'loading survex v1.1.15 .3d files' issue after the mendip session, but haven't got round to uploading the binaries yet. Sorry about that - I'm far too busy building an extension right now to get any survey software work done.

I think it is an over simplification to consider LRUD data as only being associated with a station. It has to be associated with a station in the context of a leg. Otherwise you cannot determine which directions the L and R are referring to. I have always thought of the L and R as being the measure of the passage width orthogonal to the direction of the survey leg they are attached to. So to me it has always made more sense to record LRUD data as part of the leg. The important additional information being which of the two stations in the leg if belongs to.

On another point Wookey made, I would say PocketTopo does not force toporobot style series, because it allows branches in a series, whereas toporobot data enforces each series number to be a single continous set of legs with no branching. In fact in PocketTopo I generally use one prefix number per survey trip. Or at least one prefix number per set of connected stations in a trip. So I'll have lots of side passages sharing the 1.x prefix. I'll only change to a 2.x series on the next trip or when we've stopped surveying and then started another section of survey attached to some other part of the cave not onto the 1.x series.

footleg said:

I think it is an over simplification to consider LRUD data as only being associated with a station. It has to be associated with a station in the context of a leg. Otherwise you cannot determine which directions the L and R are referring to. I have always thought of the L and R as being the measure of the passage width orthogonal to the direction of the survey leg they are attached to. So to me it has always made more sense to record LRUD data as part of the leg. The important additional information being which of the two stations in the leg if belongs to.

Click to expand...

I agree, LRUD in isolation, or attached just to a single station, are wholly meaningless. They must relate to a leg in some way or another. Are they perpendicular to the leg that leads to the station, that from the station, or does their base bisect those two legs? This is one reason why I so prefer the Pocket Topo/Therion methodology of using splays that have an absolute vector to define one's passage dimensions.

footleg said:

On another point Wookey made, I would say PocketTopo does not force toporobot style series, because it allows branches in a series, whereas toporobot data enforces each series number to be a single continous set of legs with no branching. In fact in PocketTopo I generally use one prefix number per survey trip. Or at least one prefix number per set of connected stations in a trip. So I'll have lots of side passages sharing the 1.x prefix. I'll only change to a 2.x series on the next trip or when we've stopped surveying and then started another section of survey attached to some other part of the cave not onto the 1.x series.

Click to expand...

Agreed. I didn't quite understand where Wookey was coming from on that,

wookey said:

Rhys, I've always taken my notes with centreline in one section, and LRUD in another - so in fact the notes are entered just as they are written down.

The problem with trying to combine them into one section is that LRUDs are about stations and centrelines are about legs, so formats that combine them are at best a bit awkward.

And somehow you have to tell survex where to break tunnels. I believe olly did look at various ways of trying to infer them from station numbering, but there is no reliable heuristic. This is the same reason that toporobot enforces surveying in 'series'. Where a series is a 'contiguous passage tube'. It has never been a popular scheme in the UK, but we're all getting exposure to it now because pockettopo only works if you use 'totprobot-style' numbering. The UK-style numbering is bust.

I did fix the loch 'loading survex v1.1.15 .3d files' issue after the mendip session, but haven't got round to uploading the binaries yet. Sorry about that - I'm far too busy building an extension right now to get any survey software work done.

Click to expand...

Thanks for the reply. As others have pointed out, LRUDs don't make sense without reference to legs and legs don't make make sense without reference to stations. The whole lot is linked. Surely you just need to apply a convention such as recording the LRUD data at the "from" station in the direction of the leg. That's what I've always done and thought it was fairly standard practice. I've never come across centreline and LRUDs being recorded separately.

A thing I really like about Survex is that you can enter your data in any order, call the stations whatever you like, change layout to suit your own style etc. This seems to have been lost for the passage tube feature. Now, I won't pretend to be a hugely experienced surveyor and I really wouldn't have clue how to write surveying software, but can't Survex work out what's a branch and what's not? It knows about which stations are connected to which and to how many.

I have used Toporobot on expedition and found the station numbering tedious. I've not used Pockettopo or DistoX as yet. Believe it nor not, many of us have not yet made the transition to paperless surveying and are still relying on more traditional techniques!

Good luck with the extension. I'm finding gardening in the sun far more attractive than drawing up a survey at the moment!

Rhys

Rhys said:

Believe it nor not, many of us have not yet made the transition to paperless surveying and are still relying on more traditional techniques!

Click to expand...

lol

I'm waiting for the next generation; that doesn't rely on an obsolete instrument and palmtop!

Rhys said:

lol

I'm waiting for the next generation; that doesn't rely on an obsolete instrument and palmtop!

Click to expand...

Well, I gather that Beat is working on a replacement DistoX and I am sure we can get PocketTopo running on an Android Slate (Tablet, call 'em what you will) just as soon as Otterbox have produced a waterproof case for them. Awkward to carry, but the bigger screen will be a serious benefit.  In the mean time I do know that Andrew once collected data using his Android phone.

I'd like a dive proof digital compass with an LCD display that my poor eyes can read and doesn't go into some wierd mode (like my diving watch) when you press the wrong button.

Oh and a tablet computer waterproof to 200 m that you can still write on.

I've got a spare SONAR wand - maybe Beat could fit a compass module and BlueTooth to that!?