<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Dear Alberto, all<br>
</div>
<div class="moz-cite-prefix">Le 24/02/2023 à 01:18, Alberto Micol a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:AAA942A4-63DA-461B-A0DA-F013130607E8@eso.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.apple-converted-space
{mso-style-name:apple-converted-space;}span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}span.EmailStyle27
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style>
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks
Françoios. I think the query constraints should not involve
the velocities (is there a use case that calls for this?),
but only the em_min/max, or equivalently f_min/max, and on
v_resolution (or equivalently on em_resolv_power =
c/v_resolution). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">The
fact that a query could lead to a cube that covers or not a
redshifted Halpha or a NII, is not an issue as this is
exactly the same behaviour we accept when querying spectra.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">em_unit
is also not of interest for a ObsCore discovery query, plus
as said, v_min and v_max should be express always in m/s, as
well as v_resolution.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
</div>
</blockquote>
<br>
<blockquote type="cite"
cite="mid:AAA942A4-63DA-461B-A0DA-F013130607E8@eso.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">For
me is important that the v_min and v_max be present in the
ObsCore result, because they can be used to express the SODA
max value of the “velocity” filtering parameter. With that,
a user can provide the cuts in velocity, after having
discovered a cube using ranges in wavelengths or
frequencies.
</span></p>
</div>
</blockquote>
<p>But if we push v_min v_max in ObsCore we cannot make them not
queryable , do we ? So I think this some kind of second step
information (basically the wcs which is not in ObsCore, neither
for spatial, nor for other axes such as the spectral one.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:AAA942A4-63DA-461B-A0DA-F013130607E8@eso.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">It
also useful to have the rest frequency/wavelength and the
velocity flavour in ObsCore, so that they can be passed in
input to SODA: in this way cuts could be provided in
wavelengths or frequencies, as all the parameters to perform
vel vs freq vs wavel transformations are then available (and
this allows to treat frequency cubes as if they were
velocity cubes).</span></p>
</div>
</blockquote>
<p>I can see several ways to do that :</p>
<p>use dataLink and the #detached-header semantics value. But the
connexion to SODA is not that obvious in that case<br>
</p>
<p> two ways to do it :</p>
<p class="MsoNormal"> <font size="4"> a ) use an
extra parameter such as META=true (see proposal and
implementation by CADC there :
<a class="moz-txt-link-freetext" href="https://wiki.ivoa.net/internal/IVOA/InterOpNov2021DAL/minoc-soda-objectstore.pdf">https://wiki.ivoa.net/internal/IVOA/InterOpNov2021DAL/minoc-soda-objectstore.pdf</a>)</font></p>
<p class="MsoNormal"><font size="4"><br>
</font></p>
<p class="MsoNormal"><font size="4">b ) directly describe the VEL
cutout parameters in the service descriptor of SODA (with VALUES
and MIN/MAX elements</font></p>
<p class="MsoNormal"><font size="4"><br>
</font></p>
<p class="MsoNormal"><font size="4">I personnaly prefer a ) and this
can be integrated in SODA-next. We can also imagine to provide
ObsCore-style PARAM names (and maybe also utypes) for the wcs
parameters</font><br>
</p>
<blockquote type="cite"
cite="mid:AAA942A4-63DA-461B-A0DA-F013130607E8@eso.org">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">I’d
like to know if anybody as a use case to place a constraint
on the v_min/max instead of using em_min/max (or f_min/max);
anybody?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Alberto<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">BONNAREL FRANCOIS
<a class="moz-txt-link-rfc2396E" href="mailto:francois.bonnarel@astro.unistra.fr"><francois.bonnarel@astro.unistra.fr></a><br>
<b>Date: </b>Thursday, 23 February 2023 at 15:48<br>
<b>To: </b>Alberto Micol <a class="moz-txt-link-rfc2396E" href="mailto:amicol@eso.org"><amicol@eso.org></a>, alberto
micol <a class="moz-txt-link-rfc2396E" href="mailto:amicol.ivoa@googlemail.com"><amicol.ivoa@googlemail.com></a><br>
<b>Cc: </b><a class="moz-txt-link-rfc2396E" href="mailto:dal@ivoa.net">"dal@ivoa.net"</a> <a class="moz-txt-link-rfc2396E" href="mailto:dal@ivoa.net"><dal@ivoa.net></a>, Data
Models mailing list <a class="moz-txt-link-rfc2396E" href="mailto:dm@ivoa.net"><dm@ivoa.net></a><br>
<b>Subject: </b>Re: ObsCore for velocity cubes<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<table class="MsoNormalTable" style="width:100.0%" width="100%"
cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td style="border:solid orange 1.0pt;border-left:solid
orange 6.0pt;background:white;padding:7.5pt 7.5pt 7.5pt
7.5pt">
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif">This
email was sent from outside of ESO from the address
<strong><span
style="font-family:"Arial",sans-serif;color:black">[<a class="moz-txt-link-abbreviated" href="mailto:francois.bonnarel@astro.unistra.fr">francois.bonnarel@astro.unistra.fr</a>]</span></strong><span
style="color:black">. If it looks suspicious,
please report it to <a class="moz-txt-link-abbreviated" href="mailto:phishing@eso.org">phishing@eso.org</a>.</span><o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="display:none"><o:p> </o:p></span></p>
<table class="MsoNormalTable" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr style="height:7.5pt">
<td style="width:100.0%;padding:0cm 0cm 0cm
0cm;height:7.5pt" width="100%">
<p class="MsoNormal" style="line-height:7.5pt"><span
style="font-size:7.5pt"> <o:p></o:p></span></p>
</td>
</tr>
</tbody>
</table>
<div>
<p class="MsoNormal">Dear Alberto,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> For sure it's possible to have the
parameters of Greisen et al in an extension.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> But I'm still wondering how useful
and handy it is.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> Again, definitely I see the interest
of delivering these metadata (which are actually fitw wcs
metadata) at the SODA level in order to create a velocity
cutout query.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> But I'm still filling chilly for
data discovery.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Let's look at a couple of examples<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> select * from
obscore-with-vel-extension where dataproduct_type= cube and
v_min = 800 and v_max= 1200 and em_unit = km/s and em_ucd =
vel
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> then you get for example <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> optical cubes with h
alpha line redshifted by ~1.7 to ~2.6 nm<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> and radio cubes with 21
cm line redshifted by ~0.55 to ~0.8 mm<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> and probably many
others<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> So, will you say, we have to give
the reference line to get h alpha redshifted line ONLY
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> select * from
obscore-with-vel-extension where dataproduct_type= cube and
v_min = 800 and v_max= 1200 and em_unit = km/s and em_ucd =
vel and em_ref = 656.3 10**-9
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> But then what you get is
something which may contain the redshifted halpha line but
maybe also nothing about halpha (because the velocity axis
is not a guarantee for redshifted line to be there in the
dataset) but instead the NII line at 658.4.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> Or even worse = (highly)
redshifhted halpha and (nearly) non redshifted NII !!! (and
there we are close to the 4D use case)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> So I find this misleading and I
think we can find also the same kind of mess in the radio
domain (imagine very high z pushing 21 cm in low frequency
radio or mm lines in the metric domain for example )<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> So if you want velocity cubes in
the halpha redshift rang eas above just query<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> select * from
obscore-with-vel-extension where dataproduct_type= cube and
em_min = 658.0 10**-9 and em_max = 658.9 10**-9 and em_unit
= km/s and em_ucd = vel and em_ref = 656.3 10**-9<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> This will be exactly the same
results with the same limitations (Halpha redshift and there
or not and NII there or not) but at least less confusion.
And you will exclude all cubes which are not organized with
velocity axes anyway.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> I still wonder if the em_unit is
needed there, because it is supposed to describe the unit
used in the dataset and I don't think if you look for
velocity cubes you want to select those in m/s from those in
km/s. I think what you need is to know what is the unit.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> My conclusion adding em_ref for
the reference line an a couple of new values for em_ucd
should be enough for ObsCore extension and all the other
things for SODA.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">François<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Le 22/02/2023 à 17:33, Alberto Micol a
écrit :<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Sorry
let me rephrase more correctly:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Can
we aim to describe the Greisen (2006) cubes, limiting to
the 3d case (2 spatial 1 velocity), so to cover most of
the existing velocity cubes?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Alberto</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">Alberto Micol
<a href="mailto:amicol@eso.org" moz-do-not-send="true"><amicol@eso.org></a><br>
<b>Date: </b>Wednesday, 22 February 2023 at 17:26<br>
<b>To: </b>BONNAREL FRANCOIS <a
href="mailto:francois.bonnarel@astro.unistra.fr"
moz-do-not-send="true">
<francois.bonnarel@astro.unistra.fr></a>,
alberto micol <a
href="mailto:amicol.ivoa@googlemail.com"
moz-do-not-send="true">
<amicol.ivoa@googlemail.com></a><br>
<b>Cc: </b><a href="mailto:dal@ivoa.net"
moz-do-not-send="true">"dal@ivoa.net"</a> <a
href="mailto:dal@ivoa.net" moz-do-not-send="true">
<dal@ivoa.net></a>, Data Models mailing list <a
href="mailto:dm@ivoa.net" moz-do-not-send="true"><dm@ivoa.net></a><br>
<b>Subject: </b>Re: ObsCore for velocity cubes</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks
for the explanation!</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">As
said, my aim is to cover the cubes described in Greisen et
al, 2006, and not “any kind of imaginable cube”.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">This
4D cube you described is something of a different nature.
And indeed is no longer a regular 3D cube.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Can’t
we aim to describe just only the Greisen et al, 3d cubes?
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">That
would cover a huge fraction of the existing cubes.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Alberto</span><o:p></o:p></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">BONNAREL FRANCOIS
<a href="mailto:francois.bonnarel@astro.unistra.fr"
moz-do-not-send="true"><francois.bonnarel@astro.unistra.fr></a><br>
<b>Date: </b>Wednesday, 22 February 2023 at 17:20<br>
<b>To: </b>Alberto Micol <a
href="mailto:amicol@eso.org" moz-do-not-send="true"><amicol@eso.org></a>,
alberto micol
<a href="mailto:amicol.ivoa@googlemail.com"
moz-do-not-send="true"><amicol.ivoa@googlemail.com></a><br>
<b>Cc: </b><a href="mailto:dal@ivoa.net"
moz-do-not-send="true">"dal@ivoa.net"</a> <a
href="mailto:dal@ivoa.net" moz-do-not-send="true">
<dal@ivoa.net></a>, Data Models mailing list <a
href="mailto:dm@ivoa.net" moz-do-not-send="true"><dm@ivoa.net></a><br>
<b>Subject: </b>Re: ObsCore for velocity cubes</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<table class="MsoNormalTable" style="width:100.0%"
width="100%" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td style="border:solid orange 1.0pt;border-left:solid
orange 6.0pt;background:white;padding:7.5pt 7.5pt
7.5pt 7.5pt">
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif">This
email was sent from outside of ESO from the
address
<strong><span
style="font-family:"Arial",sans-serif;color:black">[<a
href="mailto:francois.bonnarel@astro.unistra.fr" moz-do-not-send="true"
class="moz-txt-link-freetext">francois.bonnarel@astro.unistra.fr</a>]</span></strong><span
style="color:black">. If it looks suspicious,
please report it to
<a href="mailto:phishing@eso.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">phishing@eso.org</a>.</span></span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="color:white"> </span><o:p></o:p></p>
<table class="MsoNormalTable" cellspacing="0" cellpadding="0"
border="0">
<tbody>
<tr style="height:7.5pt">
<td style="width:100.0%;padding:0cm 0cm 0cm
0cm;height:7.5pt" width="100%">
<p class="MsoNormal" style="line-height:7.5pt"><span
style="font-size:7.5pt"> </span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<div>
<p class="MsoNormal"><span style="color:white">Dear Albe</span>rto,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I quote Arnold (2015 Apr 30)<o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>I strongly urge to keep the two separate.<o:p></o:p></pre>
<pre>Yes, they have much in common, but they serve very different purposes.<o:p></o:p></pre>
<pre>And it is possible to create a 4-D cube where the 4th axis is actually a<o:p></o:p></pre>
<pre>spectral axis and the pixels are different lines (rest frequencies).<o:p></o:p></pre>
<pre>STC2 will treat the spectral and redshift/Doppler as distinct axes.<o:p></o:p></pre>
</blockquote>
<p class="MsoNormal">Now imagine you have Halpha and Hbeta
lines in the same dataset (MUSE cubes?). The may come from
different regions and the velocities will be different for
both.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">You could have a different velocity map
for the two lines in the same dataset.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">François <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Le 22/02/2023 à 17:06, Alberto Micol a
écrit :<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">Many thanks François,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">I will think
thouroughly through your message, but first I would like
to ask you to clarify the meaning of your sentence: “As
Arnold pointed at that time you have datasets where you
provide different doppler shift information at different
spectral coordinates. What are the radial velocity
bounds in that case ?”</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">Could you explain
that with more words, maybe giving an example?</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">To explain why I do
not understand that sentence, I give you an example of a
cube I have at hand here.</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">In my case a velocity
cube is a FITS cube with the third axis defined as:</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">CTYPE3 = ‘VRAD’</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">CUNIT3 = ‘m/s’</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">CD3_3_ = 250</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">CRVAL3 = 0</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">CRPIX3 = 141</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">NAXIS3 = 281</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">That is enough to
state that:
</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">V_min = -35000 m/s</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">V_max = +35000 m/s</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">Many thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US">Alberto</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:12.0pt;color:black">From: </span></b><span
style="font-size:12.0pt;color:black">BONNAREL FRANCOIS
<a href="mailto:francois.bonnarel@astro.unistra.fr"
moz-do-not-send="true"><francois.bonnarel@astro.unistra.fr></a><br>
<b>Date: </b>Wednesday, 22 February 2023 at 16:46<br>
<b>To: </b>alberto micol <a
href="mailto:amicol.ivoa@googlemail.com"
moz-do-not-send="true"><amicol.ivoa@googlemail.com></a>,
Alberto Micol
<a href="mailto:amicol@eso.org" moz-do-not-send="true"><amicol@eso.org></a><br>
<b>Cc: </b><a href="mailto:dal@ivoa.net"
moz-do-not-send="true">"dal@ivoa.net"</a> <a
href="mailto:dal@ivoa.net" moz-do-not-send="true">
<dal@ivoa.net></a>, Data Models mailing list <a
href="mailto:dm@ivoa.net" moz-do-not-send="true"><dm@ivoa.net></a><br>
<b>Subject: </b>Re: ObsCore for velocity cubes</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<table class="MsoNormalTable" style="width:100.0%"
width="100%" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td style="border:solid orange 1.0pt;border-left:solid
orange 6.0pt;background:white;padding:7.5pt 7.5pt
7.5pt 7.5pt">
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif">This
email was sent from outside of ESO from the
address
<strong><span
style="font-family:"Arial",sans-serif;color:black">[<a
href="mailto:francois.bonnarel@astro.unistra.fr" moz-do-not-send="true"
class="moz-txt-link-freetext">francois.bonnarel@astro.unistra.fr</a>]</span></strong><span
style="color:black">. If it looks suspicious,
please report it to
<a href="mailto:phishing@eso.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">phishing@eso.org</a>.</span></span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="color:white"> </span><o:p></o:p></p>
<table class="MsoNormalTable" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr style="height:7.5pt">
<td style="width:100.0%;padding:0cm 0cm 0cm
0cm;height:7.5pt" width="100%">
<p class="MsoNormal" style="line-height:7.5pt"><span
style="font-size:7.5pt"> </span><o:p></o:p></p>
</td>
</tr>
</tbody>
</table>
<div>
<p class="MsoNormal"><span style="color:white">Dear Albe</span>rto,
all,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> I come to this copying also to
the dm list (ObsCoire and extensions are dm stuff). As
you may remember this point was EXTENSIVELY discussed
when we upgraded ObsCore from 1.0 to 1.1.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> This discussion was mainly in
2014/2015. See for example these threads starting by
<a
href="http://mail.ivoa.net/pipermail/dm/2015-April/005147.html"
moz-do-not-send="true" class="moz-txt-link-freetext">http://mail.ivoa.net/pipermail/dm/2015-April/005147.html</a>
and
<a
href="http://mail.ivoa.net/pipermail/dm/2015-April/005168.html"
moz-do-not-send="true" class="moz-txt-link-freetext">http://mail.ivoa.net/pipermail/dm/2015-April/005168.html</a>
as well as
<a
href="http://mail.ivoa.net/pipermail/dm/2015-May/005174.html"
moz-do-not-send="true" class="moz-txt-link-freetext">http://mail.ivoa.net/pipermail/dm/2015-May/005174.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> The conclusion at that time was
that we didn't have to extend ObsCore this way
eventually.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> For several reasons.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - radial velocity or
redshifts derivation from spectral frequencies or wl
are complex things. querying between vel = 10 km/s and
60 km/s may give different results according to the
radial velocity (or dopplershift) flavor. And if we add
the constraint em_ucd = vrad (or vopt, or ) then the
query become really specialised.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - if the velocity cube is
simply a transform of the frequency/wavelength axis we
still have to select on wavelength because velocity
cubes in radio domain and velocity cube in optical
domain are really different things<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - But generally speaking the
velocity axis is not ONLY a transform of the wavelength
(or frequency) axis, it provides different information.
It is a different axis (although related). As Arnold
pointed at that time you have datasets where you provide
different doppler shift information at different
spectral coordinates. What are the radial velocity
bounds in that case ?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> ---> ObsCore will become
really complex to manage and fill in these situations<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> Considering your use case
Alberto, I think we have two distinguish two steps<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - data discovery (With
ObsTAP/ SIA) = it's probably enough to let the user know
that you have velocity cubes by providing the
appropriate values in em_ucd and em_unit (which are
there to describe the dataset content and not the
spectral characterization). We may think to add em_ref
to give the wl of the reference line. velocity limits
will have to be transformed in wavelength to fill the
mandatory em_min/max anyway. With this you already know
that the data you discover by a standard ObsCore (or
radio extension) query are "'velocity cubes"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - SODA cutouts : there ,
the parameters you propose are useful. A discussion
started already some time ago to extend SODA . For
example adding pixel cutouts, or changing the projection
or the spatial sampling of the cutout. In this context
we could also choose to extract by forcing velocity
constraints, when appropro$iate.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> To do that we need
additional metadata (eg : the content of WCS, and this
also for the spectral axis). And for that, there is the
old idea to have a SODA mode providing full metadata,
CADC already implemented something like that. The
velocity '"axis" detailed flavor can be described this
way if it exists. This also has to be integrated in the
SODA-next discussion. Some more on this will come soon.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">François<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> 1Le 22/02/2023 à 11:33, alberto
micol a écrit :<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Very well, thanks both Markus and
Pat. <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">So, yes, we need a v_resolution,
and it must be in fixed units.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Taking the Greisen et al. default,
this is [m/s].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We though need the fravergy UCD to
be able to discriminate the different velocity
flavours.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Is em_ucd the correct field to
use? <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(Yes, I’m hit strongly by the
confusion of throwing untested features from a data
model into a relational mapping,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">that’s why I need your confirmation
on this)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Alberto<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On 21 Feb 2023, at 21:11,
Alberto Micol <<a
href="mailto:amicol@eso.org"
moz-do-not-send="true"
class="moz-txt-link-freetext">amicol@eso.org</a>>
wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Hi
James,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Thanks
for the answer. I have a question/doubt
regarding the v_resolution and v_unit.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">ObsCore
already foresees the em_resolution, so I
originally thought we do not need the
v_resolution.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">But
now I am reconsidering this, because I
think (in the ObsCore standard we were not
super-clear regarding this) the units of
em_resolution are the ones provided by the
em_unit attribute. Different cubes could
have different em_units, and that means
that em_resolution could not be used to
seamlessly query across all possible
cubes.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">If
the above is correct, then, yes, we need
to have a new field,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">v_resolution,
with units fixed to e.g. m/s,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">similarly
to the case of em_min/max always provided
in [m], whatever the value of the em_unit,
to support searches.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">In
which case, we do not need a v_unit, as
v_min/max are fixed in [m/s] and we
already have em_unit for the units encoded
in the cube.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Would
that make sense?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Regarding
treating frequency cubes as velocity cubes
(and viceversa), </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">it
is indeed useful to provide
characterisations both in frequency and in
velocity</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">(and
why not energy and wavelength),
distinguishing the different cases
according to</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">the
value of the em_ucd, e.g., em.freq,
em.wl, em.energy (see ObsCore B.6.2), or</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">spect.dopplerVeloc.radio, spect.dopplerVeloc.opt, spect.dopplerVeloc.rel
(*) (see ObsCore B.6.2.6). </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">So
we would have:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">em_ucd
required</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">v_resolution
required, fixed in m/s</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">em_unit
optional, expressing the unit encoded in
the cube for the spectral axis</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">em_resolution
optional, expressing the resolution in the
units used by the data cube</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">If
we converge on this, I could put together
a little document with a detailed
proposal.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Would
that considered useful?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Cheers,</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">Alberto</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">(*)
cross-standard issue: the
spect.dopplerVeloc.rel is mentioned in the
ObsCore standard, </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">but
it is not a recognised value in the
current UCD1+ standard.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:10.5pt;font-family:Helvetica">We
will need to act on this (Mireille?).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<div>
<p class="MsoNormal"><b><span
style="font-size:12.0pt">From:<span
class="apple-converted-space"> </span></span></b><span
style="font-size:12.0pt">"Dempsey, James
(IM&T, Black Mountain)" <<a
href="mailto:James.Dempsey@csiro.au"
moz-do-not-send="true"><span
style="color:purple">James.Dempsey@csiro.au</span></a>><br>
<b>Date:<span
class="apple-converted-space"> </span></b>Thursday,
16 February 2023 at 00:21<br>
<b>To:<span
class="apple-converted-space"> </span></b>Alberto
Micol <<a
href="mailto:amicol@eso.org"
moz-do-not-send="true"><span
style="color:purple">amicol@eso.org</span></a>>,
"<a href="mailto:dal@ivoa.net"
moz-do-not-send="true"><span
style="color:purple">dal@ivoa.net</span></a>"
<<a href="mailto:dal@ivoa.net"
moz-do-not-send="true"><span
style="color:purple">dal@ivoa.net</span></a>><br>
<b>Subject:<span
class="apple-converted-space"> </span></b>Re:
ObsCore for velocity cubes</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<table class="MsoNormalTable"
style="width:100.0%" width="100%"
cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td style="border:solid orange
1.0pt;border-left:solid orange
6.0pt;background:white;padding:7.5pt
7.5pt 7.5pt
7.5pt;background-position:initial
initial;background-repeat:initial
initial">
<div>
<p class="MsoNormal"><span
style="font-size:10.0pt;font-family:"Arial",sans-serif">Th<span
style="color:black">is email was
sent from outside of ESO from
the address<strong><span
style="font-family:"Arial",sans-serif">[<a
href="mailto:prvs=40330730a=James.Dempsey@csiro.au"
moz-do-not-send="true"><span
style="color:purple">prvs=40330730a=James.Dempsey@csiro.au</span></a>]</span></strong>. If
it looks suspicious, please
report it to<span
class="apple-converted-space"> </span><a
href="mailto:phishing@eso.org"
moz-do-not-send="true"><span
style="color:purple">phishing@eso.org</span></a>.</span></span><o:p></o:p></p>
</div>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span
style="font-size:9.0pt;font-family:Helvetica;color:white"> </span><o:p></o:p></p>
<table class="MsoNormalTable" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr style="height:7.5pt">
<td style="width:100.0%;padding:0cm 0cm
0cm 0cm;height:7.5pt" width="100%">
<div>
<p class="MsoNormal"
style="line-height:7.5pt"><span
style="font-size:7.5pt"> </span><o:p></o:p></p>
</div>
</td>
</tr>
</tbody>
</table>
<div>
<p class="MsoNormal"><span style="color:white">Hi
Alberto</span>,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">At CASDA we support
cutouts of velocity spectral line cubes.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We currently require the
user to provide a BAND or CHANNEL parameter
to the SODA service which is translated by
the service to the velocity frame of the
target cube. This works, but requiring
conversions on both the client and server
side isn’t ideal. Likewise, in our ObsCore
implementation only the em_ucd indicates the
cubes are in velocity but it would certainly
be useful to have full velocity information
for data discovery!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The extension you outline
looks like it would work nicely for the same
use case in CASDA. However I think we should
add the following to fully describe the
velocity axis (as opposed to its translation
into wavelength for the base obscore).<o:p></o:p></p>
</div>
<ol style="margin-top:0cm" type="1" start="1">
<li class="MsoListParagraph"
style="margin-top:0cm;margin-bottom:0cm;margin-bottom:.0001pt;mso-list:l0
level1 lfo3">
v_resolution – value of CDELT3 or CDELT4<span
style="font-size:10.0pt"> </span><o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-top:0cm;margin-bottom:0cm;margin-bottom:.0001pt;mso-list:l0
level1 lfo3">
v_unit – although this should always be m/s<span
style="font-size:10.0pt"> </span>
<o:p></o:p></li>
</ol>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Another consideration is
that a lot of our users tend to use velocity
to interact with frequency cubes. So even
for these frequency cubes we might end up
filling in velocity metadata if the fields
were defined. Tools such as CARTA tend to
automatically show the spectral axis as
velocity where it can, such that many users
would assume the cubes are in velocity not
frequency.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span
style="color:#00A9CE">James Dempsey</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:9.0pt">Senior
Developer <span
class="apple-converted-space"> </span>|
CSIRO </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a
href="mailto:james.dempsey@csiro.au"
moz-do-not-send="true"><span
style="font-size:9.0pt;color:purple">james.dempsey@csiro.au</span></a><span
style="font-size:9.0pt"> <span
class="apple-converted-space"> </span>|
02 6214 2912</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"
style="margin-bottom:12.0pt"><b><span
style="font-size:12.0pt">From:<span
class="apple-converted-space"> </span></span></b><span
style="font-size:12.0pt">dal <<a
href="mailto:dal-bounces@ivoa.net"
moz-do-not-send="true"
class="moz-txt-link-freetext">dal-bounces@ivoa.net</a>>
on behalf of alberto micol <<a
href="mailto:amicol.ivoa@googlemail.com"
moz-do-not-send="true"
class="moz-txt-link-freetext">amicol.ivoa@googlemail.com</a>><br>
<b>Date:<span
class="apple-converted-space"> </span></b>Thursday,
16 February 2023 at 12:02 am<br>
<b>To:<span class="apple-converted-space"> </span></b><a
href="mailto:dal@ivoa.net"
moz-do-not-send="true"
class="moz-txt-link-freetext">dal@ivoa.net</a>
<<a href="mailto:dal@ivoa.net"
moz-do-not-send="true"
class="moz-txt-link-freetext">dal@ivoa.net</a>><br>
<b>Subject:<span
class="apple-converted-space"> </span></b>ObsCore
for velocity cubes</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Dear ObsCorers,<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I have received with
much interest the ObsCore extension for
RADIO data, thanks for that very clear
document.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Would it be possible to
have a similar extension for cubes with
velocity as third axis (the other two
being the usual spatial ones)?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Let me call them
“velocity cubes”...<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Here my use case…<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">At ESO we need to
support cutouts of velocity cubes.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Up to now our SODA
interface supported spectra, images, and
wavelength cubes;<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">to provide the user
with the SODA input parameters and their
possible MIN/MAX values<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">we query ivoa.ObsCore.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Now with the
introduction of velocity cubes, we would
like to get the necessary SODA input
params also from ObsCore.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">We can certainly do so
by extending our own ObsCore table
(ObsCore allows to extend the table), but
I was wondering<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">if others have similar
needs, and see if we can agree with a
common ObsCore extension.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Velocity cubes should
come in a FITS format as described by
Greisen et al, 2006, so-called Paper 3.<o:p></o:p></p>
</div>
</div>
<blockquote
style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Shortly summarised,
the velocity can be either:<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<ol style="margin-top:0cm" type="1" start="1">
<ol style="margin-top:0cm" type="1"
start="1">
<li class="MsoNormal" style="mso-list:l3
level2 lfo6">a radio (VRAD), <span
style="font-size:10.0pt">
</span><o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l3
level2 lfo6">an optical (VOPT), <span
style="font-size:10.0pt">
</span><o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l3
level2 lfo6">a relativistic velocity
(ZOPT), <span style="font-size:10.0pt">
</span><o:p></o:p></li>
<li class="MsoNormal" style="mso-list:l3
level2 lfo6">a generic apparent velocity
(VELO).<span style="font-size:10.0pt">
</span><o:p></o:p></li>
</ol>
</ol>
</div>
<blockquote
style="margin-left:30.0pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">The RESTFRQa
(RESTWAVa) keyword conveys the necessary
reference frequency (wavelength) to
transform velocity into frequency or
wavelength. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The velocity unit is
m/s.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">SODA cutouts on the
velocity axis are usually formulated by
passing cuts already expressed in velocity<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">though it must be
possible to perform the conversions to and
from frequency/wavelength.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">What would then be
needed in ObsCore is:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">v_min<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">v_max<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">but also, in case of
radio velocity cube:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">f_min<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">f_max (getting these
from the RADIO extension)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">f_rest = RESTFRQ<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">and, in case of a
optical or relativistic velocity cube<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">em_rest = RESTWAV<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">(we already have
em_min, em_max)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The em_resolv_power
should then be set to:<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> lambda
freq c<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> ——————— = ————— =
—————<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> delta lambda
delta freq 2 * delta_v<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">where delta_v is the
CD3_3 in the cube (in the example of a
cube with the velocity on the third axis);<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">but I would also likely
accept a v_pixel_scale (= delta_v).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The UCD for the
velocity should then be:<o:p></o:p></p>
</div>
</div>
<div>
<pre>spect.dopplerVeloc.opt<o:p></o:p></pre>
<div>
<pre>spect.dopplerVeloc.radio<o:p></o:p></pre>
<div>
<div>
<p class="MsoNormal">unsure what it
should be for the relativistic case.<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">This would allow us at
ESO to implement SODA on top of ObsCore
(as already done for all other parameters)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">and would allow
astronomer to search the velocity cubes
with certain characteristics using
ObsCore.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">What do you think? <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Is that doable? I think
at ESO we will simply start implementing
the above extra ObsCore parameters (unless
you suggest different names for that),<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">while waiting to see if
there is more interest to build a proper
standard.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Eager to know what you
think, <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Alberto<o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
</blockquote>
<p> <o:p></o:p></p>
</blockquote>
<p> <o:p></o:p></p>
</blockquote>
<p><o:p> </o:p></p>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>