Re: [Therion] Detecting errors

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


Re: [Therion] Detecting errors

2019-09-07 Thread Martin Sluka via Therion

> 7. 9. 2019 v 13:33, Ben Cooper :
> 
> I think I see what you mean now, the following drawing portrays the issue 
> with a Disto sitting on top of one station, and pointing to another.

That is the reason to use extension.

Martin

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


Re: [Therion] Detecting errors

2019-09-07 Thread Ben Cooper
>Took your advice to heart and calibrated without helmet. Much better!

My non-surveyor assistants are usually dismayed when I ask them to remove 
everything!

 

Apologies, I misunderstood what you meant by display to the left and right.  I 
think I see what you mean now, the following drawing portrays the issue with a 
Disto sitting on top of one station, and pointing to another.  The two stations 
are horizontally aligned, but the Disto is pointing down.  The angular error 
will be the angle subtended by the height of the laser beam above the station 
(3.3 cm or 1.2 cm for my DistoX, depending on orientation).  If the error is 
2-degrees, then this suggests the distance is 94cm  (=3.3cm / tan(2.0)) – 
that’s a very short leg.  At 5m, this error reduces to 0.4-degrees, within the 
calibration error of the device.



In practice, I find legs of 5m to 8m produce the best surveys – much more than 
that and it is hard to accurately hit the target station with the laser beam, 
much less and errors like this “position” error start to get too big.  
Alternatively, when taking short legs, make sure that the “back” projection of 
the laser beam is as closely aligned to the station as possible – often easy to 
do for example when taking a shot from one wall across the passage to the 
opposite wall.  

 

Being aware of this issue should help surveyors choose better station 
positions, especially for short legs.  

 

The gadget shown in other emails would help, but only in certain circumstance – 
eg shots along the wall still suffer from this issue.  

- Ben



oledata.mso
Description: Binary data


image003.wmz
Description: application/ms-wmz
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-09-06 Thread MD
On 6. Sep 2019, at 08:01, Ben Cooper  wrote:
> 
> In my experience poor calibration is usually down to either just inaccurate 
> calibration shots, or local magnetic anomalies: take off watch, step counter, 
> metal belt buckle, jewellery, glasses, helmet, lights, steel toe caps, etc!!

Took your advice to heart and calibrated without helmet. Much better!

Thanks!

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


Re: [Therion] Detecting errors

2019-09-06 Thread MD
On 6. Sep 2019, at 18:31, Wookey  wrote:
> 
> What SD numbers do you use for this?
> 
> I agree they should be different, but I've not seen much research
> evidence on what the correct numbers are.

Pre-Disto we used https://de.wikipedia.org/wiki/H%C3%A4ngezeug which should 
result in about the same SD as an Disto.

I toyed with taking the Callibration SD but I‘m not sure this makes sense. 

> Also SDs are about expected errors and do not cover blunder
> probability

I think this is an important point. They tend to mess up things much worse than 
anything else.

—max___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-09-06 Thread Wookey
On 2019-08-15 11:50 +0200, Benedikt Hallinger wrote:
> To expand a little in this, you could also use the standard „grade“ to tell 
> theriob which centerline data has which quality. We use this to mark the 
> centerlines we have surveyed with distox and traditional way and therion uses 
> this to put more of the errors towards the more bad survey.

What SD numbers do you use for this?

I agree they should be different, but I've not seen much research
evidence on what the correct numbers are.

Also SDs are about expected errors and do not cover blunder
probability very usefully, which is also quite different for fully
digital and paper-based surveying as well as for compass/clino/tape vs
SAP or DistoX. You could adjust the SDs to allow for this, given that
we don't have a better mechanism, but again - how do we choose the
numbers?

I have asked this before and not had useful answers.

I have a re-survey project which has found a lot of errors in old
(both compass/clino and distoX surveys). I'm struggling to work out
what to do with the differences, but it's possible that some plausible
blunder probabilities could be generated if enough resurvey is
done. The main problem is that the resurvey is wrong too, just by a
different unknown amount, and could itself contain blunders.

In practice I found it really difficult to refind all the previous
stations so the resurveys are not mostly leg-for-leg, just connected
every so often.

None of that helps much with the fact that survex does its sums as if
there are only measurments errors, not blunders.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-09-06 Thread Martin Sluka via Therion
You are the wizard, but for as normal people the physical laws are valid. ;)

Martin

Odesláno z iPhonu

6. 9. 2019 v 10:39, Pavel Herich :

> Martin,
> I´ve never used this back extention, but before every "topo day" I use to 
> calibrate DistoX, which brings me errors under 0,5 % permanetly, very rarely 
> between 0,5 - 1 %.
> Pavel
> 
> 
> Dňa 2019-09-06 10:00 Martin Sluka via Therion napísal(a):
>>> 5. 9. 2019 v 13:10, Max D :
>>> So I know that if the display is to the right the Disto tends to
>>> reassure an Azimuth 2 degrees to high and if the display is to the
>>> left.
>>> And when the display is to the left it tends to give an Azimuth 1
>>> degree to low.
>> The main source of error could be misaligned back side of Disto with
>> station point especially together with short distance to measured
>> station. There is a way to reduce this error to minimum when the back
>> extension aligned with laser beam of the Disto is used.
>> Martin
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion

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


Re: [Therion] Detecting errors

2019-09-06 Thread Pavel Herich

Martin,
I´ve never used this back extention, but before every "topo day" I use 
to calibrate DistoX, which brings me errors under 0,5 % permanetly, very 
rarely between 0,5 - 1 %.

Pavel


Dňa 2019-09-06 10:00 Martin Sluka via Therion napísal(a):

5. 9. 2019 v 13:10, Max D :

So I know that if the display is to the right the Disto tends to
reassure an Azimuth 2 degrees to high and if the display is to the
left.
And when the display is to the left it tends to give an Azimuth 1
degree to low.


The main source of error could be misaligned back side of Disto with
station point especially together with short distance to measured
station. There is a way to reduce this error to minimum when the back
extension aligned with laser beam of the Disto is used.

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

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


Re: [Therion] Detecting errors

2019-09-06 Thread Markus Boldt
Hi Martin,

in Ebensee I have asked you, if this part is buyable. Is it? And when where.


Best regards

Markus



Von: Therion [mailto:therion-boun...@speleo.sk] Im Auftrag von Martin Sluka
via Therion
Gesendet: Freitag, 6. September 2019 10:00
An: List for Therion users
Cc: Martin Sluka
Betreff: Re: [Therion] Detecting errors





5. 9. 2019 v 13:10, Max D :



So I know that if the display is to the right the Disto tends to reassure an
Azimuth 2 degrees to high and if the display is to the left.

And when the display is to the left it tends to give an Azimuth 1 degree to
low.





The main source of error could be misaligned back side of Disto with station
point especially together with short distance to measured station. There is
a way to reduce this error to minimum when the back extension aligned with
laser beam of the Disto is used.



Martin





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


Re: [Therion] Detecting errors

2019-09-06 Thread Ben Cooper
An error of 3 degrees in clino does indicate a device out of calibration.  I 
would expect it to be within 0.5 degrees for a well calibrated device, and 
would not tolerate more than 1 degree.  In my experience poor calibration is 
usually down to either just inaccurate calibration shots, or local magnetic 
anomalies: take off watch, step counter, metal belt buckle, jewellery, glasses, 
helmet, lights, steel toe caps, etc!!

Sent from my iPhone

> On 5 Sep 2019, at 12:10, Max D  wrote:
> 
> So I know that if the display is to the right the Disto tends to reassure an 
> Azimuth 2 degrees to high and if the display is to the left.
> And when the display is to the left it tends to give an Azimuth 1 degree to 
> low.
> 
> But perhaps I just should try to do more and better calibrations instead of 
> fixing stuff afterwards.

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


Re: [Therion] Detecting errors

2019-09-05 Thread Benedikt Hallinger
You could also indicate the misalignment with instrument correction commands, 
but i dont know the exact command at the moment. I think that would not with  
different orientations of the same device...

