-- FrancoisBonnarel 15 mar 2011

Use case 3.2 and 3.4 directly include constraints in radial velocities. It is a typical feature of some radio or interferometry cubes observing a single line to give measurements of fluxes for a given spatio-radvel coordinate or spatio-redshift coordinate.

Discussion in Nara initiated by Arnold and Igor showed that most people consider the RadVel axis to be different from the spectral axis. The argument being that we are facing two non permutable quantities as long as we are not considering a single , isolated spectral line.

Upcoming version 2 of characterisation DM will add a new RadVel or Doppler axis. It would be perfectly possible to add a couple of optional fields allowing to search against "radial Velocity" bounds and resolution...

This is the minimum required to fulfill the use cases 3.2 and 3.4.

-- JuanDeDiosSantanderVela - 16 Mar 2011

In order to make a concrete proposal, I would propose the following fields:

  • vel_min: Minimum value of the line-of-sight velocity. Positive values indicate receding velocity.
    • Mandatory: NO.
    • datatype: adql:DOUBLE
    • Can be NULL: YES
    • UCD: phys.veloc;stat.min
    • Unit: m/s
    • UType: to be discussed; could be Char.VelocityAxis.Coverage.Bounds.Limits.Interval.LowLim

  • vel_max: Maximum value of the line-of-sight velocity. Positive values indicate receding velocity.
    • Mandatory: NO.
    • datatype: adql:DOUBLE
    • Can be NULL: YES
    • UCD: phys.veloc;stat.max
    • Unit: m/s
    • UType: to be discussed; could be Char.VelocityAxis.Coverage.Bounds.Limits.Interval.HiLim

  • vel_resolution: Velocity difference average or reference bin size.
    • Mandatory: NO.
    • datatype: adql:DOUBLE
    • Can be NULL: YES
    • UCD: phys.veloc; spect.resolution
    • Unit: m/s per bin
    • UType: to be discussed; could be Char.VelocityAxis.Coverage.Resolution.refVal

I do not like the term Radial Velocity, as it implicates a geometry in the object. Line-of-sight velocity (or plain Velocity, as in the proposal) seems better and cleaner to me.

Use Case 3.2

Show me a list of all data that satisfies:

  1. DataType=Cube with 3 dimensions (see discussion on DataProduct)
  2. Axes includes Velocity
  3. Axes includes RA
  4. Axes includes DEC
  5. Velocity Resolution better than 50 km/s
  6. RA includes 16.000
  7. Dec includes +41.000

An approximation might be:

select * from ivoa.obscore where dataproduct_type = 'image-spectrum' and vel_resolution < 50000 and (contains(s_region,point('ICRS',16,+41)) = 1 or distance(point(s_ra,s_dec),point(16,+41)) < s_fov )

Condition 1 is dealt with by dataproduct_type field; condition 2 is dealt with by the fact that NULL vel_resolution fields will not contribute to the comparison; conditions 3 and 4 are taken care of at the same time as 6 and 7, by the contains or distance. The contains or distance is used to allow for services with non-precise regions, but that they still might have a chance of including the point.

Use Case 3.4

  1. DataType=Cube with 3 dimensions
  2. Axes includes FREQ
  3. Axes includes RA
  4. Axes includes DEC
  5. Velocity Resolution better than 1 km/s
  6. RA includes 83.835000.
  7. Dec includes -5.014722.
  8. Rest Frequency = 345.795990 GHz
  9. VLSRK in the range [6.0, 10.0] Km/s

An approximation might be:

select * from ivoa.obscore where dataproduct_type = 'image-spectrum' and vel_resolution < 1000 and vel_min < 6000 and vel_max > 10000 and em_min < 299792458/345.795990e9 and em_max > 299792458/345.795990e9 and (contains(s_region,point('ICRS', 83.835000,-5.014722)) = 1 or distance(point(s_ra,s_dec),point(83.835000,-5.014722)) < s_fov )

Could anyone please check that the query indeed corresponds to the use case? Best regards!

-- FrancoisBonnarel 16 mar 2011 Very good and accurate definition of these new optional fiel ds , Juande. Use case 3.4 proposed ADQL query looks fine.

I note that there is nothing here that indicates what Doppler velocity definition is being used - radio or optical (these being the common ones). That's needed. And let's keep the units in km/s.

-- ArnoldRots - 18 Mar 2011

You're indeed right, Arnold, but for ObsTAP I would go and mandate the optical definition. Even radio observatories are standardizing on that, such as the IRAM and, if I recall correctly, ALMA. Re: units for the doppler velocity, I went to m/s to mimic other units that we have, but km/s would be handy. We just have to stick to one. In the future we are going to be able do deliver m/s resolutions, so I think we should go for m/s.

-- JuanDeDiosSantanderVela - 21 Mar 2011

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2011-03-21 - JuanDeDiosSantanderVela
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback