about galaxy "velocity cubes"

[Arnold Rots]

It is unfortunate that Igor went off on his discourse on Doppler
velocities, angular, and linear spatial coordinates.
I believe it is a red herring and we should drop that subject; see
also my comments from yesterday.

Let me be clear on what STC says. In the Astronomical Coordinate
System it distinguishes 6 types of coordinate frames: Generic,
Temporal, Spatial, Spectral, Redshift, and Pixel.
Time, space, spectrum, and redshift are the important ones.
For documentation, see:
http://www.aspbooks.org/publications/382/393.pdf
and Section 2 of the STC standard.

Spatial deals with positions and *true* space velocities.
Spectral is used for SEDs, line identifications, equivalent widths, etc.
Its only frame parameter is the reference position.
Redshift represents the special transformation of a spectral
coordinate to redshift or Doppler velocity - an interpretation that is
fundamentally different from what I listed under "Spectral" and that
requires a different specification of the frame metadata. The
reference position is still required, of course, but in addition there
needs to be an indicator whether the quantity is redshift or Doppler
velocity, and what the definition is - optical, radio or "relativistic".
And it needs different units.
In addition, the spectral coordinates may hold the rest frequency or
wavelength. It should be emphasized that Doppler velocities are
formalisms, not (necessarily) true space velocities - though they are
often used that way.

So, if Characterisation is to be consistent with STC, it should make
te same distinction and recognize a Redshift axis; and in this I agree
with Francois.

Cheers,

  - Arnold

François Bonnarel wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> I think DM work has to be usefull for astronomers.
>    -  So, Igor if data providers have data with radial velocities on the 
> third axis and want to distribute like that, why should we oppose ?
>     - from the Char DM point of view, a specific  axis (time, position, 
> spectral etc ... )is always  a specialization of the generic time axis 
> by fixing:
>                 -name attribute value
>                 -ucd attribute value
>                 -unit attribute
>                 - use of STC coordinates class instances with 
> appropriate reference to STC coordsys instance
> So, Arnold, it was always the intent (and it's done actually) to reuse 
> STC where it is needed in Char
> DM. I think STC model Recom don't make Redshift (or any) coordinate 
> mandatory in the coordinate
> structure. So we have to add it if  and when we need it.
>                 - an last but not least, specific utype (TimeAxis, 
> SpectralAxis, etc ....) (- this actually from
> the model point of view is a role and from the xml serialisation pov an 
> element name).
>        In addition each "specific" axis may actually recover different 
> observables, units, and (usual) names
> Spectral axis eg can be (at the moment) in frequency, wavelength or 
> photon energy.
> 
>      I see two possible solutions if we want to describe a redshift 
> dimension :
>           solution 1 : add the velocity or redshift "flavor" to spectral 
> axis.
>              This will require that usual name is "redshift", ucd the 
> appropriate one, as well as unit and that
> we reuse the redshift coordinate structure from STC with appropriate  
> Coord system.
> 
>          solution 2: we define a new Redshift axis by adding a new 
> RedshiftAxis utype (or UML role, or xml
> element by type restriction) in  addition to the other attribute changes 
> described in solution 1.
> 
> My understanding is that most people here would prefer solution 2. the   
> main reason I guess is that
> frequency and redshift are equivalent representation only if we consider 
> a single line.
> 
> It's time to discuss this because the new version of characteriation 
> which will be presented tommorrow can include this change...
> 
> Why dont' we push this discussion to DM, Mireille ?
> 
> Cheers
> Fran?ois
> 
> Le 07/12/2010 16:54, Roy Williams a ?crit :
> > I agree with Adam. It should be clear to the radio astronomers a 
> > simple thing is sufficient. The only necessary metadata is 
> > labeling/describing the axes of the cube, and providing min and max 
> > values. The VO-supplied libraries should work with this simple 
> > information and the VO registry. An interoperable representation of 
> > the radio cubes in HDF5 or FITS would complete the picture, ways to 
> > subset the cubes, access protocols for cubes, etc.
> >
> > The next level -- after acceptance of the above by the community -- 
> > could allow computers to "understand" the meaning of the axes by 
> > allowing complex metadata (utypes, STC, Char, semantic linking, etc 
> > etc). Moving too fast on these advanced concepts could make the VO 
> > look out of touch with real scientists.
> >
> > I suggest that "full metadata characterization" is not interesting to 
> > 99% of scientists.
> >
> > Roy
> >
> >
> > On 12/07/2010 6:33 AM, Adam Brazier wrote:
> >> Yes indeed. The radio astronomers with whom I am working are excited
> >> about the prospect of their data cubes being easily and directly
> >> embeddable in VO protocols and any suggestion that they are "horribly
> >> wrong" or the like is going to be met with reactive hostility and a
> >> complete lack of compliance with whatever else we suggest.
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------