> Am 05.09.2019 um 13:10 schrieb Max D :
> 
> 
> 
>> On 5. Sep 2019, at 08:28, Olly Betts  wrote:
>> 
>>> On Fri, Aug 16, 2019 at 05:11:22AM +0200, MD wrote:
>>> We also then to measure the same small loop at the beginning  of each trip: 
>>> A-B in four device orientations
>>> B-A in four device orientations
>>> A-C in four device orientations
>>> C-A in four device orientations
>>> C-B once
>>> 
>>> So I could calculate an SD based on that. 
>> 
>> You probably don't want to work out a set of SDs per-trip -
> 
> Currently we set the SD per calibration - which works out to about every 
> second trip. We Take the "Error stddev" from Topodroid Calibration Results - 
> e.g.0.1058 in the attached Screenshot.
> 
> Thinking of it, this might be the wrong approach because it only considers 
> the instrument.
> 
>> *sd tape 0.002 metres ; 2 millimetres
>> *sd compass clino 0.5 degrees
>> *sd position 0.05 metres ; 5 centimetres
> 
> Interesting. I will read up on the difference between tape and position
> 
>>> For sone Devices errors seem to be bound very much to orientation. In
>>> the data saved by TopoDroid you can see the device orientation and so
>>> we could set a sd based on the direction in which the shot was taken.
>>> I have nit investigated this further so far. Also because we have this
>>> data only for about 20% of the cave.
>> 
>> This is already taken into account - you tell Survex the SD for the
>> "tape" (read laser range-finder), "compass" and "clino" (read magnetic
>> field measuring devices) and position (how close to the station you
>> actually measure from) and it uses the direction of the leg to produce
>> a 3D set of expected errors, which are then summed along each traverse.
> 
> But I would need a extra set SD data per device orientation. 
> So I know that if the display is to the right the Disto tends to reassure an 
> Azimuth 2 degrees to high and if the display is to the left.
> And when the display is to the left it tends to give an Azimuth 1 degree to 
> low.
> 
> But perhaps I just should try to do more and better calibrations instead of 
> fixing stuff afterwards.
> 
> 
>>> TopoDroid also is able to flag an “magnetic anomaly” - i’m not totally
>>> sure how but this als could be used in setting a per shot SD. i have
>>> not looked much into this.
>> 
>> I think you want to treat that as an in-cave indication that you should
>> check for sources of magnetic interference and redo affected readings.
> 
> Good Advice!
> 
> Thanks!
> 
> --max
> 
> 
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-09-05 Thread Max D


> On 5. Sep 2019, at 08:28, Olly Betts  wrote:
> 
>> On Fri, Aug 16, 2019 at 05:11:22AM +0200, MD wrote:
>> We also then to measure the same small loop at the beginning  of each trip: 
>> A-B in four device orientations
>> B-A in four device orientations
>> A-C in four device orientations
>> C-A in four device orientations
>> C-B once
>> 
>> So I could calculate an SD based on that. 
> 
> You probably don't want to work out a set of SDs per-trip -

Currently we set the SD per calibration - which works out to about every second 
trip. We Take the "Error stddev" from Topodroid Calibration Results - 
e.g.0.1058 in the attached Screenshot.

Thinking of it, this might be the wrong approach because it only considers the 
instrument.

> *sd tape 0.002 metres ; 2 millimetres
> *sd compass clino 0.5 degrees
> *sd position 0.05 metres ; 5 centimetres

Interesting. I will read up on the difference between tape and position

>> For sone Devices errors seem to be bound very much to orientation. In
>> the data saved by TopoDroid you can see the device orientation and so
>> we could set a sd based on the direction in which the shot was taken.
>> I have nit investigated this further so far. Also because we have this
>> data only for about 20% of the cave.
> 
> This is already taken into account - you tell Survex the SD for the
> "tape" (read laser range-finder), "compass" and "clino" (read magnetic
> field measuring devices) and position (how close to the station you
> actually measure from) and it uses the direction of the leg to produce
> a 3D set of expected errors, which are then summed along each traverse.

But I would need a extra set SD data per device orientation. 
So I know that if the display is to the right the Disto tends to reassure an 
Azimuth 2 degrees to high and if the display is to the left.
And when the display is to the left it tends to give an Azimuth 1 degree to low.

But perhaps I just should try to do more and better calibrations instead of 
fixing stuff afterwards.


>> TopoDroid also is able to flag an “magnetic anomaly” - i’m not totally
>> sure how but this als could be used in setting a per shot SD. i have
>> not looked much into this.
> 
> I think you want to treat that as an in-cave indication that you should
> check for sources of magnetic interference and redo affected readings.

Good Advice!

Thanks!

--max

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


Re: [Therion] Detecting errors

