Thanks for your insight,

Vancouver Island and New Zealand are very similar. Most of our caves are highly accessible due to logging roads. In my main project most caves are less than 100m from a road. The land is mostly public crown land. Plus some bastard created a commercial backroads map book and marked the entrances to Glory 'ole Arch and Resonance. It sells 20000 copies and I thought there would be a massive influx but the truth is 99.99 percent of people don't want to cave. Thank god.

The Vancouver Island Cave Exploration Group was an exclusive brotherhood, you had to be sponsored by a member in order to join. The idea was to protect the caves. I was caving 5 years on the Island, leading and organizing lots of exploration before I finally said, look sponsor me for christ sake. Sadly because the club was so exclusive, egos were bruised, splinter groups formed (and collapsed) and there were some ugly politics. The by product was that the pace of exploration drastically slowed down as old members got old and new cavers (Do you guys call them Ouigees (Weegees) too?) had a hard time making the transition to independent cave explorers.

Anyway I totally understand the data shackles your fellow cagers have you wearing.

As for data structure, I think I was heading for number 3 naturally but only because I never thought of 1 or 2. I will go with number 3 and let you know how it turns out.

Since it may be beneficial to my learning, I may create a sample data set with my cave data and post it to the Therion wiki (long term goal though - probably not for months). I'll just hide the cave locations by commenting out the fixed stations. Joking. Ill just translate the coordinates to put the cave in the ocean.

I've always like the idea of a "series" in bigger caves, i.e. a group of related passages that help divide the cave into neighbourhoods. For example Arch Cave has the Arch series (main entrance stream way), the Tunnel vision series (separate entrance larger "tributary" stream way, that follows a separate bedding plane/fault 50 m below the Arch Stream, the Triple Pots series (fossil upper level passages off Arch stream way vadose) The Fecal pot series (another parallel overlying stream), Mudfinger Series (large fossil series that eventually leads to two other separate streams. There are many others but these five I mention all overlap significantly in plan view. It would makes sense to produce stand alone maps of each series.

I think I will go for a structure of
1) Caving Area Level- surface data, area maps
2) Cave Level- define entire cave maps from level 3 (is this possible or do i have to repeat definitions from level 4 data I'm confused since i haven't done it yet) I will probably want surface data here too.
3) Series Level - define series maps from scraps
4) Scrap level
5) Survey trip Level

Anyway I'm going to play around and try to figure it out before I go too far in one direction. I still don't have a very good grasp on Therion. It seems kind of not fully object oriented. I pictured it as a bunch of building blocks (scraps and associated centrelines) that I could put together hierarchically and that I could easy pass parameters from one level to the other or change parameters of one branch or another. In Walls and On Station it was super easy to change the colour of centreline for 2D or 3D display in a hierarchical manner, just right click on the appropriate  survey or folder (on Station) or Book (Walls). I used this a lot to visualize the cave. Eg make all newly surveyed passage pink, colour code passage by survey date, depth etc. With my limited understanding of Therion, I've not yet been able to do this. goes now it is hard to subdivide parameters of a map. It seems like there should be some commands for this. e.g. if survey = Arch then colour = blue, if team includes "Rob Countess" then colour = yellow, if flag = lead then colour = pink, if flag = drafting in then scrap/map = blue, elseif drafting out then scrap/map = red, elseif oscillating then scrap = yellow, else if scrap = black. Actually that last one would be a useful visualization, now I want to do that. It should be easy to set labels to hide if font <7 pt, 

In answer to your "why not walls": Well i really like some features of Walls. The blunder detection system is awesome. Worth porting your data to if you can write a script for it, I found so many blunders in the old data I inherited, backlight/foresight, clino +/-, decimal misplaced, etc. The round tripping with SVG drawing programs gets super complicated when you have many levels because each level has many levels (centreline, passage, passage detail, labels, symbols) it does't understand overlapping passages. If your old centreline data is shitty like mine ( some is one man survey trips with topofil and ESTIMATED clino!!) and you are closing loops with new exploration ( the cave went from 1 loop to hundreds) then overlapping passages move and you have to redraw tons of stuff. I just got frustrated. I want a program that associated one passage A with centreline A and adjust A properly regardless of what B C D E are doing. plus I'd keep making mistakes and putting shit in the wrong layer (easy when you have 30+ layers and ADHD)  and having issues with grouping ungrouping and changing attributes. I don't know maybe there was a better way. I like Therions approach better - let the computer do it.

I'll probably keep parallel databases Walls and Therion. If I keep my datafile consistent I could probably figure out a conversion script. But we shall see. Maybe if I learn enough Therion will be enough.

Plus I like being a gatekeeper for my projects. You get to stay up to date and to on and to a degree direct  whats going on in your pet projects. When I used On Station everybody knew how to use it. When I switched to walls only a few people knew how to use it. So Therion is, so far, absolutely the least user friendly cave mapping software around, but at least I know I won't have someone scooping my best leads since they can't decipher the data. (only half joking)

The other main issue is lost data. I want to to fix this problem for the future. There are about 150 km of mapped cave passages on Vancouver Island and actual original survey notes or photocopies exist for 30-40 km. Perhaps from your point of view this is a good thing. Its interesting. I never thought of mapping a cave as destroying a future generation's chance to explore. I do get that though. I can remember going through my first virgin passage. It was just a short oxbow of a main passage that nobody bother to go through but i was thrilled. That said I hate resurveying or surveying something some asshole has scooped. I think of myself as saving future generations of cavers from having to waste time resurveying, by mapping and preserving the data. Its probably a moot point because technology already exists for handheld LIDAR so in the next few years we can just walk though the cave and produce a mm accuracy 3D model. I'm sure someone could write a program to produce 2D projections in standard UIS form from such accurate 3D data. See www.youtube.com/watch?v=DUEAz_naHHg

This video makes me wonder why I'm still wasting time with compass clino and tape (no one has DistoX2 here yet, I'll probably get on this year) when I should just scoop for 3 years until I get a zebedee. But of course I HAVE to know how the passages relate and I'm no Stephen Bishop.

Well I should stop procrastinating now,

Rob

On Sun, Apr 26, 2015 at 8:42 PM, Bruce <bruce@tomo.co.nz> wrote:

Rob

…my experiences only, others may have other perspectives.  And hope it is not exposing my ignorance.

What I have found is that once you start generating a particular structure (and naming convention) it is very tedious to rearrange it later, because the names and relationships get embedded in all of the scraps, maps, index files etc, of which there are a lot.

 

So, Low level map (ie first stage collection of scraps into usable maps) definitions;

 

1)       in the survey.th file outside of survey/endsurvey:  Was a feeble attempt to disassociate the maps (artistic and may have many forms) from the survey (predetermined by the survey that actually occurred in the field and ‘fixed’) when I was new to Therion.
Pros: means related map and scraps are close at hand to the survey when you are drawing and later when you want to edit.  No wondering where to find them.
-Lends itself to self contained map and survey datasets in each cave folder.
Cons: The map and survey may well be disassociated at the lowest level, but in a real cave system where multiple surveys are collected together in an INDEX file, they become dependant again, in that all references to the low-level maps need a suffix such as @cavename.  So they are really dependant in a hybrid kind of way.
-Is more complicated to figure out map references because of this.
-It is harder to completely rearrange the structure of the maps, for example, as you explore the cave and see that better map arrangements are possible.

2)       in the survey.th file inside of (and at the start of) survey/endsurvey:
Pros: same as for 1) and…
-Maps at the beginning because once the survey is entered you hardly ever change it much so the survey may as well be lower down in the file.  During drawing and subsequent edits (as always happen in a growing cave survey and map) the low level maps can get quite a bit of tweaking.  So beginning of file makes them quicker to find.
-Results in a truly dependant map and survey set (‘aesthetically’ cleaner than item 1 above)
-Easy to understand, fewer files.
Cons: Maps and surveys are codependant.  If once you have a hierarchical structure with your 43 caves entered and drawn, you want to  produce a map with part of one cave system and part of another system, which may be physically close in the earth, but in the Therion dataset in completely different folder branches because of how the cave exploration evolved, you will end up with complicated  map references.
ie @upperseries.cave1.region4
-It is harder to completely rearrange the structure of the maps, for example, as you explore the cave and see that better map arrangements are possible.

3)       not in the survey file at all: (I have never done it so a bit theoretical for me)
Pros: Maps are independent of surveys (except for the obvious relationship due to the survey stations that tie the map to the survey).
-Low level maps need not be limited by the extent of the low level surveys.  Make your lowest level maps suit the natural form of the cave passages, not the extent of arbitrary survey trips.
-I don’t think you end up with any subscripts in your map references ie @cavename, so very much simpler (I could be wrong here)
-You can dispense with ‘low-level’ map definitions altogether, and so for a moderate length (and simply laid out) cave, just put all your scraps in a single map definition for the cave (although this may not be very ‘modular’).
-Lends itself to hierarchical survey folders with all maps defined at the top project level (or cave level) folders if you want.
Cons: Another type of file to manage and keep track of (ie surveys, maps, indexes, layouts etc) – although this should not be a problem with modern text editors.
-Either almost twice as many files to manage (surveys and maps) or if low level maps are dispensed with, very long cumbersome to navigate map definition files.

 

