sexagesimal

[Roy Williams]

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>