<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,
<br>
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
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
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.
<br>
<br>
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. <br>
<br>
So I support Mireille's proposal of adding new possible values to
em_ucd (including z) for evolution of Obscore.
<br>
<br>
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.
<br>
<br>
Best regards
<br>
François
<br>
Le 30/04/2015 16:47, Arnold Rots a écrit :
<blockquote
cite="mid:CAJXToE-55sFsuciWCAON8q=fdt-mGhmbWX4g_M8MQCd2WCBx1A@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>I strongly urge to keep the two separate.<br>
</div>
Yes, they have much in common, but they serve very
different purposes.<br>
</div>
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).<br>
</div>
STC2 will treat the spectral and redshift/Doppler as
distinct axes.<br>
<br>
</div>
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.<br>
<br>
</div>
- Arnold<br>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature">
<div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>
Arnold H. Rots
Chandra X-ray Science Center<br>
Smithsonian Astrophysical Observatory
tel: +1 617 496 7701<br>
60 Garden Street, MS 67
fax: +1 617 495 7356<br>
Cambridge, MA 02138
<a moz-do-not-send="true"
href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>
USA <a
moz-do-not-send="true"
href="http://hea-www.harvard.edu/%7Earots/"
target="_blank">http://hea-www.harvard.edu/~arots/</a><br>
--------------------------------------------------------------------------------------------------------------<br>
<br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">On Mon, Apr 27, 2015 at 2:26 PM, Louys
Mireille <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mireille.louys@unistra.fr" target="_blank">mireille.louys@unistra.fr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> dear DMers, <br>
<br>
I am trying to recap on the discussion held since 2013
about the addition of a redshift or doppler axis in
Obscore. <br>
there has been various opinions expressed and typically
two different ways to think about it : <br>
<br>
1. Some dataset contain velocity measurements and are
sampled inside a velocity range , have velocity resolution
, etc .<br>
this is the case for Marco's Usecase for instance Then
quite naturally we could think a new axis is needed .<br>
this was the first suggestion we had before and at the
Banff interop meeting.<br>
<br>
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.<br>
if I consider the Spectral FITS WCS specification,( <a
moz-do-not-send="true"
href="http://www.aanda.org/articles/aa/pdf/2006/05/aa3818-05.pdf"
target="_blank">http://www.aanda.org/articles/aa/pdf/2006/05/aa3818-05.pdf</a>)
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.<br>
<br>
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. <br>
<br>
For the needs of the Obscore v1.1 update , I suggest that
velocity cubes be discovered by using <b>em_ucd</b>, with
the possible values equal to the following , as extracted
from the UCD list:<br>
<br>
<i>E | spect.dopplerVeloc | Radial velocity, derived from
the shift of some spectral feature</i><i><br>
</i><i>E | spect.dopplerVeloc.opt | Radial velocity
derived from a wavelength shift using the optical
convention</i><i><br>
</i><i>E | spect.dopplerVeloc.radio</i><i> | Radial
velocity derived from a frequency shift using the radio
convention</i><i><br>
<br>
</i>em_dim, em_min, em_max, etc will describe the
dimension and range along the velocity axis for the
returned datasets.<br>
<i><br>
</i>In a more detailed description , as required for
instance for the <i>getmetadata</i> capability in SIAv2 ,
then the full WCS axis description could be exposed.<br>
<br>
Many thanks for comments , Mireille.<span class="HOEnZb"><font
color="#888888"><br>
<br>
<br>
<pre cols="72">--
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
<a moz-do-not-send="true" href="http://astro.unistra.fr" target="_blank">http://astro.unistra.fr</a> <a moz-do-not-send="true" href="http://www.telecom-physique.fr" target="_blank">http://www.telecom-physique.fr</a>
tel : 03 68 85 24 34</pre>
</font></span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>