|
|
|
September 2003 |
Characteristics of a highly interoperable GIS
Oracle Normalized Geometry (No longer supported by Oracle at V9.2) Informix SQL Geometry Types IBM DB2 SQL Geometry Types
What Role should the OpenGIS Simple Features for SQL Specification Play?
It is very important to note that the OpenGIS Simple Features for SQL specification does not dictate how geometry should be stored in the database. The Well-known Binary representation adequately represents simple points, lines and polygons but does not cater for other information such as linear measures or mathematical curves, Annotations, Topology Definition etc. As far as the specification is concerned, the requirement is that a SQL query can return the geometry in WKB or WKT format, regardless of what other data might be stored with the geometry.
In order to support the more advanced capabilities of GIS software, the stored geometry must contain greater intelligence than WKB can provide. Therefore OpenGIS Simple Features for SQL specification is inadequate for writing spatial data to the database.
In practice, the specification lays a foundation for common read-only access via SQL to DBMS spatial data and it is in this role that OpenGIS Simple Features for SQL is most useful.
OpenGIS Simple Features for OLE/COM
When looking at software interoperability, it is impossible to ignore the dominance of Microsoft and the Windows operating system for the PC platform and the efforts made by Microsoft to provide open and universal access to databases. The Open Database Connectivity (ODBC) specification was widely adopted by database vendors for many years and more recently the OLEDB specification has taken over from ODBC as the dominant data access standard.
The OLEDB specification provides a standard Component Object Model (COM) API for access to any kind of data, regardless of how it is created or stored. Client software written in COM compliant languages such as Visual Basic and Visual C++ can access data through OLEDB drivers provided by data providers such as RDBMS vendors, either through the OLEDB interfaces or through a set of higher-level objects provided by Microsoft known as ActiveX Data Objects (ADO).
The Open GIS Consortium recognised the universal adoption of OLEDB by all DBMS vendors, and the dominance of the PC as the platform for GIS client software and developed the OpenGIS Simple Features for OLE/COM Specification. This standard provides for a set of additional COM interfaces that enable access to geometry in a standardised form, plus other interfaces for working with geometry in Well-known Binary and Well-known Text form.
The specification enables DBMS and GIS vendors to expose their proprietary spatial data in a manner accessible to industry standard software development languages.
Given the wide range of software vendors that provide OLEDB drivers to access their proprietary data stores, you could be forgiven for thinking that most PC based GIS software would support such drivers. Unfortunately that has not been the case, with only three GIS vendors implementing the standard for both server and client.
A General Note Regarding Data Access Level Specifications
On paper it would seem that the Open GIS data access level specifications should make it simple for all DBMS vendors to at achieve at least a simple capability to serve spatial data in an open manner, either through SQL or OLEDB. In practice, the adoption rate has been poor. This is possibly due to the fact that these data level access specifications provide more than one method to achieve compliance. The OGC Simple Features for SQL specification has at least 3 methods and the Simple features for OLE/COM is a different specification again, typically a DBMS vendor will choose to only comply with.
Openness is a two-way street, it requires many vendors to comply at both the client and the server level and to the same set of specifications in order for tnie interoperability to be achieved. For example, if one vendor complies with Simple Features for OLE COM (Server) only and another complies with Simple Features for SQL (Client) only, then the two systems will not be iI1teroperable despite both being compliant with OGC Simple Features specifications. Under these circumstances, data transfer becomes the logical fallback solution for physical sharing of data.
|
|
|
|
|
|
|
