Date: 4/11/2000 Time: 3-5pm Place: Boardroom 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 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.