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