Return to GeoComputation 99 Index

Interoperable geospatial objects

Jonathan Doughty, Patrick Jones, James Nolan, Stephen Hirsch
The MITRE Corporation U.S.A.
E-mail: jwd@mitre.org 

Abstract

Geospatial interoperability, the ability for two or more heterogeneous data sets to interact with one another, is increasingly an issue for users of spatial data. Emerging products are designed for use by non-GIS professionals unaware of the complexities of map projections, datums, scale, topology, accuracy, etc. This paper describes a research project that is developing a geospatial information interoperability envelope to surmount these problems: an object that contains methods that can act on geospatial metadata in addition to the information itself. This envelope contains knowledge about the geospatial information that it accompanies and can ensure the data's integrity, "pedigree," and interoperability. Interoperable geospatial objects comprised of metadata about the underlying data sets combined with users' interoperability characteristics constitute this envelope. This paper describes a research prototype that creates an XML representation of these metadata and interoperability characteristics for transmission between systems and manipulates them via Java-based components for validation.

1. Introduction

Maps traditionally had a variety of associated metadata. Hard copy maps had "collar" information that provided a wealth of details about the contents and heritage of map information. Some details had implications that often made sense only to trained professionals; however, as long as maps were in hard copy form, users often had little need to be overly concerned with the details.

Until recently, metadata about soft-copy spatial data was often non-existent or implicit in the system used to display the information. Recently interest has been growing in geospatial metadata collection and publication. This metadata is generally intended as the basis for potential data discovery applications; expertise is still required to decide whether discovered data can or should be used.

As users become aware of the availability of other geospatial information, they frequently want to combine that with the information they already have; or they anticipate that combinations of geospatial data will result in new insights. Geospatial integration operations may seem uncomplicated to users not trained in some of the subtleties of geospatial information. Some geospatial context information may have implications for the integration of the datasets as well. Finally, whether geospatial datasets can be integrated may depend on the intended use of the result: a simple coincident display at a small scale may be feasible whereas topological integration of features or large-scale precision positioning may not be.

The increase in the number of sources and availability of geospatial data has begun to cause problems for data users. Geospatial data is becoming increasing accessible, e.g., imagery from sources such as TerraServer, street information such as the U.S. Census Bureau's TIGER Mapping Service, and spatial data of all kinds via the FGDC Clearinghouse to name just a few. As geospatial data becomes more accessible to the general public, geospatial tools have broken out of traditional Geographic Information Systems (GIS) packages and are starting to appear in more common desktop applications. This, combined with the appearance of less expensive GIS packages in the marketplace, has resulted in exponential growth in the number of users who are aware of the potential of geospatial data; however, these are not the same geospatial users to which the traditional GIS marketplace is accustomed. In fact, many of these users may not realize they are manipulating geospatial data. The appearance of geospatial data in users' desktop environments is fueling interest in geospatial data integration: "But why can't I easily combine the Census street data with TerraServer's images?" Geospatial data sets differ for a variety of reasons: data may be compiled for a specific purpose, with specific attributes, from a specific source, or for a specific scale. This can make a data set produced by one person very different from another's data set even over the same geographic region. Yet, in order for a data consumer to achieve her mission, she may have to derive products from a variety of heterogeneous data sources. Further, as geospatial data is exchanged from one organization to another, each succeeding generation loses the "pedigree" associated with its predecessor. The trend then is that while data, applications, and users proliferate, the necessary geospatial expertise to use it appropriately is proportionately less available.

2. Interoperable geospatial objects research

The MITRE research project that this paper describes seeks to develop a geospatial information interoperability envelope to surmount these problems: a mechanism to exchange and act upon geospatial metadata and intended usage characteristics. The hypothesis of this research is that an intermediary can use such envelopes to help users to determine integration issues and to facilitate their resolution. These envelopes would contain knowledge about the geospatial information that it accompanies and can ensure the information's integrity. Methods associated with a geospatial interoperability envelope can be invoked whenever the information is acted upon or the information interacts with other such objects. The envelope and the information it accompanies become interoperable geospatial objects that can migrate from system to system. The envelopes can be used prior to accessing the (often voluminous) geospatial data to determine the feasibility of integration.

