From: Peter MATTHEWS (matthews_at_melbpc.org.au)
Date: Tue Jul 02 2002 - 21:48:25 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 D678315801 for <cavexml-outgoing_at_ethz.ch>; Tue, 2 Jul 2002 21:50:56 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id AF45114AE9; Tue, 2 Jul 2002 21:50:54 +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 6BD1315801 for <cavexml-loopcheck_at_ethz.ch>; Tue, 2 Jul 2002 21:50:53 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 3CAA414ADC; Tue, 2 Jul 2002 21:50:51 +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 E546815801 for <cavexml_at_cartography.ch>; Tue, 2 Jul 2002 21:50:50 +0200 (CEST) Received: from relay1.melbpc.org.au (newglider.melbpc.org.au [203.12.152.9]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 8B6E414A89 for <cavexml_at_cartography.ch>; Tue, 2 Jul 2002 21:50:47 +0200 (CEST) Received: from localhost.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by relay1.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g62JnAQO078904 for <cavexml_at_cartography.ch>; Wed, 3 Jul 2002 05:49:10 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) Content-Type: text/plain; charset="us-ascii"; format=flowed Date: Wed, 03 Jul 2002 05:48:25 +1000 From: Peter MATTHEWS <matthews_at_melbpc.org.au> In-Reply-To: <20020702122142.E396C15911_at_karmail.ethz.ch> Message-Id: <5.1.0.14.1.20020703054505.01d8a120@popa.melbpc.org.au> Received: from relay1.melbpc.org.au (localhost.melbpc.org.au [127.0.0.1]) by localhost.melbpc.org.au (AvMailGate-2.0.0.6) id 78811-78F14DCC; Wed, 03 Jul 2002 05:49:01 +1000 Received: from peter.melbpc.org.au (a2-40.melbpc.org.au [203.12.157.40]) by relay1.melbpc.org.au (8.12.3/8.11.6) with ESMTP id g62Jmwsm078765 for <cavexml_at_cartography.ch>; Wed, 3 Jul 2002 05:48:59 +1000 (EST) (envelope-from matthews_at_melbpc.org.au) References: <3D2087D9.7060702_at_xmission.com> Subject: Re: Progress report - cave survey data model To: cavexml_at_cartography.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 X-Sender: matthews_at_popa.melbpc.org.au 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
Richard:
>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 is the "Interpoint" entity in my list. "Coming real soon now!" ;-)
Peter
At 07:17 02-07-02 -0400, Richard Knapp wrote:
>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