- Therion - speleo.sk

Loch passage tube behaviour
by Bruce 23 Jul '13

23 Jul '13

Footleg I think the answer is 'yes'. Hopefully you can view the images embedded in the image rather than attached, otherwise this won't make much sense. In this example there is a single centreline (comprising both cave and surface survey) and 4 scraps. A short section of cave at the left hand end does not have any scrap drawn. Compiled with Therion 5.3.11 One interesting point is that regardless of the 'walls' setting, there is never a tube generated there once we have scraps drawn anywhere in this centreline. My deduction is that Loch uses only one type of tube generation per centreline, because in almost all my larger projects that transition between traditional survey and paperless survey, I have a combination of each type of tube generation within the same Loch model. This fits with the description in the Therion Book "walls <auto/on/off> turn on/off passage shape generation from LRUD data for subsequent shots. If set auto, passage is generated only if there is no scrap referencing given centreline." In these examples I have not used any 'point passage-height' or 'point dimensions' in the scraps. Paperless survey (no LRUD), walls auto, off or on (or not specified), No plan scraps. [Loch always guesses tube dimensions] -same if LRUD present and walls off Paperless survey (no LRUD), walls auto, off or on (or not specified), plan scraps drawn [Loch uses scraps for tube width and guesses tube height] Now, I added a few LRUD to the same centreline, including some with only UD data dimensions station left right up down 1.4 - - 20 20 1.5 - - 20 20 1.6 2 2 20 20 3.13 10 10 20 20 3.14 10 10 20 20 Tube generation, where it occurs extends one station beyond those specified. Paperless survey (some LRUD), walls on or auto (or not specified), No plan scraps. [Loch uses LRUD for tube dimensions and only for stations where partial data is provided, it guesses the missing data ie if a station has no data, no tube is generated] And now adding some scraps and things get interesting. Paperless survey (some LRUD), walls off (or not specified), Plan scraps drawn. [Loch uses scraps, not LR, for tube plan dimensions, and UD for height where specified, otherwise height is guessed. Where there are no scraps, LRUD is not used.] That is perhaps contrary to what one might expect from the Therion Book 'walls' entry. It also produces perhaps the best model. Paperless survey (some LRUD), walls on or auto, Plan scraps drawn. [Loch uses scraps AND LR for tube plan dimensions, and UD for height where specified, otherwise height is guessed. Where there is no LR, then it is guessed. Where there are no scraps, LRUD is used.] If I change the LRUD definition like this. data dimensions station up down 1.4 20 20 1.5 20 20 1.6 20 20 data dimensions station left right up down 3.13 10 10 20 20 3.14 10 10 20 20 ..then the guessed width troubles continue. Paperless survey (some LRUD), walls on or auto, Plan scraps drawn. [same as above] So my final conclusion, for paperless survey, no need to include walls statements in each survey, or if you do, walls off is better than on or auto. If you happen to provide some UD data, then your model will be improved (more realistic). I surmise that with these same settings, scraps with point passage-height or point dimensions will have a similar effect, but I have not tested this. Bruce

3 3

Re: [Therion] Options for converting splays in my Cave Converter tool
by Graham Mullan 22 Jul '13

22 Jul '13

I agree with Andrew and Martin. Splays are a different - and in my view more useful - form of data from LRUD. Keep them as splays. One or twice (in Therion) I have needed to convert a splay to a leg, but that is a highly selective process and not for a conversion tool. Graham -- graham.mullan(a)coly.org.uk

1 0

Options for converting splays in my Cave Converter tool
by Footleg 20 Jul '13

20 Jul '13

As I am working on improving the handling of splays in my cave converter tool, I wanted to get the opinions of other surveyors as to what options are actually useful. Previously the cave converter automatically converted splays to LRUD dimensions for survey legs, removing the splays as it did so. This was because I came to DistoX surveying from traditional instruments where I typically only measured LRUD at stations. So my initial thoughts on splays were that they were just a way to measure these passage dimensions at each station. As I progressed in knowledge I came to realise the value of splays for marking key points to assist in sketching the shapes of chambers and interesting bends and shapes in passages, to mark side passages and key formations or other features. So I changed the converter to only remove the splays when just LRUD measurements were found at a station. This removed the masses of splays for long sections of simple passage, but retained them at interesting points where more splays were measured. Another few years on, and I am finally moving this LRUD generation code from the PocketTopo file parser into the general survey utility classes. So it will be possible to generate LRUD data from splays for any survey from any format read in. This is where my current questions arise. Which of the following options do people think are genuinely useful: 1) Remove all splays from the output survey file. 2) Keep all splays and also generate LRUD data for legs with stations which have splays. 3) Remove splays which are used to generate a passage dimension (one of LRUD), but keep the rest of the splays. 4) Remove splays when generating LRUD data only when there are no splays at a station other than those used to generate the LRUD data. Anything I missed? Feedback welcome. For anyone who is not familiar with my Cave Converter, the homepage for the tool is: http://wscc.darkgem.com/caveconverter/ Footleg

4 5

NODATA value in loch surface
by Jonny Prouty 05 Jul '13

05 Jul '13

Hello all, My apologies in advance if I've overlooked something, but is there a way to instruct Loch to NOT draw elevation data equal to a certain value? For instance, in my current model, I do not want Loch to draw any elevations that are equal to 0. Is this possible? Thanks very much in advance! Cheers, Jonny ^v^

2 1

Typical Head of Water between entry and exit of sumped passages
by Footleg 27 Jun '13

27 Jun '13

I am working on a master survey of the Kingsdale System in Yorkshire, UK. There is a substantial submerged portion to the system. Over a rough distance of 1500m of sumped passage, what difference in water levels could be expected between the upstream and downstream ends of the sump? The diving data just records water depth, so it computes both ends of the sump as having identical water levels. We know in flood conditions the upstream sump level backs up considerably. But assuming the diving is done in conditions of low flow, what typical difference might be reasonable to expect in the altitude of the resurgence and of the upstream end of the sump (determined by survey data from an entrance)? My data shows a significant difference, but I do not know how much of that difference might be expected and how much is due to errors in the dry passage survey and entrance altitudes? Footleg

5 11

Re: [Therion] Therion Digest, Vol 90, Issue 9
by Graham Mullan 27 Jun '13

27 Jun '13

Footleg said: > what difference in water > levels could be expected between the upstream and downstream ends of > the sump? and Wookey responded: > This is a question for hydrologists, not cave surveyors :-) Wookey is wrong. Without the data from survey and from geodesics the hydrologist would have no way of knowing the facts of this. In science, observation comes first :-) Graham -- graham.mullan(a)coly.org.uk 0117 9502556 or 07887 637064 (or 0844 2327803)

1 0

Fwd: Diving data loop closures altering depths
by Footleg 17 Jun '13

17 Jun '13

This is a Survex issue but may also be of interest to this list. Plus the Survex list does not accept my 7 KB of data as it says my post is too big. Posting the data here for lack of a capable list for Survex. Footleg ---------- Forwarded message ---------- From: "Footleg" <drfootleg(a)gmail.com> Date: 17 Jun 2013 14:38 Subject: Diving data loop closures altering depths To: "survex" <survex(a)survex.com> Cc: Trying to track down why some underwater data was several metres higher than a sump water surface, I discovered that closing loops between stations at the same depth in diving data alters the depth of surrounding data. This was not expected! I've attached a fragment of the data which illustrates this. Without the loop closed: Station entrance.030 is at depth -5.30 Closing the loop: *equate Entrance.010 EntranceLoopNorth.019 where both these stations are at the same depth, but horizontally displaced (a common scenario as depths are absolute but length and compass errors accumulate in diving data), now: Station entrance.030 is at depth -5.48 Is this a bug, or have I not understood something here? Footleg

2 2

Using autonamed station named from PocketTopo sketches in complex projects
by Footleg 16 Jun '13

16 Jun '13

Having embarked on drawing up a larger cave system with data from various sources, I discovered that PocketTopo sketches brought into the drawing editor just get names local to that sketch (e.g. 3.3, 3.4, etc.) but my project builds up the centreline from multiple centreline surveys. So the actual name of the stations in my cave is like 3.3(a)subsection.dataset.cavename Thinking there must be a solution to this, I searched the wiki, and found it (Thanks Bruce!). I can use the -station-names option on my scraps in the sketch to say what the full name of the station should be. But my station names do not need a prefix (it is already set from the xvi file by the editor) and with a bit of experimentation I discovered that to omit the prefix I have to put a pair of double-quotes as the prefix. This works, but is there a neater way to do it? e.g. -station-names "" @ShortDryWay.swildons means my station with -name 3.3 will be treated as 3.3(a)ShortDryWay.swildonsin the scrap and this is what my station in the complete cave centreline data is named so it works. It just seems unintuitive to have to give a blank prefix this way. Bruce's example also includes author and copyright options on the scraps. How does Therion use these? Or are they just allowed on the scrap options but not used in any generated output? While reading Bruce's excellent advice pages on data structures I spotted some places where more recent developments or ways I work make things easier since the section was written. So I've added a tip on getting data off PDA via memory card, and a link to Andrew's TopParser application to this wiki page: http://therion.speleo.sk/wiki/doku.php/paperless#data_transfer_from_pockett… Footleg

3 4

Selecting different maps for output in one config file
by Footleg 16 Jun '13

16 Jun '13

I am trying to generate PDFs for different parts of my cave using named maps. But if I select one map, export it and then select another and export that all in one file then it appears all the selects are processed before any exports. So all my output PDFs are the same. e.g. The following config file: source swildonsmaster.th select EntranceSeriesPlan@SwildonsHole export map -projection plan -layout local -o swildons_ent_plan.pdf select testPlan@SwildonsHole export map -projection plan -layout local -o swildons_plan.pdf Does not give me a PDF of just the entrance series. I get two PDFs of the testPlan map. Is there any way to do this from a single config file? Footleg

2 1

How to mark station with labels and make them appear in plan and extended projection
by Marco Menchise 16 Jun '13

16 Jun '13

Hello, maybe it's a silly question, maybe not: It would be useful to have a station point labelled with some text and get the label appear either in plan than in extended projection. I made many attempt to achieve this but I cannot see any label unless I define a "label" point in 2 .th2 scraps (one for the plan, another for the extended projection) and include them in the map. I know it is possible to label a station in the centerline file but the label does not appear in projections. I was searching if there is any simpler way to get those labels visible than defining 2 scraps. Thanks, Marco

2 2