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
>
>
>
> _______________________________________________
> Therion mailing list
> Therion at speleo.sk
> http://mailman.speleo.sk/mailman/listinfo/therion
--
> -------------------------
> Xavier Pennec
> Senior Research Scientist / Directeur de recherche
> Asclepios project-team, INRIA Sophia-Antipolis
> 2004 Route des Lucioles, BP93
> F-06902 Sophia-Antipolis Cedex, France
> +33 4 92 38 76 64
> +33 6 78 35 16 90
> http://www-sop.inria.fr/asclepios/
> -------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.speleo.sk/pipermail/therion/attachments/20131222/12c72271/attachment.html>
