Nabble - Therion

Re: CS output specification

2008-11-27T02:06:00Z

Thanks Stacho
Now that you explain it, the significance of the 3rd sentence on page 14
Therion Book becomes clearer!

I see now that this aspect is even more modular and flexible than I thought.

In the same data set, one can independently specify different co-ordinate
systems for each input survey, surface image, terrain model, scanned sketch,
gridline position origin, atlas page position origin and the actual output
co-ordinates printed. I had assumed that the last three items in that list
would be constrained to the same co-ordinate system; hence my
misunderstanding.

I suspect that the way Therion is now is probably best (assuming I have 'got
it right'). What would help would perhaps be an expanded explanation in the
Therion Book. Ie explaining the usage and scope (visibility) in the
different su=ituations.

I'm wondering if one could ever come up with six or more valid co-ordinate
systems in common usage that apply to any one single cave system? :)
To answer my own question, we probably have more than six where I live, but
only two or three we are likely to use.
Bruce

-----Original Message-----
From: therion-bounces@... [mailto:therion-bounces@...] On Behalf
Of Stacho Mudrak
Sent: Wednesday, 26 November 2008 11:14 p.m.
To: List for Therion users
Subject: Re: [Therion] CS output specification

> So now I'm a bit confused. Must be in layout to set atlas page positions?

Yes. CS must be specified, if you want to specify atlas page origin in
the layout.

> Must not be in layout for all other outputs?

CS from layout is not used in any outputs. Therion outputs are allways
in output CS specified outside of the layout in your configuration
file.

> Is there a logical explanation?

I am not sure, I understand your problem correctly. Does your
confusion comes from fact, that you need to specify same CS twice -
once in the layout and once outside of the layout? May be if layout
would use cs specified outside of the layout by default - would it
solve your problems?

Regards, S.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

survey-level: Minor correction /clarification of entry in Therion Book

2008-11-27T02:06:00Z

Just looking for a clarification of the following entry copied from pg 51 of the Therion Book…

(text copy and image copy)

_ survey-level <N/all> . how many surveys to display with stations.

There seems to be a formatting issue, but more importantly it’s function.

I’m being lazy here and have not experimented.

I assume it’s related to the debug statement used in layouts.

Does it control the display of the nested level of survey? Eg 126 versus 126@...

If so I assume the default is N for none, based on my experience so far.

Is this correct?

Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T14:26:37Z

Stacho Mudrak schrieb:
> Well, currently we have 3 symbols in therion: floor-step (for steps
> where no equipement is needed), pit (= step where equipement is
> needed) and overhang.
>
> As far as I understand Austrian symbol set - your
> floorstep:filled/unfilled should be applied to pit symbol, not
> floorstep symbol.
I guess you're right, it should be applied to the pit symbol.
My first thought was, that a pit symbol should always be a closed line.
But as the symbol is the same, a single name makes it simpler.

> But are you really in reality using different
> symbols for pits over and under 10 m, especially when there is allways
> number right beside the symbol? How is it in other countries - do
> other people have experience with using different symbols for
> different pit depths?
>

I'm checking this with people who were involved in the creation of the
standard and use it more frequently than I do...

> For me the correct solution for this problem would be to add parameter
> to the pit/floor-step/overhang symbol with assigned depth, that would
> be automatically shown on the map and available in metapost if you
> would like to fill/unfill rectangles.
>

For the symbol I agree, yet I think the depth label should be placed
manually for a nice position.

> Another small issue is chimney/ceiling-step. You have there in your
> symbol set "+" sign in the middle. If there will be separate height
> symbol (e.g. +5 m) in the middle of the chimney, there will be two
> times "+", which will not look very well. Here I would also suggest
> adding chimney height as an argument to the chimney line and "+"
> symbol will be shown, only if it will be assigned using this argument.
>

Yes, I wasn't happy with the '+' in the middle of the chimney anyway...

> Your changes in a zip file are OK. I will diff and patch our sources.
ok, I'm not sure wheter I'll get the way arguments are passed to
metapost, but we'll see...

Thanks for the good suggestions
Georg.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T14:14:09Z

Martin Sluka schrieb:

> I'm able to do it in Illustrator, but how to program it for MetaPost?
>
> from bottom:
>
> 1. Make path.
>
> 2. Make thickest line on path.
>
> 3. Make mask on that path - it should cut the inner part of line
>
> 4. Make thick line on path
>
> 5. Make thin white line on path

Yes, this works well!
I'm not sure if it's possible to mask only the path and not the entire
enclosed area, but that doesn't matter much I think.
One can put the entrance pit to the beginning of the .th2 file.

thanks,
Georg

Ps.: the metapost code I used:

def PenXXL = pencircle scaled (2.4*u/10) enddef;

