[Therion] wikipedia

[Andrew Atkinson]

The main one I am working on is

http://www.ubss.org.uk/cave_survey_archive.php

which includes mcg (Ben Coopers) work

http://www.mendipcavinggroup.org.uk/sections/upperflood/surveys.html

Also might be worth

http://www.mulucaves.org/wordpress/surveying/the-therion-survey

Andrew



On 13/12/11 09:04, Xavier Robert wrote:
> Hi Martin,
>
> If this is what you want, you can find mapping project on my caving club web 
> site :
>
> * for the Gouffre Jean-Bernard System : 
> http://www.groupe-speleo-vulcain.com/01_04_topographie_jean_bernard.html?lang=en
> * For our last Expedition in Borneo : 
> http://www.groupe-speleo-vulcain.com/expeditions-borneo.html?lang=en (with 
> sources)
>
> Cheers,
> Xavier
>
>
>
> Le 13 déc. 2011 à 09:48, Martin Sluka a écrit :
>
>> There is a request from one wikipedia editor:
>>
>> x
>> Are there any reliable, third party sources which can speak to the 
>> notability of this software? I see that people are using it as witnessed by 
>> the articles in newsletters; but, I don't see any reliable sources. WTucker 
>> (talk) 06:02, 13 December 2011 (UTC)
>> x
>>
>> So may you add the links to your project pages or send me a link I'll do it.
>>
>> Martin S.
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>
>
>
> --
> Xavier Robert
> Chercheur CR2 - IRD
> ISTerre - Maison des Géosciences
> 1381 rue de la Piscine - BP 53
> 38041 Grenoble Cedex 09
> France
>
> mail 1: xavier.robert at ird.fr
> mail 2: xavier.robert at ujf-grenoble.fr
> mail 3: xavier.robert01 at gmail.com
>
> Phone :
> Fax : 33 (0)4 76 51 40 58
>
>
> xavier.robert01 at gmail.com
>
>
>
>
>
>
>
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] List of dig sites

[Andrew Atkinson]

Bruce

You have been active, serves me right, I did my search on my hols, and 
took a month to send the mail, in the mean time you had written a wiki 
page, looks like we are doing the same sort of thing, but I am only 
doing it all in the maps, not really got a reason, just the way I 
developed it.

It is a little combersome at the moment, I like the idea of a pictorial 
output as well, but not sure I can visualise how it would work

Andrew

On 04/02/11 09:27, Bruce wrote:
> I have just started playing with point continuations like this...
> http://therion.speleo.sk/wiki/doku.php?id=drawingchecklist[]=continuation#
> points
>
> This way we get a dig list, rigging list, exploration list, or whatever type
> of 'to do' list you want.  Quite cumbersome I admit, but it seems like it
> might be working.  (With some extension of therions list exports it could
> get easier.) You get your list in text-like format and plan or elevation pdf
> pictorial format if you want.  The text list can be pulled into a
> spreadsheet to make filtering and sorting a trivial matter.  I just need to
> put together a vba script to automate this... one day
>
> Bruce

[Therion] Irish Grid coordinates

[Andrew Atkinson]

Try these

http://spatialreference.org/ref/epsg/2157/
http://spatialreference.org/ref/epsg/29903/


Andrew

On 10/02/11 08:03, Graham Mullan wrote:
> I am starting the tedious process of migrating a large dataset from
> Survex to Therion. Now would therefore seem the right time to start
> converting the co-ordinate system that is used.
>
> The data is for Co. Clare in Ireland and previously all entrances and
> fixed points were listed in Irish Grid. The Irish are changing this to
> ITM (Irish Transverse Mercator) and I would like this to be the system
> that we use as it is what will appear on their maps etc. I am assuming
> that it is not supported by Therion. I cannot find an EPSG number that
> specifically relates to this. The IOS website talks about their system
> being compatible with ETRF89, for Europe but that is the nearest
> indication I get.
>
> Can anyone tell me what the correct EPSG number might be or is it
> possible for ITM to be built into Therion as an option?
>
> Graham
>
> ---
>
> graham.mullan at coly.org.uk
>
> 0117 9502556 or 07887 637064 (or try 0844 2327803)
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] strike and dip

[Andrew Atkinson]

We did discuss trying to put faults etc into our lox model a while back, 
but found more useful things to do,

It would be a nice feature, but no idea how it could be done.

I have included Anddy Farrant in this mail, as our trained (but not very 
well) Geologist, he should be able to help in this discussion, but has 
little knowledge of Therion

Andrew

On 10/02/11 10:43, Stacho Mudrak wrote:
> Hi all,
>
> we are solving a problem of adding a basic geological observations
> (measurements) to therion.
> When measuring a planar feature (bedding or fault or others), you
> measure strike and dip.
> When measuring linear features, trend and plunge is measured.
> In the case of faults, also whether it is dextral or sinistral fault is
> determined and potentially a magnitude.
>
> My question is, do you have some idea/wish how to integrate these into
> therion? Do you have some experience with it?
>
> Our first idea is to add a standard T symbol for strike and dip
> measurement, but there is one problem. Orientation of this symbol is not
> drawn, but it is measured (with compass). But its position is given by
> position on the map. Should these measurements be entered into a table
> (as centerline data are), or put as options with symbols?
>
> Do you have any ideas or comments?
>
> Best regards, S.
>
>
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Inkscape import/export plugins

[Andrew Atkinson]

I know little about Inkscape, but got the basics.
Using Inkscape  0.47 r22583  Ubuntu 10.04

So loaded up the add in, one question that does not affect its use, but 
might be important for update. All my others are in folders, but this 
just goes in as is (I did try it in a folder but it did not work.)

It imported my th2 files fine, but with no background image, not sure if 
it was meant to. All the ones I tried had been from a PocketTopo import.

First impressions are impressive, all the wall types shown, if anything 
a little fine on the detail, sometimes had to zoom in a bit to tell the 
difference.

Then tried a new file, did not bother with a background image, just 
played, added walls and even different subtype of walls, okay they all 
came up the same but when saved and then reloaded they came out fine.

Couple of comments, I try to connect node points together when attaching 
a pit to a wall, etc. I know it is not needed in Therion, as clip sorts 
it out, but it works for me, but I could not do this on Inkscape.
On a loaded file you cannot change the wall subtype, which is how you 
said, however I am not sure if this is the right behaviour. As I could 
tell from my new file I could add in different subtypes of wall as new, 
so why not give the option of changing them. When opening ask if you 
want read only or changeable. Okay it would not change on the display 
until next reloaded, but currently I would have to change it in Xtherion 
or an editor..

Also on loading it found a few errors

skipped: #point
skipped: #point
warning: empty line
warning: empty line

An indication of which line would be good, or better still an option to 
correct.

Maybe lots of this is planned. It is very impressive, I can see it in 
the future helping lots of people to be able to use Therion in the 
future. It would be good to have an idea where you intend to go with it, 
I have lots of questions, things like viewing at different scale 
outputs, and seeing the text along a line labels, then there are Areas.

Wonderful stuff it looks like I will be teaching myself Inkscape!

Andrew



On 14/02/11 15:41, marco corvi wrote:
> On Sun, 2011-02-13 at 15:18 +0100, Thomas Holder wrote:
>> Hi all,
>>
>> I wrote import and export plugins for Inkscape to edit th2-files. This
>> is particular useful to remaster existing therion-drawings with the
>> convenience of a quite modern vector-graphics application. The therion
>> line/point type annotation is stored in the object label (Object
>> Properties Dialog) and can also be altered with dialogs from "Extensions
>>   >  Therion>  Set..." menus.
>>
>> Download:
>> http://www.thomas-holder.de/projects/inkscape-speleo/extensions/th2-latest.zip
>>
>> Unsupported is the editing of lines with line point options, since there
>> is no concept in SVG for this. Such lines will be marked as read-only on
>> import.
>>
>> I will be happy for any feedback (if it works, if you find it useful).
>>
> that's interesting indeed.
>
> import works.
>
> line drawing is ok, and the line appears in the export with type "wall",
> but when i change the label it's no longer exported.
>
> i do not know anything about inkscape:
> how to draw points ?
> and areas ?
>
> marco
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Inkscape import/export plugins

[Andrew Atkinson]

On 14/02/11 16:58, Thomas Holder wrote:
> Andrew Atkinson wrote, On 02/14/11 17:05:
>> I know little about Inkscape, but got the basics.
>> Using Inkscape 0.47 r22583 Ubuntu 10.04
>>
>> So loaded up the add in, one question that does not affect its use,
>> but might be important for update. All my others are in folders, but
>> this just goes in as is (I did try it in a folder but it did not work.)
>
> what is in folders, the plugin files?

See screen shot, the first 4 are in folders, the rest are just a long 
list. My thinking was on the lines of on expedition without internet, if 
all the files where in a folder, I could pass them on to someone else, 
very unimportant
>
>> It imported my th2 files fine, but with no background image, not sure
>> if it was meant to. All the ones I tried had been from a PocketTopo
>> import.
>
> there is a hidden layer that should show your background image. Open the
> layers panel and un-hide it there.

Okay found the hidden layer, and switch on the legend, which is fine, 
but cannot get the background to show, relevant files attached 
(DieselDuck), hope it helps, could be just my poor use of inkscape, 
there are 2 background images in this file. Tied another, this time 
switching the image on gives a Linked image not found box
>
>> First impressions are impressive, all the wall types shown, if
>> anything a little fine on the detail, sometimes had to zoom in a bit
>> to tell the difference.
>>
>> Then tried a new file, did not bother with a background image, just
>> played, added walls and even different subtype of walls, okay they all
>> came up the same but when saved and then reloaded they came out fine.
>
> Annotation is not so elegant but can be done for selected elements from
> the menu with "Extensions > Therion > Set...". So you can change line
> type, for example draw a couple of rocks, select them all and then
> annotate as "line rock-border".

Can get this to work for most (all?) things apart from wall subtypes, I 
am entering it through Extensions-Therion-Set Line type.
However, saving it and reloading it and the subtype works.
>

>
> you can change the subtype of the complete line by adding the -subtype
> option to the label. But changing the subtype within the line at a
> certain point is not supported since this concept does not exist in
> Inkscape. If you would allow the user to edit such a line, this
> information would be lost.

I do not tend to change subtype along a line.
>

>
> Text along line labels and areas are preserved on import/export, but
> cannot be edited on the inkscape canvas, sorry.

Such is life, I'm always hopeful
>
> Acutally, I intend to leave it as is for now. Of course any reasonable
> suggestion for improvement I will consider, that's why I asked for
> feedback :)

Hope this helps, and not sending you in the wrong direction, I must have 
now got the vast experience of 1 hour using Inkscape.

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 173660 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20110214/d7d20181/attachment.png>
-- next part --
A non-text attachment was scrubbed...
Name: DieselDuck.tar.gz
Type: application/x-gzip
Size: 68065 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20110214/d7d20181/attachment.bin>

[Therion] Converting Inkscape Drawings of very large cavesintoTherion

[Andrew Atkinson]

That is fine for the plan, but does it work for the model, I still have 
some not right joins in my model, not fully got my head round these

Andrew

On 25/02/11 05:54, Bruce wrote:
>
>> >What do you do if a passage branches out vertically, meaning one
>> >branch is completely covered by the other?
>> >The lower passages has to be drawn in its own scrap because of
>> >the overlap and the division must be directly at the junction, so it
>> >is impossible to follow rule 3.
> In this case there is no need for a join (unless you really want to).
> Just draw two scraps and in the map define like...
>   topscrap
>   break
>   bottomscrap
> Bruce
>

[Therion] Lox Model showing walls from wrong side

[Andrew Atkinson]

I've branched this from  Converting Inkscape Drawings of very large 
caves   intoTherion:

I have experienced the stretch using 2 points, and where I have tried 
this is always solved by adding more points and scraps were needed, but 
the inside out part I do get more often. I have tried splitting into 
more scraps, and splitting the lines.

The former works totally or reduces the incorrect bit, however a side 
affect is that the model is not as neat as it should be as the lox model 
has a 'step' on the scrap join. As demonstrated by the 2 attached set of 
files.

But currently all this is a bit random, and the moving to a new scrap is 
very tedious, it would be good to have some understanding of the 
problems, so they could be avoided?

Andrew


On 24/02/11 18:47, Bruce wrote:
 >>Simple scrap, but why does my lox model appear to only show the walls
 > when seen from the wrong side?
 >
 >>I have checked that the wall lines all have the yellow tick pointing
 > inside the passage. But half my passage appears in the Loch viewer to
 > only show the wall from the inside face, not from outside the model.
 >
 >>Very simple data file contents are as follows. The survey stations are
 > being imported from a survex 3D file. But I am only using 2 survey
 > points to scale the scrap, so you should be able to create any two
 > points to substitute the survey data.
 >
 >   I have done this with scanned paper files a number of times.
 >
 > Always if I use two points the lox files come out as you describe, or
 > with vertical extensions from the actual cave position to the surface.
 >
 > A solution that has worked once, but not tested yet on the others is two
 > break the drawing into more than one scrap, and have at least two points
 > per scrap.  This way the therion drawings and lox come out the same as
 > with a conventional survey.
 >
 > It seems that two points, one scrap is too minimalist for the current
 > implementation.
 >
 > Bruce
 >
 >
-- next part --
A non-text attachment was scrubbed...
Name: StPauls.tar.gz
Type: application/x-gzip
Size: 3174 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: StPauls-extra-scrap.tar.gz
Type: application/x-gzip
Size: 3235 bytes
Desc: not available
URL: 

[Therion] Lox Model showing walls from wrong side

[Andrew Atkinson]

Not from footleg, but here is one I have not solved yet, probably 
something to do with the high level passage coming in at the end of 
scrap one, separate survey

On 25/02/11 17:49, lada at blazcata.cz wrote:
>   If you can send me your data I can help you with debugging. Otherwise it is 
> hard to say what is wrong.
> Odesláno z mého bezdrátového zařízení BlackBerry®
>
> -Original Message-
> From: Footleg
> Sender: therion-bounces at speleo.sk
> Date: Fri, 25 Feb 2011 17:08:25
> To: List for Therion users
> Reply-To: List for Therion users
> Subject: Re: [Therion] Lox Model showing walls from wrong side
>
> ___
> 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 --
A non-text attachment was scrubbed...
Name: PortalPool.tar.gz
Type: application/x-gzip
Size: 25878 bytes
Desc: not available
URL: 

[Therion] Lox Model showing walls from wrong side

[Andrew Atkinson]

Excellent, that does make sense, will be a great help in trouble shooting.

Andrew

On 26/02/11 11:18, Stacho Mudrak wrote:
> This is the same problem. Adding line wall:invisible to both ends of
> this simple scrap (scrapPlan1) ultimately solves the problem. Sorry for
> late answer. I will try to fix it in the next snapshot.
>
> The problem is simple. When scanning outline, therion goes line by line.
> If there is another line, starting at the same point, where another
> ends, it continues this way. If there is none, it tries to find nearest
> end line point. But it does not care, whether it is really end point -
> or it just wall divided into two lines. I apologize for inconvenience.
>
> Best regards, S.
>
>
> 2011/2/26 Footleg mailto:drfootleg at gmail.com>>
>
> I have attached a very simple project showing the problem. There are
> screen shots in the zip file too. Using the cave1.th2 file you get
> the bad model. Note that it looks like the lox model has created a
> wall between a line node in one wall and a line node in an
> unconnected line node on the opposite wall. The wall in the Loch
> screen shot appears to be passing through the cave centreline.
>
> By adding a bit of extra line to the end of one of the walls, as
> shown in the ExtraLine.png, the lox model comes out correct. This is
> in the cave2.th2 file. So use either cave1.th2 to reproduce the
> problem, or cave2.th2 to see how it is fixed by adding a bit extra
> on the end of one wall.
>
> All done using the current latest 5.3.6 update of Therion.
>
> Footleg
>
>
>
> On 25/02/11 17:49, lada at blazcata.cz  
> wrote:
>
> If you can send me your data I can help you with debugging.
> Otherwise it is hard to say what is wrong.
> Odesláno z mého bezdrátového zařízení BlackBerry®
>
> -Original Message-
> From: Footlegmailto:drfootleg at 
> gmail.com>>
> Sender: therion-bounces at speleo.sk
> 
> Date: Fri, 25 Feb 2011 17:08:25
> To: List for Therion users >
> Reply-To: List for Therion users >
> Subject: Re: [Therion] Lox Model showing walls from wrong side
>
> ___
> 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 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] Lox Model showing walls from wrong side

[Andrew Atkinson]

Okay an improvement, but still not perfect, (5.3.5) but I can now try to 
solve with knowledge

Andrew

On 26/02/11 11:07, Stacho Mudrak wrote:
> Well, this is issue of outline scanning algorithm. Adding invisible wall:
>
> line wall:invisible
>5036.0 1371.0
>4832.0 1298.0
> endline
>
> Solves the problem. Therion very often has problems correctly connecting
> outline, if there are short wall lines and relatively long gaps between
> them. Adding invisible line there always solves the problem.
>
> HTH, S.

[Therion] Every Survey with data has 2 centrelines?

[Andrew Atkinson]

Hello

I was just wondering if this is correct, but it would appear that when 
searching the database output all surveys contain at least 2 centreline ids

Attached is the Forbidden.th file which has only one 
centreline/endcentreline pair, but the result below seems to show that 
there are 2 centreline id per survey when there is a 
centreline/endcentreline, of which one always have zero length. There is 
one id in files where there are no centreline/endcentreline, Eg 
CheddarCatchment which is the file that puts it all together, again this 
has zero length.

This could be the way that it is designed, but it does seem to lead to 
lots of redundant data.

Here is the search (I added the names in for ease of reference)

SELECT C.`TITLE`, C.`ID`, C.SURVEY_ID, SURVEY.NAME, C.`SURFACE_LENGTH`, 
C.`LENGTH`
FROM CENTRELINE C, SURVEY
where SURVEY.ID=C.SURVEY_ID Limit 30

which gives this result (also attached as csv, as email can make a mess 
of tables)

