If I interpret Marco's post regarding data structure description correctly,
it seems you have folders for
(hope my ascii pictures survive intact)
-Cave folder
|-'surveys',
|-'groups of surveys' and
|-'whole cave - collection of the groups' [thconfig file((s) for each
output task]
all at the same hierarchical level, but able to be stacked up or nested if
other caves were to be incorporated into the data set.
Seems nice and tidy to me, but the folder hierarchy does not match the
conceptual hierarchy of the data, which would be more like Jonathan
described,
-Region folder
|-cave folder
|-Surveys
|-Notes [scanned notes taken in cave]
|-Therion [survey *.th data files]
|-Pictures
|-Date [pictures taken on this date]
I like the concept that the folder hierarchy matches the data hierarchy and
especially that it is very cave centric, ie not just Therion data, but all
data related to the cave
Both the above seem quite tidy, and as Martin has just posted, each user
will have their own "cave project circumstances and preferences"
Marcos seems to me like it would have many versions of a number of thconfig
files. I have found maintaining consistency among many thconfigs to be
quite a problem, as I am still learning and refining my opinion of what is a
good way to set them out.
I am also trying to optimise my system for collaborative data entry and
development of the Therion cave dataset, which Therion seems ideally suited
to. Therefore the tiny size of the Therion batch files is an advantage I
want to keep. So I would adopt Jonathans 'single cave centric' model at
once, except I don't want to be emailing back and forth large chunks of
non-Therion data amongst the people developing the dataset, nor do I want to
have to pick out fiddly bits of non relevant data each time. I have adopted
the perhaps the lesser approach of having two parallel folders, one for
Therion data and one for non-Therion data such as photos, cave related texts
and articles, scanned cave survey notes etc.
The Therion folders look something like this;
(My thconfig files have the extension .thc - much nicer if using with
Windows OS)
(and as with the others, highly modular, one survey and very few scraps per
file)
(and with a fairly highly structured and explicit naming convention so you
know what is in a file without peering into it - not really described
herein)
-Regional folder [RegionINDEX.th contains very simple equates and 'maps',
Single Region.thc contains layouts and all exports for region wide outputs]
|-common folder [layoutSTANDARD.thc, club logos and graphics common to all
layouts]
|-outputs folder [all output files go here]
|-surface folder [overlandsurveys.th, overlandINDEX.th, surfaceINDEX.th,
surface.jpg]
|-cave1 folder [surveys.th contains centrelines & maps relating to
associated scraps, caveAElev290.th2 contains scraps generally relating to
survey A, caveINDEX.th containing entrance co-ords; equates; joins and maps,
single cave1.thc contains layouts and all exports for cave1 wide outputs,
and if there is no actual survey data, caveplan.jpg - a picture of an old
fashioned cave plan for which there is no data]
|-sketches [sketchAElev290.jpg containing sketches for scraps relating
to this cave.]
|-cave2 folder [caveINDEX.th contains very simple equates and 'maps',
Single cave2.thc contains layouts and all exports for cave2 wide outputs
|-group21 folder [same as for cave1 folder above]
|-sketches [sketchAElev290.jpg containing sketches for scraps
relating to this cave group or branch.]
|-group22 folder [same as for cave1 folder above]
|-sketches [as above.]
Cave1 is a simple cave a few km long perhaps; cave2 might have many km or
distinct 'branches'.
This is perhaps flatter than Jonathans, but still hierarchical. Has few
thconfig files, one per 'family' of passages 'selected' for output and one
'singlesurveytest.thc per cave, to enable frequent and quick checking of
survey and sketch data as it is being entered (and still they drive me
crazy). The common, outputs and surface folders live at the top level and
do not need to be shared (often) among users. The cave data folders can
easily be zipped without the sketches and shared by email. This is working
well informally with two users, but would require good discipline and record
keeping with more simultaneous users.
I plan to keep single thconfig files for exporting all outputs, but break
them up into referenced modules according to function; ie layoutMapPlan.thc,
layoutMapElevation290.thc, layoutAtlasPlan.thc, etc. This might make them
easier to manage.
We don't do splay legs (well, perhaps one or two for every 100 survey legs,
or if the passage is 20m wide and the surveyors' fussy) so I don't make a
distinction for them.
I have yet to deal with significant levels of the cave which over/under-lie
each other, but I will have to come to grips with it shortly. I am hoping
my structure above will work well in this scenario. I will heed Martins sage
advice quoted below.
"The main principle is that the map itself is divided into small pieces -
scraps. The scraps are absolutely independent from survey structure created
more or less historically. You may use in one scrap data from several
surveys made historically in very long interval by different surveyors. Only
condition is all the data are accessible in survey which include the map
structure with that particular scrap.
The main rules to create such structure is to divide the system into
horizontal layers (in case of map) which the atlas will be able to recognize
and shows in enough simple way. There one may see the importance of idea of
scraps -you may reorganize your structure anytime in the future.
The main problem is organize the maps and submaps. The structure of survey
data itself is existing more or less automatically."
Any other insights or ways of setting out the data appreciated.
Bruce
