One of the key trends of recent years is the integration of geospatial technology into mainstream IT. What this means practically is that standard IT architectures, tools, and standards are now being applied to geospatial solutions.

One of the major problems that IT in general faced since the beginning of IT is interoperability.

Different applications, applications from different vendors, and applications running on different operating systems need to share data.  The most widely used approaches are paper and file exchange.  For example, many utilities and telecoms still rely on paper construction drawings as the solution for interoperability between engineering design (CAD) and records (GIS).

For data sharing and application integration two approaches have evolved in mainstream IT and are being applied to problems involving spatial data.  I think the simplest way to refer to them is as loosely and tightly coupled architectures.

Tightly coupled

A tightly coupled architecture integrates enterprise applications around a single point of truth, which is often a single spatially-enabled RDBMS. The types of applications that are linked include engineering design (CAD), facility records management (GIS), asset management, workflow, ERP, CRM, outage management, and other enterprise applications.  An EAI tool is sometimes used to link enterprise applications from specific vendors such as SAP.  A major advantage of a tightly coupled architecture is that it enables the rapid and efficient processing of large volumes of data, provides a single point of truth instead of several, often redundant, data sources, and enables open access to data throughout the organization.  This architecture has been widely adopted within large organizations.

Tightly coupled architectures rely on standards such as  SQL, ODBC, JDBC, and OLEDB, SQL/MM, and the Simple Feature
Specification for SQL from the OGC, to provide open and secure access to data, including geospatial data, throughout the organization.  Most geospatial vendors provide the basic level of support for geospatially-enabled RDBMSs, which means practically that they support basic spatial data types, points, polylines, and closed polygons.  Many RDBMS vendors support the OGC’s Sinple Feature Specfication for SQL.  The OGC with the support of geospatial and RDBMS vendors is working to extend this support to more complex data structures including oriented points and cartographic text in the short term and, I hope,  long-transactions, topology, linear referencing, and georeferenced rasters in the longer term.  The objective is to enable comprehensive geospatial interoperability, so that spatial data can be shared by different applications, applications from different vendors, and applications running on different operating systems.  At the recent Oracle Spatial User Conference, which took place right after the GITA 2006 Annual Conference, two muncipalities shared their experiences in implementing tighly coupled architectures centred around shared data in Oracle Locator/Spatial and involving applications from Autodesk, ESRI, Intergraph, GE Smallword, and MapInfo.

Loosely coupled

The loosely coupled architecture most people are familiar with currently is a service-oriented
architecture (SOA) based on web services. Web services enables internet-based access to distributed data sources and applications using open standards from the W3C (http, XML, SOAP, WSDL, UDDI) and from the OGC (WMS, WFS, GML).  All geospatial vendors including support the basic geospatial web services (WMS, WFS, and GML). Autodesk and almost all of the major vendors demonstrated WMS/WFS/GML interoperability recently at GITA 2006 in Tampa.

Different Problems Means Different Solutions

I think it is fair to say that most IT professionals would agree that loosely and tightly coupled architectures address different problems and that both are necessary and they are not incompatible.  For example, a tightly coupled solution can expose web services.  I think that it is necessary for geospatial vendors to support both of these approaches. Specifically, this implies supporting web services available through mass market vendors such as Google and others, the OGC’s open web services initiatives, as well as working with the RDBMS vendors such as Oracle, the OGC, and with other geospatial vendors to move standards forward for tightly coupled architectures involving spatial data.