TITLE   ID  SURVEY_ID   NAMESURFACE_LENGTH  LENGTH  
2   1   0   0   
12  11  CheddarCatchment0   0   
14  13  Blackmoor   0   0   
15  13  Blackmoor   0   105.3   
18  17  BoneHole0   0   
20  19  BH_Surface  0   0   
21  19  BH_Surface  13.49   0   
22  19  BH_Surface  110.86  0   
25  24  BH_Entrance 0   0   
26  24  BH_Entrance 0   26.77   
29  28  BH_FirstPitch   0   0   
30  28  BH_FirstPitch   0   23.23   
33  32  BH_PerforationChoke 0   0   
34  32  BH_PerforationChoke 0   41.57   
37  36  Bone2   0   0   
38  36  Bone2   0   65.52   
42  41  Box 0   0   
43  41  Box 0   55.96   
46  45  charter 0   0   
48  47  OldCave 0   0   
50  49  Chiaroscuro 0   0   
180 49  Chiaroscuro 0   89.01   
183 182 Entrance0   0   
616 182 Entrance0   103.07  
617 182 Entrance0   281.2   
620 619 Forbidden   0   0   
720 619 Forbidden   0   36.84   
723 722 Midsummer   0   0   
812 722 Midsummer   0   31.38   
815 814 ReadsInlet  0   0   
-- next part --
A non-text attachment was scrubbed...
Name: resultset.csv
Type: text/csv
Size: 887 bytes
Desc: not available
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: Forbidden.th
URL: 

[Therion] Thanks Beat for the DistoX, PocketTopo

[Andrew Atkinson]

On 25/01/11 19:21, Bruce wrote:
> Firstly I’d like to thank Beat for;
>
> -developing the DistoX and for the regular improvements to PocketTopo,
>
> -repairing our DistoX when it was faulty after our initial assembly, and
>
> -‘walking’ me through and troubleshooting on numerous times I’ve been
> confused or one of the devices was not working.

I will second that, its adaptability keeps amazing me, just done a 
survey in a cave with too much metal to use a compass, therefore had to 
use a total station, it does not do negative inclination but give out 
350 for -10. Pocket Topo took it in its stride. (therion gives an error, 
which I will mail about shortly)
>
> We just found 2.5km of 10-30m diameter passage, and would not have been
> able to face surveying with a tape measure and paper (too slow and
> inaccurate). It’s big muddy light absorbing passage. Having launched
> into the project I have a suggestion for PocketTopo development, (and
> distoX observations) that the forum might like to comment on.

Well done, sounds like fun, do we get to see a survey soon?
>
> *PocketTopo v1.35*

Must upgrade to this!
>



> shots and ‘.’ shots).
>
> *Disto Distance*
>
> Our distoX occasionally gives one off spurious distance (and rarely
> compass) readings. On our most recent trip it went one step further – a
> ~15m survey leg gave ‘3 in a row’ readings of 0.21m and some time later
> (after many readings that looked OK) on a similar ~15m survey leg it
> gave ‘8 in a row’ 52.0m readings with the odd 48m and 82m reading thrown
> in for good measure. We chose another station and the anomaly
> disappeared. We are quite sure that for the majority of these bogus
> readings the laser was squarely on the target. This survey (but not
> these legs) included a 100m loop, which closed at 1.25%. This is among
> the worst we’ve had with the distoX, but it does not suggest any gross
> distance errors occurred within the loop.
>
> Some 100 distance readings later the lithium AAA batteries died. (The
> indicator suggested the batteries were full at the start, and the survey
> included probably 300 shots).
>
> Has any one else noticed similar issues?
>
> Are the spurious readings likely to be battery level related? Or do they
> suggest something more sinister?

In reverse order, for lithium batteries when they die they die quickly, 
all bars showing to dead in less than 10 shots. I have no idea how many 
reading the distoX takes on one set, but it must be thousands, I am on 
my second set, and covered many km's of passage, with splays, it must be 
about 1 leg per metre.

As for the spuriuos distance reading, yes occasionally, but never 3 of 
similar length together, it usually occurs in damp or drippy areas, we 
have also managed to reflect it off a wet surface of a wall or a pond, 
and get a more consistent error, but not enough to form a leg in 
PocketTopo. I have seen silly short measurements, again in damp 
conditions, usually with steaming or muddy front, not necessarily on the 
lens, can be on the rubber bit round the edge. I have not been able to 
reproduce it back at home, when I try to it just works or does not work.

Also on 2 occasions the clino has 'frozen' repeatedly given the same 
measurement, while the distance and the bearing seemed fine. both times 
I have had to calibrate the DistoX to fix the problem

 From my experience 1.25% seems a little high for a loop closure using a 
DistoX. Since using DistoX anything above 0.5 is suspicious, I regularly 
get 0.0 (the output is only 1 dp)
>
> *Disto Display*
>
> A new distoX, recently acquired and upgraded by a colleague has
> developed some permanently ‘lit’ pixels (about 20 of them) in the middle
> of where the inclination is displayed – even when the device is powered off.
>
> He is a ‘distoX & paper’ surveyor (and like me has aging eyes) so the
> difficulty in reading the display is particularly frustrating.
>
> Is there a solution to this?
>
> -New display from Leica?
>
> -New circuit board from Leica?

I have some weird lines on one of mine, so might need a solution to this 
soon as well, let's face it they were not built for caving

Andrew

[Therion] Possible minor point increment bug

[Andrew Atkinson]

Hi all

In therion 5.2

When using -name f01 on a station point

the next station is incremented to -name f2 not -name f02. Very minor, 
but it does get tedious I have had to correct quiet a few similar ones.

also would it be possible to increment alphabetical stations ie

-name 2a
to -name 2b

thanks

Andrew

[Therion] Loch 5.3.7 fails to start in Debian wheezy

[Andrew Atkinson]

After getting no output in ubuntu I decided to try Debian. So squeeze 
ran fine, nice bat icons and everything in the menu. But it was version 
5.3.3 so bit the bullet and changed to wheezy. Excellent, 5.3.7 xtherion 
works fine. (Well as far as I can tell) But loch just does nothing, 
whether from the or opening a file.
Trying the command line I get this

The program 'loch' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
   (Details: serial 2540 error_code 8 request_code 73 minor_code 0)
   (Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() 
function.)

Back to where I started, at least I have Aven this time, although it is 
not really that useable, as it flickers loads

Not found any other graphics that do not work, but then I only changed 
over a few hours ago

Andrew

[Therion] Loch 5.3.7 fails to start in Debian wheezy

[Andrew Atkinson]

What sort of graphics card have you got? (and which
> drivers/kernel)

lshw gives
*-display
 description: VGA compatible controller
 product: G71 [GeForce 7300 GS]
 vendor: nVidia Corporation
 physical id: 0
 bus info: pci at :01:00.0
 version: a1
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi pciexpress vga_controller 
bus_master cap_list rom
 configuration: driver=nouveau latency=0
 resources: irq:16 memory:e100-e1ff 
memory:d000-dfff memory:e000-e0ff

lspci give

01:00.0 VGA compatible controller: nVidia Corporation G71 [GeForce 7300 
GS] (rev a1)

If I have this right the install put on
X.Org X server -- Nouveau display driver (experimental)
1:0.0.16+git20110411+8378443-1+b1

Thought the drive might be a problem so tired installing

nvidia-kernel-common 20110515+1

Now I am not positive this was the right thing, and I have no idea how 
to check to see which one is in use, which might help to see if it is 
the right one, as the other one is still there! There are a plethora of 
nvidia things I could install, including nvidia-settings and 
nvidia-xconfig, butnot found much of use on the internet about what does 
what

I notice that
nvidia-kernel-common 20110515+2

is available, but I have not played with forcing yet, and the graphics 
driver seems a poor one to start with.





Can you save the info from the Aven 'about' window -
> that can be helpful.

Linux 2.6.39-2-amd64 x86_64
wxWidgets 2.8.10 (GTK+ >= 2.6)
Display Depth: 24 bpp (colour)
OpenGL 2.1 Mesa 7.10.2
Mesa Project
Software Rasterizer
R8G8B8
Max Texture size: 16384x16384
Max Viewport size: 16384x16384
Smooth Point Size 1.000-60.000 (granularity 0.100)
Aliased point size 1.000-60.000
GL_ARB_copy_buffer GL_ARB_depth_clamp GL_ARB_depth_texture 
GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex 
GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions 
GL_ARB_fragment_program GL_ARB_fragment_program_shadow 
GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_half_float_pixel 
GL_ARB_half_float_vertex GL_ARB_map_buffer_range GL_ARB_multisample 
GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object 
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex 
GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_shadow_ambient 
GL_ARB_shadow GL_ARB_sync GL_ARB_texture_border_clamp 
GL_ARB_texture_compression GL_ARB_texture_cube_map 
GL_ARB_texture_env_add GL_ARB_texture_env_combine 
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two 
GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_swizzle 
GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra 
GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object 
GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr 
GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_equation_separate 
GL_EXT_blend_func_separate GL_EXT_blend_logic_op GL_EXT_blend_minmax 
GL_EXT_blend_subtract GL_EXT_compiled_vertex_array GL_EXT_copy_texture 
GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements 
GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample 
GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters 
GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil 
GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_pixel_buffer_object 
GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_provoking_vertex 
GL_EXT_rescale_normal GL_EXT_secondary_color 
GL_EXT_separate_shader_objects GL_EXT_separate_specular_color 
GL_EXT_shadow_funcs GL_EXT_shared_texture_palette 
GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_subtexture 
GL_EXT_texture3D GL_EXT_texture_array GL_EXT_texture_cube_map 
GL_EXT_texture_edge_clamp GL_EXT_texture_env_add 
GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 
GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp 
GL_EXT_texture_object GL_EXT_texture GL_EXT_texture_rectangle 
GL_EXT_texture_sRGB GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra 
GL_EXT_vertex_array GL_OES_read_format GL_3DFX_texture_compression_FXT1 
GL_APPLE_object_purgeable GL_APPLE_packed_pixels 
GL_APPLE_vertex_array_object GL_ATI_blend_equation_separate 
GL_ATI_envmap_bumpmap GL_ATI_fragment_shader GL_ATI_separate_stencil 
GL_ATI_texture_env_combine3 GL_ATI_texture_mirror_once 
GL_IBM_multimode_draw_arrays GL_IBM_rasterpos_clip 
GL_IBM_texture_mirrored_repeat GL_INGR_blend_func_separate 
GL_MESA_pack_invert GL_MESA_resize_buffers GL_MESA_texture_array 
GL_MESA_window_pos GL_MESA_ycbcr_texture GL_NV_blend_square 
GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fragment_program 
GL_NV_fragment_program_option GL_NV_light_max_exponent 
GL_NV_packed_depth_stencil GL_NV_point_sprite GL_NV_texgen_reflection 
GL_NV_texture_env_combine4 GL_NV_texture_rectangle 

[Therion] Loch 5.3.7 fails to start in Debian wheezy

[Andrew Atkinson]

