GIS and Interoperability
Interoperability is an essential design goal for any enterprise GIS system, but this will not be achieved through standardization of fine-grained APIs. The experience of GIS
vendors and data publishers within the OGC, not to mention the larger software industry, has confirmed this. The first family of OGC technology specifications, collectively referred to as Simple Features, did not deliver directly in terms of interoperability because the Simple Features APIs for Component Object Model (COM) and the Common Object Request Broker Architecture (CORBA) were not widely implemented (only one vendor has implemented all these, which does not constitute interoperability). However, the specification of feature geometry and coordinate systems that emerged from the Simple Features specifications has become central to the new generation of Web-based specifications.
The bearer of interoperability must be the data model. The data model must be rich enough and adaptive enough to contain all that is needed by an enterprise GIS software's anticipated clients. It must also be simple enough structurally that it is easily and widely supported by multiple vendors' software. Coarse-grained APIs working with this data model will provide the best performance and most efficient communication and processing of geospatial information among various application clients.
The approach laid out in this paper achieves the following important goals:
! Enterprise GIS systems need interoperability solutions that are scalable across a range of bandwidths from zero to very high connectivity.
! Some GIS users need to be able to work with legacy systems for the foreseeable future, but this should not prevent others from taking advantage of current and future capabilities of information technology as they appear.
! Any API defined for an enterprise GIS should be permissive, rather than prescriptive, in support of differing data requirements for its various client applications. GIS consumers should not be limited to getting only what they can use in their legacy applications today but should be able to pull additional information from the central data store as their applications evolve to handle it (such as commercial GIS can today).
vendors and data publishers within the OGC, not to mention the larger software industry, has confirmed this. The first family of OGC technology specifications, collectively referred to as Simple Features, did not deliver directly in terms of interoperability because the Simple Features APIs for Component Object Model (COM) and the Common Object Request Broker Architecture (CORBA) were not widely implemented (only one vendor has implemented all these, which does not constitute interoperability). However, the specification of feature geometry and coordinate systems that emerged from the Simple Features specifications has become central to the new generation of Web-based specifications.
The bearer of interoperability must be the data model. The data model must be rich enough and adaptive enough to contain all that is needed by an enterprise GIS software's anticipated clients. It must also be simple enough structurally that it is easily and widely supported by multiple vendors' software. Coarse-grained APIs working with this data model will provide the best performance and most efficient communication and processing of geospatial information among various application clients.
The approach laid out in this paper achieves the following important goals:
! Enterprise GIS systems need interoperability solutions that are scalable across a range of bandwidths from zero to very high connectivity.
! Some GIS users need to be able to work with legacy systems for the foreseeable future, but this should not prevent others from taking advantage of current and future capabilities of information technology as they appear.
! Any API defined for an enterprise GIS should be permissive, rather than prescriptive, in support of differing data requirements for its various client applications. GIS consumers should not be limited to getting only what they can use in their legacy applications today but should be able to pull additional information from the central data store as their applications evolve to handle it (such as commercial GIS can today).
Comments