- Therion - speleo.sk

ceiling step in the wrong direction when exported from topodroid
by עמרי גסטר 24 Sep '19

24 Sep '19

Hi, I've noticed that when I export sketches from Topodroid to Therion all of the ceiling step lines are in the wrong direction. it doesn't happen in the other lines... has anyone else had this problem? Omri Gaster

4 6

Limit on scale
by Andrew Atkinson 23 Sep '19

23 Sep '19

I'm working on a survey http://www.cave-registry.org.uk/svn/CheddarCatchment/Bagpit/ As I'm working on it the Head will be changing as often Using the config file in this directory it works at a scale of 1 100 However if I import common_layout.th (which imports another file) from http://www.cave-registry.org.uk/svn/CheddarCatchment/ Then use the common layout in my local layout, I get an error if I try to go to a scale bigger than 1 139 (eg 1 138) The message does not give me any clues, as far as I can fathom, of what is causing the error, and there is lots going on in these files, some very old now, so how do I find the problem? The error message is writing BagpitP.pdf ... ####################### metapost log file ######################## This is MetaPost, version 2.00 (TeX Live 2019/dev/Debian) (kpathsea version 6.3.1/dev) 23 SEP 2019 19:29 **data.mp (/usr/share/texlive/texmf-dist/metapost/base/mpost.mp (/usr/share/texlive/texmf-dist/metapost/base/plain.mp Preloading the plain mem file, version 1.005) ) (./data.mp {randomseed:=42} [4001] [4002] [4003] [4004] [4005] [4006] [4007] [4008] [4009] [4010] [4011] [ 4012] [4013] [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] (./mptextmp.mp) (./mptextmp.mp) (./mptextmp.mp) (./mptextmp.mp) (./mptextmp.mp) (./mptextmp.mp) [22] ! Number is too large (5669.29134). l.6842 s_hgrid(-1, -1, 5669.29134 , 5669.29134); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) ! Number is too large (5669.29134). l.6842 s_hgrid(-1, -1, 5669.29134, 5669.29134 ); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) [23] ! Number is too large (5669.29134). l.6845 s_hgrid(0, -1, 5669.29134 , 5669.29134); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) ! Number is too large (5669.29134). l.6845 s_hgrid(0, -1, 5669.29134, 5669.29134 ); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) [24] ! Number is too large (5669.29134). l.6848 s_hgrid(1, -1, 5669.29134 , 5669.29134); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) ! Number is too large (5669.29134). l.6848 s_hgrid(1, -1, 5669.29134, 5669.29134 ); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) >>>>>>>>>..........and it continues on a similar vein until ); It is at least 4096. Continue and I'll try to cope with that big value; but it might be dangerous. (Set warningcheck:=0 to suppress this message.) [31] ) Here is how much of MetaPost's memory you used: 7706 strings using 154690 characters 4000528 bytes of node memory 1469 symbolic tokens 11i,81n,26p,214b,5f stack positions out of 16i,96n,32p,250b,6f 44 output files written: data.1 .. data.4013 #################### end of metapost log file #################### therion: error -- metapost exit code -- 512 writing xtherion file ... done Any help most appriciated

2 2

Bounding Box to big in Loch but fine in Aven
by Max D 23 Sep '19

23 Sep '19

I have a somewhat big cave (2400 Stations) and since a few weeks Loch shows a huge bounding box of obout 250x7500 km (!) see http://filez.foxel.org/2c4512e8a235 Export is done like this: select m_all export model -output output/windloch.lox export model -format survex -output output/windloch-konstruktion.3d export model -format compass -output output/windloch.plt export model -format dxf -output output/windloch.dxf export model -format kml -output output/windloch-konstruktion.kml survex Data is fine, PLT also (when viewed in Aven) lox and dxf have the huge bounding box kml seems to have only the surface survey and is missing the cave. So far I have not been able to poin down the change that caused it. Any suggestions on how to hunt this error down? Regards --max

4 6

map without scrap, survey or map reported as incompatible map projection
by Bruce Mutton 09 Sep '19

09 Sep '19

I was creating a new map just now, and while I should have realised that it would probably not work in its current form, the error message caused al lot of confusion and initially led me down the wrong track. C:\Program Files .\therion.exe: error -- INDEXGLMESM_System.th [134] -- incompatible map projection -- SwissM_PlanMap@GLMESM_system I started looking through map definitions to find which one was not defined properly as a plan, despite knowing they all must be, as they have worked for years. map GreenlinkAreaPlanMap -title "Greenlink Area<br>Plan view" -projection plan # overview map focusing on surface features preview below SwissM_PlanMap@GLMESM_system preview below DwarfsDoorPlanMap@GLMESM_system preview below MiddleEarthPlanMap@GLMESM_system preview below GreenlinkPlanMap@GLMESM_system preview below BlackSabbathPlanMap@GLMESM_system endmap GreenlinkAreaPlanMap The problem turns out to be that a map definition must contain more than just previews. If I remove 'preview below' from one of the definition lines, all is well. I suggest that the error would be more helpfully be reported by Therion as; "map must contain at least one scrap, survey or map without preview" Bruce

1 0

Extended profile problems
by Bill Gee 08 Sep '19

08 Sep '19

Hello everyone - I have not been putting elevation profiles on my maps for several years because it is such a pain to do in Therion. The time has come where I need to start adding them to several maps in progress. In the past I have defined the profile scraps as type "elevation" and given them a viewpoint angle. The profile I am working on now will not work for that because it basically goes around in a circle. There is no viewpoint angle where the entire profile lays out in a line. The plan view is a loop. So for this one I defined the scrap as type "extended". Holy cow, that makes a mess of things! Take a look at the attached file. This is so distorted it is hard to figure out how it relates to the drawing! The stations in this profile go about 3/4 of the way around the circle. The upper half of the resulting map is upside down and magnified about 5 times larger than it should be. What am I missing??? Do I correctly understand that an "extended" scrap should draw just the way it appears on the original sketch? How should I be drawing Maybe I should completely skip using elevations. I can probably make them work by drawing as cross-sections. Indeed, that might be easier to fit onto the final map. I think the only real problem there is whether cross-section scraps can be joined. -- Bill Gee

4 12

Re: [Therion] Detecting errors
by Tarquin Wilton-Jones 08 Sep '19

08 Sep '19

This is one of the reasons that for legs like that (where the Disto will be parallel to a wall not perpendicular to it during the next shot), we aim the laser not for the station itself, but for the middle of a small block that is a similar size to the Disto, held on the station. The easiest thing to use is the nail varnish bottle which will be used to physically paint semi-permanent stations. It is easier to see from a distance, and it removes angular and distance errors you mention. And the person holding the nail varnish can clearly identify whether the Disto missed the target.For calibration, I get a typical error of around 0.3 or below. All metal objects are removed first: tripods, tackle bags, krabs, belt, Android device, stylus, helmet, light, SRT gear, wedding ring, watch, safety knife, etc.. And avoid fixed aids like bolts or cables, or areas with scaffolding or fences and gates, or reinforced concrete in the cave.I use obvious natural marks on the walls for all points of the calibration, aiming from one to the opposite one, about 3 metres (10 feet ish) apart. Then the opposing measurement in the opposite direction. This is done for all measurements, horizontal, vertical and diagonal.When the cave has natural minerals, avoid those areas during calibration. For our lead mine surveys, we calibrate in a local forest where there are no minerals. null

1 0

Detecting errors
by MD 07 Sep '19

07 Sep '19

Our current project is nearing 2000 Stations in a labyrinth and things start to get cumbersome. We have more than 100 Loops detected by therion. I wonder what people use to find errors. For example im I have too loops L1 and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can assume that the error is in the stations/shots which are part of L2 but not L1. Is there an automated approach for that? When I add a new loop and the overall error goes up it is likely, that this loop is faulty. Any way to automatically check that? I also read the “Error Detection in Compass” page and couldn’t understand much mire than “we just try out”. We have Disto X (no transcription errors possible) and traditional (transcription errors likely) surveys. How to handle that? Any suggestions besides loads of manual work?

10 25

Display Station comments on Map?
by Max D 06 Sep '19

06 Sep '19

Hello, I have Stations like this in a survey: fix wiesenponor 391349.0 5650631.0 154 station wiesenponor "Wiesenponor" sink fix quelleinderagger 391952.0 5650078.0 125 station quelleinderagger "Quelle in der Agger" spring fix aggertalhoehle 391124 5650259 150 station aggertalhoehle "Aggertalhöhle" entrance fix gipfel 391528 5650356 254.3 station gipfel "Gipfel Mühlenberg" Is there a way to display Icons for these (but not for all stations) and the Comments (e.g. "Gipfel Mühlenberg") in the map without creating a scrap and retyping them there? I checked the MetaPost files and found no obvious way to enable that. Regards --max

5 10

Problems with Compass PLT files
by Bill Gee 25 Aug '19

25 Aug '19

Hello everyone - I have been working with the developer of a cave viewing program called "Cave Breakout". The web site is https://breakoutcavesurvey.com/ This is a Java application which, among other things, can import Compass PLT files for viewing and searching. It works well on Linux as long as the display driver supports OpenGL3. I am not a Compass user, so I generate PLT files from Therion using an "export" command, something like this: export model -fmt compass -enable all -wall-source all -o MosbyCave.plt After a few go-arounds, Cave Breakout will now successfully read and display simple PLT files from Therion. However, it appears there are some deeper issues relating to how Therion generates a PLT file. 1) The PLT file that Therion generates, even a simple one like Mosby Cave (only 13 stations and 163 feet) will not open in Compass Viewer. The error message is "Invalid numeric input". 2) Complex PLT files from Therion will open in Cave Breakout, but the display is all messed up. The specific file that shows this contains four caves and has some duplicate station names among the caves. The PLT file from any one of the caves will display correctly, but the combined file is a big mess. One of the issues that Cave Breakout has to deal with is very large numbers. The developer told me that the Therion file had easting numbers in the millions. I don't know if that is normal or not - but apparently Compass does not do that. He did not mention the northing numbers, but I suspect they are also very large. Has anyone here done much work with Compass PLT files? Am I missing something in the export command? -- Bill Gee

1 0

Re: [Therion] Therion 5.4.2. potential bug
by Martin Budaj 31 Jul '19

31 Jul '19

On Sat, Jan 12, 2019 at 10:51 AM Michael <knollesimage(a)t-online.de> wrote: > I have now attached a minimal cave sample produced with 5.4.1. and one > produced with 5.4.2. to demonstrate the displacement. > Hi, the problem is that EPSG:31467 projection uses the "potsdam" datum and the PROJ library used by Therion changed the way how to transform potsdam datum to the standard WGS84 datum – it switched from a simple string parameter (towgs84) to using external grid file (see https://proj4.org/resource_files.html#transformation-grids for examples). No grid files are currently included in the windows Therion distribution, so the transformation is not correct in 5.4.2. Therion needs to be modified to include and use those files – hopefully soon. Best regards Martin

5 8