WD-AccessData-1.0-20140312

[Francois Ochsenbein]

Well if a number has to be attached to the BAND, I would personnally recommend
to use its frequency rather than its wavelength -- the ambiguities which exist
about vacuum or air wavelengths do not exist in the frequency space.

François Ochsenbein

Le 13/03/2014 23:01, Patrick Dowler a écrit :
>
> 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
>>
>> .
>>
>

-- 
======================================================================
Francois Ochsenbein   ---   Observatoire Astronomique de Strasbourg
11, rue de l'Universite 67000 STRASBOURG        +33-(0)368 85 24 29
Email: Francois.ochsenbein at astro.unistra.fr
======================================================================