ObsCore for velocity cubes

[BONNAREL FRANCOIS]

Dear Alberto, all,

     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.
     This discussion was mainly in 2014/2015. See for example these 
threads starting by 
http://mail.ivoa.net/pipermail/dm/2015-April/005147.html and 
http://mail.ivoa.net/pipermail/dm/2015-April/005168.html as well as 
http://mail.ivoa.net/pipermail/dm/2015-May/005174.html

       The conclusion at that time was that we didn't have to extend 
ObsCore this way eventually.
       For several reasons.
        - 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.
       - 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
         -  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 ?
         ---> ObsCore will become really complex to manage and fill in 
these situations

         Considering your use case Alberto, I think we have two 
distinguish two steps
             - 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"

              - 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.
                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.

Cheers
François


  1Le 22/02/2023 à 11:33, alberto micol a écrit :
> Very well, thanks both Markus and Pat.
>
> So, yes, we need a v_resolution, and it must be in fixed units.
> Taking the Greisen et al. default, this is [m/s].
>
> We though need the fravergy UCD to be able to discriminate the 
> different velocity flavours.
> Is em_ucd the correct field to use?
> (Yes, I’m hit strongly by the confusion of throwing untested features 
> from a data model into a relational mapping,
> that’s why I need your confirmation on this)
>
> Thanks!
> Alberto
>
>
>> On 21 Feb 2023, at 21:11, Alberto Micol <amicol at eso.org> wrote:
>>
>> Hi James,
>> Thanks for the answer. I have a question/doubt regarding the 
>> v_resolution and v_unit.
>> ObsCore already foresees the em_resolution, so I originally thought 
>> we do not need the v_resolution.
>> 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.
>> If the above is correct, then, yes, we need to have a new field,
>> v_resolution, with units fixed to e.g. m/s,
>> similarly to the case of em_min/max always provided in [m], whatever 
>> the value of the em_unit, to support searches.
>> 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.
>> Would that make sense?
>> Regarding treating frequency cubes as velocity cubes (and viceversa),
>> it is indeed useful to provide characterisations both in frequency 
>> and in velocity
>> (and why not energy and wavelength), distinguishing the different 
>> cases according to
>> the value of the em_ucd, e.g., em.freq, em.wl, em.energy (see ObsCore 
>> B.6.2), or
>> spect.dopplerVeloc.radio, spect.dopplerVeloc.opt, spect.dopplerVeloc.rel 
>> (*) (see ObsCore B.6.2.6).
>> So we would have:
>> em_ucd required
>> v_resolution required, fixed in m/s
>> em_unit optional, expressing the unit encoded in the cube for the 
>> spectral axis
>> em_resolution optional, expressing the resolution in the units used 
>> by the data cube
>> If we converge on this, I could put together a little document with a 
>> detailed proposal.
>> Would that considered useful?
>> Cheers,
>> Alberto
>> (*) cross-standard issue: the spect.dopplerVeloc.rel is mentioned in 
>> the ObsCore standard,
>> but it is not a recognised value in the current UCD1+ standard.
>> We will need to act on this (Mireille?).
>> *From:*"Dempsey, James (IM&T, Black Mountain)" <James.Dempsey at csiro.au>
>> *Date:*Thursday, 16 February 2023 at 00:21
>> *To:*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*[prvs=40330730a=James.Dempsey at csiro.au]*. If it looks 
>> suspicious, please report it tophishing at eso.org.
>>
>> 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 <mailto: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:
>>
>>       o a radio (VRAD),
>>       o an optical (VOPT),
>>       o a relativistic velocity (ZOPT),
>>       o 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/20230222/d63c7d4b/attachment-0001.htm>