GISdevelopment.net ---> Technology ---> Geographic Information System


Open Geospatial Datastore Interface (OGDI): A geospatial data infrastructure solution

Gilles Clément and Christian Larouche
Global Geomatics Inc. 1600, St.Martin Blvd. East,Tower A,
Suite 650, Laval, Quebec, Canada, H7G 4R8
tel.: (450) 668-4949, fax: (450) 668-2822,
Email: gc@globalgeo.com


Abstract
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 suppliers have developed versions of geospatial data products for several software packages.

Geospatial data format standardization is one solution to this problem. However, standardization efforts alone will not solve the geospatial data conversion and integration problem by itself. This paper proposes a solution called Open Geospatial Datastore Interface (OGDI) to leverage and to accelerate this standardization effort. OGDI uses a client/server architecture to facilitate the dissemination of geospatial data products over the Internet or a corporate Intranet and an adapter-oriented approach to facilitate access to several geospatial data products and formats.

OGDI provides a solution for some of the most difficult geospatial data integration problems. These solutions include:
  • conversion of various formats into a uniform transient data structure
  • adjustment of coordinate systems and cartographic projections
  • retrieval of metadata, geometric and attributes data
  • access to a growing number of geospatial data products and formats and
  • use of the Internet as a medium to distribute geospatial data products.
Use of the OGDI-based technology through pure html and simple Java applications working with main Internet browsers and through plug-ins working with popular GIS packages will be demonstrated, highlighting the direct access to several geospatial data formats such as Shapefile, GeoTIFF, MidMif, MrSID and DIGEST raster and vector products.



Open Geospatial Datastore Interface (OGDI)


1. Introduction
The geomatics industry has grown continuously over the last two decades, and the number of application domains in which Geographic Information System (GIS) and geospatial information are used has increased every year. However, growth in the industry has not lived up to the predictions made 10 years ago, especially compared with that of other information technologies such as Internet, Office Automation or Sales Automation.

The major reasons for slow growth are the lack of digital geospatial data and its high cost, the geospatial data barrier, problems integrating GIS into existing systems, and the complexity of existing GIS software [Larouche et al. 1996]. The geospatial data barrier is probably the most significant problem: geospatial data products are offered in a large variety of different and incompatible formats, many using different coordinate systems or cartographic projections.

In order to leverage on the standardization efforts and to provide a solution to the geospatial data integration problem, the Department of National Defence (DND) of Canada and Global Geomatics Inc have developed the Open Geospatial Datastore Interface (OGDI). OGDI is an application programming interface (API) that sits between a GIS software package and various geospatial data products and, using a standardized access method, provides solutions to some of the most difficult geospatial data integration problems. OGDI source code has been contributed to the public domain, in order to improve the interoperability of GIS software.

2. Solving the Geospatial Data Barrier Problem
Billions of dollars have been invested worldwide in the production of geospatial datasets. These datasets have been developed for a large variety of application domains, such as municipal planning, forestry, mining, environmental, and military command-and-control applications. Each of these applications has specific requirements (e.g., raster or vector representation, level of detail, set of coverages, projection, datum), so the datasets have been produced in a variety of formats, in many cases targeted at specific GIS packages.

In order to take advantage of existing data and to minimize production costs and the duplication of effort, geospatial data must be shared. Because data conversion and integration costs are high, two solutions have been developed through the years to solve the geospatial data barrier problem: data translation and data standardization.

  1. Geospatial data translation
    In most cases, GIS developers have developed their own proprietary geospatial data format, specifically designed to speed up the display and query of data in their particular systems. Their solution to the geospatial data barrier problem is the use of ethnocentric translators that convert foreign geospatial data formats into their own format. Although this provides a certain level of interoperability, there are several drawbacks:

    • Lost of significant information because of different degrees of completeness.
    • Duplication of effort by vendors who must write translators for the commonly used geospatial data formats.
    • Duplication of effort by data suppliers who have to develop tailored versions of their geospatial data products for several software packages.
    • Adoption of incomplete de facto industry standards because of difficulty and cost of data integration.

  2. Geospatial data standardization
    Over the past several years, users have been encouraged to adhere to a set of international geospatial standards and thus to minimize the number of geospatial data formats in the marketplace, in order to reduce duplication of work, optimize resource expenditure and facilitate information exchange.

    A number of digital geospatial data exchange standards have been developed, and although their use does not completely eliminate the need for translators, it does provide better interoperability by specifying the information to be exchanged. Among the most interesting of them, in terms of completeness, flexibility and life expectancy, are:

    • the DIgital Geographic information Exchange STandard (DIGEST);
    • the Spatial Archive Interchange Format (SAIF); and
    • the Spatial Data Transfer Standard (SDTS).

    Standardization is a positive step toward solving the geospatial data barrier, but by itself it isn't enough, since it is highly unlikely that the industry will move to a single standard. It is more probable that at least a half-dozen principal standards will coexist. Moreover, billions of dollars of legacy datasets must continue to be supported.


  3. Open GIS frameworks
    Over the last three years, significant initiatives have been taken to address the geospatial interoperability issue at a more global level than just the geospatial standard. In addition to national initiatives on spatial data infrastructures, three important bodies are conducting work on GIS frameworks, in order to improve geospatial interoperability:

    ISO/TC 211. ISO/TC 211, is an international effort to establish industrial and world standards in geomatics. TC 211 provides a politically neutral forum for all proponents to align their respective standards.

    OGIS. The Open GIS Consortium is an open forum for the GIS community to contribute to the interoperability in geodata and operations [Buehler et al. 1996].

    DGIWG. The Digital Geographic Information Working Group (DGIWG) promotes the use of DIGEST by providing a set of freeware tools, interoperability over geospatial data, direct and transparent access (platform and projection independent) to DIGEST-compliant data, and a worldwide data access through communications networks (Internet/Intranet, local and wide area networks).

    The Department of National Defense, in partnership with Global Geomatics Inc has been developing the DIGEST Geo Components to promote the use of DIGEST. A key component, the Open Geospatial Datastore Interface (OGDI), provides a good solution to the geospatial data barrier problem.
3. Open Geospatial Datastore Interface (OGDI)
As has been described in the previous sections, the geospatial data barrier problem exists because various geospatial data products, in different formats and cartographic projections, coexist and need to be integrated. In a way, the situation is analogous to the multiplicity of languages that coexist. Multilingual people can share information with each other without having to translate into their mother tongue. For example, if English-speaking people were to learn to read Chinese and vice versa, nobody would have to learn to write Chinese; the Chinese would know how to read English.

Applying this "learn foreign languages instead of being ethnocentric" theory to geospatial data has led to the Open Geospatial Datastore Interface (OGDI). Using OGDI, different geospatial data formats can be read without any translation or conversion.

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.

  1. Definition
    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.


  2. Main Characteristics
    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.


    3. 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 conversion of various formats into a uniform transient data structure;
    • the transparent adjustment of coordinate systems and cartographic projections;
    • the transparent transformation of platform-dependent representations; and
    • the retrieval of geometric and attribute data.

    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).

  3. Architecture
    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.


  4. Available Drivers
    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.


  5. Using the API in an application
    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.




Figure 2: Using the OGDI API in an Application


4. Conclusion and current developments
The previous sections have described how OGDI provides direct and transparent access to a large number of geospatial data formats. Currently, OGDI provides
  • retrieval functions for geometric and attribute data;
  • the transparent adjustment of coordinate systems and cartographic projections;
  • the transparent transformation of platform-dependent representations;
  • a growing number of geospatial data drivers;
  • the use of the Internet as a medium to distribute geospatial data products.
Currently, Global Geomatics Inc has improved the OGDI technology in the following ways:
  • compression/decompression, encryption and authentication facilities are provided;
  • spatial analysis services can be applied to geospatial data in its native format;
  • new drivers are developed with each new release;
  • Various format generator can be provided to allow user to generate data:
  • a VPF/VRF product generator driver
  • an Oracle 8I Spatial loader
  • an Informix Geodetic DataBlade loader
  • a World Wide Web map-viewer plug-in is available to provide a geospatial data browsing capability.
References
  • Buehler, K. and McKee L., 1996, The OpenGIS Guide, Open GIS Consortium Inc., OGIS TC Document 96-01, http://www.opengis.org
  • DGIWG, 1994. CGIS-DIGEST Canadian Geomatics Interchange Standard - Digital Geographic Information Exchange Standard, Edition 1.2, Canadian General Standards Board (Publisher), Ottawa.
  • Larouche, C., G. Clément, G. and T. Moore, C., 1996. Adapting GIS Technology for Decision-Makers, Proceedings of the 1996 Canadian Conference on GIS, Ottawa, Canada, June 4-10, 12p.
  • LAS (Logiciels et Applications Scientifiques Inc.), 1996a. Open Geographic Datastore Interface (OGDI), Version 1.0: Programmer's Reference, 145p.
  • LAS (Logiciels et Applications Scientifiques Inc.), 1996b. GRASSLAND USER'S GUIDE for Windows 95 and Windows NT, Version 1.1.


© GISdevelopment.net. All rights reserved.