Re: sexagesimal

From: Roy Williams <roy-at-cacr.caltech.edu>
Date: Sat, 16 Sep 2006 15:44:24 -0700

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 Received on 2006-09-17Z00:45:00