On 02/07/11 03:02, Wookey wrote:
>> Time for a remote control program that works across the web, been
>> >  looking for one that works on linux, easy to do on Windows nowadays
>> >  :(
> Been around for ages it's called vino/vinagre. (if you have gnome
> installed it'll probably already be there. The tricky bit is that both
> ends are often behind NAT so the machines can't see each other. It
> works well given an IP.

Hence I said across the web, I use the above at work, this one keeps 
promising Linux support, but

Hmmm in getting the web address, I see they seem to have released a beta 
for linux yesterday

http://www.mikogo.com/2011/04/21/mikogo-linux-beta-testers/
>
>>> >  >There should be some wxgtk samples/demos you can run which would show
>>> >  >if it is a wx problem or a loch problem. (loch uses VTK, which uses WX).
>>> >  >
>> >
>> >  A bit more of a pointer could be useful, but I will see what I can find
> Sorry I failed to find that info quickly, so left as excercise for the
> reader.
>
As I said a pointer, not actually the test, a search for wxgtk, takes me 
to all sort of thing, like wxpython wxperl
vtk I thought was typo of gtk at first, but it is also a graphics tool, 
but again, I do not have the knowledge to do a useful search, sorry this 
reader failed.

I will work on all the other alternatives early next week, cave 
surveying getting in the way of computing.

Andrew

[Therion] Extended elevation

[Andrew Atkinson]

I am struggling with the extend: left right normal and reverse, they do 
not seem to be doing what I would expect or as described at

http://therion.speleo.sk/wiki/doku.php?id=tfc:321

therion 5.3.7 on debian wheezy

These have been generated from the th file attached, which was an import 
from pocket topo. The file is as I needed it to work, for the below, 
remove all extend commands and then only add before the first line as 
shown. which is how PocketTopo export comes in. Adding it to the 
centreline -extend # seems to have the same effect as below. They 
are all viewed in the pdf, as I really have nothing else at the moment :(

Also it appears that the extend command, moves all the splays in the 
same direction, which I guess is how survex intended it, but this is 
different from the PocketTopo, that treats slays differently and to me 
more sensibly (well in most situations). But this is not really that 
important as the splays generated by therion are not used for the 
PocketTopo image import.

Noextend.pdf as it says has all the extend commands removed, so I would 
expect everything to go right, apart fro, 2.0 to 2.1 goes left


case1.pdf
So add extend right before the line

extend right
   2.0 - 260.00 11.60 2.610

So the legs go right then left, right,left right right...right, left, 
leftleft???

case2.pdf (file not included as it is the same as Noextend)
extend normal
   2.0 - 260.00 11.60 2.610

should be the same as right (unless I am missing a subtle difference) 
and no commands at all. It is the same as Noextend.pdf but different 
from case 1

case3.pdf
extend left
   2.0 - 260.00 11.60 2.610

opposite of right so at least consistent
left, right, left, right, left, left ... left right, right

case4.pdf
extend reverse
   2.0 - 260.00 11.60 2.610

consistent again: opposite of normal, but the first leg goes right 
instead of left and the they all go left

So normal and reverse seem to work apart from the first leg, but left 
and right are doing something strange to the first few legs

Using the commands in anywhere else in a linear part of the centreline 
mostly seems to work fine, and as expected, continuing down the 
consecutive numbering at a branch fine (but this could also be the order 
of the data in the file). However, left and right are less reliable than 
normal and reverse?? But not worked out a pattern yet. Other branches it 
is less clear for and this email is long enough

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: Hazelnut.tar.gz
Type: application/x-gzip
Size: 124608 bytes
Desc: not available
URL: 

[Therion] Loch 5.3.7 fails to start in Debian wheezy

[Andrew Atkinson]

Okay I have found time (mainly contingency time to fix a mess was the 
problem) to change the drives to the nvidia once as in the instructions on

http://wiki.debian.org/NvidiaGraphicsDrivers#non-free_drivers


And loch runs, unfortunatly it only shows a grey screen when you load a 
file, and it is not refreshing properly as the menus get left behind.

Worse, Aven now also shows a grey screen when you load items, although 
it seems to be there as the tree appears, and by randomly stabbing at 
the screen I can select stations and measure to another station.

Xorg.log and the information from the Aven help screen included

I notice that 5.3.8 is now an update, but I have not applied that yet.



On 02/07/11 03:02, Wookey wrote:

>>> >  >This is going to be difficult to debug remotely if I can't reproduce.
>> >
>> >  Time for a remote control program that works across the web, been
>> >  looking for one that works on linux, easy to do on Windows nowadays
>> >  :(
> Been around for ages it's called vino/vinagre. (if you have gnome
> installed it'll probably already be there. The tricky bit is that both
> ends are often behind NAT so the machines can't see each other. It
> works well given an IP.

My parents broke their computer, so it spurred me into looking again 
Teamview does remote access across the web, and does not need installing
Works quiet well, although you cannot shut down X which might be needed 
for this.

http://www.teamviewer.com/en/download/index.aspx

>
>>> >  >There should be some wxgtk samples/demos you can run which would show
>>> >  >if it is a wx problem or a loch problem. (loch uses VTK, which uses WX).
>>> >  >
>> >
>> >  A bit more of a pointer could be useful, but I will see what I can find
> Sorry I failed to find that info quickly, so left as excercise for the
> reader.

Is this the sort of thing you meant?

http://gtkperf.sourceforge.net/

It worked before and after and gave a time
-- next part --
A non-text attachment was scrubbed...
Name: Xorg.0.log
Type: text/x-log
Size: 24248 bytes
Desc: not available
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: System_info_Aven.txt
URL: 

[Therion] Duplicates including adding splays?

[Andrew Atkinson]

Hello

Therion 5.3.5 ubuntu 10.04

In the attached file the following information is given about the survey

title: RhinoPassage
length: 189.07m (surface 0.00m, duplicated 24.58m)
vertical range: 20.51m (from 1.27 at RhinoPassage at 20.38m to 
1.3 at RhinoPassage at -0.13m)
north-south range: 92.47m (from 1.27 at RhinoPassage at 33.43m to 
1.53 at RhinoPassage at -59.04m)
east-west range: 66.67m (from 1.53 at RhinoPassage at 66.67m to 
1.0 at RhinoPassage at 0.00m)
number of shots: 281
number of stations: 282

The duplicate figure got me wondering, it seems to be counting the 
splays but the length does not. As the duplicate none splays are only 
about 10m.
Maybe this is what is wanted, but I personally think that the duplicate 
value should be the amount taken off the length by the duplicate flag? 
Ie why is length treated differently to duplicate (something to do with 
the way survex treated splays and duplicate as different, I think that 
splays are not included in extend in survex)

Maybe 2 figures would be better, duplicate length and duplicate splays.

{probably best to ignore this next bit}
Oh this leads to all sorts of thinks that are really not important, like 
maybe giving the length of all the splays, and the number of stations, 
is it really 282 or really 54. All depends on your definition I guess

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: RhinoPassage.th.zip
Type: application/zip
Size: 3583 bytes
Desc: not available
URL: 

[Therion] No output in loch 5.3.3 Ubuntu 11.04 (Or aven for that matter)

[Andrew Atkinson]

After a hard drive failure I upgraded to ubuntu 11.04 and the default 
versions came in. therion 5.3.5 loch 5.3.3 (survex 1.1.14)

Xtherion seems to run fine and produces output (viewed in ubuntu 10.04 
loch and the 3D file in aven )

However, loch has no menus (a minor pain) trying to open a .3d file 
gives a blank page. Opening a .lox file it just crashes out.

Now I am sure I had read something about this in the mailing lists, but 
cannot seem to find it.

Now probably upgrading might solve it, but it would be good if the 
default packages worked in an OS.
Now will the new 5.3.7 (well hopefully 5.3.8) trickle down from debian 
to Ubuntu 11.04 or will I have to wait for 11.10?  {Nearly moved to 
Debian experimental when I lost my drive, starting to think it might 
have been better :( }

(For the record, aven also show a blank screen but you can see all the 
stations in the left hand bar)

Below is some info that I hope is useful

Andrew


I think this is the syslog line that happens when trying to open a lox, 
is there another log file I should be looking for. Nothing appears when 
opening a .3d

Jun 20 17:55:38 janda kernel: [  941.228479] loch[2762]: segfault at 
28d02ed ip 7f53c50f6b28 sp 7fff21d93e90 error 6 in 
libwx_baseu-2.6.so.0.3.1[7f53c509b000+10c000]

This is the system information that you can get out of the help menu on 
Aven (maybe it is relevant to loch)

Linux 2.6.38-8-generic x86_64
wxWidgets 2.8.11 (GTK+ >= 2.6)
Display Depth: 24 bpp (colour)
OpenGL 2.1.2 NVIDIA 270.41.06
NVIDIA Corporation
GeForce 7300 GS/PCI/SSE2
R8G8B8
Max Texture size: 4096x4096
Max Viewport size: 4096x4096
Point Size 1.000-63.375 (granularity 0.125)
GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_clamp 
GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_ES2_compatibility 
GL_ARB_explicit_attrib_location GL_ARB_fragment_program 
GL_ARB_fragment_program_shadow GL_ARB_fragment_shader 
GL_ARB_framebuffer_object GL_ARB_half_float_pixel 
GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_map_buffer_range 
GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query 
GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object 
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex 
GL_ARB_robustness GL_ARB_sampler_objects GL_ARB_separate_shader_objects 
GL_ARB_shader_objects GL_ARB_shading_language_100 
GL_ARB_shading_language_include GL_ARB_shadow 
GL_ARB_texture_border_clamp GL_ARB_texture_compression 
GL_ARB_texture_cube_map GL_ARB_texture_env_add 
GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar 
GL_ARB_texture_env_dot3 GL_ARB_texture_float 
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two 
GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_swizzle 
GL_ARB_timer_query GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra 
GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object 
GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos 
GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once 
GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra 
GL_EXT_blend_color GL_EXT_blend_equation_separate 
GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract 
GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test 
GL_EXT_direct_state_access GL_EXT_draw_range_elements GL_EXT_fog_coord 
GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample 
GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters 
GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil 
GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters 
GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color 
GL_EXT_separate_shader_objects GL_EXT_separate_specular_color 
GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap 
GL_EXT_texture3D GL_EXT_texture_compression_dxt1 
GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map 
GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine 
GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic 
GL_EXT_texture_format_BGRA GL_EXT_texture_lod 
GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp 
GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle 
GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra 
GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat 
GL_KTX_buffer_region GL_NV_alpha_test GL_NV_blend_minmax 
GL_NV_blend_square GL_NV_complex_primitives GL_NV_copy_depth_to_color 
GL_NV_depth_clamp GL_NV_fbo_color_attachments GL_NV_fence 
GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragdepth 
GL_NV_fragment_program GL_NV_fragment_program_option 
GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage 
GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint 
GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range 
GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners 
GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_barrier 
GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 
GL_NV_texture_expand_normal 

[Therion] No output in loch 5.3.3 Ubuntu 11.04 (Or aven for that matter)

[Andrew Atkinson]

On 20/06/11 18:16, Andrew Atkinson wrote:
> After a hard drive failure I upgraded to ubuntu 11.04 and the default
> versions came in. therion 5.3.5 loch 5.3.3 (survex 1.1.14)
>
> Xtherion seems to run fine and produces output (viewed in ubuntu 10.04
> loch and the 3D file in aven )

Meant to say loch 5.2.8, but wrote the rest while waiting for it to boot 
then forgot to go back and add it
>
> However, loch has no menus (a minor pain) trying to open a .3d file
> gives a blank page. Opening a .lox file it just crashes out.
>
> Now I am sure I had read something about this in the mailing lists, but
> cannot seem to find it.
>
> Now probably upgrading might solve it, but it would be good if the
> default packages worked in an OS.
> Now will the new 5.3.7 (well hopefully 5.3.8) trickle down from debian
> to Ubuntu 11.04 or will I have to wait for 11.10? {Nearly moved to
> Debian experimental when I lost my drive, starting to think it might
> have been better :( }
>
> (For the record, aven also show a blank screen but you can see all the
> stations in the left hand bar)
>
> Below is some info that I hope is useful
>
> Andrew
>
>
> I think this is the syslog line that happens when trying to open a lox,
> is there another log file I should be looking for. Nothing appears when
> opening a .3d
>
> Jun 20 17:55:38 janda kernel: [ 941.228479] loch[2762]: segfault at
> 28d02ed ip 7f53c50f6b28 sp 7fff21d93e90 error 6 in
> libwx_baseu-2.6.so.0.3.1[7f53c509b000+10c000]
>
> This is the system information that you can get out of the help menu on
> Aven (maybe it is relevant to loch)
>
> Linux 2.6.38-8-generic x86_64
> wxWidgets 2.8.11 (GTK+ >= 2.6)
> Display Depth: 24 bpp (colour)
> OpenGL 2.1.2 NVIDIA 270.41.06
> NVIDIA Corporation
> GeForce 7300 GS/PCI/SSE2
> R8G8B8
> Max Texture size: 4096x4096
> Max Viewport size: 4096x4096
> Point Size 1.000-63.375 (granularity 0.125)
> GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_clamp
> GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_ES2_compatibility
> GL_ARB_explicit_attrib_location GL_ARB_fragment_program
> GL_ARB_fragment_program_shadow GL_ARB_fragment_shader
> GL_ARB_framebuffer_object GL_ARB_half_float_pixel
> GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_map_buffer_range
> GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query
> GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object
> GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex
> GL_ARB_robustness GL_ARB_sampler_objects GL_ARB_separate_shader_objects
> GL_ARB_shader_objects GL_ARB_shading_language_100
> GL_ARB_shading_language_include GL_ARB_shadow
> GL_ARB_texture_border_clamp GL_ARB_texture_compression
> GL_ARB_texture_cube_map GL_ARB_texture_env_add
> GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar
> GL_ARB_texture_env_dot3 GL_ARB_texture_float
> GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
> GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_swizzle
> GL_ARB_timer_query GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra
> GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object
> GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos
> GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once
> GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra
> GL_EXT_blend_color GL_EXT_blend_equation_separate
> GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract
> GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test
> GL_EXT_direct_state_access GL_EXT_draw_range_elements GL_EXT_fog_coord
> GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample
> GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters
> GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil
> GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters
> GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color
> GL_EXT_separate_shader_objects GL_EXT_separate_specular_color
> GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap
> GL_EXT_texture3D GL_EXT_texture_compression_dxt1
> GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map
> GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine
> GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic
> GL_EXT_texture_format_BGRA GL_EXT_texture_lod
> GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp
> GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle
> GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra
> GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat
> GL_KTX_buffer_region GL_NV_alpha_test GL_NV_blend_minmax
> GL_NV_blend_square GL_NV_complex_primitives GL_NV_copy_depth_to_color
> GL_NV_depth_clamp GL_NV_fbo_color_attachments 

[Therion] data style problem

[Andrew Atkinson]

The Therion book p20 has this

data 

[Therion] data style problem

[Andrew Atkinson]

okay, I got the fix context wrong, so it just behaves different to survex.

I personally think the survex version is what is more useful, as vocal 
connections etc are not normally between 2 points that are fixed. Would 
that functionality be possible?

working th file attached

Andrew

On 23/03/11 20:14, Andrew Atkinson wrote:
> The Therion book p20 has this
>
> data 

[Therion] Diving data, limit 8 lines for lox?

[Andrew Atkinson]

hi all (again)

This has been puzzling me for hours

For the diving data attached (now very simplified as I tried to work out 
what was going on)

Uncommenting any consecutive lines up to 8 and the lox output works, any 
more than 8 and an output is produced but it does not open, the loch 
flashes on the screen then vanishes. one of the none working Lox file 
also attached. pdf and 3d files are produced from the full set of data

I am on Ubuntu 10.04
therion 5.3.5
loch 5.2.8


I am now giving up for the night, it has not been a good session

Andrew
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: goughs_sump_data2.th
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: sumps.lox
Type: application/octet-stream
Size: 1483 bytes
Desc: not available
URL: 

[Therion] Diving data, limit 8 lines for lox?

[Andrew Atkinson]

thanks Bruce

Your lox file does not open for me, looks like I need to upgrade loch.

Wookey: I think you did a build of therion (and loch) 5.3.6 on the 
Mendip survey course weekend, I can not see it on your site.

http://wookware.org/software/therion/

therion-viewer_5.3.5-1_amd64.deb

gives error

Error: Dependency is not satisfiable: libjpeg62 (>= 6b1)

(Which I think has been answered on the list before)

therion-viewer_5.3.3-1_amd64.deb
and
therion-viewer_5.3.0-1_amd64.deb

gives error

Error: Dependency is not satisfiable: libvtk5.4

(ubuntu 10.04 has libvtk5.2.1-14)

Which has also been on the list before 14th July 2010 wookey wrote

> Hmm, yes, only libvtk5.2 is available. That would be solved by a PPA
> build or therion migrating into next ubuntu release. I'll get my PPA
> sorted.

Andrew


On 24/03/11 06:44, Bruce wrote:
> Hi Andrew
> No problems at this end. Attached the file you posted with the comments
> removed - no other change.  Also the rudimentary thconfig file I made to
> compile it, the therion log and the resulting loch file.
>
> Therion 5.3.6 (using survex to process the survey)on Windows XP.
>
> Bruce
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Cross sections from pocketTopo

[Andrew Atkinson]

Hi all

I know this is just and experimental feature, so this might be on the 
list of things to do.

Why do the cross sections not have the station and splays on them? I am 
having to do lots of 'tidying' with the notes from underground, and 
having these on would help massively. The link to the original station 
would also be useful, but not that important.

Getting the drawn cave straight in without having to scan and then link 
sections etc, is wonderful. (although it has to be said being my first 
time in anger, it is taking quite a bit longer, spent ages playing with 
the dxf file, before going for the background image and redoing it)

thanks

Andrew

[Therion] x-section lines

[Andrew Atkinson]

hi all

I have got my cross sections where I want them, but now working on the 
line type. The picture on page 52 of the Therion book shows the type of 
line indicator I would like on my plan, but I cannot find a way to do 
it. I have a solid line across the plan with a arrows on, but cannot get 
it to hide the bit in the middle. I've tried
-place bottom
but this seems to make no different

While searching the book, examples and wiki I have come across a couple 
more things that I cannot fathom the instructions for

On the section line, all the other direction options work but I cannot 
figure out
-direction point

I get the error
  -- no line point specified
and I cannot find a way to specify the point.

also in the book p27 note 24

"Line showing cross-section position. If both control points of a 
Bezier curve are given then the line
is drawn up to the perpendicular projection of the first control point 
and from the projection of the
section control point. No section curve is allowed."

I cannot work out what this means

hoping you can help

thanks

Andrew

[Therion] fatal crash

[Andrew Atkinson]

Not sure what happened here, I moved a few points on a line, then tried 
to start another line, one point was inserted, tried to undo and got an 
error message, then everything I did including trying to save and close 
gave me an error. Attached is the log of the error, when I tried to save.

Version 5.2.9 on Win2000

Andrew
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: stuck.log
URL: 

[Therion] Should I worry about lots of these?

[Andrew Atkinson]

In version 5.2.9

Warning: the turningnumber algorithms do not agree. The current computed 
value  is -1, but the 'connect-the-dots' algorithm returned 0

thanks

Andrew

[Therion] Fixed corner co-ordinates on a map

[Andrew Atkinson]

Hi all

I am looking to try and generate an output which will always have the 
same co-ordinates.

I am try to do this as we have a rapidly expanding cave system which we 
would like to plot on google earth (or the likes) using Bill Chadwicks 
map of the Mendips

http://www.bdcc.co.uk/mendip.html

Now after consulting with Bill it appears if we predifine the size of 
the plot the crunching, just becomes computer power, so we can update 
then map as data comes in, full instructions are at

http://www.bdcc.co.uk/GoogleCrunch/Crunch.htm

Any hints welcome, one idea I have had is to use a 'blank' bit map as a 
surface, does it always displace the whole surface? This is something 
that I am having dificulty understanding the instructions for

thanks

Andrew

PS as soon as we fix the corners we will go back to the old fashiones 
paper problem of going off the sides

[Therion] co-ordinate problem

[Andrew Atkinson]

I am using therion with servex 3d files

using the command

import GB.3d -surveys use -cs EPSG:27700 -calibrate [0 0 0 30 10 0]

Which works fine, and generating the 3d file to check, using

export model -fmt survex -o GBth.3d

in the configuration file gives the same co-ordinates (with the
displacement added for the national grid) as the original survex 3d
file, however generating the kml file and looking at it on google earth,
the entrance has moved 90 metres on a heading of 078 degrees (and I 
assume the rest of the cave)

I have no idea where to look to fix this!

Thanks

Andrew


(The file extern/proj4/nad/epsg gave 3 results when searched for OSGB
and I have to say I did not understand the contents of the file, but got
three search results gave 2 numbers that I hope are the ones to use 4277
and 27700 I went for 27700 as
http://www.dnf.org/Pages/registry/CRS.asp#ETRS89
has 27700 but this is the SRID and also EPSG OP 19916 further down?
trying 4277 crashes my machine with a memory unaddressable error)

[Therion] wrong representation in google earth

[Andrew Atkinson]

No I have not tried loch models as yet, as I am not sure what they are 
or what they are used for, more to learn I guess

Andrew

Bruce Mutton wrote:
>> A bit of checking and making sure the the ticks where on the outside 
>> (into rock) and then for the 'pilers' some of which where massive and 
>> crossed scrap boundaries, use of the line option
>> -outline in
>> solved it in the end.
> 
> Did you happen to make any loch models with each set of data?
>>From your description your original data did not have the correct
> orientations on the wall lines.
> If this is the case I would expect the loch models to have exhibited similar
> aberrations to the kml files (did not observe your files, don't have a kml
> viewer).
> The pdf outputs seem to be very tolerant of some forms of careless drawing,
> so a successful pdf output does not mean the drawing is free of errors.
> 
> Bruce
> 
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
> 
> 
> 
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.339 / Virus Database: 270.12.36/2128 - Release Date: 05/22/09 
> 06:03:00
> 

[Therion] Version Control Systems and Therion

[Andrew Atkinson]

Bruce

If you have beginners, I personally would stick to one that does have a 
central record somewhere, if you want to support decentralised systems 
fine, but set it up in a way that the beginners can just log onto the 
'central' record and have to 'commit' every change. I have now tried 
using SVN with at least 3 sets of caving data. Trying to get people to 
understand a simple update and commit routine is hard enough, without 
the decentralised options, that I also find confusing. I would only go 
down that route for expeditions where it is difficult/impossible to talk 
to the central.

If you need it I have a document showing beginner windows users how to 
set up tortoiseSVN, but it is a few years only now, so the pictures are 
certainly not the correct ones

Andrew

[Therion] new snapshot

[Andrew Atkinson]

Martin

Thanks for implementing OSGB: so quickly, I will test as soon as possible.
Unfortunately, that means I have to learn some new skills, installing 
from source. So after lots of errors, and the web, I have got it down to 
the attached text. This is most probably my lack of knowledge, but any 
assistance or pointers would be most appreciated.

Andrew

On 01/06/10 15:08, Martin Budaj wrote:
> Hi all,
>
> new snapshot is available. Changes include:
>
> * Austrian symbol set is implemented (just use "copy AUT" in your
> layout to activate it).
> * New coordinate system OSGB:ST is added (Andrew, please test it -- if
> it works fine, we will include other squares as well)
>
> Other news is that after a spam attack we decided to change editing
> policy for wiki pages. Editing is now allowed only for registered
> users (some of the users are already registered; for those who are not
> we will publish registration instructions soon).
>
> Martin
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
URL: 

[Therion] new snapshot

[Andrew Atkinson]

No that was not all of it, I'll copy and paste into the file this time.

Also I guess information like

I am on amd64 running ubuntu 10.04

would be useful

Andrew

On 07/06/10 00:55, Wookey wrote:
> +++ Andrew Atkinson [2010-06-06 21:25 +0100]:
>> Martin
>>
>> Thanks for implementing OSGB: so quickly, I will test as soon as possible.
>> Unfortunately, that means I have to learn some new skills, installing
>> from source.
>
> In fact I have made some new therion packages for both 5.3.0 and 5.3.3
> so you may not need to bother.
>
> There are various minor things not quite right yet to do with help
> files and desktop icons - that sort of thing, but it should be
> sufficient to test.
>
> I've also tried to make an ubuntu PPA so things get build for your
> arch and with correct libraries. But that's not uploaded yet.
>
> Are you i386 or amd64? I've made amd64 packages. I can make some i386
> ones with a bit of faffage, on another machine.
>
>> make -C ./loch
>> make[1]: Entering directory `/usr/local/src/therion/loch'
>> gcc -c -Wall -D_GNU_SOURCE -DLOCH -DLXLINUX  
>> -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 
>> -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -O2 -o lxR2P.o 
>> lxR2P.c
>> make[1]: Leaving directory `/usr/local/src/therion/loch'
>
> That's not an error. Should there be more text?
>
> Wookey
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: output.txt
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20100607/950fc208/attachment.txt>

[Therion] new snapshot

[Andrew Atkinson]

Thanks wookey. therion_5.3.3-1_amd64.deb seems to work. It installs and 
I can run it and produce pdfs and 3d files. From Synaptic package 
manager (screen shot attached)  it would seem that the documentation and 
view has not been updated, but also everything appears twice, but this 
could be something that I have done, when trying install for source?? 
However the 5.3.3-1 properties both say maintained by Wookey, but why 
the other 2 doubled up does not seem logical.

Now to test OSGB:ST

Andrew

On 07/06/10 04:07, Wookey wrote:
> +++ Wookey [2010-06-07 00:55 +0100]:
>> +++ Andrew Atkinson [2010-06-06 21:25 +0100]:
>> In fact I have made some new therion packages for both 5.3.0 and 5.3.3
>> so you may not need to bother.
>
> OK. Highly preliminary packages uploaded to:
> http://wookware.org/software/therion/
>
> Only amd64 built so far. If you need i386 either ask for someone to
> build it, or download the sources, and do dpkg-buildpackage to build
> them locally (it'll complain and report missing dependencies if you
> haven't got everything you need).
>
> Feedback welcome although I've spotted a pile of things wrong in 5.3.0
> already. (samples docs in twice - that sort of thing).
>
> Wookey
-- next part --
A non-text attachment was scrubbed...
Name: Synaptic_screen.png
Type: image/png
Size: 36130 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20100607/c868bf1d/attachment.png>

[Therion] new snapshot - OSGB:ST

[Andrew Atkinson]

On 01/06/10 15:08, Martin Budaj wrote:

> * New coordinate system OSGB:ST is added (Andrew, please test it -- if
> it works fine, we will include other squares as well)

Works and entrances is within 12m on Google earth, but in different 
directions, however I doubt this is Therion, we have lots of checking to do.

Have used it to import survex 3d files and for fixing directly in .th file.

Thanks, this will make life easier for the group here.


Andrew

PS. Not urgent by any means, but could the Irish grid be added to the 
todo list, one of the projects I am involved in is County Claire, in 
Ireland.

[Therion] Irish Grid

[Andrew Atkinson]

As usual, you are ahead of me, I was referring to the IG, I did not know 
about the ITM, but I guess this will become more common as it is 
designed for GPS, however, we have lots of historic data which will be 
in the IG.

Andrew

On 07/06/10 10:25, Matthias Mansfeld wrote:
> On 7 Jun 2010 at 10:06, Andrew Atkinson wrote:
>
>> PS. Not urgent by any means, but could the Irish grid be added to the
>> todo list, one of the projects I am involved in is County Claire, in
>> Ireland.
>
> Please define which one. I assume the old one (Garmin GPS know it as
> "IG") which is used in most OSI maps and in the current literature.
> At least my GPS offered me both IG and ITM for Ireland.
>
> Best wishes
> Matthias
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] new snapshot - gone private

[Andrew Atkinson]

Doubt everyone needs to see this, so gone private


>
> Appears twice where? In the menus?

In Synaptic, as shown in the previous screen shot
>
> That could well be the case. Building loaclly from source will install
> versions in /usr/local/bin.

I think from the longer error file I got I did not install. The output 
was cut and past after using make

(the short version that you said contained no error was from
make > output.txt
Why did that not capture all the text?)

when trying to build from source I did try
checkinstall

on the hope it would put in Therion without loch, but when I ran Therion 
it was still the old version

Again here is the output from makefile, attached (hope this does not 
break what I have)

  Packaged versions witll go in /usr/bin.
> The /usr/local/bin version will take priority if you just run
> 'xtherion' or 'therion' so you may have been testing those...

/usr/local/bin is empty
>
> Best to remove the local versions (by just deleting all
> therion-related files under /usr/local - this is no neat way like
> there is with packages)
>
>> However the 5.3.3-1 properties both say maintained by Wookey, but why
>> the other 2 doubled up does not seem logical.
>
> No, you'll have to give more details to work out exactly what's what.

Here (search_results.txt) is a dump of all the files I get when I search 
for therion, does it help?


Andrew
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: search_results.txt
URL: 

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: output_checkinstall.txt
URL: 

[Therion] new snapshot

[Andrew Atkinson]

On trying to use the package

therion-viewer_5.3.3-1_amd64.deb


I get this

Error: Dependency is not satisfiable: libvtk5.4

on ubuntu 10.04

Andrew



On 07/06/10 04:07, Wookey wrote:
> OK. Highly preliminary packages uploaded to:
> http://wookware.org/software/therion/

[Therion] Disappearing menus in xtherion 5.3.3-1

[Andrew Atkinson]

Using the deb package Wookey built on Ubuntu 10.04

The menus disappear occasionally. I can find no logic to when or where 
(tend not to use menus very often.)
If I have more than one instance of therion open, there can be menus in 
one, and not in the other.

Andrew

[Therion] data nosurvey

[Andrew Atkinson]

Hi all

I have 2 stations connected by sight only so I tried

data nosurvey from to
   2.1 2.9

full file attached, which works with the 2 lines above commented out, 
but with them in I get the error

therion: error -- unsurveyed shot between unfixed stations -- 
StalPotInlet.th [95]

Which is true, they are not fixed any help connecting these 2 stations 
with a centreline, to show line of sight would be useful

thanks

Andrew
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: StalPotInlet.th
URL: 

[Therion] data nosurvey

[Andrew Atkinson]

Yep, that would work, but Therion is meant to work with the survex data 
formats, so the nosurvey should work. It looks a bit like a bug, or I am 
using wrongly. If no survey is not supported, that is fine, it is not 
critical.

My solution would be to put a false leg in and not that nearly hit and 
accept a small gap. This would not case any false distortion but I 
prefer the idea of nosurvey.

Andrew

On 10/06/10 21:19, Bruce wrote:
>> I have 2 stations connected by sight only so I tried
>
>> data nosurvey from to
>> 2.1 2.9
>
>
> Andrew
> I can only think of somewhat lateral solutions to this.
>
> 1. Make the measurements between the stations (You seem to be using a distoX
> based on the data format), or
>
> 2. Replace the nodata line with;
> station 2.1  "Can see stn 2.9 from here"
> and then make your drawings using Xtherion with this in mind, or
>
> 3. Make a guess at what the measurements are between the points, and do
> something like making your survey grade BCRA5 and then;
> group
>   grade BCRA3
>   
> endgroup
>
> If this distorts too much you could use sd to lower the dependence on the
> guessed data.  Based on my trials a year ago this can be very effective.
>
> Bruce
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Overview maps

[Andrew Atkinson]

Martin (or anyone else)

On this complex example from the wiki, there appear to be different 
scale maps of the same cave.

http://cachtice.speleo.sk/mapa_cj/template.html

I would like to do this to highlight a very complex junction of cave. So 
in a map I can offset by using

map_to_offset [50 0 m] below

Is there a way to double the scale of this section, or have you done it 
by putting it together in another program, which is fine, I just do not 
want to waste effort if it is something Therion will do.

thanks

Andrew

[Therion] Overview maps

[Andrew Atkinson]

Martin

Not sure I understand. So I have exported it at 1:5000 and would like it 
on a 1:1000. Currently I am exporting both then using Inkscape to put 
them together. Are you saying that, if I export at 1:5000 then when I do 
the 1:1000 export from therion, I can add it in at this stage?
If this is so, I am not looking for the right thing, as I cannot find 
anything on the wiki or thbook that I can see would do this?

thanks

Andrew

On 14/06/10 13:59, Martin Sluka wrote:
>
> On 14.6.2010, at 10:19, Andrew Atkinson wrote:
>
>> Is there a way to double the scale of this section, or have you done
>> it by putting it together in another program, which is fine, I just do
>> not want to waste effort if it is something Therion will do.
>
> Not directly, but if you export the map in different scale first, you
> may add it as picture/PDF to final export.
>
> m.
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Outside and inside

[Andrew Atkinson]

Okay this is a simple question, that after all these years I should have 
got in my head, but obviously not. I thought it was somewhere in the 
wiki or thbook, but I cannot find it now.

When drawing walls should the yellow 'tick' be on the inside or out?

Possibly more important, does it make a difference, all me pdfs are 
fine, but I have a problem with the kml.

Which leads to a question when is a space between passages a pillar? If 
this 'pillar' is defined over many survey trips and multiple scraps, is 
the only solution to use -outline in option? Which leads to a further 
question, what happens if I would like to produce output with one of the 
passages not included, ie not publish the picture to the whole world 
before giving a lecture at a conference.

The scenario is illustrated by the 2 attached images. The model shows 
what it should look like, the other is the kml on google earth with the 
passage on the right missing. Is the only way to get this to work as a 
kml, to define all the inside walls as outline in?

thanks in advance for the help

Andrew

PS If anyone is interested, all the help received has produced this 
output (8Mb)

http://www.ubss.org.uk/resources/surveys/survex/Charterhouse.lox

Lots of the 'smearing' is from made up surveys, constructed from old plans.

More project information available on

http://www.ubss.org.uk/cave_survey_archive.php
-- next part --
A non-text attachment was scrubbed...
Name: Model.png
Type: image/png
Size: 52720 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: kml.png
Type: image/png
Size: 451820 bytes
Desc: not available
URL: 

[Therion] Outside and inside

[Andrew Atkinson]

>
>> Which leads to a question when is a space between passages a pillar?
>> If this 'pillar' is defined over many survey trips and multiple
>> scraps, is the only solution to use -outline in option?
>
> Pillar and  has sence only in one scrap. If pillar is
> created by two or more scraps therion should recognize it correctly. You
> may use <-outline out -clip off> for line/s which ends gallery in
> concave form, or if pit should be transparent (IT IS transparent on a
> correct map).
>

Only in one scrap, that  makes sense logically, and has saved me lots of 
trial and error. But the real benefit has been it has allowed me to 
focus on the correct scrap to find the error, that I have now done, and 
have a working kml

thank you

Andrew

[Therion] Degrees: minutes in centreline

[Andrew Atkinson]

Hello

We have lots of old data that we are trying input to build up our area 
map. Lots of this data is in degrees and minutes.
When dealing with co-ordinates (lat-long) 52:34:23.2 works as 
degrees:minutes:seconds.
I cannot seem to be able to get this format to work for survey data, is 
there a way to use degrees:minutes, if not could it be added to the 
things to be implemented, it would save lots of spread sheet work 
converting it, and make checking back to the original data far easier 
for future users of the data

thanks

Andrew

[Therion] Wiki examples

[Andrew Atkinson]

So how do I register for the wiki? Instructions say go to the login box 
and then you can login/register, but I cannot seem to find a register button

thanks

Andrew

On 23/06/10 10:48, Bruce wrote:
> Your example would make a nice addition to the therion projects page
> http://therion.speleo.sk/wiki/doku.php?id=projeurope
>
> You might like to add it, or give permission for someone else to
>

[Therion] Degrees: minutes in centreline

[Andrew Atkinson]

sorry I have not been clear enough, yes it works with lat-long

it is when you try it in centreline it does not work

centreline
   data normal from to tape compass clino
   1 2 3.24 -6:50 1:50

thanks

Andrew

On 30/06/10 08:22, Martin Sluka wrote:
>
> On 30.6.2010, at 8:53, Andrew Atkinson wrote:
>
>> Hello
>>
>> We have lots of old data that we are trying input to build up our area
>> map. Lots of this data is in degrees and minutes.
>> When dealing with co-ordinates (lat-long) 52:34:23.2 works as
>> degrees:minutes:seconds.
>> I cannot seem to be able to get this format to work for survey data,
>> is there a way to use degrees:minutes, if not could it be added to the
>> things to be implemented, it would save lots of spread sheet work
>> converting it, and make checking back to the original data far easier
>> for future users of the data
>>
>> thanks
>>
>> Andrew
>>
>> ___
>> Therion mailing list
>> Therion at speleo.sk
>> http://mailman.speleo.sk/mailman/listinfo/therion
>
> It should be possible according Thbook:
>
> lat-long, long-lat ◃ latitude (N positive, S negative) and longitude (E
> positive,
> W negative) in given order in degrees (deg[:min[:sec]] allowed), WGS84
> datum. By
> default, not supported on output.
>
> 52:34.56461 ?
>
> m.
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Degrees: minutes in centreline

[Andrew Atkinson]

Thank you for confirming it should work, that allowed me to find my 
error else where.

However it has lead to another question, it seems to accept minutes 
larger than 60, (500 adds on 8 1/3 degrees as would be expected) should 
this not generate a warning at the very least?

thanks

Andrew



On 30/06/10 13:30, Stacho Mudrak wrote:
> This is very strange, so far I have tried it, it works on my computer.
> Can you send me exact description of an error that it generates when
> reading such a data? Or a minimaln sample that does not work?
>
> Thanks, S.
>
> On 30 June 2010 09:27, Andrew Atkinson  wrote:
>> sorry I have not been clear enough, yes it works with lat-long
>>
>> it is when you try it in centreline it does not work
>>
>> centreline
>>   data normal from to tape compass clino
>>   1 2 3.24 -6:50 1:50
>>
>> thanks
>>
>> Andrew
>>
>> On 30/06/10 08:22, Martin Sluka wrote:
>>>
>>> On 30.6.2010, at 8:53, Andrew Atkinson wrote:
>>>
>>>> Hello
>>>>
>>>> We have lots of old data that we are trying input to build up our area
>>>> map. Lots of this data is in degrees and minutes.
>>>> When dealing with co-ordinates (lat-long) 52:34:23.2 works as
>>>> degrees:minutes:seconds.
>>>> I cannot seem to be able to get this format to work for survey data,
>>>> is there a way to use degrees:minutes, if not could it be added to the
>>>> things to be implemented, it would save lots of spread sheet work
>>>> converting it, and make checking back to the original data far easier
>>>> for future users of the data
>>>>
>>>> thanks
>>>>
>>>> Andrew
>>>>
>>>> ___
>>>> Therion mailing list
>>>> Therion at speleo.sk
>>>> http://mailman.speleo.sk/mailman/listinfo/therion
>>>
>>> It should be possible according Thbook:
>>>
>>> lat-long, long-lat ◃ latitude (N positive, S negative) and longitude (E
>>> positive,
>>> W negative) in given order in degrees (deg[:min[:sec]] allowed), WGS84
>>> datum. By
>>> default, not supported on output.
>>>
>>> 52:34.56461 ?
>>>
>>> m.
>>> ___
>>> 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] distox

[Andrew Atkinson]

Bluetooth connection was a problem on one of the DistoX I have, 
sometimes it worked other times it did not ( as luck would have it, 
generally went I had taken it caving.) In the end the problem was the BT 
in the distoX, so we had to send it back to get a new one soldered on

Andrew

Wookey wrote:
> +++ marco corvi [2010-04-16 09:07 +0200]:
>> On Fri, 2010-04-16 at 04:49 +0100, Wookey wrote:
>> ...
>>> Here is a calib file. This one had 2 legs missing so has couple of
>>> extra 'downs' at the end. Not sure if that's fatal. If not could you
>>> send me back a set of numbers 
>> hi wookey,
>>
>> attached are the calibration coeffs of your disto.
>> calibration shots are well distributed over the directions.
>> max error is about 0.5 deg.
>> did not play to get it lower.
> 
> Thanx Marco. Beat's article on how to do the sums has now been
> published inthe CREG journal (I have a copy in front of me). So that
> means you can release the code and include it in topolinux.
> 
> I had some trouble getting bluetooth to work with the distoX and my
> openmoko and then failed to get topolinux to run with the version of
> stdlibc++ installed and actually talk to the bluetooth serial device,
> so I took my netbook underground to experiment with instead, but then
> failed to get bluetooth association even though it had been working
> justfine the evening before.
> 
> So I didn't get to try it underground usefully. But I can see that
> some changes to the interface would be helpful. Hopefully I'll have
> some more time to work on it in order to get it going usefully for this
> summer's expo.
> 
> Wookey

[Therion] Calibration of co-ordinate systems

[Andrew Atkinson]

Hi

I am having a little bit of difficulty with the various different helps 
on co-ordinate systems. I am building an area survey map from data from 
various different sources, so having to 'adapt' it, but really do not 
want to have to convert it all. It would be nice to have one of the 
outputs as .kml for google earth and the like.

Lots of the data is in Survex, with Local OSGB 6 figure grid references. 
These I have been importing eg

import Great_Swallet.3d -surveys use -filter great_swallet -cs 
EPSG:27700 -calibrate [0 0 0 299912 1 0]
#Should be -calibrate [0 0 0 30 10 0]

(goodness knows why the calibrate is not right, the bodge is to align it 
on goodle earth, probably my ignorance)


As most of the new data is in Pockettopo imported, into therion, is 
attached to the survex data this has worked well.
One cave entrance has been done in therion direct but I just dealt with 
that by doing the calibrate manually

I have now been sent lots of data with lots (60 fix #ed points or more) 
of cave entrances, all in therion with local 6 figure grid references.

I can set the coordinate system to EPSG:27700 by adding it within the 
centreline/endcentre, but that puts the cave in the Atlantic somewhere. 
So using
centreline -cs EPSG:27700 -calibrate [0 0 0 299912 1 0]
gives the error

not enough option arguments -- -calibrate -- must be 2

Which is fair enough as calibrate is already used in the centreline for 
correcting a zero error.

Not to be easily put off I tried it the other way round, remove the 
calibrate from the centreline and use

cs EPSG:27700 in the config files to get therion to output in these 
coordinates, however although I can get the caves relatively next to 
each other, the kml puts them in the Atlantic again and

cs EPSG:27700 -calibrate [0 0 0 299912 1 0]

gives error

output coordinate system specification requires single parameter


and

cs EPSG:27700
calibrate [0 0 0 299912 1 0]

gives error

unknown configuration command -- calibrate

Have I missed something or do I need to go through and add 30 and 
10 to all the fixed points. If this is so, could we have a 
calibratecs to use with the cs command to overcome localised coordinates 
on a national grid, the UK cannot be the only country with this problem, 
and it must be easier to work mainly in the more localised coordinates 
and calibrate it on output

hope this all makes sense,

Andrew

[Therion] Calibration of co-ordinate systems

[Andrew Atkinson]

I will try to explain a little more to help clarify. (we will ignore te 
uneven numbers for now to stick to one topic)

In the OSGB it is typical to quote 10 figure grid references to fix a 
location to 1m EG
47130 56380

Strictly this identifies a location within a 100km square the is 
referred to with a 2 letter code so the above should be

ST 47130 56380

However, it is common to miss out the ST if it is clear what area you 
are talking about, ie a Mendip cave.


Now these 10 figure grid references are fine for putting systems 
together, however to get a kml output, in the right place, I need to add 
30 1 which I can do, but makes the files a bit confusing to 
people that do not understand co-ordinate systems. (And I am trying to 
get lots of people to be able to contribute to the area map, so 
simplicity is important)

Now when importing a 3d file it is possible to use calibrate option to 
add the 30 10 but I cannot find a way to do this to all the th 
files I have, so I would have to go through all the fixed stations and 
do it manually.

It would seem sensible to be able to work in these local co-ordinates 
until the output of the kml and then do the a calibrate to add the 3 
1. (I am sure there must be similar situations in other countries.)
I am hoping there is a way to do this and I am just been incapable of 
finding it. From other function is Therion such as prefix etc, it would 
seem to fit the pattern of construction.

(It is simple to do it manually if it is 3 1 but if it is 299912 
1 it will be far more tedious)

hope this is clearer and a solution that does not involve me manually 
editing tens of fixed locations is possible

thanks

Andrew

Wolfgang Zillig wrote:
> Hi Andrew,
> 
> I'm not sure if I understand your problem correctly. There is on issue 
> with the EPSG codes for OSGB36, see:
> http://osgeo-org.1803224.n2.nabble.com/EPSG-27700-td4469120.html
> and
> http://www.osgeo.org/pipermail/grass-user/2009-July/051494.html
> 
> But this could explain your uneven numbers in the calibrate command. Can 
> it be that the coordinate fix misses some leading numbers? The skipping 
> is sometimes common to avoid huge numbers. Can you check this by 
> converting some coordinates from WGS84 (for instance) to OSGB36?
> 
> Best regards
> Wolfgang
> 
> Am 17.05.2010 23:17, schrieb Andrew Atkinson:
>> Hi
>>
>> I am having a little bit of difficulty with the various different 
>> helps on co-ordinate systems. I am building an area survey map from 
>> data from various different sources, so having to 'adapt' it, but 
>> really do not want to have to convert it all. It would be nice to have 
>> one of the outputs as .kml for google earth and the like.
>>
>> Lots of the data is in Survex, with Local OSGB 6 figure grid 
>> references. These I have been importing eg
>>
>> import Great_Swallet.3d -surveys use -filter great_swallet -cs 
>> EPSG:27700 -calibrate [0 0 0 299912 1 0]
>> #Should be -calibrate [0 0 0 30 10 0]
>>
>> (goodness knows why the calibrate is not right, the bodge is to align 
>> it on goodle earth, probably my ignorance)
>>
>>
>> As most of the new data is in Pockettopo imported, into therion, is 
>> attached to the survex data this has worked well.
>> One cave entrance has been done in therion direct but I just dealt 
>> with that by doing the calibrate manually
>>
>> I have now been sent lots of data with lots (60 fix #ed points or 
>> more) of cave entrances, all in therion with local 6 figure grid 
>> references.
>>
>> I can set the coordinate system to EPSG:27700 by adding it within the 
>> centreline/endcentre, but that puts the cave in the Atlantic 
>> somewhere. So using
>> centreline -cs EPSG:27700 -calibrate [0 0 0 299912 1 0]
>> gives the error
>>
>> not enough option arguments -- -calibrate -- must be 2
>>
>> Which is fair enough as calibrate is already used in the centreline 
>> for correcting a zero error.
>>
>> Not to be easily put off I tried it the other way round, remove the 
>> calibrate from the centreline and use
>>
>> cs EPSG:27700 in the config files to get therion to output in these 
>> coordinates, however although I can get the caves relatively next to 
>> each other, the kml puts them in the Atlantic again and
>>
>> cs EPSG:27700 -calibrate [0 0 0 299912 1 0]
>>
>> gives error
>>
>> output coordinate system specification requires single parameter
>>
>>
>> and
>>
>> cs EPSG:27700
>> calibrate [0 0 0 299912 1 0]
>>
>> gives error
>>
>> unknown configuration command -- calibrate
>>
>>

[Therion] Calibration of co-ordinate systems

[Andrew Atkinson]

On 27/05/10 13:29, Martin Budaj wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:17 PM, Andrew Atkinson  
> wrote:
>> import Great_Swallet.3d -surveys use -filter great_swallet -cs EPSG:27700
>> -calibrate [0 0 0 299912 1 0]
>> #Should be -calibrate [0 0 0 30 10 0]
>>
>> (goodness knows why the calibrate is not right, the bodge is to align it on
>> goodle earth, probably my ignorance)
>
> Which therion version are you using? Recent versions include geodetic
> datum shift parameter which should eliminate the 90-m difference.

5.28 on ubuntu. Wookey has said that he is trying to update the 
repository, so I am waiting to be the crash dummy..
But the datum shift would explain one of the jumps we got, however we 
still seem to get jumps (google earth), on the same version with no 
change to the cs, calibration (3d files) or the fixed points. This is 
something I do not understand. Generally all the entrances are off by 
the same amount, so I can go and adjust them, but it is tedious, 
especially when the jump a few months latter (possibly when google earth 
is updated?)
Maybe this indicates a calibrate for cs when used as output will still 
be needed, even with the solution below, although in reality it should 
not be.
>
>> cs EPSG:27700 -calibrate [0 0 0 299912 1 0]
>>
>> gives error
>>
>> output coordinate system specification requires single parameter
>
> It is not possible to modify cs using 'calibrate' option.
>
> I guess your problem could be solved by defining custom Proj4
> coordinate system. For ST square it should be
>
> +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=10
> +y_0=-20 +ellps=airy +datum=OSGB36 +units=m +no_defs
>
> Currently the 'cs' command doesn't accept custom Proj4 specifications
> like the one given above (this funcionality will be added as soon as
> possible), so the easiest way to add this projection is to modify
> thcsdata.tcl and recompile therion.
>
> In thcsdata.tcl just duplicate line 52 (s-merc projection) and replace
> 's-merc' with e.g. OSGBST and proj4 specification with the
> specification given above.
>
> Then use cs OSGBST in your data.
>

Thanks Martin, sounds like another good solution. I think that I will 
wait for the ability to customise proj4. I have already been through an 
adjusted them by hand. Plus this is a project spread over lots of cavers 
and clubs (SVN is wonderful, most of the time!) and everyone having to 
compile from source would be a pain (I have to go round and install the 
software as it is...)

thanks

Andrew

[Therion] surface and loch

[Andrew Atkinson]

That would be brilliant.

Then the only essential feature I think that is missing from a cave 
viewer is the measuring tool

Andrew



On 04/11/10 18:07, Bruce wrote:
> marco
> I presume you are saying Loch can cope with one DEM and many surface images
> in the same model??
>
> Yes, it would be much more convenient to toggle between each of the loaded
> surface images, and even perhaps select which of the multiple images to
> display simultaneously.  This would save having to export with separate runs
> (and manage) the 3 or 4 Loch files I currently make for each area (topo map,
> geology map, air photos etc).
>
> It gets my vote.
>
> bruce
>
> -Original Message-
> From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On 
> Behalf
> Of marco corvi
> Sent: Thursday, 4 November 2010 11:35 p.m.
> To: therion at speleo.sk
> Subject: [Therion] surface and loch
>
> therion accepts mere than one surface command, ie, many surfaces.
> the loch export writes all of them.
>
> loch reads all of them, and displays only the first ...
> but it is "ready" to display all of them.
>
> it would be nice to have all displayed ...
> possibly cropped to stay beneath one "special" surface, say the DEM.
>
> marco
>
> ___
> 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] label -place bottom

[Andrew Atkinson]

Hello

As can be seen from the attached screenshot, the label "box" is clipping 
the passage wall. To try to overcome this, as space is tight, I have 
added the option of -place bottom. However, the result is same.

Am I doing something wrong, misunderstanding the use or possibly a bug?

The thbook says that clip on is not an option for labels (and it 
complains if you try to add it as you would expect.) Is there another 
solution?

Therion 5.3.3 (the debian build) on Ubuntu
Also tested on 5.3.4 on Windows 7

thanks

Andrew


-- next part --
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 7348 bytes
Desc: not available
URL: 

[Therion] label -place bottom

[Andrew Atkinson]

>
> (Gloop Pot doesn't make the place sound very inviting so perhaps you are
> better off with no label!)
>

Gloop Pot is named after the noise it makes, it is the Narrows that 
follow that are not inviting

Andrew

[Therion] Possible opacity offset bug

[Andrew Atkinson]

Hi

The file individually.png, shows a section of passage that when run by 
itself greys out 2 of the lines either side of the traverse.

However, when compiled in the full survey it an offset part of the cave, 
and the lines are in full black.

What looks to be happening: If these lines were not displaced they would 
be under another passage, and therefore all be the same shade of grey. 
When they are offset they are all returned to full black?

Or am I missing a trick?

thanks

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: together_and_displaced.png
Type: image/png
Size: 64254 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: individually.png
Type: image/png
Size: 34385 bytes
Desc: not available
URL: 

[Therion] Possible opacity offset bug

[Andrew Atkinson]

Might be normal, however, it does not seem right!

Thank for the hint on subtype, I will look at that next week, just 
getting ready to teach 12 people how to use Therion

hope it is not the blind leading the blind

Andrew

On 12/11/10 17:06, Martin Sluka wrote:
> It is normal I think, add the lines to be clear from where the offset
> part is. Check line subtype map-connection
>
> Martin
>
>
> On 12.11.2010, at 14:45, Andrew Atkinson wrote:
>
>> Hi
>>
>> The file individually.png, shows a section of passage that when run by
>> itself greys out 2 of the lines either side of the traverse.
>>
>> However, when compiled in the full survey it an offset part of the
>> cave, and the lines are in full black.
>>
>> What looks to be happening: If these lines were not displaced they
>> would be under another passage, and therefore all be the same shade of
>> grey. When they are offset they are all returned to full black?
>>
>> Or am I missing a trick?
>>
>> 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
>

[Therion] Possible opacity offset bug

[Andrew Atkinson]

Stacho

Thanks, yet again, for being so diligent. Glad to here that it is my 
dataset, I will have to continue to play until I get it right

Andrew

On 15/11/10 09:09, Stacho Mudrak wrote:
> Well, I do not have your dataset, but when I tried to reproduce it, I was not
> able.
>
> It means, when the map is in offset and there are two overlying scraps, the 
> one
> below is gray. See attached dataset.
>
> All you need to do, is probably to play with "breaks" in "map" a little bit.
>
> HTH, S.
>
> Quoting Andrew Atkinson:
>
>> Might be normal, however, it does not seem right!
>>
>> Thank for the hint on subtype, I will look at that next week, just
>> getting ready to teach 12 people how to use Therion
>>
>> hope it is not the blind leading the blind
>>
>> Andrew
>>
>> On 12/11/10 17:06, Martin Sluka wrote:
>>> It is normal I think, add the lines to be clear from where the offset
>>> part is. Check line subtype map-connection
>>>
>>> Martin
>>>
>>>
>>> On 12.11.2010, at 14:45, Andrew Atkinson wrote:
>>>
>>>> Hi
>>>>
>>>> The file individually.png, shows a section of passage that when run by
>>>> itself greys out 2 of the lines either side of the traverse.
>>>>
>>>> However, when compiled in the full survey it an offset part of the
>>>> cave, and the lines are in full black.
>>>>
>>>> What looks to be happening: If these lines were not displaced they
>>>> would be under another passage, and therefore all be the same shade of
>>>> grey. When they are offset they are all returned to full black?
>>>>
>>>> Or am I missing a trick?
>>>>
>>>> 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
>>>
>> ___
>> 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] Source and Select

[Andrew Atkinson]

Your suggested solution, is what I do, for 3d, and it works, but I have 
not used lists yet. However, it would be nice to be able to select a map 
and only get a centreline with this would be good, but I suspect too 
much work for it to be worth while. (plus lots of decisions about what 
exactly would appear in the output

Andrew

On 16/11/10 09:08, Bruce wrote:
> My reading of the Therion Book suggests to me;
>
> - that ‘source’ specifies the files that Therion should read and process
> before deciding what to export. The source files should contain or
> reference surveys and or a surface.
>
> - that ‘select’ chooses which survey(s) and or map(s) from the above
> files to export. If there is no ‘select’ statement then ‘all’ are 
> exported.
>
> My interpretation #1 is that this should allow all the surveys of a
> large (or modest) system of cave passages to be referenced by way of
> ‘source’ so that all the survey loop and scrap join distortions can be
> processed BEFORE Therion decides what to export. This is what seems to
> occur. So far, so good.
>
> My interpretation #2 is that when a map or maps for any particular
> projection is ‘selected’ then ONLY the data that relates to those maps
> should be exported. This is what seems to happen for Map outputs (pdf
> and ?kml) and Atlas outputs.
>
> I have some difficulty and confusion with outputs that don’t have a
> projection, such as the lists, 3d outputs and database. What seems to
> happen is that regardless of the ‘selected’ maps, all of the ‘sourced’
> data is exported to this type of output.
>
> What I would like is that only the data related to the ‘selected’ maps
> are exported. This way all subset outputs can be consistent (same loop
> closure distortions applied), and separately exported.
>
> In writing this out I suspect I may have realised the answer to my
> question (but not yet tested it). Perhaps what I need to do is ‘select’
> survey(s) that encompass the same part of the cave as the maps?
>
> Any insights or clarifications gratefully received.
>
> Bruce
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] 5.3.5 packaged for Debian - please test

[Andrew Atkinson]

On Ubuntu 10.04 with therion 5.3.3 (debian package also from your 
webpage) already installed get the error

Error: Dependency is not satisfiable: libjpeg62 (>= 6b1)

Checking Synaptic

libjpeg62 is there (and installed) and is version 6b-15ubuntu1

Andrew

On 17/11/10 03:06, Wookey wrote:
> I've packaged the current unstable release 5.3.5 for Debian testing
> (squeeze). Do please try it out and tell me how it works for you -
> especially if you have an intel graphics card and had problems with
> Loch crashing in the past.
>
> In 5.3.3 textures were disabled in order to have loch run on intel
> cards, but at least on this machine I have access to, this problem
> seems to have gone away so I have re-enabled it. Hopefully it was a
> VT/mesa bug. But I'd like to know how it works for other people.
>
> And do of course whinge if you see other issues such as documentation
> bugs. There does seem to be a problem with Loch and xtherion not
> appearing on menus, at least with XFCE, which I need to investigate.
> (desktopand application files are present)
>
> The packages are here for the time being:
> http://wookware.org/software/therion/
>
> Once feedback is satisfactory these will be uploaded to Debian
> experimental and my Ubuntu PPA.
>
> Martin/Stacho - the new v3.0 source format (quilt patches) makes it a
> lot easier to see what's been changed. Do please peruse the patches as
> several of them could usefully go upstream.
> 10changelog.patch
> 30doc-fixes.patch
> 35loch-manpage.patch
> 40samples-fixes.patch
> 82-nolang-segfault-fix.patch
>
> Note that I have nobbled a
> lot of "warning: deprecated conversion from string constant to
> ‘char*’" by using -Wno-write-strings but these should probably be
> fixed properly. There are also a few build warnings remaining:
>
> ++ -c -Wall -DTHLINUX -O2 -o thimport.o thimport.cxx
> thimport.cxx: In member function ‘void thimport::import_file_img()’:
> thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fz’ may be used 
> uninitialized in this function
> thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fy’ may be used 
> uninitialized in this function
> thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fx’ may be used 
> uninitialized in this function
>
> ++ -c -Wall -DTHLINUX -O2 -o thepsparse.o thepsparse.cxx
> thepsparse.cxx: In function ‘void parse_eps(std::string, std::string, 
> double, double, double&, double&, double&, double&, converted_data&, double, 
> double, double)’:
> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[5]’ may be 
> used uninitialized in this function
> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[4]’ may be 
> used uninitialized in this function
> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[3]’ may be 
> used uninitialized in this function
> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[2]’ may be 
> used uninitialized in this function
> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[1]’ may be 
> used uninitialized in this function
> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[0]’ may be 
> used uninitialized in this function
>
> ++ -c -Wall -DTHLINUX -O2 -o thattr.o thattr.cxx
> thattr.cxx: In member function ‘void thattr::export_html(const char*, 
> int)’:
> thattr.cxx:732: warning: format ‘%u’ expects type ‘unsigned int’, but 
> argument 3 has type ‘size_t’
>
>
> Wookey

[Therion] 5.3.5 packaged for Debian - please test

[Andrew Atkinson]

Sorry

Seem to have deleted the first lines, so the below need this information


The Therion package works fine.
For http://wookware.org/software/therion/therion-viewer_5.3.5-1_amd64.deb

On 19/11/10 12:03, Andrew Atkinson wrote:
> On Ubuntu 10.04 with therion 5.3.3 (debian package also from your
> webpage) already installed get the error
>
> Error: Dependency is not satisfiable: libjpeg62 (>= 6b1)
>
> Checking Synaptic
>
> libjpeg62 is there (and installed) and is version 6b-15ubuntu1
>
> Andrew
>
> On 17/11/10 03:06, Wookey wrote:
>> I've packaged the current unstable release 5.3.5 for Debian testing
>> (squeeze). Do please try it out and tell me how it works for you -
>> especially if you have an intel graphics card and had problems with
>> Loch crashing in the past.
>>
>> In 5.3.3 textures were disabled in order to have loch run on intel
>> cards, but at least on this machine I have access to, this problem
>> seems to have gone away so I have re-enabled it. Hopefully it was a
>> VT/mesa bug. But I'd like to know how it works for other people.
>>
>> And do of course whinge if you see other issues such as documentation
>> bugs. There does seem to be a problem with Loch and xtherion not
>> appearing on menus, at least with XFCE, which I need to investigate.
>> (desktopand application files are present)
>>
>> The packages are here for the time being:
>> http://wookware.org/software/therion/
>>
>> Once feedback is satisfactory these will be uploaded to Debian
>> experimental and my Ubuntu PPA.
>>
>> Martin/Stacho - the new v3.0 source format (quilt patches) makes it a
>> lot easier to see what's been changed. Do please peruse the patches as
>> several of them could usefully go upstream.
>> 10changelog.patch
>> 30doc-fixes.patch
>> 35loch-manpage.patch
>> 40samples-fixes.patch
>> 82-nolang-segfault-fix.patch
>>
>> Note that I have nobbled a
>> lot of "warning: deprecated conversion from string constant to
>> ‘char*’" by using -Wno-write-strings but these should probably be
>> fixed properly. There are also a few build warnings remaining:
>>
>> ++ -c -Wall -DTHLINUX -O2 -o thimport.o thimport.cxx
>> thimport.cxx: In member function ‘void thimport::import_file_img()’:
>> thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fz’ may be used
>> uninitialized in this function
>> thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fy’ may be used
>> uninitialized in this function
>> thimport.cxx:440: warning: ‘tmpshot.thimg_shot::fx’ may be used
>> uninitialized in this function
>>
>> ++ -c -Wall -DTHLINUX -O2 -o thepsparse.o thepsparse.cxx
>> thepsparse.cxx: In function ‘void parse_eps(std::string, std::string,
>> double, double, double&, double&, double&, double&, converted_data&,
>> double, double, double)’:
>> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[5]’ may be
>> used uninitialized in this function
>> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[4]’ may be
>> used uninitialized in this function
>> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[3]’ may be
>> used uninitialized in this function
>> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[2]’ may be
>> used uninitialized in this function
>> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[1]’ may be
>> used uninitialized in this function
>> thepsparse.cxx:527: warning: ‘fntmatr.MP_transform::transf[0]’ may be
>> used uninitialized in this function
>>
>> ++ -c -Wall -DTHLINUX -O2 -o thattr.o thattr.cxx
>> thattr.cxx: In member function ‘void thattr::export_html(const char*,
>> int)’:
>> thattr.cxx:732: warning: format ‘%u’ expects type ‘unsigned int’, but
>> argument 3 has type ‘size_t’
>>
>>
>> Wookey
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] point remark - possible context problem

[Andrew Atkinson]

Hello

I have been trying to turn off the remarks in the pdf output, having 
successfully turned off lots of other things. However in the layout using

symbol-hide point remark

does not seem to work

neither does

symbol-hide group all
symbol-show point label
symbol-show line label

(as an aside should there not be a group for labels?? Not that it is 
problem really)

However if on the  remark as an option you add

-context point remark

both of the above seem to work.

Should point remark not be in its own context by default? Is this a bug 
or am I missing something?

thanks

Andrew

[Therion] Magazine printing of surveys from Therion

[Andrew Atkinson]

Hi

We are trying to send our Charterhouse survey to Descent for 
publication. Chris Howes, the editor, would love to have an output he 
can use directly, but as yet this is not to be.

Over a series of emails here are some of the points that he has made. I 
hope I have not taken them out of context in editing them down to a 
single email. (I also accept some of the comments may come from the fact 
I do not understand some of the features of Therion or some of the 
terminology) Hope this is useful for future development


1
My problem was that if I'm using colour on a page, I often use a tinted
background and/or run bits of survey across a photo corner or something 
(or even over a graphic) as part of my layout. But if there is 
transparency in the fill, I can't do that. What's needed is for no 
transparency to be used in 'normal' fills = all passages, but instead a 
solid colour. For overlying bits, transparency is fine for the upper 
section, but not the lower.

Transparency for all 'non cave' bits = the background *should* be
transparent of course.

2
Another oddity - there seemed to be a lot of non-stroked detail/bits way off
the passages/survey that don't show up but are selectable. Doesn't seem to
affect anything and I can't even see them, but only spot that *something* is
there when trying to select the image. Odd - not a problem (as far as I
know) but as this is a report on what happens here, I thought I'd mention
it.

3a (svg with walls and lables only, no passage fill colour)

I can change the line weight
okay, but as I hit as a problem before when working on files like this, 
the paths don't seem to stay as a path (text, for example, aren't words 
but just single letters) and I can't figure out how to do a fill to add 
colour to the passage content. That is, if there is a colour there, I'm 
pretty sure I can change it but I can't select enough to actually add a 
fill in the first
place.

3b (svg with only cross section switched off)
The detailed view won't open correctly in Illustrator - there are warnings
about too many nested groups (surprising considering the complexity of the
.svg files for the Three Counties that are in the next issue, which breezed
through) and that it might not look correct, then it opens with most of the
content missing (the only bit that appears fully intact is at the extreme
bottom and only for a few metres). Needed for this I think/suspect: some
work in flattening/decreasing grouping in the original before creating the
.svg, but I don't have experience of the creating package (nor any other
vector software).

