As described in my previous post, GIS architectures are evolving from environments where all the functionality resides in the corporate GIS platform to new architectures where external applications are providing capabilities that have historically been performed within the corporate GIS. There are two general directions that these new architectures are taking: 1) a “Geo-Centric” architecture, and 2) a “Database-Centric” architecture. This post describes the geo-centric architecture and how it is being used today.
A geo-centric architecture is a somewhat subtle change from environments where organizations have one, common, enterprise GIS. In this environment, the GIS is still the common source of truth for the organization. The GIS is responsible for several key roles, including:
- Managing the vendor’s data model
- Representing a common network model, which is particularly important for utility and telecommunications organizations
- Managing the associated metadata structures, and
- Conflict resolution to support multi-user editing within the corporate GIS
External products that perform graphical functions, such as CAD-based design, or geospatial visualization can be integrated with the GIS database in multiple ways, but the following are common examples:
Loosely coupled approach – in this case, an ETL (extract-transform-load) product, such as FME from Safe Software (www.safe.com) can be used to perform a translation out of the enterprise GIS database to provide source data to support new application requirements.
The advantages of this approach are that it can be a simple, relatively quick and low cost means for leveraging data within an existing corporate GIS environment. The primary issue with this approach is that once the data is out of the corporate GIS it is no longer under the management of the GIS platform. There are workarounds for this, based on concepts such as a check-in and check-out, but this loose disassociation can lead to data integrity issues if not carefully managed.
Tightly coupled approach – Another approach involves more tightly coupling the external application to the GIS. An example of this is through the use of the OSGeo Feature Data Objects (FDO) API. FDO allows graphic applications to access geospatial data from the source database directly where it is stored. Each FDO source has a “Provider” that is accessed by the appropriate client. More about FDO is provided at the OSGeo FDO landing page, http://fdo.osgeo.org/. An example is shown in the diagram below.
The FDO approach offers an elegant way of accessing geospatial data to make it available to external applications. In some cases it can even be cached in the external environment where it can be utilized to support visualization and editing operations. There are also challenges with this approach however; not all vendors support these open standards; and editing, while available, must still be well-managed to ensure that the source database receives valid updates.
The geo-centric architecture is something that organizations have been adopting for some time. For some organizations it is a planned means of accessing their GIS data. For many however, it just happens, usually on an unstructured basis. As mentioned in an earlier post, organizations are utilizing their corporate spatial information in best-of-breed tools, mash-ups and other forms of ad hoc analysis to support important business decision making. The challenge is to ensure that this valuable, enhanced geospatial information does not wind up lost on an individual’s hard drive. Rather, it needs to be made available to the broader organization to enable advanced decision support, while retaining proper data integrity.
Our next post will discuss database centric spatial architectures and how they are being used in organizations that need to manage geospatial information at an enterprise level.
