|
Open Geospatial Datastore Interface (OGDI): A geospatial data infrastructure solution
The following subsections define OGDI, describe its main characteristics and architecture, list the geospatial data formats it understands and show how to integrate it into an application.
OGDI is an application programming interface (API) that sits between a GIS software package (the application) and various geospatial data products (or drivers). The open style of OGDI is similar to that of Microsoft Open DataBase Connectivity (ODBC), a programming interface that allows applications to access data in a data base management system using Structured Query Language (SQL). Like ODBC, OGDI uses a driver approach, achieving interoperability by accessing each geospatial data format through an appropriate driver. OGDI is a collaborative and coordinated effort within NATO nations, intended to avoid duplication. Consequently, it and all its source code has been made available the public domain: there are no fees and there is no private club associated with it. Section 6 gives the Internet addresses where the source code is available. OGDI is also an evolving concept that is simple and easy to maintain. OGDI is already available. It is presently in its third generation implementation, which implies robustness and maturity. OGDI is based on the TCP/IP protocol and consequently can easily use the Internet as a medium to distribute geospatial data products. OGDI facilities can be accessed either through an ANSI C or a Tcl/Tk API, which can be called from Win32 or UNIX applications. OGDI provides tools for some of the most difficult geospatial data integration tasks, including: The transient data model 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. More information on the transient data model can be found in LAS (1996a). Figure 1 illustrates the components of the OGDI architecture. A dynamically loadable C language API is normally used to access OGDI facilities. Alternatively, a Tcl/Tk API can also be called from an application. Drivers are used to access various geospatial data formats, one for each format.  Figure 1: OGDI Architecture 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. For remote procedure calls, other components are needed. The gltpd (geographic locator transfer protocol deamon) module is a small utility program that mimics the behavior of the C language API on a remote computer. The network driver is a special dynamically-loadable library that relays calls from the C API to a gltpd process running on a remote computer. The gltpd process and the network driver are used together to link the application to a remote driver through a TCP/IP network, allowing the application programmer to access remote drivers as if they were local, using a client/server paradigm. When the gltpd process receives its first request from an application, it creates a new thread (a fork) of itself, which loads the requested driver type, takes control of the communication process with the network driver and serves all subsequent OGDI calls coming from the application. 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 and the network driver take care of the communication protocol transparently, and automatically transform data between incompatible processor architectures. In the current implementation, the gltpd process and the network driver are based on the ONC RPC 4.0 protocol. To standardize vocabulary, "client" is used to describe a connection made by an application, and "server" to describe an instance of one driver connected to one application. A new component called "gltp" is used by OGDI. It is similar to the "http" or "ftp" prefixes of the Web, and it gives direct access to a local database or remote access to an external database. The range of available adapters covers most of the actual geospatial data products on the market place. Currently, over 50 different GIS (vector and raster), CAD and imagery data formats can be accessed without the need to convert them in advance. The C-language API is the heart of OGDI. It is a dynamically loadable C library composed of 20 functions that programmers use to access OGDI facilities. A complete list of these functions with a complete set of instructions for programmers can be found in [LAS 1996a]. The underlying philosophy of OGDI is to encapsulate all the tasks related to geospatial database access in a simple and standard API. With OGDI, an application is isolated from the details of integrating a new kind of datastore. To interact with a datastore, a simple application goes through the sequence of steps shown in Figure 2. First, it establishes a connection or creates a "client. Second, it selects a geographic region. Then it selects map layer and extracts objects from it, either sequentially or randomly. It processes the results and finally terminates the connection. |