- Therion - speleo.sk

Best approach for colouring elevations
by Tarquin Wilton-Jones 01 May '19

01 May '19

Hi folks, With either extended or projected elevations, we end up with a few passages overlapping each other. This is intentional (so displacing some of them is not a desired solution). However, it would be nice to be able to colour them differently, to make it easier to see which parts belong to which passage. Colouring by altitude doesn't help in elevations, because they are all at the same altitude when they are overlapping. "Colour by distance from the viewer" is better. This could be coloured by colouring the individual scraps, but that is messy, and hard to maintain. The desired output would be "colour by break". Meaning; each time there is a "break" in the map, change the fg colour. Does anyone have any tips on how best to colour extended/projected elevations? Is "colour by break" possible in some way? Or do you prefer a different approach? Cheers, Tarquin

3 17

new Therion 5.4.4
by Therion 01 May '19

01 May '19

Hi, there is a new release 5.4.4 of Therion. Release notes: v5.4.4 Therion 5.4.4 (2019-05-01): therion: * support for Proj 5.0 and newer API (proj.h) * bugs fixed: - segfault while generating SVG when compiled by newer g++ - incorrect EPSG projections handling if more than one EPSG codes are used - custom projection name missing - missing Proj4 human readable projection names Best regards, Therion team

1 0

Calculation of LRUD from splays
by Markus Boldt 30 Apr '19

30 Apr '19

Hello, is there a possibility to calculate LRUD-Data from splays? It would be nice, if you have not measured LRUD at the point in the cave, but only splays for drawing. I hope you understand my terrible English J. Greetings Markus

3 3

Re: [Therion] Making projected elevations
by Bruce Mutton 30 Apr '19

30 Apr '19

Hi Tarquin Probably better to create a new post for each topic. Makes for smaller bites and easier to respond to. Basically, there is no conversion of sketches from one projection to another. You have to do the work yourself or accept any distortions that a fudge might incur. Have a search on the mail archive for 'projected elevation'. In essence I think you have come to the right conclusions below. https://www.mail-archive.com/therion@speleo.sk/ Check out https://www.mail-archive.com/therion@speleo.sk/msg06370.html and https://www.mail-archive.com/therion@speleo.sk/msg06368.html I started my Therion life as a projected elevation fan, but now I think extended is the way to go (subject to the proviso that they are way more vexatious for a non-trivial cave). Your description of the cave/mine makes it sound perfect for an extended elevation to me, especially as you already have extended sketches. Multiple projections on the same pdf page can only be achieved using map-image to insert them as images. Or you could post-process with another application (which defeats a key advantage of Therion). You could take your extended sketches and just flag them as projected, accepting that there may be gross distortions. You could forget about the xvi file, and print out a projected centreline (one trip file at a time is my preference), and sketch on that the passage detail, scan it, and import it as a background image in XTherion. Then you trace it with XTherion to produce scraps. Seems odd to take an electronic process, and force a pencil and paper stage to it, but that is my preference if the alternative is to have an xvi with no sketches embedded. Bruce -----Original Message----- From: Therion <therion-bounces(a)speleo.sk> On Behalf Of Tarquin Wilton-Jones via Therion Sent: Thursday, 25 April 2019 09:56 To: therion(a)speleo.sk Cc: Tarquin Wilton-Jones <tarquin.wilton-jones(a)ntlworld.com> Subject: [Therion] Making projected elevations, and using map connectors Hi, Still learning (never stop)... I have looked through the various tutorials, and several examples, but I have not found any information on how to create a projected elevation - all tutorials stop at that point with "TODO: show how to do elevations". The software I am using to survey the caves (DistoX2 + SexyTopo) gives me a plan view and an extended elevation, exported as centreline+xvi. The area I am surveying is mostly linear with passages stacked at various levels above each other. As a result, projected elevation is more useful than extended elevation. I know I have to use "-projection [elevation 265]" on my scraps and maps to make them all work when I try to use: export map -projection [elevation 265] However, I have not been able to find how to get from an extended elevation to a projected elevation. I had hoped for some magic where I just create an extended elevation then ask Therion to warp that extended elevation into a projected elevation, but I have come to the conclusion that I probably have to do this: export map -projection [elevation 265] -output elevation265.xvi Then create a dedicated surveyname_elevation265.th2 file and go over all the survey data and create the required scraps for it, without being able to see the sketches in the XTherion scrap editor. Have I made the right assumption, or is there some clever magic that can happen? Does this mean that in order to create two elevations, one facing 265° and one facing 180°, I actually have to do this all twice, creating each scrap from scratch each time? Imagine I want to have half of the cave on a bearing of 265 and the other half on a bearing of 180 in the same file (because the cave turns a corner half way along) - essentially extending a projected elevation. I could export the data once on a bearing of 265, and once on a bearing of 180, then create appropriate scraps for each half, pretend that the ones on a bearing of 100 are actually on a bearing of 265 by using the -projection options of maps and scraps. But then it would warp them to oblivion when trying to make it fit the centreline. So would I actually have to export two PDFs, one with a map that only covers half of the cave on a bearing of 265, and another that covers the other half of the cave on a bearing of 180, and position the outputs very close together by importing them as images into a third map? (Not as insane as it sounds. It is a mine, with major passages all very linear at different levels, and just one significant passage running at right angles to the other passages.) ... snipped... Tarquin _______________________________________________ Therion mailing list Therion(a)speleo.sk https://mailman.speleo.sk/listinfo/therion

