Hi Tom -
On Mon, 24 Apr 2006, Thomas McGlynn wrote:
> ... 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.
Frankly, I think this scalar/vector ambiguity is complete nonsense. A coordinate is a single value; sexagesimal, if permitted, is a format type, even if the formatting includes spaces. Furthermore, in the spirit of the data model mediation techniques used elsewhere to hide the peculiarities of external data and improve rigour, we should require that values such as coordinates be expressed in a standard form. A suggested display formatting type, or possibly just a UCD-specific default display format, can provide all that is required in the user interface.
> 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.
This looks reasonable, except that the next full version will use UTYPE to identify fields like this, which avoids the need to say "one and only one field" (a UCD will also be defined of course). In general multiple fields may share the same UCD, but the interface will specify a unique UTYPE for each interface element.
> 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>
Right ascension should not be hyphenated; if we did so that was an error.
> 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
>>>
>>
>>
>
Received on 2006-04-24Z19:13:31