3c (pdf with cross sections off)
Having imported the pdf to Illustrator, as I mentioned already evident 
is that the file has been simplified by having taken that route, rather 
than the svg. At least, that's my assumption as it opened without 
warning about groups, as opposed to opening without any real content 
remaining.

[Therion] Magazine printing of surveys from Therion

[Andrew Atkinson]

Chris cannot reply directly to the list so I will have to be intermediary

I can turn a pdf (or any vector file) into a 'usable' file by 
rasterising it. I often do. I can set the ppi when doing so at whatever 
I wish, so that is not a difficulty. But, for this purpose:

1. The file itself is too massive to be used - we are talking hundreds 
of mb here (after sizing for the page)

2. It is no longer editable, thus removing the whole point of the 
exercise. It will rastorise with the same parameters as the native file 
- I won't be able to edit the line thickness, in particular, not any 
other element (which is the whole point of wanting the .ai file to 
work). Rastored files are actually my first stage when I redraw surveys, 
so I can use them to create my own file - it's what I base that work on, 
so I'm well used to their benefits and limitations. For this, it doesn't 
work.

I think that point 1 in your mail to the therion group might mislead 
some - this factor of transparency must be one that is under the control 
of the person creating the file (the choice of using transparency or a 
solid colour) and not a restriction of the package. I suspect it is 
something that is easy to do to create an effect and, reasonably, it is 
therefore done ...
But doesn't help if the aim is print on paper by a third party (me!).

