From: Julian Todd (julian_at_ncgraphics.co.uk)
Date: Wed Jan 24 2001 - 02:01:19 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id CAA05687 for cavexml-outgoing; Wed, 24 Jan 2001 02:05:03 +0100 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id CAA05683 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 02:04:58 +0100 Received: from [213.123.20.139] (helo=gordon) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14LEMn-0006nU-00 for cavexml_at_cartography.ch; Wed, 24 Jan 2001 01:04:54 +0000 Message-ID: <057601c085a1$46e9f320$0a3c10ac@gordon> From: "Julian Todd" <julian_at_ncgraphics.co.uk> To: <cavexml_at_cartography.ch> Subject: Splitting SHOT into constituent members Date: Wed, 24 Jan 2001 01:01:19 -0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Hi there,
Here's another approach to the problem of defining some amazingly
elaborate <SHOT></SHOT> definition with hundreds of attributes,
nested parameters, backsights, crazy cross-sections, alternative
instruments and so forth.
It's not actually necessary to group a set of measurements into a single
complex structure. In fact, since we take each measurement separately
(rather than simultaneously) and often these are done by different
people (two people hold the tape, but only one reads the compass),
it is more faithful to record the measurements separately.
I don't see why, if you have a very clear location of your survey
stations, you can't go through the whole cave passage with just
compass and clino, and come back another day and take
all the tape measurements with a friend? If you suspect an error
in the survey you normally look for a single measurement rather
than the whole shot as being the source of the problem.
Some measurements, such as depth measured by a cave diver,
can't really be associated to a shot, because they are of a single station.
What shot would you force it into?
So, the current way everyone is thinking about is:
<shot from=88, to=88a>
<tape>5.5<units t=metres/></tape>
<compass>45<comment>dodgy</compass>
<clino>78<intr serialno=099999A/><readby name=toad/></clino>
<backsight>
<clino>-76<readby name=jim/></clino>
</backsight>
</shot>
Superficially this would become
<tape from=88, to=88a>5.5<units t=metres/></tape>
<compass from=88, to=88a>45<comment>dodgy</compass>
<clino from=88, to=88a>78<intr serialno=099999A/><readby name=toad/></clino>
<clino from=88a, to=88>-76<readby name=jim/></clino>
So what's the advantage? Well, now we are in a better position to
define the properties of what could happen. A single measurement
is an instantaneous event, and we can concern ourselves with defining
all the properties about it (who did it, with what gadget, and
what did it say)
To me, forcing triples or quadruples of measurement events into a single
shot
grouping structure feels artificial and unnecessary. Pretty
much the only thing that is shared between these events are their
"from" and "to" fields -- and these are the other way round when
you do a backsight. Instruments, operators, time and units
are all independent.
Without that restriction we can present the measurements in
chronological order and more easily extract data from one
particular instrument, say.
The only other reason to group these measurements up (apart from
saving your "from" and "to" attributes in 2/3 of the XML records)
is because that set of data defines a single shot vector.
Now, I believe that the computer can sort through all the data pertaining
the relative locations of stations "A" and "B" and work all this out
for itself. Sure, the shot record will supposedly stop you from
creating an ill-defined leg -- maybe. But we already know
about collecting enough information to define the geometry;
nothing currently stops us from making unconnected legs,
but we don't do it. Likewise, we wouldn't forget to take
a tape measurement just because there is no shot structure
which requires it.
There are also other methods of measurements where there is
no such shot grouping. Trilateration, for example, where the data is
only tape measurements (when there are enough of them, the
geometry becomes rigid). And cave diving depth data where
the following non-excusive data defines a so-called shot vector:
<depthgauge station=A depth=5.15/>
<tape from=A to=B distance=18.8/>
<compass from=B to=A bearing=89.0/>
<depthgauge station=B depth=8.32/>
Yes, a perfectly good survey can be made without a clino if
you have a depthgauge. Maybe in air we can back-up our
survey with altimeter readings on some of the survey stations.
As I think I have said before, I consider the survey notes
that we bring out of the cave with us are simply that: shorthand
notes. They are brief, ambiguous and -- rightly -- recorded
in a convention chosen by the surveyor. Their formats
are not to be taken as the basis for communication or
record keeping any more than any other type of personal
live note form. They should be transcribed and expanded
(by hand or with a small parsing routine) into a non-ambiguous
precise XML format. I claim that the <shot> structure
has no place in such a format because it is not general,
not necessary and can force measurements (such as depthgauge
measurements) into places they don't naturally belong.
Julian Todd.
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET