Therion - Calculating altitude for labels from a previous station

[marsrat]

Evening all.
Just been drawing up a survey and I've been stumped (I couldn't find an answer online). I know the altitude of a pre-existing station, and what I want to do is be able for Therion to automatically calculate the altitude based on the new survey data (and enable me to put it on a label). Any Therion masters here know what to do?

Cheers

 

[andrew]

Assuming you are using the altitude point? If not that is probably the answer, if not I'm a little stumped about what you are asking, please could you send and example.
Therion takes the altitude from the closest survey station. For this reason I tent to put the altitude point on a survey station.

tbe:wiki2 [Therion wiki]

therion.speleo.sk

Therefore if you use your know height in the survex/therion data file as a fix, this will then be reflected in the altitude point.
I hope this points you in the right direction.

 

[marsrat]

Assuming you are using the altitude point? If not that is probably the answer, if not I'm a little stumped about what you are asking, please could you send and example.
Therion takes the altitude from the closest survey station. For this reason I tent to put the altitude point on a survey station.

tbe:wiki2 [Therion wiki]

therion.speleo.sk

Therefore if you use your know height in the survex/therion data file as a fix, this will then be reflected in the altitude point.
I hope this points you in the right direction.

I've attached 2 altitude labels next to their stations. I have given the altitude label bottom left the option: "-value [fix 288]" with no option being given to the top right one (as I want it to auto calculate the altitude from the station I have fixed an altitude to).
However, it just spits out 2 (which is not correct).

Am I missing something?

 

[andrew]

View attachment 19141
I've attached 2 altitude labels next to their stations. I have given the altitude label bottom left the option: "-value [fix 288]" with no option being given to the top right one (as I want it to auto calculate the altitude from the station I have fixed an altitude to).
However, it just spits out 2 (which is not correct).

Am I missing something?

Without seeing all the data, well at least the 3d, what I think is happening is that fix just puts the number, 288, in an altitude label, the 2 comes from the altitude of closest station in the dataset. Trying fixing the 288 in the data instead of the drawing. (I've not used fix in the drawing before, just trusted the data. I'm currently not near a machine I can play on)

 

[alastairgott]

I'd agree with Andrew, and knowing you're possibly surveying the dig in Aggy(?), you may only have a short section of survey which doesn't reference the altitude. As Andrew says, try fixing the data in your .th file. for an example in Derbyshire, we have:
cs OSGB:SK #SK is the os map for Derbyshire.

date 2023.07.29
# 29/07/2023
team "JE" notes instruments
station 9 "main ent." entrance
fix 9 10061 81290 328
fix [station] [x] [y] [altitude]
you may need to fix from last known coordinates on the survex model for the cave? x[space]y[space]altitude

I have tried a few options on the survey that I have here, selecting a point of type altitude works for me without the need to use fix anywhere after placing the point of type altitude down.

also working for me is right clicking a point on the cave wall and setting the altitude label to "auto", as shown below.

A point of note from the therion book is an echo of Andrew where it says
"10 General altitude label. All altitudes are exported as a difference against grid Z origin (which is 0
by default). To display altitude on the passage wall, use altitude option for any line point of the
passage wall"

Your point altitude which says "2" i'm guessing is 2m higher than the start of your data? hence the need to use fix in the .th file.

 

[marsrat]

I'd agree with Andrew, and knowing you're possibly surveying the dig in Aggy(?), you may only have a short section of survey which doesn't reference the altitude. As Andrew says, try fixing the data in your .th file. for an example in Derbyshire, we have:
cs OSGB:SK #SK is the os map for Derbyshire.

date 2023.07.29
# 29/07/2023
team "JE" notes instruments
station 9 "main ent." entrance
fix 9 10061 81290 328
fix [station] [x] [y] [altitude]
you may need to fix from last known coordinates on the survex model for the cave? x[space]y[space]altitude

I have tried a few options on the survey that I have here, selecting a point of type altitude works for me without the need to use fix anywhere after placing the point of type altitude down.