def l_pit (expr P) =
T:=identity;
#draw the two lines
pickup PenXXL;
thdraw P;
thclean P;
pickup PenX;
thdraw P;
pickup PenC;
thdraw P withcolor (1,1,1);

# draw triangles
laenge:= arclength P;
symsize:=0.5u;
triangle_width:=symsize/2;

pair l_triangle;
pair f_triangle;
pair test;
path triangle;
path draw_triangle;
triangle:= (-triangle_width/2,0) -- (triangle_width/2,0) --
(0,symsize/2) -- cycle;
cur:=(symsize);

t := arctime (cur) of P;
f_triangle := (point t of P +.05u*unitvector(thdir(P,t) rotated 90));
thfill triangle rotated angle thdir(P,t) shifted f_triangle ;
l_triangle := f_triangle;

for cur=(symsize) step 0.1 until laenge:
t := arctime (cur) of P;
test := (point t of P +.05u*unitvector(thdir(P,t) rotated 90));
my_dist := distance(test,l_triangle);
# show my_dist;
if abs(my_dist-symsize) < 0.05u:
draw_triangle:=triangle rotated angle thdir(P,t) shifted test;
if xpart (draw_triangle intersectiontimes P) < 0:
thfill triangle rotated angle thdir(P,t) shifted test;
l_triangle:= test;
fi;
fi;
endfor;
enddef;

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

test.pdf (13K) Download Attachment

Re: Xtherion interface point data entry differs to otherentity types

2008-11-26T11:31:20Z

Stacho
Yes I think that would make the behaviour appear to be consistent.
(Presumably it is difficult to re-code so that an object is created on
pressing Ctrl+P)
Bruce

-----Original Message-----
From: therion-bounces@... [mailto:therion-bounces@...] On Behalf
Of Stacho Mudrak
Sent: Wednesday, 26 November 2008 11:05 p.m.
To: List for Therion users
Subject: Re: [Therion] Xtherion interface point data entry differs to
otherentity types

Well, I understand your confusion, the problem is, that this behavior
is because of program design:

If you hit Ctrl+L or Ctrl+A, an object is immediately created and
therefore you can edit types or options.

If you hit Ctrl+P, no object is created - you are just switched to the
point insertion mode. Point is created after you click on the
position.

I see just one solution to your problem. When you switch to point
insertion mode, point dialog will be enabled and changes you have made
to this dialog will be applied to the first point inserted. Would it
help you?

Regards, S.

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T03:03:16Z

example:

m.

On 26.11.2008, at 11:25, Martin Sluka wrote:

>
> On 26.11.2008, at 11:15, Georg Pacher wrote:
>
>> but I dont know if that is possible...
>
> I'm able to do it in Illustrator, but how to program it for MetaPost?
>
> from bottom:
>
> 1. Make path.
>
> 2. Make thickest line on path.
>
> 3. Make mask on that path - it should cut the inner part of line
>
> 4. Make thick line on path
>
> 5. Make thin white line on path
>
> m.
> _______________________________________________
> Therion mailing list
> Therion@...
> http://mailman.speleo.sk/mailman/listinfo/therion

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Picture 1.png (28K) Download Attachment

Re: Austrian Symbol-Set

2008-11-26T02:25:50Z

On 26.11.2008, at 11:15, Georg Pacher wrote:

> but I dont know if that is possible...

I'm able to do it in Illustrator, but how to program it for MetaPost?

from bottom:

1. Make path.

2. Make thickest line on path.

3. Make mask on that path - it should cut the inner part of line

4. Make thick line on path

5. Make thin white line on path

m.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T02:22:08Z

On 26.11.2008, at 11:15, Georg Pacher wrote:

> Good idea, yet I forgot to mention that the outer line should be
> thicker (like a wall), than the inner line (pit). An 'asymmetric
> pen' could solve that, but I dont know if that is possible...

I'm affraid that this is unpossible in MetaPost - PostScript use only
the central line on path.

Maybe somebody else knows another trick.

m.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T02:15:28Z

Martin Sluka schrieb:
> On 25.11.2008, at 23:22, Georg Pacher wrote:
>> -Drawing the symbol for entrance pits which uses a double line.
>> Currently I generate points at a fixed distance perpendicular to the
>> given line and connect them to form the inner line. This results in
>> very bad behaviour at edges, and needs a lot of memory due to the
>> large number of generated points. Any ideas how to solve that?
> Simple trick: thick black line at background and thin white line at
> foreground on the identical path.

Good idea, yet I forgot to mention that the outer line should be thicker
(like a wall), than the inner line (pit). An 'asymmetric pen' could
solve that, but I dont know if that is possible...

regards
Georg

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: CS output specification

2008-11-26T02:13:46Z

> So now I'm a bit confused. Must be in layout to set atlas page positions?

Yes. CS must be specified, if you want to specify atlas page origin in
the layout.

