Re: [Therion] using Survex files in Therion

[Footleg]

I use this for one of my larger projects. This is the data structure I use:

encoding  utf-8
# This file defines the survey data (imported from a Survex 3d file) and
imports
# the master map for the survey. Rendering this file will give a complete
survey
# for the Riano part of the system.

survey Riano

survey 4ValleysCL
import 0105_therion.3d -surveys use -cs EPSG:25830
endsurvey

centreline
#This centreline data block enables team names and dates
#to be incorporated into the map headers, and allows the
#elevation range used to colour the maps by altitude to be
#pinned to specific ranges

cs EPSG:25830

copyright 2018 "Matienzo Caving Expeditions"

#Date ranges for survey trips
date 1974.08.01 #Earliest date (estimated)
date 2018.04.01 #Latest date

#Survey teams
team "Paul_'Footleg' Fretwell"
team "Paul Dold"

explo-date 1974.08.01 #Earliest date (estimated)
explo-date 2018.04.01 #Latest date
explo-team "Joe Caver"

endcentreline

input RianoPlan_SomeDrawing.th2
input RianoPlan_MainUpstream.th2

join Riano_EntranceSP1 Riano_EntranceMazeSP1
join Riano_EntranceSP1 Riano_EntranceInletSP1

map RianoEntranceSeries -title "Riano Entrance Series"
 GreyRiftNorthExtnSP3
break
 Riano_EntranceMazeSP1
 Riano_EntranceSP1
 Riano_EntranceInletSP1
endmap

endsurvey

On Mon, Dec 4, 2023 at 2:13 PM Rodrigo Severo via Therion 
wrote:

> I wonder if Survex 3d files shouldn't be treated in Therion as the "data"
> part of a "centreline". This way, we would be able to set all centreline
> properties for 3d files.
>
>
> Rodrigo
>
>
> On Friday, December 1st, 2023 at 7:37 PM, Rodrigo Severo 
> wrote:
>
> Hi,
>
>
> I am trying to use survex 3d files in Therion. AFAICT, 3d files don't
> include the extra info that a svx file accepts like team, export, etc, only
> the actual centerline.
>
> How can I set, for example, the team responsable for the centerline if I
> am importing a 3d file?
>
>
> Regards,
>
> Rodrigo Severo
>
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Tunnel to therion conversion

[Footleg]

I did this for some of my Matienzo surveys which I originally started
drawing in Tunnel before I moved to Therion when the process of morphing
old drawings onto new data became too time consuming as the project got
larger. The approach I took was to export the drawings from Tunnel as SVG,
then process these in Inkscape and save to Therion format using the Therion
Inkscape plug-in. The main pitfall I found was that the 'click to place
line points' method of drawing splines in Tunnel had led to much denser
points per line than typically is the case when drawing in Therion with the
'click and drag out handles' method with bezier curves. I found I tended to
get many short line fragments from the conversion, and tiny line
fragments overlapping themselves or hidden under other lines. Cleaning
these up was time consuming, and I eventually concluded I would get better
drawings by using bitmaps of my Tunnel drawings as background sketches in
Therion and redrawing them in Therion. Like many big survey projects where
nobody else seems interested in getting involved beyond the actual caving
trips it all proved too much work for me alone and after 10 years my
enthusiasm waned, so much remains to be drawn up still.

Footleg

On Wed, Jun 29, 2022 at 6:10 PM Wookey  wrote:

> Has anyone done any work on the task of converting existing Tunnel
> sketches (xml) to therion .th2 files?
>
> CUCC (Cambridge Loser expeditions: https://expo.survex.com) has a huge
> investment of tunnel drawings (55km of cave?), but because there are
> no elevations for any of this and Tunnel is a bit niche we are
> pondering using therion more.
>
> If a semi-automated conversion of the existing drawings was possible, that
> would help enormously.
>
> It seems like it shouldn't fundamentally be too hard to turn xml
> lines/beziers into therion lines/beziers, and map the line types, but
> there are issues with how to allocate lines to files and how to get
> the scaling right.
>
> I've not done anything at all about it yet, but thought I'd check if
> anyone else had before having a proper look.
>
> Thoughts?
>
> Wookey
> --
> Principal hats:  Debian, Wookware, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Joining surveys at a curved/sloping pitch

[Footleg]

Nice. I had not thought to join all the line points like that. I'll bear
that in mind next time I have a particularly tricky join.

Footleg

On Fri, 10 May 2019 at 14:39, Tarquin Wilton-Jones via Therion <
therion@speleo.sk> wrote:

> On 10/05/2019 14:28, Footleg wrote:
> > If the two scraps are in the same map layer (i.e. not separated by a
> > break line in the map definition) then the upper scrap will completely
> > hide any part of the lower scrap which passes under it. So the lower
> > scrap curved outline of the pit bottom can be quickly drawn a bit larger
> > than the curved line of the pit in the upper scrap, as any overlap will
> > be hidden.
>
>
>
> Sounds convenient, but sadly not possible in my case, as there is a
> break. But my manual process does work. Tested it out. Wish it were more
> convenient, but it works.
>
> 1. text editor, copy pit line from upper scrap in upper survey
> 2. text editor, paste pit line into lower scrap in lower survey
> 3. set -outline out, -visibility off
> 4. in XTherion, open lower survey
> 5. select first line point on the new line (it will be positioned
> somewhere weird), press "shift from"
> 6. select the line point on the wall line where it needs to end up,
> press "shift to"
> 7. select the new line, press "shift object"
> 8. connect walls to it as needed
> 9. in overall .th file, add joins for each line point, and the scrap as
> needed:
>
>   join pitchbottomSP@topsurvey pitchtopSP@bottomsurvey -smooth on
>   join pitchedge@topsurvey:0 pitchlip@bottomsurvey:0
>   join pitchedge@topsurvey:1 pitchlip@bottomsurvey:1
>   join pitchedge@topsurvey:2 pitchlip@bottomsurvey:2
>   join pitchedge@topsurvey:3 pitchlip@bottomsurvey:3
>   join pitchedge@topsurvey:4 pitchlip@bottomsurvey:4
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Joining surveys at a curved/sloping pitch

[Footleg]

If the two scraps are in the same map layer (i.e. not separated by a break
line in the map definition) then the upper scrap will completely hide any
part of the lower scrap which passes under it. So the lower scrap curved
outline of the pit bottom can be quickly drawn a bit larger than the curved
line of the pit in the upper scrap, as any overlap will be hidden.

Footleg

On Fri, 10 May 2019 at 13:51, Tarquin Wilton-Jones via Therion <
therion@speleo.sk> wrote:

> > So if you
> > need to join them to keep them aligned you have to specify the exact
> > line points to join to pin the points at either end of the curved lines
> > to each other in the pair of scraps.
>
>
> Many thanks for that.
>
> I was afraid you would answer something like that though. Laborious
> manual editing it is.
>
> I was wondering if maybe I could manually add the pit line into the
> lower scrap's .th2 file using a text editor. Make it invisible, outline
> out, then use XTherion to move it into position so that it touches the
> lower scrap properly, and then manually join all the linepoints in the
> .th file. That way, the shape of the curve should be perfect, with
> minimal distortion, and not relying on line thickness to hide the
> approximations.
>
> It's a real shame to have to do it like that though. Imagine instead
> that I could create a scrap filling only the gap, in the *upper*
> survey's .th2 file (fairly easy to do). Then imagine I could say:
> fillerscrap@uppersurvey -color lowerscrap@lowersurvey.
>
> (Whether this is done as a lookup, or as a direct command or property
> doesn't really matter, just as long as it is possible.)
>
> This would solve the problem without needing all the manual
> approximations and attempting to copy vectors between surveys.
>
> Feature request?
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Joining surveys at a curved/sloping pitch

[Footleg]

I do this sort of thing a lot. You just need an equivalent line in the
lower (blue) survey with -outline out to extend the blue scrap border to
cover the white hole in your plan. I generally use an invisible wall line
(so does not need '-outline out' option specifying) and make it slightly
larger than the curved pit line so the overlap of the scraps is maintained
even if a bit of distortion is applied due to loop closure corrections. As
long as the scraps are in the same map level (i.e. not separated by a
break) then the upper scrap will hide the overlapping area of the lower
one. You cannot 'join' the scraps automatically now as neither will have an
opening in the outline at the pit now. So if you need to join them to keep
them aligned you have to specify the exact line points to join to pin the
points at either end of the curved lines to each other in the pair of
scraps.

Footleg

On Fri, 10 May 2019 at 12:42, Tarquin Wilton-Jones via Therion <
therion@speleo.sk> wrote:

> Thanks for the reply.
>
> > Adding the option -outline out to the (closed) line of  your pit on the
> > top scrap should create the whole that you want in the blue color so
> > that you will see the green color of the bottom scrap.
>
> See attached for what happens when you do that. I need the blue to fill
> the blank area. Blue and green belong to different surveys, so getting
> them to perfectly match the curve of each other manually is ... hard.
>
> Is there a way to create a scrap within the green survey (where it is
> easy to perfectly follow the same line), but tell it to take it's
> altitude colour from the blue scrap instead?
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Compass (.dat) to Therion (.th) converter?

[Footleg via Therion]

You might also find the Cave Converter tool I wrote of some use. It doesn't
convert to Therion, but it can read Compass.dat and convert to Survex. The
survex files are not too difficult to then convert into Therion in a text
editor:
http://wscc.darkgem.com/caveconverter/

Footleg

On Mon, 7 Jan 2019 at 11:18, Marco Menchise via Therion 
wrote:

> Wow, I didn't know about that page, thanks...
>
> Maybe I missed it because I googled in English and Marco wrote it in
> Italian (quite unusual for him :-) )
>
> Thanks,
> Marco
>
>
> Il giorno lun 7 gen 2019 alle ore 12:09 Tom via Therion 
> ha scritto:
>
>> Hi,
>>
>> in handling compass data I use the procedures described in this wiki
>> page, written by Marco Corvi, which unfortunately I have found it only in
>> italian language.
>> In it is linked also a very nice perl script to convert dat files in
>> therion.
>>
>> Tom
>>
>> Il giorno lun 7 gen 2019, 12:02 Torsten Schnitter via Therion <
>> therion@speleo.sk> ha scritto:
>>
>>> Hi Marco
>>>
>>> I have an excel macro tool which I use for such tasks.
>>>
>>> I have done this for my own and I'm using this Excel tool as my
>>> "database" for survey data.
>>> You can import different formats like compass, walls, therion, mnemo,
>>> pockettopo into Excel.
>>> And you can export to formats for Therion, Walls and Compass.
>>> This tool is still under progress but may be a help for your task.
>>>
>>> Unfortunately you can use it only with Windows and Excel.
>>> Let me know if you are interested.
>>>
>>> cheers,
>>> Torsten
>>>
>>> Marco Menchise via Therion  hat am 7. Januar 2019 um
>>> 11:35 geschrieben:
>>>
>>> Hello,
>>> does anybody know if such a converter is available?
>>>
>>> Thanks,
>>> Marco
>>>
>>> ___
>>> Therion mailing list
>>> Therion@speleo.sk
>>> https://mailman.speleo.sk/listinfo/therion
>>>
>>> ___
>>> Therion mailing list
>>> Therion@speleo.sk
>>> https://mailman.speleo.sk/listinfo/therion
>>>
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
>>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] SDs for distoX surveys

[Footleg via Therion]

In my own experience, the most common blunder which the 'measure 3 times'
method with DistoX2 catches is mis-read distance. The Disto tends to be
used in the same orientation for all 3 shots, so the compass and clino tend
to be well aligned in all 3 (regardless of how well calibrated the DistoX
is, or is there are local magnetic fields throwing the compass). But the
laser does sometimes miss the target and overshoot, resulting in one of the
3 shots being out of tolerance for PocketTopo to count them as a valid leg.
Of course catching blunders so they never make it into the data (we would
reshoot when it happens) is not the same as the SD in the measured data.

The way we catch bad calibration problems or local magnetic interference is
to take backshots (3 of them). This has saved serious errors on multiple
occasions which would not have been detected taking shots in one direction
alone.

Footleg
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Wrong average calculation from compass/backcompass data

[Footleg via Therion]

The correct way to average bearings is to the treat them as vectors, then
average the x and y components separately before converting the resulting
vector back to a bearing. It is likely this is what the trig functions
mentioned in this thread are doing.

Footleg
On Fri, 18 May 2018 at 12:57, Bruce Mutton via Therion <therion@speleo.sk>
wrote:

> I agree to some extent with both sentiments below, however the software
> should not abort just because of backsight discrepancies.
>
> What about adding one more line to the Therion and or Survex log file;
> either
>
> “There are no backsights in the centreline”, or
>
> “Maximum backsight discrepancy is xx [degrees|grads]”, as approprite
>
> That way the user can be fully informed and make their own decision about
> whether to investigate further if the information is not what they expect.
>
> Bruce
>
>
>
> 17. 5. 2018 v 9:25, Evaristo Quiroga via Therion <therion@speleo.sk>:
>
>
>
> In this case is not a problem with my formula, is a serious magnetic
> anomaly (100 degrees difference)  and the program should to stop and to
> send a warning.
>
>
>
> Evaristo,
>
>
>
> Therion is a program to interprete your data, not to solve problems with
> your data.
>
>
>
> It is your responsibility what the data you import into Therion.
>
>
>
> Martin S.
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] How to combine two maps

[Footleg via Therion]

Hi Bill,

I generally put just one .th file in my thconfig file, and that .th file
represents all the caves I want to process with that config. My master .th
file then includes the different .th files for different caves, and also
contains the equates to link them together (where they are joined by survey
data).

Footleg

On Sun, Feb 18, 2018 at 2:27 PM Bill Gee via Therion <therion@speleo.sk>
wrote:

> Hello everyone -
>
>
>
> Well, that turned out to be easy! I was fearing a huge conglomerated mess
> of entries in a thconfig and *.th file. It turned out to be some relatively
> simple mods to thconfig.
>
>
>
> As noted by several people - I put each cave survey in its own directory.
> Each directory contains a master .th file and a thconfig file. For bigger
> projects I create a subdirectory for each survey trip which contains the
> centerline data and all scanned sketches from that trip. It also contains
> the .th2 files.
>
>
>
> One of the centerline data files (usually the first one) contains the GPS
> coordinates of the cave and also specifies the entrance station.
>
>
>
> To create the combined map, I created a new survey directory. It contains
> only a thconfig file. The thconfig file names the three cave surveys like
> this:
>
>
>
> # Name the three input caves
>
> source ../AllieSpringCaveSurvey/AllieSpringCave.th
>
> source ../MillCreekCaveSurvey/MillCreekCave.th
>
> source ../ShiftyRockPit/ShiftyRockPit.th
>
>
>
> The layout sections are exactly the same as in the thconfig files for each
> cave. The TeX code that I have for changing the size of the legend is also
> identical, as is the MetaPost code for drawing my custom symbols.
>
>
>
> At the bottom of the thconfig file I listed the exports. The only thing I
> changed was the export file names. Everything else is the same as in the
> thconfig files for each cave.
>
>
>
> # The main plan map
>
> export map -proj plan -layout mainmapnocolor -o CaveRanch.pdf
>
>
>
> # The main map for printing
>
> export map -proj plan -layout mainmapprint -o CaveRanchPrint.pdf
>
> (continue for kml, lox and 3d files)
>
>
>
> When I ran therion with this thconfig file, it Just Worked! The first
> time! I was astounded. The output files contain all three cave maps and
> they are properly located relative to each other. WooHoo! That was easy!
>
>
>
> The next adventure will happen when the link between two of the caves is
> finally surveyed. The use of an "equate" statement has been mentioned. That
> needs to go in a .th file - right? Which means, in the end, there will be
> four .th files mentioned in the thconfig. Is that right?
>
>
>
> Thanks for all the help and suggestions.
>
> --
>
> Bill Gee
>
>
>
>
>
>
> On Friday, February 16, 2018 10:57:27 PM CST Bruce Mutton via Therion
> wrote:
>
> > Hi Bill
>
> >
>
> > I think you have the answers you need already, but I’ll add my two bits
>
> > anyway.
>
> >
>
> > I do almost the same as Ladislav.
>
> >
>
> > Sounds like your caves are or should be part of one Therion project
> (simply
>
> > because they are in the same general locality). No need to change
> anything
>
> > other than to make sure all of the existing cave folders are collected
>
> > together in a single project folder (as in the image below).
>
> >
>
> > In the example below, my project folder is th_TakakaValley/trunk (the
>
> > /trunk is just an artefact of the version control system we use) and
> there
>
> > are 7 caves.
>
> >
>
> > The other folders are for outputs and standardised layout files.
>
> >
>
> > I use a flat structure these days, ie each individual cave has its own
>
> > folder, with INDEX*.th and thconfig files, which is entirely
> self-contained
>
> > (except for the output and standard files folders) so an individual cave
>
> > can be easily moved to any other folder location and still compile with
>
> > little fuss.
>
> >
>
> >
>
> >
>
> > Below, the INDEXTakakaValley.thc ties together all of the caves in the
>
> > project, and puts them on the same map. If two or more of the caves were
>
> > joined, then I would just create another INDEX file in the top level
>
> > project folder, eg INDEXBaigentsBreweryCaves.thc, and possibly matching
>
> > thconfg and layout files.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > If you download the latest development version of Therion, you can use a
>
> > lookup to specify particular colours for each of the caves, as described
>
> >
> https://therion.speleo.sk/wiki/examples?s[]=lookup#colour_scales_-_lookups
>
> > <
> https://therion.speleo.sk/wiki/examples?s%5b%5d=lookup#colour_scales_-_loo
>
> > kups> (half way down the page).
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Regards
>
> >
>
> > Bruce
>
>
>
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Fwd: Aven in stereoscopic 3D

[Footleg via Therion]

Apologies for cross posting, but I think this is of general interest to
Therion users too. I had not heard of this route to view 3D cave models in
a stereoscopic viewer before. If Loch could export models in a standard 3D
model format including the landscape overlays it would open up 3D viewing
options. E.g. A side-by-side image pair video signal can be viewed in full
colour 3D on many 3D TV sets and projectors. Loch does not provide a side
by side option currently. If it could export models to a format another
viewer can show then it gives a quick route to display models in this sort
of way.

Footleg

-- Forwarded message -
From: Jarvist Moore Frost
Date: Thu, 1 Feb 2018 00:07
Subject: Re: Aven in stereoscopic 3D
To: Pedro Silva Pinto
Cc: sur...@survex.com <sur...@survex.com>


Perhaps easiest is to extract the data & use with a more mainstream viewer.

I had a lot of luck with Pymol (designed for biological molecules /
molecular dynamics), and Thomas Holder's python library for directly
importing .3d data:
https://github.com/jarvist/migovecsurveydata/tree/master/scripts/pymol

Example video:
https://www.youtube.com/watch?v=s68V9EsRvmE

Pymol is open source, but a lot of the web links direct you to the pay
version.

Pymol supports all kinds of weird and wonderful 3D outputs, including
shutter glasses. Mainly I've just used the 'cross eyed' stereo and anaglyph
(coloured 3D specs).

Back in ~2011 I wrote a C program that linked to Survex and exported the
.3d file to a '.CGO' set of graphics primitives. This was a bit more
clunky, but also worked fine.

Best,

Jarv

On 30 January 2018 at 20:50, Pedro Silva Pinto
wrote:

> Hi,
>
> Is there any way I could take advantage of the OpenGL 3D capabilities of
my
> Nvidia Quadro graphics card and see my surveys in Aven in Stereoscopic 3D?
>
> Regards
>
> Pedro
>
>
> --
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Joining scraps and PDF layouts

[Footleg via Therion]

More of a problem at scrap joins where both scraps have water area fills
adjoining is that the hash lines indicating the fill type do not align. I
work around this by drawing the entire water fill area on just one of the
scraps so that it overlaps on top of the adjoining scrap (they must be in
the same 'block' of the map; without a 'break' between them). Turn 'clip
off' for the area fill so it extends outside the scrap border, overlapping
the other scrap and appears as one area fill on the PDF. I often use this
deliberately to hide colour differences at scrap joins where I am colouring
my scrap backgrounds by altitude. The water area fill is always blue in my
layout so it hides the contrast between adjoining scrap colours (circled in
red in attached graphic).

Footleg
[image: ScrapJoinHiddenByWater.png]

On Mon, Aug 14, 2017 at 8:22 PM Martin Sluka via Therion <therion@speleo.sk>
wrote:

> There is one possibility to play with invisible walls and define borders
> of scraps not as straight lines but as puzzle.
>
> In such case one scrap may include all water area.
>
> The problem is with contact of scraps, but if both scraps are on the same
> background image you may copy line from one scrap to another with  plain
> text editor. Coordinates are the same.
>
> m.s.
>
>
>
> 14. 8. 2017 v 19:45, Torsten Schnitter via Therion <therion@speleo.sk>:
>
>
> Hi
> As I was told by a grafic designer problem 1 is just visible on the
> screen/monitor.
> When printing to a plotter there are no white lines anymore.
> I do have the same problem on the screen. But when plotting there are
> really no white lines anymore.
> Cheers,
> Torsten
>
> Am 14.08.2017 um 19:04 schrieb Henry Bennett via Therion <
> therion@speleo.sk>:
>
> Problem 2 can be addressed by working with some custom Tex.
>
> Take a look at this
> https://github.com/speleo/SpeleoPhilippines/blob/master/CodeLibrary/_layouts.tex
>
> You’ll then need to inject the code into your thconfig file using the
> “input” command.
>
>
> https://github.com/speleo/SpeleoPhilippines/blob/master/Region-2/Baggao/thconfig-BlueWater-System
>
> or you could just cut and paste it in.
>
> Hope this helps.  Should at least get you in the right direction.
>
> Problem 1 has been discussed before and I agree, it is a pain.
>
> Henry
>
>
> *From:* Therion [mailto:therion-boun...@speleo.sk
> <therion-boun...@speleo.sk>] *On Behalf Of *Steven Tucker via Therion
> *Sent:* 14 August 2017 17:29
> *To:* therion@speleo.sk
> *Cc:* Steven Tucker <sjtucker...@gmail.com>
> *Subject:* [Therion] Joining scraps and PDF layouts
>
>
> Hello,
>
> I am busy completing a survey of a cave and I am running into two problems
> with the final PDF
> First problem.
> There are water areas that cross over two scraps and the water is coloured
> blue. In the PDF file, the line where the two scraps join show a thin white
> line. The kml and loch files don't show any split between the joint scraps.
>
>
> Any idea how to fix this?
> Second problem.
>
> I would like to display the cave name, scalebar etc in one area of the PDF
> and have my legend in a seperate area of the PDF, but I can't figure out
> how to do this.
>
> Any help will be much appreciated!
>
> Thanks in advance,
> Steven
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] mud!

[Footleg via Therion]