Figure 1 illustrates the envelope concept: An Interoperable Geospatial Object (IGO) consists of a particular user's interoperability model and one or more geospatial objects. Initially these geospatial objects consist solely of metadata for a particular data set. As IGOs are created and exchanged between users, however, geospatial objects may be IGOs themselves, encapsulating information about the lineage of a data set and the use for which each was intended.

Geospatial objects in the research prototype are primarily made up of metadata about the underlying data sets combined with the interoperability characteristics. The prototype validates the data set metadata against the interoperability characteristics as being a valid use of the data given the user's context. Metadata used by the prototype, both for the interoperability models and for the geospatial objects, is represented in eXtensible Markup Language (XML.) Geospatial interoperability model metadata has been developed, so far, via a Document Type Definition (DTD) of our own invention. The metadata representation for geospatial data sets used by the prototype is based on the Federal Geographic Data Committee's Content Standard for Digital Geospatial Metadata and the International Standard Organization (ISO) Technical Committee 211 (TC211) 15046-15 metadata models, which we re-cast into an XML format.

3. Prototype architecture

The diagram in Figure 2 depicts a high-level overview of the components of the system we are creating. The interoperability model and geospatial objects both provide input to a validator. The validator extracts the characteristics of geospatial objects and requests experts who have registered interest in those characteristics to assess the significance of those differences in the context of an interoperability model. The experts that the validator calls on are modules that encapsulate expert geospatial knowledge in various and extensible areas. An explainer module provides a rationale for identified interoperability problems and suggests solutions.

In future work we intend to create an integration capability that would make use of translation/conversions services to mitigate interoperability problems. We envision the need for an orchestrator component to determine the appropriate actions to be taken and guide geospatial data through these processes (creating new IGOs along the way, naturally.)

We envision the need to provide adaptors that permit geospatial objects to be plugged into a variety of off-the-shelf or legacy GIS capabilities. A GIS adapter provides the system-specific interface to geospatial objects.

4. Interoperability model

A substantial amount of our effort initially went into defining the characteristics of a geospatial interoperability model. Figure 3 is a representation of the subcomponents that constitute an interoperability model, which characterizes a particular user's requirements for geospatial data. We decompose a user's intended use of geospatial information into a small set of spatial operations that require combinations of dataset display, editing, and analysis. These are further decomposed into finer-grain geospatial operations or requirements, e.g., the display of two data sets simultaneously requires some amount of overlap of coverage area and compatible projections. As an exemplar of fairly sophisticated geospatial data use, we illustrate cross-country mobility analysis as requiring particular kinds of dataset characteristics (attribution, scale, etc.) The interoperability model simply characterizes these requirements as sets of atomic, non-system specific geospatial operations and their requirements. Allowance is made in the interoperability model for including other metadata related to geospatial data usage, e.g., the characteristics of a GIS that the user has or prefers, security information describing what kinds of data the user may access, etc. We have not, as yet, further decomposed those modules.

Any particular user will potentially have a unique combination of geospatial data use characteristics; however, some classes of users might have similar sets. Two instances of interoperability model templates might be, for example, a terrain analyst's profile or that of a theater commander.

A key aspect of combining geospatial objects, or even of characterizing the use of a single geospatial data collection, is the necessity to include metadata about the interoperability profile context in which the combination was created or the geospatial object was used. This information, and the encapsulated geospatial objects themselves, provides the "pedigree" for objects as they evolve over time. A tool that we have developed to assist users in creating an interoperability model uses a "wizard" approach to stepping the user through defining the various subcomponents of a model. Driven by an XML Document Type Definition, a set of Java components leads the user through generating appropriate responses. To enable users to provide information in a geographic context, this tool uses an OpenMap^TM Java Map Bean to let users point and click their way to the specification of interoperability model characteristics. We capture the resultant interoperability model via a description that is itself represented in XML.

