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.

PatrickDowler 09 Mar 2011

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 case 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.

The s_ra is and s_dec columns are there as a convenience only; they are not actually required for any of the use cases and, if the s_region was in ICRS the values could be trivially obtained in ADQL with coord1(centroid(s_region)) and coord2(centroid(s_region)), although one might also want to select coordsys(s_region) as well, or - even better - coordsys(centroid(region)) just in case other transformations are going on and they really want to be careful.

AnitaRichards 09/03/2011

Thanks, that solves the problem. I think.

DougTody 10 Mar 2011

A target name query should still work in this case.

-- JuanDeDiosSantanderVela

PatrickDowler said:

It is always the case that services are responsible for converting spatial queries to the system they use.

Thanks for the reminder, Patrick. I think this should be stressed more in ObsTAP and in the corresponding DAL protocols. But at least use case of solar system body observations could be nice.