2019-09-05 Thread Olly Betts
On Fri, Aug 16, 2019 at 05:11:22AM +0200, MD wrote:
> We also then to measure the same small loop at the beginning  of each trip: 
> A-B in four device orientations
> B-A in four device orientations
> A-C in four device orientations
> C-A in four device orientations
> C-B once
> 
> So I could calculate an SD based on that. 

You probably don't want to work out a set of SDs per-trip - there
would be quite a lot of random fluctuation in the observed SDs
from such a short loop, and an equivalent instrument properly calibrated
and used with suitable care really ought to be able to achieve similar
SDs.

Combining information from a lot of such small test loops would be
interesting though.

We've been doing some surface measurements at home with our disto-x2
while planning some building work and I did some experimenting with
setting different SDs and looking at how the loop error values are,
and I found the following SDs seem to be achievable with care:

*sd tape 0.002 metres ; 2 millimetres
*sd compass clino 0.5 degrees
*sd position 0.05 metres ; 5 centimetres

The tape/compass/clino are just taken from Beet's disto-x2 article:
http://paperless.bheeb.ch/download/DistoX2.pdf

I've glossed over exactly what a "precision" of 2mm means and assumed
it's just the standard deviation.  It might actually mean the SD is
even smaller, but that's pretty much irrelevant as the compass, clino
and position errors will swamp any contribution from the tape (1m at
0.5 degrees is 8.7mm).

The position error reflects how close I think I can reliably position
the spot I've marked on the back of the disto relative to the "from"
station plus the error in where the laser beam hits compared to the
"to" station.

I haven't tested if those are still reasonable underground.  There
should be less electromagnetic noise underground, but it's often
colder and wetter underground than in our front garden, and I've found
misty or dusty air can cause problems for the disto.

I'd be interested to hear what people can actually achieve in-cave.

> For sone Devices errors seem to be bound very much to orientation. In
> the data saved by TopoDroid you can see the device orientation and so
> we could set a sd based on the direction in which the shot was taken.
> I have nit investigated this further so far. Also because we have this
> data only for about 20% of the cave.

This is already taken into account - you tell Survex the SD for the
"tape" (read laser range-finder), "compass" and "clino" (read magnetic
field measuring devices) and position (how close to the station you
actually measure from) and it uses the direction of the leg to produce
a 3D set of expected errors, which are then summed along each traverse.

> TopoDroid also is able to flag an “magnetic anomaly” - i’m not totally
> sure how but this als could be used in setting a per shot SD. i have
> not looked much into this.

I think you want to treat that as an in-cave indication that you should
check for sources of magnetic interference and redo affected readings.

Cheers,
Olly
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-09-04 Thread Olly Betts
On Thu, Aug 15, 2019 at 10:06:05PM +0100, Olly Betts wrote:
> The colour scale is fixed such that blue is "good" and anything else
> is suspect.  You probably want to look at the worst first.
> 
> Once you have a suspect traverse identified, you can look it up in the
> .err file which is produced alongside the .3d file when you process the
> data.  Here's an example entry:
> 
> 76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
> 76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
> Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   3.90%
> 4.920289
> H: 5.888476 V: 0.864600
> 
> Here 4.920289 is the number of sds (which is what aven colours by).  But
> below that the H and V are the equivalent numbers looking only at the
> horizontal and vertical errors.

Survex 1.2.42 (released yesterday) adds the ability to colour by
horizontal or vertical error (H and V above), so you can zoom in on
a suspect traverse based on the overall error, and then check how
its H and V values compare based on the colouring.

> So here the vertical error is very good,
> and the horizontal error lousy.  That suggests the error is probably either
> in a compass reading or the tape reading in a low-inclination leg.  (If
> H was fine and V bad, you'd be looking for a clino error or a tape error
> in a steep leg or plumb.)
> 
> So you can now look at each of the legs in the list on the first line and
> look at their compass readings and the tape readings for any low-inclination
> legs.  For manually entered data, compare with the original notes.

Another tip is that a common error type is a "mis-tie" - connecting a
new survey to the wrong existing station(s).

This is probably especially prevalent in long running survey projects
with a turnover of the people involved.  For example, it's all to easy
to tie to the "first bolt of the traverse" but fail to realise
somebody's extended the traverse since the original survey.  This sort
of problem affects both electronic and traditional instruments.

