This page discusses how to integrate om with the TerraLib library. TerraLib is an open source C++ library allowing a collaborative environment and its use for the development of multiple GIS tools. Its main aim is to enable the development of a new generation of GIS applications, based on the technological advances on spatial databases TerraLib databases can store vector and raster data in databases build on object-relation Database Management Systems, such as PostGIS, MySQL or Oracle.
The integration with TerraLib will make it possible to use data sets from a geographical database as environment maps and occurrence variables.
The first stage of this integration is concerned with the Environment maps. TerraLib provides a class called TeRaster, responsible for dealing with raster data. Although TeRaster is a generic API that can decode raster files in well known formats as GeoTIFF, JPEG or ASCII-GRID, it also can handle a raster data stored in a TerraLib database.
The architecture of om to access raster data is:
We propose to create a Abstract Raster Interface. A Raster is an implementation of this interface. A Raster TerraLib is another. This proposal minimizes the changing impact for om users. The new architecture is:
This new architecture will also simpify possible further integrations, with other data sources.
1. Comments
The proposal above has interesting advantages.
First, it clearly decouples om from GDAL by adding another adapter to a different raster library. Second, it simplifies the task of adding the terralib adapter by moving all existing raster code to the "GDAL side".
Actually, the proposed GenericRaster interface seems to have the same original purpose of the Raster class, as we can see from an old class diagram below. However, for some reason the existing code still does not reflect that idea.
So, following the suggested strategy, a next step would be to move the existing functionality from Raster to RasterGdal.
Obviously, more details will need to be sorted out during implementation.
If we have more than one raster library available through adapters, om should ideally be able to use different raster libraries for each map in a single experiment.
Anyway, om will somehow need to know which adapter needs to be instantiated on each situation, not only at the library level but also at the interface level. The current adapter for GDAL could be the default when none is specified. There are interesting ideas about how to specify the adapter. Kevin suggested to prefix maps, making them look like URLs, so the console request file could specify maps like:
Map = gdal://somedirectory/file.tiff
Map = terralib://mysql.localhost:3306/dbname/rastername
This also suggests that another interesting adapter could be especialized in WMS (btw, that was also suggested by Kevin). The curl library could be used to retrieve remote rasters as well.
After adding support to Terralib, it's also important to include another autoconf/automake option --enable-terralib or --with-terralib.
--Renato