ObsCore update discussion : adding Axes information in Obscore table

[Louys Mireille]

Dear Markus, Dear  DMers,

My comments below.
Any other points of views from the data providers' side?

Best wishes,
Mireille.

Le 16/04/2015 10:16, Markus Demleitner a écrit :
> Dear Data Modellers,
>
> I've not closely followed the discussion, so this may be a dumb
> question, but let me still ask it:  What use cases is this to cover?
>
> Is it, in essence, "Give me all lightcurves/spectra/spectral
> cubes/polarisation images satisfying these conditions"?  If so, then
> I have to say I feel
>
> On Wed, Apr 15, 2015 at 07:50:33PM +0200, Louys Mireille wrote:
>>   * 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
> is both a bit too much and a bit too little.
In the ObsTap protocol , you get the same column as query and as query 
response .
It is important for the user ( human or client application) to get a 
sense of richness from the discovered data set in terms of sampling 
cells on all axes.

if s_dim1> 200 and  s_dim2> 200 , I can derive that the discovered 
dataset is rather rich enough in spatial dimension, and still manageable 
for download.
if t_dim > 20,  I may be interested in this time serie aspect: enough 
time samples , or I may discard it : not enough time samples...
I admit there is some overlap , between pol_dim and pol_states , because 
you can derive pol_dim from counting the number of slashes

the suggestion to expose the nature of axes as an ordered list , as a 
simple concatenation of FITS  WCS Ctype is not completely satisfactory 
either:
long strings to parse , not really unique as a dataset can be packaged 
in one N-D table or in  a multi-extension FITS, and in this case , one 
"axis_type" string is not
appropriate.

The advantage here is to stick to existing axes classes: s, em , t , pol 
, and to provide a first guess on the size along these axes.

A richer description , that convey the number of arrays and the WCS 
ctype, and axes ranks settings can then be provided in a second step.

-- 
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