sexagesimal

[Gilles DUVERT]

Considering the DataModel, correct me if i am wrong, but what is 
important are the coordinates themselves (which ones, in which reference 
frame, what accuracies on them, etc), not their format.  Physically, 
this things are angles, and already, In the international system MKSA,  
angles are expressed in RADIANS...  Is this sexagesimal question really 
part of DM work?

Anyway, enforcing a better use of the sexagesimal notation for 
coordinates and _times_ is a good idea, although I do not think today's 
data producer amuse themselves to write "borderline" sexagesimal 
coordinates/times.

In fact, since the whole planet use sexagesimal notation for time, it 
has been de facto fixed by ISO 8601 standard, and it would only 
complicate things if VO standards were markedly different from ISO ones.

For me, a sexagesimal notation of a real number is  3 numerical fields 
separated by ONE "separator type". The purpose of this notation
is to encode in a traditional historical complicated way a real number, 
which is obtained by the formula:
value = PI / 180 * first_field*3600.0+second_field*60.0+third_field.
Note that if, according to  Murphy rule, the "value" you obtained is of 
type "right ascension" or "time", then you have to multiply by 15.0 
"value" to get radians and start doing physics.

Rule: the first field is a signed integer (but sign may be omitted if 
positive), the second an unsigned integer of TWO digits not greater than 
59, the third an unsigned float of any precision, absolutely less than 
60.0, whose integer part is written with TWO digits.
If, when writing the sexagesimal value, the rightmost field is null, it, 
and its separator from the fields to its left, can be omitted (and the 
process repeated until exhaustion of simplification).
The separator between the fields is THE SAME (like ins CSV) , but can be 
an abstract construction:

    * 64
    * 6435
    * 64D35
    * 643526
    * 643526.546
    * +64:35:26.546
    * +64 35 26.546
    * +64<sup>d</sup>35<sup>m</sup>26.546

are all OK, since for the last example the separator is of the <sup> 
persuasion (to quote Piers Anthony). You could even have a bit of java 
code making a  separator in a widget, between <java> tags!

Note that the "null" separator is allowed because 6435 is 64:35 and not 
643:5 since the last fields have two digits or none.
Note also this is of the same line of thought  as in the ISO 
recommandation for DATE (the separator is "-": 1955-02-04)

This leaves out perfectly human-readable values (using 100% of their 
brain capacity):

    * 64<sup>d</sup>35<sup>m</sup>25<sup>s</sup>546 ! 4 fields
    * 64D35M26.546 ! two different separators. Worse, people infer these
      are degrees from the first separator!
    * 64°35'26."546   ! three and a spurious decimal sign. But the best
      we could we do when we had only mechanical typewriters...
    * -12:3:2.225        ! not good number of digits
    * \def\degr{\hbox{$^\circ$}} \def\arcmin{\hbox{$^\prime$}}
      \def\farcs{\hbox{$.\!\!^{\prime\prime}$}}
      64\degr35\arcmin26\farcs546  ! Although one could write a TeX
      macro that coudl automatically format nicely a sexagesimal
      notation following the norm..
    * 643
    * 64352
    * etc...


... But recommending the form "(+)64:35:26.546" would be a good idea. 
And recommending that angles be expressed as floats, not sexagesimal, 
and perhaps even in radians (after all, nobody's going to look at the 
XML, all values will be mediated by data converters in the user's 
preferences), would be a still better idea.

Best

Gilles


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20060918/8e10395b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gilles.Duvert.vcf
Type: text/x-vcard
Size: 382 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20060918/8e10395b/attachment-0001.vcf>