Multi-dimensional Data Access minimal requirements
Peter Teuben
teuben at astro.umd.edu
Fri Mar 7 07:42:10 PST 2014
This does make sense if your spectral axis contains one line, but raw cubes
from MUSE, or ALMA for that matter, often contain thousands of channels
with many spectral lines.... it's good to have the doppler shift of the
intended object in a header, but where is the decision which line to use as
reference line?
Peter
On 03/07/2014 10:27 AM, Arnold Rots wrote:
> While appreciative of these requirements that are generally reasonable,
> I have to register my strong objection to its leaving out the Doppler
> velocity
> (Redshift) axis. I have said this over and over, and will keep
> repeating it:
> if we don't properly distinguish between the redshift and the spectral
> axes,
> queries and results will get confused and users annoyed.
> Redshift or Doppler velocity constraints need to be added to Data
> Discovery
> and to Simple Cutout.
>
> Cheers,
>
> - 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 <mailto:arots at cfa.harvard.edu>
> USA
> http://hea-www.harvard.edu/~arots/ <http://hea-www.harvard.edu/%7Earots/>
> --------------------------------------------------------------------------------------------------------------
>
>
>
> On Thu, Mar 6, 2014 at 7:14 PM, Gaudet, Severin
> <Severin.Gaudet at nrc-cnrc.gc.ca <mailto:Severin.Gaudet at nrc-cnrc.gc.ca>>
> wrote:
>
> Hi all
>
> During the Exec meeting two weeks ago, the topic of
> multi-dimensional data access was discussed. The two main points
> from that discussion were:
>
> * The Exec endorsed the CSP's recommendation for the minimum
> requirements (see below) for the first version of the
> necessary standards as defined by the CSP.
> * The Exec expressed their strong desire to see "RFC-ready"
> working drafts ready by the May InterOp.
>
>
> Practically speaking, the endorsement of the minimum requirements
> for the first version of the multi-dimensional data access
> standards means:
>
> * The preparation of the standards cannot be held up by
> discussion of "features" that are not necessary to meet the
> minimum standards
> * The WGs should be thinking in an agile sense where subsequent
> versions of a given standard with more "features" come rapidly
> after the first version.
>
>
> Here is my view of what standards need to be RFC-ready by the May
> InterOp:
>
> 1. SIAv2 (query capability only)
> 2. DataLink
> 3. AccessData (for simple cutouts only)
>
>
> By implication, ImageDM, the "get additional metadata" capability
> in SIAv2 and other AccessData functions are not required to meet
> the minimum requirements.
>
> Just to be clear, this does not imply that work on
> ObsCore/ImageDm/Observation data models or on complex AccessData
> services is not required. To the contrary, after the initial
> versions of the standards (SIA, DataLink, AccessData) are adopted,
> those will be the next things required to meet the use cases that
> will be discussed in Madrid. The request is to see
> RFC-ready standards (SIA, DataLink, AccessData) being presented
> and discussed in May. Although SIAv2.0 will only be dependent on
> the ObsCore, SIAv2.1 will certainly be dependent on "get
> additional metadata" and thus on ImageDM and possibly
> AccessDatav1.1, ObsCorev1.1 or v2.0.
>
> Cheers
> Séverin
>
> --------------------------------------------------
>
> Multi-dimensional Data Access minimal requirements:
>
> * Data Discovery (Query)
> o A service shall be able to receive queries regarding its
> data collection(s) from a client, with the client placing
> one or more of the following constraints:
> + RA,Dec
> + Frequency/wavelength
> + Polarization states
> + Spatial size
> + Angular resolution
> + Integration time
> + Time of observation
> o A service shall return to the client a list of
> observations, and the corresponding metadata for each
> observation, meeting the user-imposed constraints. In the
> event that the user places no constraints, the entire list
> of observations, and the corresponding metadata for each
> data set, shall be returned. In the event that no data
> meet the user's constraints, the service shall indicate
> the absence of any matches.
> * Data Access
> o Once a user has the list of observations that satisfy the
> constraints, they select all or a subset of the
> observations and:
> + Download the complete science data for each of the
> selected observations (the service shall return the
> complete multi-dimensional science data and metadata
> for each selected observation) or;
> + Download simple cutouts of the science data for each
> of the selected observations (the service shall be
> able to extract and return a user-specified subset of
> the complete multi-dimensional science data and
> metadata for each selected observation).
> * Simple Cutout
> o For a simple cutout, the user-specified subset is
> restricted to be a contiguous interval within each
> dimension of the multi-dimensional science data. The user
> should *not* be allowed to specify subsets with "gaps" or
> resampling or anything like that.
> + Spatial: a circle (a coordinate and a radius)
> + Energy: one interval (from energy1 to energy2)
> + Time: one interval (from time1 to time2)
> + Polarization: a list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20140307/aa06ba38/attachment-0001.html>
More information about the dal
mailing list