So, what I currently do is described in number 1).

What would be an improvement is described in number 2) – thanks to Andrew Atkinson.

What I would try if I was start my ‘Therion Life’ again is described in number 3).

 

There is no reason why a dataset created along the lines of 1) or 2) cannot have a ‘parallel’ set of maps developed along the lines of 3) at a later date.  It is just hard to find the motivation if you already have something that works!  There is also the risk of confusing yourself with variations of maps that are similar to each other.

 

Anyway, enough talk.  I’ll get in trouble for not working on my share of the map drawing.

 

Bruce

 

From: therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Rob Countess
Sent: Monday, 27 April 2015 10:30 a.m.
To: List for Therion users
Subject: Re: [Therion] Therion Digest, Vol 112, Issue 5

 

Bruce,

 

Again thanks for all your help.

 

In your attachment you had some mention of where to put low-level map definitions. Could you explain the benefits of placing map definitions:

1) in the file outside of survey/endsurvery

2) in the file inside of at and the start of survey/endsurvey

3) in separate file

 

It seems like you've given this a lot of thought and would choose differently if you were starting out again and since I am just starting out I'd like to understand more.

 

Rob

 

 

The survey network and map hierarchies are then tied together in INDEX.th files

 

[If I were to start my 'Therion life' again, I would place the map definitions inside of, and at the start of the survey-endsurvey block to promote ease of use and simpler map references in INDEX files.  The above structure was intended to make maps independent of surveys (which is preferred), but I did not think it through – to achieve that we would have to have map definitions in separate files.  Separate files would work OK, but would increase the number or size of files.  At the time, we chose not to go this way.  Another time, I might choose differently.  Bruce]

 

On Sun, Apr 26, 2015 at 2:54 PM, Bruce <bruce@tomo.co.nz> wrote:

Rob

This is not a dataset, but it is an example of a file I have recently started placing at the top level of a survey project folder, to remind me and other users what conventions are used and preferred in a particular project.  It might, indirectly, help you think about some of the considerations when starting a large project.

See attached.

Bruce

 

From: therion-bounces@speleo.sk [mailto:therion-bounces@speleo.sk] On Behalf Of Rob Countess
Sent: Friday, 24 April 2015 7:58 a.m.
To: List for Therion users
Subject: Re: [Therion] Therion Digest, Vol 112, Issue 5

 

Does anyone mind sending me one of your data sets. It would help me understand the structure and organization.

I have data for several cave areas on Vancouver Island BC Canada in Walls and On Station. I want to convert the whole mess.

My data sets are

 

Glory 'ole/Arch Cave area

   -18 km in 4 main caves and a dozen or so smaller caves linked by overland survey and GPS

   - longest caves are  Arch (10.6 km km 3 entrances), Glory 'ole (2.7 km) Pellucidar (1.9 km) Resonance (1.8 km)

   - Arch cave is divided into several series based on streams and distinct areas of the cave

   - 3 caves (Glory 'ole, Resonance, and Arch) overlap in plan view (I want to produce a high level map with all three caves in different colours, initially just line plots but eventually real maps)

 

White Ridge

-7 km in 3 main caves and a half dozen smaller caves Linked by radio location and GPS

 

Larch Mountain

 

2 km in 3 main caves and a dozen smaller caves linked by GPS

 

I also have a friend that manages data for Weymer Creek (over 30 km in over 100 caves, longest are 12 and 9 km lots of caves overlap in plan view). I am trying to convince him to switch to Therion too.

 

I am looking for an example data set that has

 

1) multiple caves in one caving area

2) at least one cave large enough to be broken into series

3) overlapping layers in at least one of the caves

4) examples of files to produces different outputs with overlapping caves or cave series in different colours on the same map.

 

Thanks,

 

Rob Countess

 

PS If you don't want to spam the mailing list then send to:

 


_______________________________________________
Therion mailing list
Therion@speleo.sk
http://mailman.speleo.sk/mailman/listinfo/therion

 


_______________________________________________
Therion mailing list
Therion@speleo.sk
http://mailman.speleo.sk/mailman/listinfo/therion