TerraLib and TerraView Wiki Page

This is an old revision of the document!

Data Access Module

The Data Access module provides the fundamental layer for applications that handle spatial data from different sources, ranging from traditional DBMSs to OGC Web Services.

This module is composed by some base abstract classes that must be extended to allow the creation of Data Access Drivers which actually implement all the details needed to access data in a specific format or system.

This module provides the base foundation for an application discover what is stored in a data source and how the data is organized in it.

Keep in mind that this organization is the low-level organization of the data. For instance, in a DBMS, you can find out the tables stored in a database and the relationships between them or detailed informations about their columns (data type, name and constraints).

It is not the role of this module to provide higher-level metadata about the data stored in a data source. This support is provided by another TerraLib module: Spatial Metadata module.

This section describes the Data Access module in details.


As one can see in the class diagram below, the Data Access module provides a basic framework for accessing data.

Data Access Class Diagram

It is designed towards extensibility and data interoperability, so you can easily extend it with your own data access implementation.

The requirements that drove this design were:

  • extensible data formats/access: the API must be flexible enough to allow new data source driver implementations for new data formats.
  • data type extension: it must be possible to add new data types to the list of supported ones. The API must provide a way for developers to access new data types that exist only in particular implementations. The new data types can be added to all data source drivers or just for part of them. This will enable the use of extensible data types available in all object-relational DBMS.
  • query language extension: it must be feasible to add new functions to the list of supported operations in the query language of a specific driver.
  • dynamic linking and loading: new drivers can be added without the need of an explicit linking. The data access architecture must support dynamic loading of data source driver modules, so that new drivers can be installed at any time, without any requirement to recompile TerraLib or the application.

The yellow classes with the names in italic are abstract and must be implemented by data access drivers. Following we discuss each class in detail.