also working for me is right clicking a point on the cave wall and setting the altitude label to "auto", as shown below.

View attachment 19142

A point of note from the therion book is an echo of Andrew where it says
"10 General altitude label. All altitudes are exported as a difference against grid Z origin (which is 0
by default). To display altitude on the passage wall, use altitude option for any line point of the
passage wall"

Your point altitude which says "2" i'm guessing is 2m higher than the start of your data? hence the need to use fix in the .th file.

View attachment 19143

Thank you so much! Your suggestion worked

 

[andrew]

fix 9 10061 81290 328

The above fix assumes the information you give is perfect, (zero error) which is unlikely/impossible. It is far better to give the possible error on the readings.

*fix <station> [reference] [ <x> <y> <z> [ <x std err> <y std err> <z std err> [ <cov(x,y)> <cov(y,z)> <cov(z,x)> ] ] ]

You generally only need one or two std error numbers, the rest are just to cover nearly any possibility you can think off, which afyer all is the power of survex.

For more details

https://survex.com/docs/manual/datafile.htm

 

[alastairgott]

Thanks Andrew, I'm fairly sure we covered it in one of the sessions, but I can't say I've ever placed SD in any data, either in the classroom or after.

I have looked it up this morning, to get the grey matter flowing, and found the below text which seems to add some context to implementation within survex. source: https://survex.com/docs/manual/svxhowto.htm

I remember tarquin talking about errors and how garmins were 20m accurate (or thereabouts). If for an example our grid references are taken within a small car park no far away from the P-swallets of Castleton. Then could you use this to reference the map and narrow the accuracy down of the garmin to within the walls of the car park (as surveyed by OS).

Enter Radiolocation Data​

This is done by using the *SD command to specify the appropriate errors for the radiolocation `survey leg' so that the loop closure algorithm knows how to distribute errors if it forms part of a loop.

The best approach for a radiolocation where the underground station is vertically below the surface station is to represent it as a plumbed leg, giving suitable SDs for the length and plumb angle. The horizontal positioning of this is generally quite accurate, but the vertical positioning may be much less well known. E.g: we have a radiolocation of about 50m depth +/- 20m and horizontal accuracy of +/- 8m. Over 50m the +/-8m is equivalent to an angle of 9 degrees, so that is the expected plumb error. 20m is the expected error in the length. To get the equivalent SD we assume that 99.74% of readings will be within 3 standard deviations of the error value. Thus we divide the expected errors by 3 to get the SD we should specify:

*begin *sd length 6.67 metres *sd plumb 3 degrees surface underground 50 - down *end

We wrap the radiolocation leg in a *begin/*end block to make sure that the special *sd settings only apply to this one leg.

For more information on the expected errors from radiolocations see Compass Points Issue 10, available online at http://www.chaos.org.uk/survex/cp/CP10/CPoint10.htm

 

[andrew]

Thanks Andrew, I'm fairly sure we covered it in one of the sessions, but I can't say I've ever placed SD in any data, either in the classroom or after.

It has to be said for many year I and most other people didn't. I suspect the zero error on fixed points by definition is a historic anomaly, leading to lots of data sets, mine included having many in them. For single entrance caves, with only one point fixed, it hardly matters As soon as there are two fixed points linked there is a reasonable chance of a bit of distortion. Survex will essentially pin those two points and bend everything else to fit, which is unlikely to be the right answer. I discovered this in Cheddar. There is (was) a cardinal OS fixed point, which I thought great, possibly the best fix you can get. However, it appears to have been wrong, and knowingly wrong for many years. Which just shows everyone can make a mistake and allowing errors on fixed points reduces incorrect distortions from them.
In more common cases a survey grade GPS is probably accurate to 50cm or better, but reading off a map is probably a couple of meters, so setting different errors would help the distortion.
[For pedants: yes the above is a slight over simplification, but hopefully gets across a reasonable idea)