Re: Other areas that haven't been discussed.

New Message Reply About this list Date view Thread view Subject view Author view

From: John Halleck (John.Halleck_at_utah.edu)
Date: Mon Feb 12 2001 - 17:38:07 CET


Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id RAA09067 for cavexml-outgoing; Mon, 12 Feb 2001 17:38:08 +0100
Received: from cor.oz.cc.utah.edu (nahaj_at_cor.oz.cc.utah.edu [155.99.2.2]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id RAA09062 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 17:38:07 +0100
Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id JAA22380 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 09:38:08 -0700 (MST)
Date: Mon, 12 Feb 2001 09:38:07 -0700 (MST)
From: John Halleck <John.Halleck_at_utah.edu>
To: cavexml_at_cartography.ch
Subject: Re: Other areas that haven't been discussed.
In-Reply-To: <3A87FC69.4080606_at_aic.nrl.navy.mil>
Message-ID: <Pine.GSO.4.05.10102120931030.19817-100000@cor.oz.cc.utah.edu>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cavexml_at_karto.baug.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch

On Mon, 12 Feb 2001, Ralph Hartley wrote:

> Date: Mon, 12 Feb 2001 10:08:25 -0500
> From: Ralph Hartley <hartley_at_aic.nrl.navy.mil>
> Reply-To: cavexml_at_cartography.ch
> To: cavexml_at_cartography.ch
> Subject: Re: Other areas that haven't been discussed.
>
> John Halleck wrote:
>
> > On Fri, 9 Feb 2001, Ralph Hartley wrote:
> >
> >>>
> >>> Identification of some set of loops.
> >>> I assume that reasons for this would be obvious.
> >>
> >> I would classify this as a special case of "Intermediate" processing
> >> information. For some ways of processing the data(sequential loop
> >> closure, the number of possible loops can be astronomical) this sort of
> >
> > Astronomical? For minimal loops it can't be any worse than the
> > redundancy. I'm not talking ALL (redundant), just a minimal set.
> > (For a survey with 1000 points and 1100 shots, there can only
> > be 100 loops in a minimal set. (Which can be derived from the
> > spanning tree + the shots not in it.)
>
> I mean there are an astronomical number of loops to choose from to form
> a minimal set, not that any particular minimal set will have an
> unreasonable number of loops. Is it allways the case that any minimal
> set of loops is uniquely determined by a spanning tree?

  No... It is the case that the number of loops is fixed, with one
  loop for edge (shot) not in the tree. And one way to come up with
  loops is to walk back down the tree from the two endpoints, and use
  those loops. But that doesn't account for (often minimal) loops
  that involve another redundant edge. (But there is a clean algorithm
  that can do those.)
 
> Also, talk of *a* spanning tree seems to imply that all the stations are
> connected. Unfortunately, hanging surveys are rather common, and need to
> be handled.

  Good point.

> > But even in "pure" least squares, it will be needed to try to identify
> > the blunders if the reference variance of the adjustment is too high.
>
> I know I am being a little pedantic here, but identifying blunders is
> not a part of least squares at all.

  But the survey books I have state that identifying and fixing blunders
  is part of a proper adjustment involving least squares.
  LS applied by itself, without anything further when the statistics are
  bad is a poor idea.

> >> The
> >> minimal spanning tree is fairly easy to recompute, but an unclosed line
     ************************
> >> plot depends on a particular tree, that may not be minimal in any sense
> >
> > But the unclosed line plot can be read off of a minimal spanning tree.
                                                      *********************
>
> Off the spanning tree used to make the plot. That might not be a minimal
> spanning tree.

  Clearly the discussion was of minimal spanning trees.

> >
> >> (often it is determined by historical accident). Any description of the
> >> unclosed lineplot must (explicitly or not) describe that tree.
> >
> >
> > I was campaining for an explicit tree, because it has more uses
            **********
  I can't spell.

> > than just the line plot.
>
> I agree. An unclosed line plot has two parts: a tree, and the
> coordinates of the points. The tree needs to include the closing shots
> to the "unclosed images" of tie in stations. It is relatively easy to
> recompute the lineplot given the original data and the spanning tree
> used. Given a lineplot it is easy to get the spanning tree it was based on.
>
> A good format for a lineplot should make the spanning tree easy or
> trivial to obtain (e.g. it could contain an explicit tree).

  There are good algorithms that just mark the edges in the MST,
  instead of explicitly listing the tree.
 
> Ralph Hartley


New Message Reply About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET