<div dir="ltr"><div><div><div>I know I sound like a broken record, but this is the kind of use case that requires<br></div>the redshift/Doppler axis.<br></div>Note that FITS also distinguishes this through the use of VELO/FELO from a proper spectral axis.<br><br></div>  - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots                                          Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory                   tel:  +1 617 496 7701<br>60 Garden Street, MS 67                                      fax:  +1 617 495 7356<br>Cambridge, MA 02138                                         <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA                                                   <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 23, 2015 at 3:51 AM, Marco Molinaro <span dir="ltr">&lt;<a href="mailto:molinaro@oats.inaf.it" target="_blank">molinaro@oats.inaf.it</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Dear all,</div><div>regarding this topic I have a small use case that comes from a (currently custom) set of services whose aim is to allow velocity spectra analysis of galactic FITS cubes.</div><div>The full service (the combination of the set of services) itself can fit into a &quot;TAP/ObsCore-Datalink and/or SIAv2-AccessData&quot; scenario.</div><div><br></div><div>The use case can be described as:</div><div>a - a super-set of FITS cubes from non-homogeneous galactic surveys and pointed archives in the radio band is deployed to allow velocity spectra analysis</div><div>b - the first step for the user is to search in this set for available data along a line-of-sight, with possible filtering on a cone around it, or a box around it, limiting the velocity range, selecting explicitly one/more survey(s) by name, species, transition, ...</div><div>c - the search output (which includes something along the lines of a PublisherDID) is then used to explicitly cut the needed cube(s) to make data transfer affordable (in the near future merging of adjacent &quot;same-survey&quot; cubes will be also implemented)</div><div><br></div><div>The need for WCS information in the output of the search comes from the idea of allowing the client side to build correct cutout queries to the system in terms of spatial boundaries but also for the available velocity ranges and units available for each stored dataset.</div><div>That is, given the surveys are heterogeneous, a broad filtering will return datasets with different boundaries and the client should be able to understand the limits in coverage before asking for the actual data.</div><div>As a last, but not less important feature, the fits cutout can be performed using both positional and velocity constraints, together or independently.</div><div><br></div><div>I take the chance of this mail thread to give here also my 2 cents on the regexp approach Markus described in the DM-listed starting post on this topic (<a href="http://mail.ivoa.net/pipermail/dm/2015-April/005150.html" target="_blank">http://mail.ivoa.net/pipermail/dm/2015-April/005150.html</a>).</div><div>I tend to agree with Laurent&#39;s reply content.</div><div>I agree adding fields to a table is something we should care about, but packaging information is not usually my preferred solution.</div><div>Anyway, it could work in discovery, but it&#39;s not enough for the results output I need in my above use case.</div><div><br></div><div>Cheers,</div><div>    Marco</div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-04-16 9:09 GMT+02:00 François Bonnarel <span dir="ltr">&lt;<a href="mailto:francois.bonnarel@astro.unistra.fr" target="_blank">francois.bonnarel@astro.unistra.fr</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div 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&#39;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 type="cite">
      
      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" target="_blank">http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf</a>
      ) <br>
      we iterated with Doug Tody to enhance the axes&#39; 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><span><font color="#888888">
      <br>
      <pre 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&#39;Université                        CS 10413
67000 Strasbourg                                 F - 67412 ILLKIRCH Cedex
<a href="http://astro.unistra.fr" target="_blank">http://astro.unistra.fr</a>                        <a href="http://www.telecom-physique.fr" target="_blank">http://www.telecom-physique.fr</a>
tel : 03 68 85 24 34</pre>
    </font></span></blockquote>
    <br>
  </div>

</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>