WD-AccessData-1.0-20140312

[Patrick Dowler]

WD-AccessData-1.0 will support a single set of fixed units:

* POS is ICRS degrees
* BAND is barycentric wavelength in meters
* TIME is UTC but allows MJD or timestamp strings

This is the minimal simplest thing that meets the CSP use cases and can 
pretty easily cover common (90% or more of) use cases. This is the same 
restriction as in the WD-SIA-2.0 {query} capability.

So it is true that services will have to know how to convert to internal 
units. The goal is to add feature to AccessData in the form or a 1.1, 
1.2, etc revisions in the near future.

Once the ImageDM is done and SIA-2.0 {metadata} interface is usable, the 
client will be able to discover the detailed metadata, including the 
"native" units and reference systems. At that point, we will figure out 
how to allow the client to work in "native" as that would be the next 
thing to add that is only extra work for clients. Working in arbitrary 
3rd set of units or systems is probably never going to be worth the 
effort, even though some common cases are not too hard (for example, we 
have services that can support requests in FK4/B1950, FK5/J2000, ICRS, 
and GAL systems... but it it that useful to arbitrarily support all 
that? I think standard and native get you from 90% to 99.9% of use cases.

Anyway, the exec and CSP have made it clear that we have to be "done" 
with the initial revisions of the relevant specs (SIA-2.0, DataLink-1.0, 
AccessData-1.0 from DAL) before the May interop, so if something is not 
in a document now it is more or less out of scope by necessity. We just 
have to make sure we define what is there as well as we can -- and there 
is plenty to discuss without adding more.


Pat

On 13/03/14 01:16 PM, Petr Skoda wrote:
>>
>>> but letters and devise the way how to request multiple ranges => BAND=B,V,R
>>
>> Some folks don't like list-valued parameters (likewise POL=I,Q,U), but
>> it does seem more natural and convenient for the client doesn't it?
>
> At least for scientist who should be tought to use the VO stuff it is the
> most natural way - of course something like [U,B,V] or other formalism
> might be accepted.
>
>
>
>>> meters explicitly) - but how the user will know the units of original data?
>>
>> By a prior queryData and/or getMetadata.  In particular, for most
>> advanced image access via accessData, one will need to know the image
>> geometry and WCS, which will be returned with getMetadata (which is not
>> yet fully defined, and requires more work on the Image data model).
>
> well this returns to philosophy about rectangular circle for SIAP query or
> cutout ....
> But I had in mind the BAND units - suppose several X-ray channels (similar
> to photometric band like U,B,V) - will I extract 50/100 What ? KeV,
> Angstroms ? Hz ?  (for nu - frequency)
>
> Is this to be said by queryData ? Well it may say the units=Anstrom but
> how to define range for special channel (again the analogy with filter -
> it may even have leakage and some opaque ranges (whis is explicitly
> rejected in this version of proposal by Pat)
>
> I would prefer to recive from query to IRAS - we have 10, 25 mu zones or
> from X-ray we have bands .....hard,soft
> which one would you like to get  ?
>
> The client can easily build the interactive menu for choosing such
> selection options.
> It is still resembling rather the Carlos's S3 protocol.
>
>
>>
>> Several people have expressed interest in image sections as in IRAF,
>> CFITSIO, etc.  This is a pixel space expression such as "[101:105,*]"
>> (spatial cutout of a 3-cube), "[*,5,*]" (plane 5 of a cube), etc.  In
>> general, WCS-space and pixel-space operations are equally important and
>> the client might prefer either.  AccessData is WCS-space initially as we
>> already have to support this for the discovery query, whereas supporting
>> pixel-space
>
> I see the only application of pixel space for mosaics. Otherwise it might
> be used for reducing size of images to conserve space - like thumbnails of
> individual galaxies from SDSS ....
> But it will be always very rough experimental size to select (well if I
> have CDELT1 I can compute pixel scale - but IMHO all reasonable science
> request will be driven in WCS space - in physical units ....
>
> But I do not want to restart the discussion again....
>
>
> thanks for support of BAND names
>
> .
>

-- 

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)