RFC 62 : Raster algebra
Author: Ari Jolma
Contact: ari.jolma at gmail.com
Implementation in version:
It is proposed that a set of functions or methods are written for raster band objects to support “raster algebra”, i.e., a set of operations, which modify bands or compute values from bands. An example of a modification is adding a value to all the cells of the band. An example of a computation is the maximum cell value in the band. Operations may or may not take arguments, in addition to the band itself, and if they take, the argument may be a numeric value, a data structure, or another band. Similarly, the computed value may be a simple numeric value, a data structure, or another band.
Raster algebra is a well known branch of geospatial science and technology and an often needed tool. Currently GDAL does not have comprehensive support for raster algebra in core.
The implementation should be data type aware. This may mean code written with templates.
The implementation should be parallel processing friendly.
The implementation should allow a relatively easy to use C++ / C API. This may mean interface, which does not use templates.
The implementation should allow arbitrary functions on cell values. I.e., be extensible by the user.
The implementation should allow focal methods. I.e., methods, where the value of a cell depends on its neighborhood.
The implementation does not need to be tightly integrated with the core. This means an “add-on” type solution is ok.
GDAL design sets some constraints/requirements to raster algebra implementation: 1) the access to data is based on blocks, 2) GDAL supports several datatypes, even complex values, 3) there is no immediate support for the not-simple data structures needed by some methods (by “method” I refer to functions of raster algebra in this text), 4) data can be read from a band in parallel but writing needs to be exclusive.
Drivers are not affected.
The functionality will be added to the bindings.
Existing utilities are not affected but new utilities may be written taking advantage of the new functionality.
Must be written.
Must be written.
A proposed implementation is developed at https://github.com/ajolma/raster_algebra
This code attempts to solve the problem as follows. (The source is in transition from an old approach, which was based on operators as methods, while the new approach is based on operator classes)
Classes ‘operand’ and ‘operator’ are defined. An operand is an object, which holds data and an operator is an object, which computes a result (essentially an operand) from operands.
Raster algebra computation is a tree of operand and operator objects, which is executed in a recursive fashion.
There are interface classes and templated concrete classes. The concrete classes inherit from the interface classes.
Two operand classes are defined: a number and a band. There is a need for other types of operands. For example a classifier would map integer values or real number ranges into numbers. Code for such exists in the source but it is not organized to reflect the new approach.
A central method is ‘compute’ in band class, which is basically the effective block loop code presented in the documentation for GDALRasterBand::ReadBlock.
Multiple data types are supported by template concrete class for bands and by overloaded get_value method, which returns the value in required data type.