Chris


On 21/07/10 09:04, Martin Sluka wrote:
> Andy, try to rasterize PDF in Photoshop to 360 or 240 or 180 dpi
> (depending on scale you need to reduce size). It will reduce all
> problems with too huge vector formats.
>
> Martin
>
> On 21.7.2010, at 9:58, Andrew Atkinson wrote:
>
>> Hi
>>
>> We are trying to send our Charterhouse survey to Descent for
>> publication. Chris Howes, the editor, would love to have an output he
>> can use directly, but as yet this is not to be.
>>
>> Over a series of emails here are some of the points that he has made.
>> I hope I have not taken them out of context in editing them down to a
>> single email. (I also accept some of the comments may come from the
>> fact I do not understand some of the features of Therion or some of
>> the terminology) Hope this is useful for future development
>>
>>
>> 1
>> My problem was that if I'm using colour on a page, I often use a tinted
>> background and/or run bits of survey across a photo corner or
>> something (or even over a graphic) as part of my layout. But if there
>> is transparency in the fill, I can't do that. What's needed is for no
>> transparency to be used in 'normal' fills = all passages, but instead
>> a solid colour. For overlying bits, transparency is fine for the upper
>> section, but not the lower.
>>
>> Transparency for all 'non cave' bits = the background *should* be
>> transparent of course.
>>
>> 2
>> Another oddity - there seemed to be a lot of non-stroked detail/bits
>> way off
>> the passages/survey that don't show up but are selectable. Doesn't
>> seem to
>> affect anything and I can't even see them, but only spot that
>> *something* is
>> there when trying to select the image. Odd - not a problem (as far as I
>> know) but as this is a report on what happens here, I thought I'd mention
>> it.
>>
>> 3a (svg with walls and lables only, no passage fill colour)
>>
>> I can change the line weight
>> okay, but as I hit as a problem before when working on files like
>> this, the paths don't seem to stay as a path (text, for example,
>> aren't words but just single letters) and I can't figure out how to do
>> a fill to add colour to the passage content. That is, if there is a
>> colour there, I'm pretty sure I can change it but I can't select
>> enough to actually add a fill in the first
>> place.
>>
>> 3b (svg with only cross section switched off)
>> The detailed view won't open correctly in Illustrator - there are
>> warnings
>> about too many nested groups (surprising considering the complexity of
>> the
>> .svg files for the Three Counties that are in the next issue, which
>> breezed
>> through) and that it might not look correct, then it opens with most
>> of the
>> content missing (the only bit that appears fully intact is at the extreme
>> bottom and only for a few metres). Needed for this I think/suspect: some
>> work in flattening/decreasing grouping in the original before creating
>> the
>> .svg, but I don't have experience of the creating package (nor any other
>> vector software).
>>
>> 3c (pdf with cross sections off)
>> Having imported the pdf to Illustrator, as I mentioned already evident
>> is that the file has been simplified by having taken that route,
>

