Fwd: Re: http://www.ngs.noaa.gov/FGCS/BlueBook/ (fwd)

New Message Reply About this list Date view Thread view Subject view Author view

From: R Knapp (gyp_caver_at_yahoo.com)
Date: Thu Feb 07 2002 - 03:10:17 CET

Return-Path: <owner-cavexml-outgoing_at_ethz.ch>
Delivered-To: cavexml-archive_at_cartography.ch
Received: from localhost (localhost []) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id C03CA9F13 for <cavexml-outgoing_at_ethz.ch>; Thu,  7 Feb 2002 03:37:09 +0100 (CET)
Received: by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0, from userid 28) id 8149E9F15; Thu,  7 Feb 2002 03:37:06 +0100 (CET)
Delivered-To: cavexml_at_cartography.ch
Received: from localhost (localhost []) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with ESMTP id 666649F13 for <cavexml_at_cartography.ch>; Thu,  7 Feb 2002 03:37:05 +0100 (CET)
Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com []) by karmail.ethz.ch (Postfix on SuSE eMail Server 2.0) with SMTP id 957079E76 for <cavexml_at_cartography.ch>; Thu,  7 Feb 2002 03:37:01 +0100 (CET)
Received: from slip-12-64-170-164.mis.prserv.net (HELO Muphin) ( by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Feb 2002 02:16:31 -0000
From: "R Knapp" <gyp_caver_at_yahoo.com>
To: "CaveXML" <cavexml_at_cartography.ch>
Date: Wed, 06 Feb 2002 21:10:17 -0500 (EST)
X-Mailer: PMMail 2.20.2370 for OS/2 Warp 4.5
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Fwd: Re: http://www.ngs.noaa.gov/FGCS/BlueBook/ (fwd)
Message-Id: <20020207023701.957079E76@karmail.ethz.ch>
Sender: owner-cavexml_at_karmail.ethz.ch
Precedence: bulk
Reply-To: cavexml_at_cartography.ch
X-Virus-Scanned: by AMaViS perl-11

Some of the discussion John and I have been having recently.

==================BEGIN FORWARDED MESSAGE==================
> From: "R Knapp" <gyp_caver_at_yahoo.com>
> To: "John Halleck" <John.Halleck_at_utah.edu>
> Date: Wed, 06 Feb 2002 07:49:28 -0500 (EST)

> > Before, you were talking about having an element with the raw value and a cononical
> > value. I think the canonical units were degrees for angles and meters for distance.
> > Is that correct? So for a distance element:
> >
> > <Distance value="10"/>
> >
> > the canonical representation you mentioned would be something like:
> >
> > <Distance value="10" canon_value="3.05"/>
> >
> > or
> >
> > <Azimuth value="N30E" canon_value="30.0"/>
> >
> > Is this correct?
> Yes. With the argument that if cannonical values exist then things
> later in the pipeline can be simpler and small utilities are easy
> to keep small.

It shouldn't be a problem to add them to the DTD, just repetitive (this is where Schemas
excel; I could create a new type with the canonical value there instead of repeating the
attribute for each element.)

I can see the value of the entry. This will add a bit (a very small bit) of burden to an
editor but that is all. And since it would be a one-way conversion, there should not be
as much a loss of precision as if it was two-way (due to rounding errors).

Now, what units to use.

- Should length be metric or English? Either choice w/could incur conversion back to the
other "base" for misc calculations (length, depth, etc).

- Should angles be degrees or radians? Radians have the advantage of being friendly to
computers (most functions like rads and not degrees) but again there might be a
conversion back for misc calculations (rose diagrams, etc).

Maybe there could be an attribute/element that specifies this information at the top of
the XML file?

> > <Position value="standing" location="bottle of ivory liquid">
> Huh?

(An XML way of saying Standing on Soap Box. In my case, I use a bottle of Ivory Liquid
since I usually fall off halfway through.)

> > This was driving him nuts and I can understand why. I just don't want the final data
> > format.. whatever that might be.. to have the same issues.
> A value for precision takes care of this, no?
> 3.1 in that case is really 3.1+-0.05 so a precison of 0.05 and a value of 3.1 would
> be reasonable.

I guess that depends. With a +-0.05m that could be as much as 0.1m between two shots.
Thinking more about this later, I'm guessing COMPASS does not discard the extra decimal
places; it just doesn't display them. Discarding them would be very bad.

Should this discussion head to the list? It's beens so quite there it might regenerate
some interest.

        Richard Knapp

===================END FORWARDED MESSAGE===================

        Richard Knapp

Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

New Message Reply About this list Date view Thread view Subject view Author view

This archive was generated by hypermail 2b30 : Thu Feb 28 2002 - 23:00:00 CET