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).
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
>
Received on 2006-04-24Z17:26:25