[Therion] -size -r-size and -l-size on line label

[Andrew Atkinson]

On page 68 of the Therion book

Customizing text labels
There is a preliminary interface to changing font sizes for labels via 
the METAPOST
macro
fonts_setup();
which may be used inside of the code metapost section of the layout 
command. 
applies to point label,  applies to remark and all other 
point labels.
Each of them may apply to line label according to its -size option.
Example:
code metapost
fonts_setup(6,8,10,14,20);
% default values depend on scale; for 1:200 they are 7,8,10,12,14

Now this works well when I have used -scale m etc on the line label. But 
as I changes text sizes it sometimes overlaps the passage, as it seems 
to use the line as a centre. so I wanted to try something cleverer, 
similar to the -align available with point label, align only works with 
points

and on page 26 it gives me this

size  ◃ line width (left and right sizes are set to one half of 
this value)
r-size  ◃ size of the line to the right
l-size  ◃ same to the left. Required for slope type.

Which suggests to me, with page68, that I should be able to use

-r-size normalsize

which would  put the text on the right side only

but got the error

no line point specified
(tried adding -l-size 0 just in case this was needed, but same error)

Also checked by adding a number as well eg

-r-size 20

but same error.

Am I trying to misuse this option? If not what am I missing?



If I have not interpreted this right, is there a way to make the text 
only be on the left or right of the line


thanks

Andrew

[Therion] Magazine printing of surveys from Therion

[Andrew Atkinson]

I have just started on the metapost journey, expect some more mails

I have been using the base-scale trick,

thanks

Andrew

On 21/07/10 13:15, Martin Budaj wrote:
> On Wed, Jul 21, 2010 at 10:39 AM, Andrew Atkinson  
> wrote:
>> 2. It is no longer editable, thus removing the whole point of the exercise.
>> It will rastorise with the same parameters as the native file - I won't be
>> able to edit the line thickness, in particular, not any other element (which
>
> You can also consider changing line width in therion (metapost)
> directly. The easiest way is to play with base-scala and scale
> combinations in layout.
>
> Martin
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Colour fill problems

[Andrew Atkinson]

Hmm the problem deepens, by itself it works fine. I have attached it.

but when run with the rest it gives this problem.

I have also attached the thconfig I am using to run the whole lot, and 
the common layout that it builds on.

I am happy to make available the full data set, but will not have time 
before I go away, it will have to be done in September, or possibly 
Graham can get it to you if it helps.

This is not the only part of the pdf that has this. Also attached

Andrew

On 22/07/10 10:55, Martin Sluka wrote:
> May you send the th2 file?
>
> m.
>
>
> On 22.7.2010, at 11:32, Andrew Atkinson wrote:
>
>> Hi
>>
>> Can I fix the patch of white on the right, inside? The wall has the
>> tick on the air side, and it is all in one scrap. I have tried to
>> break the wall down into small pieces, but it gives exactly the same
>> result?
>>
>> There are no Warning: scrap outline intersects itself in scrap
>>
>> (well not in any of the scraps that make up that area of cave)
>>
>> Which seems to be the closest thing I can find in the thbook or wiki
>>
>> Any other ideas?
>>
>> 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 --
A non-text attachment was scrubbed...
Name: Rip_Rift2.zip
Type: application/zip
Size: 17972 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20100722/cf3299e0/attachment.zip>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: common_layout.th
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20100722/cf3299e0/attachment.ksh>
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: thconfig
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20100722/cf3299e0/attachment-0001.ksh>
-- next part --
A non-text attachment was scrubbed...
Name: Charterhouse.pdf
Type: application/pdf
Size: 860421 bytes
Desc: not available
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20100722/cf3299e0/attachment.pdf>

[Therion] Colour fill problems

[Andrew Atkinson]

Removed them, however, still the same problem.

Are empty objects a problem. I remove them when I see them, but 
generally do not worry about it too much.

Andrew

On 22/07/10 18:03, Martin Sluka wrote:
> Andy,
>
> check first the Rip_Rift2.th2 file for empty objects. TI found four of
> them on lines:
>
> 708-709
> 835-836
> 1190-1191
> 1461-1462
>
> Erase them manualy and try the compilation again.
>
> What version of Therion do you use?
>
> Martin
>
> On 22.7.2010, at 14:45, Andrew Atkinson wrote:
>
>> Hmm the problem deepens, by itself it works fine. I have attached it.
>>
>> but when run with the rest it gives this problem.
>>
>> I have also attached the thconfig I am using to run the whole lot, and
>> the common layout that it builds on.
>>
>> I am happy to make available the full data set, but will not have time
>> before I go away, it will have to be done in September, or possibly
>> Graham can get it to you if it helps.
>>
>> This is not the only part of the pdf that has this. Also attached
>>
>> Andrew
>>
>> On 22/07/10 10:55, Martin Sluka wrote:
>>> May you send the th2 file?
>>>
>>> m.
>>>
>>>
>>> On 22.7.2010, at 11:32, Andrew Atkinson wrote:
>>>
>>>> Hi
>>>>
>>>> Can I fix the patch of white on the right, inside? The wall has the
>>>> tick on the air side, and it is all in one scrap. I have tried to
>>>> break the wall down into small pieces, but it gives exactly the same
>>>> result?
>>>>
>>>> There are no Warning: scrap outline intersects itself in scrap
>>>>
>>>> (well not in any of the scraps that make up that area of cave)
>>>>
>>>> Which seems to be the closest thing I can find in the thbook or wiki
>>>>
>>>> Any other ideas?
>>>>
>>>> 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
>>>
>> ___
>>
>> 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] Colour fill problems

[Andrew Atkinson]

Bruce

I really must simplify the file, possible by slitting it for the 
different things I am trying to do, it is getting messy.

Any way put the quote sign bay in, unfortunately still there, although 
the passage has changed colour!

Andrew

On 22/07/10 21:58, Bruce wrote:
> May or may not be related to the issue, but there is a quote missing at the
> end of the map-comment in thconfig.txt
>
> My experience is that this type of error can sometimes have very subtle
> effects.
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Colour fill problems

[Andrew Atkinson]

>
> What version of Therion do you use?
>

5.3.3

The version downloaded directly from Wookey's site. Built for Debian 
running on Ubuntu 10.04

Andrew

[Therion] Colour fill problems

[Andrew Atkinson]

The really strange thing is that it does not do it if I only process the 
one file, only when I put more together does it do it!

Oh well it will have to go to print as is, thanks for your help

Andrew



On 23/07/10 08:28, Martin Sluka wrote:
> It is really very strange, because there is no any reason for therion to
> "shortcut" the line. I checked these lines in your th2 file and there is
> no any additional point, nothing strange.
>
> Stacho?
>
> Martin
>
> On 23.7.2010, at 9:13, Andrew Atkinson wrote:
>
>>
>>>
>>> What version of Therion do you use?
>>>
>>
>> 5.3.3
>>
>> The version downloaded directly from Wookey's site. Built for Debian
>> running on Ubuntu 10.04
>>
>> 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
>

[Therion] Length & Depth differ

[Andrew Atkinson]

On 07/09/10 10:38, Bruce wrote:
> Has anyone noticed that cave lengths and depths reported by the textual
> (survey-list and cave-list) exports sometimes differ from the length and
> depth reported by the map (pdf) export, even when all these outputs are
> produced with the same thconfig run?
>

Yes, in the therion compiler window, I am getting

length: 4156.16m (surface 0.00m, duplicated 477.89m)

but the pdf is reporting 3744m

For a minute I thought that I had been missunderstanding the duplicates 
but a quick check with one of my other surveys


length: 212.77m (surface 0.00m, duplicated 433.72m)

shows that duplicates have already been excluded, plus the numbers do 
not quite add up

Andrew

[Therion] Length & Depth differ

[Andrew Atkinson]

Further to that on the same survey

The sections length in the Config window are

OldCave:398.47
2008:625.48
2009:1763.52
2010:956.68+171.84

Which gives 3915.99 but the total is given by the compiler as 4156.16

Now a little playing and 2008 is made from a survex 3d file that has 
more data in it than is used and actually has 865.63 which is 240.15 
more than reported. Which when added to the 3915.99 gives 4156.16.

So the root folder under survey structure seems to use the whole length 
of the 3d file the subfolders do not. And this is just a simple part of 
my survey, puts into doubt lots of my other length


This leads me to the question, why cannot we just use the survex files 
as a centreline file between the centreline-endcentreline why not have

centreline
...
survexdata

#survexformated data

endsurvexdata

This would allow lots easier management of the data, I would not have to 
work out which 3d files to update, which with the above seems to have 
become even more important, as I will have to remove any 3d data that is 
also in therion. I cannot just use the parts because I then get a cannot 
mix local and global co-ordinates error (which I am sure I can get round 
but feel in the long term converting my svx files to .th is the way forward)

thanks

Andrew

