<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear all,<br>
<br>
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.
<br>
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).
<br>
<br>
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.
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Regards
<br>
François Bonnarel after discussion with Marco and Mireille<br>
Le 15/04/2015 19:50, Louys Mireille a écrit :
<blockquote cite="mid:552EA4E9.1040305@unistra.fr" type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Dear all , <br>
Here is a summary of discussions on the Obscore data model update,
with several iterations <br>
with Doug Tody, François Bonnarel, Laurent Michel, Daniel Durand
and Pat Dowler.<br>
After the suggestion I made at the last interop in Banff, <br>
(see <a moz-do-not-send="true"
href="http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf">http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf</a>
) <br>
we iterated with Doug Tody to enhance the axes' description of
the data part exposed in a dataproduct distributed by Obscore.<br>
<br>
These add_ons are meant to enrich the query response of ObsTAP
serving N-D datasets in order to expose the <br>
dimensions and the nature of axes involved in the data part.<br>
<br>
The way the data values are organized in files ( File format,
single or multiple extensions in FITS, etc, ..) is not taken into
account here, <br>
as the goal is discovery and selection of candidate datasets
from the query response.<br>
<br>
These values are not meant to be exact but represent a very good
approximation of the dimension in each physical axis.<br>
So we are proposing the addition of <br>
<ul>
<li>s_dim1, s_dim2 = the coverage in sampling elements ( pixels)
for each spatial axis</li>
<li>em_dim = the coverage in spectral elements along the energy
axis</li>
<li>t_dim = the coverage in the time axis, as number of time
bins<br>
</li>
<li>pol_dim = the coverage in the polarization axis, as number
of polarization states <br>
</li>
</ul>
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.<br>
<br>
These parameters are not describing the packaging (this is not
providing enough information for cutout yet. <br>
If the value of the <n>_dim is 1, it means that this is a
degenerate axis. <br>
One cannot have a <n>_dim =0 but NULL is allowed
(interpreted as 1). <br>
<br>
Please note that the default polarization for any imaging data is
I, intensity.<br>
<br>
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 <br>
(it might be true for simple cases, i.e. simple image but
certainly not for mosaic observation where the gap<br>
and/or the presence/absence of a given chip is not specified) .<br>
<br>
Here are some examples of various datasets exposed with this
strategy : <br>
<ul>
<li>MUSE data cube</li>
</ul>
<pre> s_dim1 = 300
s_dim2 = 300
em_dim = 3463
pol_dim = 1
pol_state = I
t_dim = 1
</pre>
<ul>
<li>2MASS: 2D image<br>
</li>
</ul>
<pre> s_dim1 = 300
s_dim2 = 300
em_dim = 1
pol_dim = 1
pol_state = I
t_dim = 1
</pre>
<ul>
<li>MEGACAM: mosaic image<br>
</li>
</ul>
<pre> s_dim1 = 20000
s_dim2 = 20000
em_dim = 1
pol_dim = 1
pol_state = I
t_dim = 1
</pre>
<ul>
<li>STIS spectroscopy (1D):<br>
</li>
</ul>
<pre> s_dim1 = 1
s_dim2 = 1
em_dim = 1024
pol_dim = 1
pol_state = I
t_dim = 1
</pre>
<ul>
<li>STIS spectroscopy (2D long slit):</li>
</ul>
<pre> s_dim1 = 1024
s_dim2 = 1
em_dim = 1024
pol_dim = 1
pol_state = I
t_dim = 1
</pre>
<ul>
<li>ALMA:<br>
</li>
</ul>
<pre> s_dim1 = 1000
s_dim2 = 1000
em_dim = 3000
pol_dim = 4
pol_state = I/U/V/Q
t_dim = 1
</pre>
The more detailed mapping of s, em , etc on NAXIS1, NAXIS2, etc.
in terms of WCS values could be handled in <br>
a future <b><i>getmetadata </i></b>capability of SIAv2, either
via ADQL / Obstap or with a query by parameter, awaiting a <br>
more complete WCS solution for all astronomical observation.<br>
A discussion on WCS implementation for instance at the IVOA
interop meeting in Sesto in June will help to go forward.<br>
<br>
There are suggestions to use an optional UCD tag to specify the
flavour of these axes , like <b><i>em_ucd</i></b>, for instance ,
already in ObsCoreDM <br>
to help to disentangle between frequency , wave and energy in the
query response.<br>
<br>
A draft is currently updated along these lines. <br>
<br>
Your comments , and suggestions welcome . <br>
Mireille <br>
<br>
<pre class="moz-signature" cols="72">--
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
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://astro.unistra.fr">http://astro.unistra.fr</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.telecom-physique.fr">http://www.telecom-physique.fr</a>
tel : 03 68 85 24 34</pre>
</blockquote>
<br>
</body>
</html>