DSpatial is not a GIS like any other. First and foremost because it does not try to be a GIS, but (apart from that little detail) it does implement a number of features that make it stand out against the other (commercial) offerings.

DSpatial is a collection of code modules that can be assembled by a programmer to fit some specific need. Basically, only two of those modules are required for a valid application: the kernel and the PFA. Any useful application would also include a number of drivers to access data sources, one or more analysis modules, and the visualization module. The programmer works above the level of the kernel, PFA, and drivers, working mostly with the analysis and visualization modules.



The kernel manages the internal organization of the components and the data that flows between them. It makes sure that the computer remains responsive by keeping memory consumption in check, by isolating lengthy processes from the user interface, and by efficiently storing large data sets. The kernel is thread-safe, and guards against data corruption. Most of the basic components of the kernel that have different "forms" are implemented in an object-oriented hierarchy, having abstract methods low in the hierarchy. For instance, a raster data set (TDSpRaster) derives from a base data set (TDSpDataset) as a user view to a data source. The data itself is stored in a descendant of TDSpDataSource, the DSpatial "equivalent" of TPersistent. The abstract methods provide a consistent calling interface to you as the programmer. As a programmer you will rarely have to access the kernel directly, accessing its components through these standard interfaces.


Pluggable Format Architecture

The Pluggable Format Architecture is part of the kernel and it provides access to all the data sources that you might use with DSpatial. It is a thread-safe environment that supplies the programmer with a consistent interface to a small number of data set types (e.g. raster, vector, database), making it easier to work with diverse data formats.

The PFA is thread-safe, providing the internal data manager with a handler which has exclusive access to a physical resource. The internal data manager (unit DSpDataMgr), of which there can be many at any given time, requests a handler from the PFA and it then fires off requests for data to the handler, which in turn passes the request on to the reader. Confused? Don't worry, because you will not need to deal with the PFA or the handler directly. From the DSpatialGIS:

// Get the filter of supported raster data sets
dlgAddSource.Filter := PFA.FilterString(dspReadRaster);

if dlgAddSource.Execute then

  // Iterate through all the selected sources

  for i := 0 to dlgAddSource.Files.Count - 1 do begin

    h := PFA.OpenSource(dlgAddSource.Files[i], ofReadOnly in dlgAddSource.Options);

    // Do something with the source handler h



The PFA variable is an instance of TDSpPFA, which is automatically created and of which your application needs only one. Variable h is an instance of TDSpSourceHandler and it is the single point of access to a data source. The source handler uses access tokens to control access. Granularity of the tokens is currently at the data set level. A single handler can support multiple data sets, although not all data formats allow multiple data sets. (Examples of formats that do are DSpatial, TIFF and HDF.)

You can link a data driver into your project, or use it as a dynamic library. Adding a static driver to your project requires no coding at all (really!). All you have to do is include the unit that contains the driver in your project, and update the search path for the project. The driver will register itself with the PFA in its initialization section. (Currently the PFA does not yet support dynamically loaded drivers, this is planned for a later version.)



The visualization pipeline starts with the TDSpViewer component, available from the DSpatial palette page if you installed the DSpatial component package. The viewer knows nothing about spatial data, it only knows about renderers (TDSpRenderer). The renderer has references to any number of data sets maintained by a data manager (TDSpDataMgr) and a transformation (TDSpRRT) to go from data to pixel colour.

Interestingly a renderer can display multiple data sets in one pass, making it easy to work with tiled data, such as the USGS DEMs. Get yourself any number of adjacent DEMs and add them all to a single renderer. (Drag the first raster band to anywhere in the list of renderers. Expand the list to show the new renderer. Add additional raster bands by dropping them on the new renderer. Click Update.)

Another really interesting feature is that a data set can be instructed to render to a single colour band of the viewer, such that you can blend different data sets into one display, no matter how the data sets are aligned to eachother. This is particularly useful with multi-spectral satellite imagery, such as Landsat, MODIS, Ikonos, SPOT, etc. As an added sophisticated feature, you can load a high resolution pan-chromatic image (pan band of Landsat, SPOT, or Ikonos; aerial photograph, etc) and assign that to the pan band of the 3-channel renderer, which will enhance the image using pan sharpening.

You can also save your raster data as a graphic, using the current renderer settings. You can save either the contents of the viewer, or a single renderer having one or more raster bands. In this latter case, when a renderer has a single band, the graphic will have the same resolution (in pixels) as the source data; when a renderer has multiple bands, the resolution is determined by the raster band having the coarsest resolution. Since the actual generation of the graphic uses the standard TPicture design, you can plug any graphics writer that you prefer.


Go to SourceForge
Last modified: 10 January 2007. Page maintained by pvanlaake