On 13/09/10 14:02, Andrew Atkinson wrote:
>
>
> On 07/09/10 10:38, Bruce wrote:
>> Has anyone noticed that cave lengths and depths reported by the textual
>> (survey-list and cave-list) exports sometimes differ from the length and
>> depth reported by the map (pdf) export, even when all these outputs are
>> produced with the same thconfig run?
>>
>
> Yes, in the therion compiler window, I am getting
>
> length: 4156.16m (surface 0.00m, duplicated 477.89m)
>
> but the pdf is reporting 3744m
>
> For a minute I thought that I had been missunderstanding the duplicates
> but a quick check with one of my other surveys
>
>
> length: 212.77m (surface 0.00m, duplicated 433.72m)
>
> shows that duplicates have already been excluded, plus the numbers do
> not quite add up
>
> Andrew
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] area file defs

[Andrew Atkinson]

Bruce (or anyone else)

Thanks for the examples of code you have put on the wiki, it is helping 
me lots with my first play at altering the code. I have moved onto 
playing with the area defs.

I am slowly getting my head round it, and hopefully will be able to add 
a novice guide to the wiki, when eventually I do.

What I would like to do is change the density of the debris code, 
although random, it seems logical that the probability of getting more 
can be increased.. Same size parts but more of them.

I have played with some of the numbers but not got anywhere, is it 
possible to change the density of the 'blocks' and for future reference 
the size of them?

   def a_debris_AMER (expr p) =
   T:=identity;
   pickup PenC;
   path q, qq; q = bbox p;
   picture tmp_pic;
   tmp_pic := image(
 for i = xpart llcorner q step u until xpart urcorner q:
  for j = ypart llcorner q step u until ypart urcorner q:
 qq := punked
   (((-.2u,-.2u)--(.2u,-.2u)--(.2u,.2u)--(-.2u,.2u)--cycle)
  randomized (u/2))
rotated uniformdeviate(360)
shifted ((i,j) randomized u);
if xpart (p intersectiontimes qq) < 0:
 thclean qq;
 thdraw qq;
fi;
   endfor;
 endfor;
   );
   clip tmp_pic to p;
   draw tmp_pic;
 enddef;

thanks

Andrew

[Therion] Under and over (maps)

[Andrew Atkinson]

Just come back from a day of gathering more data.

I have set my maps up by area, then putting those areas into maps of cave.

The new data has expanded one cave so that it is over another cave, my 
problem is that the same cave is under the other cave at a different point.

Now it seems to me that the order of the maps is controlling the order 
of the layers on the pdf. So is the only way to fix this on the pdf to 
split the map (cave) up. The problem with this is if you colour by map 
(cave in my case) the cave would come out in 2 colours.

Hope I have missed something

Andrew

[Therion] Under and over (maps)

[Andrew Atkinson]

Yes I have been aware of it in the back of my mind for sometime, I was 
sort of hoping we I could avoid it

(I did not think we could colour by user specific maps, yet, or maybe I 
missed a change)

I can understand the scraps could not 'corkscrew' but it seems a little 
strange with maps, can this not be worked out when processing, even if 
it was the average height of the stations or something, there would have 
to be an override when it got it wrong. It just seems to me that 
arranging maps by what may or may not be over something else is not a 
good system to force on the user. When finding new cave, how do you even 
know. In my case I had an feeling  this could happen, and I have a way 
round it, although it will make it far more difficult of the beginners 
to understand, which is a shame.

Andrew

On 16/09/10 21:42, Bruce wrote:
>> Now it seems to me that the order of the maps is controlling the order
>> of the layers on the pdf.
>
> Yes
>
>> So is the only way to fix this on the pdf to
>> split the map (cave) up.
>
> I think so.
>
>> The problem with this is if you colour by map
>> (cave in my case) the cave would come out in 2 colours.
>
> Ha ha! This is another challenge that has been looming for me for years!
>
> As you have figured out it requires careful thought about how to organise
> and order the map definitions, which in turn dictates the best ways to
> organise how everything is arranged in the data files.  I have managed in an
> adhoc way so far, and it is now time perhaps to figure out and write down an
> ordered 'system'.  I'll work on it with my current project over the next few
> months...
>
> Provided we can colour by map with user specified colours (and I think we
> can) the problem you describe should be 'no problem'.
>
> Bruce
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Cross Sections - Scale?

[Andrew Atkinson]

Sorry but I am getting no where with this (well not strictly true.)

Looking at the .th2 file in the text editor, I can see it is getting a 
default scale from somewhere, so I can do a search and replace on all the
-scraps [-128.0 -128.0 9261.85826771 -128.0 0.0 0.0 238.5024 0.0 m]

and replace them with the correct numbers.

However, it would be better if I could do it in the file, as you suggest.

##XTHERION## xth_me_area_adjust -128.0 -128.0 9362.0 4379.96850394
##XTHERION## xth_me_area_zoom_to 400
##XTHERION## xth_me_image_insert {155.905511811 1 1.0} {949.606299212 
1.0} PocketTopo/SandWormth_p.xvi 0 {}

I cannot find any help on these lines, but to me it looks like the fist 
line defines the visible area, the second the zoom
and final one is something to do with the background image. However the 
numbers in the brackets I cannot work out. There is a {} which could 
contain a scale, but again if this is true I cannot work it out.

Although I am wondering even if I do work this out it might only be 
applied to new scraps I insert.

Reading the wiki again I found

http://therion.speleo.sk/wiki/doku.php?id=tfc:332

And to quote the first paragraph

> When you open a new .th2 file. there are 2 red squares at bottom corners of 
> canvas. These points are used to set scale manually.

I have tried opening a new .th2 file but cannot see these square? So 
moving onto the next line

> After drawing plan and extended scraps, they could not be visible. If 
> selected object on canvas is not a manually scaled scrap, they will NOT be 
> visible at all. You need to go to “File commands control” panel, then 
> click on the line representing cross-section scrap you create on last step. 
> They should be visible now. However, if some zooming was done, they could be 
> out of visual reach. You may scroll canvas or set zooming to 25% to see them. 
> Once found, they can be dragged.

What is the "File Control Panel"

The closest I can find is Command Preview but this does not bring up the 
red square?

version 5.3.3 on Ubuntu 10.04

thanks

Andrew




On 20/09/10 21:06, Martin Sluka wrote:
> Any scrap is "calibrated" see first lines of th2 file. Probably there is a 
> another way.
>
> Odesláno z iPhone
>
> 20.9.2010 v 18:26, Andrew Atkinson:
>
>> Damn
>>
>> Thanks, I had read the wiki, but sort of saw it working without the scale, 
>> so assumed that it was an undocumented feature, and that it took the scale 
>> from the main map some how, as I seem to remember it complaining if it did 
>> not have scale before, or was that only for plans.
>>
>> Now my reading of the wiki, and the thbook is that a scale would be needed 
>> for every scrap.
>>
>> Okay this seems like a good option, but as most of the time anything in a 
>> single th2 file would be at the same scale, could not a default one be set 
>> for the file, and then over ridden by a scrap scale. As you might have seen 
>> I have lots of cross sections, to scale.
>> It would be even better if it could take the scale from the plan, or maybe 
>> somehow from the PocketTopo import. Maybe an option for the sections been a 
>> a set multiple of the plan. (but I am not sure if people do this when 
>> drawing in the cave so might be pointless.) But maybe this is not possible, 
>> it is certainly for the future, this print will have to go out as is, guess 
>> the problem is that lost of the poeple looking at the survey next w/e are on 
>> the list so the mistake will jump out at them, now :(
>>
>> If I do want to stay up all night and correct this, would the quickest way 
>> be to set the scale in one cross-section scrap and then edit it in the text 
>> editor and copy to all the other cross-section scraps?
>>
>> thanks
>>
>> Andrew
>>
>>
>> On 20/09/10 12:10, Martin Sluka wrote:
>>> The cross-sections has no included any stations to calibrate the size as
>>> map or elevation. Normally you should calibrate them:
>>> http://therion.speleo.sk/wiki/doku.php?id=tbe:wiki3#cross_sections
>>>
>>> Martin
>>>
>>> On 19.9.2010, at 23:51, Andrew Atkinson wrote:
>>>
>>>> At last a final survey to be printed, well not quite.
>>>>
>>>> On closer examination, there seems to be a scale problem with the
>>>> cross section. Either that or my drawing is really bad.
>>>> Some of them seem to be twice the scale of the main survey, others
>>>> seem to be the same.
>>>>
>>>> Is there a way to control this and what is the default?
>>>>
>>>> I have a horrible feeling that when I have imported from pocket topo,
>>>> it asks which scale,

[Therion] Recovering data marked as sent from DistoX2

[Andrew Atkinson]

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] Recovering data marked as sent from DistoX2

[Andrew Atkinson]

Well, no solutions to the problem, but 2 days in silica gel and the sd card
works, so data safe, for which I'm most grateful :-))

Andrew
On 23 Mar 2016 7:11 p.m., "Bruce Mutton"  wrote:

> Although if you save to the device and have a memory card installed, ptopo
> automatically backs up to the card (twice) so you have two physical chances
> that your data might be ok. (As compared to one if you save to card)
> But if you start a new file ptopo still uses the same backup names, so you
> have to manually copy the old file to the card.
> This method worked for us when our device drowned.
>
> Bruce
>
> Sent from my Samsung device, hence the typo's
>
>
>  Original message 
> From: Footleg 
> Date: 24/03/2016 03:27 (GMT+12:00)
> To: List for Therion users , Martin Sluka <
> martinsluka at mac.com>
> Subject: Re: [Therion] Recovering data marked as sent from DistoX2
>
> 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
>>
>
> ___
> 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/20160324/36a31c2e/attachment.html>

[Therion] Setting Scrap Colours

[Andrew Atkinson]

Excellent, this has been needed for some time, and opens up lots of
possibilities.

Not tested it yet, as I am up mountains.

Just a thought, would it be possible to assign colour when adding maps to
another map, so things like water paths can be shown on an overview without
having to change the maps individually

Eg

map detail
Map1 -colour[100 0 0]
Map 2 -colour [0 100 0]
Map3 -colour [0 0 100]
endmap

map Flow
Map1 -colour[70 0 0]
Map 2 -colour [70 0 0]
Map3 -colour [0 0 100]
endmap

Thanks

Andrew
On 28 Mar 2016 3:38 a.m., "Olly Betts"  wrote:

> On Sun, Mar 27, 2016 at 09:44:37AM +0100, Olly Betts wrote:
> > On Mon, Mar 14, 2016 at 09:23:39PM +1300, Bruce wrote:
> > > Colour by map works just fine, as does colour by scrap or altitude.
> > >
> > > In the context of your question I thought you were trying to SPECIFY
> > > which colour a particular scrap (or map or altitude) would be
> > > assigned.
> >
> > I was "commissioned" to implement the ability to specify the colour
> > used for each map - patch attached.
> >
> > With this (surprisingly small) change you can specify the colour for
> > each map, which then overrides the automatic choice when the layout
> > specifies "colour map-fg [map]".  Any maps without one get the same
> > automatic colour they would before.
> >
> > Usage example:
> >
> > map 2012.map -projection plan
> >   colour [0 70 0]
> >   # etc
> > endmap
>
> You can also specify the colour on the "map" line (which is probably
> clearer):
>
> map 2012.map -projection plan -colour [0 70 0]
>   # etc
> endmap
>
> Jenny Black produced an example showing what you can do with this patch:
>
> https://survex.com/~olly/107-plan-col-year.pdf
>
> Cheers,
> Olly
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[Therion] ignoreall before newline does not seem to work

[Andrew Atkinson]

Hello

I am trying to do this data


data normal station left right up down ignoreall newline tape compass clino
P2D11   0.4 0   0.37Top of sump pool
b   3.88122.0   -3.0
P2D20.2 1   0.2 0.4 Left side passage just above bolt   
F   5.64289.0   -3.0
P2D30.7 0.6 0   0.43Roof pendant

but it tells me that I do not have enogh readings for type in   


On the survex documentation it uses this, which should work, just 
ignoreing the LRUD but same result

data normal station ignoreall newline tape compass clino

A bit of playing around and I find this works (but I don't really want 
to go through and add quotes for all my comments)

data normal station left right up down ignore newline tape compass
P2D11   0.4 0   0.37"Top of sump pool"  
b   3.88122.0   -3.0
P2D20.2 1   0.2 0.4 "Left side passage just above bolt" 
F   5.64289.0   -3.0
P2D30.7 0.6 0   0.43"Roof pendant"

So it looks like ignoreall before a new line does not work in therion, 
it is shown in survex documentation, and works in survex

[Therion] ignoreall before newline does not seem to work

[Andrew Atkinson]

On 02/11/11 03:52, Bruce wrote:
> Andrews suggestion would be a nice addition to the therion data options.

Not sure it is an addition, isn't it a bug (or me interpreting it 
wrongly). I understood that Therion used the same format as survex 
(minus the * and the other tweaks) it even refers to the survex manual 
for data types. The ignoreall is documented and supported by survex, so 
should work in Therion.

Although lots of the below would be nice


Andrew
>
> I have not checked, but assume the ‘comments’ that are part of the ignore 
> or ignoreall really are ignored by therion.
>
> It would be nice (but low priority) if they could be included in the dataset 
> as if they were specified like;
>
>
> Station 46 “Big Entrance” entrance spring dig  # as in the therion book 
> quotation below
>
>
> Ie comment appears in loch model and any number of flags
>
>
> This would keep associated data together in the survey file.  It would be 
> nice to have the option of including the station flags as well as the 
> comments.
>
> Could well be messy in some situations, but a nice option if it is easy to 
> implement.
>
>
> Not sure if or how the ‘data station’ declaration would handle the random 
> input of comments and flags.
>
> Would require quotes around multi word comments to differentiate from flags.
>
> Maybe this would be a useful data declaration to aim for...
>
> data normal station left right up down optional[“comment” flag1 flag2 
> etc] newline optional[back] tape compass clino
>
> There is probably a case for aiming for close compatibility with survex 
> however.
>
>  From the Therion Book...
> station[] ◃ set the station comment and its 
> flags.
>
> If "" is specified as a comment, it is ignored.
>
> Supported flags: entrance, continuation, air-draught[:winter/summer], sink,
>
> spring, doline, dig, arch, overhang. Also not is allowed before a flag, to 
> remove 5.3
>
> previously added flag.
>
> You can also specify custom attributes to the station using attr flag 
> followed by
>
> attribute name and value. Example:
>
> station 4 "pit to explore" continuation attr code "V"
>
> Bruce
>
>
> -Original Message-
> From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On 
> Behalf Of Andrew Atkinson
> Sent: Wednesday, 2 November 2011 5:16 a.m.
> To: List for Therion users
> Subject: [Therion] ignoreall before newline does not seem to work
>
> Hello
>
> I am trying to do this data
>
>
> data normal station left right up down ignoreall newline tape compass clino
> P2D1  1   0.4 0   0.37Top of sump pool
> b 3.88122.0   -3.0
> P2D2  0.2 1   0.2 0.4 Left side passage just above bolt   
> F 5.64289.0   -3.0
> P2D3  0.7 0.6 0   0.43Roof pendant
>
> but it tells me that I do not have enogh readings for type in 
>
>
> On the survex documentation it uses this, which should work, just
> ignoreing the LRUD but same result
>
> data normal station ignoreall newline tape compass clino
>
> A bit of playing around and I find this works (but I don't really want
> to go through and add quotes for all my comments)
>
> data normal station left right up down ignore newline tape compass
> P2D1  1   0.4 0   0.37"Top of sump pool"  
> b 3.88122.0   -3.0
> P2D2  0.2 1   0.2 0.4 "Left side passage just above bolt" 
> F 5.64289.0   -3.0
> P2D3  0.7 0.6 0   0.43"Roof pendant"
>
> So it looks like ignoreall before a new line does not work in therion,
> it is shown in survex documentation, and works in survex
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Loch 5.3.8 not displaying models on Debian wheezy

[Andrew Atkinson]

Stacho, Wookey, or anyone else

have you had a chance to have a look at this? I am running a course on 
on the first w/e of December, and it would not be good to be unable to 
show off the 3d models that are produced.

thanks

Andrew

