Thankyou Andrew, Kevin, Vasily, Footleg Your feedback appreciated, I’ll build on what I started, eventually, and put something on the wiki. My view is that that there is no single consistent approach with Therion, instead there are principles that can be chosen or discarded by individual users. The evidence for this is the wide variety of approaches described on the wiki and on this forum over the years. I don’t really have a good handle on what all these approaches are yet, which is why I make these exploratory contributions! But I feel like understanding is getting close! A reason why there is no single approach is because we all have differing circumstances and preferences that make some aspects of project organisation seem better than others. ie * legacies, such as data from precedent software (PocketTopo, TopoDroid, Survex, pencil and paper, etc) * legacies such as ‘the way my peers do it’, or ‘the way I did it the first time I could make Therion work’, etc * personal preferences for organising data, * how big your projects are, what you want to do with them or use them for, and * what other characteristics you place value on, and which ones you see as disadvantages or advantages. Vasily’s very ordered folder structure is the sort of thing you can do if adopt what I called ‘Scrap and map definitions – outside trip file – outside survey’ SAMD-OTF-OS. Will Urbanski did a similar thing. I like the orderliness of it, and that maps are not tightly bound to surveys, but seems to me it would entail lots of navigation while working on the project, as all the components you need while drawing one trip are stored far apart. That is just my impression, and it might be quite wrong, as I have never developed a project of my own along those lines. Like I said it all depends on preference, and what you see as advantage or disadvantage. Footleg. I have two cases like what you describe, where multiple surveys (up to 6) are describing either parts of the same chamber, or parts of a tightly interconnected part of the cave. In one we made no allowance, and stuck to our system (SAMD-ITF-OS) and in hindsight, was a mistake – drawing and joining scraps was a nightmare. In the other we bent the system slightly (so slightly I had trouble finding it just now) in effect creating a .th2 file that contained survey stations from 6 surveys. That one was easy, and although is locally a bit of SAMD-OTF-OS, does not seem to create any glaring dislocation of the dominant pattern. Nothing bad happened in terms of project consistency. Like Footleg describes, I hate adding namespace descriptors to each survey station, so I never do it now. Rather, I add it in the header, as Footleg described, so that the station points have names that match exactly the xvi imported from PocketTopo. I use the revise statement to keep the survey stations in the scrap in this clean state. It is described in https://therion.speleo.sk/wiki/paperless#data_transfer_from_pockettopo_to_th... Search for the word revise about ¾ way down the page. Kevin’s question about plan map of whole system and multiple projected elevations probably has a simple answer, but I have never used Survex, so it introduces variables that I know nothing about. If Therion is fed individual survey trip centrelines, then Therion can be used to manage these into the various xvi files and scraps and maps of whichever projections and cave extents that you want. If Therion is fed a single monster 3d file then I imagine it will be a challenge. Not for me to comment on really, as I don’t know what I’m talking about. So the last pages of the document posted did have a list of pro’s and con’s for each pattern, but I did not label them as pro’s and con’s, because one persons pro is another persons con. I’ll add to them based on your feedback however. Sooner I get it on the wiki, sooner others can add their insights to it. Bruce From: Therion [mailto:therion-bounces@speleo.sk] On Behalf Of Footleg via Therion Sent: Saturday, 8 July 2017 1:26 AM To: Bruce Mutton via Therion <therion@speleo.sk> Cc: Footleg <drfootleg@gmail.com> Subject: Re: [Therion] Therion Theory - scrap and map definitions Hi Bruce, An interesting read. I think the test of any model is how well it handles the exceptions. In the case of my own projects (where I use my recommended structure of course) I have cases where I have to draw up a section of cave which spans more than one trip in one drawing (typically difficult junctions where approach passages were surveyed on different trips). So here I have to add a .th2 file at a higher level than the trip and have to draw the scrap referencing the station names with more than just the number. The tip to specify the namespace in the scrap header is how I handle this where I can keep each scrap to an area belonging to a single trip (I still might want to draw multiple scraps in the same map editor file, hence the need to place the .th2 file outside the trip). But in some cases to get things to output how I want, there is no way to avoid having stations from multiple trips in the same scrap. So here each station name needs to include the namespace. So in reality the model I recommend only works in idea cases, and needs to be merged with parts of some of your other models to deal with these exceptions. The key thing I try to avoid as far as possible is having to add namespaces to each station (as it means you can no longer just click on the stations in a sketch imported from PocketTopo and have the station numbers set automatically). I usually end up clicking on all the station points to give them automatically assigned numbers, and then add the namespace using search and replace in a plain text editor. It would be good to add an analysis of the pros and cons of each structure to your document, covering how they handle the imperfect structure of real world data. Footleg On Thu, Jul 6, 2017 at 12:38 PM Vasily Vl. Suhachev via Therion <therion@speleo.sk <mailto:therion@speleo.sk> > wrote: Hello Bruce and All I had to draw a few large caves and I want to share my experience: 1) I always keep scanned survey notebooks. This is an artifact obtained in a cave and is the source of truth. 2) I store the entire centerline in a separate directory with a split into files on a trip basis. I think this is more correct because the centerline is a direct reflection of the survey notebooks. In the case of an error, this allows you to quickly navigate to notebooks. Entire cave centerline assembled in index file inside centerline directory. 3) I do not tie maps tightly to survey trips because it's usually more convenient to draw a map that covers a cave part (passage, grotto) rather than surveying trip. I call such dedicated part of the cave as `subsystem`. Subsystem maps are stored in separate subsystem directories. In each directory there are files `thconfig`, * .th2 and a file `maps.th <http://maps.th> ` in which the definition of maps and joins is stored. I store the definition of maps of the entire cave in the top directory in the `maps.th <http://maps.th> ` file in which I connect the` maps.th <http://maps.th> ` files from the subsystems' directories. I do not use therion namespaces for maps because the number of maps are much smaller than the surveys. Uniqueness of names of maps I support manually. Folder structure example: cave +-- survey # scanned notebooks +-- trip1 +-- 1.jpg +-- 2.jpg +-- 3.jpg +-- trip2 +-- trip3 +-- trip4 +-- cl # centerline +-- cave.th <http://cave.th> # index file with equates +-- trip1.th <http://trip1.th> +-- trip2.th <http://trip2.th> +-- trip3.th <http://trip3.th> +-- trip4.th <http://trip4.th> +-- model +-- thconfig +-- map +-- p # plan +-- subsystem1 +-- 1.th2 +-- 2.th2 +-- maps.th <http://maps.th> +-- thconfig +-- subsystem2 +-- 3.th2 +-- maps.th <http://maps.th> +-- thconfig +-- maps.th <http://maps.th> +-- thconfig +-- rr # extended elevation +-- r240 # elevation at 240 06.07.2017 03:08, Bruce Mutton via Therion пишет: A little while ago I explored the effects of different ways of relating scraps and maps to surveys, and to the files that contain them. I came up with the attached text, which I might get around to turning into a wiki page sometime. There are links to some examples already available via the wiki. Before I wiki-ise it, I’d like some feedback, or criticism, as appropriate! Is it helpful? (I think so) Footleg, I plagiarised your page, just a little. Also, if Danilo Magnani or Will Urbanski are still listening, or if someone knows how to contact them, I’d like permission to put on the wiki the project samples they posted to this forum some years ago. Those are named Complesso - Buc di V, and DDC – Radio Collar Cave. Bruce _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion -- WBR, Vasily _______________________________________________ Therion mailing list Therion@speleo.sk <mailto:Therion@speleo.sk> https://mailman.speleo.sk/listinfo/therion

10. 7. 2017 v 20:54, Martin Sluka via Therion <therion@speleo.sk>:

north_branch_scrap1_170321.th2 north_branch_scrap2_170321.th2 north_branch_scrap3_170321.th2

I apologize myself, more logical would be: north_branch_170321_scrap1.th2 north_branch_170321_scrap2.th2 north_branch_170321_scrap3.th2 m.s.