I designed a UK symbol set for just this purpose. You can pull a copy from
the British Caving Association registry where I (and many other UK cavers)
publish and share our data. See the gb_layout.thc file in the Wookey
Catchment repo:

http://www.cave-registry.org.uk/svn/WookeyCatchment/

My project in that catchment is Swildons. So if you want to see how I
include it in a Therion project just download the data set and process the
thconfig-swildons_ent Therion project file in the Swildons folder.

Footleg

On Mon, Aug 14, 2017 at 11:36 PM Wookey via Therion <therion@speleo.sk>
wrote:

> On 2017-08-14 11:51 -0700, Rob Countess via Therion wrote:
>
> > It would seem like a break in tradition to use a different symbol for
> mud. I've
> > been surveying caves for 20 years with this symbol. As far as I
> understood, we
> > were using British mapping symbols because of the large number of British
> > cavers like Mike Boon and Tich Morris, and others who came over because
> of
> > Derek Ford at McMaster University. I used to have a huge list of symbols
> with
> > this mud symbol included, I can't find anything to back this up several
> pages
> > deep on google. You will notice that the UIS calcite symbol is exactly
> the mud
> > symbol in Canada whereas our calcite symbol is connected scallops. Not
> sure if
> > this is based of some now defunct british symbols set.
>
> You don't have to draw your caves with the UIS sysmbol set. You can
> choose a different symbol-set if you prefer. As you say, the lack of a
> 'mud' sysmbol is a bit difficult for cavers of a UK mindset, but the
> UIS logic in just defining sediments by particle size does make some
> sense.
>
> Therion is quite happy for you to specify any sysmbol set you like, or
> to add a few extra sysmbols. (Most UK surveyors can't really get by
> without the 'slope arrow' symbol for example)
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

[Therion] Line Colours in Map Editor with 5.4.1

[Footleg via Therion]

Having finally got around to updating my install to 5.4.1 I was trying to
work out how the line colours had appeared in the official builds (I'm on
Windows). I see the ini file entries in both xtherion.ini and
xtherion.new.ini, all commented out in both files. So I am assuming the
colours are set by some hard coded defaults unless over ridden in the ini
file?

Why are there two ini files? Are they both used by the application?

When this feature was first provided (via the email list) for testing, I
commented that some of the default colours were not ideal from my
experience. In particular the use of 'brown' for unselected walls in the
active scrap is not so easy to tell from the red selected item. As users
are already accustomed to the blue wall lines in the active scrap, I
changed this one to blue.

Rock borders look the same colour as survey legs and splays in background
sketches brought in from PocketTopo, so I changed these to purple. So the
only two changes I have to add into my ini file are:

set xth(gui,me,wallcolor) blue
set xth(gui,me,rockcolor) purple

The blue walls work well with the blue controlfill because the control
points only appear on selected lines, where the line is turned red. So this
is not confused with blue wall lines which are not selected.

I would like to propose these colours be made the defaults as I think it
makes the editor easier to use, and I would like to reflect the default
colours in the screenshots in my tutorial documents when I update them to
reflect the latest release.

Footleg
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion] Therion 5.4.1 Windows Installer incomplete installs

[Footleg via Therion]

I have yet to meet a Therion user who knows another Therion user who they
share a computer with. So I would be happy with install for Current user
only.

Footleg

On Mon, Jul 17, 2017 at 1:15 PM Владимир Георгиев via Therion <
therion@speleo.sk> wrote:

> Yes, the location is flexible. I think it was that way in the old
> installer too.
> But there are also global Start menu shortcuts and registry entries that
> go into HKEY_LOCAL_MACHINE. For those the installer needs admin rights. If
> it doesn't have them, it comes down again to the All users vs Current user
> problem.
>
> Vlad
>
> On Mon, Jul 17, 2017 at 3:08 PM, Footleg via Therion <therion@speleo.sk>
> wrote:
>
>> Usually a Windows application installer offers the option to install to a
>> location of the users choosing. If this was done then users wanting to
>> install without admin privileges could choose a location they have write
>> permissions for. Otherwise users can choose to just click through 'Next' on
>> each page to accept the default install under Program Files.
>>
>> Footleg
>>
>> On Mon, Jul 17, 2017 at 9:28 AM Bruce Mutton via Therion <
>> therion@speleo.sk> wrote:
>>
>>> It is outside of my area of expertise, however:
>>>
>>>- No 1 seems dangerous, at the whim of future MS updates and there
>>>are bound to be people with non-standard setups, or very old Windows
>>>versions, any of which might break something that tries to be too clever.
>>>- No 2 is OK by me.
>>>
>>> I don’t think I would use a ‘non-installed’ version.  The installer is
>>> compact, quick, easy and has proved versatile and reliable over at least 10
>>> years.  I rely on file associations heavily, to tweak my system to make
>>> Therion workflow ‘comfortable’.
>>>
>>> Bruce
>>>
>>>
>>>
>>> *From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *
>>>  via Therion
>>> *Sent:* Monday, 17 July 2017 7:55 PM
>>>
>>>
>>> *To:* List for Therion users <therion@speleo.sk>
>>>
>>> *Cc:* Владимир Георгиев <vld.georg...@gmail.com>
>>> *Subject:* Re: [Therion] Therion] Therion 5.4.1 Windows Installer
>>> incomplete installs
>>>
>>>
>>>
>>> About the installer problems...
>>>
>>> Since I did the installer changes, here is that comes to mind:
>>> 1) I could try to make it more intelligent and to detect if there is an
>>> existing install location (all users or current user) and to install in the
>>> same one without the "All/Current user" prompt. This will probably not
>>> prevent all possible problems though.
>>>
>>> 2) Another solution would be to revert those changes and keep only the
>>> "All users" option, which requires admin privileges. This is how the older
>>> installers worked and always installed in Program Files.
>>>
>>> In addition to that, there could be a portable edition of Therion, which
>>> is distributed as a ZIP file and the user would only need to extract it in
>>> a folder. There would be no association to the TH, TH2 and THCONFIG file
>>> extensions of course. Currently the code reads the install location from
>>> the Win registry, but it could be made to search for files in the current
>>> folder.
>>>
>>> Does anyone have an opinion on what would be most useful?
>>>
>>> Would you use the portable option, or the "Current user" installer?
>>>
>>> Vladimir
>>> ___
>>> Therion mailing list
>>> Therion@speleo.sk
>>> https://mailman.speleo.sk/listinfo/therion
>>>
>>
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
>>
>>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion] Therion 5.4.1 Windows Installer incomplete installs

[Footleg via Therion]

Usually a Windows application installer offers the option to install to a
location of the users choosing. If this was done then users wanting to
install without admin privileges could choose a location they have write
permissions for. Otherwise users can choose to just click through 'Next' on
each page to accept the default install under Program Files.

Footleg

On Mon, Jul 17, 2017 at 9:28 AM Bruce Mutton via Therion <therion@speleo.sk>
wrote:

> It is outside of my area of expertise, however:
>
>- No 1 seems dangerous, at the whim of future MS updates and there are
>bound to be people with non-standard setups, or very old Windows versions,
>any of which might break something that tries to be too clever.
>- No 2 is OK by me.
>
> I don’t think I would use a ‘non-installed’ version.  The installer is
> compact, quick, easy and has proved versatile and reliable over at least 10
> years.  I rely on file associations heavily, to tweak my system to make
> Therion workflow ‘comfortable’.
>
> Bruce
>
>
>
> *From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *
>  via Therion
> *Sent:* Monday, 17 July 2017 7:55 PM
>
>
> *To:* List for Therion users <therion@speleo.sk>
>
> *Cc:* Владимир Георгиев <vld.georg...@gmail.com>
> *Subject:* Re: [Therion] Therion] Therion 5.4.1 Windows Installer
> incomplete installs
>
>
>
> About the installer problems...
>
> Since I did the installer changes, here is that comes to mind:
> 1) I could try to make it more intelligent and to detect if there is an
> existing install location (all users or current user) and to install in the
> same one without the "All/Current user" prompt. This will probably not
> prevent all possible problems though.
>
> 2) Another solution would be to revert those changes and keep only the
> "All users" option, which requires admin privileges. This is how the older
> installers worked and always installed in Program Files.
>
> In addition to that, there could be a portable edition of Therion, which
> is distributed as a ZIP file and the user would only need to extract it in
> a folder. There would be no association to the TH, TH2 and THCONFIG file
> extensions of course. Currently the code reads the install location from
> the Win registry, but it could be made to search for files in the current
> folder.
>
> Does anyone have an opinion on what would be most useful?
>
> Would you use the portable option, or the "Current user" installer?
>
> Vladimir
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Therion Theory - scrap and map definitions

