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:
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:
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
My data sets are
Glory '
-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
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