ObsCore update discussion : adding Axes information in Obscore table
Arnold Rots
arots at cfa.harvard.edu
Thu Apr 16 15:50:30 CEST 2015
... not to mention the redshift/Doppler axis.
-------------------------------------------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496
7701
60 Garden Street, MS 67 fax: +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------
On Thu, Apr 16, 2015 at 3:39 AM, François Bonnarel <
francois.bonnarel at astro.unistra.fr> wrote:
> Dear all,
> my 2 cents below
>
> Le 15/04/2015 19:50, Louys Mireille a écrit :
>
> Dear all ,
> Here is a summary of discussions on the Obscore data model update, with
> several iterations
> with Doug Tody, François Bonnarel, Laurent Michel, Daniel Durand and Pat
> Dowler.
> After the suggestion I made at the last interop in Banff,
> (see
> http://wiki.ivoa.net/internal/IVOA/InterOpOct2014DM/obcore-ObsdatasetDM_compatibility.pdf
> )
> we iterated with Doug Tody to enhance the axes' description of the data
> part exposed in a dataproduct distributed by Obscore.
>
> These add_ons are meant to enrich the query response of ObsTAP serving
> N-D datasets in order to expose the
> dimensions and the nature of axes involved in the data part.
>
> The way the data values are organized in files ( File format, single or
> multiple extensions in FITS, etc, ..) is not taken into account here,
> as the goal is discovery and selection of candidate datasets from the
> query response.
>
> These values are not meant to be exact but represent a very good
> approximation of the dimension in each physical axis.
> So we are proposing the addition of
>
> - 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
>
> 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.
>
> These parameters are not describing the packaging (this is not providing
> enough information for cutout yet.
> If the value of the <n>_dim is 1, it means that this is a degenerate axis.
> One cannot have a <n>_dim =0 but NULL is allowed (interpreted as 1).
>
> Please note that the default polarization for any imaging data is I,
> intensity.
>
> 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
> (it might be true for simple cases, i.e. simple image but certainly not
> for mosaic observation where the gap
> and/or the presence/absence of a given chip is not specified) .
>
> Here are some examples of various datasets exposed with this strategy :
>
> - MUSE data cube
>
> s_dim1 = 300
> s_dim2 = 300
> em_dim = 3463
> pol_dim = 1
> pol_state = I
> t_dim = 1
>
>
> - 2MASS: 2D image
>
> s_dim1 = 300
> s_dim2 = 300
> em_dim = 1
> pol_dim = 1
> pol_state = I
> t_dim = 1
>
>
>
> - MEGACAM: mosaic image
>
> s_dim1 = 20000
> s_dim2 = 20000
> em_dim = 1
> pol_dim = 1
> pol_state = I
> t_dim = 1
>
>
>
> - STIS spectroscopy (1D):
>
> s_dim1 = 1
> s_dim2 = 1
> em_dim = 1024
> pol_dim = 1
> pol_state = I
> t_dim = 1
>
>
>
> - STIS spectroscopy (2D long slit):
>
> s_dim1 = 1024
> s_dim2 = 1
> em_dim = 1024
> pol_dim = 1
> pol_state = I
> t_dim = 1
>
>
>
> - ALMA:
>
> s_dim1 = 1000
> s_dim2 = 1000
> em_dim = 3000
> pol_dim = 4
> pol_state = I/U/V/Q
> t_dim = 1
>
> The more detailed mapping of s, em , etc on NAXIS1, NAXIS2, etc. in terms
> of WCS values could be handled in
> a future *getmetadata *capability of SIAv2, either via ADQL / Obstap or
> with a query by parameter, awaiting a
> more complete WCS solution for all astronomical observation.
> A discussion on WCS implementation for instance at the IVOA interop
> meeting in Sesto in June will help to go forward.
>
> Yes , see my previous emails on these lists.
>
>
> There are suggestions to use an optional UCD tag to specify the flavour of
> these axes , like *em_ucd*, for instance , already in ObsCoreDM
> to help to disentangle between frequency , wave and energy in the query
> response.
>
> Yes I agree
> I think this is interesting and could be used in all axes to specify
> roughly the global nature of the mapping
> ( s_ucd = pos.gal to describe a dataset organized along galactic axes)
> An additional optional tag for the projection could be added (eg s_proj)
>
> The "use case" for this is very simple : to figure out what kind of
> datacube is to be retrieved !!
> I think It is interesting to know if the cube is basically equatorial, in
> tangential projection and the em axis is FREQ or that what is going to come
> is Galactic, AITOFF and the em axis is sampled as a wavelength.
> From this additional information the user can infer what the retrieved
> file will look like and prepare some usage scenarii. But we shoul let all
> this optionnal
>
> Best regards
> François
>
>
>
> A draft is currently updated along these lines.
>
> Your comments , and suggestions welcome .
> Mireille
>
> --
> 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 Cedexhttp://astro.unistra.fr http://www.telecom-physique.fr
> tel : 03 68 85 24 34
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20150416/d78113b8/attachment.html>
More information about the dal
mailing list