From: John Halleck (John.Halleck_at_utah.edu)
Date: Fri Feb 09 2001 - 19:54:00 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA10573 for cavexml-outgoing; Fri, 9 Feb 2001 19:53:20 +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 TAA10569 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 19:53:19 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id LAA22828 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 11:54:00 -0700 (MST) Date: Fri, 9 Feb 2001 11:54:00 -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: <3A84388E.8050606_at_aic.nrl.navy.mil> Message-ID: <Pine.GSO.4.05.10102091135400.11013-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 Fri, 9 Feb 2001, Ralph Hartley wrote:
> > Identification of a spanning tree.
> > Most graph programs I've seen (and therefore I assume cave
> > survey programs) find loops by working from a (minimal)
> > spanning tree. This takes processing to find, but one only
> > needs to note if they are in the tree or not...)
> >
> > Point locations on this tree.
> > I.E. An unadjusted set of coordinates.
> >
> > Indentification 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.)
> information is important. For others (pure least squares) it has no
> effect on the outcome (but may be computed to permit optimization).
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.
> 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.
> (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 explict tree, because it has more uses
than just the line plot.
> > "Intermediate" processing information (method specific).
> > For most processing methods (particularly LS) there exist
> > methods for updating an adjustment on the fly that take
> > notibly less work than doing the entire adjustment again.
> > It would be nice to have some way of stating this so that
> > appropriate programs could add new surveys quickly.
>
> This starts to get tricky.
My disclaimer at the front of the original pointed out that many of my
"wish list" might be inappropriate for the current discussion.
> Each program has its own set of intermediate
> data, stored in its own representation. The only way to include it in
> general would be as proprietary data. We want to discourage that if we
> can. One way to do that is to have a standard way to store a lot of what
> a program needs, but I'm not real optimistic.
I don't agree with this... The method forces some specific information.
But I don't think any further discussion here is appropriate (it is
too academic an issue). Contact me privately if you want to discuss this.
> [...]
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET