Paul
Morin
J2
Geomatics
615
Booth Street, Ottawa, Ontario, K1A 0K2
Tel.:
(613) 992-7666, fax: (613) 996-3328
email:
pmorin@ncs.dnd.ca
Denis
Gouin
Defence
Research Establishment Valcartier (DREV)
2459
Pie-XI Blvd. North, Val-Bélair, Quebec, G3J 1X5
Tel.:
(418) 844-4339, fax: (418) 844-4538
email:
denis.gouin@drev.dnd.ca
Gilles
Clément and Christian Larouche
Logiciels
et Applications Scientifiques (L.A.S.) Inc.
1600,
Boul. St-Martin Est, Tour A, bureau 650, Laval, Quebec, Canada, H7G 4R8
Tel.:
(514) 668-4949, fax: (514) 668-2822
email:
cl@las.com
email:
gc@las.com
ABSTRACT
Interoperability of spatial systems is a goal sought by many and, by most measures, attained by none. If systems were truly interoperable, it would be straightforward to share geographic information across software platforms and between databases collected for different purposes by different organizations. In contrast, a variety of technical, institutional, and physical barriers inhibit the fluid exchange of geographic information.
One of the main problems in today's spatial or geographic information management framework is geospatial data conversion and integration. Very often, GIS developers and users need to import geospatial data from different sources. This task has proven to be difficult and time consuming. Industry experts believe that 60% to 85% of the total cost of implementing a GIS is data conversion. Geospatial data products are offered in a large variety of different and incompatible formats, possibly in different coordinate systems or cartographic projections. Typically, GIS software developers have developed their own proprietary geospatial data format and use ethnocentric translators to convert foreign geospatial data formats into their own format. Consequently, data suppliers have to develop versions of geospatial data products for several software packages.
Geospatial data format standardization is one solution to this problem. However, it is very unlikely that the industry will move to a single standard. At least half-dozen important standards can be expected besides all the proprietary commercial data products already gaining momentum in the marketplace. This means that standardization alone will not solve the geospatial data conversion and integration problem by itself.
This paper proposes a solution, the Open Geospatial Datastore Interface (OGDI), a dynamically loadable C language application programming interface (API) that provides a standardized method through which a GIS software package can access a variety of geospatial data products. OGDI uses a client/server architecture to facilitate the dissemination of geospatial data products both locally and over any TCP/IP network, and a driver-oriented approach to provide access to many geospatial data products and formats.
OGDI provides tools
to convert various formats into a uniform transient data structure, to
adjust coordinate systems, cartographic projections and platform-dependent
data representations, and to retrieve geometric and attribute data, all
"on the fly." It can access a growing number of geospatial data products
and formats, and it is tailored to use the Internet as a medium to distribute
geospatial data products.
The transient data
structure supports both geometric and attribute data. Geometric data is
divided into vector (area, line, point) and raster data (line or tile access).
Metadata used includes geographic regions and coverage, cartographic projection
and sources.
Drivers are used to access various geospatial data formats, one for each format. A driver is also a dynamically loadable library that processes C language API requests for a specific datastore. Once a driver is loaded, it receives requests, fetches information from the datastore, translates it into the uniform transient data structure and returns the results to the application. All the APIs are available for UNIX operating systems (Solaris and Linux) and for Microsoft's Windows NT and Windows 95 operating systems.
Drivers can be accessed either directly, for local datastores, or remotely, for external datastores. To improve the exchange of geospatial data over the Internet, a new stateful protocol GLTP (Geographic Library Transfer Protocol) has been developed to replace the stateless HTTP (Hyper Text Transfer Protocol). With stateless protocols, such as HTTP, each query (or call to a method) is processed independently such that only one server is sufficient to communicate with several users. For OGDI, a protocol with a "persistent memory" was necessary to handle successive related queries or geospatial transfers. In contrast to HTTP, there is a server process for each client.
This new protocol has been integrated into a small utility program called gltpd (geographic library transfer protocol deamon) that mimics the behavior of the C language API on a remote computer. The combination of the gltpd process and a specific driver becomes a server to the client (i.e., the application's connection). For a programmer using OGDI, there is no difference between a local driver and a remote one. The gltpd process takes care of the communication protocol transparently and automatically transforms data between incompatible processor architectures. In the current implementation, the gltpd process is based on the ONC RPC 4.0 protocol.
OGDI drivers are already available for several geospatial formats such as VRF/VPF, ADRG, CADRG, CIB, DTED, CCOGIF, CEOS, Oracle SDO, GRASS, PAMAP, Arc/Info, DGN, DWG, DXF, USGS DLG-3 and USGS DOQ. Drivers will soon be developed for other geospatial formats such as GeoTIFF, Mapinfo MID/MIF and Imagery (TIFF, GIF, PCX, BMP, etc.).
To interact with a datastore, a simple application goes through a sequence of steps. First, it establishes a connection or creates a "client," the term used to describe each instance of a connection. Second, it selects a geographic region. Then it selects a map layer and extracts objects from it, either sequentially or randomly. It processes the results and finally terminates the connection.
Each connection between the application (a client) and a driver (a server) is defined by an ASCII string similar to the Uniform Resource Locator (URL) used by the World Wide Web. Each string is prefixed by "gltp" (analogous to the URL prefixes "http" or "ftp"). The prefix is followed by a host name for remote driver access, a driver descriptor and then a file path-name that indicates the location of the datastore. The general form is:
gltp:[//<hostname>]/<name of driver>/<pathname> . The hostname is not used when accessing a local datastore.The use of OGDI in the GRASSLAND GIS software package is demonstrated, highlighting direct access to several geospatial data formats, including GRASS, VRF, ADRG and DTED. Considerations about future OGDI development such as writing new drivers, applying spatial analysis services to geospatial data accessed through OGDI in its native format, improving remote communications, adding encryption facilities and authentication services are discussed.
Finally, the strong interest shown in OGDI from two important international committees: the ISO/TC 211 (International Standards Organization/Technical Committee 211) and the OGC (Open GIS Consortium) is briefly outlined.
OGDI and its source
code are freeware in order to improve the interoperability of GIS software.