|
|
|
September 2003 |
Characteristics of a highly interoperable GIS
Each of these interoperability methods comes with advantages and disadvantages and the choice of which to use will depend on the circumstances of each application. When trying to determine the best method to use, the fundamental question is, what do you want to do with this data? For example, if you want to take full advantage of specific GIS software capabilities (Spatial Analyses, High Quality Carto~aphy), it will probably be necessary to convert the data to the specific GIS native format using the import/export functions that represented the top level of inter operability capability many years ago. If you want to perform more simple functions such as simple mapping or spatial analysis then direct read, common features or web services would require less effort and thus be more efficient in achieving a high level of interoperability. All of the 6 approaches to interoperability that are listed above remain relevant today and only GIS software vendors that cater to the full range of capabilities described may claim to be truly interoperable and open.
A Review of Existing GIS Interoperability Standards
Data Conversion
Up to the early 1990's, GIS implementations were typically stand-alone systems not integrated with other business processes. The data used was stored in file-based formats optimized for fast access. The ability to share data within an organisation was limited to Network File System (NFS) capability and typically required that all application software be from the same software vendor. Sharing of data with other organizations using a different vendors software typically involved the use of data translators either provided with the GIS software or purpose built using programming languages and utilities such as
FORTRAN, sed and grep. During this period, there was very little automation between the GIS, its data and other applications that operated within an organisation.
Spatially Enabled DBMS
By the mid-1990's several technologies emerged that allowed the storage of spatial data in a DBMS, some of these technologies include ESRI SDE, Oracle SDO, and Informix Spatial Datablade. The ability to store and operate with spatial data in a DBMS along with the availability of client development languages that allowed the embedding of GIS functionality in mainstream business applications brought a new dimension to the use the spatial data. These spatially enabled databases allowed organizations to take the first steps toward enterprise GIS and the elimination of organizational "spatial data islands". The interoperability of these early systems was provided by published data access Application Programming Interfaces (API) such as the ESRI SDE C API and the Oracle Call Interface, however use of these required the investment of skilled resources in order to achieve interoperability between systems and this was something outside of the capability of most user organizations.
It is important to note that if two software vendors share a common spatialially enabled DBMS such as Oracle Spatial, they do not automatically become interoperable. This is due to the fact that both vendors are likely to implement different schemas for data storage, particularly for storage of annotations and other non-simple feature objects and behaviours that are required to support their functional requirements. For example, one software vendor may choose to support all simple feature types (points, lines and polygons) in one layer while the other may choose to separate feature types into different layers, a decision based on their individual software architecture and functional goals. Under these circumstances, usage of common DBMS for data storage does not equate to interoperability. There was a need for interoperability standards to be negotiated between vendors and end-user organizations.
Emerging Standards Organizations
About the same time several standards organisations such as the Open GIS Consortium (OGC), the International Organization for Standardization (ISO), and the U.S. Federal Geographic Data Committee (FGDC), began promoting the idea of data sharing through spatial data standards. The early work of these organizations was focused on sharing simple spatial features in a relational database, thereby enabling interoperability betw,een the commercial GIS vendors and in so doing attempt to solve the problems described above. OGC, an international industry consortium of private companies, government agencies, and universities, published an open spatial standard called the Simple Features Specification that promoted interoperability by direct data access.
OGC Data Access Level Specifications
There are two Open GIS Consortium specifications covering direct access to simple feature data at the database access or DBMS level. By simple features we mean simple geometry (points, lines, polygons or aggregations of these) and attributes. The specifications are:
OpenGIS@ Simple Features Specification for SQL, and C .OpenGIS@ Simple Features Specification for OLE/COM
OpenGIS@ Simple Features Specification for SQL
At the time the ISO SQL 92 standard was created and subsequently adopted by all DBMS vendors, the requirement to incorporate spatial information into DBMS was not recognised. ESRI pioneered the "spatial enabling" of commercial DMBS packages with SDE in the mid 90s, with companies such as Oracle, IBM and Informix following suit soon after.
The OpenGIS@ Simple Features Specification for SQL was developed to extend the ISO standard to cater for spatial data and queries. It utilises data types and DBMS extension capabilities allowed by ISO SQL 92, and sets out a framework for how geometry should be accessed, as well as functions for accessing, manipulating and querying spatial data. Central to this specification are standard representations for simple geometry, namely Well-known Binary (WKB) and Well-known Text (WKT).
There are 2 broad approaches to compliance with this specification:
- SQL 92 Implementation of Feature Tables -this approach uses either normalized tables and standard numeric types to store geometry, or through accessing binary data in the WKB representation
- SQL 92 with Geometry Types -a more complex implementation requiring functions to be provided for accessing the geometry in WKB or WKT representations, for conversion between them. Further functions are required for geometry manipulation, relational comparisop and spatial query.
Server Compliance with this specification is the responsibility of commercial RDBMS vendors and to date only three DBMS products support it:
|
|
|
|
|
|
|
