|
Items in cart [0] |
Questions? Call 888-624-8373 |
| Copyright © 2009. National Academy of Sciences. All rights reserved. Terms of Use and Privacy Statement |
Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 511
Page 511
58
Geodata Interoperability: A Key NII Requirement
David Schell, Lance McKee, and Kurt
Buehler
Open GIS Consortium
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.
Background
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
OCR for page 512
Page 512
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
attributes—emergency response, health and public safety,
military command and control, fleet management, environmental
monitoring—the 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
OCR for page 513
Page 513
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.
OCR for page 514
Page 514
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 OGIS
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.
Object Technology
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
OCR for page 515
Page 515
"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:
•
A single, "universal" spatiotemporal data and
process model that will cover all existing and potential
spatiotemporal applications;
•
A specification for each of the major database
languages to implement the OGIS data model; and
•
A specification for each of the major distributed
computing environments to implement the OGIS process model.
By providing these interoperability standards, the OGIS will
also provide the means for creating the following:
•
An interoperable application environment
consisting of a configurable user workbench supplying the specific
tools and data necessary to solve a problem;
•
A shared data space and a generic data model
supporting a variety of analytical and cartographic applications;
and
•
An interoperable resource browser to explore and
access information and analytical resources available on a
network.
The two main components of the architectural framework of the
OGIS are the OGIS geodata model (OGM) and the OGIS reference model
(ORM).
OCR for page 516
Page 516
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
OCR for page 517
Page 517
"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:
•
The multiplicity of geodata formats and data
structures, often proprietary, that prevent interoperability and
thereby limit commercial opportunity and government
effectiveness;
•
The need to coordinate activities of the public
and private sectors in producing standardized approaches to
specifying geoprocessing requirements for public-sector
procurements;
•
The need to create greater public access to public
geospatial data sources;
•
The need to preserve the value of legacy GIS
systems and legacy geodata;
•
The need to incorporate geoprocessing and
geographic information resources in the framework of NII
initiatives;
•
The need to synchronize geoprocessing technology
with emerging information technology (IT) standards based on open
system and distributed processing concepts; and
•
The need to involve international corporations in
the development and communication of geoprocessing standards
activity (particularly in the areas of infrastructure architecture
and interoperability) to promote the integration of resources in
the context of global information infrastructure initiatives.
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:
•
Software vendors have already begun writing
software that conforms to the object-based paradigm exemplified by
the OGIS. GIS database, visualization, desktop mapping, and
application tool vendors will all be able to provide capabilities
that will seamlessly integrate into applications targeted for
specific end-user communities. Just as the new paradigm will
transform monolithic desktop applications into environments of
compatible components (such as printing modules that work with a
spreadsheet or word processor, making it unnecessary for the
spreadsheet or word processor to contain its own printing
software), OGIS-based components
OCR for page 518
Page 518
will perform specific analysis and display
functions, and they will work seamlessly with other, non-GIS
applications.
•
Integrators working on systems that require the
ability to access geodata and geoprocessing resources are already
building OGIS compliance into their frameworks.
•
Data providers, public and private, who are
preparing to serve data across networks, are planning and
prototyping encapsulation schemes and database approaches that will
depend on the OGIS. This group will ultimately include, for
example, public digital libraries; remote sensing data vendors like
SPOT and EOSAT; state and federal agencies that need to distribute
data to agency offices and/or that are obliged to make their data
publicly available; major corporations with spatial data in their
corporate databases; and military intelligence, planning, and
training 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 NOAA—Nautical Charting Division, U.S. DOD
Defense Mapping Agency (DMA), and U.S. DOI Geological
Survey—National 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 interoperability—which is to say, to
bring the NSDI into the NII—is 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
OCR for page 519
Page 519
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.
Recommendations
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
OCR for page 520
Page 520
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.
References
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.
Representative terms from entire chapter:
object technology
