From: John Halleck (John.Halleck_at_utah.edu)
Date: Mon Feb 12 2001 - 00:05:20 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id AAA03286 for cavexml-outgoing; Mon, 12 Feb 2001 00:05:24 +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 AAA03282 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 00:05:22 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id QAA27810 for <cavexml_at_cartography.ch>; Sun, 11 Feb 2001 16:05:21 -0700 (MST) Date: Sun, 11 Feb 2001 16:05:20 -0700 (MST) From: John Halleck <John.Halleck_at_utah.edu> To: "'cavexml_at_cartography.ch'" <cavexml_at_cartography.ch> Subject: RE: Other areas that haven't been discussed. In-Reply-To: <Pine.GSO.4.05.10102111512310.26377-100000_at_cor.oz.cc.utah.edu> Message-ID: <Pine.GSO.4.05.10102111547370.26377-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 Sun, 11 Feb 2001, John Halleck wrote:
> Date: Fri, 9 Feb 2001 20:46:31 -0500
> From: Thrun Robert IHMD <ThrunR_at_ih.navy.mil>
> Reply-To: cavexml_at_cartography.ch
> To: "'cavexml_at_cartography.ch'" <cavexml_at_cartography.ch>
> Subject: RE: Other areas that haven't been discussed.
>
> On Thursday, February 08, 2001 7:52 PM, John Halleck said:
>
> > 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...)
>
> Any program that uses a spanning tree will generate its own
> using the survey data.
Bob, the way you handle survey data is not the only way
that data can be handled.
Spanning trees have many uses. For example, if a program
finds loops having a spanning tree availiable makes it easy.
Most importantly from my point of view, spanning trees
can be updated when combining two files, with less effort
than they can be computed from scratch. Just as with
L.S. adjustments, you can update what you have with something
new with relatively small overhead compared with the overhead
of doing the entire thing from scratch.
I am personally a fan of programs that do incremental updates
of data instead of massive "do it all over" approaches. You
may or may not me, I don't know. But I think that membership
in the spanning tree (or not) is a useful thing to know about
a shot. While I could recompute it, if I provide it, with
some basic programs to use it, then I think it could save
others work.
It also fits well with my view of the world that the processing
should be a parser to put things into a "standard" form (Maybe
CaveXML) and then several small programs that can take that
form and do things (such as adjustments) with it. In that
context I would want the ability to update what I have with
new stuff without redoing everything (such as spanning trees
and adjustments).
I'm not asking you to share this view.
But I don't think that you ought to argue against a
simple OPTIONAL shot attribute such as InMinimalSpanningTree,
that doesn't cost much, and could be useful to me.
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET