One does not exclude the other.
However, let me warn you that your model may not be realistic:
a box in Equatorial does not transform into a box in Galactic.
Thus several services my offer both coordinate systems.
Yuji SHIRASAKI wrote:
> Dear Arnold,
>
> > Yuji,
> >
> > Inserting the coordinate frame is no more verbose than inserting a
> > table alias when there is only one table.
> >
> > My proposal has been to use STC-S in the ADQL-S queries. That has the
> > advantage that it is a fully defined system, consistent, extensible,
> > and compliant with other IVOA functions, and that it is convertible to
> > the STC-X XML serialization.
> > Within that context the default value for a missing element is always
> > UNKNOWN. Proper frame identification avoids confusion - which will
> > happen if you don't require it. The user will almost always assume
> > that it is his/her favorite frame.
>
> My modivation to allow the frame-less region query is arised from
> the consideration that frame conversion should be done at the client
> application. It is difficult to assume all the data service does
> the same quality of translation. The number of data services is
> expected to be larger than the number of client. I think it is enough
> to enfornce data service to provide the medata of default search
> frame, so that client application can do the proper frame-conversion.
>
> > I'd be happy to include simulations in STC-S since they are in STC-X.
> > That will allow more sensible querying of those datasets: only being
> > able to ask for a circle in (X,Y) seems rather restrictive.
> >
> > And again, how many users do you expect to actually craft ADQL
> > queries? I would imagine that most queries would be constructed by a
> > more user-friendly user interface.
>
> I imagine almost all user will use a client application or a portal
> service (I cannot assume whether it is user friendly or not), so doing
> the frame conversion on the client side seems to be reasonable to me.
>
> > On two other issues:
> > Units are included in the STC-S definition and actually have defaults,
> > but should be the same for all related numbers in a query.
> >
> > For time ISO8601, JD, or MJD are allowed. I would strongly suggest
> > for the ISO case to adopt the same restrictions that are in FITS and
> > in STC: yyyy-mm-ddThh:mm:ss.s..., optionally dropping the 'T' in SQL
> > conversion; no support for time zones or the 'Z' indicator, but
> > instead a timescale specification where needed.
>
> With the same reason, I think that the translation from ISO8601 to
> SQL-standard expression should be done on the client side.
>
> Also about unit, I think it should be translated on the client side.
>
> I don't like to rely all the translation on the data service.
>
> Yuji Shirasaki.
>
> --
> Yuji SHIRASAKI <yuji.shirasaki-at-nao.ac.jp>
>
>
Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots-at-head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ --------------------------------------------------------------------------Received on 2006-05-15Z17:55:51