[Footleg via Therion]

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> 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` 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` file in which I connect the` 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   # index file with equates
> +-- trip1.th
> +-- trip2.th
> +-- trip3.th
> +-- trip4.th
> +-- model
> +-- thconfig
> +-- map
> +-- p # plan
> +-- subsystem1
> +-- 1.th2
> +-- 2.th2
> +-- maps.th
> +-- thconfig
> +-- subsystem2
> +-- 3.th2
> +-- maps.th
> +-- thconfig
> +-- 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 Urbansk

Re: [Therion] Question/Problem with customizing text labels

[Footleg via Therion]

An alternative to setting smaller text size codes to 0 (to hide xs labels)
is to put the labels in a different scrap to the drawing. I have done this
with some success where I wanted more detailed text in large scale maps. I
still draw it all in the editor on one th2 file, but just move the labels
into a separate scrap. Then I can decide when I define my maps which ones
to include the labels in. This works well where some maps use offsets too,
as I can include labels in the white space per map depending on where the
white space on the survey appears based on different use of offsets on each
map.

Footleg

On Mon, May 15, 2017 at 6:04 PM Владимир Георгиев via Therion <
therion@speleo.sk> wrote:

> There is also a "min-symbol-scale" option in layout, which hides smaller
> symbols. It might work similar to what you are doing in the font_setup
> metapost.
> You can hide the smallest items, not the largest ones, but hiding the
> larger ones is not that useful anyway.
>
>
> On Mon, May 15, 2017 at 7:13 PM, Henry.Bennett--- via Therion <
> therion@speleo.sk> wrote:
>
>> Hi Vladimir,
>>
>>
>>
>> “-scale” sounds interesting.  One of the things I like about s,m,l,xl,
>> etc was the ability in metapost to set xs to zero (0).
>>
>>
>>
>> Consider a system where you have a full size survey of a single cave.  I
>> can draw that cave with full detail using xs set to a x font size. When
>> that cave intercepts the cave master I can simply draw the system by
>> suppressing some of the detail by using
>>
>>
>>
>>   code metapost
>>
>> #change the size of the default fonts
>>
>>
>> #fonts_setup();
>>
>> fonts_setup(0,18,40,64,80);
>>
>>   endcode
>>
>>
>>
>> I will take a look at –scale and see how that works in such a case.
>>
>>
>>
>> Regards,
>>
>>
>>
>> *Henry Bennett*
>>
>> Solutions Consultant
>>
>> *Dell* *EMC* | Public Sector
>>
>> henry.benn...@dell.com  +44 7717 157 193 <+44%207717%20157193>
>>
>> http://uk.linkedin.com/in/bennetthenry/
>>
>> Planned absence: *19-23 June*
>>
>>
>>
>> *From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *
>>  via Therion
>> *Sent:* 15 May 2017 16:34
>> *To:* Bennett, Henry <henry_benn...@dell.com>
>> *Cc:* Владимир Георгиев <vld.georg...@gmail.com>; TherionList <
>> therion@speleo.sk>
>> *Subject:* Re: [Therion] Question/Problem with customizing text labels
>>
>>
>>
>> Henry
>>
>> After a talk with Stacho, he thought that it would be better not to
>> increase the list of sizes. They are restrictive, in a sense that you have
>> a limited set and can not use anything larger or smaller or in-between
>> sizes.
>>
>> There was a "scale" option that already existed, but was not enabled, so
>> he enabled it.
>>
>> For point and line items you can use this option:
>>
>> "-scale ", where  is the scale factor. The normal size
>> corresponds to 1.0, but you can use any value >0.
>>
>> Vladimir
>>
>>
>>
>> On Mon, May 15, 2017 at 3:48 PM, <henry.benn...@dell.com> wrote:
>>
>> Hi,  I see that more text size options didn’t make it into the 5.4.1
>> release.
>>
>>
>>
>> Would be great to see it in a future release.
>>
>>
>>
>> Thanks, Henry
>>
>>
>>
>>
>>
>> *From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *
>>  via Therion
>> *Sent:* 13 December 2016 15:13
>> *To:* List for Therion users <therion@speleo.sk>
>> *Cc:* Владимир Георгиев <vld.georg...@gmail.com>
>> *Subject:* Re: [Therion] Question/Problem with customizing text labels
>>
>>
>>
>> Torsten
>>
>> I can't confirm or test the issue, but if the -xl size is too small, you
>> can check out the beta version here
>> https://github.com/vldgeorgiev/therion/wiki
>>
>> A few weeks ago I added three more large symbol sizes. E.g. 2XL, 3XL and
>> 4XL. They might work in your case.
>>
>>
>> If I have time next week I will see about the frame size and why it is
>> drawn smaller.
>>
>> Vladimir
>>
>>
>>
>> Dell Corporation Limited is registered in England and Wales. Company
>> Registration Number: 2081369
>> Registered address: Dell House, The Boulevard, Cain Road, Bracknell,
>> Berkshire, RG12 1LF, UK.
>> Company details for other Dell UK entities can be found on
>> www.dell.co.uk.
>>
>>
>>
>> Dell Corporation Limited is registered in England and Wales. Company
>> Registration Number: 2081369
>> Registered address: Dell House, The Boulevard, Cain Road, Bracknell,
>> Berkshire, RG12 1LF, UK.
>> Company details for other Dell UK entities can be found on
>> www.dell.co.uk.
>>
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
>>
>>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Loch giving strange artifacts

[Footleg via Therion]

Possibly your walls are inside out. Do the walls appear and vanish as you
rotate the model? That is a sure sign some of your scrap boundaries are not
right. Common causes are the insides of loops not flagged as outline in, or
walls which cross other walls.

Footleg

On Fri, Mar 24, 2017 at 3:34 PM Benedikt Hallinger via Therion <
therion@speleo.sk> wrote:

> Hello,
> in my loch model i get some strange artefacts.
>
> It seems that the further-away objects are rendered in front of the
> nearer-in-front objects.
> I would expect that the passages far away would be covered by those in the
> front of the camera (as is the case where i did not yet have scraps and
> only
> the centerline is present... look at the screenshot)
>
> What am i doing wrong?___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Projected Elevation Reprojection

[Footleg via Therion]

Thank you Bruce and Martin for the replies and links to further reading.
These were really helpful.

Martin, I am not sure what -flip right, left in centreline is about. I
cannot find any reference to using flip in centrelines in the Therion book.
But the -flip horizontal scrap option which both of you pointed me to did
the trick.

In summary, I draw my scrap using the extended elevation sketch from
PocketTopo (which was for a passage heading downslope almost due West). I
set that scrap type to 'elevation [000]' which represents a 'West to East'
slice through the cave model, but also add the '-flip horizontal' into the
scrap options. This turns my scrap which was drawn using a sketch
representing more or less along the elevation [180] view into a scrap
projected onto elevation [000] with minimal distortion. The Rendering looks
good.

So this is a nice easy technique for easy linear passages along the same
approximate bearing as the elevation view you want to present, and allows
you to directly use the extended elevation sketch from PocketTopo as the
background (so you get the features like auto numbering of survey stations
in the sketch editor).

For passages not conveniently all aligned with the plane of the elevation
slice I will have to distort the drawings in the X dimension only to match
the approximate station spacing in the projection, then load these as PNG
background sketches and place the stations by hand. I'll report back on how
I get on.

Footleg
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] xtherion: "Edit line" contextual menu for line points doesn't work

[Footleg via Therion]

Same as Bruce (but on Windows 7). Edit line context menu items work for me
(e.g. Convert to Curve when clicking on a line makes all the nodes smooth
curves).

Footleg

On Fri, Feb 24, 2017 at 5:22 AM Bruce Mutton via Therion <therion@speleo.sk>
wrote:

> I cannot duplicate this problem.
>
> At least Insert, Delete and Split line work just fine from the right-click
> context menu.
>
> Using 5.3.16 Vlad’s version.
>
> Windows 10
>
>
>
> Bruce
>
>
>
> *From:* Therion [mailto:therion-boun...@speleo.sk] *On Behalf Of *Rodrigo
> Severo via Therion
> *Sent:* Friday, 24 February 2017 3:27 PM
> *To:* List for Therion users <therion@speleo.sk>
> *Cc:* Rodrigo Severo <rodr...@fabricadeideias.com>
> *Subject:* Re: [Therion] xtherion: "Edit line" contextual menu for line
> points doesn't work
>
>
>
> 2017-02-23 22:56 GMT-03:00 Bill Gee via Therion <therion@speleo.sk>:
>
> I am unable to duplicate this problem. Therion version 5.3.16 compiled
> from source, running on 64-bit Fedora 25.
>
>
>
> Just to understand, all options of the "Edit line" contextual menu for a
> line point worked just the same as if you called these same options from
> the button menu on the right panel?
>
>- Insert point
>- Delete point
>- Split line
>- Trace line
>- Convert to curve
>- Simplify
>
> Is that it?
>
>
>
> Rodrigo
>
>
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] Stations coordinates

[Footleg via Therion]

For converting Compass survey data files into metric, you can use my Cave
Converter program.

http://wscc.darkgem.com/caveconverter/

You can read Compass data into the program, and export it as Survex format.
>From this it is straight forward to copy and paste the data sections into
Therion files. I am working on adding direct Therion export (and import)
next.

Footleg

On Wed, Dec 21, 2016 at 2:50 PM Martin Sluka via Therion <therion@speleo.sk>
wrote:

> Anyway, you may use Survex and .3d file exported from Therion:
>
> 3dtopos - name of utulity
>
> 3dtopos — produce a .pos file from a .3d file
>
> Synopsis
>
> 3dtopos [options] {.3d file} [.pos file]
>
> Description
>
> 3dtopos takes a .3d file and produces a .pos file which contains a list of
> all the stations with coordinates (ordered x,y,z [East, North, Up]) and
> complete names.
>
> The stations are sorted such that numbers occur in the correct order (so
> “2” before “10”). 3dtopos even sorts numbers with a prefix and/or suffix,
> so you’d get:
>
>  040.sv8
>  040.sv8a
>  040.sv8b
>  040.sv8c
>  040.sv9
>  040.sv10
>  040.sv11
>  40_entrance_tag
>  40b_entrance_tag
>
> Survex 1.2.30 Manual
>
> 11
>
> You can also export .pos files from aven in versions 1.2.19 and later.
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
>
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

Re: [Therion] UISv1 grades: made a file, please give feedback

[Footleg]

This looks potentially very useful, but I have not yet explored defining sd
settings in my survey data. So I may need to learn a bit more in order to
use it.

I spotted one potential error? In the grade 6 section, the compass bearing
is to 0.125 degrees. But the clino is stated as 1.125 degrees. I think both
should be 0.125 right?

Footleg

On Mon, Nov 7, 2016 at 10:17 PM Benedikt Hallinger <b...@hallinger.org>
wrote:

> Hello,
>
> for a recent project i made a grades file (based on the BCRE-example in
> therion distribution) for UISv1 specifications (see attachment).
> It would be a pleasure for me if it is useful to somebody; it would also be
> very nice if i could get some feedback on it.
>
>
> With the naming i had the intention that exporting from databases is easily
> doable. The prefix is "UISv1_" followed by the actual grades number.
> I included all the grades to faciliate documentation inside the th-files,
> so
> one can stright export "-1" surveys too.
>
>
> With best regards,
> Benedikt Hallinger
>
>
>
>
> For better archiving and searchability, here is the code reproduced:
>  UISv1Grades.th -
> encoding utf-8
> # UIS Grades - International standard grades specification
> #   from: http://www.uisic.uis-speleo.org/UISmappingGrades.pdf
> # Version 2 from 14 Sep 2012 (cosmetic update; UISv1 values still apply)
> #
> # Note: UIS standards says nothing about accuracy of the stations
> #   positions, so it is probably good practice to include a
> #   "sd position  " definition in your centrelines.
> #
>
> # Grade -1: no map available
> # Only for database purposes: It means that the cave map has not been drawn
> yet.
> grade "UISv1_-1" -title "UISv1 ungraded survey without map"
># Not applicaple for therion data.
># It is mainly here to support automated data exports from
># databases wich may export such a number.
> endgrade
>
>
> # Grade 0: ungraded
> # Only for database purposes. If a cave survey is ungraded, its quality
> cannot be
> # assessed. This is most usually true for historic or otherwise old maps.
> grade "UISv1_0" -title "UISv1 ungraded survey"
># Nothing defined here.
># Specifying such an grade may be useful to document that the survey was
># not graded. As it is documented in the *.th-datafiles it may easily be
># searched for. Use it as a kind of "todo" flag...
> endgrade
>
>
> # Grade 1: sketch from memory, not to scale
> grade "UISv1_1" -title "UISv1 survey grade 1"
># nothing defined here.
># Specifying such an grade may be useful to document that the survey was
># just the result of a sketch and shpuld be redone.
> endgrade
>
>
> # Grade 2: No instruments, from annotations/sketches/estimates
> # Map compiled from annotations, sketches and estimates made
> # in the cave. No instruments used.
> grade "UISv1_2" -title "UISv1 survey grade 2"
># nothing defined here.
># Specifying such an grade may be useful to document that the survey
># was the result of sketches/annotations in the cave.
> endgrade
>
>
> # Grade 3: Rough magnetic/analogue survey
> # Directions measured by compass, distances measured by chord,
> # pace, or body dimensions. Significant slopes estimated.
> #
> # A Silva clinometer or comparable, relatively simple means without precise
> # readings qualify for grade 3. Mapping from head to head of the surveyors
> # qualifies only for grade 3. Topofil measurements qualify generally for
> # grade 3 or 4.
> grade "UISv1_3" -title "UISv1 survey grade 3"
>
># 95.44% of readings are within 0.5m (2 S.D.)
>length 0.25 metres
>
># 95.44% of readings are within 5.0 degrees (2 S.D.)
>bearing 2.50 degrees
>
># 95.44% of readings are within 30.0 degrees (2 S.D.)
># (estimating is allowed, no measurement needed - value guessed by me)
>gradient 15.0 degrees
>
># UIS specifications say nothing about station position accuracy.
># Add "sd position  " to your centreline.
>
> endgrade
>
>
> # Grade 4: Magnetic survey
> # Compass and tape survey, using deliberately chosen and fixed
> # stations. Slopes measured by clinometer or horizontal and vertical
> # components of line.
> #
> # Topofil measurements may qualify for grade 4 if the survey shots are not
> too
> # long and care is given to correctly read all data. Laser rangefinder can
> be
> # used throughout grades 4 to 5. In order to attain grade 4, fixed and
> # re-findable survey stations must be made. They have not to be necessarily

[Therion] Map to Data

[Footleg]

Or you could convert the Compass DAT file back to metric using my Cave
Converter utility which reads Compass format now.

http://wscc.darkgem.com/caveconverter/

Footleg

On Tue, Jul 19, 2016 at 11:12 AM Graham Mullan 
wrote:

> Bruce wrote:
>
> "Also notice you have added a link to an executable for converting maps to
> data.
>
> Is there a page or some information about what it is and how it works?
>
> Some might be nervous about downloading an executable directly without any
> explanation about what it is and how it works (in case it is malware)"
>
> Bruce
>
> That program is part of Larry Fish's "Compass" suite. It is perfectly safe
> to use. The one thing to remember is that its output is a Compass data file
> which means that whatever you think you did when using it, it will
> automatically convert all lengths to decimal feet. This is not an issue
> just as long as you remember it. I've used it a number of times, but only
> on small caves or mines, so I've had little problem editing the output into
> a therion or survex file by hand - and remembering to add the line "tape
> units feet" to it.
>
> Graham
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160719/f6604203/attachment.html>

[Therion] Really bad idea?

[Footleg]

I generate my maps using the colour by altitude (in the plans). I just
break my scraps wherever the altitude of the stations changes significantly
for the cave I am drawing. I pin the min and max altitude used for the
colour scale using invisible dummy stations fixed as specific altitudes, so
the colours do not keep changing as I draw more scraps. I try hard to hide
my scrap borders with pitch or floor step lines, Or under water area fills.
I've attached an example.

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160628/9ec1594a/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: ScrapJoins.png
Type: image/png
Size: 181713 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160628/9ec1594a/attachment.png>

[Therion] Therion iMac El Capitan jpeg

[Footleg]

I have seen bitmaps always rendered in one grey shade in the Loch viewer
(on Windows) when used as landscape overlays. It was a graphics card driver
issue in that case. So it is possible you are seeing a related issue on the
map editor. I found that if I viewed the same Loch model on a different
laptop (or in a virtual machine running on the same laptop) then it
rendered fine. But using the native OS on the laptop directly (I think it
was an ATI graphics chipset) just rendered a plain grey overlap.

Footleg

On Tue, May 31, 2016 at 9:05 AM Martin Sluka  wrote:

> It is very strange. GIMP should 100% correct soft.
>
> May you try to convert your image by ImageMagick from command line?
>
> BTW, what is the size and resolution of your image?
>
> m.s.
>
>
>
>
> 31. 5. 2016 v 9:00, Völkl Gernot :
>
> I tryed to set a better contrast and i use Gimp 2.8 to change the settings.
>
> I also export .png with gimp. It also doesn’t work.
>
> I will try to export .gif
>
> lg
>
>
>
>
> Gernot Völkl
> Assistent der Geschäftsführung
>
> 
> RMVG Restmüllverwertung
> Erzberg 3
> 8790 Eisenerz
> Austria
> *tel * +43 3848 5700
> *fax *+43 5700 - 20
> *mobile *+43 664 963 32 07
> *email *G.Voelkl at rmvg.at
> *www.asamer.at* <http://www.asamer.at/>
>
>
> This message is confidential. It may not be disclosed to, or used by,
> anyone other than the addressee. If you receive this message by mistake,
> please advise the sender.
>
> *Von:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk
> ] *Im Auftrag von *Martin Sluka
> *Gesendet:* Dienstag, 31. Mai 2016 08:57
>
>
> *An:* List for Therion users
> *Betreff:* Re: [Therion] Therion iMac El Capitan jpeg
>
>
> Some softwares save JPG with strange headers which are not 100% correct.
> So some other softwares, not only Therion, could have problems with them.
>
> May you write which soft you used to generate that jpg?
>
> m.s.
>
>
>
> 31. 5. 2016 v 8:50, Völkl Gernot :
>
> Hy!
>
> I don’t know what you meen! I use the aktuell Version of Therion and the
> new version of Mac OS X.
>
> I have the therion file fo1.th in the editor and want to paste the
> picture in the Background put i can’t open it. The Picture ist grey. I
> checked the roots option but there are ok. I am write able..
>
> lg
>
>
>
>
> Gernot Völkl
> Assistent der Geschäftsführung
>
> 
> RMVG Restmüllverwertung
> Erzberg 3
> 8790 Eisenerz
> Austria
> *tel * +43 3848 5700
> *fax* +43 5700 - 20
> *mobile* +43 664 963 32 07
> *email* G.Voelkl at rmvg.at
> *www.asamer.at* <http://www.asamer.at/>
>
> This message is confidential. It may not be disclosed to, or used by,
> anyone other than the addressee. If you receive this message by mistake,
> please advise the sender.
>
> *Von:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk
> ] *Im Auftrag von *Martin Sluka
> *Gesendet:* Dienstag, 31. Mai 2016 08:42
> *An:* List for Therion users
> *Betreff:* Re: [Therion] Therion iMac El Capitan jpeg
>
>
>
> 31. 5. 2016 v 8:14, Völkl Gernot :
>
> I have tryed png. But it is the same problem.  On windows it works!
>
> Do you have an other idea?
>
>
>
> Have you chance to save it as "friendly for windows“? Which software did
> you use?
>
> m.s.
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160531/b8359b67/attachment.html>

[Therion] Recovering data marked as sent from DistoX2

[Footleg]

Hi Andrew,

After all those courses we ran where I always teach people to save the
PocketTopo files onto a memory card rather than the PDA internal memory so
that it can be recovered in the event of a a broken PDA! Worth checking the
memory card anyway (including with a file recover utility) because
PocketTopo saves temporary backup files to any memory cards in the PDA
during use. I think these get cleaned up when you save the project, but a
recovery utility may find the files still there.

Footleg

On Wed, Mar 23, 2016 at 12:04 PM Andrew Atkinson 
wrote:

> Yep, I could not find it, only how to mark data that had not been sent as
> sent
>
> Andrew
> On 23 Mar 2016 11:42 a.m., "Martin Sluka"  wrote:
>
>> Have you checked Beat's page?
>>
>> m.
>>
>> On Mar 23, 2016, at 12:25 PM, Andrew Atkinson 
>> wrote:
>>
>> Hello
>>
>> Not strictly Therion, but..
>>
>> Somewhere I think I have read about how to get data from a DistoX2 once
>> it has been marked as sent it is still in the memory. (My pelicase broke
>> on the way out of the cave and the pda was flooded, luckily the Distox2
>> survived) So I can see the data in the DistoX, so I can just type it in
>> manually, but it would be better to get it off electronically, then all
>> I have lost is the diagrams, which where not much, it is a grim bit of
>> cave to survey.
>>
>> Anyway if anyone knows how to get the data to be resent, I would be most
>> data, my web searching skills do not seem to be coming up with an answer
>>
>> thanks
>>
>> Andrew
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>
>> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160323/ceaddde3/attachment.html>

[Therion] Therion Tutorial Update - Data Structures and Layouts

[Footleg]

Thanks Bruce, I didn't know that. Last time I tried I was trying to
generate two different plan PDFs from one thconfig file, and found I got
the same PDF output. But I had not realised that multiple maps were being
included in that output.

What I had tried to do was combine several outputs into one file by doing
something like this:

select 
export 
select 
export 

As I understand this now, this still would not work as I intended. But it
would generate two PDFs both containing both map1 and map2 right?

Footleg

On Tue, Mar 22, 2016 at 6:47 AM Bruce  wrote:

> Footleg
>
> Had a quick skim through your tutorial today, one thing stood out as
> incorrect.
>
> “Note that you can only use one select statement in a thconfig file, and
> it does not matter where in the file you put it. I always put it at the top
> so it is easy to spot. If you put in select statements for more than one
> map then only one of them will be used.“
>
>
>
> We routinely use thconfig files with multiple select statements for maps
> with the same projection.
>
> All of the maps are produced in the resulting pdf (and other) files.  As
> with Therion’s typical treatment of lists of drawn entities, the first map
> listed is in the top layer of the pdf, and the last map is in the bottom
> layer.
>
> Bruce
>
>
> =___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160322/230c0282/attachment.html>

[Therion] Therion Digest, Vol 123, Issue 5

[Footleg]

I tried this in my team list:team [text Paul/"Footleg"] notes

but it appears in the PDF as:text Paul .Footleg.,

It is the double quotes appearing as . which puzzles me. Is this a language
setting problem?

Footleg

On Thu, Mar 17, 2016 at 10:25 AM Владимир Георгиев 

wrote:

> You can use double quotes like this [text "quoted text"]
>
> Vladimir
> On Mar 16, 2016 2:59 PM, "Footleg"  wrote:
>
>> Thanks Dave,
>>
>> I didn't know that. A little more experimentation and I have noticed that
>> the position of the / determines where the name appears in the sorted names
>> lists. So
>>   team "Tim 'The Beast'/Bloggs" dog
>> makes Tim appear in alphabetical order sorted using 'Bloggs', whereas
>>   team "Tim/'The Beast' Bloggs" dog
>> put him at the start of the list as the ' character is sorted ahead of A.
>>
>> I've put this into the Tutorial. Does anyone know how to include
>> double-quotes in a name? I can't seem to escape the double-quote character.
>>
>> Footleg
>>
>> On Wed, Mar 16, 2016 at 12:34 AM Dave Clucas 
>> wrote:
>>
>>> Note that the team members names are only allowed to contain one space
>>> character, so use hypens for double barreled names or your project will
>>> generate an error when you try to compile it.
>>>
>>> You can also use the escape character "/" to allow as may spaces as you
>>> want e.g. team "Giles /St. John Cuthbert Junior"
>>>
>>> Dave Clucas
>>> daveclucas.com
>>> sarawak-caves.com
>>> dave.clucas at icloud.com 
>>>
>>> *Exploring the World* - One cave at a time
>>>
>>>
>>> On 16 Mar 2016, at 04:32, therion-request at speleo.sk wrote:
>>>
>>> Send Therion mailing list submissions to
>>> therion at speleo.sk
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> http://mailman.speleo.sk/mailman/listinfo/therion
>>> or, via email, send a message with subject or body 'help' to
>>> therion-request at speleo.sk
>>>
>>> You can reach the person managing the list at
>>> therion-owner at speleo.sk
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Therion digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>   1. Therion Tutorial Update - Data Structures and Layouts (Footleg)
>>>   2.  Re:  Therion Tutorial Update - Data Structures and Layouts
>>>  (Martin Sluka)
>>>   3. Re: Therion Tutorial Update - Data Structures and Layouts
>>>  (Footleg)
>>>   4. Re: Therion Tutorial Update - Data Structures and Layouts
>>>  (Martin Sluka)
>>>
>>>
>>> --
>>>
>>> Message: 1
>>> Date: Tue, 15 Mar 2016 14:45:46 +
>>> From: Footleg 
>>> Subject: [Therion] Therion Tutorial Update - Data Structures and
>>> Layouts
>>> To: List for Therion users 
>>> Message-ID:
>>> <CAJkGg4mK7DPP47LVkft8++iBN2hVOVu+VV_a98XdNhsA6ps7wA at mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hot off the press, I have published another update to my Therion
>>> Tutorial.
>>> Since the last revision in November 2015 I have simplified the
>>> recommendations on larger project data structures (I realised my own
>>> projects were not following my advice I had written!), and added a new
>>> lesson on defining layouts.
>>>
>>> As always, feedback and comments are welcomed. But don't be disheartened
>>> if
>>> I have not yet incorporated suggestions made already into this latest
>>> revision. I just wanted to get this initial layouts chapter out there as
>>> several people asked for it. I'll take the time to read all the feedback
>>> I've received already and merge it into the tutorial in time.
>>>
>>> Download here (or follow the link from the Therion Wiki page):
>>> *http://wscc.darkgem.com/footleg/therion/
>>> <http://wscc.darkgem.com/footleg/therion/>*
>>>
>>> Footleg
>>> -- next part --
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> http://mailman.speleo.sk/pipermail/therion/attachments/20160315/e8fec669/attachment-0001.htm
>>> >
>>>
>>> --

[Therion] Therion Digest, Vol 123, Issue 5

[Footleg]

Thanks Dave,

I didn't know that. A little more experimentation and I have noticed that
the position of the / determines where the name appears in the sorted names
lists. So
  team "Tim 'The Beast'/Bloggs" dog
makes Tim appear in alphabetical order sorted using 'Bloggs', whereas
  team "Tim/'The Beast' Bloggs" dog
put him at the start of the list as the ' character is sorted ahead of A.

I've put this into the Tutorial. Does anyone know how to include
double-quotes in a name? I can't seem to escape the double-quote character.

Footleg

On Wed, Mar 16, 2016 at 12:34 AM Dave Clucas  wrote:

> Note that the team members names are only allowed to contain one space
> character, so use hypens for double barreled names or your project will
> generate an error when you try to compile it.
>
> You can also use the escape character "/" to allow as may spaces as you
> want e.g. team "Giles /St. John Cuthbert Junior"
>
> Dave Clucas
> daveclucas.com
> sarawak-caves.com
> dave.clucas at icloud.com 
>
> *Exploring the World* - One cave at a time
>
>
> On 16 Mar 2016, at 04:32, therion-request at speleo.sk wrote:
>
> Send Therion mailing list submissions to
> therion at speleo.sk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mailman.speleo.sk/mailman/listinfo/therion
> or, via email, send a message with subject or body 'help' to
> therion-request at speleo.sk
>
> You can reach the person managing the list at
> therion-owner at speleo.sk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Therion digest..."
>
>
> Today's Topics:
>
>   1. Therion Tutorial Update - Data Structures and Layouts (Footleg)
>   2.  Re:  Therion Tutorial Update - Data Structures and Layouts
>  (Martin Sluka)
>   3. Re: Therion Tutorial Update - Data Structures and Layouts
>  (Footleg)
>   4. Re: Therion Tutorial Update - Data Structures and Layouts
>  (Martin Sluka)
>
>
> --
>
> Message: 1
> Date: Tue, 15 Mar 2016 14:45:46 +
> From: Footleg 
> Subject: [Therion] Therion Tutorial Update - Data Structures and
> Layouts
> To: List for Therion users 
> Message-ID:
> <CAJkGg4mK7DPP47LVkft8++iBN2hVOVu+VV_a98XdNhsA6ps7wA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hot off the press, I have published another update to my Therion Tutorial.
> Since the last revision in November 2015 I have simplified the
> recommendations on larger project data structures (I realised my own
> projects were not following my advice I had written!), and added a new
> lesson on defining layouts.
>
> As always, feedback and comments are welcomed. But don't be disheartened if
> I have not yet incorporated suggestions made already into this latest
> revision. I just wanted to get this initial layouts chapter out there as
> several people asked for it. I'll take the time to read all the feedback
> I've received already and merge it into the tutorial in time.
>
> Download here (or follow the link from the Therion Wiki page):
> *http://wscc.darkgem.com/footleg/therion/
> <http://wscc.darkgem.com/footleg/therion/>*
>
> Footleg
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mailman.speleo.sk/pipermail/therion/attachments/20160315/e8fec669/attachment-0001.htm
> >
>
> --
>
> Message: 2
> Date: Tue, 15 Mar 2016 15:34:01 + (GMT)
> From: Martin Sluka 
> Subject: [Therion]  Re:  Therion Tutorial Update - Data Structures and
> Layouts
> To: Footleg 
> Cc: therion at speleo.sk
> Message-ID: <202dcf19-8fcc-4845-a465-f7a7f0a795cc at me.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Hi Footleg,
>
> you don't show using right click with mouse when drawing scraps. It is
> much faster way.
>
> Drawing line - one may not draw beziers directly. It is possible to draw
> only points which are not "smooth" and then use "Convert to curve" feature
> from "Edit line" menu. There are only small correction necessary.
>
> The problem with transparency is that all viewers using Apple library and
> several others (Sumatra) ignore group transparency which is in definition
> of PDF. So it is bug. (According to?Martin Budaj).
>
> m.s.
>
> On Mar 15, 2016, at 03:46 PM, Footleg  wrote:
>
> Hot off the press, I have published another update to my Therion Tutorial.
> Since the last revision in November 2015 I have simplified the
> recommendations on larger project data stru

[Therion] Therion Tutorial Update - Data Structures and Layouts

[Footleg]

Hi Martin,

Thanks for these points. Can you clarify what you mean by using right mouse
click when drawing scraps? I thought I covered the right-mouse menus for
setting line options. Was there something specific I've missed, or not
clear enough mention of context menus when drawing?

I'm not sure where group transparency is applied in the PDFs. I see
transparency working for overlying passages and for boulders drawn over
area fills. At least I see it in Sumatra and FoxIt readers, but not in
Adobe Acrobat Reader. Can you give examples of features where I can check
whether it is working?

Convert to curve is a good one. I'll find a place to add that in as I've
seen a few people struggle with drawing beziers directly when we run out
training courses.

Thanks,
Footleg

On Tue, Mar 15, 2016 at 3:34 PM Martin Sluka  wrote:

> Hi Footleg,
>
> you don't show using right click with mouse when drawing scraps. It is
> much faster way.
>
> Drawing line - one may not draw beziers directly. It is possible to draw
> only points which are not "smooth" and then use "Convert to curve" feature
> from "Edit line" menu. There are only small correction necessary.
>
> The problem with transparency is that all viewers using Apple library and
> several others (Sumatra) ignore group transparency which is in definition
> of PDF. So it is bug. (According to Martin Budaj).
>
> m.s.
>
> On Mar 15, 2016, at 03:46 PM, Footleg  wrote:
>
> Hot off the press, I have published another update to my Therion Tutorial.
> Since the last revision in November 2015 I have simplified the
> recommendations on larger project data structures (I realised my own
> projects were not following my advice I had written!), and added a new
> lesson on defining layouts.
>
> As always, feedback and comments are welcomed. But don't be disheartened
> if I have not yet incorporated suggestions made already into this latest
> revision. I just wanted to get this initial layouts chapter out there as
> several people asked for it. I'll take the time to read all the feedback
> I've received already and merge it into the tutorial in time.
>
> Download here (or follow the link from the Therion Wiki page):
> *http://wscc.darkgem.com/footleg/therion/
> <http://wscc.darkgem.com/footleg/therion/>*
>
> Footleg
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160315/9afcfacc/attachment.html>

[Therion] Setting Scrap Colours

[Footleg]

Does colour by map not work? I thought it was an option specified in the
Therion book in this section:

• colo[u]r   ◃ customize colour for special map items
(map-fg, mapbg,
preview-above, preview-below, label). Colour range is 0–100 for grayscale,
[0–100
0–100 0–100] triplet for RGB colours.
For map-fg, you can use altitude, scrap or map as colours. In this case the
map is
coloured according to altitude, scraps or maps.
For map-bg, you can use transparent to omit page background completely.
For labels, you can switch colour on/off. If on, labels are coloured using
the colour of
associated scrap.

Footleg

On Thu, Mar 10, 2016 at 6:21 PM Bruce Mutton  wrote:

> I use colour by scrap quite often as a drawing aid. Random is fine for
> that. Colour by map would be the more useful to be able to specify for
> 'finished presentations'.
>
> Colour by map has been discussed and requested from time to time.
>
> Bruce
>
> Sent from my Samsung device, hence the typo's
>
>
> ---- Original message 
> From: Footleg 
> Date: 11/03/2016 02:25 (GMT+12:00)
> To: List for Therion users 
> Subject: [Therion] Setting Scrap Colours
>
> I've been doing some more work on my Therion Tutorial, which has led me to
> explore more options than I typically use. One of these is to colour scraps
> different colours. All I can find in the Therion Book is how to specify to
> colour map-fg by altitude or by scrap. If I do either of these then the
> colours are assigned automatically. I've searched my email history and seen
> that colour by altitude has been discussed before, but I can't work out if
> there is supposed to be a way to set the colour for a scrap?
>
> If this isn't currently possible, then if would be ideally implemented in
> the layout so that if is not coded into the drawings of the scraps
> themselves. Perhaps a syntax to let you specify as follows:
>
> colour  
>
> Am I missing a way to do this in the existing release?
>
> Footleg
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160311/e39c892a/attachment.html>

[Therion] Setting Scrap Colours

[Footleg]

I've been doing some more work on my Therion Tutorial, which has led me to
explore more options than I typically use. One of these is to colour scraps
different colours. All I can find in the Therion Book is how to specify to
colour map-fg by altitude or by scrap. If I do either of these then the
colours are assigned automatically. I've searched my email history and seen
that colour by altitude has been discussed before, but I can't work out if
there is supposed to be a way to set the colour for a scrap?

If this isn't currently possible, then if would be ideally implemented in
the layout so that if is not coded into the drawings of the scraps
themselves. Perhaps a syntax to let you specify as follows:

colour  

Am I missing a way to do this in the existing release?

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160310/3a1b2ca3/attachment.html>

[Therion] XTherion modifications

[Footleg]

Confirmed with a quick test that I could reproduce that problem with the
old version, and that I don't see the issue with this latest compiled .tcl
file. I'm trying this out for some drawing up so I'll let you know whether
I find any other issues.

Footleg

On Tue, Feb 23, 2016 at 8:05 PM Владимир Георгиев 
wrote:

> There was a bug resulting from my changes. The new stations are
> triangular, while the other points oval, and changing the type of point
> resulted in improper drawing or a crash.
> Here is a crude fix for it.
>
> Vladimir
>
> On Fri, Feb 19, 2016 at 10:42 PM, Владимир Георгиев <
> vld.georgiev at gmail.com> wrote:
>
>> Well, I didn't mean that Martin and Stacho have forgotten about Therion.
>> The mods were initially for my own usage, but since its an open source
>> project I thought the authors would not mind me sharing them.
>>
>> Wookey
>> "DOSify", got it :)
>> Now that you mentioned it, my git client replaces Unix with Win line
>> endings. This is reverted when the commit is pushed to the repo, but not
>> when I manually send the files by email :)
>> Will keep it in mind when I send files.
>>
>> Vladimir
>>
>> On Fri, Feb 19, 2016 at 9:57 PM, Martin Sluka 
>> wrote:
>>
>>> Hi all,
>>>
>>> as I may say, Martin B. and Stacho are still alive, bus very busy. I
>>> spoke with Martin B. few minutes ago. Therion is not only on Stacho's
>>> computer, but on Martin B.'s too. So don't worry.
>>>
>>> They are testing Github repo too.
>>>
>>> Martin B. told me, that after they'll finish a project for their work
>>> they will prepare new release.
>>>
>>> So don't lose hope, please.
>>>
>>> :)
>>>
>>> m.s.
>>>
>>>
>>> ___
>>> Therion mailing list
>>> Therion at speleo.sk
>>> http://mailman.speleo.sk/mailman/listinfo/therion
>>>
>>>
>>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160223/b450b382/attachment.html>

[Therion] XTherion modifications

[Footleg]

I've taken a quick look, and this is really (REALLY!) useful. Just messed
with the colours, not the other enhancements. I already changed the colour
of rock lines from snow4 to yellow by editing (and uncommenting) that line
in the ini file. I could not tell my rock lines from my survey lines
rendered in the background sketch imported from PocketTopo. Some of the
other colours are maybe a little too dark so I will experiment more to
brighten them up and see what I think works best as I am sketching.

The triangles for station points have another advantage over just changing
their colour. I can now see the black circles for the stations positions in
the background sketch imported from PocketTopo. Previously the blue circles
of the stations points completely hid the black circles they were placed on
top of.

If you could add something to the points which have an orientation set to
show the orientation (without having to select them as currently) that
would be another step forwards.

Great stuff, thank you!

Footleg

On Wed, Feb 17, 2016 at 11:50 AM Владимир Георгиев 

wrote:

> Hi all
>
> There are some modifications that I made to the XTherion and would be
> interested if someone can test them and share their opinion. They were
> quickly patched up and I am no TCL developer so there might be a bug or two.
>
> Initially I needed to have an XTherion shortcut to delete a line point so
> I started looking through the source. I added Ctrl+Shift+D for deleting a
> line point, Ctrl+Up/Down for zooming in and out in the map editor.
>
> The all blue items in the map editor were harder to use so I tried to
> colorize them. E.g. walls to be "brick red", pits are magenta, rock borders
> dark gray, slope is yellow, etc. The non-selected scrap is light gray.
> The station point I made orange and a triangle instead of a circle so it
> is more visible.
> I will probably add other colors after I work with the editor more.
>
> I have attached a couple of screenshots of how it looks, the xtherion
> source and the "compiled" xtherion tcl app.
>
> Btw, where does the source live, besides the zip archive on the site? Is
> there a source control repo somewhere that people can contribute to?
> For experimenting with the colors I used a private git repo. I admit I
> haven't checked the licensing for the code.
>
> Here are the colors that I changed and added them to the INI file.
> #set xth(gui,me,activefill) red
> #set xth(gui,me,pasivefill) green
> #set xth(gui,me,controlfill) blue
> #set xth(gui,me,highlightfill) cyan
> #set xth(gui,me,unselectedfill) lightgray
> #set xth(gui,me,wallcolor) brown
> #set xth(gui,me,pitcolor) magenta
> #set xth(gui,me,slopecolor) gold
> #set xth(gui,me,rockcolor) snow4
> #set xth(gui,me,bordercolor) turquoise
> #set xth(gui,me,stationcolor) darkorange
>
>
> Best
> Vladimir
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160219/d0ea4b6e/attachment.html>

[Therion] Online interactive survey of 58km system

[Footleg]

I've not looked into the features of Therion for including bitmaps in the
PDF output. So much still to learn!

Footleg

On Wed, Jan 6, 2016 at 2:05 PM Martin Sluka  wrote:

> Choice of software:
>
> I am aware that Zoomify does this sort of thing too. But I chose krpano
> viewer as I already had a license. It is not the cheapest viewer if you
> just want to present flat images, but I primarily use it for my panoramic
> tours (as example here which has hotspot links to other caves if you want
> to explore a bit http://wscc.darkgem.com/footleg/pano/Risco.html )
>
>
> Nothing to add.
>
> Don't you tried to morph scanned images in Therion by export PDFs with
> sketches on?
>
> M.s.
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160106/e7d5c9f7/attachment.html>

[Therion] Online interactive survey of 58km system

[Footleg]

Answering a few comments in one reply here:

Choice of software:
I am aware that Zoomify does this sort of thing too. But I chose krpano
viewer as I already had a license. It is not the cheapest viewer if you
just want to present flat images, but I primarily use it for my panoramic
tours (as example here which has hotspot links to other caves if you want
to explore a bit http://wscc.darkgem.com/footleg/pano/Risco.html )

How the composite map was produced:
The presentation was generated from one very high resolution bitmap image
which I assembled from various bitmaps of the different surveys at
different resolutions using Adobe Photoshop. I started with a high
resolution bitmap of the entire system centreline (printed from Survex to a
PDF and then converted to SVG using Inkscape. The SVG was then imported and
rasterised in Photoshop. I then drag and drop (from the file explorer) each
additional survey bitmap into this Photoshop project, which creates smart
object layers. These enable me to scale/rotate/position each bitmap over
the centreline. Some of the older surveys needed to be stretched a bit to
fit. I made the joins as neat as possible using layer masks to control
which parts of each bitmap are visible over the underlying layers. I can
easily add new surveys into the mix now as I draw up more of the system.
The Therion output was taken from the PDF generated by Therion, and saved
as a bitmap using Inkscape. I could possibly get better conversion quality
by converting to SVG and rasterising that in Photoshop instead. Finally I
export a single flattened TIFF file of the composite map and drop that into
krpanotools, which generates the multi-resoution tiles and HTML5+Flash web
output which I put online.

Footleg

On Tue, Jan 5, 2016 at 3:56 PM Martin Sluka  wrote:

> Nice work!
>
> If pro version of Zoomify you may add images too.
>
> :)
>
> m.s.
>
> On Jan 05, 2016, at 02:58 PM, Footleg  wrote:
>
> I thought people on this list might be interested in the latest
> presentation of the 58km system survey I have been working on. I have just
> added the first part drawn using Therion (the colourful bit around the
> Carcavuezo entrance in the middle of the southern edge). This survey
> assembles the best data over 40 years, featuring 'pencil and graph paper',
> 'ink on tracing paper', 'offlet litho printed', Tunnel and Therion software
> drawings.
>
> http://wscc.darkgem.com/matienzo/4valleys/
>
> This format should work on all mobile devices and web browsers on
> computers.
>
> Footleg
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160106/974e358f/attachment.html>

[Therion] Online interactive survey of 58km system

[Footleg]

I thought people on this list might be interested in the latest
presentation of the 58km system survey I have been working on. I have just
added the first part drawn using Therion (the colourful bit around the
Carcavuezo entrance in the middle of the southern edge). This survey
assembles the best data over 40 years, featuring 'pencil and graph paper',
'ink on tracing paper', 'offlet litho printed', Tunnel and Therion software
drawings.

http://wscc.darkgem.com/matienzo/4valleys/

This format should work on all mobile devices and web browsers on computers.

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20160105/29e45e4c/attachment.html>

[Therion] change palette for color map-fg altitude

[Footleg]

A trick I use is to define a pair of made up fixed stations at a higher and
lower altitude than my cave, then define a scrap containing both stations
as points. Include this scrap to force the colour range to cover this
altitude range. If you make the lower point lower than your cave then your
cave will be rendered entirely in the green to red colour range.

Footleg

On Thu, 10 Dec 2015 18:28 Andrew Atkinson  wrote:

> .
> > >
> > > Anyone know where the palette is defined?
> >
> > I think this is an outstanding wishlist item. i.e. there is no way to
> > do this yet, but you are not the first person to ask. Andrew knows.
>
> I believe you cannot control the palette, I use tricks to keep colours
> aligned and remove certain colours, but even this changes occasionally
> without me knowing why
>
> Andrew
>
> Andrew
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20151211/08d52a3c/attachment.html>

[Therion] Updated Tutorial

[Footleg]

I have just put an updated draft of my Therion Tutorial online (link on the
Therion wiki), or click here: http://wscc.darkgem.com/footleg/therion/

I've completed lessons on area fills, and tackled the much more complex
topic of how to structure your data for a project which is more than one
scrap/survey trip. There are many ways to do this of course, but I have
suggested one in the tutorial which should help people who do not already
have a data model in mind. As always I welcome feedback and comments which
will help me and others to improve and learn more.

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20151101/f62f3931/attachment.html>

[Therion] Export to 3D processing softwares

[Footleg]

Looks like a great topic to add to the wiki Martin. I used the export to
vtk and import into Paraview before when creating a model for 3D printing.
But beyond that point I was not involved in processing the data further
(the person arranging the 3D printing handled it from here on). I am sure
there is more to learn which can then be added to the topic if you start a
wiki page for this.

Footleg

On Wed, Oct 21, 2015 at 6:00 PM Martin Sluka  wrote:

> Therion and 3D
>
> Therion is able to export 3D model in format .lox based on LRUD data,
> shape of walls in plan and passage height informations recently. If the map
> is drawn in correct way these models are quite good. To view the model one
> should use internal viewer of Therion named Loch. The Loch has feature to
> export model in the VTK format. And several softwares for manipulating with
> 3D data for example CloudCompare or Paraview are able to import this VTK
> format.
>
> CloudCompare is able to export next formats:
>
> BIN .bin CloudCompare own format
> ASCII .asc,.txt,.xyz,.neu,.pts ASCII point cloud file (X,Y,Z,etc.)
> LAS .las ASPRS lidar point clouds
> E57 .e57 ASTM E57 file format
> PCD .pcd Point Cloud Library format
> PLY .ply Stanford 3D geometry format (cloud or mesh)
> OBJ .obj Wavefront mesh
> VTK .vtk VTK file format (triangular mesh or cloud only)
> STL .stl STereoLithography file format (mesh)
> OFF .off Object File Format (mesh)
> FBX .fbx Autodesk (Filmbox) File Format
> DXF .dxf Autocad DXF format
> SHP .shp ESRI Shape file format
> RASTER .geotiff, etc. Common raster formats (GDAL)
> PV .pv Point cloud + scalar field
> PN .pn Point cloud + normals
> Sinusx .sx Sinusx curves
>
> ParaView is able to work with next formats:
>
> ParaView files
> VTK files
> Parallel (partitioned) VTK files
> VTK MultiBlock (MultiGroup, Hierarchical, Hierarchical Box) files
> Legacy VTK files
> Parallel (partitioned) legacy VTK files
> EnSight files
> EnSight Master Server files
> Exodus files
> BYU files
> XDMF files
> PLOT3D files
> SpyPlot CTH files
> HDF5 raw image data files
> DEM files
> VRML files
> PLY Polygonal files
> Protein Data Bank files
> XMol Molecule files
> Stereo Lithography files
> Gaussian Cube files
> Raw (binary) files
> AVS files
> Meta Image files
> Facet files
> PNG files
> SAF files
> LS-Dyna files
>
> So you may for example calculate surface and volume of cave - thanks to
> Filippo Gregori:
>
> 1) Export the lox file to vtk format
> 2) With Paraview software I opened the file vtk
> 3) Save the file as .x3d
> 4) Open the file x3d in Meshlab software
> 6) Apply the filter: Filters -> Quality measure and computation -> compute
> geometric Measures
> 7) Open log window: View -> Show Layer dialog
> 8) Read the lines Volume Mesh and Mesh Surface
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20151021/a0c70462/attachment.html>

[Therion] Plotting scraps and the centreline together

[Footleg]

(Actually you only need to check out the
http://cave-registry.org.uk/svn/MatienzoCaves/5Valleys/Therion%20Drawings/
folder
to get the complete Therion project)

Footleg

On Mon, Oct 19, 2015 at 5:27 PM Footleg  wrote:

> Hi Jenny,
>
> I have a project where I do this. I think I copied the idea off Bruce.
> I've just taken another look at the files to see how it works. I have a map
> definition in my project which looks like this:
>
> map CarcPlanCL -title "Carcavuezo centreline Plan" -projection plan
>   4ValleysCL #centreline survey
> endmap
>
> All my map definitions are in the Carc_Map-Complete.th file which is
> referenced in my survey in the master .th file of my project. That file
> imports a survey 3D file for the centreline. Note how the map defined above
> contains the name of the survey from my master file, rather than the name
> of a map or scrap. The master .th file contents are as follows:
>
> survey Carcavuezo
>
>   survey 4ValleysCL
> import 0081_therion.3d -surveys use -cs EPSG:25830
>   endsurvey
>
>   input Carc_MAP-Complete.th
>
> endsurvey
>
> -
> All you need to do to include the entire centreline from the survey in the
> PDF is include the map CarcPlanCL in the map you are generating the PDF
> from (along with the other maps which contain the scraps you want to plot
> on the PDF. Just remember you cannot mix maps and scraps in a map
> definition, which is why I have the special map containing the survey
> rather than including the survey in my master map directly.
>
> Also remember in your thconfig file to specify which map is the master map
> to generate the PDF from (in my thconfig file I declare: select
> CarcavuezoPlan at Carcavuezo )
>
> If you want to play with my complete project then you can check it out
> from the UK cave registry svn here:
> http://cave-registry.org.uk/svn/MatienzoCaves/5Valleys
>
> This particular project is part of a much larger one (the entire 5
> valleys). You want to process the thconfig-carcavuezo project in the
> folder 5Valleys\Therion Drawings\0081_Carcavuezo
>
> Footleg
>
>
>
> On Mon, Oct 19, 2015 at 10:23 AM Martin Sluka  wrote:
>
>> Jenny,
>>
>> It looks the problem is you want to mix maps defined from scraps and maps
>> defined from surveys. Try to draw „blind“ scraps only with stations and
>> generate map from scraps.
>>
>> As I may say, I newer tried to define map as this:
>>
>> map from_surveys_only.map
>>  survey1
>>  survey 2
>> endmap
>>
>> map from_scraps.map
>>   scrap1
>>   scrap2
>> endmap
>>
>> map all.map
>>   map_from_surveys_only
>>   map_from_scraps
>> endmap
>>
>> thconfig:
>>
>> select all.map
>>
>> m.s.
>>
>>
>> > 19. 10. 2015 v 6:23, Jenny Black :
>> >
>> > Hi,
>> >
>> > I want to plot both the centreline for the entire cave and passages in
>> > the scraps I have drawn. I can do one at a time but can't figure out
>> > how to plot both.
>> >
>> > In my thconfig file I have:
>> > symbol-show point station
>> > symbol-show group cave-centreline
>> > symbol-show point station-name
>> > debug station-names
>> >
>> > so when I don't have any scraps, I get the centreline and stations
>> > nicely plotted for the entire cave, which is proving very helpful with
>> > figuring out where to break loops for my extended elevation.
>> >
>> > However, as soon as I add in my scraps, which I've been doing by adding:
>> > input 107ee_ropeless.th2
>> > input 107ee_china_new.th2
>> > input 107ee_oldroute.th2
>> > to my .th file I can only see the centreline (and walls, etc) for the
>> > scraps of drawn and not the rest of the cave.
>> >
>> > I'm sure it is possible to plot the scraps *and* the entire
>> > centreline. I'm sure I read it on a mailing list post when I was
>> > looking fro something else, but I can't rmanage to re-find it. Can
>> > anyone help?
>> >
>> > In case it makes a difference, I am plotted an extended elevation and
>> > reading in survex data as a 3d file.
>> >
>> > Thanks,
>> > Jenny
>> > ___
>> > Therion mailing list
>> > Therion at speleo.sk
>> > http://mailman.speleo.sk/mailman/listinfo/therion
>>
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20151019/b4c16c64/attachment.html>

[Therion] Plotting scraps and the centreline together

[Footleg]

Hi Jenny,

I have a project where I do this. I think I copied the idea off Bruce. I've
just taken another look at the files to see how it works. I have a map
definition in my project which looks like this:

map CarcPlanCL -title "Carcavuezo centreline Plan" -projection plan
  4ValleysCL #centreline survey
endmap

All my map definitions are in the Carc_Map-Complete.th file which is
referenced in my survey in the master .th file of my project. That file
imports a survey 3D file for the centreline. Note how the map defined above
contains the name of the survey from my master file, rather than the name
of a map or scrap. The master .th file contents are as follows:

survey Carcavuezo

  survey 4ValleysCL
import 0081_therion.3d -surveys use -cs EPSG:25830
  endsurvey

  input Carc_MAP-Complete.th

endsurvey

-
All you need to do to include the entire centreline from the survey in the
PDF is include the map CarcPlanCL in the map you are generating the PDF
from (along with the other maps which contain the scraps you want to plot
on the PDF. Just remember you cannot mix maps and scraps in a map
definition, which is why I have the special map containing the survey
rather than including the survey in my master map directly.

Also remember in your thconfig file to specify which map is the master map
to generate the PDF from (in my thconfig file I declare: select
CarcavuezoPlan at Carcavuezo )

If you want to play with my complete project then you can check it out from
the UK cave registry svn here:
http://cave-registry.org.uk/svn/MatienzoCaves/5Valleys

This particular project is part of a much larger one (the entire 5
valleys). You want to process the thconfig-carcavuezo project in the
folder 5Valleys\Therion Drawings\0081_Carcavuezo

Footleg



On Mon, Oct 19, 2015 at 10:23 AM Martin Sluka  wrote:

> Jenny,
>
> It looks the problem is you want to mix maps defined from scraps and maps
> defined from surveys. Try to draw „blind“ scraps only with stations and
> generate map from scraps.
>
> As I may say, I newer tried to define map as this:
>
> map from_surveys_only.map
>  survey1
>  survey 2
> endmap
>
> map from_scraps.map
>   scrap1
>   scrap2
> endmap
>
> map all.map
>   map_from_surveys_only
>   map_from_scraps
> endmap
>
> thconfig:
>
> select all.map
>
> m.s.
>
>
> > 19. 10. 2015 v 6:23, Jenny Black :
> >
> > Hi,
> >
> > I want to plot both the centreline for the entire cave and passages in
> > the scraps I have drawn. I can do one at a time but can't figure out
> > how to plot both.
> >
> > In my thconfig file I have:
> > symbol-show point station
> > symbol-show group cave-centreline
> > symbol-show point station-name
> > debug station-names
> >
> > so when I don't have any scraps, I get the centreline and stations
> > nicely plotted for the entire cave, which is proving very helpful with
> > figuring out where to break loops for my extended elevation.
> >
> > However, as soon as I add in my scraps, which I've been doing by adding:
> > input 107ee_ropeless.th2
> > input 107ee_china_new.th2
> > input 107ee_oldroute.th2
> > to my .th file I can only see the centreline (and walls, etc) for the
> > scraps of drawn and not the rest of the cave.
> >
> > I'm sure it is possible to plot the scraps *and* the entire
> > centreline. I'm sure I read it on a mailing list post when I was
> > looking fro something else, but I can't rmanage to re-find it. Can
> > anyone help?
> >
> > In case it makes a difference, I am plotted an extended elevation and
> > reading in survex data as a 3d file.
> >
> > Thanks,
> > Jenny
> > ___
> > Therion mailing list
> > Therion at speleo.sk
> > http://mailman.speleo.sk/mailman/listinfo/therion
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20151019/283a746f/attachment.html>

[Therion] osx mavericks - loch 3D overlay graphics

[Footleg]

I see this problem with some graphics cards (on Windows computers). The
same Loch file viewed on another computer (or on a VM running on the
computer where I see the problem) shows the graphic overlay fine. So it is
likely a display driver problem.

Footleg

On Mon, Sep 21, 2015 at 7:27 PM Dr. Heinrich Kestler <
heinrich.kestler at tnr.at> wrote:

> I managed to install thereon successfully on osx mavericks using home-brew.
> Nearly everything seems to work fine so far.
> However, trying to apply an overlay graphic to a surface model in loch, it
> doesn´t work, i.e. the surface remains grey. I wonder whether this is a
> known issue with loch
> or if I missed to install something. Any suggestions?
>
> Many thanks in advance!
>
> Heinrich
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150922/d14349b4/attachment.html>

[Therion] Best caving tablet

[Footleg]

I would agree that the 'hold in one hand' size of a PDA is a big plus. You
need to be able to cave with the device in your hand, and unless you only
survey large walking passages with flat floors you will appreciate
something that you can climb around the cave while holding in one hand.
Also makes packing the device for transportation through crawls and awkward
entrance series much easier. I am often surveying 3 hours from an entrance
and having a light weight compact kit means it always gets taken on
exploration trips in case we make a break through. So we often leave the
cave with data on the trip where a discovery was made.

Footleg

On Tue, Sep 15, 2015 at 9:13 PM Andrew Atkinson  wrote:

> I have a asus vivo tab/not 8 tablet, which I just find too big for cave
> surveying, which I feel will be a problem with the one below. I think
> that you need to be able to hold it on one hand while caving, which for
> me makes a 6inch tablet probably the biggest, but I have not got round
> to buying one as yet.
> The vivo although it has a wacom tablet built in, I am not very
> impressed with the accuracy, even after going through the 100+ point
> calibration, gone back to my dell axim,
>
> Andrew
>
> On 15/09/15 20:50, Rob Countess wrote:
> > http://ruggedpcreview.com/3_slates_xplore_xslate_b10.html
> >
> > I'm thinking of this: XSlate B10. Has wacom digitizer. They also make
> > smaller android model. Any thoughts?
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150916/4aaf2da2/attachment.html>

[Therion] Therion tutorial

[Footleg]

I've been thinking along much the same lines regarding my tutorial, as I
have increased my knowledge of Therion somewhat since I wrote to original.
I started work on a new version earlier in the year, based on a more
suitable data set which would enable me to cover more Therion skills with
less drawing and expand into some of the areas I was unsure about when I
wrote the original. I also tried to incorporate details of all the common
pitfalls I have observer trainees fall into on the training courses we have
run in recent years in the UK. I've not got back to continue work on this
tutorial since March (I took a break to actually do some survey drawing up)
so rather than sit on this longer, I have posted a link to the current
draft on the Documentation section of the wiki. Or you can find it directly
from this link: http://wscc.darkgem.com/footleg/therion/

I would welcome any feedback on this new revision. If you spot any errors
or omissions of course, but particularly please let me know what Therion
knowledge is not covered which you think is important to progress further.

Great to hear that the original tutorial has proved so useful. I hope this
revision can make it even more valuable to people.

Footleg

On Sun, Sep 6, 2015 at 7:19 AM Graham Mullan 
wrote:

> Nick Bairstow wrote:
>
> "I have been giving some thought to producing a tutorial to follow on from
> Footlegs wiki item. Unfortunately it's not a simple as I first thought.
> Over
> the next few months I will attempt to come up with something that will
> enable a novice therioneer understand the next steps following the Footleg
> wiki article. It would be nice to continue using Bull Pot as the sample
> cave
> but I have not got time to re-survey that so I propose we use an existing
> data set which could become the default novice reference.
> It seems many people give up with Therion as it is difficult to learn but
> with a good tutorial and a little help many more could be using it.
> What do people think, am I wasting my time, comments please.
> Oh and if someone else is already doing something similar please shout up.
> No point doing it twice."
>
> I use Footleg's tutorial a lot. If you are not using a program every day,
> then having a handy known reference point for the details is always a good
> thing. It doesn't cover every single aspect, so if Nick wants to add
> further
> material, I for one would be delighted. Please do it, Nick.
>
> The other main trick for learning in this way is "How did we do this last
> time?" or looking back at a previous data set, your own or someone else's,
> and seeing how it works. If there was a reference data set available (if
> not
> on the Therion wiki but on the cave-registry page, perhaps) then the
> tutorial could certainly link to that. Of course 'live' data can change
> over
> time, so having a fixed example set might be better. Bear in mind that data
> for a single cave is insufficient to cover all problems. We routinely
> combine data from different caves, because they are close together or, as
> has been done several times, to produce a context overview to show a cave
> in
> relation to its neighbours and the land surface. See, for example, the
> thing
> below the caption in the latest version of the Gough's Cave survey
> http://www.ubss.org.uk/resources/surveys/survex/Goughs_all.pdf  . Does
> anyone have a good multi-cave dataset that is now stable and so can be used
> for this purpose?
>
> It is also worth remembering, of course, that different people do some
> things differently, an example data set might enshrine work habits that are
> not the same as mine or yours.
>
> Graham
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150907/e8a1913b/attachment.html>

[Therion] Cave Surveying and Therion Training Weekend in Mendip, UK at end of March

[Footleg]

I'm running a cave surveying and drawing up training course in Mendip
(Somerset, UK) on the weekend of 28-29th March. Covering DistoX and
Therion. Reply to me if interested. Limited to 12 places, first come first
served. (£10 deposit to book a place. £20 total per person to cover travel
and caving hut expenses of trainers).

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150224/c63be59c/attachment.html>

[Therion] Joining old and new surveys

[Footleg]

If you are genuinely processing Compass data which was originally measured
in feet and inches, then use that format in your Therion data files and
just tell Therion which units your data is in. If however you are working
with data that was stored in Compass but originally surveying in metric,
then you can use my cave converter program to convert Compass data to
Survex data. Not quite Therion format, but very close and you can cut and
paste the numbers from the Survex file into Therion files. This will
convert the data back to metric from the imperial units saved in a Compass
file.

http://wscc.darkgem.com/caveconverter/

Footleg

On 17 February 2015 at 14:50, Martin Sluka  wrote:

>
> > 17. 2. 2015 v 13:34, Graham Mullan :
> >
> > One always has to remember, however, that Compass natively stores all
> linear
> > measurements in feet and decimal feet, not in metres. This is the case
> however the
> > data is inputted. I have accidentally ended up with some alarmingly long
> caves before
> > remembering this!
>
> Therion may too. :)
>
> m.s.
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150223/7d15508f/attachment.html>

[Therion] Therion Will Not Start On New XP Install

[Footleg]

We had problems on a recent training course getting Therion installed on
one XP laptop. It turned out in that case that service pack 3 had not been
installed. So that is one thing to check.

Paul
On 15 Feb 2015 17:26, "Nick Bairstow"  wrote:

> Hi, I just re-installed XP Pro on a laptop, updated everything, installed
> Therion and I get the following error.
>
> This application has failed to start because the application configuration
> is incorrect.Reinstalling the application may fix this problem.
>
> I'm running Therion on two other XP machines with no problems.I have
> looked everywhere for an answer with no luck. What have I missed, any ideas.
>
> Thanks,
>
> Nick Bairstow
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[Therion] Pocket Topo Shot Direction question

[Footleg]

Thank you Beat. That explains why I have never seen it in my data. I have
not yet flipped an extended elevation in PocketTopo. Now I can update my
cave converter to handle text export files with these characters knowing
what they are for.

I had an enquiry as to what this converter tool was I an talking about.
Details can be found here for those who are interested:
http://wscc.darkgem.com/caveconverter/

Footleg

On 26 January 2015 at 15:19, Beat Heeb  wrote:

> The ‘<’ character after the trip number means the extended elevation runs
> to the left.
>
> Without the character it runs to the right.
>
>
>
> Regards
>
>
>
> Beat
>
>
>
>
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Footleg
> *Sent:* Monday, 26 January, 2015 00:05
> *To:* List for Therion users
> *Subject:* Re: [Therion] Pocket Topo Shot Direction question
>
>
>
> Thanks. So I think I may have suspected that this option was the cause of
> the problem I was investigating. But it sounds like it is not related. What
> I am actually trying to work out is what is causing the text export file
> from a PocketTopo survey someone sent me to include a < character between
> the trip number [1] and the comment in double quotes. I've not seen this in
> any text files exported before, and I need to know what it indicates so I
> can update the parser in my cave converter program.
>
> Footleg
>
> On 25 Jan 2015 22:05, "Beat Heeb"  wrote:
>
> The direction used for the extended elevation is set by the ‘Flip’ command
> in the drawing context menu.
>
> This completely independent of the shot direction set by the ‘Shot ->’
> command.
>
>
>
> Regards
>
>
>
> Beat
>
>
>
>
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Andrew Atkinson
> *Sent:* Sunday, 25 January, 2015 22:49
> *To:* Therion
> *Subject:* Re: [Therion] Pocket Topo Shot Direction question
>
>
>
> I believe it is the direction used on the extended elevation (from memory)
>
> Andrew
>
> On 25 Jan 2015 21:41, "Footleg"  wrote:
>
> Can anyone tell me what the purpose/use is of the menu item in PocketTopo
> on the data screen which says either 'Shot ->' or 'Shot <-' ?
>
> I see it set to one or the other on my shots depending whether they were
> forward or back shots. But then the shots direction is still indicated
> primarily by the station names in the From and To columns. So I am not
> clear what this menu item does or when I might want or need to use it?
>
> Footleg
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150126/d08e8655/attachment.html>

[Therion] Pocket Topo Shot Direction question

[Footleg]

Thanks. So I think I may have suspected that this option was the cause of
the problem I was investigating. But it sounds like it is not related. What
I am actually trying to work out is what is causing the text export file
from a PocketTopo survey someone sent me to include a < character between
the trip number [1] and the comment in double quotes. I've not seen this in
any text files exported before, and I need to know what it indicates so I
can update the parser in my cave converter program.

Footleg
On 25 Jan 2015 22:05, "Beat Heeb"  wrote:

> The direction used for the extended elevation is set by the ‘Flip’ command
> in the drawing context menu.
>
> This completely independent of the shot direction set by the ‘Shot ->’
> command.
>
>
>
> Regards
>
>
>
> Beat
>
>
>
>
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Andrew Atkinson
> *Sent:* Sunday, 25 January, 2015 22:49
> *To:* Therion
> *Subject:* Re: [Therion] Pocket Topo Shot Direction question
>
>
>
> I believe it is the direction used on the extended elevation (from memory)
>
> Andrew
>
> On 25 Jan 2015 21:41, "Footleg"  wrote:
>
> Can anyone tell me what the purpose/use is of the menu item in PocketTopo
> on the data screen which says either 'Shot ->' or 'Shot <-' ?
>
> I see it set to one or the other on my shots depending whether they were
> forward or back shots. But then the shots direction is still indicated
> primarily by the station names in the From and To columns. So I am not
> clear what this menu item does or when I might want or need to use it?
>
> Footleg
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150125/e25bfae8/attachment.html>

[Therion] Pocket Topo Shot Direction question

[Footleg]

Can anyone tell me what the purpose/use is of the menu item in PocketTopo
on the data screen which says either 'Shot ->' or 'Shot <-' ?

I see it set to one or the other on my shots depending whether they were
forward or back shots. But then the shots direction is still indicated
primarily by the station names in the From and To columns. So I am not
clear what this menu item does or when I might want or need to use it?

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150125/74a19218/attachment.html>

[Therion] Altitude colors range

[Footleg]

Now I have added this into my surveys, I see that the centreline is
rendered as solid lines when you include the centreline (and have not
set the centreline symbol group to be hidden), but if you do not
include the centreline then the survey lines renderer in the scraps
are just dashes at each station rather than complete lines running the
complete distance between pairs of stations. Not a problem, but
curious as to why I get two different styles for cave survey lines.

Then I tried this on my 66km system survey and with centrelines set to
show in my layout, I found metapost used up all the words of memory it
is allowed so I get no output. From my logfile:

Here is how much of MetaPost's memory you used:
 6498 strings out of 6522
 15689 string characters out of 34452
 151 words of memory out of 150
 1389 symbolic tokens out of 16384
 12i,75n,41p,489b,3f stack positions out of 300i,84n,5000p,608b,15f
 10510 string compactions (moved 140463121 characters, 13446441
strings)371 output files written: data.1 .. data.4017

How can I get around this limitation?

Footleg

On 8 January 2015 at 10:28, Footleg  wrote:
> I see it too now. I have not realised you could include just a
> centreline in the map. It shows every survey station and leg in the
> cave, rather than just those included in scraps right? When I add that
> my altitude baseline is set to 0m like yours using 5.3.16
>
> I've not done this before as I had assumed I could only see survey
> sections which were drawn in scraps. I can see how it is useful to be
> able to render centrelines and stations for the entire system
> regardless.
>
> Footleg
>
> On 7 January 2015 at 18:41, Bruce  wrote:
>>>Or maybe I am not understanding what you mean by including the centreline
>>> in the map
>>
>>
>>
>> Like this
>>
>> map DeckExtensionPlanMap -title "The Deck ExtensionUpper
>> LevelsMiddle Earth CaveGreenlink System"
>>
>>  …
>>
>>  36-BigWednesdayPlan at MiddleEarth
>>
>>  36-BigWednesdayPlanCL at MiddleEarth
>>
>> …
>>
>> end map
>>
>>
>>
>> where the contributory maps look like this…
>>
>>
>>
>> map 36-BigWednesdayPlanCL -title "36-BigWednesday centreline Plan"
>> -projection plan
>>
>>   36 #centreline survey
>>
>> endmap
>>
>>
>>
>> map 36-BigWednesdayPlan -title "36-BigWednesday Plan" -projection plan
>>
>>   36-BigWednesdayPlan-s1 #scraps
>>
>>   36-BigWednesdayPlan-s2
>>
>> endmap
>>
>>
>>
>> So what it is looking like, if the contributory maps are all derived from
>> scraps (or maps in turn derived from scraps), then the altitude range is
>> correct.
>>
>> But if there is a map that is centerline derived (ie has no scraps) then the
>> altitude minima is set to zero.
>>
>>
>>
>> One other thing.
>>
>> All my tests so far use survex for loop closure.  I have not tried using
>> Therion loop closure.
>>
>> And all my files are native Therion files – no survex imports.
>>
>>
>>
>> Bruce
>>
>>
>>
>> 
>>
>> From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On 
>> Behalf
>> Of Marco Menchise
>> Sent: Thursday, 8 January 2015 3:05 a.m.
>> To: List for Therion users
>> Subject: Re: [Therion] Altitude colors range
>>
>>
>>
>> I checked and I can confirm what Bruce is saying. If you don't include
>> centerline in map, the altitude range is correct.
>>
>>
>>
>> If you hide the centerline in the layout (leaving it in the map) the
>> altitude range keeps starting from 0 m.
>>
>>
>>
>> Marco
>>
>>
>>
>>
>>
>> On Wed, Jan 7, 2015 at 2:52 PM, Footleg  wrote:
>>
>> I am not seeing this Bruce. I just tested with 5.3.16. My survey imports the
>> centreline from a Survex .3d file however, so that might make a difference?
>> Or maybe I am not understanding what you mean by including the centreline in
>> the map. I turned off the centreline using 'symbol-hide line survey'. If I
>> comment that out in my layout then the centreline is drawn in the map, but
>> my altitude range still covers only the range of my scraps.
>>
>>
>>
>> Footleg
>>
>>
>>
>> On 5 January 2015 at 22:40, Bruce  wrote:
>>
>> OK, the problem is not the previews or the offsets, as it occurs in the map
>> examples below regardless of presence of previews or offsets.
>>
>> What does seem to control whether the altitudes start at zero meters is
>> whether the map definition includes a survey centerline.
>>
>> If part of map definition includes a survey centerline, then altitudes are
>> coloured from zero meters to survey maxima (a bug?).
>>
>> If map definition has no survey centerline as part of it’s definition, then
>> coloured from survey minima to survey maxima (correct behaviour).
>>
>> Hence I find this behaviour manifests in maps in progress, but when they are
>> finished and I (usually) turn off the centerline maps, they correct
>> themselves.
>>
>>  Bruce
>>
>>
>>
>>
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>

[Therion] Altitude colors range

[Footleg]

I see it too now. I have not realised you could include just a
centreline in the map. It shows every survey station and leg in the
cave, rather than just those included in scraps right? When I add that
my altitude baseline is set to 0m like yours using 5.3.16

I've not done this before as I had assumed I could only see survey
sections which were drawn in scraps. I can see how it is useful to be
able to render centrelines and stations for the entire system
regardless.

Footleg

On 7 January 2015 at 18:41, Bruce  wrote:
>>Or maybe I am not understanding what you mean by including the centreline
>> in the map
>
>
>
> Like this
>
> map DeckExtensionPlanMap -title "The Deck ExtensionUpper
> LevelsMiddle Earth CaveGreenlink System"
>
>  …
>
>  36-BigWednesdayPlan at MiddleEarth
>
>  36-BigWednesdayPlanCL at MiddleEarth
>
> …
>
> end map
>
>
>
> where the contributory maps look like this…
>
>
>
> map 36-BigWednesdayPlanCL -title "36-BigWednesday centreline Plan"
> -projection plan
>
>   36 #centreline survey
>
> endmap
>
>
>
> map 36-BigWednesdayPlan -title "36-BigWednesday Plan" -projection plan
>
>   36-BigWednesdayPlan-s1 #scraps
>
>   36-BigWednesdayPlan-s2
>
> endmap
>
>
>
> So what it is looking like, if the contributory maps are all derived from
> scraps (or maps in turn derived from scraps), then the altitude range is
> correct.
>
> But if there is a map that is centerline derived (ie has no scraps) then the
> altitude minima is set to zero.
>
>
>
> One other thing.
>
> All my tests so far use survex for loop closure.  I have not tried using
> Therion loop closure.
>
> And all my files are native Therion files – no survex imports.
>
>
>
> Bruce
>
>
>
> 
>
> From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On 
> Behalf
> Of Marco Menchise
> Sent: Thursday, 8 January 2015 3:05 a.m.
> To: List for Therion users
> Subject: Re: [Therion] Altitude colors range
>
>
>
> I checked and I can confirm what Bruce is saying. If you don't include
> centerline in map, the altitude range is correct.
>
>
>
> If you hide the centerline in the layout (leaving it in the map) the
> altitude range keeps starting from 0 m.
>
>
>
> Marco
>
>
>
>
>
> On Wed, Jan 7, 2015 at 2:52 PM, Footleg  wrote:
>
> I am not seeing this Bruce. I just tested with 5.3.16. My survey imports the
> centreline from a Survex .3d file however, so that might make a difference?
> Or maybe I am not understanding what you mean by including the centreline in
> the map. I turned off the centreline using 'symbol-hide line survey'. If I
> comment that out in my layout then the centreline is drawn in the map, but
> my altitude range still covers only the range of my scraps.
>
>
>
> Footleg
>
>
>
> On 5 January 2015 at 22:40, Bruce  wrote:
>
> OK, the problem is not the previews or the offsets, as it occurs in the map
> examples below regardless of presence of previews or offsets.
>
> What does seem to control whether the altitudes start at zero meters is
> whether the map definition includes a survey centerline.
>
> If part of map definition includes a survey centerline, then altitudes are
> coloured from zero meters to survey maxima (a bug?).
>
> If map definition has no survey centerline as part of it’s definition, then
> coloured from survey minima to survey maxima (correct behaviour).
>
> Hence I find this behaviour manifests in maps in progress, but when they are
> finished and I (usually) turn off the centerline maps, they correct
> themselves.
>
>  Bruce
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Compiling Therion projects from Notepad++

[Footleg]

Searching for one of my own configuration tips in the wiki, I found it
was not there. So I searched my email to find this thread which never
made it onto the wiki. I have now updated the wiki with this
information (and updated the link to where Notepad++ now lives for
downloading it too).

http://therion.speleo.sk/wiki/doku.php/contrib:externaleditors#notepad

Footleg

On 15 January 2013 at 19:41, Bruce  wrote:
>> I find having multiple thconfig files open so I can compile different
> parts of my large cave system project very useful.
>
> Nice
> My usual mode of working is to have many instances of Therion open (a
> thconfig or two, and a few .th2, but rarely a .th), each with only a single
> file open.  All run from the pallet of Therion data files open in Notepad++
> (usually about 10 or many more).
>
> Your idea is a useful addition to this page
> http://therion.speleo.sk/wiki/doku.php/contrib:externaleditors#notepad -
> feel free to edit the page.
>
>>Next I'll see if I can get my batch file to open the output PDF
> automatically in Foxit Reader.
>
> You can probably make use of the file name in your export statement to open
> the output file. "Highlight a file and (relative) path and it opens that
> file in NP++. Alt + F5, Alt + F6".
>
> Bruce
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Altitude colors range

[Footleg]

I am not seeing this Bruce. I just tested with 5.3.16. My survey imports
the centreline from a Survex .3d file however, so that might make a
difference? Or maybe I am not understanding what you mean by including the
centreline in the map. I turned off the centreline using 'symbol-hide line
survey'. If I comment that out in my layout then the centreline is drawn in
the map, but my altitude range still covers only the range of my scraps.

Footleg

On 5 January 2015 at 22:40, Bruce  wrote:

>   OK, the problem is not the previews or the offsets, as it occurs in the
> map examples below regardless of presence of previews or offsets.
>
> What does seem to control whether the altitudes start at zero meters is
> whether the map definition includes a survey centerline.
>
>
>
> If part of map definition includes a survey centerline, then altitudes are
> coloured from zero meters to survey maxima (a bug?).
>
> If map definition has no survey centerline as part of it’s definition,
> then coloured from survey minima to survey maxima (correct behaviour).
>
>
>
> Hence I find this behaviour manifests in maps in progress, but when they
> are finished and I (usually) turn off the centerline maps, they correct
> themselves.
>
>
>
> Bruce
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Bruce
> *Sent:* Sunday, 4 January 2015 10:42 a.m.
> *To:* 'List for Therion users'
> *Subject:* Re: [Therion] Altitude colors range
>
>
>
> Hmm, seems like there is an issue here.
>
> Comparing 5.3.10 map with 5.3.16 map as attached.
>
>
>
>  Not sure if it might be a side effect of something else, as I think the
> colour range is OK sometimes (I think I noticed some irregularities with
> 5.3.15 but assumed I was imagining things at the time) – maybe the preview
> below triggers it?  - I might investigate further if I get time.
>
>
>
> Bruce
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Marco Menchise
> *Sent:* Saturday, 3 January 2015 8:45 a.m.
> *To:* List for Therion users
> *Subject:* [Therion] Altitude colors range
>
>
>
> Hello,
>
> I use to color maps by scrap altitude.
>
>
>
> Lately I noticed Therion color gradient starts from 0 m altitude to
> maximum cave altitude. Because caves don't reach 0 m almost all color range
> is unused and most scraps are colored with similar colors. If I remember
> correctly some time ago Therion used all color range because color gradient
> extended from minimum cave altitude (not 0 m) to maximum.
>
>
>
> Am I missing something? Is there a way to use all available colors?
>
>
>
> Thanks,
>
> Marco
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150107/d0f52d3f/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 123853 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150107/d0f52d3f/attachment.jpg>
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 123727 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150107/d0f52d3f/attachment-0001.jpg>

[Therion] Altitude colors range

[Footleg]

If someone is working on this area, then it would be good to allow the
minimum and maximum altitude to be used for the colour range to be
specified in maps. I currently do this via a hack in my maps, including a
scrap containing two artificial fixed survey stations at the min. and max.
altitudes I want the map to use for colouring. Provided the rest of the
scraps in the map are in this range then the entire map is coloured the
same regardless of which scraps I include. So I can generate a map of part
of the cave with the same colours as the map of the entire cave. Otherwise
maps of small areas of the cave get coloured with very different scrap
colours due to the small altitude range of the scraps in the map.

Footleg

On 5 January 2015 at 22:40, Bruce  wrote:

>   OK, the problem is not the previews or the offsets, as it occurs in the
> map examples below regardless of presence of previews or offsets.
>
> What does seem to control whether the altitudes start at zero meters is
> whether the map definition includes a survey centerline.
>
>
>
> If part of map definition includes a survey centerline, then altitudes are
> coloured from zero meters to survey maxima (a bug?).
>
> If map definition has no survey centerline as part of it’s definition,
> then coloured from survey minima to survey maxima (correct behaviour).
>
>
>
> Hence I find this behaviour manifests in maps in progress, but when they
> are finished and I (usually) turn off the centerline maps, they correct
> themselves.
>
>
>
> Bruce
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Bruce
> *Sent:* Sunday, 4 January 2015 10:42 a.m.
> *To:* 'List for Therion users'
> *Subject:* Re: [Therion] Altitude colors range
>
>
>
> Hmm, seems like there is an issue here.
>
> Comparing 5.3.10 map with 5.3.16 map as attached.
>
>
>
>  Not sure if it might be a side effect of something else, as I think the
> colour range is OK sometimes (I think I noticed some irregularities with
> 5.3.15 but assumed I was imagining things at the time) – maybe the preview
> below triggers it?  - I might investigate further if I get time.
>
>
>
> Bruce
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Marco Menchise
> *Sent:* Saturday, 3 January 2015 8:45 a.m.
> *To:* List for Therion users
> *Subject:* [Therion] Altitude colors range
>
>
>
> Hello,
>
> I use to color maps by scrap altitude.
>
>
>
> Lately I noticed Therion color gradient starts from 0 m altitude to
> maximum cave altitude. Because caves don't reach 0 m almost all color range
> is unused and most scraps are colored with similar colors. If I remember
> correctly some time ago Therion used all color range because color gradient
> extended from minimum cave altitude (not 0 m) to maximum.
>
>
>
> Am I missing something? Is there a way to use all available colors?
>
>
>
> Thanks,
>
> Marco
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150107/4495f8e0/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 123727 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150107/4495f8e0/attachment.jpg>
-- next part --
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 123853 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20150107/4495f8e0/attachment-0001.jpg>

[Therion] Converting Splays Therion to Survex

[Footleg]

Mark, I've copied this reply to the Therion Group. You should join the
group to get replies people might make to the group.

My cave converter application can generate LRUD data from splays to enable
you to view a solid model in Survex. But it does not yet read Therion
format data files. So you are probably bsst converting the data to Survex
format in a text editor. You will have to put 'splays' flags around the
splay legs. It might be easiest to group all the splays in one block at the
end of the file so you do not need to cut and paste lots of splays on/off
lines into a text editor.

Once you have the data in Survex format you can read and write it in Survex
format using cave converter with the lrud argument to generate passage data
(i.e. lrud data in the survex file). Note that cave converter does not yet
read pasage data from Survex files. So any existing passage data blocks in
the input survex file are ignored and not output in the output file. But
new passage data is generated from any splays if you specified the lrud
argument on the command line.

Footleg
On 3 Dec 2014 00:50, "Mark Brown"  wrote:

> Hi chaps
>
> I've got some data that is Therion, which I need to convert into Survex
> (Yes, really, I do!).
>
> The in cave data has been recorded as a series of splays at each station,
> without doing a set of LRUDs first.
>
> Presumably if i create a set of LRUDs of zero length for each leg then
> cave converter would convert it to survex and show the splays...  but the
> cubes function wouldn't work...
> I also wouldn't be able to print out plans with widths on ...
>
> Any suggestions?
>
> Could you remind me of the user group that you recommended too - should I
> post this there?
>
> Thanks
>
> Mark
>
> PS - loads of interest in the Derbyshire course - I'll be in touch
> separately about that.
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20141203/ebcedbe0/attachment.html>

[Therion] PDA

[Footleg]

A search on ebay for 'dell axim pda x51v' with the 'sold items' and
under £30 filters showed that several sold for that price in the past
few weeks. So certainly these come up regularly and sell for a
reasonable price in the UK. Just keep watching out and one will come
up.

Footleg

On 14 October 2014 20:19, Markus Boldt  wrote:
> Many thanks to all for the answers!
>
> I work with Asus A696. It works without any problems since 4 years.
>
> I must say, I havn`t not found “many” Dell Axim or HPs on Ebay. Yes, there
> are some more for over 100€, but that price in inacceptable for that old
> device. 4 others are at an acceptable price in the moment…..Hope, there is
> no other colleague in the moment, who needs one…..
>
>
>
> I hope, there will be a version of Pocketopo not only for Windows mobile.
> Particularly because the Calibration-Funktion of that program. Even if there
> is an Lion-akku in the Distox2 or mµ-sheet in the Distox1, you must
> calibrate the device from time to time.
>
> Greeting
>
> Markus
>
>
>
> Martin: Thanks for advise us of the Panasonic CF18/19. May be interesting.
>
> Von: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] Im 
> Auftrag
> von Martin Sluka
> Gesendet: Sonntag, 12. Oktober 2014 23:47
> An: List for Therion users
> Betreff: Re: [Therion] PDA
>
>
>
> With Axim no any problem.
>
>
>
> What is interesting too: there are plenty of cheap Toughbooks CF-18 and
> CF-19 on eBay.
>
> Odesláno z iPhonu
>
>
> 12. 10. 2014 v 23:20, torstein finnesand :
>
> There has been some minor incidents. We have used them in many caves, since
> DistoX arrived. And are still using them (some without protection)
>
> Torstein
>
>
> Den 12.10.2014 23:04, skrev Martin Sluka:
>
> Hasn't it problem with BT connection? Any Hp I tried had problems with BT.
>
>
>
> 12. 10. 2014 v 22:37, torstein finnesand :
>
>
>
> HP iPAQ 214 (4 inch screen size)
>
>
>
>
>
>
> ___
>
> Therion mailing list
>
> Therion at speleo.sk
>
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] PDA