4 6

wiki editing
by Bruce Mutton 26 Apr '19

26 Apr '19

> it would be good to get this somewhere easier to find, such as a wiki page. Having never edited the Therion wiki, what is the convention there - it usually looks like one page per jumble of knowledge someone tries to impart (with a meaningless URL), rather than a single page per topic. Any suggestions for where to create the page to store this information? Instructions are at the top of https://therion.speleo.sk/wiki/doku.php Ladislav will most likely give you access. New users often have the best insights as to how to 'improve' the documentation, so you are ripe for authorship! Alas the wiki is chaotic, I think you have characterised it reasonably. There was a call for interest in rationalising it some years ago. While it would be worthwhile, I fear it would be a very big job, so I kept very quiet! I still have far too many unfinished projects to contemplate such a thing. The search function is quite effective in the wiki, although less effective in the mail archive. My approach is to always try to add to an existing page that is referenced by topic on the wiki home page. Unfortunately sometimes a topic is fragmented across many pages, and in that case I just try not to make the fragmentation worse. And sometimes it is just too hard (or risky) to try to edit 'someone else's page', as there are many somewhat incompatible ways that people can chose to use Therion, so I create a new page, sometimes with a meaningful url. If you have insights into use of projections, then I think the FAQ page would be a good place to start. Somewhere near https://therion.speleo.sk/wiki/faq#projections_plan_elevation_extended_and_… might work. Bruce

1 0

Making projected elevations, and using map connectors
by Tarquin Wilton-Jones 24 Apr '19

24 Apr '19

