# sexagesimal

Gilles DUVERT Gilles.Duvert at obs.ujf-grenoble.fr
Mon Sep 18 02:25:24 PDT 2006

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>