My experience is that the largest errors tend to turn out to be
mis-ties (but not all mis-ties result in large errors).  Mis-ties will
tend to have bad H and V, though maybe H will tend to be a bit less bad
(because it's easier to mis-tie to something in the same passage or
chamber, and harder to mix up top vs bottom of a pitch).

If you suspect a mis-tie, I would try simply disconnecting each end of
the problematic survey in turn.  If that makes the remaining network
look good then you can see what stations the disconnected end is near
to give you some candidates to consider for where it perhaps should be
tied to.

Cheers,
Olly
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-20 Thread Max D


> On 20. Aug 2019, at 11:21, Max D  wrote:
> 
>> 
>> On 20. Aug 2019, at 11:15, Bruce Mutton  wrote:
>> 
>> Survex loop closure seems to be fed arbitrary station names 
> 
> Maybe be we can ask Therion to dump a mapping between svx station names and 
> it's own names. 

We can!

1. Ensure that you generate an SQL export in your thcondig: 
export database -format sql -output mycave.sql

2. load the data in SQLite (it comes preinstallted on MAc and most Linux boxes):
rm -f cave.db
sqlite3 mycave.db < /mycave.sql

3. extract the data you want:


sqlite3 mycave.db 
.headers on
SELECT s.ID as sid, (s.NAME || '@' || su.NAME) AS station FROM STATION s LEFT 
OUTER JOIN SURVEY su ON s.SURVEY_ID=su.ID where s.NAME not in ('-', '.') order 
by sid;
.mode tabs
.output stations.tsv
SELECT s.ID as sid, (s.NAME || '@' || su.NAME) AS station FROM STATION s LEFT 
OUTER JOIN SURVEY su ON s.SURVEY_ID=su.ID where s.NAME not in ('-', '.') order 
by sid;
.quit

The file ' stations.tsv' should now contain the desired mapping. IT looks like 
this:

sid station
1   1.0@g1
2   1.1@g1
3   1.2@g1

If you have much deeper nested surveys the code could be extended to resolve 
them. For me one level is enough to know what was meant by the station name.

--max

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


Re: [Therion] Detecting errors

2019-08-20 Thread Max D


> On 20. Aug 2019, at 11:15, Bruce Mutton  wrote:
> 
> Survex loop closure seems to be fed arbitrary station names 

Maybe be we can ask Therion to dump a mapping between svx station names and 
it's own names. Something like this but for all stations:


therion.log
…
### cavern log file 
 1> Survex 1.2.27
 2> Copyright © 1990-2016 Olly Betts
…
13> Vertical range = 77.55m (from 11088 at 202.55m to 10918 at 125.00m)
14> North-South range = 651.00m (from 10917 at 5650639.00m to 10918 at 
5649988.00m)
15> East-West range = 630.39m (from 10918 at 391931.00m to 43 at 391300.61m)
… # transcription 
13> 11088 : C@g28aussen.aussen -- 10918 : B@virtuelle_verbindungen.aussen
14> 10917 : A@virtuelle_verbindungen.aussen -- 10918 : 
B@virtuelle_verbindungen.aussen
15> 10918 : B@virtuelle_verbindungen.aussen -- 43 : 2_14s1@g2.windloch2019
…
 end of cavern log file 

but for all stations.

--max

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


[Therion] Detecting errors

2019-08-20 Thread Bruce Mutton
OK, I found it.

Therion stores it in the thTMPDIR folder, which can be preserved if one
follows the guidance here 

https://therion.speleo.sk/wiki/metapost#how_to_get_therions_metapost_code_an
d_tex_code

 

Survex loop closure seems to be fed arbitrary station names (no survey
structure) by Therion, but you can kind of work it out if you open the .3d
file with Aven.  A bit daunting with 35000 stations though.  I found that I
can right-click the data.err file, and sort its contents by various error
metrics.

 

This is pretty cool, and highlights just how embarrassingly bad some of our
early pre-disto loop closures were.

It is a tool that gives some hope of systematically debugging and solving
possible locations of the bad data, or highlighting passages for possible
resurvey.

 

I guess Survex users have always known of this functionality, but it adds a
new dimension for this Therion user. 

 

Bruce

 

+

 

 