Hi, Still learning (never stop)... I have looked through the various tutorials, and several examples, but I have not found any information on how to create a projected elevation - all tutorials stop at that point with "TODO: show how to do elevations". The software I am using to survey the caves (DistoX2 + SexyTopo) gives me a plan view and an extended elevation, exported as centreline+xvi. The area I am surveying is mostly linear with passages stacked at various levels above each other. As a result, projected elevation is more useful than extended elevation. I know I have to use "-projection [elevation 265]" on my scraps and maps to make them all work when I try to use: export map -projection [elevation 265] However, I have not been able to find how to get from an extended elevation to a projected elevation. I had hoped for some magic where I just create an extended elevation then ask Therion to warp that extended elevation into a projected elevation, but I have come to the conclusion that I probably have to do this: export map -projection [elevation 265] -output elevation265.xvi Then create a dedicated surveyname_elevation265.th2 file and go over all the survey data and create the required scraps for it, without being able to see the sketches in the XTherion scrap editor. Have I made the right assumption, or is there some clever magic that can happen? Does this mean that in order to create two elevations, one facing 265° and one facing 180°, I actually have to do this all twice, creating each scrap from scratch each time? Imagine I want to have half of the cave on a bearing of 265 and the other half on a bearing of 180 in the same file (because the cave turns a corner half way along) - essentially extending a projected elevation. I could export the data once on a bearing of 265, and once on a bearing of 180, then create appropriate scraps for each half, pretend that the ones on a bearing of 100 are actually on a bearing of 265 by using the -projection options of maps and scraps. But then it would warp them to oblivion when trying to make it fit the centreline. So would I actually have to export two PDFs, one with a map that only covers half of the cave on a bearing of 265, and another that covers the other half of the cave on a bearing of 180, and position the outputs very close together by importing them as images into a third map? (Not as insane as it sounds. It is a mine, with major passages all very linear at different levels, and just one significant passage running at right angles to the other passages.) While I have your attention, I have been using "map [10 0 m] above" to displace certain parts of the cave. I worked out how to use map connector points (just place a connector on whichever scrap will end up moving) to show their displacement. Some parts of the cave get displaced once away from their parent map, then again when their parent map gets displaced by a grandparent map. It seemed to be impossible to show a line from their original location to their new one, so I split them up into pieces, one has the connector to show the line from the parent map, and the other gets its own map which is displaced directly into the final position, with a connector showing the original position. This seems like the best solution to me, but please shout if you know better. I am struggling a bit with this though, since it is not mentioned anywhere in much detail: map intermediateMP movedtwiceMP [-60 0 m] none movedonceMP endmap map finalMP intermediateMP [10 0 m] above notmovedMP endmap ... select finalMP... In this case, it leaves the "above" outline at the original position, not the intermediate position, while the passage is correctly shown at the final position. Meanwhile the map-connector arrow shows the 60 metre move. Have I misunderstood how that is supposed to work? I would have expected an outline at the intermediate position. But it seems that generation of outlines happens on a different step from generation of the connector arrows. Could someone please confirm the order it does these moves and arrow creation in, so I can wrap my head around what the expected outcome will be? Is it this: select finalMP position notmovedMP and intermediateMP in their natural positions. shift intermediateMP 10 metres right, and leave an outline behind. shift movedtwiceMP 60 metres left. if movedonceMP has moved and has any map-connectors, draw the map-connector to show its most recent move (10 metres right). if movedtwiceMP has moved and has any map-connectors, draw the map-connector to show its most recent move (60 metres left). That is to say; it processes the moves starting at the shallow end of the nesting (with the selected map being the shallowest), but it draws the arrows at the final step showing only the deepest move. Thanks for helping me wade through the confusion. Tarquin

1 0

How to get the right count for cave lengths
by Tarquin Wilton-Jones 23 Apr '19

23 Apr '19