[Footleg]

There is also Auriga software for Palm OS devices, which has added
vector based sketching and Therion support in recent versions. I've
not played with it for a while as my Palm PDA have poor battery life
now, and I have a couple of Dell Axim 51v PDAs which has always worked
perfectly underground with PocketTopo. But I understand there is a
Palm OS emulator for Android (not free though) which enables Auriga to
run on Android devices. Has anyone on this list tried Auriga, and if
so have you looked at running it on Android?

Footleg

On 12 October 2014 22:46, Martin Sluka  wrote:
> With Axim no any problem.
>
> What is interesting too: there are plenty of cheap Toughbooks CF-18 and
> CF-19 on eBay.
>
> Odesláno z iPhonu
>
> 12. 10. 2014 v 23:20, torstein finnesand :
>
> There has been some minor incidents. We have used them in many caves, since
> DistoX arrived. And are still using them (some without protection)
>
> Torstein
>
>
>
> Den 12.10.2014 23:04, skrev Martin Sluka:
>
> Hasn't it problem with BT connection? Any Hp I tried had problems with BT.
>
> 12. 10. 2014 v 22:37, torstein finnesand :
>
> HP iPAQ 214 (4 inch screen size)
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] metapost error on Windows7

[Footleg]

I have never seen this locking during compile, apart from PDF files. I
am using Therion extensively on Windows.

