From: Michael Lake (mikel_at_speleonics.com.au)
Date: Wed Jan 24 2001 - 11:55:45 CET
Received: (from mdom_at_localhost) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id OAA08634 for cavexml-outgoing; Wed, 24 Jan 2001 14:05:34 +0100 Received: from iggy.triode.net.au (IDENT:root_at_iggy.triode.net.au [203.63.235.1]) by karto.ethz.ch (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA08630 for <cavexml_at_cartography.ch>; Wed, 24 Jan 2001 14:05:32 +0100 Received: from speleonics.com.au (mikel_at_dm1-23.triode.net.au [203.63.34.24]) by iggy.triode.net.au (8.11.1/8.10.1) with ESMTP id f0OD5lY30393 for <cavexml_at_cartography.ch>; Thu, 25 Jan 2001 00:05:47 +1100 Message-ID: <3A6EB4B1.911D0B8E@speleonics.com.au> Date: Wed, 24 Jan 2001 21:55:45 +1100 From: Michael Lake <mikel_at_speleonics.com.au> X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.14 i686) X-Accept-Language: en To: cavexml_at_cartography.ch Subject: Re: Splitting SHOT into constituent members References: <057601c085a1$46e9f320$0a3c10ac_at_gordon> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cavexml_at_karto.baug.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch
Julian Todd wrote:
> Here's another approach to the problem of defining some amazingly
> elaborate <SHOT></SHOT> definition with hundreds of attributes,
Well we won't have hundreds of attributes. If we do then we have done it wrong :-)
> 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.
Disagree there if I understand that your suggesting that who does the measurement, and
when, takes priority or defines the structure of the data rather than the 'natural'
structure of the data. Not well explained but to me the natural structure of shot data
consists of azimuths, elevations, distances and stations (2 or more). Together they make
up an abstract entity called a shot or leg (that itself we can also argue about later). I
would keep that as a group irrespective of who or when the data was collected.
Naturally software can parse the XML extract out the SURVEYOR and DATE elements, use a
XSLT and create a nice HTML page or screen formatted anyway one wants ie by person say.
But the actual shots in an XML file should be structured the same as the shot 'entity'.
> 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?
<![%ifdiving; [
<!ATTLIST SHOT
FROMDEPTH CDATA #IMPLIED
TODEPTH CDATA #IMPLIED
]]>
The AZIM & DIST atributes are the same as for dry caving.
> 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>
Well not everyone. I have, until convinced otherwise :-), DIST ELEV AZIM as attributes of
a shot entity. I dont like using <tape> for distance. Distance is a piece of measurement
data, tape is an instrument! Otherwise if people use rangefinders would you have
<rangefinder>5.5</rangefinder> and have to create anew element for every instrument used
to measure distance ... same for azimiths.
<suunto>30</suunto> <forestrycompass>35</forestrycompass>
Best to have
<INSTRUMENTS>
<TAPE NAME="SUSS11" ZERO_CORRECT="+0.1" DESC="30m fibreglass"</TAPE>
<COMPASS ID="SUSS1">Suunto Twin</COMPASS>
<CLINO ID="SUSS2"/>
</INSTRUMENTS>
> Superficially this would become
> <clino from=88, to=88a>78<intr serialno=099999A/><readby name=toad/></clino>
Good. I see you also can see that a name and an ID are different and not necessarily the
same.
> <clino from=88a, to=88>-76<readby name=jim/></clino>
Important: I would invoke an instance of the SURVEYOR element to bring name="jim" into
scope. Because jim is a surveyor which is a different entity to the shot. Surveyor itself
will have several attributes (eyesight="short" hehe...) which we can't do if we have jim
as a part of the shot.
> 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.
Humans call one a backsight but the XML or software couldn't care less. The from and to
define the shot and it does not matter if we call it a backsight just cause from=81 to=80
> Instruments, operators, time and units are all independent.
YES so thats why they are different ELEMENTS as they are different entities and
independent.
We agree there? :-)
> Without that restriction we can present the measurements in
> chronological order and more easily extract data from one
> particular instrument, say.
Parse the XML and: extract all SHOTS where element SURVEYOR is NAME="mary"
> 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.
Yes. A natural structure.
> 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).
Ah yes. I will think about that. We could handle that if we don't make AZIM, ELEV a
required value.
> And cave diving depth data where
> the following non-excusive data defines a so-called shot vector:
No prob. see DEPTHFROM etc above.
> 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.
Disagree. But it has got me to think about things hard.
Time for me to go to bed :-)
Mike
-- -------------------------------------------------------------------- Michael Lake Active caver, Linux enthusiast and interested in anything technical. Safety Convenor, Australian Speleological Federation Owner, Speleonics (Australia) --------------------------------------------------------------------
This archive was generated by hypermail 2b30 : Wed Feb 14 2001 - 00:03:52 CET