From: Richard Knapp (richfk_at_attglobal.net)
Date: Thu Jul 11 2002 - 16:52:30 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 7DE1714A46 for <cavexml-outgoing_at_ethz.ch>; Thu, 11 Jul 2002 18:30:41 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 593C114874; Thu, 11 Jul 2002 18:30:39 +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 4F46114A46 for <cavexml-loopcheck_at_ethz.ch>; Thu, 11 Jul 2002 18:30:38 +0200 (CEST) Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 96) id 29C948B22; Thu, 11 Jul 2002 18:30:36 +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 E0CF414A46 for <cavexml_at_cartography.ch>; Thu, 11 Jul 2002 18:30:35 +0200 (CEST) Received: from prserv.net (out4.prserv.net [32.97.166.34]) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 3CA118A96 for <cavexml_at_cartography.ch>; Thu, 11 Jul 2002 18:30:33 +0200 (CEST) Received: from Muphin (<unknown.domain>[12.65.48.138]) by prserv.net (out4) with SMTP id <20020711162051204063k65ve>; Thu, 11 Jul 2002 16:20:51 +0000 From: "Richard Knapp" <richfk_at_attglobal.net> To: "cavexml_at_cartography.ch" <cavexml_at_cartography.ch> Date: Thu, 11 Jul 2002 10:52:30 -0400 (EDT) X-Mailer: PMMail 2.20.2380 for OS/2 Warp 4.5 In-Reply-To: <3D2DD9A9.8080201_at_aic.nrl.navy.mil> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: comments on the data model Message-Id: <20020711163033.3CA118A96@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
On Thu, 11 Jul 2002 19:16:57 +0000, Ralph Hartley wrote:
> Richard Knapp wrote:
> > When COMPASS does loop closure
> > ("corrected data"), it creates a copy of the DAT file with new
> > distances, azimuths, and inclinations (and sometimes survey ties).
>
> Does it?
Yes. (see below)
> If true, this would be rather bizare, reducing the data to get best
> fitting x,y,z coordinates, and then converting them back into "corrected
> survey shots". I have never heard of any other program that does that.
> However, my memory, and a quick look, indicate that it is not true;
> Compass ".plt" files contain absolute cartesian coordinates (There may
> be some Compass options or something that do this, but it isn't the
> normal way, and I've never seen it).
True, the PLT files do contain only X, Y, and Z coordinates. However,
if you select Close loops and run it on either a Make (MAK) or Data
(DAT) file, you will get a CLP file which is almost an exact
duplicate of the DAT file, except for corrections made to reading.
Compass uses this file to create another PLT file with the new X, Y,
Z coordinates. (I just tried this on WinCompass 3.00.09.16)
> > Are you saying that is the correct way to handle this (separate
> > files) or should this be stored with the raw data?
>
> With the raw data, but distinguished from it, is preferred. I think I
> agree with you on this point, but I don't know if you can enforce it.
> Some people are certian (for various reasons) to disagree.
I don't see any problem with putting loop closure information in the
data file as long as it is clearly labeled.
The would be a problem on shots with multiple measurements: back and
front sights or just multiple azimuths/inclinations. It might be more
distinct - for lack of a better term - to keep that information out
of the Measurement Element. (Again, for lack of a better term...)
Maybe something like:
<Shot>
<Measurement type="Azimuth" direction="forward" cvalue="90"/>
<Measurement type="Azimuth" direction="forward" cvalue="95"/>
<Measurement type="Azimuth" direction="backward"
cvalue="273.5"/>
<Measurement type="Inclination" cvalue="-5.0"/>
<Measurement type="Distance" value="10 6" cvalue="10.5"/>
<Closure using="LeastSquares" azimuth="92.5"
inclination="-4.7" distance="10.5"/>
<Closure using="NetworkAdjustment" azimuth="91.5"
inclination="-5.0" distance="10.5"/>
</Shot>
This would allow multiple closing methods to be applied to a
cave/system and not overwrite each other. All necessary spherical
coordinate data would be part of that element (as children or
attributes).
> > Measurements
> > already have a cvalue (or at least did for a while) to store the
> > canonical value of the measurement. Why not have a similar attribute
> > for corrected values?
>
> You must also already have a way to store abosolute coordinates (for
> fixing the datum, gps stations etc.) as well. That's what everyone
> computes so that's what should be stored. A computed position,
> preferably labeled in some way as to how (e.g. by what program) it was
> computed, shouldn't be a problem.
Measurements do not address compiled/absolute coordinates, just the
raw data items (azimuth, distance, inclination).. unless I'm reading
the text wrong.
> Also there is a data safety issue. If even one shot is missing, (due to
> file corruption, deliberate editing, or if the data is in several files
> but you don't have them all) then some or all of the position data is lost.
That would be just as true for multiple files as it would for a
single file; any file can be corrupted, especially with all the junk
(ie virii) running around on the net these days. Which is why it
seems reasonable to have the compiled (coordinate data) in one,
separate file instead of in many files.
(enough for now)
This archive was generated by hypermail 2b30 : Wed Jul 31 2002 - 23:00:00 CEST