One case we found on Windows which had us stumped on a training course
we ran was that one Windows user found his PDF file was locked even
after apparently closing the Adobe reader. It turned out to be because
he had file previews turned on in Windows Explorer so it was
generating a rendering of all PDF files in the open explorer Window
and that used the Adobe Reader under the hood so the files were still
locked. Turning off previews in Explorer sorted that one out.

For those who run Therion on Windows and have not already seen the PDF
viewer tip on the wiki, I use Sumatra PDF reader which is the only
reader I have found on Windows which does not lock the PDF file when
it is open in the reader, and that renders the PDF correctly as well.
Using Sumatra I can keep the PDF window open and each time I recompile
my project the PDF display refreshes automatically which is really
handy.

Footleg

On 22 September 2014 17:48, Xavier Pennec  wrote:
> Hi Stacho,
>
> It also looks to me as if there is a lock on some file. It is apparently
> happening during the generation of  small postscript elements (e.g.
> data.4008). I am still trying to reproduce it in a consistent way.
>
> But if nobody else is experiencing it, it  might comes as well from my
> antivirus scanning these bits before they are finished to be dealt with.
>
> Xavier
>
> Le 22/09/2014 18:27, Stacho Mudrak a écrit :
>
> This is really strange... I have experienced similar problem with PDF file
> being locked, even it is not open in Adobe Reader.
> It looks to me, that OS is reading somehow these files (to index them???)
> and for a very small amount of time they are locked.
> May be I am completely wrong, but without being able to reproduce this
> error, I see no way how to debug it...
>
> S.
>
> On 22 September 2014 09:56, Xavier Pennec  wrote:
>>
>> Since I installed the last version of therion, metapost is randomly
>> bugging on writing temporary files with the message
>> "! I can't write on file `'. Please type another file name for input:"
>> As this is blocking therion, I have to kill the compilation windows and
>> retry. It usually reworks after a few try.
>> I tried so see what was wrong in the tmp files with the compile option -d
>> without success so far
>>
>> Does anyone experience the same behavior or does it come from some special
>> feature of my installation?
>>
>> Xavier
>>
>> --
>>>
>>> -
>>> Xavier Pennec
>>> Senior Research Scientist / Directeur de recherche
>>> Asclepios project-team, INRIA Sophia-Antipolis
>>> 2004 Route des Lucioles, BP93
>>> F-06902 Sophia-Antipolis Cedex, France
>>> +33 4 92 38 76 64
>>> +33 6 78 35 16 90
>>> http://www-sop.inria.fr/asclepios/
>>> ---
>>
>>
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
> --
>> -
>> Xavier Pennec
>> Senior Research Scientist / Directeur de recherche
>> Asclepios project-team, INRIA Sophia-Antipolis
>> 2004 Route des Lucioles, BP93
>> F-06902 Sophia-Antipolis Cedex, France
>> +33 4 92 38 76 64
>> +33 6 78 35 16 90
>> http://www-sop.inria.fr/asclepios/
>> ---
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Combining caves using different co-ordinate systems

