From: Ralph Hartley (hartley_at_aic.nrl.navy.mil)
Date: Fri Feb 09 2001 - 19:35:58 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id TAA10440 for cavexml-outgoing; Fri, 9 Feb 2001 19:32:11 +0100 Received: from sun0.aic.nrl.navy.mil (sun0.aic.nrl.navy.mil [132.250.84.10]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id TAA10436 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 19:32:09 +0100 Received: from aic.nrl.navy.mil (pc31.aic.nrl.navy.mil [132.250.84.181]) by sun0.aic.nrl.navy.mil (8.9.3+Sun/8.9.3) with ESMTP id NAA24374 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 13:32:52 -0500 (EST) Message-ID: <3A84388E.8050606@aic.nrl.navy.mil> Date: Fri, 09 Feb 2001 13:35:58 -0500 From: Ralph Hartley <hartley_at_aic.nrl.navy.mil> User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010124 X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Other areas that haven't been discussed. References: <Pine.GSO.4.05.10102081723110.5063-100000_at_cor.oz.cc.utah.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
John Halleck wrote:
> Unique numbering of points.
> Point numbers can make some match up easier. In the case
> where a program interprets "AB24", "ab24" and "ab-24" as the
> same point, giving them the same number means that programs
> that are case sensitive can import the data without having
> to have code to deal with the details of the other program's
> assumptions on name equivalence.
>
> "Canonical" point names.
> Besides the unique number, it might be useful to have
> the cannonical name of the point. Not only useful in
> the previous case, but if a processing program supports
> "equivalencing" names, one can keep the original in the
> data, and also give the name it is "really" known as.
This would also be very useful when converting data to and from a
program that has restrictions on what constitutes a legal name. The "to"
converter would generate a unique legal name, and record which station
it corresponds to. Results from the program could then be merged back
into the file in a "processed" element, with no ambiguity about which
stations are which.
> 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
information is important. For others (pure least squares) it has no
effect on the outcome (but may be computed to permit optimization). 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
(often it is determined by historical accident). Any description of the
unclosed lineplot must (explicitly or not) describe that tree.
> "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. 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.
> A CaveXML version.
> XML may not have different versions, but any DTD or schema
> we use is likely to change over time, and I'd like to know
> what version I've been handed... if nothing else, just
> to tell the user that this file may have stuff I couldn't
> process. (Maybe in a root element?)
> <CaveXML version="1.0">
> ...
> </CaveXML>
Gotta have it.
Ralph Hartley
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET