[Therion] Therion Digest, Vol 112, Issue 5

[Rob Countess]

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 at 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 <http://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 <http://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 at speleo.sk [mailto:therion-bounces at 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 at 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 at speleo.sk [mailto:therion-bounces at 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:
>
> rob.countess at gmail.com
>
>
>
>
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
>
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20150427/357fee63/attachment.htm>