Geodata Interoperability: A Key NII Requirement
Statement of the Problem
A wide range of activities depend on digital geographic data and geoprocessing, and these information resources are rapidly becoming more important as commerce expands, information technology advances, and environmental problems demand resolution. Unfortunately, noninteroperability severely limits the use of digital geographic information. Spatial data exist in a wide range of incompatible and often vendor-proprietary forms, and geographic information systems (GISs) usually exist in organizations as isolated collections of data, software, and user expertise.
The potential uses for geodata in the context of the national information infrastructure (NII) reach far beyond current uses, making current limitations even more disheartening. If legacy geodata, data generated by new technologies such as geopositioning systems, and high-resolution, satellite-borne sensors were easily accessible via networks, and if spatial data of various kinds were compatible with a wide range of desktop and embedded applications, the effects would be revolutionary in NII application areas such as emergency response, health and public safety, military command and control, fleet management, traffic management, precision farming, business geographics, and environmental management.
The problem of geodata noninteroperability will be solved in part by institutional cooperation: organizations need to create data locally in standard formats that can be used globally. But we need to plan a technological solution if we want systems in which diverse applications can transparently exchange diverse geodata types and can access remote spatial databases and spatial processing resources in real time. The technological solution is to develop a common approach to using spatial data with distributed processing technologies such as remote procedure calls and distributed objects.
In this paper we look at the components of the geodata noninteroperability problem and describe the technical solution and the unique consortium that is providing that solution. This consortium approach, which involves users in the specification process and which organizationally isolates technical and political agendas, holds promise as a model means of simultaneously developing important technologies and developing and implementing technology policy.
The Importance of Geospatial Information and Geoprocessing Services
The NII broadly defines an information technology environment for the development and use of many information-based products of vital significance to the nation. Fundamental to the design and function of many of these products is the use of geospatial data, more commonly known as geographical information. So widespread and critical is the use of geographical information and the geographical information systems (GISs) that have been marketed to work with this information in its many forms that President Clinton, in Executive Order 12906 (April
11, 1994), established the National Spatial Data Infrastructure (NSDI). He commissioned the Federal Geographic Data Committee (FGDC; chaired by Secretary of the Interior Bruce Babbitt) to document the NSDI, to give it operational form, and to provide a management structure designed to help it grow and become a focus for the combined efforts of both public- and private-sector organizations concerned in any way with the development and use of geospatial information.
In terms of the clear objectives that give it form and sustain it, as well as its highly focused data development and standardization activities, the NSDI is positioned to be a well-defined and vital component of the NII and a valuable resource for those working in a variety of the application areas targeted for intensive development by NII policy planners. However, although the NSDI was conceived as a distributed data resource, it lacks the operational framework to support real-time access to distributed geoprocessing resources and their associated database archives. Resources such as the Wide Area Information Server (WAIS) and Government Information Locator Service (GILS) are available for catalog access and superficial browsing of spatial data sets. But the problem of remote query against the wildly heterogeneous assortment of spatial data sets that constitute the NSDI's ''clearinghouse" environment will not be solved until an operational model for the interoperability of distributed geoprocessing environments is developed and accepted by the geoprocessing community.
The nation's wealth of geospatial data is vast and is used more and more by developers and planners at all levels of operation in both the public and private sectors. Much of the information technology world is rapidly transforming its basis of computation from the tabular domain (the world of spreadsheets and accounting ledgers) to the spatial domain (the world of maps, satellite imagery, and demographic distributions). Applications that merge digital mapping, position determination, and object icons are already being introduced in activities such as overnight delivery service and urban transit. These three technologies and new database management systems capable of handling multidimensional data will play an important role in operations decision support systems, maintenance management, and asset management wherever assets and processes are geographically dispersed.
As the NII concept challenges organizations to adopt more comprehensive, entreprise processing models based on wide-area, multimedia communications technologies, there is a growing need to invest the NSDI with distributed processing capabilities that can ensure the full integration of geoprocessing resources into these models. Commercial need for better spatial data integration is already clear in areas such as electric and gas utilities, rail transport, retailing, property insurance, real estate, precision farming, and airlines. Given the critical nature of applications positioned to combine "real-time" and geospatial attributesemergency response, health and public safety, military command and control, fleet management, environmental monitoringthe need to accomplish the full integration of NSDI resources into the NII context has become increasingly urgent.
The Importance of Interoperability Standards to NII-based Applications
Fundamental to the development of enterprise information systems is the concept of interoperability, which is used at all levels of information technology development to define a user's or a device's ability to access a variety of heterogeneous resources by means of a single, unchanging operational interface. At the level of chip technology, the interface is a backplane or a bus specification; at the network level the interface may be a hardware-based transmission protocol or a packet specification; at the operating system level, the interface is a set of system calls or subroutines; and at the object programming level, the interface is a specification for the behavior of object classes. Interoperability thus denotes the user's ability to function uniformly and without product modification in complex environments by applying a standard interface to heterogeneous resources.
In the geodata domain, interoperability is defined as the ability to access multiple, heterogeneous geoprocessing environments (either local or remote) by means of a single, unchanging software interface. Interoperability in this context also refers to accessing both multiple heterogeneous data sets and multiple heterogeneous GIS programs. By definition, this view of interoperability assumes the sort of interoperable network environment envisioned by NII policy.
The interoperability profile of the NII is characterized by multiple hardware and software standards, some complete and some under development. Such standards are the product of years of concentrated effort on the part of both public- and private-sector organizations, as well as such recognized standards bodies as the American
National Standards Institute (ANSI) and the International Organization for Standardization (ISO). Within the operational framework established by these standards, it should be possible to exchange diverse information encoded in a wide variety of data formats among all known makes and types of computer, communications, and video systems. Already significant strides have been taken toward integrating such forms of information as database tables, with the result that both database applications and nondatabase applications such as spreadsheet and word processing documents can use database information without switching applications.
To integrate geospatial data into the application environment of the NII and to use it in a coherent way, the FGDC has taken valuable first steps by organizing an approach to standardizing on an exchange format that includes entity attribute schemes for each of the significant geoprocessing application areas in the federal government and a standardized description of the content of geospatial data collections (i.e., their metadata). Associated with this effort is the establishment of the National Spatial Data Clearinghouse, a directory and metadata catalog accessible by the Internet describing a rich assortment of registered databases meant to define the resources of the NSDI. Taken together, the geodata standardization and Clearinghouse initiatives make up the data resources needed to introduce geoprocessing into the mainstream of NII-based distributed application systems. However, they do not address the interoperability issue. They remain available as a "static resource," requiring either that data be accessed by software that is familiar with its native format or that entire data sets be converted to standardized transfer formats and reconverted to the user's processing format before any useful work can be done with them. Many databases are frequently updated, which adds to the cost of acquisition and conversion.
To make the NSDI data both freely available and useful in the NII environment, it will be necessary to introduce a standardized interoperability mechanism specifically designed for remote access of geographical databases. Such a mechanism must embody the interoperability principles on which the NII is based. That is, it must enable transparent, barrier-free access to heterogeneous geospatial data sets in a distributed environment, relying on standardized interfaces for the generation of queries in real time and the consequent retrieval of query-derived data sets to the user's native environment.
A significant issue faced in recognizing the necessity of such an interoperability mechanism for geoprocessing is that the geoprocessing community has been slow to adapt many recent advances in mainstream information technology. Traditionally, GIS packages (whether commercial or public sector) have created highly structured and architecturally closed operational environments, tightly coupling display graphics with spatial analysis mechanisms, and relying on a tight coupling of spatial analysis with proprietary spatial database designs. Such packages tend to be operationally monolithic, lacking the modularity required for an efficient use of the distributed architectures that are more and more coming to characterize enterprise computing. In the past, the GIS user worked primarily in a closed-shop environment on limited data sets that could be archived and maintained in the local environment and only intermittently updated by means of tape import or batch transfer over the network. With the advent of the Internet and the associated surging demand for "processed data" in real time, such closed environments fail to provide geoprocessing professionals with the same ready access to the nation's data resources as people in general are coming to expect of such institutions as libraries, legal archives, news and entertainment programming, and general information and interaction services on the Internet.
Analysis and Forecast
Contingencies and Uncertainties
The growth of the NSDI subset of the NII, like the growth of the NII itself, is a complex, many-faceted phenomenon. As in a developing economy or ecosystem, there are many complex dependencies. Organized cooperative effort will characterize the growth in some domains; chance, raw market initiatives, and surprise breakthroughs will dominate in others. The rise of geodata interoperability depends on the expertise, commitment, and user focus of those who are directly addressing the problem, but it also depends on the infrastructures that support their efforts and on the vagaries of the market.
In this section we describe a geodata interoperability standards effort in progress and note the other standards and new technologies on which it depends. We also describe the process by which the standard is being developed, and the participation essential to that process.
The Open Geodata Interoperability Specification (OGIS) is a specification for object-oriented definitions of geodata that will enable development of true distributed geoprocessing across large networks as well as development of geodata interoperability solutions. OGIS is like other emerging distributed object-oriented software systems in its basic structure and benefits, but it is the first large-scale application of object technology to GIS and to the management of spatial data in the global information infrastructure (GII) and NII contexts. It is being made sufficiently general so that it can be implemented using software methodologies other than object technology, including remote procedure call (RPC) architectures such as the Open Software Foundation's Distributed Computing Environment (DCE) or application linking schemes such as Microsoft's Object Linking and Embedding (OLE).
The OGIS will specify a well-ordered environment designed to simplify the work of both developers and users. Developers adhering to OGIS-defined interface standards will easily create applications able to handle a full range of geodata types and geoprocessing functions. Users of geodata will be able to share a huge networked data space in which all spatial data conforms to a generic model, even though the data may have been produced at different times by unrelated groups using different production systems for various purposes. In many cases automated methods will bring older data into conformance. The OGIS, and the object technology that underlies it, will also provide the means to create an extremely capable resource browser that users will employ across networks to find and acquire both data and processing resources. Searches will be executed using powerful, object-oriented distributed database technology developed to handle large, complex, abstract entities that cannot be managed in conventional relational database management systems. Queries will potentially return only the data requested, not whole data sets that will require further reduction and preparation before the user can begin.
With the OGIS in place, the GIS industry will have the tools it needs to address the expensive geodata incompatibility problems faced by federal agencies, large private enterprises, and state and local governments. The OGIS will provide a technological boost to organizations committed to spatial data transfer standards. By providing a "smart" generic wrapper around data, OGIS will achieve the objectives of a universal data format while respecting the widely varying missions of data producers. Making good use of distributed processing on high-bandwidth networks, OGIS will multiply the utility of geospatial databases and reduce the size and duration of data transfers.
To understand how the OGIS will work, one must understand the basics of object technology. Object technology will, over the next 5 years, change the way we conceptualize, build, use, and evolve computer systems. It provides a way to integrate incompatible computer resources and a way to build software systems that are much easier to maintain, change, and expand. Its robust components can be quickly assembled to create new or modified applications. It is synergistic with the information superhighway, offering a model in which adaptable agents spawned by a user's local computer can act across the network. In harmony with today's emphasis on sharing of data and resources within enterprises, it breaks out of the earlier model that sequesters proprietary software and data within isolated systems. Object technology will make it much easier for nontechnical people to access and customize information and information systems, because many instances of data conversion and manipulation will become transparent.
The old way of programming, procedural programming, segregates data from the programs that operate on the data. Procedural programming makes sense when processing resources are in short supply and programmers are available in abundance to maintain and "debug" aging software systems that have grown into
"spaghetti code." The world is moving away from this model. Processing power is abundant and cheap, and large enterprises now look to object technology to reduce escalating software maintenance costs (and data conversion costs) that are straining their budgets.
Moving beyond stand-alone programs that operate on specific kinds of data to perform specific tasks, developers of large enterprise systems are now beginning to write software in special modules called objects. Objects typically include both data and behaviors. Data are spoken of as being "encapsulated" in an object. The capsule that contains the data is a set of behaviors (or procedures, or methods) that can act on the data and return a result when requested to do so by another object. If an object is requested to do something it cannot do, it returns an error message. Older, preexisting data and applications can be encapsulated so that they will work in the object environment.
Client objects in distributed object systems can learn other objects' contents and capabilities and invoke operations associated with those capabilities. In other words, objects interact as clients and servers. The object-to-object messaging that is central to object technology gains efficiency through a system by which objects belong to classes with common properties. Classes can be nested in hierarchies. In these hierarchies, classes inherit attributes (data and procedures) from classes that are higher in the hierarchy. Inheritance allows objects to efficiently represent the large amount of redundant information that is common to all the objects of a class.
Large object systems, especially distributed systems, typically have an interface layer called an object request broker (ORB) that keeps track of the objects and activities in the system. The ORB screens for improper requests, mediates between competing requests, makes request handling more efficient, and provides an interface through which dissimilar applications can communicate and interoperate.
Just as a Microsoft Word user can now run analyses on a Microsoft Excel spreadsheet embedded in a Word document without changing applications, a GIS user will access (through the development of the OGIS and the object technology environment) a full set of GIS capabilities while working in an application that may not be a GIS application. Just as the Word user no longer needs to convert the spreadsheet to tab-delimited text before importing the static data into the Word document, the GIS user will not need to convert data formats and projections.
The OGIS Architecture
The OGIS will provide the following:
By providing these interoperability standards, the OGIS will also provide the means for creating the following:
The two main components of the architectural framework of the OGIS are the OGIS geodata model (OGM) and the OGIS reference model (ORM).
The OGM is the core component of the framework. It consists of a hierarchical class library of geographic information data types that make up the shared data environment and unified data programming interface for applications. Cohesive, comprehensive, and extensible, encompassing all current geospatial and temporal descriptions of data, presentation issues, analysis modes, and storage and communication issues, the OGM will be the language of OGIS. The OGM will be the interface to geodata transfer standards such as the Spatial Data Transfer Standard (SDTS), Spatial Archive and Interchange Format (SAIF), and Digital Geographic Standard (DIGEST). It will be interoperable with SQL3-MM, the next generation of SQL, which will be object oriented and will support multimedia entities, including geospatial data.
The OGM will support object queries, read/write of multiple formats, temporal modeling, and long-duration transactions. To accomplish these objectives, it will include sophisticated GIS definitions of spatial objects, fields, and functions.
The ORM describes a consistent open development environment characterized by a reusable object code base and a set of services. The design approach for the OGM determines the set of services that must be supported in the ORM. As a result, the ORM requires directories of services and databases, which will support complex query processing. It also specifies standard methods for requesting and delivering geospatial transformations and processing tasks. The ORM will also facilitate transformations between "private" data and OGM constructs, as well as coordinate conversion and raster/vector conversion. It also manages visualization and display and supports data acquisition.
Other Emergent IT Standards and their Relationship to OGIS
As mentioned previously, implementations of the OGIS will be layered on interfaces such as CORBA, DCE, and OLE. These are, in fact, the three major interfaces that are likely to be used. The success of the OGIS will therefore ultimately depend on the robustness, completeness, stability, schedule, and market acceptance of these standards. CORBA and DCE are the products of consortia; OLE is the product of Microsoft. The success of a consortium-produced standard depends greatly on whether the members put in enough time and money to finish the standard in a timely and complete fashion and whether the members understand the needs of the community that might use the standard. The success of a vendor-produced de facto standard like DCE depends greatly on the vendor's market penetration. The success of any standard depends on whether the standard solves a problem for a sufficient number of users, with sufficient cost-benefit advantage to make the standards-based solution more attractive than alternative nonstandards-based solutions.
The robustness, completeness, stability, schedule, and market acceptance of other aspects of the NII also bear on the success of the OGIS. Everything from the installation schedule of broadband cable to the security of network-based payment schemes will affect the demand for geodata and remote geoprocessing. Reciprocally, working geodata and geoprocessing solutions will help drive the demand for bandwidth, payment schemes, and network-ready devices, as well as the demand for more data and applications.
In the domain of GIS, the standards work of the FGDC and other groups focused on institutional solutions to interoperability will contribute to acceptance of OGIS-based solutions. These groups are focusing the attention of tens of thousands of traditional GIS users. These users will be motivated to publish their data electronically, and their need for data will simultaneously increase the demand for remote access to the data of others. The expense of manually bringing data into conformance will, we believe, often be greater than the expense of using OGIS-based automated methods, thereby increasing the demand for OGIS-based solutions.
Factors in Making the Business Case: Who will Build the OGIS and Why?
The Open GIS Consortium, Inc. (OGC) is a unique membership organization dedicated to open system approaches to geoprocessing. By means of its consensus building and technology development activities, OGC has had a significant impact on the geodata standards community and has successfully promoted the vision of
"open GIS" as the vehicle for integration of geoprocessing with the distributed architectures positioned to define the emerging worldwide infrastructure for information management.
OGC's direction is set by a board of directors selected to represent key constituencies in the geoprocessing community. The OGC board speaks on behalf of both public- and private-sector users interested in finding more integrated and effective ways to use the world's increasing wealth of geographical information to support problem solving in such areas as environmental monitoring and sustainment, transportation, resource management, global mapping, agricultural productivity, crisis management, and national defense.
The OGIS Project Technical Committee of the OGC operates according to a formal consensus process structured to be fair and equitable and to ensure the technical completeness of the specification. To ensure the eventual adoption of OGIS as an official standard, the OGIS Project Technical Committee is represented on key geodata, GIS, and geomatics standards committees, including the International Organization for Standardization (ISO) TC211 GIS/Geomatics Committee and the American National Standards Institute (ANSI) X3L1 Committee. In addition, the OGIS Technical Committee maintains close ties to the Federal Geographic Data Committee (FGDC).
The OGIS Project Management Committee is composed of representatives from the OGIS Project Technical Committee, representatives of the principal member organizations, and others who represent particular constituencies. The OGIS Project Management Committee maintains a business plan for the project and sets overall policy for the project. The dual committee structure serves to separate technical and political issues.
OGC was founded to create interoperability specifications in response to widespread recognition of the following problematical conditions in the geoprocessing and geographic information community:
OGC is not-for-profit corporation supported by consortium membership fees, development partnerships, and cooperative agreements with federal agencies. As of April 26, 1995, the consortium included 40 members. Though organized to manage multiple project tracks, OGC's initial focus is on the development of the OGIS. OGC plans to establish other project tracks in areas related to implementations of the OGIS architecture.
Who will Use the OGIS and Why?
The OGIS will be used by at least the following groups:
Ultimately, the OGIS will be an invisible but essential enabler of ready access to remote geodata in all of the application areas mentioned here, and probably in others that we have not imagined. Like other standards, it will not be noticed or understood by most people who use it. It will make an extraordinary complex activity simple.
What Can the Federal Government Do to Facilitate the Process?
Many agencies of the federal government have a critical interest in geodata interoperability, and some are already providing support to OGC. Though most of OGC's funding and technical participation comes from the private sector, OGC was started with funding from the U.S. Army Corps of Engineers Construction Research Laboratories (USACERL) and the DOA Natural Resources Conservation Service (NRCS). Both of these agencies are still involved with OGC. Also, the Universal Spatial Data Access Consortium (USDAC), a NASA-funded digital library technology project, has joined the OGIS Testbed Program of OGC. Funding for USDAC comes from a Cooperative Agreement Notice, "Public Use of Earth and Space Science Data Over the Internet," provided by NASA's High Performance Computing and Communications Program. Other federal agencies that are members include U.S. DOC NOAANautical Charting Division, U.S. DOD Defense Mapping Agency (DMA), and U.S. DOI Geological SurveyNational Mapping Division.
Other federal agencies with a critical interest in geodata interoperability would benefit from participating in the development of the OGIS, because their specific needs would be represented and they would be in close touch with the organizations best able to help them. Also, their support would help ensure timely completion of the OGIS, and as a result they would begin to reap the benefits of OGIS-based solutions as early as possible.
The federal government can also encourage other distributed computing standards efforts on which the OGIS will depend, such as the Object Management Group's Common Object Request Broker Architecture (CORBA). The OGIS will have value in nondistributed environments, but its greatest potential lies in the potential for remote geodata access.
Perhaps the most important way the federal government can help the cause of geodata interoperabilitywhich is to say, to bring the NSDI into the NIIis to make the OGIS project a special focus for the national Information Infrastructure Task Force (IITF). Technology policy at the IITF level needs to stress private sector support for the standards activities of OGC. The IITF is positioned to strongly encourage major corporations (particularly telecommunications companies) to put significant resources into supporting OGIS development work, testbed activities, and, finally, OGIS-based products and services. The IITF can provide solid leadership in showing major corporations why this kind of interoperability ought to be considered a high-priority development issue.
Projections, Including Barriers
OGIS-based implementations will become available in the same time frame in which underlying and auxiliary NII capabilities will become available. Early prototype work has begun at testbed sites, even though the
specification is not complete. The specification will be complete in about a year, and several testbed projects and independent efforts by vendors are expected to begin yielding useful implementations at about that time. The OGIS merely prepares the world of geodata and geoprocessing to participate in the general progress of information technology (IT) that industry experts forecast. The OGIS is being developed concurrently with other essential software standards and components of the NII that will be developed, released, and tried in the real world of the marketplace in the next 5 years.
Dissension in the software community is the principal barrier to this general progress and to the progress of geodata interoperability. The long history of UNIX shows how industry giants seeking dominance can thwart standards efforts and stunt the growth and acceptance of a useful technology. Every standards consortium confronts the tendency for industry leaders to fly apart because of competitive issues. From the standpoint of the OGIS, it is important that underlying standards like CORBA and DCE succeed and that the members of OGC stay true to the vision of geodata interoperability across the industry.
How Can the Problem of Geodata Noninteroperability Be Addressed by a Public and Private Partnership?
As described above, the problem of geodata noninteroperability is being addressed by a standards consortium, the Open GIS Consortium. OGC is developing not another geodata standard but rather a standard approach to using distributed computing methodologies, primarily object technology and RPCs, in geodata and geoprocessing applications. Participation by public and private organizations is particularly important in this case because so many public agencies are critically dependent on geodata and geoprocessing, and because most geodata is a product of public agencies. The public agencies have everything to gain and nothing to lose from their support of OGC, because (1) the OGIS Project gives them an opportunity to increase the certainty that the specification, and solutions based on it, will meet their needs, (2) agency representatives have the opportunity to learn about and learn from the most knowledgeable technology providers, and (3) the capabilities unleashed by the OGIS will enable them to vastly improve their ability to fulfill their missions.
OGC members, public and private, recognize the wonderful opportunity afforded by the timing of this effort: No vendor has yet dominated the market with object-based GIS solutions that might hinder the effort to create a rational, comprehensive, standardized approach that can potentially benefit everyone. Through the consortium, vendors and integrators have an opportunity both to involve sophisticated users in their common technology specification effort and to share the costs of this development. All of the members believe that their collective efforts will lead to greatly expanded markets, though they also recognize that their existing products and services will need to change to accommodate the new paradigm. Most understand that change is inevitable in the IT industry whether they embrace it or not, and OGC offers a way for them to exert a degree of control, stay at the leading edge, and make relatively sound business projections.
OGC's goal is to create successful standards for geodata interoperability, and many of the discussions surrounding its founding focused on the failings of other consortia that tried and failed in their attempts to create standards. Leading consortium lawyers and experts in technology standardization contributed to the formation of OGC and its bylaws, and their guidance continues. The challenge is to carefully craft an organization and a set of goals that make all participants winners, and to be sure that all the interests of all affected constituencies are represented.
OGC has a unique organizational structure that resulted from the process described above. It has a board of directors, a full-time professional staff, and separate project tracks. The board of directors has responsibility for approving business plans from each track, for organizing new tracks, and for setting overall consortium direction and strategy. Each project track has its own membership and is managed by a management committee that is responsible for strategic and business planning, technical oversight, and product approval. (OGC products are IT standards related to geodata interoperability.) Each track also has a technical committee responsible for technology development and mediation of the different technical views of the membership. A testbed program in
each track coordinates early implementation efforts and provides feedback to the technical committee. The technical committee is responsible for product development, which it then delivers to the management committee for final approval. This organizational structure isolates technical issues from management issues and allows a better overall progression of product development. It also isolates the board of directors from each project track.
The IITF is positioned to help OGC succeed by encouraging key NII-building companies to participate in OGC's efforts. Clearly, the technology policy mission of the IITF is perfectly aligned with the mission of OGC. But OGC also offers the IITF a higher-level benefit: the opportunity to observe and evaluate a state-of-the-art consortium that may be the forerunner of tomorrow's technology policy planning bodies. The continuing acceleration of technological change forces a new, more anticipatory and proactive approach to technology policy planning, an approach based on community-wide discussion of objectives followed by development of standards that channel vendors' efforts in agreed-upon directions.
Committee on Applications and Technology, Information Infrastructure Task Force. 1994. The Information infrastructure: Reaching Society's Goals. U.S. Government Printing Office, Washington, D.C., September.
National Institute of Standards and Technology. 1994. Putting the Information Infrastructure to Work: A Report of the Information Infrastructure Task Force Committee on Applications and Technology. SP857. National Institute of Standards and Technology, Gaithersburg, Md., May.