Beside (Re: ObsCore update discussion : adding Axes information in Obscore table) ---> WCS in nDAL

[François Bonnarel]

Dear all,

Beside the discussion on OBscore upgrade for datatype specific 
description of cubes or whatever (see belox Mireille's email), a lot of 
arguments were developped about the question of access to WCS 
information with DAL protocol.
     In general WCS information is not usefull for data discovery but 
nonetheless there is a lot of use cases requiring WCS knowledge in 
advance to data retrieval or access (among others: preparation of pixel 
cutouts or conveing WCS information with png images).

     The original DAL idea is that SIA2 Getmetadata method will provide 
a full serialisation of  ImageDm when this will be available. The WCS 
(or Transfom) classes in ImageDM will be based on STC2.0 and encompass 
all the possible complex situations.
     However, I am aware of several  experiments under study in 
differents groups   which could provide quick  solutions for DAL WCS 
access in most of the simpler cases including simple and multiple array 
calibrated with linear solutions.

      It would be a good idea to start a  discussion on this topic  
based on description  of  various proposals and prototypes. It would be 
also usefull to better specify the GetMetadata concept in this 
perspective and to highlight the relationships of these proposals with 
the ImageDM effort in order to clarify  the strategy and DAL roadmap.

      A dedicated DAL session on this topics could be held in Sesto. 
According to what DM chairs think it could be alos co-organized as a 
DAL/DM joint session.

Regards
François Bonnarel after discussion with Marco and Mireille
Le 15/04/2015 19:50, Louys Mireille a écrit :
> Dear all ,
> Here is a summary of discussions on the Obscore data model update, 
> with several iterations
> with Doug Tody, François Bonnarel, Laurent Michel, Daniel Durand and 
> Pat Dowler.
> After the suggestion I made at the last interop in Banff,
> (see 
> http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf 
> )
> we iterated with Doug Tody to enhance the axes' description of  the 
> data part exposed in a dataproduct distributed by Obscore.
>
> These add_ons are meant to enrich the query response of ObsTAP 
> serving  N-D datasets in order to expose the
> dimensions and the nature of axes involved in the data part.
>
> The way the data values are organized in files ( File format, single 
> or multiple extensions in FITS, etc, ..) is not taken into account here,
> as the goal is discovery  and selection of  candidate datasets from 
> the query response.
>
> These values are not meant to be exact but represent a very good 
> approximation of the dimension in each physical axis.
> So we are proposing the addition of
>
>   * s_dim1, s_dim2 = the coverage in sampling elements ( pixels) for
>     each spatial axis
>   * em_dim = the coverage in spectral elements along the energy axis
>   * t_dim = the coverage in the time axis, as number of time bins
>   * pol_dim = the coverage in the polarization axis, as number of
>     polarization states
>
> The nature of each axis is given by their prefix (s (spatial), em 
> (energy), t (time) and pol (polarization) s mentionned in the Obscore 
> previous version.
>
> These parameters are not describing the packaging (this is not 
> providing enough information for cutout yet.
> If the value of the <n>_dim is 1, it means that this is a degenerate 
> axis.
> One cannot have a <n>_dim =0 but NULL is allowed (interpreted as 1).
>
> Please note that the default polarization for any imaging data is I, 
> intensity.
>
> It is important to note that the <n>_dim values are the overall 
> characteristic of the dataset and NOT the value of its WCS axis
> (it might be true for simple cases, i.e. simple image but certainly 
> not for mosaic observation where the gap
>  and/or the presence/absence of a given chip is not specified) .
>
> Here are some examples of various datasets exposed with this strategy :
>
>   * MUSE data cube
>
>      s_dim1   = 300
>      s_dim2   = 300
>      em_dim   = 3463
>      pol_dim      = 1
>      pol_state = I
>      t_dim      = 1
>
>   * 2MASS: 2D image
>
>      s_dim1   = 300
>      s_dim2   = 300
>      em_dim   = 1
>      pol_dim  = 1
>      pol_state = I
>      t_dim = 1
>
>
>   * MEGACAM: mosaic image
>
>      s_dim1   = 20000
>      s_dim2   = 20000
>      em_dim   = 1
>      pol_dim  = 1
>      pol_state = I
>      t_dim = 1
>
>
>   * STIS spectroscopy (1D):
>
>      s_dim1   = 1
>      s_dim2   = 1
>      em_dim   = 1024
>      pol_dim  = 1
>      pol_state = I
>      t_dim = 1
>
>
>   * STIS spectroscopy (2D long slit):
>
>      s_dim1    = 1024
>      s_dim2    = 1
>      em_dim    = 1024
>      pol_dim   = 1
>      pol_state = I
>      t_dim = 1
>
>
>   * ALMA:
>
>      s_dim1    = 1000
>      s_dim2    = 1000
>      em_dim   = 3000
>      pol_dim  = 4
>      pol_state = I/U/V/Q
>      t_dim = 1
> The more detailed mapping of s, em , etc on NAXIS1, NAXIS2, etc. in 
> terms of WCS values could be handled in
> a future */getmetadata /*capability of SIAv2, either via ADQL / Obstap 
> or with a query by parameter, awaiting a
> more complete WCS solution for all astronomical observation.
> A discussion on WCS implementation for instance  at the IVOA interop 
> meeting in Sesto in June will help to go forward.
>
> There are suggestions to use an optional UCD tag to specify the 
> flavour of these axes , like */em_ucd/*, for instance , already in 
> ObsCoreDM
> to help to disentangle between frequency , wave and energy in the 
> query response.
>
> A draft is currently updated along these lines.
>
> Your comments , and suggestions welcome .
> Mireille
>
> -- 
> Mireille Louys	, Maître de conférences
> Centre de Données ( CDS)		Icube&  Télécom Physique Strasbourg, Pôle API
> Observatoire de Strasbourg 		300, boulevard Sébastien Brant
> 11, Rue de l'Université			CS 10413
> 67000 Strasbourg 				F - 67412 ILLKIRCH Cedex
> http://astro.unistra.fr			http://www.telecom-physique.fr
> tel : 03 68 85 24 34

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150416/4ee9e4e6/attachment.html>