-Original Message-
From: Olly Betts  
Sent: Tuesday, 20 August 2019 11:27
To: Bruce Mutton 
Cc: 'List for Therion users' 
Subject: Re: [Therion] Detecting errors

 

On Fri, Aug 16, 2019 at 02:23:20PM +1200, Bruce Mutton wrote:

> I'm a Therion user (not Survex), although I use survex loop closure.

> That gives some additional statistics in the Therion log file, but not 

> the loop error standard deviations.  I wonder if Therion (or Cavern) 

> could incorporate these in the log file, or if Aven could be made to 

> list them?

 

Cavern already produces such a file - that's exactly what the .err file I'm
referring to here tells you:

 

> > 76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 -
76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10

> > Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error
3.90%

> > 4.920289

> > H: 5.888476 V: 0.864600

 

I'm not sure what happens to that file when therion calls cavern to process
data though.  I keep my survey data in .svx files and process as a separate
step, then point therion at the .3d file.

 

Cheers,

Olly

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


Re: [Therion] Detecting errors

2019-08-19 Thread Olly Betts
On Fri, Aug 16, 2019 at 02:23:20PM +1200, Bruce Mutton wrote:
> I'm a Therion user (not Survex), although I use survex loop closure.
> That gives some additional statistics in the Therion log file, but not
> the loop error standard deviations.  I wonder if Therion (or Cavern)
> could incorporate these in the log file, or if Aven could be made to
> list them?

Cavern already produces such a file - that's exactly what the .err file
I'm referring to here tells you:

> > 76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
> > 76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
> > Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   
> > 3.90%
> > 4.920289
> > H: 5.888476 V: 0.864600

I'm not sure what happens to that file when therion calls cavern to
process data though.  I keep my survey data in .svx files and process
as a separate step, then point therion at the .3d file.

Cheers,
Olly
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-15 Thread MD
Thanks for all the suggestions. Especial the „Aven colored by error“ is a 
superb starting point.

We do not always  practice paperless caving but Disto X1/X2 devices are used 
for everything.

So we get a SD from
Calibrating - although to my understanding this value is something different 
then the survey sd.

We also then to measure the same small loop at the beginning  of each trip: 
A-B in four device orientations
B-A in four device orientations
A-C in four device orientations
C-A in four device orientations
C-B once

So I could calculate an SD based on that. 

For sone Devices errors seem to be bound very much to orientation. In the data 
saved by TopoDroid you can see the device orientation and so we could set a sd 
based on the direction in which the shot was taken. I have nit investigated 
this further so far. Also because we have this data only for about 20% of the 
cave.

TopoDroid also is able to flag an “magnetic anomaly” - i’m not totally sure how 
but this als could be used in setting a per shot SD. i have not looked much 
into this.

Regards

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


Re: [Therion] Detecting errors

2019-08-15 Thread Bruce Mutton
I second Ollies advice.
I'm a Therion user (not Survex), although I use survex loop closure.  That 
gives some additional statistics in the Therion log file, but not the loop 
error standard deviations.  I wonder if Therion (or Cavern) could incorporate 
these in the log file, or if Aven could be made to list them?

The graphical presentation in Aven is of course the best, but sometimes a 
written list is useful as well.

Bruce

-Original Message-
From: Therion  On Behalf Of Olly Betts
Sent: Friday, 16 August 2019 09:06
To: MD 
Cc: therion@speleo.sk
Subject: Re: [Therion] Detecting errors

On Thu, Aug 15, 2019 at 10:17:00AM +0200, MD wrote:
> I wonder what people use to find errors. For example im I have too 
> loops L1 and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4%
> error) i can assume that the error is in the stations/shots which are 
> part of L2 but not L1. Is there an automated approach for that?

I would avoid looking at the percentage error - what's reasonable varies 
depending on the number of legs in the loop, and also how long the legs are, so 
you can't simply compare the percentage errors for two different loops.

What's more useful is what the observed error is compared to what you'd expect 
the error to be based on the grade(s) of the survey(s).  The grades say things 
like "compass readings within one degree" and from that you can work out what 
you'd expect the error for each leg to be (in 3 dimensions) and sum those to 
get the expected error for each traverse.

Benedikt's suggestion to view coloured by error in aven is where I would start 
(right click on the colour key is the easiest way to change what to colour by). 
 This shows you each traverse coloured by its error measured in standard 
