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?
Somebody else could answer you more detailed.
15. 8. 2019 v 10:17, MD <md@foxel.org>:
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
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 <therion@speleo.sk>:
Somebody else could answer you more detailed.
15. 8. 2019 v 10:17, MD <md@foxel.org>:
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
... 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 <beni@hallinger.org>:
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 <therion@speleo.sk>:
Somebody else could answer you more detailed.
15. 8. 2019 v 10:17, MD <md@foxel.org>:
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
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/
On 6. Sep 2019, at 18:31, Wookey <wookey@wookware.org> 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
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
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 <therion-bounces@speleo.sk> On Behalf Of Olly Betts Sent: Friday, 16 August 2019 09:06 To: MD <md@foxel.org> 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
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
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 <olly@survex.com> Sent: Tuesday, 20 August 2019 11:27 To: Bruce Mutton <bruce@tomo.co.nz> Cc: 'List for Therion users' <therion@speleo.sk> 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
On 20. Aug 2019, at 11:15, Bruce Mutton <bruce@tomo.co.nz> 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
On 20. Aug 2019, at 11:21, Max D <md@foxel.org> wrote:
On 20. Aug 2019, at 11:15, Bruce Mutton <bruce@tomo.co.nz> 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
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
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
On 5. Sep 2019, at 08:28, Olly Betts <olly@survex.com> 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
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 <md@foxel.org>:
On 5. Sep 2019, at 08:28, Olly Betts <olly@survex.com> 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
<Screenshot_20190720-135115_TopoDroid.jpeg> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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 <md@foxel.org> 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.
On 6. Sep 2019, at 08:01, Ben Cooper <ben@caver.plus.com> 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
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
5. 9. 2019 v 13:10, Max D <md@foxel.org>:
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
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 <md@foxel.org>:
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
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 <herich@speleodd.sk>:
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 <md@foxel.org>: 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
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-bounces@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 <md@foxel.org>: 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
6. 9. 2019 v 11:02, Markus Boldt <markus.boldt@gmx.net>:
in Ebensee I have asked you, if this part is buyable. Is it? And when where.
Hi Marcus, as I know it is not. But there are several sources of CAD or 3D printers data for it you may find on internet. I made my based on this design:
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
participants (10)
-
Ben Cooper -
Benedikt Hallinger -
Bruce Mutton -
Markus Boldt -
Martin Sluka -
Max D -
MD
-
Olly Betts -
Pavel Herich -
Wookey