# sexagesimal

Roy Williams roy at cacr.caltech.edu
Sat Sep 16 15:44:24 PDT 2006

```On Sep 16, 2006, at 1:36 PM, Rob Seaman wrote:

> Hi Roy,
>
>> it takes hundreds of lines of code to understand something like 5h:
>> 23m,35d:12m:23".23 and all its tortured friends.
>
> Well, yeah, but I don't see how your proposal is going to avoid the
> need for for translators when importing non-IVOA data.

I believe that the IVOA should Recommend something. Not a requirement.
>
>> My suggestion is to say that the IVOA understands a sexagesimal
>> position if and only if it fits the definition as "six numbers
>> separated by non-numbers". It is a very simple defintion and yet
>> accepts almost all the formats that are used.
>
> Surely what you're describing are two sexagesimal numbers?

Yes. Lets try to be a bit precise. We define a Sexg to be a
representation of an angle. The number of "hours or degrees" is the
integer hds. It includes a conversion factor from hds to degrees.
There is a converter degreesPerHds which is 15 or 1 for hours or
degrees. A Sexg is equivalent to a data structure:
struct Sexg {
int hds;
int minutes;
float seconds;
float degreesPerHds;
}
It is represented as a sequence of numbers separated by strings of
non-digits. Note that there is a strange conversion to degrees
because the sign of hds is carried to the minutes and seconds fields.
Note also that -5hours 30minutes 00seconds becomes -5.5 hours.

The sky position object is then
struct skyPosition {
Sexg longitude;  // will be shifted to be >=0 and <360
Sexg latitude;     // illegal if <-90 or >90
}

>
>> an IVOA sexagesimal position must consist of the numbers RAh, RAm,
>> RAs, Decd, Decm, Decs, and there can be arbitrary "non-number"
>> characters separating them.
>
> Well, there's nothing about sexagesimal formats that implies the
> specification of equatorial - or even spherical - coordinates, just
> base-60.  Other than that, for reading a pair of coordinates, your
> heuristic is serviceable.
>
> For writing sexigesimal numbers, there's no reason not to be more
> specific - IVOA can require colon separators and zero-filled, two
> digit fields.  (Omit leading zeros.)

I am afraid that this will block us from the Recommendation. Nothing
more unseemly than academics fighting over their colons. That is why
I propose to very liberal by allowing anything separated by "non-
digit" characters. Writers have freedom and reading is easy. The only
real constraint is that both minutes and seconds MUST be provided.

> The final field of any specification can be a floating point of
> whatever precision.  Not all sexigesimal values have three fields,
> many have two fields, hh:mm.mmm, for instance.  In IRAF, such a
> number is recognized as simply another floating point format.

We can allow the minutes to be float, but ask IRAF to add seconds:
hh:mm.mmm:00.
There could be a translation in the XML to add the :00.

Roy

California Institute of Technology
626 395 3670

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20060916/6c28dcff/attachment-0001.html>
```