[Obscore DM update ] Redshift axis and Spectral Axis

Mon May 11 17:37:54 CEST 2015

Hi all,
    Arnold is right that we are facing two world coordinate axes 
characterizing the emmited light: spectral coordinate and doppler 
coordinate. The difficulty is that in general they are not disentangled 
and that this information is mixed on the same "data axis". The flux 
measured along the spectral axis is the result of a combination of the 
emmited spectral distribution by a doppler shift distribution
The use case  given by Arnold of 4D dataset with two different axes for 
spectral coordinates and doppler shift is to be considered but is very 
rare at the moment.

     In some situations the nature of the data allows to simplify the 
interpretation : broad spectral range with a single doppler shift value 
(where it is easy to apply a correction)  or oppositely isolated 
emission line ( where all spectral variations are due to doppler shift 
distribution). But in the most general case they are mixed and their 
separation is the result of detailed analysis.

     The WCS model doesn't separate  the two axes. The case where the 
spectral axis coordinate is given in one of the doppler shift unit is 
some kind of convenience for description of the spectral axis. The "rest 
frequency" is actually working as a parameter in the conversion between 
wl or frequencies and the doppler unit. It doesn't mean that all the 
measurements along the axis are related to a single line or transition. 
In general surrounding continuum and neighbourgh lines appear at 
"pseudo-redhsift" coordinates and must be suppressed to find out the 
emission line.
     The choice of this convenience mode  is motivated by the a priori 
knowledge we should be facing data for some given line but there is no 
guarantee we are observing ONLY this.

     In discovery mode, Obscore asserts that the spectral axis 
CHARACTERIZATION is always expressed in meters. If the actual datasets 
have a spectral axis sampled in doppler shift units this should be 
described by the em_ucd exactly like we do for axes in frequency or 
photon energy in ObsTap allready.

So I support   Mireille's proposal  of adding new possible values to 
em_ucd (including z) for evolution of Obscore.

      Use case of the datasets like the ones of Arnold cannot  be fully 
described this way because they really have the two axes disentangled. 
We assume that full ImageDm serialization provided by a GetMetadata 
resource will allow  fine tuning for the discovery of such datasets. 
They should also allow to tackle selection of datasets by some redshift 
or velocity ranges restriction.

Best regards
François
Le 30/04/2015 16:47, Arnold Rots a écrit :
> I strongly urge to keep the two separate.
> Yes, they have much in common, but they serve very different purposes.
> And it is possible to create a 4-D cube where the 4th axis is actually 
> a spectral axis and the pixels are different lines (rest frequencies).
> STC2 will treat the spectral and redshift/Doppler as distinct axes.
>
> I also note that you are missing redshift and that spect.dopplerVeloc 
> makes no sense: it's either radio or optical (or, in rare cases, 
> so-called relativistic), and one should not be allowed to gloss that over.
>
>   - Arnold
>
> -------------------------------------------------------------------------------------------------------------
> 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 <mailto:arots at cfa.harvard.edu>
> USA http://hea-www.harvard.edu/~arots/ 
> <http://hea-www.harvard.edu/%7Earots/>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Mon, Apr 27, 2015 at 2:26 PM, Louys Mireille 
> <mireille.louys at unistra.fr <mailto:mireille.louys at unistra.fr>> wrote:
>
>     dear DMers,
>
>     I am trying to recap on the discussion held since 2013 about the
>     addition of a redshift or doppler axis in Obscore.
>     there has been various opinions expressed and typically two
>     different ways to think about it :
>
>     1. Some dataset contain velocity measurements and are sampled
>     inside a velocity range , have velocity resolution , etc .
>     this is the case for Marco's Usecase for instance  Then quite
>     naturally we could think a new axis is needed .
>     this was the first suggestion we had before and at the Banff
>     interop meeting.
>
>     2. The doppler shift is always derived from an initial set of
>     spectral measurements . Therefore it can be described as a
>     spectral axis , with added reference position , rest frequency ,
>     etc. , specific unit in km/s , specific ucd.
>     if I consider the  Spectral FITS WCS specification,(
>     http://www.aanda.org/articles/aa/pdf/2006/05/aa3818-05.pdf)  the
>     velocity/doppler axes can have several flavors that are
>     characterized precisely. Table 1 and Table 2 of the spec , provide
>     all tags to differentiate the various cases.
>
>     I also gave a second read to the most recent version of ImageDM
>     published in March , and from the description of the Spectral
>     coordinate class ,Fig 20. p 55 compared to the RedshiftCoordinate
>     Fig 21, it is clear the two subtrees have a lot in common . This
>     means the Redshift coordinate could just be a derived class of the
>     spectral coordinate construct, with the addition of all the
>     reference frequency, positions , etc. , needed for that.
>
>     For the needs of the Obscore v1.1 update , I suggest that velocity
>     cubes be discovered by using *em_ucd*, with the possible values
>     equal to the following , as extracted from the UCD list:
>
>     /E | spect.dopplerVeloc | Radial velocity, derived from the shift
>     of some spectral feature//
>     //E | spect.dopplerVeloc.opt | Radial velocity derived from a
>     wavelength shift using the optical convention//
>     //E | spect.dopplerVeloc.radio//| Radial velocity derived from a
>     frequency shift using the radio convention//
>
>     /em_dim, em_min, em_max, etc  will describe the dimension and
>     range along the velocity axis for the returned datasets.
>     /
>     /In a more detailed description , as required for instance for the
>     /getmetadata/ capability in SIAv2 , then the full WCS axis
>     description could be exposed.
>
>     Many thanks for comments , 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 Cedex
>     http://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/dm/attachments/20150511/697b00bb/attachment.html>