Handling data cubes in VO

[Anita Richards]

On Mon, 26 Dec 2005, Arnold Rots wrote:

> Access to 3-D cubes requires a single generalized interface.
> Otherwise you are going to (a) confuse the users and (b) fail to cover
> some cases.
>
> The access model is simply: everything - full cube, cut-out cube
> (including those with only one pixel along one or more axes),
> all possible transpositions, 2-D slices along any plane in three
> dimensions, 1-D slices along any curve in 3 dimensions.
>
> Believe me, they are all needed.

Happy 2006!

Arnold is right - but so are later contributors pointing out that >3 axes 
may be needed.  We very strongly need to keep standards generalisable 
(e.g. not too bogged down in the details of IFUs*), but we have to get a 
basic working model which can be tested against tools which astronomers 
can actually use - not try and do evreything at once.

I would suggest cocentrating on describing 'science-ready' data, or at 
least data where there are VO-enabled tools not only to display data, but 
also if possible to make measurements and/or apply calibration (if not 
already done) and extract commonly needed products.  Or rather, in some 
cases, where a standard data model will facilitiate deveoping such a tool. 
For example, allowing the  the Aladin-based slice tool to convert between 
frequency, velocity and wavelength or adjust velocities to different 
origins if there is more than one species in a cube.

Then we can move to more complex cases.  Arnold's first statement is a 
very laudable goal which we should move towards, but if we try and cover 
every eventuality  before we release aything we will never finish (and 
produce something no-one wants, if it hasn;t been tested on real users).
So for once I agree with Roy, who said:
> I guess I would want to keep things as simple as possible, get a solid 
> implementation and users, and only add sophistication when a real 
> genuine use case -- or two or three -- scream their heads off and demand 
> more complexity. That's just how I would do it.

Having just seen Doug's summary, I am now wondering if we are talking more 
about data discovery, or manipulation? Of course, they are not totally 
separate - a tool which allows a qhick non-quantitative look at the data 
is useful to help decide whether to download a Gb FITS file... but we must 
not lose sight of the VO goal to use standard models to allow data 
discovery and manipulation to be integrated into workflows.

Datacubes (and higher dimensions) also highlight one of the bees in my 
bonnet - in many cases, even for science-ready data, specialised software 
will be best for manipulation - both due to the size of the cubes and the 
range of ways to handle data.  Hence, as well as data discovery, we may 
need software discovery - i.e., the user does not just need to find a cube 
to download or view in a standard browser tool, but also to find software 
to translate 'show linear polarization vectors' into 'if radio take arctan 
U/Q ...' or whatever the equivalents are for other domains.  This is quite 
possible, but not much discussed.



All the best

Anita


*As I understand it,  Integral Field Unit data are recorded as single CCD 
frames, but contain small stripes for each source representing a spectral 
spread?