ObsCore for velocity cubes

Tue Feb 21 22:06:31 CET 2023

To be honest, I don't recall ever seeing em_unit (first seen in appendix B,
page 42) and even in the document it is clear that it isn't actually usable
in the ObsTAP context (see B.6.2). I guess that 's what happens when we mix
the model (ObsCore) and the relational mapping (ObsTAP) in a single
document *and* throw in a bunch of un-tried/tested/used features.

Note that there are no s_unit or t_unit (columns) so yeah: the fravergy
axis is quite a bit more complex, which could be fine by itself but
collides with the goal of simplicity that is highly desirable for
relational mapping for TAP.

Nothing that first appears in the appendix is part of the spec.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Tue, 21 Feb 2023 at 12:12, Alberto Micol <amicol at eso.org> wrote:

> Hi Andreas and Arnold,
>
>
> The little proposal I’m putting together wants to cover the cases covered
> by Greisen et al, in paper 3, 2006,
>
> where they mention:
>
>
>
> "[…] The apparent radial velocity then is a sum of
>
> all spectroscopic effects presented as if they were solely a ra-
> dial velocity. While this may be sufficiently accurate for many
> uses, observers wishing to achieve very high accuracies should
> consult Lindegren & Dravins (2003), and references therein, closely."
>
>
>
> It seems to me, but please correct me if wrong, that the simple model I’m
> proposing covers the most common of the Greisen’s described cases, and not
> the more complex or less frequent cases.
>
> One consideration I have in mind is that ObsCore is used to search, and
> not to analyse the data, so I think it does not need to be that precise.
>
>
>
> Could you please consider the above and tell me if there is anything that
> I have missed? It could be plenty of things that I have missed as I am
> certainly not an expert in the field! Your help is much appreciated.
>
>
>
> Many thanks,
>
> Alberto
>
>
>
> *From: *Andreas Wicenec <andreas.wicenec at uwa.edu.au>
> *Date: *Friday, 17 February 2023 at 03:01
> *To: *Arnold Rots <arots at cfa.harvard.edu>
> *Cc: *"Dempsey, James (IM&T, Black Mountain)" <James.Dempsey at csiro.au>,
> Alberto Micol <amicol at eso.org>, "dal at ivoa.net" <dal at ivoa.net>
> *Subject: *Re: ObsCore for velocity cubes
>
>
>
> This email was sent from outside of ESO from the address *[andreas.wicenec at uwa.edu.au
> <andreas.wicenec at uwa.edu.au>]*. If it looks suspicious, please report it
> to phishing at eso.org.
>
>
>
>
>
> Yes!!
> ------------------------------
>
> *From:* Arnold Rots <arots at cfa.harvard.edu>
> *Sent:* Thursday, 16 February 2023 11:25 PM
> *To:* Andreas Wicenec <andreas.wicenec at uwa.edu.au>
> *Cc:* Dempsey, James (IM&T, Black Mountain) <James.Dempsey at csiro.au>;
> Alberto Casa Micol <amicol at eso.org>; dal at ivoa.net <dal at ivoa.net>
> *Subject:* Re: ObsCore for velocity cubes
>
>
>
> FWIW, this all would have been simpler if the redshift and spectral
> coordinates has been retained in the coordinate system model.
>
> Just an observation...
>
>
>
> *Arnold H Rots*
>
> *Research Associate*
>
> SAO/HEAD
>
> *Center for Astrophysics | Harvard & Smithsonian*
>
>
>
> Email: arots at cfa.harvard.edu
>
> Office: +1 617 496 7701 | Cell: +1 617 721 6756
>
> 60 Garden Street | MS 69 | Cambridge, MA 02138 | USA
>
>
>
> [image: Image removed by sender.]
>
> [image: Image removed by sender.]
>
>
>
> cfa.harvard.edu
> <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcfa.harvard.edu%2F&data=05%7C01%7Candreas.wicenec%40uwa.edu.au%7Cb342f379f0f64735d21908db103213a7%7C05894af0cb2846d8871674cdb46e2226%7C0%7C0%7C638121579495614236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UW2lEbcfP9f3gv1c1xV3meUYWrQec2JCNG2fe9uEfAg%3D&reserved=0>
> | Facebook
> <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcfa.harvard.edu%2Ffacebook&data=05%7C01%7Candreas.wicenec%40uwa.edu.au%7Cb342f379f0f64735d21908db103213a7%7C05894af0cb2846d8871674cdb46e2226%7C0%7C0%7C638121579495614236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=x2Nmx22SVOakHhVQG9oYc8m0X2UKXah69AjFPCbhbCM%3D&reserved=0>
> | Twitter
> <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcfa.harvard.edu%2Ftwitter&data=05%7C01%7Candreas.wicenec%40uwa.edu.au%7Cb342f379f0f64735d21908db103213a7%7C05894af0cb2846d8871674cdb46e2226%7C0%7C0%7C638121579495614236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=WrFu2L5Q0%2BDGrHVGFxBWWBIBUiDCs2qXrYTCNFid6AU%3D&reserved=0>
> | YouTube
> <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcfa.harvard.edu%2Fyoutube&data=05%7C01%7Candreas.wicenec%40uwa.edu.au%7Cb342f379f0f64735d21908db103213a7%7C05894af0cb2846d8871674cdb46e2226%7C0%7C0%7C638121579495614236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BGr1ESnrr9uVY4jgT929NKU%2FIg8mdKMX8RR45Tui%2BG0%3D&reserved=0>
> | Newsletter
> <https://aus01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcfa.harvard.edu%2Fnewsletter&data=05%7C01%7Candreas.wicenec%40uwa.edu.au%7Cb342f379f0f64735d21908db103213a7%7C05894af0cb2846d8871674cdb46e2226%7C0%7C0%7C638121579495614236%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=S7%2BSKMZJT%2BsnqkRzVqZ8FBYWYXa0oaYTkPiVnOqKe5o%3D&reserved=0>
>
>
>
>
>
> On Wed, Feb 15, 2023 at 9:10 PM Andreas Wicenec <
> andreas.wicenec at uwa.edu.au> wrote:
>
> Hi James,
>
>
>
> that is a good suggestion. The usage of velocity vs. frequency is mostly
> use case/user driven. The original measurements are in frequency and in
> some cases the conversion from one to the other is not straight forward,
> again mostly dependent on the use case, in which case we end up having
> 'pure' velocity cubes. Thus encoding both might work for some, but not for
> others. The other thing to consider is the rest-frame, since quite often
> these velocity cubes are used for studies of local dynamic effects, like
> galaxy rotation curves, in which case the zero point is set to some
> estimate of the galaxies cosmological velocity (RESTFREQa). Now, obviously
> all of this is limited to just radial velocities, while in fact we are
> dealing with velocity vectors. To cover that we are using proper motion and
> parallax to describe apparent and intrinsic velocity on the sphere and in
> addition line-of-sight velocity to capture the intrinsic and apparent
> radial movement. Taken together, we end up in a set of vectors and probably
> frames. For a naive user the proposed description is probably sufficient,
> for actual scientific use of multiple of such cubes, quite a bit more
> information is required. Thus probably just a good start....
>
>
>
> Cheers,
>
> Andreas
> ------------------------------
>
> *From:* dal <dal-bounces at ivoa.net> on behalf of Dempsey, James (IM&T,
> Black Mountain) <James.Dempsey at csiro.au>
> *Sent:* Thursday, 16 February 2023 7:20 AM
> *To:* Alberto Casa Micol <amicol at eso.org>; dal at ivoa.net <dal at ivoa.net>
> *Subject:* Re: ObsCore for velocity cubes
>
>
>
> Hi Alberto,
>
>
>
> At CASDA we support cutouts of velocity spectral line cubes.
>
>
>
> 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!
>
>
>
> 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).
>
>    - v_resolution – value of CDELT3 or CDELT4
>    - v_unit – although this should always be m/s
>
>
>
> 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.
>
>
>
> Cheers,
>
> *James Dempsey*
>
> Senior Developer  |  CSIRO
>
> james.dempsey at csiro.au  |  02 6214 2912
>
>
>
>
>
> *From: *dal <dal-bounces at ivoa.net> on behalf of alberto micol <
> amicol.ivoa at googlemail.com>
> *Date: *Thursday, 16 February 2023 at 12:02 am
> *To: *dal at ivoa.net <dal at ivoa.net>
> *Subject: *ObsCore for velocity cubes
>
> Dear ObsCorers,
>
>
>
> I have received with much interest the ObsCore extension for RADIO data,
> thanks for that very clear document.
>
>
>
> Would it be possible to have a similar extension for cubes with velocity
> as third axis (the other two being the usual spatial ones)?
>
> Let me call them “velocity cubes”...
>
>
>
> Here my use case…
>
>
>
> At ESO we need to support cutouts of velocity cubes.
>
>
>
> Up to now our SODA interface supported spectra, images, and wavelength
> cubes;
>
> to provide the user with the SODA input parameters and their possible
> MIN/MAX values
>
> we query ivoa.ObsCore.
>
>
>
> Now with the introduction of velocity cubes, we would like to get the
> necessary SODA input params also from ObsCore.
>
> We can certainly do so by extending our own ObsCore table (ObsCore allows
> to extend the table), but I was wondering
>
> if others have similar needs, and see if we can agree with a common
> ObsCore extension.
>
>
>
> Velocity cubes should come in a FITS format as described by Greisen et al,
> 2006, so-called Paper 3.
>
> Shortly summarised, the velocity can be either:
>
>
>    - a radio (VRAD),
>       - an optical (VOPT),
>       - a relativistic velocity (ZOPT),
>       - a generic apparent velocity (VELO).
>
> The RESTFRQa (RESTWAVa) keyword conveys the necessary reference frequency
> (wavelength) to transform velocity into frequency or wavelength.
>
> The velocity unit is m/s.
>
>
>
> SODA cutouts on the velocity axis are usually formulated by passing cuts
> already expressed in velocity
>
> though it must be possible to perform the conversions to and from
> frequency/wavelength.
>
>
>
> What would then be needed in ObsCore is:
>
>
>
> v_min
>
> v_max
>
>
>
> but also, in case of radio velocity cube:
>
> f_min
>
> f_max (getting these from the RADIO extension)
>
> f_rest = RESTFRQ
>
>
>
> and, in case of a optical or relativistic velocity cube
>
> em_rest = RESTWAV
>
> (we already have em_min, em_max)
>
>
>
> The em_resolv_power should then be set to:
>
>  lambda                    freq                     c
>
>  ———————  =  ————— = —————
>
>  delta lambda           delta freq       2 * delta_v
>
>
>
> where delta_v is the CD3_3 in the cube (in the example of a cube with the
> velocity on the third axis);
>
> but I would also likely accept a v_pixel_scale (= delta_v).
>
>
>
> The UCD for the velocity should then be:
>
> spect.dopplerVeloc.opt
>
> spect.dopplerVeloc.radio
>
> unsure what it should be for the relativistic case.
>
>
>
> This would allow us at ESO to implement SODA on top of ObsCore (as already
> done for all other parameters)
>
> and would allow astronomer to search the velocity cubes with certain
> characteristics using ObsCore.
>
>
>
> What do you think?
>
> Is that doable? I think at ESO we will simply start implementing the above
> extra ObsCore parameters (unless you suggest different names for that),
>
> while waiting to see if there is more interest to build a proper standard.
>
>
>
> Eager to know what you think,
>
> Cheers,
>
> Alberto
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20230221/37d89268/attachment-0001.htm>