Title: Starview2/VTT Integration Kickoff Meeting
Attendees: Jeremy Jones, Anuradha Koratkar, Sandy Grovesnor,
           Tony Krueger, Steve Lubow, Megan Donohue, 
           Frank Tanner, Rob Douglas, Karla Peterson,
           Scott Binegar, Niall Gaffney
Date: 4/11/2000

AGENDA;
=======

- Introductions (everyone)

- Science Vision (Megan)

- Technical Discussion (Everyone)

GOALS;
======

I have two goals I'd like to achieve in this meeting
I know this may be hard to achieve, but lets see if we can 
achieve them.  

1) Can we come up with a phased approach to 
this integration such that we can get usable
tools in our Scientists hands as soon as its
reasonable.  The key here is that we don't have
to think of delivering a totally integrated final product,
but pieces of the end product over time.  We can also think
of releasing things as prototypes for evaluation and feedback.

2) I'd like to come up with some ideas of what functionality
could be put in the different phases and an estimation of the
amount of time to complete the phases.

I expect to have a Java experienced person available .5 starting 
in the 3rd wk of April, so if there are things we can do, I have some
resources that I can apply shortly.  If we don't start now, I may not
have resources to apply for some time (6-8 months), as they will
be applied to other tasks.  This is my reason for trying to push
us to try and answer my 2 goals.  It will help me decide when and
what to apply resources to.

SCIENCE VISION;
==============

DRAFT 3/28/2000

StarView II - Visual Target Tuner interaction

StarView II = StarView v6.0: 
	a Java application that allows users to search the current
	Hubble data archive, make HST data retrieval requests, duplication
	checking of archived and planned exposures etc.

	Right now there are
	two java graphic-based tools in StarView that uses the results of
	queries to the HDA: one displays 
	one overlay per DSS field (this is the tool that uses 
	something like JSky, which has
	a similar feel to the VTT), and a sort-of worthless "all sky"
	display, which displays every pointing in the query on an all-sky
	map - it was done as a proof-of-concept of java tool interactions.
	I say it's kind of worthless because there's not much scientific
	utility to it. But it does display the locations of 
	multiple pointings (not overlays), on a map too huge to be 
	interesting.


VTT:
 	a Java application that can retrieve a DSS image based on a
	coordinate center, overlay user-defined HST apertures and rotate
	them, overlay multiple apertues, read WCS coordinates, etc.

Here's how they might interact.

In StarView II, a user has completed a query of the HST catalog and 
	has before them a list of HST observations. They highlight (by
	shift-clicking, say) 5 HST exposures. Then they push the button
	labelled VTT (or Overlay, which is already a Java application
	called by StarView, but does not have all the VTT functions.)
	VTT pops up. The user selects a sensible group of exposures 
	(say, all the ones of a specific target).

	If the exposures are within 1 degree (or 15 arcminutes, or 
	whatever seems sensible) one DSS image that is big enough to
	accomodate all of the exposure's apertures is extracted, and 
	the apertures are overlaid. The user could select an aperture
	on the VTT, and the appropriate record would be highlighted
	and displayed in the StarView results area. 

	The user could then lay down their own apertures. 

 	One weakness of this case is that I haven't thought through how
	VTT might handle a situation where the user sends the metadata for
	multiple exposures to the VTT, but the exposures are really far
	apart -- on the sky, I mean. Maybe a dialog box pops up and says
	"the DSS image that contains all these pointings would be 20x30
	degrees, have 30 bjillion megabytes, and would take roughly 20
	hours to display. Are you sure you want all of these pointings
	displayed on one image?" Then when they click "Yes" we say 
	"Too bad." 

>From the VTT, the user may have been investigating a target already. They
	could select a point on the screen, or highlight an aperture and
	select "Duplication Check". The VTT pushes the coordinates and
	aperture description to SVII's Duplication Screen (so SVII comes
	up with the standard Duplication Screen already loaded and the
	correct coordinates and instrument already qualified.)

	Then the user could further qualify the search (say, by filter
	or by exposure or by date of observations or some such), and
	then execute the query. The results of the query would not only
	be listed in SVII, but the apertures of each exposure would be
	displayed (in a different color from user apertures) in the
	VTT screen. The user could then see all the HST observations
	done in a certain way.

The path from the VTT to StarViewII seems easier than vice versa to me
because of the multiple target complication by going from ANY StarViewII
query result to the VTT. But maybe this is something that could be 
worked so the user controlled such an action in an intuitive way.

I have an idea of what I'd like this interaction
to look like, and maybe some piece of it would be reasonably quick for us 
to bat out. Of course, any change to StarView or the VTT would be made
and prioritized in context with the other changes needed for the 
individual improvements to those tools. I'd like the conversation
to start, in order to begin to scope out how difficult this coordination
might be.

TECHNICAL DECISIONS;
====================

1) Put both the STARVIEW2 and APT(VTT) code in the same VM.
   This will be an initial attempt at hooking them up.
   There was discussion about the size of the application and
   the slowness of the application, but we decided to try an
   initial prototype in the same VM.

2) The Starview2/APT teams will work together to develop a Java
   interface between the two systems.  We estimated that it would
   take 3 FTE weeks of effort on both the Starview2 and APT sides
   to design and implement this interface.

3) There are some VTT Architecture and GUI changes that will be
   needed to support this effort.  Apertures will be handled
   a little differently than the current VTT handles them.  We
   will need to work out the requirements and design for this 
   task.  It was estimated this would take 4 FTE weeks.

4) There is some book keeping tasks needed in Starview2 to
   support this task.  It was estimated that this would take
   2 FTE weeks.

5) The Starview2 Team will change the Starview2 code and the
   APT team will change the APT code.  

6) Starview2 will be able to start working on design/interface
   issues in the mid-may timeframe and should be able to start
   coding in the early July 2000 timeframe.  Starview2 has a June
   30 release and will be concentrating their efforts on the
   release

7) APT will be able to start working on the this in the mid/late May 
   timeframe.