[Footleg]

I have checked that both my survey files have date and cs declarations
inside centreline blocks. Each file generates the correct position
when I generate a KML from either file alone.
Next I tried to add a cs statement in my thconfig file. This appears
to over-ride the cs I declared in the centreline block. So if I put a
different cs declaration in the thconfig file to the cs declared in
the survey data file, then this results in the kml output putting the
cave in the wrong place.

I have created a bear bones set of examples (attached). The cave
should be on the edge of the open grass area and trees.

thconfig-eur79Only.thc  Puts the cave declared with Eur79 datum in the
correct place.
thconfig-EPSGOnly.thc Puts the cave declared with EPSG:25830 datum in
the correct place.

thconfig-eur79csconfig.thc Declares the cave with Eur79 but specifies
EPSG:25830 in the thconfig, and the cave now appears in the wrong
place.

The other files show various ways of including both caves, and they
are rendered always with one in the correct place and one in the wrong
place.

Footleg
-- next part --
A non-text attachment was scrubbed...
Name: DualCSTests.zip
Type: application/zip
Size: 6821 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140920/1d86b9d3/attachment.zip>

[Therion] Combining caves using different co-ordinate systems

[Footleg]

I had put one cave using a cs and gps fix coordinates into one survey block
in a .th file. Then a second cave using a different cs and gps fix
coordinates in a second .th file.

My project then uses a master.th file which inputs both of these. If I run
my config on either of the individual files then they appear at the correct
place on Google Earth from an output kml file. If I include both caves then
they appear in different places. The one I include first is in the correct
place. If I swap the order they appear in the master.th file then this
confirms the first one is alway put in the correct place, and the second is
positioned using the cs of the first one.

The same in a lox model file (except I cannot confirm which is correct, but
I see them in different places when I give them the same entrance location
to test this).

Footleg
On 19 Sep 2014 14:33, "Andrew Atkinson"  wrote:

> You can use cs in config file, either inside layout, or outside layout
> (most likely what you want to do) to control the output co-ordinate system,
> which I think is what you are trying to do?
>
> Andrew
> On 19 Sep 2014 14:00, "Footleg"  wrote:
>
>> I have been converting a project from an old datum to a more recent
>> one following the issuing of new maps using the newer datum. So all my
>> entrance GPS coordinates changed. I updated the cs statements in my
>> survey data files and my KML output is still in the correct place. So
>> all was looking good. Then I discovered that if I include a survey in
>> the old cs with one using the new cs then Therion appears to treat
>> both caves as having the same cs. Whichever cs is used by the first
>> included cave is applied to subsequent caves too. Is there a way to
>> deal with this?
>>
>> Footleg
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140919/c33ac1b7/attachment.html>

[Therion] Combining caves using different co-ordinate systems

[Footleg]

I have been converting a project from an old datum to a more recent
one following the issuing of new maps using the newer datum. So all my
entrance GPS coordinates changed. I updated the cs statements in my
survey data files and my KML output is still in the correct place. So
all was looking good. Then I discovered that if I include a survey in
the old cs with one using the new cs then Therion appears to treat
both caves as having the same cs. Whichever cs is used by the first
included cave is applied to subsequent caves too. Is there a way to
deal with this?

Footleg

[Therion] What is going on with these survey legs?

[Footleg]

This is a classic problem, and since I ran foul of it in my own cave
data processing software ( http://wscc.darkgem.com/caveconverter/ ) I
have heard of two other cases of cave survey software falling into the
same trap. The answer is to treat the bearings as vector forces and
average the vectors. This works for all cases. I have written a
function (averageCompassBearings) to implement this angle averaging in
the UtilityFunctions.java source file in my Cave Converter (released
under GNU General Public License).

See this article for a discussion of the problem and the maths:
http://stackoverflow.com/questions/491738/how-do-you-calculate-the-average-of-a-set-of-angles

This will give you very similar results to just averaging the bearing
angles when there is no wrap around the 360=0 boundary when the angles
are all within a degree or so of each other. But you get quite
different answers when the angles are well spaced apart. I believe the
average vectors answer is more applicable in the case of bearings. It
is not an issue either way for cave survey cases where I hope the
bearings being averaged are all of very similar values. But in the
case of vector forces pulling on an object, if three equal forces were
pulling at angles of 0, 5, and 180 degrees, then the 0 and 180 vectors
would cancel each other out, and the remaining vector at 5 degrees
would be dominant giving a vector average of 5 degrees. But the simple
mean of the 3 numbers is around 61 degrees, which shows how different
the results of these two averaging methods can be.

Footleg

On 8 September 2014 19:47, Bill Gee  wrote:
> Hello everyone -
>
> I did some skull time on this problem.  I have an idea that might work.  Many
> numbers need to be run on this to prove that it works in all cases.  Would
> some of you take a glance and render an opinion?
>
> This algorithm depends on a floating-point MODulus (or remainder) operation
> which I am not sure exists in most languages.  Also, I use degree measures
> here, but in a real program it would have to be adjusted to (1/2 circle) and
> (1 circle) ... 200 grads or pi radians or whatever.
>
> The starting point is two azimuth readings.  Call them FOR1 and BACK1.
>
> 1) FOR2 = BACK1 + 180
> 2) FOR2 = FOR2 MOD 360.0
> 3) If (FOR1 - FOR2) > 180 then FOR2 = FOR2 + 360.0
> 4) FINAL = ((FOR1 + FOR2) / 2) MOD 360.0)
>
> Thanks - Bill Gee
>
>
> On Saturday, August 16, 2014 04:38:36 Olly Betts wrote:
>> On Thu, Jul 17, 2014 at 09:19:43AM -0500, Bill Gee wrote:
>> > I am struggling with a couple of survey shots that Therion is not
>> > interpretting correctly.  It might be a bug in how Therion averages
>> > forward
>> > and backward compass when the readings are near 360 and 180 degrees.
>>
>> There's a bit of a gotcha when averaging compass readings, due to the
>> wrap-around at 360/0 degrees.
>>
>> For example, if we try to average two readings: 359 and 003, then the
>> correct answer (at least assuming we believe them to be equally
>> accurate) would be 001.  But if we naively sum and divide by the number
>> of readings, we get (359+003)/2 = 362/2 = 181.
>>
>> The same issues affects averaging forward and back sights - the only
>> different is that the back sights get altered by 180 degrees before
>> averaging.
>>
>> I've not tried to find where in therion this is implemented, but it
>> appears to explain what you are seeing here - assuming therion subtracts
>> 180 from the backcompass, it would calculate (359 + (181 - 180)) / 2 =
>> 180 for the first case, and (359.5 + (180 - 180)) / 2 = 179.75 for the
>> second.
>>
>> > One of the shots (B11-B12) has compass readings of exactly 0 and 180.
>> > This
>> > shot displays correctly on the map.
>>
>> In that care, the average would be (0 + (180 - 180)) / 2 = 0, so this
>> case also fits my hypothesis.
>>
>> Survex is careful to get these cases right, but unfortunately it seems
>> that when therion uses Survex to process the centreline data, it does
>> the backreading averaging itself before it passes data to Survex, so
>> that doesn't provide a way to work around this problem.
>>
>> You could put the centreline data in a .svx file, and tell therion to
>> process that and use the .3d file.
>>
>> Cheers,
>> Olly
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Symbol different in legend to survey

[Footleg]

Nice drawing Jenny. You appear to be using similar tricks to me to try
to join scraps along curved pitch lines so that in colour by altitude
the colour boundaries are hidden along drawn boundaries in the cave.
I've been meaning to write a wiki page about how I do this. Nice to
see I am not the only one.

Footleg

On 9 July 2014 06:47, Jenny Black  wrote:
> Hi,
>
> Sorry, I should have replied sooner. You are both right of course, the
> symbols are the same size. It was an optical illusion due to the shape of
> some of the area fills in the original survey
> (http://expo.survex.com/expoimages/surveys/107-plan-2013-draft3.pdf), and
> once I could see it there I convinced myself it was true in the cut down
> example as well. Sorry to have wasted your time!
>
> Thanks,
> Jenny
>
>
>
> On 26 June 2014 20:28, Stacho Mudrak  wrote:
>>
>> Hi Jenny,
>>
>> this is magnification from your PDF file. Legend and map. To me, symbols
>> look to be in the same scale. I am probably getting something wrong.
>>
>> S.
>>
>>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] How to locate points on the surface above a surveystation?

[Footleg]

If you generate kml output then you can read the lat-lon for any station
from that.
If you generate survex 3d output then you can read the coordinates of any
station in the Aven viewer (part of the Survex install) in the grid
coordinate system you defined for the data.

Footleg


On 3 June 2014 07:42, Bruce  wrote:

>  JP
>
> As a hack, how about temporarily making the survey station near the debris
> an entrance.  Then an export to a cave-list will give you the coordinates
> directly.
>
> Eg
>
> export cave-list \
>
> -location on \
>
> -surveys off \
>
> -output ../Output/MiddleEarthcaves.html
>
>
>
> Or of you use .kml extension you get a Google Earth file directly.
>
> I’m assuming you want the easiest way to walk to the surface location
> directly above the cave, and have a gps unit into which you can enter these
> as way points.  Re-reading you question that might not be what you want.
>
>
>
> There might be other approaches using continuation flags, and or obtaining
> the coordinates from an sql export or from a model export to .3d and use
> Aven to obtain coordinates.
>
>
>
> Bruce
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *McLendonJP at aol.com
> *Sent:* Tuesday, 3 June 2014 9:17 a.m.
> *To:* therion at speleo.sk
> *Subject:* [Therion] How to locate points on the surface above a
> surveystation?
>
>
>
> I would appreciate any suggestions regarding the best (easiest, quickest)
> way to locate points on the surface that directly overlie survey stations
> in the cave. For example, suppose we find a place in the cave with surface
> debris and would like to examine the surface directly above for an entrance
> or dig. The ideal solution would allow me to input surface survey data in
> the field using a laptop and would generate an azimuth and distance from
> the last station to the desired point. I've sometimes overlayed the cave
> map or lineplot onto a topo or satellite image to identify the general
> area, but I'm looking for a much more precise solution. Currently, I survey
> overland from the entrance toward the area overlaying the station I want to
> get above. As I get close, I temporarily rename the last surface survey
> station to the name of the station in the cave below. This tells Therion
> that I've closed a loop and it gives me the closure error in all three
> axes. The x and y axis tell me how close I am, and I can guesstimate an
> approximate azimuth for the next shot to get closer. This eventually gets
> me close, but it is subject to blunders and overly time consuming. Is there
> a better way, perhaps through some function of Therion with which I am
> unfamiliar? Thanks for any ideas.
>
>
>
> JP
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140603/7b92d0d0/attachment.html>

[Therion] Selective display of survey lines

[Footleg]

I would certainly suggest that some sort of diveline symbol is used, as
that is really what you are wanting to indicate. Then you can turn off all
survey lines (which just happen to correspond to the dive line position in
this case).

Footleg
On 20 May 2014 22:24, "Steve Clark"  wrote:

> On a related note to Alvaro's questions regarding show and hide of survey
> lines, I'm looking for some advice on the best way to handle the selective
> displaying of some survey lines, but not others.
>
> We have a project surveying a mainly submerged (diving) cave. The vast
> majority of our survey stations and connecting lines are an actual
> continuous physical line in the cave (say 300 stations). Some stations
> (maybe 50) do not have physical lines connecting them (e.g. gaps/jumps in
> the line and dry disto survey).
>
> We would like to be able to :
>
> 1. Produce a map with with no lines at all (seems easy, use 'symbol-hide
> line survey' & 'symbol-hide point station' )
> 2. Produce a map with only the physical lines shown, but not the other
> survey lines. This is as a resource for divers to show the line
> configuration and navigation etc. but not the other survey information.
>
> What is the best way to achieve 2? I've considered making a user-defined
> line type 'u:caveline' and drawing it in all the scraps where submerged
> line exists. Then hide all survey lines and stations. This would be
> laborious but may give most flexibility.
>
> Is this the best way or can anyone suggest an alternative approach?
>
> Regards,
>
> Steve Clark
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140521/ff357f58/attachment.html>

[Therion] New release of Cave Converter

[Footleg]

A new version (20140412) of my Cave Converter tool is now available. It
converts between various cave survey file formats. Enables users of DistoX
devices to get their existing data into PocketTopo, and their new survey
data out of PocketTopo and into Survex format. Plus enables migrating
survey data from one program to another.

Help and the download link can be found on the Cave Converter home page.
Source code is available under a GNU GPLv3 license.
http://wscc.darkgem.com/caveconverter/

A summary of the changes in this release:
- Adopted JScience.org libraries for handling measurements, and implemented
length measurements
  as unitised lengths rather than plain decimal values.
- Added support for reading Compass format survey data files.
- Added substitution of illegal characters in series and station names to
Survex format output.
  Compass files allow various punctuation characters in series and station
names, which are not
  allowed in Survex format data files. These will be substituted by an
underscore character followed
  by a two letter code indicating the character which was substituted (e.g.
'!' becomes '_ex').
- Added additional command line options:
  - splays/nosplays: Survex writer and Toporobot writer now have option to
not output splays.
  - lrud: Option to generate LRUD data from splays (can be used on any
conversion).
- Added rounding of LRUD values to 2 decimal places in the Survex file
writer.
- Changed LRUD generation to better select the best splay for each
dimension, and to calculate
  the distance for the LRUD dimensions based on the angle of the splay to
the passage direction
  instead of using the total length of the splay. The splay selected when
there is a choice is now
  the splay giving the biggest dimension in the direction of the LRUD
measurement rather than using
  the splay closest to the compass bearing of the passage dimension
measurement direction. Passage
  direction is now calculated from the average bearing of the forward leg
and the previous leg
  arriving at the station. When more than two legs join at a station then
the previous leg will be
  the one with the closest bearing to the bearing of the onward leg.
- Splays fired as back shots are now excluded from LRUD generation.
- Splays are no longer removed from the output when used to generate LRUD
dimensions.
- The Survex writer now groups passage data from LRUD dimensions into
blocks of readings corresponding
  to the survey legs in the file (previously one block of passage data was
output per series with all
  stations listed with no respect for their connectivity).
- Added duplicate and surface flags to leg class, and added reading of
flags to Survex parser and writing
  them to Survex writer.
- Made the logging output less verbose, and fixed the survey summary
details log output to include inner series.

Bugs fixed:
- Fixed case sensitivity bug in Toborobot file generation which left series
unlinked if series or
  station names did not have identical case.
- Fixed bug in PocketTopo parser which repeated the station name given to
the 'to' station for a splay
  leg when the splays were not all located together in the survey.
- Fixed bug where compass calibration was used instead of declination
calibration in PocketTopo parser,
  Survex parser and Survex writer.
- Added date reading to Survex parser.
- Fixed bug in utility function to calculate the average of a set of
compass bearings (thanks to Peter Kellaway
  for pointing me to a much more robust and elegant solution). This bug
does not affect the use of the function
  in previous versions (where it was only used to convert PocketTopo triple
leg readings into one average leg)
  but it did show up in the new LRUD generation code when calculating the
average bearing of two legs either
  side of a station when the passage went round a sharp bend.
- Fixed bug in Toporobot Writer which caused passage dimensions data to be
output on the wrong station
  (LRUD values for the 'from' station of each leg were being put on the
'to' station of each leg).
- PocketTopo file reader no longer reorders the splay legs for each station
(something which used to happen
  due to the old code which sorted splays into groups for L,R,U,D
measurements in this reader).

Bug reports and requests to support other formats always welcomed.

Enjoy!

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140413/61a93c10/attachment.html>

[Therion] PDA

[Footleg]

I think PocketTopo requires Windows Mobile 5 or later.

The most popular choice among UK cavers is the Dell Axim X51v. The 'v' on
the end of the model name is important, as it means is has a 640x480
resolution screen which makes a big difference. the X51 only has 320x240.
These are easy to find on eBay for not much money. I have seen people using
Fujitsu ruggedised PDAs and HP PDAs too. The HPs seem to more often have
issues with the bluetooth connection dropping. Apart from the screen
resolution, the other great feature of the Dells is the replaceable
battery. So you can buy larger batteries which can run them for around 24
hours continuous use. I use an Aquapac case to waterproof the PDA. Others
prefer rigid boxes (Otterbox?).

Footleg


On 11 April 2014 15:45, Markus Boldt  wrote:

> Hello,
> has anyone a list of PDA mobiles, which are able to work PocketTopo? I
> have an ASUS MyPal 696 with Win mobile 6.0. On this device PocketTopo is
> working. On another device HP AXIM with Win CE 3.0 it is not working.
> Thank you
> Regards
> Markus
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140411/524cb83c/attachment.html>

[Therion] Drawing for generating outputs at multipledifferentscales

[Footleg]

Turns out it was just label lines with text set to xl size which were
appearing at 1:5000. But the text was rendering smaller than xl because my
lines were not that long.

Having played with label lines a bit more I understand how they work now.
What I don't like is how the text character spacing gets wider when the
line is longer than is needed for the text when rendered at the specified
size. What I would like is an option to specify that the text should shrink
to fit the line when the line is shorter than the text would be at the
scale specified, but not be stretched out when the line is too long. That
way I could put my labels on long lines and not see them stretched too much
at more detailed scale rendering (1:1000), but have them shrink to stay
within the bounds of the line ends when rendering at much less detailed
scales (1:5000).

Footleg


On 4 March 2014 06:29, Bruce  wrote:

>   >Playing with the scale layouts, I notice that label lines still
> display text at 1:5000, but label points do not.
>
> That seems odd.
>
>
>
> >It also appears that label lines stretch the text to match the length of
> the line regardless of the font scale set in the options for the label
> line.
>
> That is my understanding as I described here
> http://therion.speleo.sk/wiki/doku.php/drawingchecklist#lines
>
>
>
> >I was hoping there would be a way to set text so that if the font size
> makes the text size shorter than the line when the text would not stretch
> out along the full line length, but if the text scale made it larger than
> the line length then it would be limited to the length of the line. This
> would prevent text growing to be excessively large and run over the cave
> passage, but at scales where smaller text scales are set it is not
> stretched out so much along the line. Is something like this possible?
>
> Not as far as I know.  The text should only overwrite cave passage if the
> line crosses the passage or if the line is very close to the passage.  The
> maximum text height is controlled by -scale xs to xl, so you have very good
> control of that.
>
> Once I figured out how it works I decided I like the behavior of 'line
> label';
>
> -you set the (maximum) text size, and the text path and length exactly
> where you want it
>
> -if the text won't fit its size is reduced until it does.
>
>
>
> What I have found, if the scales are not too divergent, the desirable text
> path length is about the same regardless of the scale.
>
> Where this doesn't work for me I use 'point label'.
>
>
>
> Bruce
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140304/fac9b734/attachment.html>

[Therion] Drawing for generating outputs at multiple differentscales

[Footleg]

Playing with the scale layouts, I notice that label lines still display
text at 1:5000, but label points do not. It also appears that label lines
stretch the text to match the length of the line regardless of the font
scale set in the options for the label line. I was hoping there would be a
way to set text so that if the font size makes the text size shorter than
the line when the text would not stretch out along the full line length,
but if the text scale made it larger than the line length then it would be
limited to the length of the line. This would prevent text growing to be
excessively large and run over the cave passage, but at scales where
smaller text scales are set it is not stretched out so much along the line.
Is something like this possible?

Footleg


On 3 March 2014 18:56, Bruce  wrote:

>   Footleg
>
> This was one of my early challenges shortly after discovering Therion, and
> it crops up from time to time on this forum.
>
> I have decided that with 'draw once, use many times' I am limited to about
> half an order of magnitude difference in scales (ie 1:500 to 1:2000) to get
> label spacing and symbol placement that is more or less OK at a range of
> scales.
>
> Personally, once I get to 1:5000 I pretty much turn off all symbols.
> http://therion.speleo.sk/wiki/doku.php/templates
>
> Judicious use of text scales xs, s, m, l, xl allows one to crudely hide
> minor text at smaller scales.
>
> You can use base-scale to globally reduce all text and symbol sizes.
>
> Thomas Holders examples show how symbols can be made to plot to suit the
> scale. Ie hide smaller symbols.
> http://therion.speleo.sk/wiki/doku.php/metapost?s[]=thomas#scale_dependant_visualization_of_symbols
>
>
>
> People have proposed various 'dual scrap' scenarios, but it seems to
> defeat what simplicity Therion has :)
>
>
>
> You could use 'revise' for each symbol, but I think madness would lie down
> that route.
>
>
>
> Check the wiki.
>
>
>
> Bruce
>
>
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140303/a0bb3529/attachment.html>

[Therion] Drawing for generating outputs at multiple differentscales

[Footleg]

Thanks Bruce,

Those templates are immensely useful. I looked at them some years ago but
at the time did not know enough to understand how to use them. A fresh look
has got me up and running with a significantly better rendering of 1:5000
scale. I will probably spend far too long playing with them now rather than
actually drawing anything new to be sure I have things working in my scraps
properly before I spend a load of time drawing up a load more.

Footleg


On 3 March 2014 18:56, Bruce  wrote:

>   Footleg
>
> This was one of my early challenges shortly after discovering Therion, and
> it crops up from time to time on this forum.
>
> I have decided that with 'draw once, use many times' I am limited to about
> half an order of magnitude difference in scales (ie 1:500 to 1:2000) to get
> label spacing and symbol placement that is more or less OK at a range of
> scales.
>
> Personally, once I get to 1:5000 I pretty much turn off all symbols.
> http://therion.speleo.sk/wiki/doku.php/templates
>
> Judicious use of text scales xs, s, m, l, xl allows one to crudely hide
> minor text at smaller scales.
>
> You can use base-scale to globally reduce all text and symbol sizes.
>
> Thomas Holders examples show how symbols can be made to plot to suit the
> scale. Ie hide smaller symbols.
> http://therion.speleo.sk/wiki/doku.php/metapost?s[]=thomas#scale_dependant_visualization_of_symbols
>
>
>
> People have proposed various 'dual scrap' scenarios, but it seems to
> defeat what simplicity Therion has :)
>
>
>
> You could use 'revise' for each symbol, but I think madness would lie down
> that route.
>
>
>
> Check the wiki.
>
>
>
> Bruce
>
>
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Footleg
> *Sent:* Tuesday, 4 March 2014 7:01 a.m.
> *To:* List for Therion users
> *Subject:* [Therion] Drawing for generating outputs at multiple
> differentscales
>
>
>
> Now that I have enough knowledge to really start drawing up my large
> project cave systems, I am discovering that it is difficult to draw scraps
> in a way which renders nicely at different scales. I want to be able to
> produce a very detailed survey (using a scale of around 1:500) but also to
> output a complete system drawing at a scale more suited to a large map (say
> 1:5000). I find symbols getting rendered larger than the passage widths
> (which seems odd as unless people have much larger passages than me in
> their caves, I would expect symbols to be limited to a sensible scale for a
> typical large passage, or omitted?). But also text labels are so large that
> they obscure entire areas of the cave at the 1:5000 scale.
>
>
>
> Any tips and tricks for how to draw once, use twice? Or do I really need
> to maintain two copies of every scrap? Is there a way to draw some detail
> on a scrap for 1:5000 type scale, and then augment it with fine details for
> rendering at 1:500 by adding a second scrap for the labels and symbols?
>
>
>
> Footleg
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140303/87939644/attachment.html>

[Therion] th2 files don't change after loop closure

[Footleg]

The lines and points in your drawing are positioned as you drew them. If
you change the xvi file or background image then you will see that changed
in the drawing editor, but it will not move your drawn lines and points to
match in the editor. Only the rendered output from therion will reflect the
changes to the centreline.

If you really want to edit the drawing based on the changed centreline when
you need to edit the drawing yourself. But this is not necessary unless the
distortion in your output therion rendered maps to too bad to look right.
Usually you would keep the original xvi file you drew against for that
drawing and let Therion distort the survey to match the updated centreline
when you render the maps.

Footleg


On 25 February 2014 18:11, Tomek Chojnacki wrote:

> Hi,
>
> After I closed a loop in a cave the background image (centerline from
> xvi file) changed, but all "drawings" (survey station points and walls
> lines) stayed in place.
> Does anyone have an idea why it happens and how I can change it?
>
> Thx in advance,
> Tomek
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140226/6a387088/attachment.html>

[Therion] Wish84

[Footleg]

I have been using Therion on Windows 7 over several recent versions
including the very recent release and not seen this problem. I am running
under a user account which has administrator privileges which might make a
difference?

Footleg


On 25 February 2014 12:29, Markus Boldt  wrote:

