SIA-2.0 constants (coord sys, reference positions, time scales, etc)

[Jose Enrique Ruiz]

Hi all

I think it could be worth thinking on the different communities using the
VO clients/protocols. In the same way we have S*AP for images and spectra
because clients in general do not perform broadcasted discovery queries of
both images and spectra at the same time, we could think if broadcasted
discovery queries for both planetary and galactic reference systems may
have a meaning. I would be inclined to a flavour of option 3, only after
considering at least a rough study of potential use cases. In my opinion a
golden-bullet image protocol which covers all generic multiD discovery is
neither simple nor usable /useful.

Cheers !


---
Jose Enrique Ruiz
Instituto Astrofisica Andalucía - CSIC
Glorieta de la Astronomía s/n
18009 Granada, Spain
Tel: +34 958 230 618


2014-07-10 22:42 GMT+02:00 Arnold Rots <arots at cfa.harvard.edu>:

> 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/20140711/eb1e299c/attachment-0001.html>