We all know that ice cream comes in many flavors, but did you ever consider that interoperability does too? The Open GIS Consortium (OGC, http://www.opengis.org/) uses the short-hand term "plug and play" to describe its goal of geospatial interoperability, but it's more complicated than that. Still, exploring the different flavors sheds light on how much interoperability is already available, and where the challenges lie.

Interoperable data. Data interoperability, for instance, is very familiar to geospatial software users. We often use generic intermediate data formats (this also includes data models and encodings) that allow different systems to share data. The intermediary is ideally lossless (no data loss) but could in fact be lossy (some data loss). We use dozens of formats, some of which have history outside our discipline. Rich text format, for example, is commonly used to move text data between word processing software, and Lotus 123's worksheet format helps move data between different types of spreadsheet software.

Software interfaces. Software interface interoperability relies on sending a service request in a known format and receiving a reply, or eliciting a service response, in a known format. To work, there must be an enabled server somewhere on the Web waiting for the service request that knows how to generate and send a proper service response.

This concept is played out in many different ways. Underlying e-mail clients and servers are protocols called SMTP (simple mail transfer protocol) and POP (post office protocol) that define how messages are sent and received. These protocols allow any mail e-client (such as Outlook or Eudora) to access any e-mail server.

Another way to send requests uses a URL (uniform resource locator). The OpenGIS Web Map Service (WMS) specification details this methodology. The reply comes in the form of a well-known graphic format (PNG, GIF, or JPG). WMS also illustrates another type of interoperability -- portrayal interoperability -- which means that instead of receiving the data itself, the recipient receives a picture of the data. PDF files are another example of portrayal interoperability.

XML (eXtensible markup language) is yet another way of sending and receiving requests over the Web. It is also the basis of today's Web services. XML documents with known structures define queries and encode and return replies.

Programming interfaces. The most complicated type of software interoperability involves programming language interfaces. Far more than just specifying a data format or sending or receiving of messages, this type of solution requires an actual layer of software between the two software programs that need to communicate. That's how the OpenGIS Simple Feature Specification works. ODBC (open database-compliant) connections to databases work the same way. Though this is perhaps the most complex way to implement interoperability, it also provides the most control.

Information interoperability. In infor-mation interoperability, also called semantic interoperability, the goal is to help systems understand that two items with different names really represent the same object in the real world. The big advantage that we humans hold over computers in this type of situation is that we can use context -- how the word is used -- to decipher equivalences and shades of differences. In computer terms, the goal is equivalence, not between words, but between schemas -- the lists of types and structures in which we store data.

In OGC's GeoSpatial One-Stop Transportation Pilot, we are specifically asking the question, "What does it mean to correlate the different data structures used for transportation data from one organization to another, and how can we achieve such a correlation?" The current solution involves a reference schema -- that is, a known structure to which each organization can map its data structure in a two-way fashion. In fact, we depend on human knowledge to perform the mapping and on the computer to do the rest of the matching work. Someday, perhaps, computers will be able to do this without human intervention, but for now, this solution is a big step forward.

Your role. Making interoperability a reality is challenging but vitally important work. To move these efforts to the next level, we need your input and your data! Consider providing data or other resources for future testbeds and pilots, and let OGC know about your interoperability needs. When you are ready, select software that implements our specifications. Ready to get involved? Contact Mark Reichardt, mailto:mreichardt@opengis.org

Kurt Buehler is vice-president and chief technical officer of the Open GIS Consortium (OGC, http://www.opengis.org/). One Last Thing features invited commentary from geospatial community leaders.