The Internet has amazing potential to
provide an ever-increasing number of goods and services—evils like
viruses and spam notwithstanding. But the Internet also has shown
that many of today’s software applications often don’t work well
together. Non-interoperability needlessly drives up the cost of
information technology by impeding the sharing of data and
computing resources. Real-world risks, however, are a more serious
consequence of non-interoperability.
For instance, suppose a gasoline truck hits a utility pole where a
state highway intersects a county road. Fuel spills and burns, and
some runs into a storm drain that empties into a stream. The
utility pole—owned by the electric utility and used by a cable
company and a phone company—topples amid a tangle of wires.
Traffic backs up in all directions. People are injured, and the
fire spreads to nearby properties.
Consider the information sharing possibilities in this scenario,
beginning with the government and private entities that might have
and/or urgently need spatial information: the state and local
police, the ambulance service, the local fire department, the
company that employs the truck driver, the company that monitors
hazardous material transportation, the state and local highway
departments, the local sewer department, field engineering and
customer service groups at each of the “wires” companies, the
traffic reporters at the local news broadcasting stations, the
state department of environmental protection, the owner of the
burning property, and perhaps federal authorities such as the
Federal Emergency Management Administration and the Environmental
Protection Agency.
Currently only some of this information flows smoothly,
particularly that which requires only a phone call or works
through proprietary interfaces in tightly coupled systems. But
most of the real-time sharing of digital spatial data can’t
happen. It often takes hours or days, because no single technology
provider has “tightly coupled” all of those systems, nor have all
providers yet implemented standards that enable “loose coupling”
of multiple vendor applications.
Now imagine a much broader disaster—a major flood, an earthquake,
an explosion, a building collapse in a downtown area, a natural
gas pipeline explosion or a sudden national epidemic. Consider the
impact of non-interoperable data on services such as power, water,
electricity, sewage and transportation, and consider the impact on
safety and repair costs. Suffice it to say that
all “spatial data infrastructure” stakeholder groups, along with the
vendors that serve them, have a responsibility to work together to
establish interoperable geoprocessing that will help agencies plan for,
mitigate and respond to such real-world havoc.
In recognition of this important responsibility,
the Open Geospatial Consortium (OGC), an innovative public-private
partnership, has worked for more than a decade to enable
interoperability in the spatial technology domain. Although geographic
information and geoprocessing software pose some particularly difficult
interoperability challenges, OGC’s efforts have become increasingly
important as agencies and businesses work to increase quality while
reducing costs of services, face an ever-changing economic landscape and
address national security threats.
Sources of Geoprocessing Non-Interoperability
Information about the location, shape of, and relationships among
geographic features and phenomenon can be highly complex. One reason is
that there are many fundamentally different kinds of systems for
creating, storing, retrieving, processing and displaying geospatial
data. These include vector and raster geographic information systems, as
well as systems for Earth imaging via satellites and airplanes,
computer-aided design, navigation, surveying, cartography,
location-based services, facilities management, etc.
Numerous vendors work within each of these technology domains that did
not, until they joined OGC, collaborate with their competitors to form
agreements on how geospatial data should be structured and shared, and
how their respective systems might better communicate, or interoperate.
This lack of communication, coupled with the many different ways of
measuring and mathematically representing the Earth, produced a complex
and non-interoperable geoprocessing environment. Moreover, there are
user-side semantic issues. For example, without coordination, no two
highway departments will use the same attribute schemas, measurement
types and data types to describe a road. Their “metadata,” or data
describing their data sets, also use different schemas, making automated
data discovery and data sharing difficult.
Overcoming Havoc with Open Standards
According to a recent Delphi Group report, “The Value of Standards,”
there is a clear and sudden shift in attitudes toward software standards
(see “What Is an Open Standard?” below). Delphi’s conclusions are
striking: “The climate of economic constraint and risk aversion, along
with the mandate to integrate systems on both sides of the firewall, has
created a sea change in the sense of imperative to adopt software
standards.”
The report portrays a shifting landscape in which standards will provide
the foundation for long-term advances in the way software is built,
bought and deployed. It appears that interoperability is seen to be much
more important than just a year or two ago. This realization is
reinforced by the success of the Internet and Web, where open standards
such as HTTP, TCP/IP, XML, SOAP and ebXML give users a taste of what
interoperability is truly about.
Open standards address user needs that can only be met by cooperation
among and between technology providers. Overall, users want to maximize
the value of past and future investments in systems and data. In the
geospatial world, that general statement points to the following user
needs:
1. The need to share and reuse data to decrease costs, obtain additional
or better information and increase the value of data holdings.
2. The need to choose the best tool for the job and the related need to
reduce technology and procurement risks —i.e., the need to avoid being
locked into one vendor.
3. The need to leverage investments in software and data, such as
enabling more people to benefit from using geospatial data across
applications without the need for additional training.
An open framework that addresses these basic needs makes it possible for
vendors to address a new array of user needs that require a standards
foundation. These additional needs include:
1. The need to organize geographic data stored in text and on video,
audio and other media.
2. The need to access and process on-line sensor data (a sensor is
always someplace) from multiple sources.
3. The need for location-based services that are portable across
devices, networks and providers.
4. The need to apply different symbology to data for different
applications.
5. The need to take advantage of grid computing for geoprocessing
applications.
The solutions that vendors will offer to fill these needs must have a
standards platform that enables them to establish new markets and new
opportunities for growth.
The OGC Model
One might argue that governments, industries, professions and
disciplines are obliged to their stakeholders to create a shared
information framework that will optimally support their work in the
future. OGC has learned that this happens best in an inclusive,
structured, consensus-based specification process with ample input from
prototyping in testbeds and real-world testing in pilot projects. OGC’s
“Interoperability Initiatives” are testbeds, pilot projects and other
short-term, intensive, multiparticipant “spiral engineering” activities
to develop, test and promote the use of OpenGIS Specifications.
Specifications developed initially in testbeds typically are completed
in the OGC Technical Committee, tested in commercial products in pilot
projects, and then approved by the OGC Technical and Planning Committees
for worldwide use. Interoperability Initiatives provide an opportunity
for technology user organizations to steer the direction of technology
by providing user interoperability requirements, which are the main
guiding factors in these initiatives. Other technology domains could use
the same methods to quickly develop standards that are quickly
implemented in commercial products and tailored to users’
interoperability needs.
To ignore the opportunities offered by the effective use of standards to
enable interoperability leaves “interoperability” to be defined by
vendors’ de facto standards and to consultants who build a stovepipe
system from the top down that essentially condemns stakeholders to
prolonged havoc—increased cost of ownership, lack of flexibility and
agility, and increased life cycle risk. Of course, vendors and
consultants also play essential roles in the world of interoperability
and standards, because software development, maintenance, customization
and service require special skills. Success, however, lies in the
ability to engage these experts and other stakeholders in the OGC
specification process.
Data models also play an important part of the information space. OGC
developed an XML encoding for spatial data, the Geography Markup
Language (GML), that, when used with XML tools, makes it possible to
resolve many of the difficulties associated with incompatible data
models (see “JPEG 2000 and GML”).
In addition, it’s important to emphasize the crucial role that users
play in the move toward open standards. With so much at stake, imagine
what could be accomplished if a large number of people each took a small
step and insisted on open standards in procurements.
Publisher’s note: This article is condensed from a chapter written by
Mark Reichardt for The Standards Edge: Dynamic Tension, copyright 2003,
The Bolin Group.