Charac Answer

Thu Sep 1 11:18:41 PDT 2005

Just a few comments from STC perspective.
STC distinguishes between velocity, redshift, and spectral axes.
Velocity is part of the spatial frame (literally the time derivative
of position) and would be used where a true velocity is measured, for
instance in ephemerides or theoretical data.
Redshift covers redshift as well as Doppler velocity, i.e., where a
quantity with a kinematic notion is derived from the spectral axis,
using a specific formalism.
Spectral is just that.

It's unlikely to have velocity and redshift in the same coordinate
system, but redshift and spectral are quite feasible.  In fact, I would
always recommend to have a spectral axis, even if it had only a single
pixel, to store the rest frequency; obviously, that axis will have
multiple pixels if data from different spectral lines are combined in
a single n-dim image or visibility set.

The exchange on channel width and spacing illustrates that resolution
and pixelsize always need to be specified separately.

It may sound strange, but ObservatoryLocation is actually part of the
coverage.  I'll grant you that it makes no difference for
far-field objects, but it is essential for doing research on
near-field objects in far-field observations and vice-versa -
especially if you have a spacecraft that goes regularly a third of the
distance to the moon.
In addition, the ObservatoryLocation (and particularly its
time-derivative) is essential for redshift and spectral analysis.
Coverage pertains to all coordinate axes.

  - Arnold

Anita Richards wrote:
> 
> >> 
> >> Axes
> >> What is 'cinematic' - is this the temporal+spatial analogy of a
> >> spectral+spatial data cube?
> >> 
> > 
> > No, no ; for us kinematic was just the velocity axis.
> 
> Ah!  Because to Brits cinematic with a c is like cinema!  Now I understand. 
> thanks.
> 
> So my comment about not having a velocity axis and needing one is wrong 
> anyway.
> 
> > We are aware that "spectral transition" and "radial velocity"
> > information are mixed on the wavelength axis. Probably we had in mind
> > simple cases where the relationship between  lambda and the velocity is
> > simple and unique  (single emission line for example). The overlapping
> > case you are adressing is "strange" because one single data dimension
> > (the "spectrum") is described by two independant axis: wavelength and
> > velocity. But if you present this kind of data as a velocity spectrum,
> > how much do you need ? one per spectral structure ?
> 
> In the first example I can think of, yes, but I would welcome input from other 
> regimes...
> 
> >     We also remember that Jonathan was in defavour of having two
> > different axes. Jonathan, could you argument that?
> ....
> >    Ok, we agree. BTW Are the channel width and channel spacing the same
> > with  Visibility data?
> 
> The minimum available is determined by what is in the visibility data but you 
> can average together an arbitrary No of channels, e.g. if you start with a 
> visibility data set with 240 good channels you can squash them all together for 
> a continuum image; you can squash together every 3 for an 80-channel cube, you 
> can make an unsquashed 240 channels ube (and you can apply spectral smoothing 
> so that yu end up with e.g. 240 channels with a separation of 1 kHz but an 
> effective FWHM of 1.4 kHz...)
> 
> > 
> >> 3.1
> ....
> >> etc. etc.) in enough detail for extraction and processing.  As far as
> >> I can see some of the top layers of the Characterisation model could
> >> map to the Registry model but I would like to see this done explicitly
> >> with cut-offs.
> >    We do not totally catch you here, what is "cut-off" for here?
> 
> Sorry, I am not entirely sure what I meant either but I think what I meant was 
> that the Registry shuold be kept simple, so the finer-grained detail from 
> Characterisation is not necessary for the registry - but where they desribe the 
> same concepts theys should be consistent.
> > 
> >    Well: that's a tricky point:
> >     1) Registry RM is dealing with "Resources"
> > and Characterization with individual (but also collections of) DataSets.
> >    This may intersect in some cases, but generally not: not all
> > Observations or even collections will gain a "Resource" status.
> >     2) Characterization is layered while Registry  RM is not.
> >     Anyway that would have been nice if Characterization level 1 and RM
> > could have shared the same formalism. Historically it was not possible, but
> > a mapping should be done. The actual values will differ of course.
> > 
> >> I also think that we should see VOs in general and Characterisation in
> >> particular as being mainly aimed at providing data which will be
> >> passed between other VO tools.  Thus 'Characterisation ... is necesary
> >> .. but not sufficient .. also requires details of observing...'
> >> worries me.  In many cases I hope that the Characterisation model will
> >> be sufficient because we should be encouraging data providers to
> >> supply data with instrumetal signatures already removed, so that other
> >> VO tools can tackle the images etc.  Observational details should be
> >> provided as part of giving the data a history, and we do already have
> >> that in the Observation DM, but they are only directly relevant to
> >> Characterisation if we have tools to use them (e.g. a special tool to
> >> convert Chandra counts or 2MASS magnitudes to physical units).
> > 
> >   Hmmm! Does VO have to be a data "police" ? What about "old data"? What
> > about reprocessing of raw data? Potential use of the data is different
> > according to the level of available description. Eg: Uncalibrated spectra
> > are usefull to study line ratio in the same spectral domain, no ?
> 
> I agree entirely and as you know I am very against data police... just that we 
> should reword the emphasis - e.g. 'Characterisation should be sufficient to 
> allow the user to do science directly (e.g. using other VO tools) on 
> well-calibrated data.  For data which requires further instrument-specific 
> reduction, the data model should also give a pointer to the origin of the data 
> or other sources of necessary information'.  I still want to _encourage_ people 
> who work in non-physical units to provide a translation, but not to _force_ 
> them to.  One of the biggest problems which has come up in almost every science 
> case I have worked with users on, is needed to convert optical or IR magnitudes 
> to physical units.  In some cases the conversion is well-known (to an accuracy 
> of <1 - few %) but often also well-hidden.
> 
> Actually your last example about uncalibrated spectra sort of supports my point 
> because in order to measure a line ratio, you don't need flux calibration - so 
> the spectrum might be immediately tractable in e.g. SpecView, which can 
> subtract a baseline and measure a ratio...
> 
> > 
> >> Fig. 2
> >> 
> >> I was amused to see Observatory Location under Coverage_SPATIAL
> 
> > This class comes from the re-use of the STC classes for coordinates.
> > it appears in the diagram because we show the STC subclasses , and not
> > one big STC blackbox.
> > Is this misleading?
> Um, it confused me but maybe that is just me!
> 
> I agree with your other points.
> 
> Anita
> 
--------------------------------------------------------------------------
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/
--------------------------------------------------------------------------