Error in loop closure algorithm?

[Mike McCombe]

----- Original Message ----- 
From: "Olly Betts" <olly at survex.com>
To: "John Halleck" <John.Halleck at utah.edu>
Cc: "Mike McCombe" <mikemccombe at btinternet.com>; "Survex User Group"
<survex at survex.com>
Sent: Thursday, August 12, 2004 5:47 PM
Subject: Re: Error in loop closure algorithm?


> On Thu, Aug 12, 2004 at 08:44:34AM -0600, John Halleck wrote:
> >   By the way, in order to sove the least squares problem at all you
> >   have to tie down the location of at least one point.
>
> Survex will fix the first station mentioned at the origin if no points
> are fixed.  So station 1 will have coordinates (0,0,0).
>
> The rationale is that it's fairly common to have a cave survey which
> hasn't (yet) been tied into any point for which coordinates are known,
> and it's convenient for the software to pick an arbitrary coordinate
> system rather than force the user to pick one.
>
> >   I think it obvious, but worth stating, that any shot between
> >   a given loop, and the control point, is not statistically
> >   independent of that blunder.  (Since all sections between
> >   the control point and a given point contribute SOMETHING)
> >   to the computation of the coordinates.
>
> I don't follow what you're trying to say here at all.  I suspect you
> must mean something other than "statistically independent" in its
> normal mathematical sense...
>
> The example Mike gave (with the implicit fixing of station 1) has a loop
> with a control point and a single leg linking this to a second loop with
> a blunder in.  That's rather different to the linked loops example you
> gave in an earlier mail.
>
> Mike's network has articulation points at either end of the single
> linking leg so solving the first loop (and fixing the coordinates of all
> the stations in it) then solving the second loop should be equivalent to
> solving the whole system.  Hence nothing in the second loop should
> affect the coordinates of stations in the first loop.
>
> I suspect the problem here is a loss of precision somewhere in the
> calculations.  My initial prime suspect is where the coordinates are
> coverted from real numbers to integer cms while writing the .3d file.
>
> Cheers,
>     Olly
>
> -- 

I can't disagree with John's argument but, as Olly points out, it's a very
different case to the one I described which had no coupling between the
loops. If it turns out to be a numerical precision problem, so much the
better - assuming it can be fixed without me having to move to Linux!

All the best,
Mike