 |
OASIS contains a fairly complete suite of functionality for viewing and manipulating images, source catalogs (as tables and as overlays), sky drawings (e.g., contour plots), and XY plots (e.g., spectra, light curves, scatter plots). It has custom interfaces for accessing specific archives (images from various sources, catalogs from IRSA and CDS VizieR). OASIS runs as a JAVA applet/application and when running as an applet has specialized interfaces for interacting with browser forms. In this mode it relies on the JAVA 1.3 (or later) plug-in and has been tested on Solaris, LINUX and Windows using Netscape, Mozilla, and IE. It has also been successfully used on the latest version of Mac OS X (10.2) but not fully tested.
For more information on the complete suite of OASIS GIS functionality the reader is directed to the OASIS web site available through IRSA. The remainder of this paper is primarily aimed at service/data providers and describes the ways in which OASIS can be used to augment or interact with other systems.
OASIS has been optimized for access to distributed archives and data sets. However, rather than build an ever-increasing suite of custom interfaces to remote archives, the OASIS remote access model is based on the idea of allowing data and service providers to control the flow of data to OASIS. In this way, the range of data services available in association with OASIS can grow organically without IRSA's direct involvement and future OASIS development can be focussed on better data visualization and data fusion functionality.
This architectural difference can best be appreciated from the data provider point of view. By ``data provider'' we include everyone from the builder of an extensive archive system to the astronomer who simply wants to include an image, interactive plot, or data table reference on a web page. For example, a data provider who creates a query form to an archive containing a collection of data can direct the result files from the query into OASIS where it can be either viewed on its own or in conjunction with data from other sources.
This kind of interaction is possible because all OASIS data links feed into a single copy of OASIS on the client machine. In this way any data or service provider is given access to the full suite of capabilities in OASIS and the ability to include all other available datasets by reference from his web page.
As an example, Davy Kirkpatrick has included OASIS references to plot his collection of known L dwarf stars in the solar vicinity. Other examples of this third-party access feature include queries involving the high-energy image datasets accessible from GSFC SkyView, links to image data that are returned from a target-based query to the NASA Extragalactic Database (NED), and AAVSO light curves.
OASIS has been designed to serve as a presentation and data fusion tool that can be used in conjunction with existing data services. Images, source lists, etc. that are kept on-line (or even just local files) can be displayed using OASIS just by adding an extra HTML link on any web page that references them. If a service provider has data services that produce such files dynamically, these can be handled the same way. Finally, with minor adjustments an existing form interface can be modified to use attributes of the current image, etc. being displayed by OASIS (e.g., image center and size) as initialization parameters for a service. In this section, we will describe in more detail how this can be accomplished.
By far the most common OASIS link is for the purposes of displaying a data file. For example, suppose a data supplier has an image orion.fits that they wish to display. Currently, they would create a link to it on some web page which would tell the Browser to retrieve the file:
<a href="http://a.server.edu/images/orion.fits">Orion image</a>
If the browser has been told which application can handle this file, it will fire up a copy.
For an OASIS link, we use an extra level of indirection where the reference is handed off to OASIS (which is started automatically by the Browser if necessary) and OASIS retrieves the data and adds it to the current display. In this way, a whole data collection (image, catalog overlays, contours, etc.) can be fused in a single client instance of OASIS even if the data all come from different locations.
The above can be converted to an OASIS link simply by sending the existing URL to the OASIS proxy service:
<a href="http://irsa.ipac.caltech.edu/cgi-bin/OasisLink/
nph-oasislink?ref=http://server.dummy.edu/images/orion.fits">
Orion image</a>
To be safe, the `` ref'' parameter should be url-encoded. Multiple data references and references to services rather than static files can also be sent. The `` file://'' construct can also be used to work with local data.
OASIS links work by generating an extra (small) Browser page which contains an OASIS applet reference (for OASIS links to work, JavaScript must be active on the Browser). After a brief delay (longer if OASIS has not been loaded), the ``calling'' window returns to the original page, the new applet page (the small browser window) contacts or starts OASIS, and OASIS is given the data reference(s).
OASIS forwards all such references to its File Transfer Management toolkit and they appear as parallel threads in the File Transfer Manager GUI window (requests made through OASIS will be shown here as well). As data arrives it is stored in a cache (cleared every session) and added to the current display. Since different files (and services; see below) take different amounts of time, there is no guarantee in which order the data will arrive.
The proxy Browser window that is created dynamically in the above scenario contains a simple (if somewhat lengthy) standard plug-in applet reference. Such references can be hardcoded onto any page. This has the advantages that the process does not then need to go through the OasisLink proxy generator, have JavaScript active, or have extra browser windows appear on the user's screen. It has the disadvantages that the service provider has to understand and accommodate the applet information construct and load OASIS when the page comes up (as opposed to it only coming up if a link is activated).
OASIS can also be used in conjunction with web pages containing HTML forms. Any form can be used; the only constraint being that the form must have an ID (standard but not required for HTML form tags). As in the previous section, an OASIS ``button'' is included on the page, only this time a base URL is given in the formurl parameter and OASIS interacts with the Browser to collect the form parameters and complete the URL (much as the Browser does when the HTML submit button is pushed). You can have multiple forms on the same page, each with its own ``OASIS submit'' button keyed to a specific `` formid''. See the online OASIS documentation on the IRSA web site for more details.
In addition to this, OASIS checks the form inputs on startup looking for specific names (such as `` oasisImCenter'' and `` oasisImRadius''). When OASIS finds one of these fields, it updates it with the current display value. In this way, OASIS can be used as an integral part of many processing scenarios.
In addition to ongoing efforts to augment OASIS' visualization and interaction functionality IRSA is currently involved in several projects relating to the National Virtual Observatory (NVO), including a request manager for long-running or more complex jobs and a data collection/inventory mechanism, and we expect OASIS to be one of the primary portals to this functionality.
OASIS was funded by the Science Applications of Information Technology Program at JPL.