SIA-2.0 constants (coord sys, reference positions, time scales, etc)
Arnold Rots
arots at cfa.harvard.edu
Thu Jul 10 13:42:55 PDT 2014
If option 1 is selected, planetary systems are in principle supported,
since they are included in STC.
- Arnold
-------------------------------------------------------------------------------------------------------------
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 cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------
On Thu, Jul 10, 2014 at 2:35 PM, Patrick Dowler <
patrick.dowler at nrc-cnrc.gc.ca> wrote:
>
> As mentioned at the interp, I said I'd look into how planetary use cases
> could be supported in SIA-2.0 ... here are some thoughts.
>
>
> It has been standard practice to fix the coordinate system, reference
> positions, time scales, etc in simple DAL potocols in order to simplify the
> protocols for > 90% of the use (ICRS). The main side effect is that the
> protocol becomes immediately unusable when the metadata is not
> characterising position/energy/time in the universe and on the sky --
> planetary data, theoretical data, maybe solar system data -- where some
> other system of coordinates is required.
>
> I can see a few ways we could make the SIA-2.0 query spec more flexible so
> it could be used for these other classes of use cases.
>
> 1. Add optional parameter(s) where the caller can specify the coordinate
> system describing other parameter values. For example, POS_SYS=GAL would
> say that POS values are in GAL(actic). This opens up a mess of clients
> needing to find out what the service supports, digging through the registry
> for services they can use, possible need for registry extension, possible
> need for a vocabulary for that _SYS param, etc. And more ways for requests
> to fail.
>
> 2. A service specifies (registry record, VOSI-capabilities, DALI service
> descriptor) which system they work in and clients do the transformation
> work before calling each one. That definitely pushes the limits of calling
> this a Simple DAL service. It is at least as bad as #1 for clients and
> maybe worse because services could not shoulder some of the burden by
> supporting both ICRS and GAL without deploying multiple services.
>
> 3. Consider the base SIA-2.0 query with all it's constants (and
> standardID) as defining the normal "search for telescope data". Write a new
> spec for planetary use cases that at a minimum redefines the constants and
> specified a new standardID for registering services. The planetary spec
> could define additional parameters (if necessary), it could change any
> *must* to *should* (or vice versa), and it could alter the parameter units
> and output to conform to a different data model*... but mostly rely on the
> base SIA parameters.
>
> #3 is the same concept that was adopted for re-using SSA-1.1 for a simple
> time series service. Clients would simply search based on standardID for
> services they want to use and the effort to write that 3 page spec and
> define a new standardID would be sufficient to keep us to a small number
> (2-3?) well defined variants of the SIA query capability.
>
> It would be interesting to hear from the planetary people who know EpnTAP
> inside and out if this would work for them and how much would have to be
> redefined.
>
> my 2c,
>
> Pat
>
>
> * right now, WD-IA-2.0 specifies vanilla ObsCore-1.0 and there is work to
> define an image extension to add some output columns; a planetary SIA would
> want to use a model consistent with EpnTAP; if that is a variant of ObsCore
> with (again) different constants then this would probably work ok... if
> that is an entirely different model then the query params, defined in terms
> of ObsCore fields, may not fit so well.
>
> --
>
> Patrick Dowler
> Canadian Astronomy Data Centre
> National Research Council Canada
> 5071 West Saanich Road
> Victoria, BC V9E 2E7
>
> 250-363-0044 (office) 250-363-0045 (fax)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140710/0ff7d2c0/attachment.html>
More information about the dal
mailing list