<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 href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" 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 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 href="tel:%2B1%20617%20496%207701" value="+16174967701" target="_blank">+1 617 496 7701</a><br>
60 Garden Street, MS 67
fax: <a href="tel:%2B1%20617%20495%207356" value="+16174957356" target="_blank">+1 617 495 7356</a><br>
Cambridge, MA 02138
<a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>
USA <a 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 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 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 href="http://astro.unistra.fr" target="_blank">http://astro.unistra.fr</a> <a 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>