From: John Halleck (John.Halleck_at_utah.edu)
Date: Fri Feb 09 2001 - 01:52:02 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id BAA01292 for cavexml-outgoing; Fri, 9 Feb 2001 01:51:26 +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 BAA01288 for <cavexml_at_cartography.ch>; Fri, 9 Feb 2001 01:51:24 +0100 Received: from localhost (nahaj_at_localhost) by cor.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id RAA15496 for <cavexml_at_cartography.ch>; Thu, 8 Feb 2001 17:52:02 -0700 (MST) Date: Thu, 8 Feb 2001 17:52:02 -0700 (MST) From: John Halleck <John.Halleck_at_utah.edu> To: cavexml_at_cartography.ch Subject: Other areas that haven't been discussed. Message-ID: <Pine.GSO.4.05.10102081723110.5063-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
The issues of dealing with processed data in CaveXML remind me that
there are some other things that I'd like to see in CaveXML.
These issues may be issues for a later version... but I'll bring
them up.
I see CaveXML as the repositary for all the information we have
(or chose to keep together). In the case of "adjusted" data
it seems clear that we would want to make some allowance for
including it, possibly marked with how we got it. But there
are also many other bits of processing that it would be nice
to have instead of just recomputing each time. (Some of these
may be trivial, some may be things that the rest of the group
thinks unnecessary, but I'll give it a shot.
Obviously, these should be optional.
(And appropriate processing program could take their absence
as a reason to ask the user if they want it generated.)
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.
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.
"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.
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>
This archive was generated by hypermail 2b30 : Thu Mar 01 2001 - 18:00:00 CET