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:
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. Where this methodology is helpful While theoretically the ideas of OpenGIS sound plausible, implementation of the interfaces in products, and use of those products, can only occur if there are good supporting business reasons. So, it is fair to ask how will products that support these interfaces add value for businesses in the utility sector. Utilities should be drawn to open standards for a few reasons. First, open published standards will not lock them into a proprietary system and the vendor who created it. Organizations are free to work with a variety of vendors and integrators who need access to the specification, not proprietary code. Second, utilities are growing more and more by acquisition. And, as a result, new GIS systems are being added to the organization. There are always two options for managing mixed environments: keep a heterogeneous environment or convert to a single system corporate-wide. Each has its costs. However, being able to keep both running while "connecting the two" via open interfaces cuts down on purchases as well as training. Interoperability at the interface level provides a means to replace a component of a system that becomes outmoded, or more likely, enhanced significantly by the same, or a new vendor. There is ample opportunity to switch out just that component for a new one that exposes the interface. Finally, organizations that participate in the creation, and hopefully, implementation of the interface specifications are truly on the cutting edge of technology. They have shown their willingness to strive for consensus and work with other organizations, likely their competitors. That experience can only reflect well on their ability to reach consensus within large organizations, such as utilities, and serve as resourceful integration partners. Examples of interoperability Interfaces and Implementations While the OGC does have several specifications published, only a handful of vendors have implemented them. Those organizations tended to be very involved in the specification development. Further, many of the initial specifications were "groundwork" specifications defining the most basic elements needed for future interoperability: simple features, grid (image) coverages, catalog (metadata), transformations (projections). These in and of themselves certainly can be implemented, and have been in a handful of products, but perhaps their real role was to underlie what was to come: interoperability on the Internet. Web Mapping Test Bed I The first fast track interoperability initiative, begun last year, revolved around developing interoperable interfaces for Internet map servers. The idea, in short, was to find a way to capture information from many different "brands" of web servers using a standard interface and bring them together for an answer to a question. The end user simply sees the answer (often a map) and need not know the underlying mechanics - such as searching for the correct data, putting it in the correct projection - etc. The resulting specification was made public in April 2000. Later that month Cubewerx of Canada shipped the first product compliant with the specification. And, NASA, in September, one of the sponsors of the Test Bed, purchased the Cubewerx Map Server. Other implementations are in the works from other participants with little or no fanfare. Since some of the organizations showing the most interest are the data holders, such as NASA, future use of their data may depend on being interoperable. What's Next? The vision is that more and more software vendors will offer compliant servers to make Web mapping interoperability a reality. But that can only come with customer demand - if users do not place a high value on interoperable systems, vendors will not build them. And, if only one system exposes the interface, very limited connections are possible. OGC works in tight conjunction with ISO, and many initiatives are being fast tracked there. Since more and more governments and others, turn to ISO as a guide for software selections, they may soon be turning to OGC specifications. And, in parallel, many of the new developments in GIS and GIS research are building off of the public specifications as a starting point, underlying much of what lies ahead. Utilities, like telecommunications companies, see interoperability as both a blessing and a curse. The vision of easier sharing of resources is appealing, but the energy to get there may seem significant. As more utilities take further advantage of the Web, both internally and for customer services, conformance with interface standards can only grow. | ||
| © GISdevelopment.net. All rights reserved. |