sexagesimal

[Alberto Conti]

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>