sexagesimal

[Alberto Micol]

Roy Williams wrote:

> Well then they are not compliant. I just want to know if there is a  
> serious momentum to clean up the sexg mess. Am I the only person  
> who thinks it's a mess? If so, then I will be happy to forget about  
> it.

YOU:ARE:NOT THE:ONLY:ONE.

It would be actually useful to have a precise definition which could be
used in VOTABLE context, as part of the standard.
Is this the inauguration of the IVOA Data Type WG? ;-)


On Sep 17, 2006, at 03:09, Tom McGlynn wrote:

> There are lots of perfectly readable coordinates that would flunk  
> and are used in the literature.
> I do not believe you want to use a system that simply throws out the
> the non-numeric pieces of the coordinates.

If the non-numeric pieces matter, then IVOA should be strict in defining
a minimal list of possible separators/qualifiers. But I would firmly  
claim
that it is not necessary to rely on those,
beacuse in IVOA-speak the units will be known by the "unit" attribute,
not by parsing the coordinate value.

Roy's scheme has the small advantage that parsing a sexg rendered in  
HTML
(15<sup>d</sup> 48<sup>m</sup> 33<sup>s</sup>) is possible, though
HTML is not IVOA-speak.


> They provide information
> about the fields and also facilitate disambiguation with
> target names.

Regarding target names, I guess that in the VO world
the UCD will always tell us what the field is, and nobody
will use a sexg parser on a target name.
Hence 4C+48.61 is not a problem.

Help: I thought the ucd for the target name was under the obs. tree,
       but I cannot find it. What is it?
       In the old days was: ID_TARGET, but now? Was it removed?

>
> E.g.,
>
>  12h06m14d08m
>
> has only 4 integer fields and no whitespace, but it's still clear  
> which is the RA and Dec
> [...]
> Other heuristics that could be used....
>   If a number is signed and it is not the first field, it must be  
> the start
> of the second coordinate.

One way would be to enforce the sign for the second coordinate as a
recognised separator, but please...

>  A comma can be used to separate the lat/lon coordinates, but not  
> the fields within them.

... please please do not enforce the comma separator!
I really hate it, it is not necessary. Astronomers like to "paste"
the coordinates into a search field, without having to edit it to add  
the comma
or similar superfluous (I'd say even spurious) characters.

>  If the separator after something other than the first field is   
> 'd', 'deg', 'degree' or
> the non-ASCII degree character, this preceding field is the first  
> field in
> the second coordinate (especially if there is a cooresponding  
> separator
> after the first field)
>  If the total number of fields is >2 and < 6, and the first separator
> is a legal, non-space separator (e.g., ':') and the second separator
> is white-space, then the second coordinate begins in the
> third field.

Yap, but that is quite complex...

>  Might also consider values
>    13 24 81 47
> is not ambiguous

In general xx xx xx xx is ambiguous;
13 24 81 47 specifically is not ambiguous because 81 > 60:

Vizier interprets "13 24 81 47" as 13:24:00, 81:47:00
    but interprets "20 18 38 02" as 20:18:38, 02:00:00  !!!


A nice Sunday to everybody,

Alberto