Hi Rodrigo,

A general question: can someone point me a reasonable situation where having 2 scraps in the same TH2 file makes sense/is important?

It is exceedingly rare for me to have a .th2 with just one scrap. If one passage overlaps another, then you need two scraps do they can be drawn below above/below each other properly (eg. with translucency, or just hiding the lower passage, or with background colours). That could just be a short roof tube, or a fork where one climbs over the other. It would be crazy to have another .th2 file for each of them, since you probably surveyed them at the same time. So instead, you have two scraps in the one .th2 file. Back before you had smooth-shading, you needed to break your survey into several scraps just so it could colour them differently by altitude as the passage sloped uphill (eg. one scrap for every 5 metres altitude change). You still need to do that if you have abrupt changes in height, since smooth-shading will not change colour nicely at the edge of the drop, but it will change colour nicely at the edge of a scrap, as long as it has the correct stations marked. If you have a high level passage that intersects a lower level passage (so you have a pitch down into it), then continues at high level on the other side, and you surveyed the upper level stuff all in one survey, you would have to end the first scrap where it joins the passage, then create a new scrap on the other side. This is because a scrap cannot have multiple outlines. Although Therion might sometimes understand it if you do have 2 outlines in one scrap, it cannot export it properly in KML format, and struggles with some other outputs too. So you are not supposed to do it. You are supposed to use two scraps. I also have my ropes on a rigging topo in separate scraps from the cave, so we can use maps to select the rendering with and without some of the ropes (where a layout can only disable them completely). Sometimes, I have another scrap just for adding another layer of information on a survey, such as hardware serial number labels for fixed aid maintenance. I don't want them on the main survey since regular cavers won't know why XY123 is written next to an anchor, but I want them for when I create a special version of the survey for the hardware maintainer. Lots and lots of reasons :) Cheers, Tarquin

Rodrigo For me, all the reasons that Xavier and Tarquin have pointed out. If a survey encompasses only say 20 m of passage, then it is likely only to contain a single scrap. If it is 50 m of passage, then likely two… My process typically has one th2 for a survey trip/file (there might be multiple ‘trips/files’ per day, for instance if we have the scenario of a vertical cave like that discussed recently on this forum, or if there are multiple teams surveying on the day). To the reasons for multiple scraps per th2 I would add: * Scrap joins are fully automatic within the same th2, if they are drawn contiguously, so it is better than creating a new th2, where at best they will be semi-automatic. See https://therion.speleo.sk/wiki/tips?s[]=scrap <https://therion.speleo.sk/wiki/tips?s%5b%5d=scrap&s%5b%5d=join#joining_scraps_together> &s[]=join#joining_scraps_together * Many small scraps means that you are readily able to adjust the boundaries, with a degree of granularity, of sub-maps and maps in large multi-sheet caves (when exporting map outputs, not relevant when exporting atlas outputs). I want to adjust the boundaries because I prefer to use ‘map outputs’ to manually emulate what might usually be done with ‘atlas outputs’. I find maps are easier to control than atlas (counter-intuitive perhaps). I adjust the boundaries because as exploration and the cave develops, parts of the cave that ‘naturally go with each other’ can change over time. * Another reason that escapes me now… On the topic of alternatives to XTherion’s graphical editor. It would be nice to have one, although after 15 years I am quite used to it, and only a couple of new (probably impossible for XTherion) features would make it superb! For me a critical feature of Therion ecosystems is the ability to collaborate and retain project histories, such as with git. A possible shortcoming of alternative editors is that so far each rearranges the content of the th2 file, without necessarily making any changes to the output. ie open the file, make NO changes, save the file. The ‘output’ of the file is the same, but internally objects and formatting are completely rearranged. This obfuscates the ability of git to highlight for users changes that have been made in any particular commit. This is a problem because each user on a project should have the freedom to use whatever editor they like – one using XTherion, one using Mapiah etc. Also alternative editors need to be able to edit the th2 file ‘in place’ on the storage device. Browser based editors have so far made a copy of the th2, and edit that in the browsers storage, making the original th2 an orphan. This relyies on meticulous document management by users to compensate for that. It would be great to see alternative editors – I’m just adding more constraints to the development brief! Thanks for thinking about this. Bruce From: Therion <therion-bounces@speleo.sk> On Behalf Of Rodrigo Severo via Therion Sent: Thursday, 30 January 2025 03:17 To: therion <therion@speleo.sk> Cc: Rodrigo Severo <rsev@pm.me> Subject: [Therion] Two scraps in the same .TH2 Hi, A general question: can someone point me a reasonable situation where having 2 scraps in the same TH2 file makes sense/is important? Regards, Rodrigo