call for presentations at the Data Model sessions in Cambridge , September 2007

[Doug Tody]

Hi -

Another point which I should probably mention - the 2nd generation
DAL interfaces - SSA, SIAV2, etc. are actually based upon WMS
(see the acknowledgements section of the SSA V1.0 spec).  But,
they actually work for quantitative discovery and analysis of
astronomical data, unlike WMS.  With the addition of support for
astronomical projections and graphics overlays WMS could be useful
for visualization of astronomical data, but it is not remotely suited
for serious quantitative analysis.

	- Doug


On Tue, 22 Jan 2008, Doug Tody wrote:

> 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

"could" 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.
> 
> 	- Doug