<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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
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 &lt;n&gt;_dim is 1, it means that this is a
    degenerate axis. <br>
    One cannot have a &lt;n&gt;_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 &lt;n&gt;_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 &amp; 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 class="moz-txt-link-freetext" href="http://astro.unistra.fr">http://astro.unistra.fr</a>                        <a class="moz-txt-link-freetext" href="http://www.telecom-physique.fr">http://www.telecom-physique.fr</a>
tel : 03 68 85 24 34</pre>
  </body>
</html>