Hi, I have nearly completed the total survey for the system I am mapping. In total, there are a series of little caves (actually mines, but I will stick with the word "caves" because it is clearer), a blind surface shaft, and a couple of significantly long caves. In total, these were surveyed over a series of 6 trips. On one of those trips, we surveyed the surface, and any short fragments of passage that we encountered that way. One of those fragments turned out to be one of the major caves. The major cave's survey was subsequently completed on another trip, but its first few metres are included in the surface survey. I am used to Survex. Each of the surveying trips has its own .th file: overall.th ("input"s all the other files) surface1/surface1.th (contains the entrances to several fragments, and the first 2 legs of cave 1) surface2/surface2.th (contains the blind shaft's plumbed depth and some other entrances) cave1/cave1.th (does not contain any entrances, but is a long cave, connected to the "cave 1 legs" in surface1.th cave2/cave2.th (contains the first part of cave2, and its entrance) cave3/cave3.th (contains cave3, with two entrances) cave2ext/cave2ext.th (contains the second part of cave2) Cave1 is connected to cave2. Each entrance is marked using "station 2 Cave1 entrance" in the centreline section of the file where it is defined. Survex only displays aggregate statistics. Therion tries to identify "caves", which is a concept I am not used to. I had hoped that Therion would be smart enough to see that caves are connected to each other, and work out the connected lengths. But it seems that it only works out the length of the files within the same survey. Cave1 doesn't get any length. Cave2 gets only the length from cave2.th - the length of the cave2ext and cave1 are not included. How do I make Therion realise what caves are connected? Do I need to put them into a structure like this? survey overall survey cave1_2 -entrance 2@cave2 -name "Caves 1 and 2" input cave1.th input cave2.th input cave2ext.th endsurvey endsurvey And if so ... how do I tell it that *part* of the cave lies within the surface survey file? Do I need to split the surface survey up into parts, one of which is the entrance to cave1? Separately, when using "statistics topo-length on", it ignores the surface survey legs, which is quite unfair for the person who surveyed 1 km of surface to link all of the entrances - they get no credit at all. Can it be asked to include surface legs in the topo-length calculations for survey credits? Thanks for any advice. Tarquin

3 6

Joining maps with the join command
by Tarquin Wilton-Jones 15 Apr '19

15 Apr '19

Hi, I am currently learning how to use Therion to draw up a detailed survey. My survey is split into several "caves", each of which has its own .th and .th2 file. In the .th file for each cave is a separate "map", so that the cave can be rendered separately. cave1.th: survey cave1 input "cave1 plan.th2" input "cave1 ee.th2" map cave1MP scrap1 scrap2 endmap centreline ... endcentreline endsurvey cave2.th: survey cave2 input "cave2 plan.th2" input "cave2 ee.th2" map cave2MP scrapa scrapb endmap centreline ... endcentreline endsurvey Then I have an overall file which combines the maps called allcaves.th: survey allcaves map allcavesMP cave1MP@cave1 cave2MP@cave2 join ____________ endmap centreline ... endcentreline endsurvey Imagine the two caves join in scrap1 (id "foo":0) and scrapb (id "bar":end), and I want to use a join command to make the scraps join neatly (I have already positioned the passage ends very close to each other). Could you please tell me the syntax needed to make the join command reference the correct points of the correct lines inside the correct scraps inside the correct maps? Every example of the "join" command I could find assumes you were trying to join scraps inside the same map, and did not show how to reference items in a sub-map. As a result, I have not been able to work out how to construct a valid join command for this situation. Many thanks for any information you can provide. Tarquin

5 14

FYI - scrap is too large to process in metapost in this scale - maximal scale for this scrap is
by Bruce Mutton 08 Mar '19

08 Mar '19

Possibly, but probably not, related to the issues with coordinates, that seem to be resolved just now with eddb4c3. I have one thconfig file, (in amongst a large project with many thconfigs that work just fine), with a mysterious scale related error. I suspect this must be of my own making, and not a Therion bug. C:\Program Files (x86)\Therion\therion.exe: error -- scrap RiwakaResurgenceRoughPlan-s1(a)RiwakaResurgence.RiwakaArea.RiwakaSystem defined at ./RiwakaArea/./RiwakaResurgenceCave/RiwakaResurgenceRoughPlan.th2 [9] is too large to process in metapost in this scale -- maximal scale for this scrap is 1 : 210 The scale I am using is 1:5000, which I assume is considered smaller than the 1:210 that is being complained about by Therion. This is a thconfig for a large project that I only tend to run once every year or so, therefore I'm not sure when the problem manifested. I have not figured out why the all component caves compile OK, but the whole system fails. Unless anyone has any brilliant insights I'm not really seeking a solution from the forum just yet. I have yet to find time to explore all the possible mistakes I may have made. I have tried removing the offending scrap from it's parent map, but then another scrap in a completely different cave triggers the same error. All the same, any insight gratefully received. Bruce

1 0

5.4.3 has broken output cs conversions
by Bruce Mutton 08 Mar '19

08 Mar '19

Therion version 5.4.3 and subsequent development versions have broken the functionality whereby coordinates entered with a variety of coordinate systems are converted to a user selected coordinate system for output. The 5.4.2 output attached is from the last installation file I have that gives a correct output (all coordinates start with 159), and the next one, 5.4.3 and all subsequent versions have coordinates some 1000 km apart. It makes it a very long cave, but unfortunately two of the entrances are in the middle of the pacific ocean! The problem is that Therion is assuming that they are all in the chosen output coordinate system, but it is not performing any conversion. No errors are reported (although there are mysterious scale related errors in other datasets that could be as a result of this problem). I am using these coordinate systems for input; cs EPSG:2193 #NZ Transverse Mercator 2000 cs EPSG:27200 #NZ Map Grid 1949 cs lat-long and for output in this case I am using; cs EPSG:2193 #NZ Transverse Mercator 2000 Bruce

2 2