NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/protocol/tcpip/domains/898

Internet Message Format | 1993-01-24 | 1.7 KB

Path: sparky!uunet!spool.mu.edu!agate!ames!sun-barr!decwrl!pa.dec.com!vixie
From: [e-mail] (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Positional data within DNS
Date: 24 Jan 93 00:52:12
Organization: DEC Network Software Lab
Lines: 20
Distribution: inet
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: [e-mail]'s message of Fri, 22 Jan 1993 21:25:33 GMT

> If this is going to be used in geographical calculation
> wouldn't radians or something make sense?  Or is the factor
> one of can we look it up in the printed maps in the local library?

radians are a more rational (in my opinion) way to represent polar
coordinates, but they are generally fractional.  i'm not sure this
matters, since the best idea i've heard so far is to allocate N bits
for the coordinate and then choose a unit that will maximize
resolution for the neccessary range.  thousandths of seconds would fit
in an unsigned 32-bit integer, for example.  my bit-field idea was
over-designed.  if we use radians rather than degrees, we have to pick
an implied decimal point, or we need someone who knows more than i do
about floating point arithmetic to pick the encoding.  i suppose we
could define it as a network-byte-order 32-bit IEEE float (that's a
joke, please, nobody shoot me.)
--
Paul Vixie, DEC Network Systems Lab
Palo Alto, California, USA             "Don't be a rebel, or a conformist;
<[e-mail]> decwrl!vixie        they're the same thing, anyway.  Find
<[e-mail]>     vixie!paul        your own path, and stay on it."  -me