> Hi,
>
> what I want to ask is:
>
> since I use Win7, every time I start Therion first there comes a message
> that WISH84.EXE should start. And I see, I must allow it, otherwise therion
> don`t starts. What is that? And is it possible, if it must be, that there
> is an approach that therion starts without that message?
>
> Markus
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140225/6deb42e6/attachment.html>

[Therion] Importing Compass files

[Footleg]

Is this a short term need Graham? I've been planning to add Compass format
reading/writing and Therion writing to me cave data converter for a while.
It might be another while before I get it done, but it is useful to know
what there is a need for as it helps me chose what to prioritise.

Footleg


On 18 January 2014 17:03, Graham Mullan  wrote:

>  Jonny Prouty wrote:
>
> Hi Graham,
>
> You can import a Compass PLT file directly into Therion, but not a DAT as
> far as I know.
>
> Best regards,
>
> Jonny
>
> Thanks Jonny, I assume that would be by using similar syntax to that used
> to
> import Survex.3d files. However, as I would need to firstly write a project
> level .dat file in order to include the necessary co-ordinate information
> before generating the plt file, that makes it no simpler than my 'quick and
> dirty' fix of importing the original .plt file into Survex and then
> importing the resultant .3d file into Therion.
>
> This also has the advantage of consistent syntax in my Therion file making
> it easier to see errors.
>
> Graham
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140119/1bb478b7/attachment.html>

[Therion] Compatibility with Survex

[Footleg]

Thanks Bruce.

Just to be completely clear in case anyone is confused, the fix which Bruce
has documented on the wiki is for when Therion is using Survex to generate
centreline coordinates from survey data entered into Therion project files.
My 'generate the 3d file using the -v7 argument' fix is for projects where
you import an already generated 3d file into the Therion project to define
the survey centreline (e.g. Within the 'survey' block: import
West_Kingsdale_System.3d -surveys use -cs OSGB:SD  )

Footleg



On 15 January 2014 17:46, Bruce  wrote:

>  Graham
>
> The Windows solution is to either install Survex 1.2.6 (I think) which
> produces –v7 format .3d files, or
>
> use a current version of Survex and tell it to produce –v7 format, either
> Footleg’ sway or as I just added to the wiki
>
>
> http://therion.speleo.sk/wiki/doku.php/faq#how_to_pass_survex_command_line_parameters_using_therion
>
>
>
> Bruce
>
>
>  --
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Graham Mullan
> *Sent:* Thursday, 16 January 2014 3:49 a.m.
> *To:* therion at speleo.sk
> *Subject:* [Therion] Compatibility with Survex
>
>
>
> In the latest project in which I am involved, I am having to import data
> from Survex (actually from Compass via Survex but that's another story!).
> This requires importing survex 3d files. The problem that I have is that
> .3d files generated in the most recent iterations of Survex cannot be read
> by Therion. I had the same problem some years back & eventually they caught
> up with each other, but it seems that the Survex format has changed too
> much once again.
>
>
>
> Can this be rectified, please 'cos it's a pain in the bum.
>
>
>
> Graham
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140115/67896c23/attachment.html>

[Therion] Compatibility with Survex

[Footleg]

Hi Graham,

I have the same scenario (some of my Therion projects import a Survex 3d
file to define the centreline. The easiest solution is to use the version
switch when generating the 3d files to generate the 3d file version which
Therion can read. I wrote a batch file with the following line to do this
for my main project:
"C:\Program Files (x86)\Survex\cavern.exe" -v7 mycavedata.svx

Other more technical solutions may enable Therion to read the newer format
3D files (I expect Wookey is already typing something about the Debian
version as I write this!)

Footleg


On 15 January 2014 14:48, Graham Mullan  wrote:

>  In the latest project in which I am involved, I am having to import data
> from Survex (actually from Compass via Survex but that's another story!).
> This requires importing survex 3d files. The problem that I have is that
> .3d files generated in the most recent iterations of Survex cannot be read
> by Therion. I had the same problem some years back & eventually they caught
> up with each other, but it seems that the Survex format has changed too
> much once again.
>
> Can this be rectified, please 'cos it's a pain in the bum.
>
> Graham
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20140115/ae5d7d7f/attachment.html>

[Therion] PDF display

[Footleg]

I see now why I did not upload the example source before. It was using a
compiled Survex .3d file as the source of the survey station positions.

I have sorted that out now, with the required fragment of the cave used in
the example now included in the .th file. The example source project for my
overlapping areas is now in a zip file linked from the end of that section
on the wiki:
http://therion.speleo.sk/wiki/doku.php/contrib:externalviewers#examples_of_rendering_differences_between_pdf_viewers

Footleg



On 15 December 2013 22:57, Footleg  wrote:

> Ah, that makes much more sense. I'll see if I can find the once from my
> examples. They will be somewhere as I never delete anything!
>
> Footleg
>
>
> On 15 December 2013 21:54, Wookey  wrote:
>
>> [bloody top-posters - rearranging to make sense]
>>
>> Footleg [2013-12-15 21:29 +] wrote:
>> > Wookey wrote:
>> >> On 15 December 2013 19:30, Bruce <[1]bruce at tomo.co.nz> wrote:
>> >
>> >>> [2]
>> http://therion.speleo.sk/wiki/doku.php/contrib:externalviewers#examples_of_r
>> >>> endering_differences_between_pdf_viewers and the commentary above it.
>> >>
>> >> Bruce - that's a very handy page. But it's missing the test therion
>> >> source you used to do the test.
>> >
>> >And as for the Therion source I used to render these, it would have
>> been
>> >whatever the current Windows executable was current at the date I
>> put them
>> >onto the wiki (the wiki history should be able to tell you that).
>>
>> You misunderstand. I don't mean the source code for there therion
>> program, I mean the .th/th2/thconfig source used to generate the images.
>> That's the bit that would make it easy for someone else to run the same
>> tests.
>>
>> Wookey
>> --
>> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
>> http://wookware.org/
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131216/7d1ed06a/attachment.html>

[Therion] PDF display

[Footleg]

Ah, that makes much more sense. I'll see if I can find the once from my
examples. They will be somewhere as I never delete anything!

Footleg


On 15 December 2013 21:54, Wookey  wrote:

> [bloody top-posters - rearranging to make sense]
>
> Footleg [2013-12-15 21:29 +] wrote:
> > Wookey wrote:
> >> On 15 December 2013 19:30, Bruce <[1]bruce at tomo.co.nz> wrote:
> >
> >>> [2]
> http://therion.speleo.sk/wiki/doku.php/contrib:externalviewers#examples_of_r
> >>> endering_differences_between_pdf_viewers and the commentary above it.
> >>
> >> Bruce - that's a very handy page. But it's missing the test therion
> >> source you used to do the test.
> >
> >And as for the Therion source I used to render these, it would have
> been
> >whatever the current Windows executable was current at the date I put
> them
> >onto the wiki (the wiki history should be able to tell you that).
>
> You misunderstand. I don't mean the source code for there therion
> program, I mean the .th/th2/thconfig source used to generate the images.
> That's the bit that would make it easy for someone else to run the same
> tests.
>
> Wookey
> --
> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131215/2bb00f14/attachment.html>

[Therion] PDF display

[Footleg]

And as for the Therion source I used to render these, it would have been
whatever the current Windows executable was current at the date I put them
onto the wiki (the wiki history should be able to tell you that). Not that
I think it will make any difference between most recent builds of Therion.
It was the differences in the PDF viewers which the renders illustrate,
rather than differences in Therion builds. I would expect the current
latest release of Therion renders exactly the same PDFs.

Footleg


On 15 December 2013 19:30, Bruce  wrote:

>
> http://therion.speleo.sk/wiki/doku.php/contrib:externalviewers#examples_of_r
> > endering_differences_between_pdf_viewers and the commentary above it.
>
> > Bruce - that's a very handy page. But it's missing the test therion
> source you used to do the test. If you could add that, then others could
> do other tests, on later versions, and on linux viewers, for example.
>
>
> Wooky, I think those are Footleg's examples.
>
> I put a complete sample dataset in
> http://therion.speleo.sk/wiki/doku.php/examples#all_areas_all_symbol_sets
> some time ago. An example attached.
>
> It shows all areas (as at Nov 2012) overlaid with each other and various
> lines and symbols in each of the symbol sets - and labelled as well.  It
> also indicates the drawing order.
>
> It is messier than Footleg's example, but perhaps more comprehensive.
>
> Bruce
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131215/49f8a9f8/attachment.html>

[Therion] PDF display

[Footleg]

Thanks Martin,

I sent my earlier reply from my phone which had not picked up Bruce's reply
at that time. So I did not know the question had been answered. Interesting
info about that PDF reader bug. I had not seen that before. The example
renderings on the wiki from various readers were generated and put on the
wiki by me, so I knew how things looked. I just did not know why the Adobe
Reader rendered them like that before.

Footleg


On 14 December 2013 21:28, Martin Sluka  wrote:

> Footleg, read, please, that f… wiki first  :). There is exact analysis of
> this problem and it is bug (reported) in Apple PDF rendering engine. PDF
> viewers which use this engine render PDFs generated by Therion incorrectly.
>
> m.
>
>
> Dec 14, 2013 v 9:48 PM, Footleg :
>
> I bet one pdf will show the line under the boulders and the other will not.
>
>
> Martin Sluka - Studio Sluka
>
> prodej Hahnemühle DFA
> tisk fotografií, reprodukcí a volné tvorby
>
> Na Rovnosti 2692/21
> 130 00 Praha 3
> tel.: +420 603513640
> mail: martinsluka at mac.com
> web: http://www.piezografie.cz
>
>
>
>
>
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131214/6a91788f/attachment.html>

[Therion] PDF display

[Footleg]

I am almost certain that this is one pdf reader rendering transparency, and
one cannot handle it. The boulders are partly transparent in the Therion
generated pdf, so in the reader which can render this, they will appear
darker due to the passage background colour showing through from underneath
them. Try drawing a border line though the area of boulders but under them
in the scrap ordering. I bet one pdf will show the line under the boulders
and the other will not.

Footleg
On 13 Dec 2013 15:12, "Graham Mullan"  wrote:

> I have just noticed that Adobe Acrobat and the (unnamed) pdf viewer
> currently opening from Firefox on this machine render coloured files very
> differently. It's not just that the tones are different, but, for example,
> in Acrobat boulders and the passage containing them are the same shade. In
> the other viewer the boulders render a darker tone than the remainder of
> the
> passage. Same goes for calcite flows, though not, seemingly, for sand.
>
> Graham
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131214/c699b3be/attachment.html>

[Therion] Therion et al on Win 7 or 8.1

[Footleg]

I should add that I use the Sumatra PDF reader on Windows as it is the only
PDF reader I have found on Windows which correctly renders my Therion
generated PDFs without locking the file. So I can recompile my projects
without needing to close the PDF viewer and the PDF is refreshed in the
Sumatra window automatically, making for a much smoother workflow.

Footleg


On 4 December 2013 10:07, Footleg  wrote:

> I have been using most of those applications on Windows 7 on both 32bit
> and 64bit machines with no problems for several years. My recent upgrade of
> a laptop to Windows 8 resulted in me being unable to run either Aven (the
> Survex model viewer) or Loch. But the recent free upgrade to Windows 8.1
> fixed both those issues for me (an some other graphics rendering
> applications which had the same issue of crashing on launch). So now I am
> seeing no issues with any of these applications on Windows 8.1 (32 bit) on
> the laptop.
>
> Footleg
>
>
> On 4 December 2013 07:26, Bruce  wrote:
>
>>  I’m staring down the barrel of having to migrate away from Windows XP.
>>
>>
>>
>> To help me get started on the decision making process, are there any
>> tales of terror or reassurance from the Therion family of application users
>> with Win7 or Win8.1?
>>
>>
>>
>> To name a few applications that need to integrate well,  a text editor
>> (in my case Notepad++), Therion, Survex, PocketTopo, Topparser and Foxit or
>> Adobe pdf readers.
>>
>>
>>
>> For example Michael had (has?) a problem where Win7 will not open
>> thconfig files from the os explorer window, whereas windows xp works fine.
>> I think it gets stuck with wish84 as I mentioned on
>> http://therion.speleo.sk/wiki/doku.php/windows
>>
>>
>>
>> Bruce
>>
>>
>>
>>
>>
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131204/83d6ff11/attachment.html>

[Therion] Therion et al on Win 7 or 8.1

[Footleg]

I have been using most of those applications on Windows 7 on both 32bit and
64bit machines with no problems for several years. My recent upgrade of a
laptop to Windows 8 resulted in me being unable to run either Aven (the
Survex model viewer) or Loch. But the recent free upgrade to Windows 8.1
fixed both those issues for me (an some other graphics rendering
applications which had the same issue of crashing on launch). So now I am
seeing no issues with any of these applications on Windows 8.1 (32 bit) on
the laptop.

Footleg


On 4 December 2013 07:26, Bruce  wrote:

>  I’m staring down the barrel of having to migrate away from Windows XP.
>
>
>
> To help me get started on the decision making process, are there any tales
> of terror or reassurance from the Therion family of application users with
> Win7 or Win8.1?
>
>
>
> To name a few applications that need to integrate well,  a text editor (in
> my case Notepad++), Therion, Survex, PocketTopo, Topparser and Foxit or
> Adobe pdf readers.
>
>
>
> For example Michael had (has?) a problem where Win7 will not open thconfig
> files from the os explorer window, whereas windows xp works fine.  I think
> it gets stuck with wish84 as I mentioned on
> http://therion.speleo.sk/wiki/doku.php/windows
>
>
>
> Bruce
>
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131204/524536e9/attachment.html>

[Therion] equate to non-existant station does not raise error

[Footleg]

That should have said 'not used in any fix or leg'
On 30 Nov 2013 09:53, "Footleg"  wrote:

> Does the log file contain a warning? I thought that it was using Survex
> under the hood, and that warns of stations referred to but not used in and
> fix or leg.
> On 29 Nov 2013 20:07, "Bruce"  wrote:
>
>>  This may have been raised before.
>>
>>
>>
>> If a typing error is made in a station equate statement, no error is
>> raised.
>>
>> For example in the following station kb51.29 at kb does not exist,
>> therefore the loop is not closed as the user intended.
>>
>>
>>
>>equate kb51.29 at kb kb51.29 at 57
>>
>>
>>
>> Can an error be raised in this circumstance please.
>>
>>
>>
>> Regards
>>
>> Bruce Mutton
>>
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>>
>>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131130/83d22ddf/attachment.html>

[Therion] equate to non-existant station does not raise error

[Footleg]

Does the log file contain a warning? I thought that it was using Survex
under the hood, and that warns of stations referred to but not used in and
fix or leg.
On 29 Nov 2013 20:07, "Bruce"  wrote:

>  This may have been raised before.
>
>
>
> If a typing error is made in a station equate statement, no error is
> raised.
>
> For example in the following station kb51.29 at kb does not exist, therefore
> the loop is not closed as the user intended.
>
>
>
>equate kb51.29 at kb kb51.29 at 57
>
>
>
> Can an error be raised in this circumstance please.
>
>
>
> Regards
>
> Bruce Mutton
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[Therion] 3d Animation from Therion

[Footleg]

Now I am on the computer where I was playing with these VRML models, I
can confirm that the viewer I was using was ParaView
http://paraview.org/

I've just checked, and it can export to POV-Ray format, the open
source ray tracing software which can be used to produce very high
quality rendering.

Footleg

On 11 October 2013 19:37, Wookey  wrote:
> +++ Footleg [2013-10-11 08:24 +0100]:
>>I used the vrml export from Loch to produce a 3D model file which was
>>suitable to get 3D printed. The article about it (written by Mike Bedford,
>>who got the printing done) is in the latest issue of Descent magazine. I
>>could import that model file into other 3D modelling software, so perhaps
>>there is an application out there which can convert it?
>
> 'meshlab' looks like a good tool for doing this
> http://meshlab.sourceforge.net/ (already packaged in Debian). I
> expect blender can too, but some goolgeing suggests that this needs
> extra scripts.
>
> The wavefront .obj file seems a fairly straightforward format:
> http://en.wikipedia.org/wiki/Wavefront_.obj_file#File_format
>
> But it only represents surfaces so far as I can see, not lines. So we
> can export terrain and volumes, but not plain surveys (without faking
> survey lines into cylinders).
>
> It does look like this would be a useful format to output. Or teach
> meshlab to read/write .3D and/or lox.
>
> Do Bruces' mates know that Aven can export a video file directly,
> animating a survey? However that can only have a mesh surface (as
> generated by terraintool) currently, which may or may not be 'high
> quality' enough for their purposes.
>
> Wookey
> --
> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Export Full Backbearings from PocketTopo to Therion

[Footleg]

That is all very interesting and useful John.

I have been in the habit of firing just a single splay shot back as my
back bearings. I did not know PocketTopo treated back bearings like
you describe. With my method the back bearing is just treated like any
other splay. So it does not affect the primary loop closures (in
Survex) or generate back bearing errors automatically. But the
information is there for future reference. Primarily I have used it on
the spot during the survey to spot bad legs and re-measure them at the
time on the survey.

But I am in the process of enhancing my caveconverter software to deal
with splays in various ways. Generating LRUD dimensions from splays
for model generation (again primarily for Survex) but also thinking
about how to handle the back shots. I am not aware of specific support
for flagging a shot as a back shot in either Survex or Therion. But I
was intending to at least implement support for such a flag in my in
memory data model so I have the option to output the information in
future to files which do support it, but also to give options for what
to do with it in exported files now (e.g. Export as a commented out
leg, export as duplicate legs, export as splays) or just to help
visualise data errors better (I have not started on data visualisation
yet, but have been thinking about it for a while).

Footleg

On 29 August 2013 12:12, John Stevens  wrote:
> Export oddities from PocketTopo to Therion
>
> A while back, I noted that if you do a full back bearing of three readings
> straight after you have done to forward leg, PocketTopo recognises this as
> the same leg and numbers it accordingly. I have not found any documentation
> about this useful feature though.
>
> 2.10  1.139   64.25  -33.70  [1]
>
>  2.10  1.288   53.85  -61.89  [1]
>
>  2.10  2.243  304.70  -50.40  [1]"fissure in floor
> with sound of water flowing "
>
>  2.102.11  3.574   49.25  -15.19  [1]
>
>  2.102.11  3.574   49.06  -15.19  [1]
>
>  2.102.11  3.577   49.27  -15.23  [1]
>
>  2.112.10  3.576  229.26   14.68  [1]
>
>  2.112.10  3.575  229.37   14.68  [1]
>
>  2.112.10  3.577  229.60   14.80  [1]
>
>  2.11  0.599   96.53   74.98  [1]
>
>  2.11  0.201  156.69  -50.20  [1]
>
>
>
> If the back bearing was outside the automatic parameters, then it can always
> be forced and sorted later. i.e. make a note, station may be too close to
> iron work or buried iron in spoil/deads.
>
>
>
> PocketTopo and TopParser deal with these in different ways when it is
> imported into Therion
>
>
>
> PocketTopo averages all 6 readings for the output file but it also adds a
> blank line
>
>
>
> 2.1064.25 -33.681.140 >
>
> 2.1053.85 -61.891.288 >
>
> 2.10304.69   -50.392.243 >
>
> 2.102.1149.30 -14.963.575 >
>
> 2.112.100.000.000.000 >
>
> 2.1196.67 75.01 0.599 >
>
> 2.11156.63   -50.150.201 >
>
>
>
> This second line then has to be commented out or deleted once in Therion.
> Other than that all other outputs act as expected.
>
>
>
> TopParser on the other hand outputs both sets of readings as separate legs.
> This has an advantage but a couple of disadvantages.
>
>
>
> 2.10  -  1.139  64.25  -33.7
>
> 2.10  -  1.288  53.85  -61.89
>
> 2.10  -  2.243  304.7  -50.4  fissure in floor with sound of water flowing
>
> #2.10  2.11  3.574  49.25  -15.19
>
> #2.10  2.11  3.574  49.06  -15.19
>
> #2.10  2.11  3.577  49.27  -15.23
>
> 2.10  2.11  3.575  49.15  -15.2  Calculated leg from 3 above
>
> #2.11  2.10  3.576  229.26  14.68
>
> #2.11  2.10  3.575  229.37  14.68
>
> #2.11  2.10  3.577  229.6  14.8
>
> 2.11  2.10  3.576  229.31  14.72  Calculated leg from 3 above
>
> 2.11  -  0.599  96.53  74.98
>
> 2.11  -  0.201  156.69  -50.2
>
>
>
> If I use this output, the length of the cave is doubled for the leg but I do
> get some nice 2 leg loop closure errors.
>
> The distance can be adjusted but adding flags duplicate and flags not
> duplicate lines around the duplicate leg.
>
> These loop closures then give me good feed back into where magnetic
> influences are within the cave/mine.
>
>
>
>   5.70%0.4m7.7m   2   -0.2m0.4m   -0.0m [2.7 - 2.8 - 2.7]
>
>   3.86%0.2m5.1m   2   -0.1m   -0.2m   -0.0m [2.8 - 2.9

[Therion] file.sql format

[Footleg]

In most databases, transactions are not needed for SQL imports. Their
purpose is to ensure that a partial operation does not get committed
to the database. For example if a system was transferring money from
one account to another you would not want the withdrawl of an amount
from the paying account to occur without being guaranteed that the
payment was credited to the receiving account. The transaction
begin/commit statements provide this guarantee. Either everything
inside the transaction begin/end will be committed to the database, or
none of it will.

For SQL import of Therion data it would seem unnecessary unless it was
really important to you that if you stopped the import part way
through then all the import was rolled back and none of the data
written into the database. More commonly with large data imports of
complete tables you do not want to use transactions as this slows down
the operation, and if it was to fail for some reason (like an error in
the SQL script) then you can just drop and recreate the tables to
reset the database ready to try again.

Footleg

On 24 July 2013 21:18, Andrew Atkinson  wrote:
> Hello
>
> I have just been playing with the export database part of Therion again.
>
> The file outputted was imported into some application fine, but most
> would not work phpMyAdmin being one of the ones that I could not import
> with and the one that my ISP forces me to use.
>
> phpMyAdmin was giving the error
>
> #1064 - You have an error in your SQL syntax; check the manual that
> corresponds to your MySQL server version for the right syntax to use
> near 'TRANSACTION' at line 1
>
> After a bit of searching I found this
>
> http://dev.mysql.com/doc/refman/5.0/en/commit.html
>
> (there is a similar page for MySQL4 and 3.23 that seem to say the same)
>
> So editing the exported file first line
>
> from
>
> begin transaction;
>
> to
>
> begin;
>
> and last line
>
>
> from
>
> commit transaction;
>
> to
>
> commit;
>
> then it worked
> Not sure if this is a bug or my lack of understanding of the .sql file
> format
>
> Andrew
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Loch passage tube behaviour

[Footleg]

A very useful account of the various options Bruce. Well worth adding to
the wiki!

I will experiment with some of my caves were I have LRUD data but have not
entered it into Therion to see if I can improve my models.

Footleg


On 20 July 2013 23:12, Bruce  wrote:

> **
>
> Footleg
>
> I think the answer is ‘yes’.
>
> Hopefully you can view the images embedded in the image rather than
> attached, otherwise this won’t make much sense.
>
> ** **
>
> In this example there is a single centreline (comprising both cave and
> surface survey) and 4 scraps.
>
> A short section of cave at the left hand end does not have any scrap drawn.
> 
>
> Compiled with Therion 5.3.11
>
> ** **
>
> One interesting point is that regardless of the ‘walls’ setting, there is
> never a tube generated there once we have scraps drawn anywhere in this
> centreline.  My deduction is that Loch uses only one type of tube
> generation per centreline, because in almost all my larger projects that
> transition between traditional survey and paperless survey, I have a
> combination of each type of tube generation within the same **Loch**model.
> 
>
> This fits with the description in the Therion Book
>
> *“walls   turn on/off passage shape generation from LRUD
> data for*
>
> *subsequent shots. If set auto, passage is generated only if there is no
> scrap referencing*
>
> *given centreline.”*
>
> ** **
>
> In these examples I have not used any ‘point passage-height’ or ‘point
> dimensions’ in the scraps.
>
> ** **
>
> 
>
> Paperless survey (no LRUD), walls auto, off or on (or not specified), No
> plan scraps. [**Loch** always guesses tube dimensions]
>
> -same if LRUD present and walls off
>
> ** **
>
> 
>
> Paperless survey (no LRUD), walls auto, off or on (or not specified), plan
> scraps drawn [**Loch** uses scraps for tube width and guesses tube height]
> 
>
> ** **
>
> ** **
>
> Now, I added a few LRUD to the same centreline, including some with only UD
> 
>
> ** **
>
>   data dimensions station left right up down
>
>   1.4 - - 20 20
>
>   1.5 - - 20 20
>
>   1.6 2 2 20 20
>
>   
>
>   3.13 10 10 20 20
>
>   3.14 10 10 20 20
>
> ** **
>
> Tube generation, where it occurs extends one station beyond those
> specified.
>
> ** **
>
> 
>
> Paperless survey (some LRUD), walls on or auto (or not specified), No plan
> scraps. [**Loch** uses LRUD for tube dimensions and only for stations
> where partial data is provided, it guesses the missing data   ie if a
> station has no data, no tube is generated]
>
> ** **
>
> And now adding some scraps and things get interesting.
>
> ** **
>
> 
>
> Paperless survey (some LRUD), walls off (or not specified), Plan scraps
> drawn. [**Loch** uses scraps, not LR, for tube plan dimensions, and UD
> for height where specified, otherwise height is guessed.  Where there are
> no scraps, LRUD is *not* used.]
>
> That is perhaps contrary to what one might expect from the Therion Book
> ‘walls’ entry.  It also produces perhaps the best model.
>
> 
>
> Paperless survey (some LRUD), walls on or auto, Plan scraps drawn. [**Loch
> ** uses scraps AND LR for tube plan dimensions, and UD for height where
> specified, otherwise height is guessed.  Where there is no LR, then it is
> guessed. Where there are no scraps, LRUD *is* used.]
>
> ** **
>
> If I change the LRUD definition like this…
>
> ** **
>
>   data dimensions station up down
>
>   1.4  20 20
>
>   1.5  20 20
>
>   1.6  20 20
>
>   data dimensions station left right up down  
>
>   3.13 10 10 20 20
>
>   3.14 10 10 20 20
>
> ** **
>
> ..then the guessed width troubles continue.
>
> 
>
> Paperless survey (some LRUD), walls on or auto, Plan scraps drawn. [same
> as above]
>
> ** **
>
> So my final conclusion, for paperless survey, no need to include walls
> statements in each survey, or if you do, walls off is better than on or
> auto. If you happen to provide some UD data, then your model will be
> improved (more realistic).
>
> ** **
>
> I surmise that with these same settings, scraps with point passage-height
> or point dimensions will have a similar effect, but I have not tested this.
> 
>
> ** **
>
> Bruce
>
> ** **
>
> ** **
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mai

[Therion] Options for converting splays in my Cave Convertertool

[Footleg]

Thanks Bruce, I was not aware of that option to show/hide splays in Loch.

I also never realised that lox models could generate passage walls using
LRUD data. I had only seen it done using plan scraps and over-riding badly
interpolated heights using ceiling height points in my scraps.

Can I add LRUD data to my survey data in order to generate passage heights
when the wall lines in my scraps are used to set the widths? This would be
a good reason for me to accelerate support for Therion format reading and
writing in Cave Converter. Then you will be able to generate LRUD data from
splays to improve passage dimensions in models viewed in Loch. I'll find
you a compelling reason to use this tool yet Bruce!

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130720/add82c05/attachment.html>

[Therion] Typical Head of Water between entry and exit of sumped passages

[Footleg]

I am working on a master survey of the Kingsdale System in Yorkshire,
UK. There is a substantial submerged portion to the system. Over a
rough distance of 1500m of sumped passage, what difference in water
levels could be expected between the upstream and downstream ends of
the sump?

The diving data just records water depth, so it computes both ends of
the sump as having identical water levels. We know in flood conditions
the upstream sump level backs up considerably. But assuming the diving
is done in conditions of low flow, what typical difference might be
reasonable to expect in the altitude of the resurgence and of the
upstream end of the sump (determined by survey data from an entrance)?
My data shows a significant difference, but I do not know how much of
that difference might be expected and how much is due to errors in the
dry passage survey and entrance altitudes?

Footleg

[Therion] Fwd: Diving data loop closures altering depths

[Footleg]

That is why I posted the data inline as plain text. But that was bounced as
my message exceeded 40KB. Yet my attachment is only 7 KB.
On 17 Jun 2013 19:05, "Wookey"  wrote:

> +++ Footleg [2013-06-17 18:45 +0100]:
> >This is a Survex issue but may also be of interest to this list. Plus
> the
> >Survex list does not accept my 7 KB of data as it says my post is too
> big.
> >Posting the data here for lack of a capable list for Survex.
>
> It doesn't accept any attachments. By policy. 'Too big' is the generic
> mailman message.
>
> It probably make sense to allow small attachments, but we should discuss
> that on the relevant list.
>
> Wookey
> --
> Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
> http://wookware.org/
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130617/98d9da48/attachment.html>

[Therion] Fwd: Diving data loop closures altering depths

[Footleg]

This is a Survex issue but may also be of interest to this list. Plus the
Survex list does not accept my 7 KB of data as it says my post is too big.
Posting the data here for lack of a capable list for Survex.

Footleg
-- Forwarded message --
From: "Footleg" <drfoot...@gmail.com>
Date: 17 Jun 2013 14:38
Subject: Diving data loop closures altering depths
To: "survex" 
Cc:

Trying to track down why some underwater data was several metres higher
than a sump water surface, I discovered that closing loops between stations
at the same depth in diving data alters the depth of surrounding data. This
was not expected!

I've attached a fragment of the data which illustrates this. Without the
loop closed:

Station entrance.030 is at depth -5.30

Closing the loop:
 *equate Entrance.010 EntranceLoopNorth.019

where both these stations are at the same depth, but horizontally displaced
(a common scenario as depths are absolute but length and compass errors
accumulate in diving data), now:

Station entrance.030 is at depth -5.48

Is this a bug, or have I not understood something here?

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130617/0d71b827/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: Keld_Head_divinglooperrortest.svx
Type: application/octet-stream
Size: 7993 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130617/0d71b827/attachment.obj>

[Therion] Using autonamed station named from PocketTopo sketches incomplex projects

[Footleg]

Hi Bruce,

Interesting observations on PDAs and where to store files. I was aware that
PocketTopo writes backup copies of the data file in use to the memory card,
but I thought it cleaned these up when you saved the file (or maybe it is
when you open a new file or close PocketTopo). I have never noticed my PDA
memory cards littered with back-up files. Just seen one instance on the
card when PocketTopo is running. So on that basis I assumed that the
auto-backup feature will only save you if PocketTopo crashes or the PDA was
destroyed (or battery ran flat) while in the middle of surveying. Once you
finish and close the project (or switch to a different file in PocketTopo
which I often do on a trip when working on large projects with several
areas active) then you lose any auto-backup of the file you were last
working on. If it is not on the memory card and the PDA then gets damaged
(in transit in the cave rather than while in active use) then you would
lose the data if only stored on the PDA internal memory.

I always take my cards out to copy data, but then my PDA is not sealed so
it is not a problem. Instead I use the PDA inside a waterproof Aquapaq case
which I can draw through but makes everything completely submersible (to 5m
it is claimed, but mainly I just wash it in a stream if too muddy).

I am working on a system to organise data for a larger cave, mixing
historical data and recent data. I'll try to document it once I have
determined that it really works. I have spent much more time working out
how best to do things than actually drawing anything yet, as I want to be
sure I am doing it right before spending the next few years drawing!

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130615/42aa0bc3/attachment.html>

[Therion] Using autonamed station named from PocketTopo sketches in complex projects

[Footleg]

Having embarked on drawing up a larger cave system with data from various
sources, I discovered that PocketTopo sketches brought into the drawing
editor just get names local to that sketch (e.g. 3.3, 3.4, etc.) but my
project builds up the centreline from multiple centreline surveys. So the
actual name of the stations in my cave is like
3.3 at subsection.dataset.cavename

Thinking there must be a solution to this, I searched the wiki, and found
it (Thanks Bruce!). I can use the -station-names option on my scraps in the
sketch to say what the full name of the station should be. But my station
names do not need a prefix (it is already set from the xvi file by the
editor) and with a bit of experimentation I discovered that to omit the
prefix I have to put a pair of double-quotes as the prefix. This works, but
is there a neater way to do it?

e.g.  -station-names "" @ShortDryWay.swildons
means my station with -name 3.3 will be treated as
3.3 at ShortDryWay.swildonsin the scrap and this is what my station in
the complete cave centreline
data is named so it works. It just seems unintuitive to have to give a
blank prefix this way. Bruce's example also includes author and copyright
options on the scraps. How does Therion use these? Or are they just allowed
on the scrap options but not used in any generated output?

While reading Bruce's excellent advice pages on data structures I spotted
some places where more recent developments or ways I work make things
easier since the section was written. So I've added a tip on getting data
off PDA via memory card, and a link to Andrew's TopParser application to
this wiki page:
http://therion.speleo.sk/wiki/doku.php/paperless#data_transfer_from_pockettopo_to_therion

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130615/46a8837a/attachment.html>

[Therion] Label point and Label line default text sizes

[Footleg]

Thanks Bruce, I just spotted this as I added a second piece of line label
text and it came out a different size to the previous line label. It
appears that the text resizes to fit the length of the line. So the only
way to be certain of the size of the text is to use point labels.

Footleg


On 6 June 2013 20:39, Bruce  wrote:

> ** ** **
>
> Footleg
>
> I used to have this figured out, but my memory is a bit fuzzy and I cannot
> immediately find where it is described.
>
> It’s something like this I think.
>
> ** **
>
> Point label always gives you text of the size you specify, at default
> character spacing.
>
> Line label gives you text to fit the length of the line.  If the line is
> longer than is necessary for the specified size (text height), then the
> characters are spaced out to fit the line.  If the line is too short, the
> text size is reduced (often by non-standard amounts) so that the text will
> fit and metapost (or tex?) generate a message saying that the
> text size is reduced (or at least it used to).
>
> ** **
>
> So, in effect, ‘line text’ can never be relied upon to look the same as
> ‘point text’.  Line text that looks good at one scale, will of course be
> significantly stretched or shrunk at another scale.
>
> ** **
>
> Ah ha I remember, I produced a dataset specifically exploring text effects
> and trialing a text drawing convention that I never got into established
> usage here.  Perhaps it is time to dig it out?
>
> ** **
>
> Bruce
>
> ** **
>  ------
>
> *From:* therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] *On
> Behalf Of *Footleg
> *Sent:* Friday, 7 June 2013 12:35 a.m.
> *To:* **List for Therion users**
> *Subject:* [Therion] Label point and Label line default text sizes
>
> ** **
>
> I just noticed that if I set text on a point of type Label, with the
> option -text "Water Rift" -scale xl
>
> and then set the same option on a line of type label, then I get different
> size labels on my PDF. Is this intended? I had assumed the scale options
> for text would generate the same size text whether I am placing it using a
> label or a line?
>
> ** **
>
> Footleg
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130606/27ec0331/attachment.html>

[Therion] Label point and Label line default text sizes

[Footleg]

I just noticed that if I set text on a point of type Label, with the
option -text "Water Rift" -scale xl
and then set the same option on a line of type label, then I get different
size labels on my PDF. Is this intended? I had assumed the scale options
for text would generate the same size text whether I am placing it using a
label or a line?

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130606/569b45e2/attachment.html>

[Therion] Missing information in Survex 3d model output

[Footleg]

Converting some Survex format data into Therion I discovered that despite
entering the data in Therion, the Survex 3d model output from Therion is
lacking some of the information which enables some of the most useful
visualisation features in the Survex 'Aven' viewer. If I select 'Colour by
Date' or 'Colour by Error' in Aven then none of my data appears to be
counted as being in loops or having dates associated with it. Is this a
known bug?

Footleg
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20130603/8fe7e13f/attachment.html>

[Therion] New release of Cave Converter

[Footleg]

Only ten days since I released an update to my Cave Converter program,
but I just put out another update. Just one bug fix in this one, but
it finally fixes the last niggling issues in converting survey data
into Toporobot format (at least as far as I am aware) so I put it
straight out. My most complex caves now all convert properly for
import into PocketTopo for taking underground on a PDA for surveying
trips. The change log entry is as follows:

16 Mar. 2013
- Fixed bug in Toporobot writer which left survey series unlinked when
two series crossed over
  each other in the middle of each series (i.e. Not joined at the
start or end of either series).

Same place as usual for the download:
http://wscc.darkgem.com/caveconverter/

Footleg