> Must not be in layout for all other outputs?

CS from layout is not used in any outputs. Therion outputs are allways
in output CS specified outside of the layout in your configuration
file.

> Is there a logical explanation?

I am not sure, I understand your problem correctly. Does your
confusion comes from fact, that you need to specify same CS twice -
once in the layout and once outside of the layout? May be if layout
would use cs specified outside of the layout by default - would it
solve your problems?

Regards, S.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Xtherion interface point data entry differs to other entity types

2008-11-26T02:05:04Z

Well, I understand your confusion, the problem is, that this behavior
is because of program design:

If you hit Ctrl+L or Ctrl+A, an object is immediately created and
therefore you can edit types or options.

If you hit Ctrl+P, no object is created - you are just switched to the
point insertion mode. Point is created after you click on the
position.

I see just one solution to your problem. When you switch to point
insertion mode, point dialog will be enabled and changes you have made
to this dialog will be applied to the first point inserted. Would it
help you?

Regards, S.

On Sat, Nov 22, 2008 at 8:53 PM, Bruce Mutton
<bruce.mutton@...> wrote:

> A quirk of Xtherion that still gets me from time to time is that the
> behaviour of point data entry seems to be differ to the behaviour when
> entering lines or areas, at least within Windows OS.
>
>
>
> Typically, I decide that, for example, I want to draw some lines of type
> rock-border, so my sequence will be;
>
> Ctrl+L (enter insert line mode and 'lines' menu area on right is activated)
> Select 'rock-border from the Lines type dropdown listbox and press enter
> If there are any other options I will enter them now, such as –clip off for
> example
> Left-click a sequence where I want the rock-border to appear, then tick the
> reverse and close tick-boxes if necessary
> Select each line-point node and smooth it using the drag handles
> Repeat for other nearby rock-borders
>
>
>
> Steps 1 to 5 apply for all line types I think. Steps 1 to 4 apply similarly
> for allocating areas to previously defined lines.
>
> There are other sequences that can be used, but this seems fairly efficient
> if tracing a scanned sketch, and fits one of the ways my mind likes to work.
>
>
>
> Entering POINTS in this sequence, however, results in an undesirable side
> effect at step 2. The 'points' menu area on the right is NOT activated
> (unless of course the previous action resulted in a point being selected)
>
> So, if the points menu IS NOT active, you must left-click the point
> position, THEN select the type of point and it's options/properties; OK, but
> it does not follow the consistent sequence above.
>
> Alternatively if the points menu IS active and you follow the steps above,
> the result is that the previously selected point type and properties will be
> LOST and changed to the type and properties that you enter in steps 2 and 3.
>
> This inconsistency slowed my learning to use Xtherion considerably (to a
> beginner it appeared to rarely work the same way each time) and even now
> results in unexpected map contents from time to time.
>
>
>
> Is there 'design' behind this behaviour and I am just not using it as
> intended?
>
> Or is there a bug in that activating insert point mode does not activate the
> 'points' menu area and deselect the previously edited point?
>
> This behaviour has been present in all releases since I first used Therion
> just over a year ago.
>
>
>
> Bruce
>
> _______________________________________________
> Therion mailing list
> Therion@...
> http://mailman.speleo.sk/mailman/listinfo/therion
>
>

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T01:58:02Z

> I am about to adapt the symbol-set in therion to meet the Austrian standard
> (see http://www.hoehle.org/downloads/signaturen.gif).

Thanks for your contribution.

> -Drawing the symbol for entrance pits which uses a double line. Currently I
> generate points at a fixed distance perpendicular to the given line and
> connect them to form the inner line. This results in very bad behaviour at
> edges, and needs a lot of memory due to the large number of generated
> points. Any ideas how to solve that?

Currently, there is no solution for this in metapost. The problem is,
that there is no analytical solution for creating parralel bezier
curve. One solution could be as Martin suggested, but we you approach
you are using in some symbols where this is needed (e.g. floor
meander).

> -Naming of floorstep subtypes: As in the old UIS standard(?) there are
> floorstep subtypes when equipment is needed (<10m, >10m). Any ideas for a
> good (short) name for those?

Well, currently we have 3 symbols in therion: floor-step (for steps
where no equipement is needed), pit (= step where equipement is
needed) and overhang.

As far as I understand Austrian symbol set - your
floorstep:filled/unfilled should be applied to pit symbol, not
floorstep symbol. But are you really in reality using different
symbols for pits over and under 10 m, especially when there is allways
number right beside the symbol? How is it in other countries - do
other people have experience with using different symbols for
different pit depths?

For me the correct solution for this problem would be to add parameter
to the pit/floor-step/overhang symbol with assigned depth, that would
be automatically shown on the map and available in metapost if you
would like to fill/unfill rectangles.

Another small issue is chimney/ceiling-step. You have there in your
symbol set "+" sign in the middle. If there will be separate height
symbol (e.g. +5 m) in the middle of the chimney, there will be two
times "+", which will not look very well. Here I would also suggest
adding chimney height as an argument to the chimney line and "+"
symbol will be shown, only if it will be assigned using this argument.

> And the main question is:
> - How shall I prepare the changes I did, such that they can be easily
> included in one of the next releases?

Your changes in a zip file are OK. I will diff and patch our sources.

Thanks for your contribution, S.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Austrian Symbol-Set

2008-11-26T00:48:42Z

On 25.11.2008, at 23:22, Georg Pacher wrote:

> -Drawing the symbol for entrance pits which uses a double line.
> Currently I generate points at a fixed distance perpendicular to
> the given line and connect them to form the inner line. This
> results in very bad behaviour at edges, and needs a lot of memory
> due to the large number of generated points. Any ideas how to solve
> that?

Simple trick: thick black line at background and thin white line at
foreground on the identical path.

Martin
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Austrian Symbol-Set

2008-11-25T14:22:44Z

Hi there!

I am about to adapt the symbol-set in therion to meet the Austrian
standard (see http://www.hoehle.org/downloads/signaturen.gif).

The changes I made, can be found here:
ftp://ftp.tugraz.at/outgoing/therion/symbolsetAUT_changes.zip

and an example of what comes out:
ftp://ftp.tugraz.at/outgoing/therion/types_AUT.pdf

Most symbols are finished already (or met the standard anyway), but
there are still some open issues:

-Drawing the symbol for entrance pits which uses a double line.
Currently I generate points at a fixed distance perpendicular to the
given line and connect them to form the inner line. This results in very
bad behaviour at edges, and needs a lot of memory due to the large
number of generated points. Any ideas how to solve that?

-Naming of floorstep subtypes: As in the old UIS standard(?) there are
floorstep subtypes when equipment is needed (<10m, >10m). Any ideas for
a good (short) name for those?

-Legend symbols/explanations. I didnt really care about that yet.

And the main question is:
- How shall I prepare the changes I did, such that they can be easily
included in one of the next releases?

Keep up the good work and kind regards
Georg.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-25T01:39:19Z

On Mon, Nov 24, 2008 at 8:25 PM, Bruce Mutton
<bruce.mutton@...> wrote:
> Seems OK as a start. Agree that the elevations are often less accurate than
> the plan positions...
> Just to clarify, are the values listed to be 2x sd (mean to 95% limit)
> Or 4x sd (lower 95% limit to upper 95%)?

It is meant to be 2 * SD.

Duncan: basically it is EPE with 95% confidence.

Martin
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-24T17:36:21Z

Why not use something similar to the EPE (estimated position error)
that most GPS units display? I think the terminology (and probably
the exact meaning of the measurement) varies a bit from one
manufacturer to another, though.

Duncan
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-24T17:29:01Z

I agree with David. Although it would be nice to have the flexibility of
entering feet/inches, I think it should be rather low on the priority list.

In my somewhat limited experience with cave survey, I have never seen one done
in feet/inches.

The syntax for fractional inches could be difficult. I suggest it is not
really necessary. In working with feet/tenths, I almost never take a
measurement closer than the nearest tenth of a foot. That is slightly more
than an inch, so measurements to the nearest inch would be about the same
accuracy.

Bill Gee

On Monday 24 November 2008, David A. Riggs wrote:

> On Mon, Nov 24, 2008 at 5:56 AM, Martin Budaj <m.budaj@...> wrote:
> > It would simplify code like -value [3 ft] into -value 3'.
> >
> > Any comments on this? How to enter fractions of an inch?
>
> -value 3.65'
>
> In my experience, it is much more common to encounter "decimal feet"
> rather than "feet and inches" in American cave survey.
>
> DR

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-24T11:25:22Z

Seems OK as a start. Agree that the elevations are often less accurate than
the plan positions...
Just to clarify, are the values listed to be 2x sd (mean to 95% limit)
Or 4x sd (lower 95% limit to upper 95%)?
Bruce

-----Original Message-----
> What about 'position'? I don't think the BCRA grades have much to say
about
> these. (I'm sure we can make something sensible up)

First proposal could be:

GRADE; POSITION / HEIGHT error (95% confidence); comment

0 -- position unknown
1 1000 m -- rough estimate / memory
2 100 m -- GPS in bad conditions (canyons, foliage, SA), small-scale
map
3 15 / 45 m -- GPS, large-scale map
4 5 / 15 m -- GPS longer observation, distinct features on a large-scale
map
5 1 / 3 m -- GIS GPS
6 15 cm -- geodetic GPS, theodolite/total station, technical
nivelation
7 5 cm -- geodetic GPS, precise theodolite/total station,
precise nivelation

Martin

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-24T08:18:14Z

> What about 'position'? I don't think the BCRA grades have much to say about
> these. (I'm sure we can make something sensible up)

First proposal could be:

GRADE; POSITION / HEIGHT error (95% confidence); comment

0 -- position unknown
1 1000 m -- rough estimate / memory
2 100 m -- GPS in bad conditions (canyons, foliage, SA), small-scale map
3 15 / 45 m -- GPS, large-scale map
4 5 / 15 m -- GPS longer observation, distinct features on a large-scale map
5 1 / 3 m -- GIS GPS
6 15 cm -- geodetic GPS, theodolite/total station, technical nivelation
7 5 cm -- geodetic GPS, precise theodolite/total station,
precise nivelation

Martin
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-24T07:38:00Z

On Mon, Nov 24, 2008 at 5:56 AM, Martin Budaj <m.budaj@...> wrote:
>
> It would simplify code like -value [3 ft] into -value 3'.
>
> Any comments on this? How to enter fractions of an inch?
>

-value 3.65'

In my experience, it is much more common to encounter "decimal feet"
rather than "feet and inches" in American cave survey.

DR

--
David A. Riggs <david.a.riggs@...>
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-24T05:56:17Z

We are also considering to allow direct entering of lengths in feet
and inches like 5'3" or 3" (which would be interpreted always as
feet/inches regardless of default length units setting).

It would simplify code like -value [3 ft] into -value 3'.

Any comments on this? How to enter fractions of an inch?

Martin

On Thu, Nov 20, 2008 at 2:23 PM, Stacho Mudrak <s.m@...> wrote:

>> May I suggest an extension of the idea? In the master .th file should be some
>> way of specifying a default for scraps. If the scrap contains a default
>> setting, it over-rides the setting from the .th file.
>
> If it would be specified in master file, than if you will send
> somebody a part of your data without this master file, he could not be
> sure, what units did you used. But you are right - units specification
> for every scrap is still not very convenient... I can imagine.
>
> I have another suggestion. What about setting defult units system
> simmilar way as file character encoding is set. E.g. at the beginning
> of every file you will have command, that will set default units valid
> until end of file. This command will be automatically inserted by
> xtherion each time you create new .th or .th2 file. You will be able
> to configure default units in xtherion.ini, so you will not have to
> take care of units any more. And the data will be still portable,
> because units used in file will be specified in its header. It will
> also simplify centerline insertion, because units specification after
> each centerline command will not be needed any more.
>
> Regards, S.
> _______________________________________________
> Therion mailing list
> Therion@...
> http://mailman.speleo.sk/mailman/listinfo/therion
>

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Xtherion interface point data entry differs to other entity types

2008-11-22T11:53:42Z

A quirk of Xtherion that still gets me from time to time is that the behaviour of point data entry seems to be differ to the behaviour when entering lines or areas, at least within Windows OS.

Typically, I decide that, for example, I want to draw some lines of type rock-border, so my sequence will be;

Ctrl+L (enter insert line mode and ‘lines’ menu area on right is activated)
Select ‘rock-border from the Lines type dropdown listbox and press enter
If there are any other options I will enter them now, such as –clip off for example
Left-click a sequence where I want the rock-border to appear, then tick the reverse and close tick-boxes if necessary
Select each line-point node and smooth it using the drag handles
Repeat for other nearby rock-borders

Steps 1 to 5 apply for all line types I think. Steps 1 to 4 apply similarly for allocating areas to previously defined lines.

There are other sequences that can be used, but this seems fairly efficient if tracing a scanned sketch, and fits one of the ways my mind likes to work.

Entering POINTS in this sequence, however, results in an undesirable side effect at step 2. The ‘points’ menu area on the right is NOT activated (unless of course the previous action resulted in a point being selected)

So, if the points menu IS NOT active, you must left-click the point position, THEN select the type of point and it’s options/properties; OK, but it does not follow the consistent sequence above.

Alternatively if the points menu IS active and you follow the steps above, the result is that the previously selected point type and properties will be LOST and changed to the type and properties that you enter in steps 2 and 3.

This inconsistency slowed my learning to use Xtherion considerably (to a beginner it appeared to rarely work the same way each time) and even now results in unexpected map contents from time to time.

Is there ‘design’ behind this behaviour and I am just not using it as intended?

Or is there a bug in that activating insert point mode does not activate the ‘points’ menu area and deselect the previously edited point?

This behaviour has been present in all releases since I first used Therion just over a year ago.

Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: georeferencing data added to pdf maps

2008-11-21T01:06:05Z

> I notice in the changes.txt file for 5.2.3 mentions "georeferencing data added to pdf maps"
> Is this intended to mean that the output co-ordinate system can be printed in the legend, or something more sophisticated?

It adds some additional information to pdf file which can be later
processed by xtherion (Help -> Calibrate bitmap) to create a bitmap
image + ozi explorer-compatible *.map calibration file.

> Printing the output co-ordinate system in legends generally and the 'caves list' would be useful (their common names and or their 'numerical' name)

Indeed, it should be added.

Martin
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

georeferencing data added to pdf maps

2008-11-21T00:41:57Z

I notice in the changes.txt file for 5.2.3 mentions “georeferencing data added to pdf maps”

Is this intended to mean that the output co-ordinate system can be printed in the legend, or something more sophisticated?

Printing the output co-ordinate system in legends generally and the ‘caves list’ would be useful (their common names and or their ‘numerical’ name)

Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-20T17:28:13Z

I see your point ... Yes, I think your idea is good. :-)

Thanks - Bill Gee

On Thursday 20 November 2008, Stacho Mudrak wrote:

> > May I suggest an extension of the idea? In the master .th file should be
> > some way of specifying a default for scraps. If the scrap contains a
> > default setting, it over-rides the setting from the .th file.
>
> If it would be specified in master file, than if you will send
> somebody a part of your data without this master file, he could not be
> sure, what units did you used. But you are right - units specification
> for every scrap is still not very convenient... I can imagine.
>
> I have another suggestion. What about setting defult units system
> simmilar way as file character encoding is set. E.g. at the beginning
> of every file you will have command, that will set default units valid
> until end of file. This command will be automatically inserted by
> xtherion each time you create new .th or .th2 file. You will be able
> to configure default units in xtherion.ini, so you will not have to
> take care of units any more. And the data will be still portable,
> because units used in file will be specified in its header. It will
> also simplify centerline insertion, because units specification after
> each centerline command will not be needed any more.
>
> Regards, S.
> _______________________________________________
> Therion mailing list
> Therion@...
> http://mailman.speleo.sk/mailman/listinfo/therion

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-20T11:51:27Z

Stacho wrote:

> So our suggestion is to use just simple
> grade N
> option in centerline, where N will be survey grade from 0 - 7, where
> 1-6 = BCRA 1-6, 7 = BCRA X and 0 will be data without any quality
>(e.g. position of cave nobody is able to locate now).

I quite like this idea. It will not affect me, but I imagine some people
will have quite a lot of data where they would like backwards compatibility
with the current (old) way of specifying grades??

> This grade
> should be specified in each centerline object. And such a
> configuration will allow doing statistics on survey data from
> different sources.

This seems to be a sensible approach. Beyond very simple caves, the grade is
something that should be considered with every piece of survey, just like
the date and who did the surveying. Just need to decide on a default grade
that applies if no grade statement is present.

> Of course, it will still be possible to refine data
> quality using "sd" option, but grades will remain the same for all
> survey data in therion.
>
> If you have any comments, please let us know.

What about 'position'? I don't think the BCRA grades have much to say about
these. (I'm sure we can make something sensible up)

Regards,
Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-20T05:23:31Z

> May I suggest an extension of the idea? In the master .th file should be some
> way of specifying a default for scraps. If the scrap contains a default
> setting, it over-rides the setting from the .th file.

If it would be specified in master file, than if you will send
somebody a part of your data without this master file, he could not be
sure, what units did you used. But you are right - units specification
for every scrap is still not very convenient... I can imagine.

I have another suggestion. What about setting defult units system
simmilar way as file character encoding is set. E.g. at the beginning
of every file you will have command, that will set default units valid
until end of file. This command will be automatically inserted by
xtherion each time you create new .th or .th2 file. You will be able
to configure default units in xtherion.ini, so you will not have to
take care of units any more. And the data will be still portable,
because units used in file will be specified in its header. It will
also simplify centerline insertion, because units specification after
each centerline command will not be needed any more.

Regards, S.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-19T17:03:05Z

Hi, Stacho -

Yes, this would be a large help! :-)

May I suggest an extension of the idea? In the master .th file should be some
way of specifying a default for scraps. If the scrap contains a default
setting, it over-rides the setting from the .th file.

I also think the syntax for setting the units on a specific -value should be
retained. It won't be used often, but there will be occasions when it is
needed.

Thanks - Bill Gee

> >
> > point 481.75 -722.5 passage-height -value [3 ft]
> >
> > Is there a way to avoid this convoluted syntax?
>
> Not yet. If it would help you, we can add some -units option for
> scrap. If it will be specified, all -values in current scrap will be
> treated in given units. Would this help you?
>
> Regards, S.
> _______________________________________________
> Therion mailing list
> Therion@...
> http://mailman.speleo.sk/mailman/listinfo/therion

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-19T07:05:54Z

> units compass degrees
> units clino degrees
> units length feet
> units depth feet
> units tape feet
> units altitude feet
> units dimensions feet
>
> Everything should be feet, right?? NOT! When I do a passage height point and
> specify "-value 3", for example, Therion thinks that is 3 meters.

You are right, these settings are just for centerline data, and even
there in some cases they will not be used (e.g. when specifying
explored length after station with continuation flag) :( It needs to
be checked and fixed. Until now, nobody was using feets with therion
so this problem was ignored.

> When the
> map is compiled, 3 meters is converted to feet and then printed on the map.
> It comes out as 10!
>
> point 481.75 -722.5 passage-height -value 3
>
> The workaround I discovered is to specify it as "-value [3 ft]". This comes
> out right on the compiled map.
>
> point 481.75 -722.5 passage-height -value [3 ft]
>
> Is there a way to avoid this convoluted syntax?

Not yet. If it would help you, we can add some -units option for
scrap. If it will be specified, all -values in current scrap will be
treated in given units. Would this help you?

Regards, S.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-19T06:58:34Z

> I'm still looking for a 'best practice' on where to put grade statements and
> how to control their scope/visibility. Perhaps someone could write a brief
> note for the Wiki or the Therion Book?

It looks, using survey grades will change in therion in the near
future. The reason is, that in current configuration, it is not very
clear, how to use it. We have studied the problem a little bit and it
looks, that there are more or less same survey grades used around the
world. So our suggestion is to use just simple

grade N

option in centerline, where N will be survey grade from 0 - 7, where
1-6 = BCRA 1-6, 7 = BCRA X and 0 will be data without any quality
(e.g. position of cave nobody is able to locate now). This grade
should be specified in each centerline object. And such a
configuration will allow doing statistics on survey data from
different sources. Of course, it will still be possible to refine data
quality using "sd" option, but grades will remain the same for all
survey data in therion.

If you have any comments, please let us know.

Regards, S.
_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: standard deviation and survey grade

2008-11-19T01:00:16Z

I’m still experimenting with grade and sd statements..

I can get some very extreme distortions with just a small relative difference in sd values. No problem, it’s just a function of my mis-close, and the math. To my advantage it may help me to decipher the scope/visibility of grade statements if I can concentrate on the problem long enough.

I finally took the hint in previous postings that BCRA grades 3 & 5 might be built into Therion. I tested it and indeed they are. Is this documented anywhere? Would have saved me quite a bit of experimentation (and embarrassment).

I’m still looking for a ‘best practice’ on where to put grade statements and how to control their scope/visibility. Perhaps someone could write a brief note for the Wiki or the Therion Book?

Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-18T18:59:45Z

>The workaround I discovered is to specify it as "-value [3 ft]". This
> comes out right on the compiled map.

Good tip Bill.
Interestingly, as a user of meters this sort of thing was the reason I gave
up on Compass and On-Station, and look with suspicion at anything written by
non SI users. Similar problem, but the other way around :)
Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: Passage Height units

2008-11-18T17:35:14Z

Hi, everyone - Taking off from Stacho's comment below about setting the units
for LRUD, I have been wrestling ever since I began using Therion with the
units on "Passage Height" points. I discovered quite by accident a way to
make them come out right, but it seems a kludgy way to do things.

In my .th file I specify units like this:

units compass degrees
units clino degrees
units length feet
units depth feet
units tape feet
units altitude feet
units dimensions feet

Everything should be feet, right?? NOT! When I do a passage height point and
specify "-value 3", for example, Therion thinks that is 3 meters. When the
map is compiled, 3 meters is converted to feet and then printed on the map.
It comes out as 10!

point 481.75 -722.5 passage-height -value 3

The workaround I discovered is to specify it as "-value [3 ft]". This comes
out right on the compiled map.

point 481.75 -722.5 passage-height -value [3 ft]

Is there a way to avoid this convoluted syntax?

Thanks - Bill Gee

I am using Therion 5.2 on Fedora 7

> But I am not sure, whether it is all you asked for... It looks, that
> you had problems enering survey data in feet. Is it really like that?
> Could you please send me some sample file in feets, may be you are
> just missing units settings. May be your confusion comes from a fact,
> that if you enter in your data header:
>
> units length feet
>
> LRUD data are still interpreted as metres. All you need to do in this
> case is to specify, that also dimenstions are entered in feet
>
> units length dimensions feet

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: CS output specification

2008-11-16T11:58:06Z

Thanks Xavier
Your example does indeed work the way you describe.

"
After many tests, it seems that specifying a CS inside the Layout does
nothing. Apparently, the output CS should be specified outside and that
the last CS specified is the one used for all the outputs.
"

I thought 'problem solved' until I realised that for me the most convenient
way is to include the output cs in my layout files; perhaps I can
re-organise... but on going back through my records, Martin B had this to
say (with respect to atlas page positioning on the co-ordinate system) ...

"
You need to specify 'cs' also in the layout, before setting the 'origin'.
Therion can not presume that cs in the data files is the same as in the
layout.
"

That advice seemed to work at the time; however I did not explore its full
potential.
So now I'm a bit confused. Must be in layout to set atlas page positions?
Must not be in layout for all other outputs? Is there a logical
explanation?

Bruce

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion

Re: CS output specification

2008-11-16T09:17:55Z

Bruce,

Good thing you've noticed the problem with CS specification. Actually,
it was working for me, but not always as I specified...
After many tests, it seems that specifying a CS inside the Layout does
nothing. Apparently, the output CS should be specified outside and that
the last CS specified is the one used for all the outputs.

In the test example joined, EPSG:27582 (French Lambert II) is the last
CS specified. Therion says:
-> output coordinate system: EPSG:27582
and output coordinates as well as the output map are in this coordinate
system (I translated with another tool to obtain the coordinates of
Cave1 X=543263.98772068, Y=1907965.20640927).

Xavier

Bruce Mutton a écrit :

> Xavier
>
> I have not addressed your question (as I don't know the answer).
> Your data files compile on my machine as you describe in your message (an
> error as submitted, but success if the cave names are changed).
>
> I noticed that you have a co-ordinate conversion from one cs to another.
>
> Interested to know if the conversion is performed correctly for you?
>
> I tried to do this some weeks ago with my data (different co-ordinate
> systems), and although no errors were raised, the co-ordinates were not
> transformed at all, the maps and grids printed with the input co-ordinate
> system, and not the requested output co-ord system.
>
> In studying the outputs I get with your data I find the same thing is
> happening. Am I (we?) misunderstanding how to do the co-ordinate
> conversions, or is something not working?
>
> Bruce
>
> -----Original Message-----
> From: therion-bounces@... [mailto:therion-bounces@...] On Behalf
> Of Xavier Pennec
> Sent: Thursday, 13 November 2008 8:59 a.m.
> To: List for Therion users
> Subject: [Therion] Problem with object types
>
> I have a problem with object types in therion: it seems that it is not
> possible to have a survey and a station which have the same name (see
> example included which perfectly compiles if one changes the cave1 and
> cave 2 to Cave1 and Cave2 for either the station names or the survey
> names). Is that a normal behavior? It seems to me that a correct typing
> should allow having the same names for surveys, stations and maps.
>
> Xavier
>
>
> _______________________________________________
> Therion mailing list
> Therion@...
> http://mailman.speleo.sk/mailman/listinfo/therion
>

encoding utf-8
## Gather all data togother

survey Topocave1 -title "Cave 1"

centerline
date 1991
cs EPSG:2757 ## Lambert II
station cave1 "Cave 1" entrance
equate cave1 0

data normal from to length compass clino ignoreall
units compass grads
units clino degrees

0 1 13.8 240 2
endcenterline
endsurvey

survey Topocave2 -title "Cave 2"

centerline
date 1991

station cave2 "Cave 2" entrance
equate cave2 0

data normal from to length compass clino ignoreall
units compass grads
units clino degrees

0 1 45 140 0
endcenterline
endsurvey

survey surface -title "Surface measurements"

centerline
date 1991

equate cave1 0
equate cave2 1

data normal from to length compass clino ignoreall
units compass grads
units clino degrees

0 1 5 100 0
endcenterline
endsurvey

## index all connection points to link them together

equate cave1 cave1@Topocave1
equate cave2 cave2@Topocave2
equate cave1 cave1@surface
equate cave2 cave2@surface

encoding utf-8
cs EPSG:27583 ## Lambert III
source test

source ## Reference file with all Fixed points
centerline
cs UTM31
fix cave1 390300 4891742 2160 10 10 20 # GPS accuracy is not so good
endcentreline
endsource

layout map_layout

symbol-show line survey
symbol-show point station

# debug on
north true
scale 1 100
units metric

color map-fg altitude

grid bottom
grid-size 10 10 10 m
grid-coords all

# cs EPSG:27573 ## Lambert III
transparency on
opacity 80

surface bottom
#surface-opacity 80
endlayout

cs EPSG:27583 ## Lambert III

export map -o test.pdf -layout map_layout -fmt pdf
export model -fmt survex -o test.3d

#!CAVE LIST EXPORT

cs EPSG:27572 ## Lambert II
export cave-list -o Coordonnees.html -location on

[Xavier_Pennec.vcf]

begin:vcard fn:Xavier Pennec n:Pennec;Xavier email;internet:xavier.pennec@... tel;work:+33 4 92 38 76 64 tel;fax:+33 4 92 38 76 69 version:2.1 end:vcard

_______________________________________________
Therion mailing list
Therion@...
http://mailman.speleo.sk/mailman/listinfo/therion