Hi Doug,
I certainly thought that is what we intended but I don't think that's what the document says.
The SIA document is quite clear that all inputs are in decimal degrees. However it doesn't say a thing about outputs. All it does is to specify that the type of the column with the POS_EQ_RA/DEC_MAIN UCDs shall be of type double. I believed this meant that the type was a scalar, but the discussion that have come up on sexagesimal coordinates and in particular the USNO Cone search services, indicates that others don't in practice agree even with that.
I don't think there is any support in the standard for the statement that the units of the coordinate centers are degrees. Only the units of the Image_Scales are specified (of the required fields).
The language for the coordinate columns in the Cone search is almost the same as for the SIA.
Cone search spec:
Exactly one FIELD must have ucd="POS_EQ_RA_MAIN", with type double,
representing the J2000 right-ascension of the source.
SIA Spec:
Exactly one field MUST have ucd="POS_EQ_RA_MAIN", with datatype="double",
representing the ICRS right-ascension of the center of the image.
I would suggest that in both standards we need language more like:
The table must contain one and only one field with the UCD "POS_EQ_RA_MAIN". This field must be a scalar, with no arraysize specified, and with datatype="double" and unit="degrees". The value of this field shall be the ICRS right ascension of the center of the image expressed in decimal degrees.
Tom
P.S., <Nit>Is 'right ascension' hyphenated? I didn't think so but it is a number of times in the SIA document even when used as a noun. Or were there so many uses an an adjective that the hyphen became engrained in one's fingers.</Nit>
Doug Tody wrote:
> Hi All -
>
> Our intention with SIA was to restrict coordinates to decimal degrees -
> this is specified in a number of places, although perhaps not clearly
> enough.
>
> If there is an explicit data model, as for SIA/SSA etc., then the
> data model should specify the allowable units and representations.
> This should agree with but supercede whatever the container (VOTable,
> FITS, etc.) defines.
>
> Cone search is a slightly different case as there is no catalog data
> model, and data tends to carry over directly from whatever catalog
> is being queried. Nonetheless it would be desirable for cone search
> to require that coordinates be converted to some well defined units
> and representation within the VOTable. Of course, astronomers may
> still want to see sexagesimal notation for display, but that can be
> done by allowing the service to define a suggested format for display
> To support this might require a small addition to the VOTable spec.
> (Anita - I would claim this satisfies the requirement you mentioned).
>
> - Doug
>
>
>
> On Fri, 21 Apr 2006, Thomas McGlynn wrote:
>
>> Mark Taylor wrote: >> >>> On Thu, 20 Apr 2006, Thomas McGlynn wrote: >>> >>> >>>> At it's clear that the USNO table is incorrect in the new version >>>> (since it specifies that the column is a double). >>> >>> >>> >>> I've just retrieved a table from the USNO-B conesearch using the URL: >>> http://www.nofs.navy.mil/cgi-bin/vo_cone.cgi?CAT=USNO-B1&RA=50.1&DEC=-37.5&SR=0.16 >>> >>> It has RA and DEC FIELD components with the attributes >>> >>> datatype="double" arraysize="3x1" >>> >>> which, while you might argue it's eccentric, is not incorrect, this is >>> exactly how you specify an array-valued column according to both >>> versions 1.0 and 1.1 of the standard. >>> >> >> Well I guess my reading of the Cone Search spec was that the type was >> a double, but I suppose that doesn't explicitly preclude it being an >> array -- though I think it should be forbidden and that that was >> the original intent. >> >> The SIA protocol also doesn't explicitly forbid arrays but given this >> discussion I think it should. >> >> The language is squishy here.... >> "Exactly one field MUST have ucd="POS_EQ_RA_MAIN", with >> datatype="double", representing the ICRS right-ascension of the center >> of the image." >> >> So by a liberal interpration if I had a position with RA=123.456, any >> of the following >> are valid responses (in addition to the sexagesimal issues). >> >> 123.456 (Yea!) >> 1 2 3. 4 5 6 >> 6 5 4. 3 2 1 (no reason to make it easy for the reader!). >> 1 2 3 -1 4 5 6 >> 100 23 0.45 .006 .000 1 -1 (and any other numbers that sum to 0) >> >> They all "represent" the ICRS coordinate in the sense that I can >> easily define the >> mapping between these values and the coordinate, but if the standard >> is to be useful >> it must be more restrictive and it had never crossed my mind that >> providing coordinates >> in something other than a scalar giving decimal degrees was legal... >> >> Sigh... There are more things in VOTable and SIAP then are dreamt of >> in my philosophy. >> >> Tom >>