Figure 4 depicts an example of casting the metadata information associated with an interoperability model into XML.

The rationale for maintaining geospatial objects (the combination of interoperability model characteristics and geospatial metadata) in this XML form is to make the result fairly light weight and easily Internet accessible.

5. Challenges

In designing and developing the research prototype system, we have identified a number of challenges that need to be surmounted. Following are some of the challenges we have identified and the approach we currently intend to take to address them:

• Geospatial objects primarily consist of metadata about the geospatial data itself. Metadata currently comes in many forms, some fairly well defined, e.g., metadata abiding by the FGDC Content Standard for Digital Geospatial Metadata, and others less so. Even when metadata abides by a standard, however, the values used to characterize one dataset vs. another may not be easily comparable but may be unique to the originating site. To date, most geospatial metadata capture seems to have been with the intent of simply cataloging the existence of data sets, providing human readable, text searchable descriptions of the data set content and purpose, and a minimum amount of spatial context: the footprint of the dataset, for example.
• For a validation system such as ours to scale up to provide assistance to non-expert users requires that the geospatial objects insulate the validation system and experts from the vagaries of metadata content. As a simple example, the projection associated with two datasets may be spelled differently or may have one of several equivalent names. A geospatial metadata accessor component of the runtime instantiation of a geospatial object is intended to "normalize" the metadata used by the rest of the system. To do that, we expect to need to create various instantiations of metadata accessors "tuned" to particular collections.
• Some metadata may be implicit in the specification for the data type, e.g., the post spacing of elevation data or the fact that Vector Product Format data meeting some National Imagery and Mapping Agency (NIMA) specifications will include particular kinds of topological and attribute information. Another runtime component of geospatial objects, which we refer to as instantiations of Specification Profiles, are intended to supply implicit characteristics where explicit metadata is lacking.
• The system as envisioned and implemented so far seeks to avoid accessing geospatial data collections themselves. It may be desirable in subsequent stages to access aspects of the geospatial data itself, in some cases using distribution services, to provide required metadata to perform accurate assessments. Yet another runtime component of the geospatial object that we have designed into the system are data accessors to provide this level of access if available.
• The validator component of the system delegates the evaluation of the validity of geospatial objects in combination with interoperability model characteristics by making use of "experts" that encapsulate specific kinds of geospatial knowledge. It is intended that these experts be "plug-able": new experts can be readily added over time and/or different experts might be available in different environments, e.g., experts that understand classified measuration capabilities or image geometry math models.

6. Conclusions

The combination of exploding availability of geospatial data with an exponential increase in the number of users with little or no geospatial data manipulation experience has the potential to result in increasing corruption, erroneous integration of data, and the generation of more data lacking a "pedigree."

By capturing users' intended use characteristics and associating that intended use with combinations of geospatial datasets' metadata, we can validate that the use of that combination is appropriate given the users' context.

Encapsulation of geospatial expertise to assist the user population is the only alternative to increasing the entire user population's spatial awareness.

Once specific geospatial objects and an interoperability model have passed validation, that set itself becomes a geospatial object that can be passed along for some other use. By maintaining the pedigree of operations and contexts in which a geospatial object was used, future users can retrace the steps that led to problems or determine where source data came from and why one intended use may be valid while another may not.

References

Content Standard for Digital Geospatial Metadata http://www.fgdc.gov/metadata/contstan.html

International Standards Organization. Geographic Information - Metadata - Version 2.0. ISO/TC211 Working Group 3, Doc. No. 1997-01-20. ISO, 1997.

OpenMap^TM - Open Systems Mapping Technology http://openmap.bbn.com/

Extensible Markup Language (XML^TM) http://www.w3.org/XML/