Web Access to NASA's Remote Sensing Data through GeoHarness *

The GeoScope Project

To best serve the needs of non-traditional end-users of geospatial data outside of NASA's community of scientists and researchers, e.g., Geographic Information Systems (GIS) practitioners in state and local government, a solution should be flexible enough to:

1. support a variety of metadata schema and data models, and
2. support federating widely distributed and heterogeneous metadata catalogs.

In our earlier work [6] [7], we have discussed InfoHarness, a system that supports off-line generation of metadata entities to encapsulate heterogeneous raw data, and run-time use of these entities to support search and presentation of encapsulated data. But searches of remote sensing imagery and other geospatial data also require support for complex content-descriptive metadata in the form of heterogeneous hierarchical attributes, as in the FGDC metadata content standard [3]. Moreover, the data encapsulation process has to be designed to incorporate previously defined content-descriptive metadata.

In this position paper, we present a brief summary of GeoHarness, a prototype extension of InfoHarness that is capable of supporting multiple heterogeneous metadata schemas and serving as a basis for federating metadata catalogs. GeoHarness is being used to implement the GeoScope catalog server, which is a major component of the GeoScope architecture [4]. The in-memory implementation of GeoHarness is currently available, a scalable version based on a commercial OODBMS will be available in the first half of 1996.

The GeoScope work is being performed for NASA by the Universal Spatial Data Access Consortium (USDAC) under a three-year, $2.3M Cooperative Agreement. Members of the USDAC include Bellcore, Camber Corporation, California Resource Agency, the Open GIS Consortium, Rutgers University's Center for Remote Sensing and Spatial Analysis, and NASA's Space Science Data Operations Office.

Fig. 1. GeoHarness Architecture.

GeoHarness Architecture

1. GeoHarness Server (GH Server), which uses metadata to traverse, search, and retrieve the original information.
2. HTTP Gateway, which is used to pass requests from HTTP clients to the GH Server and responses back to the clients.
3. Metadata Generator, which is used for off-line generation of metadata that represents the desirable view on the structure and organization of the original information. This metadata is used by the server for run-time search and retrieval.

At run-time, HTTP clients may issue query, traversal, or retrieval requests that are passed on to the gateway, which performs the following operations:

1. Parses the request, and reads input information when the request is associated with an HTML form.
2. Establishes a socket connection with the GH Server, generates and sends out a request, and waits for a response.
3. Parses the response, converts it to a combination of HTML forms and hyperlinks, adds the HTTP header, and passes the transformed response to an HTTP browser.

The system addresses the goals of scalability and interoperability in a large and geographically distributed environment by supporting multiple servers and multiple clients, and by decentralizing the administration of information repositories.

Object Model

GeoHarness Attributes

1. Numerical, textual, or binary items (or item) that in some way describe the encapsulated primary data.
2. A function of other attributes.
3. A set of references to other attributes, each of which describes the encapsulation unit.
4. An encapsulation unit whose content satisfies condition 1.

Consider the example in fig. 2, where all attributes describe the same encapsulation unit the content of which is a Digital Elevation Model (DEM) for some area. Here, the areal extent of the DEM is represented as a Bounding Box, whose value is assigned a set of numeric latitude/longitude coordinates. The Bounding Box satisfies condition 2 and the numeric coordinates satisfy condition 1 of the above definition. The Thumbnail Image attribute meets condition 3 of the definition because its value is an encapsulation unit, the content of which is a thumbnail image of the DEM.

Fig. 2. Sample Geospatial Attributes in GeoHarness.

We say that a set of attributes is a meta-description of an encapsulation unit if the following two conditions hold:

• Each of the member attributes describes this unit.
• All available attributes that describe this unit are members of the set.

GeoHarness Objects

1. A simple object, composed of a single encapsulation unit (e.g., a Landsat MSS image) and its meta-description (e.g., an attribute dictionary together with the image header information, and a browse product for this image).
2. A composite object that combines a simple object (such as the one above) and a set of references to other GeoHarness objects (e.g., encapsulation unit and meta-description for the Landsat Data User's Handbook together with references to encapsulated sections from this guide).
3. A collection object, composed of a set of references to other GeoHarness objects (its children) and a (possibly empty) set of references to independent indices.

Each object has a unique identifier that is recognized and maintained by the GeoScope catalog server. Simple and composite objects store the location of raw data, the logical address of the encapsulated portion of this data, and typing information that determines the data retrieval method. For example, an object that encapsulates a feature in a USGS Digital Line Graph might be assigned the presentation type SDTS and contain path information for the file and the name of the feature. Here, type serves as an implicit reference to a presentation method that would first separate out a vector feature layer, then convert it to gif and forward it to a browser.

Collection objects may contain references to multiple independent indices that in turn reference children of the collection. Each indexed collection stores sources and locations of index-related data structures, and references to associated query methods. Consequently, any indexed collection may make use of data retrieval methods that are not parts of GeoHarness. As a result, GeoHarness repositories may utilize existing heterogeneous index structures.

Any collection or composite object in a repository may contain references to objects that encapsulate entry points of other repositories. Their encapsulation information determines translations, conversions, etc. that may be necessary to support the retrieval from non-GeoHarness repositories. We are planning to support federations of possibly heterogeneous catalog servers later in this project.

Current Work

References

Footnotes

*

This work is a part of the GeoScope project and is supported by the NASA Cooperative Agreement NCC5-102.

TM

InfoHarness is a trademark of Bell Communications Research, Inc.

---

---