deviations - assuming the grades are appropriate then 99.7% of readings should 
be within 3 standard deviations:

https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule

The colour scale is fixed such that blue is "good" and anything else is 
suspect.  You probably want to look at the worst first.

Once you have a suspect traverse identified, you can look it up in the .err 
file which is produced alongside the .3d file when you process the data.  
Here's an example entry:

76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   3.90%
4.920289
H: 5.888476 V: 0.864600

Here 4.920289 is the number of sds (which is what aven colours by).  But below 
that the H and V are the equivalent numbers looking only at the horizontal and 
vertical errors.  So here the vertical error is very good, and the horizontal 
error lousy.  That suggests the error is probably either in a compass reading 
or the tape reading in a low-inclination leg.  (If H was fine and V bad, you'd 
be looking for a clino error or a tape error in a steep leg or plumb.)

So you can now look at each of the legs in the list on the first line and look 
at their compass readings and the tape readings for any low-inclination legs.  
For manually entered data, compare with the original notes.

It's still somewhat manual, but at least you can narrow down where to look 
significantly.

Cheers,
Olly
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion

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


Re: [Therion] Detecting errors

2019-08-15 Thread Olly Betts
On Thu, Aug 15, 2019 at 10:17:00AM +0200, MD wrote:
> I wonder what people use to find errors. For example im I have too
> loops L1 and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4%
> error) i can assume that the error is in the stations/shots which are
> part of L2 but not L1. Is there an automated approach for that?

I would avoid looking at the percentage error - what's reasonable
varies depending on the number of legs in the loop, and also how
long the legs are, so you can't simply compare the percentage errors
for two different loops.

What's more useful is what the observed error is compared to what you'd
expect the error to be based on the grade(s) of the survey(s).  The
grades say things like "compass readings within one degree" and from
that you can work out what you'd expect the error for each leg to be
(in 3 dimensions) and sum those to get the expected error for each traverse.

Benedikt's suggestion to view coloured by error in aven is where I
would start (right click on the colour key is the easiest way to change
what to colour by).  This shows you each traverse coloured by its error
measured in standard deviations - assuming the grades are appropriate
then 99.7% of readings should be within 3 standard deviations:

https://en.wikipedia.org/wiki/68%E2%80%9395%E2%80%9399.7_rule

The colour scale is fixed such that blue is "good" and anything else
is suspect.  You probably want to look at the worst first.

Once you have a suspect traverse identified, you can look it up in the
.err file which is produced alongside the .3d file when you process the
data.  Here's an example entry:

76.brave.18 - 76.brave.17 - 76.brave.16 - 76.brave.15 - 76.brave.14 - 
76.brave.13 - 76.brave.12 - 76.brave.11 - 76.brave.10
Original length  32.35m (  8 legs), moved   1.26m ( 0.16m/leg). Error   3.90%
4.920289
H: 5.888476 V: 0.864600

Here 4.920289 is the number of sds (which is what aven colours by).  But
below that the H and V are the equivalent numbers looking only at the
horizontal and vertical errors.  So here the vertical error is very good,
and the horizontal error lousy.  That suggests the error is probably either
in a compass reading or the tape reading in a low-inclination leg.  (If
H was fine and V bad, you'd be looking for a clino error or a tape error
in a steep leg or plumb.)

So you can now look at each of the legs in the list on the first line and
look at their compass readings and the tape readings for any low-inclination
legs.  For manually entered data, compare with the original notes.

It's still somewhat manual, but at least you can narrow down where to look
significantly.

Cheers,
Olly
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-15 Thread Benedikt Hallinger
... forgot to mention, survex can display the errors visually, when generated 
from therion this way. When you marked the surveys accordingly you can see 
which loops are bad and which ones are good in the polylines. This greatly aids 
in finding problematic or faulty measurements.

For traditional surveys i also usually get good results with the morphing 
information of therion (big morphing at stations suggests faulty data when the 
sketch is accurate).

