Send Therion mailing list submissions to
therion@speleo.skTo subscribe or unsubscribe via the World Wide Web, visit
http://mailman.speleo.sk/mailman/listinfo/therion
or, via email, send a message with subject or body 'help' to
therion-request@speleo.sk
You can reach the person managing the list at
therion-owner@speleo.sk
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Therion digest..."
Today's Topics:
1. Re: Therion Digest, Vol 112, Issue 5 (Rob Countess)
2. Re: Therion Digest, Vol 112, Issue 5 (Bruce)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Apr 2015 15:30:23 -0700
From: Rob Countess <rob.countess@gmail.com>
Subject: Re: [Therion] Therion Digest, Vol 112, Issue 5
To: List for Therion users <therion@speleo.sk>
Message-ID:
<CAJJSGway102cCAHVUMhacaEsobRgyhAJn7WBd167chzLhRzeAQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 surfer/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:
rob.countess@gmail.com
_______________________________________________
Therion mailing list
Therion@speleo.sk
http://mailman.speleo.sk/mailman/listinfo/therion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20150426/1e56e71d/attachment-0001.htm>
------------------------------
Message: 2
Date: Mon, 27 Apr 2015 15:42:46 +1200
From: Bruce <bruce@tomo.co.nz>
Subject: Re: [Therion] Therion Digest, Vol 112, Issue 5
To: 'List for Therion users' <therion@speleo.sk>
Message-ID: <DEDCE55D68574851B851AF33E6437693@JUICEBRAIN>
Content-Type: text/plain; charset="us-ascii"
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:
rob.countess@gmail.com
_______________________________________________
Therion mailing list
Therion@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/e5e7d38a/attachment.htm>
------------------------------
_______________________________________________
Therion mailing list
Therion@speleo.sk
http://mailman.speleo.sk/mailman/listinfo/therion
End of Therion Digest, Vol 112, Issue 21
****************************************