[gdal-dev] Update on RFC 62: Raster algebra

[Ari Jolma]

There's been some discussion here about doing pixel function 
calculations in VRT derived bands, so I thought I'd let you know what 
are my thoughts and what I've done regarding RFC 62.

At FOSS4G my conclusion was that my first approach was not good for many 
reasons, most importantly because it did not scale to several bands in 
one operation. So I've trying with the following ideas/decisions:

The problem is to compute y=f(x1, x2, ...), where y is a new dataset 
with one band or an existing dataset, into which a new band is added. 
x1, x2, ... are existing bands. f is an expression. The goal is to be 
able to create an expression object, with which one can write

y->compute(f);

The expression object is a tree and its nodes are operators (+,-,...), 
functions (abs, floor,...), band objects, values, and possibly more 
complex data structures (for example classifiers). It should be possible 
to define focal functions (e.g., for terrain analysis).

The compute algorithm is something like this:

for_all_blocks_of_y {

     f->cache_blocks(required_region);

     compute_the_block_of_y(f, block_of_y);

     f->free_blocks();

     write_block(block_of_y);

}

One block of y is computed cell by cell using a recursive 'get_value' 
method on the expression. The call would have the (global) cell 
coordinates as arguments. Non-spatial nodes would ignore them but 
spatial nodes need them. There would be get_value methods for all GDAL 
data types.

It's rather brute force but it should be easy to parallelize and it is 
very general and extensible - expression node types can be subclassed 
easily.

This is partly working but it's all still on my own computer and not 
committed to github. One thing I'd like to have quite early is an 
expression parser to make testing easier etc. I have not done any 
profiling so I have little idea about where the bottlenecks would be.

I plan to present this on our local developer oriented FOSS4G meeting 
next month so I guess I'll need to work on it more soon.

Ari