Feature Data Objects Core API

The Feature Data Objects (FDO) Application Programming Interface (API) is a set of interfaces used to manipulate, define, and analyze geospatial information. FDO supports the retrieving and updating of spatial and non-spatial GIS feature data through a rich classification model that is based on OpenGIS and ISO standards.

From the perspective of a client application user: the FDO API provides consistent access to feature data, whether it comes from a CAD-based data source, or from a relational data store that supports rich classification. To achieve this, FDO supports a model that can readily follow the capabilities of each data source, allowing for consumer applications functionality that is tailored to match that of the data source. For example, some data sources may support spatial queries, while others do not. Also, a flexible metadata model is required in FDO, allowing clients to adapt to the underlying feature schema exposed by each data source.

From the perspective of a client application engineer: the FDO API provides a common, general purpose abstraction layer for accessing geospatial data from a variety of data sources. The API is, in part, an interface specification of the abstraction layer. A provider, such as FDO Provider for SDF, is an implementation of the interface for a specific type of data source, which in this example is an implementation for Autodesk's spatial database format (SDF). The API can support the standard data store manipulation operations, such as querying, updating, versioning, locking, and others, only when the underlying data store has the same capabilities for these operations.

Feature Data Objects API Architecture

The high-level architecture of FDO comprises feature providers that plug into an application to expose a consistent feature schema and a consistent interface for interacting with geospatial feature data, regardless of the underlying data store. The client applications interact through the various FDO interfaces, such as FdoIConnection or FdoICommand, using an FDO interface layer, or feature access manager.

FDO is assembled in or consists of conceptual packages of similar functionality. This packaging is reflected in the substructure of the FDO include folders. FDO commands, provider-specific commands, and connections/capabilities provide access to native data stores through each specific FDO provider. Schema management (using XML), client services, and filters/expressions are all provider-independent packages that connect directly to the FDO API.

Feature Data Objects API Code Organization

The FDO API is composed of three central source code directories

Fdo: The base FDO API written in portable C++ and compliable in a Windows or Linux environment. This directory is primarily composed of:

  • A set of FDO abstract interfaces that each FDO provider must implement in order to support various commands within the FDO API such as Select, Insert, Update and Delete features.
  • A Common API consisting of various generic FDO API classes that have been reused in the development of the FDO API and the supported providers that implement the FDO API.
  • A Geometry API that encapsulates the OSGeo geometry format. (See chapter 12 in the FDO Developers Guide)

Utilities: A set of utility libraries that are meant to be reused in the development of FDO providers. These libraries were not used in the implementation of the FDO API itself.

Thirdparty: The source code for a set of Thirdparty components that are used by the FDO API and its providers. Source code for these components is provided so that OSGeo can maintain compatibility between its OpenSource and Enterprise products.

NOTE: There is also an additional set of .Net managed C++ classes that serve as wrapper classes around the unmanaged API and allows the FDO API to be executed from within a Windows .Net application.