<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hello Arnold , all,<br>
<br>
My email about the comparison between redshift axis and spectral
axis was not completely finished and has been accidentally
distributed on the list. <br>
<br>
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 . <br>
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.<br>
This is quite natural , considering that redshift measurements are
derived from spectral observations and need reference position ,
line, etc . as you mentioned.<br>
<br>
When building up an instance serialisation of a dataset, there
could be some with with redshift and spectral axes , as your 4-D
example , <br>
and some with other combinations, and may be none of them.<br>
<br>
I hope this clarifies our misunderstanding. <br>
Best wishes , Mireille.<br>
<br>
<br>
Le 12/05/2015 17:47, Arnold Rots a écrit :<br>
</div>
<blockquote
cite="mid:CAJXToE_MwwuEg8k9wJWdT=bN7SQvBcbe36U3j=RYLEqqdfur5Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Maybe not suprisingly, I strongly
disagree.<br>
</div>
My 4-D example shows where we
eventually may end up painting
ourselves in a corner,<br>
</div>
but the main issue is that spectral
properties and redshift/Doppler
properties are fundamentally<br>
</div>
in different domains.<br>
</div>
WCS also distinguishes them, though they are
not as clearly separated: the coordinate
type<br>
</div>
is either of a spectral nature or indicating
Doppler quantities. The fact that these are
defined<br>
</div>
in the same WCS paper does not alter the fact
that they are different animals.<br>
</div>
Neither does the fact that a single axis may be
interpreted as either spectral or redshift: that<br>
</div>
is the nature of WCS's allowing alternate coordinate
systems. For instance, a dataset of an<br>
</div>
observation made with a moving slit may have time as
well as spatial position defined along<br>
</div>
the direction of movement; the same is true for drift
curves: they share time and space<br>
</div>
<div>along a common pixel axis.<br>
<br>
These are different concepts and proper modeling
requires that we treat them as such.<br>
</div>
</div>
Users looking for data are typically interested in one or
the other (or maybe neither), and<br>
</div>
having to specify that they want to make a spectral selection
- and then- having to qualify that:<br>
oh, by the way, when I say spectral I really mean Doppler
shift - makes no sense at all.<br>
</div>
<div>I don't understand at all why people insist on this
complicated spectral coordinate treatment<br>
</div>
<div>when there is the simple solution of two distinct types of
coordinate axes.<br>
</div>
<div>Besides, may I remind you that having a separate
redshift/Doppler coordinate also brings<br>
</div>
<div>ObsCore into compliance with an existing IVOA standard.<br>
</div>
<div>I thought Mireille's earlier proposal (though maybe not the
ideal one from my point of view) was<br>
</div>
<div>perfectly acceptable and I suggest we follow that route and
stop haggling over this issue.<br>
<br>
</div>
<div>My 2 bits (25c).<br>
<br>
</div>
<div>Cheers,<br>
<br>
</div>
<div> - Arnold<br>
<br>
</div>
<div>PS: <br>
<div>I am also thoroughly mystified by the paragraph about
units - you mean to say that Doppler<br>
</div>
<div>velocity should be expressed in meters - a unit of
length???<br>
</div>
<div><br>
</div>
</div>
</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, May 11, 2015 at 11:37 AM,
François Bonnarel <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:francois.bonnarel@astro.unistra.fr"
target="_blank">francois.bonnarel@astro.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"> 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>
<span class="HOEnZb"><font color="#888888"> François <br>
</font></span>
<div>
<div class="h5"> Le 30/04/2015 16:47, Arnold Rots a
écrit :
<blockquote 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>
<div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>
Arnold H. Rots
Chandra X-ray Science Center<br>
Smithsonian Astrophysical
Observatory tel: <a
moz-do-not-send="true"
href="tel:%2B1%20617%20496%207701"
value="+16174967701" target="_blank">+1
617 496 7701</a><br>
60 Garden Street, MS
67
fax: <a moz-do-not-send="true"
href="tel:%2B1%20617%20495%207356"
value="+16174957356" target="_blank">+1
617 495 7356</a><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><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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" 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 class="moz-txt-link-freetext" href="http://astro.unistra.fr">http://astro.unistra.fr</a> <a class="moz-txt-link-freetext" href="http://www.telecom-physique.fr">http://www.telecom-physique.fr</a>
tel : 03 68 85 24 34</pre>
</body>
</html>