call for presentations at the Data Model sessions in Cambridge , September 2007
dtody at nrao.edu
Tue Jan 22 16:22:34 PST 2008
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
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
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.
More information about the dal