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