Open GIS interfaces: The glue for geospatial interoperability
Adena Schutzberg
Cadcorp, Inc., 6 Tower St.
Somerville, MA 02143
Using glue vs. Using conversion formats
Glue and Conversion Formats
Interoperable solutions can be best described as the opposite of "stove-pipe" solutions.
Stove-pipe solutions are built such that different technology parts are bolted on as needed
with whatever tools are available. Interoperable solutions "click together" like children's
building toys. The difference stems from a simple fact: interoperable solutions do not
come about by accident, but rather by a plan. Stove-pipe solutions occur when no
planning among those developing potential parts chooses to work together.
Until the formation of the OpenGIS Consortium, the geospatial industry had many stove-
pipe solutions. A vendor's software, might or might not work with other products from
its own product line. But certainly, no two vendors without explicit relationships
developed software that would "click" together. The OGC's mission was to lay the
framework for reaching a "clicking together" solution.
The children's building toy metaphor is helpful because it emphasizes that the OGC is
NOT about transfer standards or conversion formats. For much of GIS' short life those
tools have been the foundation of data sharing between, and sometimes within, software
families. Early on, SIFF, and DXF, formats from the CAD world, moved data from one
GIS to the next. By the 1990's more GIS-friendly formats appeared such as ESRI's
shape files and the FGDC's SDTS (Spatial Data Transfer Standard). None of these,
however, let the software work together, they simply allowed some fraction of the data to
move out of one system and take residence in another.
How to Do It?
The OGC spent some of its early years nailing down a vision for how this might work
and a process for moving forward. The vision included the development of open
interface specifications. With all the hype around these words, it is worth a careful look
at their meanings. "Open" means: An architecture whose specifications are public. …
The opposite of open is closed or proprietary." (Webopedia.com) In practice, open
means that anyone can have access to the details of the structure. "Interface" refers to
something that connects two separate entities. For example, a user interface is a
connection between computer user, to the computer or software. An RS232C interface
connects a mouse, and other things, to a CPU. A specification is "a detailed exact
statement of particulars." (Dictionary.com) So, said another way, the goal of OGC is a
set of publicly available detailed documents for connecting geospatial software.
The challenge is how to develop such documents. The OGC uses two processes. The
early work was done via RFP (request for proposal). For example, one of the first topics
to tackle involved defining geometric primitives - points, line, and polygons - as well as
their relationships - touching, near, inside. Many vendors submitted their vision for
these and, through long hours of hard work, those visions were merged into a single
document. That process is referred to as "harmonization." Although this process is time
consuming, the good news is that proposals that reach a vote have been so well studied
that they pass unanimously. The following have been passed thus far:
- Simple Features - agreed on what points, lines and polygons are (do these polygons touch? Is the point inside the polygon?)
- Grid Coverages - agreed about how to talk about imagery
- Catalog Services - agreed on an architecture for online, automated directories of geodata and geoprocessing services
- Coordinate Transformations - projections
A newer and generally quicker process involves an RFC (request for comment). In this
form a company, or group of companies simply submit their idea for a specification and,
after comment, it comes up for a vote. Several RFC style specifications have come about
from "testbeds." Here a sponsoring agency, company or group of organizations puts up
resources to develop a particular interface. Members bid to be part of the solutions team
and are partially compensated for their work. The results, such as the OGC Internet Web
Mapping Services Specification, which came from Web Mapping Testbed I, are then put
to a vote. Six organizations sponsored this first testbed and 31 organizations participated.
Several phases have been completed and resulted in a Web Map Server specification, and
a recommendation for GML, an XML based tool for moving geospatial data. Further
work in Web Mapping Testbed II is ongoing.
What Happens to the Specification?
In the end, however, what is created is a document, detailing the specification and
perhaps an implementation specification, a document explaining how to use the
specification. What happens to that document is the OGC equivalent to "if you built it,
will they come?" Just because a specification exists, does not mean its sponsors, or
anyone else, will implement it in a software package or solution. The first specification
to pass, Simple Features, has been implemented and tested for conformance on nine
products from four vendors (Oracle, ESRI, Cadcorp, Hitachi). These tests were
performed within OGC oversight. The OCG recently decided that in the future
companies will "self test" perhaps against OGC servers.
On the practical level the implementation of a specification means that conformant
products can speak intelligently to clients that also conform. (There are no tests for client
software conformance.) Further, a client that works against one conformant server
should be able to hit another conformant product and receive an answer. That is the crux
of how interoperability works.
