On Tue, 22 Jan 2008, Alberto Conti wrote:
> > When it comes to graphics intensive visualization such as
> > gSky/WWT/Worldwind etc., this is a completely different problem.
> now it is, I believe the two approaches: data and intensive viz will
> converge.
Visualization is an important element of actual data analysis, but I don't think we are going to get to the point anytime soon where all data analysis involves graphics-intensive visualization. In particular we should represent science data in a generic way that can be used for any kind of (mainly quantitative) analysis.
That said, I think (and have said before) that these general non-astronomy specific graphics intensive client apps like gSky/WWT would eventually be important for remote data interaction and analysis. They may eventually become general graphics-oriented pluggable platforms which can be used as the basis for client-side visualization and interaction with data and services. In this case they would probably integrate with local and remote, mostly non-graphical, quantitative data analysis tools, rather than replace them. Of course sophisticated client apps like Aladin, WWT, etc. might directly integrate some actual data analysis capabilities, but this will never provide all that is needed for adhoc data analysis.
> > For this you need something like WMS which serves up uniform
> > multiresolution graphics-oriented (non science) pixel tiles
> > efficiently, plus a markup language for annotations like KML.
> Or perhaps a WMS that is for (science) pixels as well. Why not think about
> this?
What is the point? WMS involves heavy processing (interpolation, filtering, rendering) of the data onto a uniform grid, to make it well suited for efficient graphical display. Usually extensive preprocessing is required. It only works for heavily processed, survey type data. There is no concept of discrete science datasets, e.g., images. All the science-specific metadata required for scientific analysis is lost; there is no provision for providing this. For quantitative data analysis it is essential to be very careful about the data samples and associated metadata describing what they mean.
SIA includes some provisions for virtualizing the sky, e.g., one can generate data according to a client-specified position and projection, and this is a bit like WMS. But when SIA says "cutout" or "archival" it means that the original data samples are not modified. We need to carefully distinguish these cases, and provide precise metadata, for actual quantitative data analysis. This leads to a very different design than WMS, which is oriented toward graphical display.
An additional consideration is that we should bear in mind that many science users write their own software in any of a number of languages or environments, or support legacy software, or use a variety of existing software tools, which we want VO to support well. Hence support for widely used astronomy standards such as the table abstraction, FITS, FITS WCS, etc. will continue to be very important for the part of VO which supports direct interaction with science data by users. I think this is a much more important consideration for VO than support for advanced visualization, hence this is what should drive how we represent science data to client applications. We want to support advanced visualization, but that is secondary.