<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 12/05/2015 18:29, Patrick Dowler a
écrit :<br>
</div>
<blockquote cite="mid:55522A59.2040508@nrc-cnrc.gc.ca" type="cite">
<br>
Is the addition of a doppler/redshift axis to ObsCore something we
are talking about for ObsCore-1.1 or later?
<br>
<br>
</blockquote>
Dear all , <br>
<br>
This is a good question . <br>
I think there is some misunderstanding for the scope of the various
data model versions.<br>
<br>
After many discussions in the last few months , trying to figure out
practical examples of data sets described in Obscore <br>
and accessed via ObsTAP, we realized there are various use-cases
where the WCS information is tricky to expose in the simple tabular
format of <br>
an ivoa.Obscore table.<br>
<br>
The suggestion I had in Banff to add a redshift axis is not
satisfactory for <br>
the simple discovery step that ObsTAP supports , as it adds 9 or 10
keywords <br>
that will be null for more than 80% of the datasets served. <br>
Numbers to be checked, but at least a large fraction of observations
are not velocity data.<br>
<br>
The problem with redshift axis is to find the appropriate level of
description <br>
and consider which information is enough just to discover a velocity
cube , for instance. <br>
<br>
For the next update of ObsCore , that is 1.1 , we will have only the
possibility to discover if a dataset has velocity content, <br>
by using the "em_ucd" field.<br>
<br>
For the future updates of Obscore, a full description, with related
reference frequency, position , etc , can be defined and prototyped.<br>
However the Image DM already contains the full description of the
Redshift axis, so specific data collections with velocity
measurements <br>
can be delivered in an SIAV2 getmetadata() capability, based on
ImageDM.<br>
<br>
Finally after much hesitation and steps forwards and backwards, I
suggest to have a minimal description of the redshift content in one
keyword<br>
for Obscore 1.1.<br>
Then for a general search, the selection criteria <b>*for
discovery*</b> stay compatible to the original ObsCore strategy :
<br>
em bounds in meter , ICRS for positions , etc ..<br>
<br>
For data retrieval, the d_ features exposed previously can be used
in extra tables, or the ImageDM serialisation.<br>
<br>
This keeps ObsTAP focused on discovery , and allows richer
description from ImageDM to be used via SIAv2. <br>
<br>
I hope this helps, <br>
Mireille<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<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 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>