release of a new version for the WD Observation Core Components data model and ObsTAP

[Anita M. S. Richards]

>
> On 2011-03-09 01:27:57 Anita M. S. Richards wrote:
>> p14 Table 1 and elsewhere
>>
>> What about Solar System or other data which cannot be described at all by
>> RA and Dec (because the body moves too fast, for example?) For example,
>> many ALMA observation sets will contain a moon as amplitude calibrator
>> along with extragalactic sources.  It would be nice to have an option e.g.
>> 'coosys other' if not all the options.  Alternatively, one could allow RA
>> and Dec to be nil and identify Solar System objects by name and time-date.
>
> The s_region column allows ANY STC region; the service has to be able to
> accept ADQL queries that use that column. It is always the caes that services
> are responsible for converting spatial queries to the system they use.
>
> s_ra and s_dec are allowed to be NULL in the database, even if s_region is not
> null.

Thanks, that solves the problem. I think.

>
>
>> p15 3.3.1 Data Product Type
>> Is it worth stating explicitly that visibility data is likely to be in
>> formats such as FITS, Measurement Sets (MS) or Science Data Models (SDM,
>> ASDM etc.) (usually distributed as tar or zip directories) - just so that
>> implementors can recognise the type of the latter, relatively new formats?
>
> The access_format will say if it is FITS (application/fits is a valid value of
> that column).

It is not FITS I am worried about, it is the newer formats - but as it 
list is extensible it is not a big issue.

Thanks again

Anita