> Am 15.08.2019 um 11:50 schrieb Benedikt Hallinger :
> 
> To expand a little in this, you could also use the standard „grade“ to tell 
> theriob which centerline data has which quality. We use this to mark the 
> centerlines we have surveyed with distox and traditional way and therion uses 
> this to put more of the errors towards the more bad survey.
> 
> See therion book page 34 for all details needed.
> 
>> Am 15.08.2019 um 11:41 schrieb Martin Sluka via Therion :
>> 
>> Somebody else could answer you more detailed.
>> 
>>> 15. 8. 2019 v 10:17, MD :
>>> 
>>> Our current project is nearing 2000 Stations in a labyrinth and things 
>>> start to get cumbersome. We have more than 100 Loops detected by therion.
>>> 
>>> I wonder what people use to find errors. For example im I have too loops L1 
>>> and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can 
>>> assume that the error is in the stations/shots which are part of L2 but not 
>>> L1. Is there an automated approach for that?
>> 
>> Not automated. You may use Survex method for loop closure and check detailed 
>> report in therion.log. If you compile (export to PDF) data (or particular 
>> data) with parameter -d (debug) you should receive graphical representation 
>> of the biggest error - the yellow line.
>> 
>>> We have Disto X (no transcription errors possible) and  traditional 
>>> (transcription errors likely) surveys. How to handle that?
>> 
>> You may set errors for data in any particular centerline section - ''sd'' 
>> parameter
>> 
>> Martin
>> 
>> ___
>> Therion mailing list
>> Therion@speleo.sk
>> https://mailman.speleo.sk/listinfo/therion
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-15 Thread Benedikt Hallinger
To expand a little in this, you could also use the standard „grade“ to tell 
theriob which centerline data has which quality. We use this to mark the 
centerlines we have surveyed with distox and traditional way and therion uses 
this to put more of the errors towards the more bad survey.

See therion book page 34 for all details needed.

> Am 15.08.2019 um 11:41 schrieb Martin Sluka via Therion :
> 
> Somebody else could answer you more detailed.
> 
>> 15. 8. 2019 v 10:17, MD :
>> 
>> Our current project is nearing 2000 Stations in a labyrinth and things start 
>> to get cumbersome. We have more than 100 Loops detected by therion.
>> 
>> I wonder what people use to find errors. For example im I have too loops L1 
>> and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can 
>> assume that the error is in the stations/shots which are part of L2 but not 
>> L1. Is there an automated approach for that?
> 
> Not automated. You may use Survex method for loop closure and check detailed 
> report in therion.log. If you compile (export to PDF) data (or particular 
> data) with parameter -d (debug) you should receive graphical representation 
> of the biggest error - the yellow line.
> 
>> We have Disto X (no transcription errors possible) and  traditional 
>> (transcription errors likely) surveys. How to handle that?
> 
> You may set errors for data in any particular centerline section - ''sd'' 
> parameter
> 
> Martin
> 
> ___
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion


Re: [Therion] Detecting errors

2019-08-15 Thread Martin Sluka via Therion
Somebody else could answer you more detailed.

> 15. 8. 2019 v 10:17, MD :
> 
> Our current project is nearing 2000 Stations in a labyrinth and things start 
> to get cumbersome. We have more than 100 Loops detected by therion.
> 
> I wonder what people use to find errors. For example im I have too loops L1 
> and L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can 
> assume that the error is in the stations/shots which are part of L2 but not 
> L1. Is there an automated approach for that?

Not automated. You may use Survex method for loop closure and check detailed 
report in therion.log. If you compile (export to PDF) data (or particular data) 
with parameter -d (debug) you should receive graphical representation of the 
biggest error - the yellow line.

> We have Disto X (no transcription errors possible) and  traditional 
> (transcription errors likely) surveys. How to handle that?

You may set errors for data in any particular centerline section - ''sd'' 
parameter

Martin

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


[Therion] Detecting errors

2019-08-15 Thread MD
Our current project is nearing 2000 Stations in a labyrinth and things start to 
get cumbersome. We have more than 100 Loops detected by therion.

I wonder what people use to find errors. For example im I have too loops L1 and 
L2 and L1 is “good” (0.1% error) while L2 is “bad” (4% error) i can assume that 
the error is in the stations/shots which are part of L2 but not L1. Is there an 
automated approach for that?

When I add a new loop and the overall error goes up it is likely, that this 
loop is faulty. Any way to automatically check that?

I also read the “Error Detection in Compass” page and couldn’t understand much 
mire than “we just try out”.

We have Disto X (no transcription errors possible) and  traditional 
(transcription errors likely) surveys. How to handle that?

Any suggestions besides loads of manual work?
___
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion