From: John Halleck (John.Halleck_at_utah.edu)
Date: Mon Feb 12 2001 - 21:18:13 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id VAA10029 for cavexml-outgoing; Mon, 12 Feb 2001 21:18:16 +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 VAA10025 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 21:18:15 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id NAA04063 for <cavexml_at_cartography.ch>; Mon, 12 Feb 2001 13:18:14 -0700 (MST) Date: Mon, 12 Feb 2001 13:18:13 -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: <3A884043.8060502_at_aic.nrl.navy.mil> Message-ID: <Pine.GSO.4.05.10102121257470.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 14:57:55 -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:
>
> > "THE" spanning tree? Spanning trees are not unique.
> > (I usually go for minimal spanning trees myself... which
> > for the cave surveys I have are unique, and not order dependent.)
> > [I will admit that there could be cases where the minimal
> > tree not unique, but I've never seen them actually occur in
> > real life.)
>
> And even that is not unique unless there is agreement on the metric with
> respect to which the tree is minimal.
Of course.
>The length of the shots in the tree is just one possibility.
I've been using inverse of the magniture of the shot's covariance matrix.
> Another useful tree would be one where the
> non included shots are chosen to be the ones believed to have the most
> error.
Which is what the measure above in some sense gives.
> [...]
> John Halleck again:
>
> > Note that CaveXML support for these don't have to be anything
> > extensive. For Unique compact point numbers it is only
> > one more (optional) attribute on a point. For spanning trees it is
> > just one more (optional) attribute on a shot.
>
> Except that mixing raw data and processed data is evil.
> The problem is
> when you have a single set of survey shots which has been processed by
> more than one program. Keeping the processed data separate from the raw
> data (as the proposed processeddata element does) lets each program
> report which (if any) tree it used, without mangling each other's
> results, even if they cannot agree on a common tree.
You make a very good point here. Some separation needs to be made
if multiple programs want to put conceptually equivalent data in.
Maybe something separate such as the following?
...
<Processblock Name="FCOM's Parser" ID="FCOM" When="2001-02-12 12:20:44">
...
</Processblock>
<Processblock Name"Outofahat Productions" ID="OTAH" When "1998-01-11 11:30:32">
...
</Processblock>
<Point ....>
<Processed Source="FCOM">
... my xxx information ...
</Processed>
<Processed Source="OTAH">
... Someonelses xxx information ...
</Processed>
</Point>
> But a format that includes unclosed lineplots already includes a way to
> output a tree.
>
> Ralph Hartley
>
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:01 CET