[gdal-dev] Update on RFC 62: Raster algebra
ari.jolma at gmail.com
Thu Sep 22 00:54:40 PDT 2016
13.09.2016, 15:40, alex kirjoitti:
>> Ari Wrote:
>> 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
> Hi Ari,
> Perhaps it is worthwhile looking back at the email I wrote earlier in the process:
> At the time, I suggested using expression objects and to allow functions with more than 2 arguments and gave some suggestions on the implementation.
Yes, that has had impact on my thinking.
> In my experience the key first step is to develop pixel iterators for raster bands. Once you have that, raster bands can be wrapped as regular ranges and you can make use of 'regular' tools and methods to develop your expression objects, e.g. as in the Range v3 library by Eric Niebler.
> Hence, my repeated suggestion for GDAL: create iterators for raster bands :)
It is still my opinion that the iterators must be in practice two level:
block and cell.
Anyway, I might at least cease working on the RFC now, if not withdraw
it. I'll rewrite the RFC text to reflect what I found out.
The main reason is that I took a new look at using PDL (Perl Data
Language) for raster algebra at the block level. I've had some support
for it in the Perl bindings for a long time but improved it lately. I
haven't done a comprehensive review but basically PDL is for Perl
perhaps what NumPy is for Python. I've now improved and documented the
'Piddle' method for Band objects, with which one can read data from Band
to a PDL object and vice versa. The method is surprisingly simple and
doesn't need any support from Swig. That solves mostly my immediate
needs but of course leaves open for example the question how to link
GDAL to for example some terrain analysis algorithms which need
neighborhood operations etc.
For information about PDL go to http://pdl.perl.org/
PDL and some related modules support parallel programming which is
interesting but I haven't yet any experience from it.
> As you may recall, the code below works just fine (but requires C++11).
> With kind regards, Alex
> #include <blink/map_algebra/map_algebra.h>
> namespace ma = blink::map_algebra;
> int my_function(int w, int x, int y, int z)
> return w * x + y * z;
> int main()
> auto a = ma::open_read_only<int>("input_1.tif");
> auto b = ma::open_read_only<int>("input_2.tif");
> auto w = ma::create_from_model<double>("output_1.tif", a);
> auto x = ma::create_from_model<double>("output_2.tif", a);
> auto y = ma::create_from_model<double>("output_3.tif", a);
> auto z = ma::create_from_model<double>("output_4.tif", a);
> // Example 1: Using operators
> w = a + 3 * b;
> // Example 2: Using assigning operators
> x = 1;
> x *= a;
> x += 3 * b;
> // Example 3: Map algebra using cell-by-cell functions
> y = ma::apply(my_function, 1, a, 3, b);
> // Example 4: Combination
> z = b + 3 * ma::apply(my_function, 1, a, 2, b);
> return 0;
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev