[Obscore DM update ] Redshift axis and Spectral Axis
Arnold Rots
arots at cfa.harvard.edu
Tue May 12 17:47:19 CEST 2015
Maybe not suprisingly, I strongly disagree.
My 4-D example shows where we eventually may end up painting ourselves in a
corner,
but the main issue is that spectral properties and redshift/Doppler
properties are fundamentally
in different domains.
WCS also distinguishes them, though they are not as clearly separated: the
coordinate type
is either of a spectral nature or indicating Doppler quantities. The fact
that these are defined
in the same WCS paper does not alter the fact that they are different
animals.
Neither does the fact that a single axis may be interpreted as either
spectral or redshift: that
is the nature of WCS's allowing alternate coordinate systems. For instance,
a dataset of an
observation made with a moving slit may have time as well as spatial
position defined along
the direction of movement; the same is true for drift curves: they share
time and space
along a common pixel axis.
These are different concepts and proper modeling requires that we treat
them as such.
Users looking for data are typically interested in one or the other (or
maybe neither), and
having to specify that they want to make a spectral selection - and then-
having to qualify that:
oh, by the way, when I say spectral I really mean Doppler shift - makes no
sense at all.
I don't understand at all why people insist on this complicated spectral
coordinate treatment
when there is the simple solution of two distinct types of coordinate axes.
Besides, may I remind you that having a separate redshift/Doppler
coordinate also brings
ObsCore into compliance with an existing IVOA standard.
I thought Mireille's earlier proposal (though maybe not the ideal one from
my point of view) was
perfectly acceptable and I suggest we follow that route and stop haggling
over this issue.
My 2 bits (25c).
Cheers,
- Arnold
PS:
I am also thoroughly mystified by the paragraph about units - you mean to
say that Doppler
velocity should be expressed in meters - a unit of length???
-------------------------------------------------------------------------------------------------------------
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 Mon, May 11, 2015 at 11:37 AM, François Bonnarel <
francois.bonnarel at astro.unistra.fr> wrote:
> 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
> USA
> http://hea-www.harvard.edu/~arots/
>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Mon, Apr 27, 2015 at 2:26 PM, Louys Mireille <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 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/dm/attachments/20150512/c4dcd2b6/attachment.html>
More information about the dm
mailing list