Hi Xavier

I tried your approach and like it a lot.

Unfortunately I get the same result; 

-specified std errors result in gross distortion,

-no std errors give accurate survey plot (but forced to specified gps
location without accounting for it’s inaccuracy)



Other ideas?

Perhaps it’s time to try 5.3.12

Bruce



  _____  

From: therion-bounces at speleo.sk [mailto:therion-boun...@speleo.sk] On Behalf
Of Xavier Pennec
Sent: Sunday, 22 December 2013 9:52 p.m.
To: therion at speleo.sk
Subject: Re: [Therion] fixed point std error causes extreme survey network
distortion



Hi Bruce,

I have hundreds of fixed points with different accuarcy and never noticed
the effect you are describing. However, I am not fixing directly the
coordinates of stations of my survey. I always create independant fixed
points and then equate them to the survey stations. In your case, this would
give something like:

   fix GPS_12   1562372 5439558 992    20 20 20  # entrance
   equate GPS_12 12 at 01
   fix GPS_0      1562117 5440239 1080  5  5   20  # another entrance
   equate GPS_0 0 at 10
   fix GPS_120  1562124 5439500 1020  10 10 10  #entrance three
   equate GPS_120 120 at 05

An advantage of this strategy is that I can comment all the equates but one
to start with and verify with Aven on the 3d file where are the GPS points
located with respect to the cave survey. That way, I can spot the outliers
in the GPS points (or the errors in their retranscription) and iteratively
validate the equates.

Xavier

PS: between us, I would not qualify your gps stddev below as very rough. A
stddev of 5 meters about the smallest I use when I get long GPS averages
(more than 30 minutes) with one of the a differential satellites. 




Le 22/12/2013 01:35, Bruce a écrit :

I got some unexpected results recently when I added some very rough gps
coordinates to my survey for a cave that has three entrances.  Because they
are approximate I added some estimates of standard errors as below, so that
I could get Therion to factor the relative accuracy into the loop closure.



   fix 12 at 01    1562372 5439558 992    20 20 20  # entrance

   fix 0 at 10      1562117 5440239 1080  5  5   20  # another entrance

   fix 120 at 05  1562124 5439500 1020  10 10 10  #entrance three



With any ONE of the entrances fixed as above, the cave plots accurately – I
can verify this in Google Earth.

As soon as I have any two or more entrances fixed, then the cave distorts
significantly, and the entrances are stretched some hundreds of metres away
from the centroid of the cave.  Also quite often getting ‘scrap exceeding
maximal scale’ errors if I output to pdf.



I checked this was not just a feature of that dataset by mocking up a
similar situation in two other datasets, and got similar results.



The work around seems to be to avoid using the standard errors;



   fix 12 at 01    1562372 5439558 992    #20 20 20   entrance

   fix 0 at 10      1562117 5440239 1080  #5  5   20   another entrance

   fix 120 at 05  1562124 5439500 1020  #10 10 10  entrance three



but this then results in each gps location receiving equal weighting.

I think I might have noticed this problem a few years ago, and gave up on
trying to sort it out because I wasn’t able to identify the characteristics
of the problem well enough.



Anyone else having problems like this?

Or identify a reason why what I am trying to do is not possible?

Or is it a bug?



Bruce

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mailman.speleo.sk/pipermail/therion/attachments/20131224/527bbe86/attachment.html>

Reply via email to