Redshift axis and Spectral Axis /
Louys Mireille
mireille.louys at unistra.fr
Tue May 12 19:36:37 CEST 2015
Hello Arnold , all,
My email about the comparison between redshift axis and spectral axis
was not completely finished and has been accidentally distributed on the
list.
I am aware Redshift axis and Spectral axis are different, but the
ImageDM , and especially the Figures, shows the two axes definitions as
clones from each other .
I was just pointing this, and think this would help to highlight this in
the Image DM specification and to emphasize which attributes are
different and needed in addition to interpret this axis with all the
reference fields implied.
This is quite natural , considering that redshift measurements are
derived from spectral observations and need reference position , line,
etc . as you mentioned.
When building up an instance serialisation of a dataset, there could be
some with with redshift and spectral axes , as your 4-D example ,
and some with other combinations, and may be none of them.
I hope this clarifies our misunderstanding.
Best wishes , Mireille.
Le 12/05/2015 17:47, Arnold Rots a écrit :
> 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 <mailto:arots at cfa.harvard.edu>
> USA http://hea-www.harvard.edu/~arots/
> <http://hea-www.harvard.edu/%7Earots/>
> --------------------------------------------------------------------------------------------------------------
>
>
> On Mon, May 11, 2015 at 11:37 AM, François Bonnarel
> <francois.bonnarel at astro.unistra.fr
> <mailto: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 <tel:%2B1%20617%20496%207701>
>> 60 Garden Street, MS 67 fax: +1 617 495 7356
>> <tel:%2B1%20617%20495%207356>
>> 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
>>
>>
>
>
--
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/20150512/ba588305/attachment-0001.html>
More information about the dm
mailing list