From: Richard Knapp (richfk_at_attglobal.net)
Date: Tue Jul 02 2002 - 13:17:44 CEST
Return-Path: <owner-cavexml-outgoing_at_ethz.ch> Delivered-To: cavexml-archive_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 778681593E for <cavexml-outgoing_at_ethz.ch>; Tue, 2 Jul 2002 14:21:51 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 5359D15929; Tue, 2 Jul 2002 14:21:49 +0200 (CEST) Delivered-To: cavexml-loopcheck_at_ethz.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 131DF1593E for <cavexml-loopcheck_at_ethz.ch>; Tue, 2 Jul 2002 14:21:48 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id E8E2115915; Tue, 2 Jul 2002 14:21:45 +0200 (CEST) Delivered-To: cavexml_at_cartography.ch Received: from localhost (localhost [127.0.0.1]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 9C5C21593E for <cavexml_at_cartography.ch>; Tue, 2 Jul 2002 14:21:45 +0200 (CEST) Received: from prserv.net (out1.prserv.net [32.97.166.31]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id E396C15911 for <cavexml_at_cartography.ch>; Tue, 2 Jul 2002 14:21:42 +0200 (CEST) Received: from Muphin (slip-12-65-13-54.mis.prserv.net[12.65.13.54]) by prserv.net (out1) with SMTP id <2002070212202220105j5gj5e>; Tue, 2 Jul 2002 12:20:23 +0000 From: "Richard Knapp" <richfk_at_attglobal.net> To: "cavexml_at_cartography.ch" <cavexml_at_cartography.ch> Date: Tue, 02 Jul 2002 07:17:44 -0400 (EDT) X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 In-Reply-To: <3D2087D9.7060702_at_xmission.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Progress report - cave survey data model Message-Id: <20020702122142.E396C15911@karmail.ethz.ch> X-Loop: cavexml Sender: owner-cavexml_at_karmail.ethz.ch Precedence: bulk Reply-To: cavexml_at_cartography.ch X-Virus-Scanned: by AMaViS perl-11
Paul:
> So how is a shot made to define a wall, i.e. a 'Ray', any different than a
> normal shot? It seems a shot is a shot, it is just that if you did have many ...
Peter:
> A fair enough comment, Paul. I must admit I considered the same question
> myself - Are they different to "normal" shots? My view was that they were ...
Alexander:
> I think this is correct. Moreover, they can even have both endpoints not
> connected with the survey line at all. Say, I have the final point of the ...
Some thoughts:
Information is being "adding" to the collected data by drawing the implicit out and
making it explicit. This allows other, more detailed information to be included as well.
However, the point remains that more information will be available in CaveXML than was in
the survey book. So precision cannot be to the collected data; it must stay in the
imprecise state it was collected. Most people take wall measurements by estimation, not
by actual measurement.
In its simplest terms, this is nothing more than a vector. There is a starting point and
an end point defined in spherical coordinates which is very similar to a shot. Both a
shot and a "ray" could be defined as parent Entities with the following structure:
<!ENTITY Ray (From, Azimuth, Distance, Inclination)>
But is that a good definition? A Shot can contain more than one azimuth and inclination
(backsights or multiple readings). Would it be valid to allow the same on a wall
dimension? Probably not. To keep the idea that the data is not as important as a Shot, it
might be better to make the representation simpler:
<!ENTITY Ray EMPTY>
<!ATTLIST Ray
from CDATA #REQUIRED
azimuth CDATA "0"
inclination CDATA "0"
distance CDATA #IMPLIED>
However, this does not allow for "offsetting" the dimension along the leg of the shot. In
this example, a station would have to be set for these dimesions to be input. It would be
nice if the existing Shot vector could be used with an offset (from From). Granted, this
makes calculations a bit more complicated but it is more similar to how the data is
collected (right or wrong).
Say I'm surveying down a passage. I've got passage dimensions at the From station but
note the line has gone through a small room and out the other side. Does the survey team
now set a new station in the center of the room (remember a small room) just to record
the dimensions? More than likely not. It is noted on the sketch the location and size of
the room. But if dimensions are wanted, how would it be done? More than likely, the text
would be:
"About ten feet down the shot, a room is encountered with dimensions of...."
so a series of rays were taken about ten feet down the shot. Could this be worked in as
well? It would be rather constraining to limit the model to only accept passage dimension
data at a set station.
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST