sexagesimal
Alberto Conti
aconti at stsci.edu
Mon Sep 18 05:20:56 PDT 2006
In the XML Schema Part 2: Datatypes Second Edition (http://www.w3.org/
TR/xmlschema-2/#isoformats) you will find the most common
implementation of ISO 8601.
Google Earth, for example, has added support for ISO 8601 in KML to
allow for new time tags like <timespan>.
Ciao,
Alberto
On Sep 18, 2006, at 5:25 AM, Gilles DUVERT wrote:
> 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
>
>
> <Gilles.Duvert.vcf>
___________________________________________________
Alberto Conti, Ph.D.
Chief Engineer
Space Telescope Science Institute (STScI)
3700 San Martin Drive, Baltimore MD 21218
Tel: 410-338-4534 Fax: 410-338-1592
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20060918/88c6424c/attachment-0001.html>
More information about the dm
mailing list