On 24/10/11 19:25, Stacho Mudrak wrote:
> Dear Andrew,
>
> I am sorry for the late answer, I have also upgraded my computer and I
> have not yet installed my "therion development environment" :(
>
> Just a question, if you just run loch without opening any file, are
> you able to rotate the "red cube" ?
>
> Unfortunatelly, it does not check OpenGL error codes when calling
> OpenGL functions, I will try to add it to see, what is going wrong,
> when I will reinstall all the stuff on my new computer.
>
> Best regards, S.
>
> On 20 October 2011 17:55, Andrew Atkinson  wrote:
>> Hello all
>>
>> I started on this problem before the summer, but then I went away for a few
>> weeks. But I am working on surveys again so I could really do with loch.
>> (One plus from before the summer is that aven is upgraded to 1.2.2 and that
>> now works again, so I am not completely blind)
>>
>> So trying to open a lox or 3d file in loch just gives a blank screen (grey
>> to go with the border)
>> Runing it from terminal does the same with no errors.
>>
>> Below is the useful information that aven gives you when you look at help
>>
>>
>> Andrew
>>
>> Linux 3.0.0-1-amd64 x86_64
>> wxWidgets 2.8.10 (GTK+>= 2.6)
>> Display Depth: 24 bpp (colour)
>> OpenGL 2.1.2 NVIDIA 275.28
>> NVIDIA Corporation
>> GeForce 7300 GS/PCI/SSE2
>> GLX 1.4
>> R8G8B8
>> Max Texture size: 4096x4096
>> Max Viewport size: 4096x4096
>> Smooth Point Size 1.000-63.375 (granularity 0.125)
>> Aliased point size 1.000-63.000
>> Double buffered: true
>> GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_clamp
>> GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_ES2_compatibility
>> GL_ARB_explicit_attrib_location GL_ARB_fragment_program
>> GL_ARB_fragment_program_shadow GL_ARB_fragment_shader
>> GL_ARB_framebuffer_object GL_ARB_half_float_pixel GL_ARB_half_float_vertex
>> GL_ARB_imaging GL_ARB_map_buffer_range GL_ARB_multisample
>> GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_occlusion_query2
>> GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite
>> GL_ARB_provoking_vertex GL_ARB_robustness GL_ARB_sampler_objects
>> GL_ARB_separate_shader_objects GL_ARB_shader_objects
>> GL_ARB_shading_language_100 GL_ARB_shading_language_include GL_ARB_shadow
>> GL_ARB_texture_border_clamp GL_ARB_texture_compression
>> GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine
>> GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float
>> GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
>> GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_swizzle
>> GL_ARB_timer_query GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra
>> GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object GL_ARB_vertex_program
>> GL_ARB_vertex_shader GL_ARB_window_pos GL_ATI_draw_buffers
>> GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc
>> GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color
>> GL_EXT_blend_equation_separate GL_EXT_blend_func_separate
>> GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_compiled_vertex_array
>> GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_direct_state_access
>> GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit
>> GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object
>> GL_EXT_gpu_program_parameters GL_EXT_multi_draw_arrays
>> GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object
>> GL_EXT_point_parameters GL_EXT_provoking_vertex GL_EXT_rescale_normal
>> GL_EXT_secondary_color GL_EXT_separate_shader_objects
>> GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side
>> GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_dxt1
>> GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map
>> GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3
>> GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA
>> GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp
>> GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle
>> GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra
>> GL_EXT_x11_sync_object GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat
>> GL_KTX_buffer_region GL_NV_alpha_test GL_NV_blend_minmax GL_NV_blend_square
>>

[Therion] Loch 5.3.8 not displaying models on Debian wheezy

[Andrew Atkinson]

Sorry to hassle, especially when bugs generally get fixed extremely 
efficiently.

aven started to work when it was upgraded to 1.2.2

Before that it did not work and behaved similarly to loch, hope this is 
a useful starting point and not a red herring

thanks

Andrew


On 10/11/11 09:23, Stacho Mudrak wrote:
> aven is upgraded to 1.2.2 and
  that

[Therion] Loch 5.3.8 not displaying models on Debian wheezy

[Andrew Atkinson]

It is not hardware, again my only real memory of exact occurrence is 
going back through the mails before the summer.


Back in June on ubuntu 11.04 it stopped when I went to 5.3.3.

Then you (wookey) built 5.3.7 for debian, so I moved to debian, but with 
no luck. I was on the noveau driver then. 5.3.8 appeared quickly 
afterwards, but this did not help and I ran out of time to move from 
noveau driver.

Well now I have had the time to install the NVIDIA drivers, but has not 
helped. And I am reasonably sure that aven did not work either, and it 
was the upgrade to 1.2 that sorted that, but I would not bet my life on it.

thanks

Andrew

On 10/11/11 18:08, Wookey wrote:
> +++ Andrew Atkinson [2011-10-20 16:55 +0100]:
>> Hello all
>>
>> I started on this problem before the summer, but then I went away
>> for a few weeks. But I am working on surveys again so I could really
>> do with loch. (One plus from before the summer is that aven is
>> upgraded to 1.2.2 and that now works again, so I am not completely
>> blind)
>>
>> So trying to open a lox or 3d file in loch just gives a blank screen
>> (grey to go with the border)
>> Runing it from terminal does the same with no errors.
>
> Is this new hardware or an OS upgrade? You used to have loch working,
> right? In which case do older loch versions work?
>
> There used to be a patch in the Debian version of loch to allow it to
> work with some intel graphics cards, but I took that out in the 5.3.6
> upload IIRC, as it had stopped breaking on my machine, due to vtk or
> xorg driver fixes (I presume). (I'd have to check to be sure exactly
> which version). It seems unlikely that this has anything to do with
> your nvidia problem.
>
>> Linux 3.0.0-1-amd64 x86_64
>> wxWidgets 2.8.10 (GTK+>= 2.6)
>> Display Depth: 24 bpp (colour)
>> OpenGL 2.1.2 NVIDIA 275.28
>> NVIDIA Corporation
>
> Does it help at all if you use the noveau driver rather than the
> nvidia one?
>
> (apt-get install xserver-xorg-video-nouveau)
>
> Wookey

[Therion] Loch 5.3.8 not displaying models on Debian wheezy

[Andrew Atkinson]

It was 1.1.14 reading the mails I sent back in July, but I might have 
tried another, tried lots of things

Andrew

On 10/11/11 17:48, Olly Betts wrote:
> On Thu, Nov 10, 2011 at 02:00:29PM +0000, Andrew Atkinson wrote:
>> Sorry to hassle, especially when bugs generally get fixed extremely
>> efficiently.
>>
>> aven started to work when it was upgraded to 1.2.2
>>
>> Before that it did not work and behaved similarly to loch, hope this is
>> a useful starting point and not a red herring
>
> Hmm, nothing obvious looking changed in 1.2.2 itself (only think
> directly GL-related was the new font drawing approach).
>
> What Survex version were you using before 1.2.2?  If it was<1.2.0,
> It's probably this change then:
>
> http://trac.survex.com/changeset/3623
>
> Cheers,
>  Olly
>

[Therion] Loch 5.3.8 not displaying models on Debian wheezy

[Andrew Atkinson]

I will try to build it tomorrow, caving today. I have not done builds 
before, so it could take me a while, and probably a few questions.

btw it is Andrew not Andy

Andrew

On 12/11/11 07:09, Stacho Mudrak wrote:
> On my kubuntu virtual machine it also failed to start. When I added your
> double buffer initialization code (including wxGLApp as application
> parent), it started to work. I have already sent codes to Andy. I am
> curious, whether it will work.
>
> Thanks a lot for ideas, S.
>
> On 12 November 2011 04:41, Olly Betts  wrote:
>
>> On Sat, Nov 12, 2011 at 01:16:17AM +, Wookey wrote:
>>> It feels like we are not initialising the card properly (or VTK
>>> isn't). Ol's double-buffer init suggestion is worth trying, althogh
>>> I'm not sure how that relates to loch as it uses VTK rather than
>>> opengl directly (as I understand it).
>>
>> I suggested it as it's the most likely opengl-related change I can think
>> of which changed between the two aven versions Andy mentioned as not
>> working and working.  Though trying the other versions in between to
>> narrow down exactly which one fixed it would make it easier to check in
>> detail.
>>
>> Cheers,
>> Olly
>> ___
>> 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] Grid and Label clipping

[Andrew Atkinson]

Hello

 From reading the therion book, if I have the grid bottom should it not 
be clipped by labels so the attached should not happen. The text should 
be on top of the grid. and therefore the grid not be seen at this point. 
Label appear to clip the passage.

thanks

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: GridandLabels.png
Type: image/png
Size: 31866 bytes
Desc: not available
URL: 

[Therion] Grid and Label clipping

[Andrew Atkinson]

Oh but you tempted me, and I cannot do it, how do I change the colour of 
the grid. Nothing I have tried under symbol-colour has worked, and I 
cannot find anything on the wiki.

thanks

Andrew

On 15/11/11 20:32, Martin Budaj wrote:
> Hi,
> it is by design, currently. Grid is processed independently, so it is
> not easy to clip it (perhaps customizing grid colour could be a
> temporary solution?)
>
> martin
>
> On Tue, Nov 15, 2011 at 9:00 PM, Andrew Atkinson  
> wrote:
>> Hello
>>
>>  From reading the therion book, if I have the grid bottom should it not be
>> clipped by labels so the attached should not happen. The text should be on
>> top of the grid. and therefore the grid not be seen at this point. Label
>> appear to clip the passage.
>>
>> 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
>

[Therion] Pitch that is larger at top than bottom

[Andrew Atkinson]

Hi

I have been trying to come up with a solution for the attached diagram. 
The pitch head is larger that the passage below, so if you turn off 
outline on the walls and put it on the pitch boundary, the fading goes 
but the parts where the pitch is on the outside of the passage take on 
the background colour so it does not look right.

I have tied using invisible lines, or even tracing the walls to the 
survey above, but none of them look right, not sure if there is a 
solution, but suggestions welcome

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: Large_pitch.png
Type: image/png
Size: 53743 bytes
Desc: not available
URL: 

[Therion] Changing outline on pitches breaks lox

[Andrew Atkinson]

hello

Just been changing the outline on a pitch so the bolders below look 
right on the pdf, by setting the bit of wall to outline none, clip off 
and the pitch boundary to outline out clip off, see p_before and 
p_after, the problem is that then the lox model also has a hole in it 
see l_before and l_after.

I suspect this is bug/feature that is hard to get around?

Andrew
-- next part --
A non-text attachment was scrubbed...
Name: l_after.png
Type: image/png
Size: 76910 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: l_before.png
Type: image/png
Size: 88961 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: p_after.png
Type: image/png
Size: 30500 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: p_before.png
Type: image/png
Size: 55460 bytes
Desc: not available
URL: 

[Therion] Changing outline on pitches breaks lox

[Andrew Atkinson]

Having slept on this, one solution which would avoid areas would be

-outline in/out/none - works for both model and 2D
-2D in/out/none - sets the outline for 2D
-3D in/out/none - sets the outline for 3D

so
-2D out -3D out

is equivalent to

-outline out

Doesn't break what we have, just extends it, hopefully without over 
complication

Andrew

On 25/11/11 09:46, Bruce wrote:
> This is just one symptom of a drawing package that attempts to make many
> outputs from single (non-duplicate) inputs.  Therion is not alone here.  At
> some point there will always be limits to the versatility of outputs that
> can be achieved with a particular set of scraps.  Another example is that it
> is hard to get maps with labels and symbols that look good at scales more
> than 2 orders of magnitude apart.
>
> Perhaps to solve the issue that Andrew describes a new area entity could be
> created.  One that 'cleans' the passage interior colouring and makes it
> transparent.  Would avoid using invisible walls and making holes in the loch
> model.  It would still result in a 'holey' pdf map if we were displaying
> only the top passage and not the bottom passage in some maps.
>
> So, increasing complexity and decreasing returns.
> Sadly, at some point we need to decide "these are the types of output we
> have in mid for this dataset" and tailor our inputs to that end, thus
> compromising the ability to get other outputs/map arrangements/scales etc.
>
> Please, please prove me wrong somebody.
>
> Bruce
>
> -Original Message-
> From: therion-bounces at speleo.sk [mailto:therion-bounces at speleo.sk] On 
> Behalf
> Of Andrew Atkinson
> Sent: Friday, 25 November 2011 11:26 a.m.
> To: List for Therion users
> Subject: [Therion] Changing outline on pitches breaks lox
>
> hello
>
> Just been changing the outline on a pitch so the bolders below look
> right on the pdf, by setting the bit of wall to outline none, clip off
> and the pitch boundary to outline out clip off, see p_before and
> p_after, the problem is that then the lox model also has a hole in it
> see l_before and l_after.
>
> I suspect this is bug/feature that is hard to get around?
>
> Andrew
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] create area filled with a colour

[Andrew Atkinson]

You can create custom fills, but pillars can be shown by
wall with the -outline in option set

If you set a background colour this will then show.

Or do you want to do something different

Andrew

On 25/11/11 14:20, Mihai Terente wrote:
> Dear friends,
>
> Is there a way to create a simple filled area? Suppose I want to
> create a black area enclosed by a line of type border to draw the
> outline of a pillar, which is to big to be represented as a point
> symbol.
>
> Mihai T.
> www.iser.ro
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
>

[Therion] Problem with diving data

[Andrew Atkinson]

Hello

So station 1_25 is the same as 4_1 and you have connected them together 
with a zero length leg. Not sure why this does not work, but if you replace

1_25 4_10.0   0.0   0.0   0.0   0.0   0.0 
0.0

with

equate 1_25 4_1

it gets rid of the stream of errors, I also find equates easier to read 
than zero length legs, especially as you have a cross section of 0 which 
seems unlikely.

Andrew

On 19/10/11 09:13, Xavier Robert wrote:
> Hi all,
>
> I am currently trying to draw a map with diving data. But she I compile,
> I receive a metapost error. This probably because of the structure of my
> data, but even after reading The THbook and the Survex tutorial, I do
> not understand where/why. Can someone give me any advise ?
>
> I attach to this emai a zip file that contain :
> - a simple part of my diving data, with its thconfig file
> - The associated log file.
>
> Thanks a lot !
>
> Xav
>
>
> --
> Xavier Robert
> Chercheur/Researcher CR2 - IRD
> ISTerre - Maison des Géosciences
> 1381 rue de la Piscine - BP 53
> 38041 Grenoble Cedex 09
> France
>
> Phone :
> Fax : 33 (0)4 76 51 40 58
>
>
> xavier.robert01 at gmail.com 
>
>
>
>
>
>
>
>
>
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion

[Therion] Loch 5.3.8 not displaying models on Debian wheezy

[Andrew Atkinson]

Hello all

I started on this problem before the summer, but then I went away for a 
few weeks. But I am working on surveys again so I could really do with 
loch. (One plus from before the summer is that aven is upgraded to 1.2.2 
and that now works again, so I am not completely blind)

So trying to open a lox or 3d file in loch just gives a blank screen 
(grey to go with the border)
Runing it from terminal does the same with no errors.

Below is the useful information that aven gives you when you look at help


Andrew

Linux 3.0.0-1-amd64 x86_64
wxWidgets 2.8.10 (GTK+ >= 2.6)
Display Depth: 24 bpp (colour)
OpenGL 2.1.2 NVIDIA 275.28
NVIDIA Corporation
GeForce 7300 GS/PCI/SSE2
GLX 1.4
R8G8B8
Max Texture size: 4096x4096
Max Viewport size: 4096x4096
Smooth Point Size 1.000-63.375 (granularity 0.125)
Aliased point size 1.000-63.000
Double buffered: true
GL_ARB_color_buffer_float GL_ARB_copy_buffer GL_ARB_depth_clamp 
GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_ES2_compatibility 
GL_ARB_explicit_attrib_location GL_ARB_fragment_program 
GL_ARB_fragment_program_shadow GL_ARB_fragment_shader 
GL_ARB_framebuffer_object GL_ARB_half_float_pixel 
GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_map_buffer_range 
GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query 
GL_ARB_occlusion_query2 GL_ARB_pixel_buffer_object 
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex 
GL_ARB_robustness GL_ARB_sampler_objects GL_ARB_separate_shader_objects 
GL_ARB_shader_objects GL_ARB_shading_language_100 
GL_ARB_shading_language_include GL_ARB_shadow 
GL_ARB_texture_border_clamp GL_ARB_texture_compression 
GL_ARB_texture_cube_map GL_ARB_texture_env_add 
GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar 
GL_ARB_texture_env_dot3 GL_ARB_texture_float 
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two 
GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_texture_swizzle 
GL_ARB_timer_query GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra 
GL_ARB_vertex_array_object GL_ARB_vertex_buffer_object 
GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos 
GL_ATI_draw_buffers GL_ATI_texture_float GL_ATI_texture_mirror_once 
GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra 
GL_EXT_blend_color GL_EXT_blend_equation_separate 
GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract 
GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test 
GL_EXT_direct_state_access GL_EXT_draw_range_elements GL_EXT_fog_coord 
GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample 
GL_EXT_framebuffer_object GL_EXT_gpu_program_parameters 
GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil 
GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_point_parameters 
GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color 
GL_EXT_separate_shader_objects GL_EXT_separate_specular_color 
GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap 
GL_EXT_texture3D GL_EXT_texture_compression_dxt1 
GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map 
GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine 
GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic 
GL_EXT_texture_format_BGRA GL_EXT_texture_lod 
GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp 
GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_swizzle 
GL_EXT_timer_query GL_EXT_vertex_array GL_EXT_vertex_array_bgra 
GL_EXT_x11_sync_object GL_IBM_rasterpos_clip 
GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_alpha_test 
GL_NV_blend_minmax GL_NV_blend_square GL_NV_complex_primitives 
GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_fbo_color_attachments 
GL_NV_fence GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragdepth 
GL_NV_fragment_program GL_NV_fragment_program_option 
GL_NV_fragment_program2 GL_NV_framebuffer_multisample_coverage 
GL_NV_half_float GL_NV_light_max_exponent GL_NV_multisample_filter_hint 
GL_NV_occlusion_query GL_NV_packed_depth_stencil GL_NV_pixel_data_range 
GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners 
GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_barrier 
GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 
GL_NV_texture_expand_normal GL_NV_texture_lod_clamp 
GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 
GL_NV_texture_shader3 GL_NV_vertex_array_range GL_NV_vertex_array_range2 
GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 
GL_NV_vertex_program2_option GL_NV_vertex_program3 
GL_NVX_conditional_render GL_OES_depth24 GL_OES_depth32 
GL_OES_depth_texture GL_OES_element_index_uint GL_OES_fbo_render_mipmap 
GL_OES_get_program_binary GL_OES_mapbuffer GL_OES_packed_depth_stencil 
GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL_OES_texture_3D 
GL_OES_texture_float GL_OES_texture_float_linear 
GL_OES_texture_half_float GL_OES_texture_half_float_linear 
GL_OES_texture_npot GL_OES_vertex_array_object GL_OES_vertex_half_float 
GL_SGIS_generate_mipmap GL_SGIS_texture_lod 

[Therion] PocketTopo Exported data image import bug

[Andrew Atkinson]

Not sure why but the xvi file lines 2 to 5 are

set XVIstations {
}
set XVIshots {
}

looking at my other data, this is where the legs and station should be.

Looking at the Stomps2010th.txt file lines 272 to 274 we have

PLAN
STATIONS
SHOTS

This is where the stations and shots should be, so it looks like it is
not coming correctly out of PocketTopo

Have you got the original top file. If so does this show up on
PocketTopo with the centre line.
Exactly the same happens with the  other Matienzo Maze090722 that you
have (I have not sent it to the list as it is not my data)

For that file adding a new first line of
1.0 1.22 0 0 0
brought the centreline back on Pockettopo then exporting it and the
Therion import worked.

It would be interesting to know how you are making these files, also how
PocketTopo desides which station is at (0,0) or even if (0,0) is used
for the first station

Andrew



On 15/03/12 21:16, Footleg wrote:
> I do not seem to be able to get the attached PocketTopo therion export
> format data file to import into the map editor properly. Using Therion
> 5.3.9.
> 
> The xvi either fails to be inserted, or appears without the survey
> centreline and stations. I have not had this problem with other data
> files. Could it be the overall size of this sketch?
> 
> Footleg
> 
> 
> 
> ___
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion