One of the things that I find fascinating are the different ways human society benefits from sharing information. Let me give you an example in the geospatial arena. GITA conducts an annual survey of its members. The 2005 report collected information from 294 members which are utility companies from the electric, gas, pipeline, public, telecom, and water sectors. The survey asked participants if they were using more than one geospatial platform, and secondly, if they were, how did they share data between the systems.
Over 60% of participants reported were using more than a single platform. This is up considerably from the previous year's survey, where between a third and a half reported using more than one platform. For both years two thirds of the companies with more than one geospatial platform were sharing data between them.
But even more interesting, although third party translation software was identified most often as the method for data sharing, an increasing number of participants said they were using "functionality native to their selected GIS" and did not require third party translation software.
I would suggest that we are seeing an increasing number of organizations who are centralizing their network infrastructure in a relational database. This is now possible because most relational databases are spatially-enabled including Oracle, DB2 (IBM), Informix (IBM), PostgreSQL/PostGIS, and even MySQL if you use the ISAM storage engine. Oracle is still the functionality and market leader. In the last three surveys that IDC conducted, over 80% of companies using a spatial database were using Oracle (Locator or Spatial).
It is interesting to see how sharing spatial data has evolved over the years from proprietary files through proprietary schemas for storing spatial data in relational database management systems, to the current state where you can store just about any spatial data with topology in a modern object-relational database management system. The advantage of ORDBMS's is that data is accessible is through an open query language, SQL, and an open interface standard such as ODBC, JDBC, and OLEDB.
[Caveat: But everything is not unalloyed bliss. If you consider the most basic geospatial data types, points, polylines, and closed polygons, the news is pretty good. Most geospatial vendors support these. We have demonstrated interoperability (read and update) with Autodesk Map and products from several other vendors. But if you look at cartographic text, the Open Geospatial Consortium is currently working on this and there does not yet appear to be a consensus. If you consider more complex things like polygon and linear topology, long transactions, and linear referencing systems, it is not yet possible to say that all vendors support a single model.]
The traditional architecture that organizations with more than one geospatial platform employ results in information silos. Engineering, records, and planning typically used applications from different vendors each with its own proprietary data store. Paper (data re-entry) and file sharing were used to exchange data. A typical example is one we have described already, engineering design typically used a CAD application and stored the data in DWG or DGN files. The records or GIS team used a traditional GIS and stored spatial data in proprietary data files supported by the GIS vendor. The planning department probably used another application and stored their data in another set of proprietary files.
An open spatially-enabled data store makes it possible to share data between applications including applications from different vendors. This means that many people with different roles in the organization can share a single point of truth, rather than the more typical situation where the engineering, records, and planning teams use applications from different vendors each with its own proprietary data store.
What this simple concept enables is everyone in different departments in the organization sharing the same information in the same repository, which eliminates data redundancy and the associated redundant processes. This includes the engineers in the central office, the financial people responsible for managing assets, the install and repair people in the field, surveyors in the field, and outage management staff.
The benefits of a centralized spatially-enabled database are the concrete business benefits that we have outlined in previous blogs about ENMAX and Telesp, better quality of service to customers and reduced costs.